The Validation Checks That Should Run Before Structured Data Ever Ships

A rich result that quietly disappeared

A restaurant's site had star-rating rich results showing up in search for months, then they vanished with no announcement and no obvious site change. After some digging, the cause turned out to be a menu update that changed a price format in a way that broke the JSON syntax of an adjacent schema block — one misplaced character, invisible to a human editor scanning the page, but enough to invalidate the entire structured data block silently. Nobody noticed until the rich results disappeared weeks later.

Why 'it looked fine' isn't validation

Structured data is invisible in a rendered page, which means visually reviewing a page tells you nothing about whether its schema is intact. A single missing comma, an unescaped quotation mark inside a text value, or a mismatched bracket can silently break an entire JSON-LD block, and unlike a visible layout bug, nothing about the page will look wrong to catch it. Validation has to be a deliberate, separate step, not something that happens by eyeballing the page.

The checks worth running before every deploy that touches schema

1. Run the exact JSON through a syntax validator (even a basic JSON linter) to catch structural errors — missing commas, unescaped characters, mismatched brackets — before worrying about schema-specific correctness
2. Run the page through a schema-specific testing tool to confirm the markup matches an actual schema.org type and required properties are present
3. Manually compare every fact stated in the schema against what's visibly displayed on the page — price, hours, ratings, availability — since a mismatch between visible and structured content is treated as a policy violation by major search engines, not just a quality issue
4. Check that dynamic values (a price pulled from a database, a rating pulled from a reviews system) are actually populating correctly in the rendered schema, not falling back to a placeholder value that got hardcoded during development
5. Re-run all of the above after any change to the template that generates the schema, not just after changes to the specific page's content

• Syntax errors: JSON that doesn't parse at all, silently voiding the entire block
• Type mismatches: using an @type that doesn't match the actual business or content
• Content mismatches: schema stating a fact that contradicts what's visibly on the page
• Stale placeholder data: template defaults that never got replaced with real values
• Missing required properties for the specific schema type being used

A rich result that disappears without warning almost always traces back to a syntax error nobody validated for, not a policy change from the search engine.

Making validation part of the deploy process, not an afterthought

The most reliable fix is structural: treat schema validation as a required step in the deploy checklist for any template or page that includes structured data, the same way a syntax check runs against PHP or JavaScript before a deploy is considered safe. A lightweight automated check that confirms JSON-LD blocks parse correctly can catch the exact failure mode that took down the restaurant's rich results, before it ever reaches production.

A common misconception about schema markup

There's a tendency to treat structured data as a one-time setup task — add the schema once, move on, and assume it keeps working indefinitely because nothing about the visible page changed. Schema often breaks precisely because something adjacent to it changed, not because the schema block itself was touched directly. A template update, a CMS plugin update, or a content edit in a neighboring field can silently corrupt a JSON-LD block that nobody intended to modify at all, which is exactly why validation needs to be an ongoing habit, not a launch-day checkbox.

This is part of why an automated check, run on every deploy rather than remembered manually, is worth the modest setup cost — a human reviewer has to remember to check something invisible, while an automated validator simply always does.

How the stakes differ by business type

• A restaurant or automotive service center with frequently changing prices carries the highest ongoing risk, since price fields are both the most commonly edited and the most consequential to get wrong in structured data
• An events and weddings business with date-specific availability schema needs particularly tight validation, since a stale or broken availability field can misrepresent something time-sensitive that's hard to correct after the fact
• A professional services business (legal, financial, healthcare) with review or rating schema needs the visible-versus-structured match checked carefully, since a mismatch here is treated as a policy issue, not just a technical one

Whatever the industry, the underlying lesson is the same: the fields most likely to change frequently are the fields most worth double-checking after every edit, since frequency of change is exactly what creates the opportunity for drift between what's visible and what's structured.

Where this fits into a broader QA habit

This kind of validation gap tends to surface most in businesses that update pricing, hours, or inventory frequently — restaurants, automotive service centers, home services providers with seasonal offers — precisely because those are the fields most likely to get edited without anyone thinking about the schema sitting alongside them. NetWebMedia validates structured data as a standard part of deploy gates across the sites it manages; a live check of any page's current schema health is available through https://netwebmedia.com/free-audit.html.

← Back to all articles