Schema that invents facts is worse than no schema at all.

There's a tempting shortcut making the rounds: paste your homepage into a chatbot, ask for "SEO schema markup," copy the result into your site. It takes five minutes, the output looks impressively official. And buried in it, more often than not, is a lie.

Not a malicious lie. A helpful one. Language models are trained to produce plausible, complete-looking output, and complete-looking business schema has an aggregateRating, a founding date, an award or two. If your actual pages don't supply those, an eager model fills them in. A 4.9 from 212 reviews. "Established 1998." Whatever fits.

Why invented markup bites

Structured data isn't decoration. It's testimony. Search engines treat it as your official statement of fact, and they have explicit policies against markup that isn't backed by visible page content. Review markup with no reviews on the page is the canonical example: it can cost you rich results entirely, sitewide. You paid for a shortcut with your credibility.

AI assistants raise the stakes further. An assistant that quotes your invented rating to a customer (who then can't find those reviews anywhere) has learned something about your domain's trustworthiness, and so has its training pipeline. The whole point of structured data is to be the source machines can trust without checking. One fabricated field poisons that.

The fix isn't a better prompt

You can tell a model "only use facts from the page," and it will, usually. "Usually" is the problem. Prompt instructions are suggestions, and on the ten-thousandth page one model in a hundred will still helpfully round your three testimonials up to a star rating. At scale, "usually grounded" means "sometimes fiction."

The reliable fix moves the enforcement out of the model entirely. In AnvixaAI's pipeline, the model is never asked to write your schema document. It's asked for a small judgment: what kind of page is this, which of the site's verified facts belong on it. Then deterministic code assembles the actual JSON-LD from your crawled content, your business profile, and your saved entities. Between assembly and publish, a sanitizer walks every field:

Grounded, and it stays grounded

Grounding isn't a launch-day property. It has to survive every later edit. So the same rules run on every regeneration: when your pages change and documents are rebuilt, wording you already approved is fed back in verbatim, profile facts are re-forced, and the strip-list is re-applied. There is no path (first publish, drift update, manual regenerate) where an unverified fact reaches your live markup.

That's the standard worth demanding from any schema tooling, ours included: every published fact should trace to your site, your profile, or your explicit approval. If a vendor can't tell you where a field came from, the honest answer might be "the model made it up."