Most advice about schema markup focuses on whether you have it at all. That's the wrong starting question for a lot of businesses. In our testing, sites with schema markup that's technically present but factually wrong come up more often than sites with no schema at all, and a broken block is a worse position to be in, not a better one. A model reading structured data has no way to know it's inaccurate. It simply treats it as fact.
Why a broken block is worse than no block
When a site has no schema markup, an AI crawler falls back to parsing the visible page text, which is imperfect but at least grounded in what a human reader would also see. When a site has schema markup with the wrong details inside it, a model has a structured, machine readable source telling it something false, and structured data is generally weighted as more reliable than loose page copy. That combination, confidently wrong and treated as authoritative, is exactly the kind of error that quietly costs a business a recommendation it should have won.
The four errors we see most often
- The business name field contains address or slogan text. A common copy paste error puts a marketing line, or the street address, into the name field instead of the actual trading name. A model reading this field will use whatever text is there, which means it may describe or cite the business incorrectly, or fail to match it against a search for the real name at all.
- An empty or placeholder phone number. Some schema blocks are built from a template that was never fully filled in, leaving the telephone field blank or set to a placeholder like "000-000-0000." A model treats this as the business having no contactable number, which removes it from any answer where contact detail matters.
- Postcode only addresses. An address field containing just a postcode, with no street name or number, is incomplete structured data. It often signals that a full address doesn't exist in plain text anywhere else on the site either, which compounds the problem for local search and local recommendation questions alike.
- Mismatched details across sources. A phone number, address, or business name that differs between the schema block, the visible page text, and the Google Business Profile creates a direct conflict. Rather than guessing which source is correct, a model often responds by trusting none of them fully, or by defaulting to whichever source it considers more authoritative, which is frequently not your own website.
How to actually check your own site
Run your homepage and your key location or contact pages through Google's Rich Results Test or Schema.org's own validator. Both will parse whatever markup is present and show you the fields it actually contains, not what you assume is there. Read every field against what's true today, not what was true when the block was first written. Business names change, phone numbers get reassigned, and addresses move, and schema markup has no mechanism for flagging that it's gone stale on its own.
The fix is usually smaller than it looks
Correcting broken schema rarely requires a rebuild. It's a matter of editing the specific fields that are wrong, matching them exactly against your current business name, address, and phone number as they appear everywhere else, and removing any field you can't fill with an accurate, current value. A shorter, accurate block beats a longer one with errors in it every time, because an AI model treats every field as equally trustworthy regardless of how many others are correct.
Build in a review point
Schema markup isn't a one time setup. Any time a phone number changes, a location moves, or opening hours shift, the schema block needs updating alongside the page content. Treating it as a living part of the site, checked whenever core business details change, is the difference between a fix that holds and one that quietly breaks again within a year.