WordPress.org SEO Plugin AI: A Review Template to Copy

What does a WordPress.org SEO plugin AI feature actually do?

A wordpress org seo plugin AI feature reads a page’s existing content and its target keyword field, then drafts a title tag and a meta description from that input. Some plugins extend the same feature to alt text or a short content summary. That’s the actual scope of it: a drafting tool for two or three specific fields, run either one page at a time or across a whole catalogue in a bulk pass.

What it doesn’t do is verify its own output against the rules that make a title or description work in search results. It doesn’t enforce a character ceiling. It doesn’t check whether the keyword lands in a useful position rather than buried at the end of a sentence. It doesn’t compare its claim about a product against the current state of that product’s page. And it has nothing to do with three settings that matter more to whether a page ranks at all: the canonical tag, the indexation directive, and the schema markup attached to the page. Those are configured separately, and getting them wrong breaks more than a weak meta description ever will.

Scale is where this compounds. A store or publisher running the bulk version of an AI drafting feature across a few hundred or a few thousand URLs in one pass produces just as many drafts, all built from the same prompt template and carrying the same character-limit blind spot, in one sitting. The proprietary element of this article is the template that catches that: a row-by-row review pass with every scoring assumption named, plus the ranked list of settings that outweigh the AI copy sitting on top of them.

How does bulk AI title and description generation work in practice?

The mechanism is consistent across most plugins that offer it: point the feature at a set of pages, either a manually selected list or a full content-type export, and it runs its drafting pass across all of them in one job. The output lands in the same fields a human would fill in by hand — the title and description meta boxes — pre-populated rather than blank.

The practical effect of doing this in bulk is that the AI feature applies one underlying prompt structure to every row. That’s efficient, and it’s also why bulk output reads templated when you scan ten or twenty rows in a row: the same sentence shape, the same kind of opening phrase, the same placement of the keyword, repeated with different nouns substituted in. Individually, none of these titles looks obviously wrong. Read consecutively down a spreadsheet, the pattern becomes obvious fast.

Bulk generation limits, whether measured per run, per day or per billing period, are set by the plugin and often by the specific pricing plan — confirm the exact number for your plugin and account rather than assuming one, since this is exactly the kind of vendor detail that changes between versions and tiers without much notice. What stays constant regardless of the limit is that the output needs the same review pass whether you generate ten rows or ten thousand — the review effort just scales with the row count, which is the argument for treating review as a per-row template rather than a one-off spot check.

Why does bulk-generated output still need a human review pass?

Because three of the most common defects in AI-drafted titles and descriptions are invisible to the AI feature itself: length overruns, templated phrasing that reads the same across many rows, and factual drift between what the draft claims and what the page currently shows. None of these are things a drafting model checks against, because none of them are part of what it was asked to produce — it was asked for plausible text, not text that fits an exact character window or matches a live inventory state.

Length overruns are the easiest to catch and the most common. A title generated without an explicit constraint routinely runs past a workable length once you add the site name or a category qualifier the plugin appends automatically. Google truncates titles it judges too long, and a truncated AI-drafted title reads as cut off mid-thought more often than a hand-written one does, because the AI draft wasn’t written with the cutoff point in mind. Our own standard for a title is 60 characters or fewer, and for a description, 130 to 158 characters — a specific window, not “under 160,” because a description that’s technically within the maximum but well under 130 still reads thin and under-explains the page.

Factual drift matters more on a commerce catalogue than almost anywhere else. An AI draft written from a product page’s current content is only as accurate as that content was on the day it ran. A price change, a discontinued variant, or a size that’s gone out of stock since the last sync can leave a bulk-generated description describing a product state that no longer exists. Google itself doesn’t just take a page’s word for either title or description: it rewrites what it judges as a weak or mismatched snippet with its own extracted text, meta description or not, AI-written or not — which means a templated-sounding AI draft is a candidate for rewriting precisely because it reads generic, not because it was AI-written specifically.

The fix isn’t to stop using bulk generation. It’s to treat bulk output as a first draft that every row passes through a fixed review step before it publishes, using a row-by-row review template.

A template for reviewing AI-generated titles and descriptions

Set this up as a spreadsheet with one row per URL and these columns, and fill it in as you review the bulk output rather than as you generate it — the columns are the review, not a record of the generation job:

The assumptions column exists because a review template that scores against unstated rules just moves the guesswork from the AI feature to the reviewer. Naming the ceiling, the window and the placement rule up front means two different people reviewing the same row reach the same verdict, which is the actual point of having a template rather than an ad hoc read-through.

Run the check in this order: character length first, because it’s mechanical and takes seconds per row; keyword placement second, because it’s a quick visual scan; factual accuracy last, because it’s the slowest check and the one worth skipping only for pages where nothing about price or availability changes often. A row that fails length gets flagged before anyone spends time checking its facts, since it’s getting rewritten either way.

For a catalogue small enough to review every row at a pace of a few dozen per session, work through the whole list. For a catalogue too large for that, review every row for your highest-traffic pages in full, and take a deliberate random sample of the long tail — a fixed percentage, chosen before you start, not “however many I get through before I stop.” A sample chosen after the fact, stopping once the reviewer gets tired, tends to catch the easy defects near the top of the list and miss the same kind of defect lower in the catalogue.

How do you adapt the template for a different catalogue size?

The six-column structure holds regardless of catalogue size; what changes is the review method applied to it, not the columns themselves. For catalogues under roughly a hundred URLs, review every row individually and skip sampling entirely — the time cost is small enough that a full pass is faster to defend to a stakeholder than explaining a sampling method would be.

Above that, sampling becomes the practical approach, and the sample needs two decisions made explicit before review starts: what fraction of the long tail gets checked, and how that fraction gets selected. A fixed percentage selected at random is defensible and repeatable. A fraction selected by whichever rows happen to be open in a browser tab is not, because it silently biases toward whatever the reviewer was already looking at for other reasons.

The factual-check column is the one that needs a different cadence by catalogue type rather than by size. A catalogue of fast-moving inventory — frequent price changes, frequent stock-outs, seasonal variants — needs its factual check re-run on a schedule, not just once at initial review, because a description approved as accurate in one review cycle can go stale within weeks. A catalogue of stable, slow-turnover products can run its factual check once and treat it as durable for longer, though “longer” still means a defined re-check interval, not indefinitely.

What breaks if you skip the factual-check column?

The mechanical checks — length, keyword placement — are the ones teams keep, because they’re fast and the failure is visible immediately in a character count. The factual check is the one that gets dropped under time pressure, because it requires opening the actual page rather than just reading the draft, and its failure isn’t visible in the spreadsheet at all.

What breaks is specific and slow to notice: a meta description in search results that names a variant, size or price that no longer matches the page a searcher lands on. The searcher doesn’t necessarily bounce immediately — they usually click through anyway, since the mismatch is between the snippet and the page, not something visible before the click — but a page that repeatedly disappoints what its own snippet promised accumulates a pattern search engines and searchers both notice over time, even without a single clear moment where it “broke.”

The factual check is also the one most likely to catch what the AI feature could not have known at generation time: content that changed after the draft was written. A bulk run generated in one afternoon and published without a second look a month later is describing whatever the catalogue looked like on generation day, not publish day, unless the factual-check column forces someone to compare the two.

Which plugin settings matter more than the AI feature?

Three settings decide more about a page’s presence in search than any title or description ever will, and none of them are part of the AI drafting feature: canonical tags, indexation control, and schema output.

A canonical tag tells a search engine which URL, among several similar ones, is the version to index and rank. Most WordPress SEO plugins default a canonical to the page’s own URL automatically, which is correct for a standalone page and wrong for a filtered or paginated variant of a page that already has a canonical version elsewhere. Whether canonical handling sits inside the same plugin settings as the AI feature or in a separate section varies by plugin and by version — confirm this directly in your specific plugin’s current documentation rather than assuming it works the same way it did in a previous version, or the same way a different plugin handles it.

Indexation control — a noindex directive on a page, or a rule in robots.txt — decides whether a search engine can index the page at all, independent of anything the page’s title or description says. A page accidentally set to noindex, whether through a plugin default, a staging setting left on after launch, or a bulk rule applied too broadly, doesn’t show up in search results regardless of how well its AI-drafted title performs, because it was never eligible to rank in the first place. This is worth auditing on its own, separately from a title-and-description review pass, because the two failures look identical from a traffic report — a page with no impressions — but need completely different fixes.

Schema output is the third. Most plugins generate structured data — product markup, article markup, FAQ markup, breadcrumb markup — through settings tied to content type, triggered separately from the text-drafting AI feature. Confirm which schema types your plugin actually supports and how each one gets triggered, since schema that doesn’t match what’s visibly on the page is a problem search engines penalise directly, not just a missed opportunity.

The order to check these in, for a page that isn’t performing the way its content suggests it should: indexation first, since a noindexed page can’t rank at all regardless of anything else; canonical second, since a wrong canonical can point a search engine at a different page entirely; schema third, since mismatched schema draws a penalty rather than a neutral non-result; and the AI-drafted title and description last, since a weak title on a correctly indexed, correctly canonicalised, correctly marked-up page is a much smaller problem than any of the first three.

What does the AI feature not do, and where does that matter most?

The AI feature doesn’t understand your catalogue’s business logic — which products are seasonal, which variants are discontinued, which categories compete against each other for the same keyword. It drafts from the text in front of it, not from context a category manager holds that never made it onto the page itself.

The AI feature also doesn’t optimise for how AI systems like ChatGPT or Perplexity summarise and cite a brand, which is a different problem from traditional search ranking. AI referral traffic to Shopify stores rose roughly 8 times year on year, with AI-search orders up nearly 13 times, according to Shopify president Harley Finkelstein on the company’s Q1 2026 earnings call (vendor-reported) — a shift worth taking seriously, but a title tag and meta description generated for a traditional search snippet are not the mechanism that drives it. Techniques specifically aimed at generative engine optimisation lifted AI visibility 30-40% in independent research from Princeton, a different set of levers entirely from what a WordPress SEO plugin’s AI drafting feature touches.

Where this distinction matters most is in expectations. A bulk AI drafting pass that produces clean, well-scored titles and descriptions across a whole catalogue is a solid traditional-SEO input. It is not a strategy for showing up in an AI-generated answer, and treating it as one because both happen to involve the word “AI” sets up a disappointing result against a goal the tool was never built to hit.

Who is this template not for?

This template assumes a catalogue and a team with enough volume that bulk generation is worth running in the first place — in practice, brands doing $3M-$30M in revenue on Shopify Plus or a comparable paid platform, with enough URLs that a manual, one-by-one writing process is genuinely slow. Below that floor, a smaller catalogue is usually faster to write by hand, page by page, with full context on each product, than to run through a bulk-then-review pipeline built for volume it doesn’t have.

It’s also not a fit for a catalogue where accuracy risk is high and review capacity is low — a small team managing a large, fast-changing catalogue is better served by writing titles and descriptions for its highest-traffic pages by hand and leaving lower-traffic pages with whatever the platform generates by default, rather than running a bulk AI pass across everything and then not having the capacity to review it properly. A half-reviewed bulk pass is worse than a smaller, fully hand-written set, because the unreviewed rows carry the same factual-drift and templated-phrasing risk without anyone catching it.

Getting the balance right between what AI can draft at scale and what still needs a person to check it is an AI search visibility problem, not just a plugin-settings problem, and it’s covered in more depth under AI search visibility.