Fixing Hallucinated Properties in AI-Generated Schema

What a hallucinated property looks like

In AI writing generally, a hallucination is a confident statement with nothing behind it. In generated JSON-LD it has a narrower meaning: a property whose value does not appear on the page and does not come from any system you control. The property name is real, the format is correct, and the value is simply made up.

Here is a typical case. A small bakery has a page about its sourdough class. The page gives the title, a description, the price and the Saturday date, and nothing else. The generated markup came back looking like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Course",
  "name": "Beginners' sourdough class",
  "description": "A three-hour hands-on class covering starters, shaping and baking.",
  "provider": {
    "@type": "Organization",
    "name": "Crumb and Crust Bakery",
    "telephone": "+44 1632 960123",
    "sameAs": ["https://www.facebook.com/crumbandcrustbakery"]
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "127"
  },
  "instructor": { "@type": "Person", "name": "Hattie Brindlecombe" }
}
</script>

Only the name and description were on the page. The phone number, the Facebook address, the 4.8 rating from 127 reviews and the instructor were all produced by the model because Course and Organization blocks in its training examples usually have them. Every one of them validates. None of them is true, or at least nobody has checked whether it is.

Why the model does this

• Pattern completion. The model predicts what a complete block of this type normally contains. An empty slot where a rating usually sits looks like a mistake to it, so it fills the slot.
• Prompt pressure. Instructions such as "generate complete schema" or "include all recommended properties" push the model to produce a value for every field, whether or not the page supports it.
• Nearby text. A testimonial quote becomes a Review with an invented reviewer name; "hundreds of happy customers" becomes a review count; a town name in the footer becomes a full street address.
• Training memory. For a business the model has seen before, it may recall an old phone number, a former address or a profile that has since been deleted.

Why invented values matter more than broken ones

A syntax error or a missing required field is annoying but honest: the markup simply does not work, and the page loses a rich result it never had. An invented value works, which is the problem. It can put false information in front of searchers, and it breaks the rule at the centre of Google's structured data guidelines, which is that markup must describe content visible to the people reading the page.

There is also a quieter cost. Structured data is one of the places where AI assistants and search features look for clean, machine-readable facts about a business. If your own markup states a wrong phone number or a founding year you never mentioned, you have published that error yourself, in the format most likely to be trusted. Nobody can promise that correcting your markup will change what a particular AI tool says about you, but there is no reason to feed it mistakes.

How to spot invented values quickly

The most reliable test is also the simplest: every literal value in the markup must be something you can point to. Either it is printed on the page, or it comes from a system you trust, such as your product database or your CMS author records. Values that meet neither condition are suspect, however reasonable they look.

Warning signs in the output

• Round, flattering numbers. Ratings of 4.7 to 4.9 with review counts in the low hundreds are a very common invented pattern.
• Names that are not in the byline. Any Person name you cannot find on the page, especially a common first and last name pairing.
• Tidy social links. sameAs addresses built from the business name, such as facebook.com/businessname, which may belong to somebody else or not exist.
• Phone numbers and postcodes you do not recognise. Also look for numbers in formats you never use on the site.
• Durations and quantities the page does not state. A prep time of exactly 15 minutes on a recipe that never mentions preparation time.
• Properties that are rare for the type. An award or knowsAbout list on a small local business page is usually the model decorating.

A quick search routine

Open the live page in one window and the generated JSON-LD in a text editor in another. For each string or number in the markup, copy it and search the page with Ctrl+F (Cmd+F on a Mac). Search for a distinctive fragment rather than the whole value, so formatting differences do not hide a genuine match: the last six digits of a phone number, a surname, the digits of a price. Remember that text inside collapsed tabs and accordions is still on the page; expand them before searching, or search the page source instead.

The fix, step by step

Which sources count, property by property

Some values can legitimately come from outside the visible page, as long as the page does not contradict them and the reader could find the same fact on your site. Others must be on the page itself. Use this as a rule of thumb when tracing values in step 3.

Organisation-level facts, such as your logo, legal name and social profiles, are best defined once for the whole site and referenced from each page rather than regenerated page by page. That way there is a single place to check them, and the generator has no reason to reinvent them. The guide on reference loss explains how to link to those site-wide entities.

Reducing hallucinations before they happen

Review will always be needed, but you can make invented values much rarer by changing what the model is given and what it is asked to do.

1. Make the facts visible. The model is most likely to invent a value when the page almost states it: a review quote with no reviewer, a class with no tutor named, a shop with no phone number in the footer. Put the real information on the page and the model has less reason to guess.
2. Set the type yourself on ambiguous pages. A wrong type invites wrong properties. A page generated as a LocalBusiness will attract opening hours and a telephone number even when it is only a blog post about your business.
3. Generate one type per page, not everything at once. Asking for an Organization, a Person and a Product in the same run gives the model many more empty slots to fill.
4. Keep site-wide entities out of the generation. Let your SEO plugin or template own the Organization and author entities, and remove the generated copies. The less the model writes about your business as a whole, the less it can invent.
5. Review in small batches. Generate five pages from a template, review them, and look for the invented properties that repeat. If every product page gains an invented rating, you know exactly which property to strip from the rest.

Harder cases

The value is true, but not on the page

Sometimes the model is right. It may know your real phone number or your founder's name from public sources. The rule still applies: markup should describe what the reader of this page can see. For contact details the better fix is usually to show them on the page, or to reference a site-wide Organization entity that is backed by your contact page. For anything you would not put on the page, leave it out of the markup.

Reviews that live on another platform

If your reviews are collected by a third-party service and displayed on your page through a widget, the ratings are on the page and can be marked up, usually by the widget itself. A rating total that only exists on an external review site, and is not shown on your page, should not be copied into your markup. Google's review snippet guidelines also exclude self-serving reviews of your own business on LocalBusiness and Organization markup, so check those guidelines before marking up any rating about your own firm.

Testimonials turned into reviews

A quote such as "Brilliant class, I will be back!" with a first name underneath may come back as a full Review with a rating the customer never gave. If you mark up a testimonial as a review at all, the reviewer name and any rating must match what the page shows. A testimonial with no star rating should not gain one.

Old facts the model remembers

For businesses that have moved, rebranded or changed number, the generator can produce the old details. These are easy to miss because they look familiar. Compare every contact detail with your current contact page, not with what you expect to see.