AI-generated schema markup: ship it straight or check every page against the copy first?

Letting the AI write JSON-LD for service pages is where most of the risk sits, and it's not about syntax. The output is almost always valid, so the rich results test passes. The problem is the schema saying things the page doesn't. FAQ answers that never show up visibly, or a price in the markup that differs from the rendered one, will both pass the test and then get flagged in Search Console weeks later.

The safer setup is to have the AI build the markup only from the visible page text, then compare each page against its rendered copy before it goes live. It's slower, but it keeps the markup from running ahead of the content. Does anyone just trust the output and clean up after Search Console complains?

Agreed on the FAQ problem, but for e-commerce the field that bites hardest is price and availability. The AI usually grabs the default variant's price, while the page only shows the sale price once someone picks a size. Or the stock line changes from a feed sync after the markup was written. The rich results test won't catch either one. So check those two fields against the live page for the variant that actually sells, not just the template, because a template can look right and still be wrong on your best-selling product.

If the sale price only shows up after someone picks a size, look at where the JSON-LD actually lives. If the markup sits in the server HTML but the price swap happens in JavaScript, the crawler sees one price in the source and a different one in the rendered DOM, and that mismatch is exactly what gets flagged. For multi-variant products, the cleaner setup is a ProductGroup with hasVariant, where each variant carries its own offers with price and availability, rather than a single Offer for the default size.

On the stale stock problem, don't treat the markup as something you write once. Have the template pull price and availability from the same feed that drives the visible page, so the two update together. Then run a scheduled comparison of the JSON-LD against the rendered price and stock line on your top sellers. That way a mismatch shows up as a diff you can fix the same day, instead of a Search Console warning a few weeks later.

ProductGroup as the fix? I don't think it gets you there. hasVariant describes the variants more cleanly, but it doesn't touch the problem you just named. If a variant's sale price only shows up after a JavaScript click, it still isn't in the server HTML, so all you've done is add more places for the source and the rendered DOM to disagree. I'd check first whether each variant's price and stock are in the initial HTML at all, and decide how to structure the markup after that.

Fair on restructuring not fixing a price that only appears after a click. But Googlebot does render JavaScript, so a JS-only variant price isn't invisible to Google. The real risk is the JSON-LD and the displayed price coming from different code paths, so they slowly drift apart.

Take a shoe store where size 42 is the bestseller. Fetch the raw HTML with curl, then pick size 42 in devtools and compare the two. If the source only has the default price, the markup should be generated from the same variant data the selector uses.

Agreed, the shared data source is what keeps this from drifting. One more thing about the click itself: Googlebot renders the page, but it doesn't pick size 42. It sees whatever state the default load produces, so a price that only appears after a size click is effectively the default variant's price as far as Google is concerned, no matter how well the JavaScript works. For a bestseller that matters, because the price shoppers see may never be the one in the snapshot.

If size 42 needs its own indexable price, it needs its own URL, either a dedicated variant page or a URL that renders that variant server-side, with its own canonical and its own markup. Otherwise your curl and devtools comparison will happily confirm the markup matches a state nobody actually lands on from search.

It comes down to whether people search for the variant by name. If "brand model 42" has real volume, a variant URL earns its keep. If shoppers just pick a size on the product page, one canonical URL with a shared data source is enough.

Volume is the right test, but I'd check it in Search Console before Keyword Planner. Filter queries by the brand plus the size or colour and see whether any variant queries already get impressions on the parent page. If they do, Google is already reading that page for those terms, and a separate URL might split the signal. If nothing shows up, the demand probably isn't there yet.

Once you do build a variant URL, don't point its canonical at the parent just to keep things tidy. That tells Google the variant's price doesn't need indexing, which defeats the whole point of the page. The variant needs a self-referencing canonical, its own server-rendered price, and enough distinct copy that it isn't a near-duplicate of the parent. A size 42 page with the same description and only a different price tends to get consolidated anyway.

Parent impressions on size queries don't prove a variant page would split the signal. Google often shows the parent for those queries just because nothing more specific exists, so those impressions show demand, not that the parent is winning. Before assuming a variant URL would cannibalize anything, look at clicks and average position for those queries.

Impressions alone can't tell you the parent is winning, Iris, so look at clicks and position together. Rule of thumb: if the variant query has steady impressions, the parent ranks in the top few for it, and clicks are already coming in, leave it alone. If the parent sits well down the results, a variant URL has a real shot.