Valid JSON-LD syntax does not guarantee that structured data describes the current page correctly. A product price may be out of date, or the markup may fail a Google feature's specific requirements even though the JSON itself parses.
While testing our JSON-LD inspector, I found that it assessed 9 of 12 prepared test cases incorrectly. I had to separate syntax checking, Schema.org validation, Google's feature requirements, consistency with visible content and testing the published URL. Each check answers a different question, so one green status cannot stand in for all of them.
Schema validator vs schema checker: vendor names, scope from the docs
A schema validator is a tool that checks the syntax and structure of JSON-LD or Schema.org data: it catches problems like invalid JSON, wrong types and mismatched values. "Schema checker" is another name for the same category. Both names come from tool vendors, and W3C and Google define no separate stages behind them, so one vendor's "checker" can check more than another's "validator".
Read the scope in the docs, the way Schema.org Markup Validator and Google's guide to testing structured data describe theirs, and ask four questions.
- Does the tool only parse JSON?
- Does it know the Schema.org vocabulary?
- Can it read a page that builds its data with JavaScript?
- Does it apply the rules for a specific rich result?
Three terms are also easy to mix up, so here's how they differ.
- JSON-LD is the linked data format from the W3C JSON-LD 1.1 specification.
- Schema.org supplies the names of objects (entities) and properties, such as
Article,Product,headlineoroffers(Schema.org data model). - JSON Schema is a separate language for constraints on JSON data, like the required fields in an API response (json-schema.org). It'll check your app's own contract, but Google's rules are foreign to it.
Google supports JSON-LD, Microdata and RDFa. According to Google's introduction to structured data, it generally recommends JSON-LD, because the data description sits apart from your HTML and is easier to maintain. I'd still keep correct Microdata where it is, even if a tool would score JSON-LD higher. For a short definition, see the glossary entry on structured data.
Five layers of structured data validation and the tool for each
Each layer has its own tool and answers its own question.
| Layer | Tool or method | What the result confirms | What the result doesn't tell you |
|---|---|---|---|
| Syntax | A JSON parser, e.g. JSON.parse | Whether the text can be read at all | Whether the Schema.org types exist and whether the data is true |
| Model and vocabulary | Schema Markup Validator | How the markup is read and issues related to Schema.org | Whether you meet the requirements of a specific Google feature |
| Search feature | Google Rich Results Test | A technical assessment for supported rich results | Whether the rich result will be shown |
| Deployment and content | Response code, DOM and a comparison with the visible page | Whether the right data was published and whether it describes the actual content | How Google read that data |
| How Google reads it | URL Inspection in Search Console | The indexed version, or a separate test of the live page | The indexed version and the live test are two different observations |
I base the split on Search Console Help on Rich Results Test and on Search Console Help on the URL Inspection tool, which separates the indexed version from the live one. Schema Markup Validator takes your URL or pasted code, reads all three formats, merges the markup it finds and can extract data added by JavaScript. External @context URLs need a full JSON-LD processor, and for a supported Google feature you'll need Google Rich Results Test. Save each result with your URL and date, plus the test mode (code or URL).
Test region in the EEA: record it next to the date and URL
The same valid markup behaves differently from country to country. That matters most if your users are in the European Economic Area (the EU plus Iceland, Liechtenstein and Norway).
On 8 September 2026 Google published documentation on regional differences in Search, also logged in its documentation changelog. For the EEA it describes, among other things, regional aggregator and supplier units and some structured data carousels.
Google's general structured data guidelines say correct markup enables a feature but doesn't guarantee it'll be shown. The decision can depend on factors such as location and device.
If your tool confirms eligibility and the SERP shows nothing, check the country and target market, the query type and the device. Then check whether the feature is currently available and what extra criteria it has. So I write the region down next to the date and the URL, and treat a missing presentation as a market question first and a schema error second.
How to check structured data in 6 steps
You go in the same order every time: your goal, then what the server sends, and finally what Google read.
Step 1: Pick a specific URL and the Google feature you expect
Record your URL, your page type and the goal of the check, which might be an article's author, a product's price or your navigation's BreadcrumbList. In Google's feature gallery, check that the presentation you expect exists and what it requires.
Pick edge cases for your sample that match your site's risk, because one correct page only tells you about itself. They might be a product without reviews, a promotion and an unavailable variant, an article with several authors, a language version, a missing optional value or data from an external provider.
Step 2: Compare the server response with the DOM after JavaScript
Check both views, because "View page source" shows the document response and the Elements panel shows the DOM after scripts have run. According to Google's guide to structured data generated with JavaScript, Google can read JSON-LD that's added dynamically. If a block is missing from the initial HTML response, inspect the rendered DOM and test the live URL to understand what Google can retrieve. For Product, the same documentation warns that dynamically generated markup can make Shopping crawls less frequent and less reliable, which is a risk when prices change quickly.
Keep your page's core description out of tabs and buttons, because Google Search reads the page without clicking around like a user (guide to fixing lazy-loaded content). When you test a URL, also check that the scripts and API responses your data comes from are reachable.
Step 3: Separate JSON syntax from Schema.org meaning
Paste only the contents of the block into a JSON parser, without the <script> tags. Fix trailing commas and unclosed brackets, remove comments and fix the quotation marks, because the syntax rules in RFC 8259 forbid them. If your tool accepts full HTML, use its HTML mode.
Check the @type values and property names as well. Artilce and hedline do not break JSON syntax, but they are not the correct Schema.org terms. Watch for repeated keys too. The JSON standard notes that software receiving such data behaves in different ways, while JSON-LD requires keys to be unique within an object. For the syntax alone, use the inspector below, which runs locally, so your data stays in your browser.
JSON-LD Inspector
Paste a JSON-LD block to check its syntax and the presence of basic fields locally. If JavaScript is turned off, use the Schema Markup Validator for the vocabulary and the SEO module of CometWeb Insight for a wider audit.
The inspector checks six things:
- whether the block is valid JSON;
- whether it has a Schema.org context;
- whether every object has a non-empty string
@type; - whether the entity has a URL;
- whether dates use the ISO 8601 format;
- only for the
Articlefamily: whether there's an author and a publication date.
The inspector doesn't check type and property names, because that takes a Schema.org vocabulary this tool doesn't carry. They get the status "Not checked", where a green "OK" used to be.
The inspector doesn't report repeated keys at all, because JSON.parse keeps only the last one. Check them with a duplicate-aware parser, as in the experiment below.
Not checking and finding no problem are two different things. That applies to my own tool too: it's still silent about duplicates. The slip from the intro was that the inspector flagged a missing author on a Product, where an author is irrelevant.
Today a contract test in the repository pins those cases, together with negative cases. If you're still writing the markup, the schema markup generator builds JSON-LD for 8 Schema.org types and flags the fields Google requires or recommends.
Step 4: Check the requirements of the right type and Google feature
Required fields depend on the Google feature. In Google's documentation for Article, every property is only recommended, so a missing author there is a different category from a syntax error.
Product snippets, on the other hand, have hard requirements. According to the product snippet documentation, Google requires name and at least one of review, aggregateRating or offers, and the object you pick brings its own requirements too. Merchant listings have requirements of their own, so check them separately.
For BreadcrumbList, the breadcrumb documentation requires at least two ListItem elements with names and positions, and you can omit the item of the last one. The list should reflect a sensible navigation path, without a mechanical split of every URL segment.
Step 5: Compare the data with the page content and the state of the offer
Compare every field that describes your content with the visible page: title, author, dates, price with currency, availability, reviews. The description has to be about your page and stay current. Whether the offer exists, and whether the price belongs to the right variant, is your call, because the test only sees the markup.
Here's a price in an offer object (only a fragment of the model; complete product markup has more fields):
{
"@type": "Offer",
"price": "129.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}On a page for a continental European market the price may show as "129,00 €". In your data you use a full stop as the decimal separator and put the currency in its own property.
According to the Schema.org definition of price, both the string "129.00" and the number 129.00 can be correct, so you can leave the quotation marks alone.
Matching is about the data: your visitors don't need to see a technical identifier like @id. Subscription content has its own markup rules, so on a paywalled site "everything visible to everyone" is too simple a rule.
Step 6: Test the code, then the full URL after publishing
Pasted code is handy while you work on a template, but after deployment, test the full URL, because only that shows what your server actually sends. For JavaScript-based implementations Google recommends URL input, because code mode has extra limitations, for example around CORS.
Then, in Search Console, compare the inspection of the indexed version with the live test. Note the date of the last crawl and the result of the page fetch. The live test tells you about the current version, but only the indexed version shows whether Google has processed your fix.
When the code test and the page test disagree, write down which layer from the table you're looking at. On its own, "The validator found no schema" is an incomplete diagnosis.
A JSON-LD article example with an author, @graph and @id
This is a fictional teaching example: everything in it, from the example.org URLs to the dates, is made up. Swap in real data and check eligibility on your own page.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://example.org/guide#webpage",
"url": "https://example.org/guide",
"name": "How to check structured data",
"inLanguage": "en"
},
{
"@type": "BlogPosting",
"@id": "https://example.org/guide#article",
"headline": "How to check structured data",
"mainEntityOfPage": {
"@id": "https://example.org/guide#webpage"
},
"author": {
"@id": "https://example.org/author#person"
},
"datePublished": "2026-09-01T10:00:00+02:00",
"dateModified": "2026-09-03T12:30:00+02:00",
"inLanguage": "en"
},
{
"@type": "Person",
"@id": "https://example.org/author#person",
"name": "Test Person",
"url": "https://example.org/author"
}
]
}@graph groups the descriptions, and @id lets you refer to an object without repeating its data. A bare reference such as {"@id":"https://example.org/author#person"} can do without an @type. Several JSON-LD blocks on one page are fine, as long as descriptions of the same object don't contradict each other.
@id and the canonical URL are separate mechanisms. The #article fragment identifies the article as an object, while rel="canonical" is a page-level signal, described in Google's canonicalization documentation. After a migration, check both, plus the redirects and the URLs used in relationships. I show how to line up the indexing signals in the guide to canonical, sitemap and robots.txt.
In your real article, add a matching image too (I left it out here, because its URL would be fictional). Record multiple authors as an array of separate objects. Write dates in full ISO 8601, with a time and time zone as Google recommends, and keep them consistent with the date on your page. Move dateModified when the publication changes, because a daily deploy or an automatic template refresh is too little reason. The block goes in a script element with the type application/ld+json.
A JSON parser let 4 of 5 broken JSON-LD samples through
JSON.parse accepted 4 of 5 deliberately broken samples, and a parser that checks for repeated keys accepted 3 of 5. I ran six files (one control, five with a defect) through JSON.parse on Node.js 22.16.0 and through a Python parser that detects repeated keys. These are chosen teaching cases, with no claim to be a representative benchmark, and without Rich Results Test or Schema Markup Validator.
In the sample with a repeated title, JSON.parse kept the last value ("Drugi", Polish for "second", in the raw file). The earlier one vanished without an error. The experiment's methodology, with results and limits, is in the research pack (in Polish, with the raw results as JSON).
Schema validator errors and warnings: what to check for each
| Symptom | What to check | What to avoid |
|---|---|---|
| Parse error | The raw block, quotation marks, commas and encoding | Fixing only the example in the generator; check the export to HTML |
| Unknown type or property | The name in Schema.org and the context | Accepting every non-empty @type as valid |
| Missing field required by Google | The documentation for that specific feature | Applying article fields to a product or an organisation |
| Warning about a recommended field | Whether the field has a real value that fits the page | Filling every field with invented data |
| "No items detected" | Type support, rendering and the input URL | Assuming the page has no Schema.org data at all |
| Code passes, the URL doesn't | Deployment, cache, access to resources and the DOM state | Presenting a code-test result as the result for the page |
| Two prices or two dates | Plugin, theme, template, GTM and the data source | Adding a third block in the hope it overrides the others |
"Error" and "warning" mean whatever a particular tool's rule says. Google's quality guidelines reach further than critical technical errors: fake reviews, or a description of different content, may need a human judgement.
With ratings, check the review snippet rules. Say a business controls the reviews about itself and publishes them in LocalBusiness or Organization data. Its page isn't eligible for review snippet stars, and an embedded third-party widget changes nothing. Genuine product reviews follow their own rules.
FAQ, HowTo and the search box: which rich results Google retired
An older template can still send markup for features Google has already retired.
The FAQ date comes from Google's documentation changelog, and Google announced the HowTo retirement in its post on HowTo and FAQ changes. The search box date comes from the farewell to the sitelinks search box.
FAQPage still exists in Schema.org, and questions and answers can be a useful part of your page, like the ones at the bottom of this guide. Do not promise expandable Google results on the strength of this markup alone. Before I delete unsupported markup, I check whether other systems use it and whether it still describes real data.
Schema and AI Overviews and AI Mode citations: what the data shows
According to an Ahrefs study from May 2026, adding schema didn't increase citations for pages that AI was already citing.
Ahrefs tracked 1,885 pages that added JSON-LD between August 2025 and March 2026 and compared them with 4,000 matched control pages. Every page in the study already had more than 100 AI Overview citations in February 2025.
Schema types were counted together, and the authors can't pin the AI Overviews drop on the markup with confidence. For pages AI doesn't know yet, the question stays open.
Google's guide to optimizing for generative AI features says you need no special Schema.org markup for generative features. It also says structured data is still worth using for rich results, which keeps structured data part of ordinary SEO.
I focus on clear definitions with sources and visible tool limits, because they help readers judge a result. I don't promise anyone citations. A score like "AI-ready 100/100" with no published method and no real observations is a number with nothing behind it.
Fixing structured data: how to close the fix and keep it after updates
In your ticket, record the URL and page variant, the faulty object, the data source, the test result and the retest condition. For example: "the price of the selected variant in the HTML matches offers.price after the promotion changes; the test covers the published URL".
In WordPress or whatever CMS you use, find out which layer generates each description. If the theme and a plugin publish conflicting offers, fix the shared source. Revalidate representative templates after a CMS or template update, a URL migration, changes to product fields and changes to the FAQ component.
Record publication blockers separately from recommendations, with "not checked" as a third category. After deployment, go back to URL Inspection and the page indexing report in Search Console. A change in clicks after publishing can come from other changes to your page or to queries, or from seasonality, so credit validation with part of the result at most.
Two blank templates (in Polish) help with the work: the validation and retest card and the template conflict check. The technical SEO audit checklist covers the surrounding crawl and indexing checks.
Got too many URLs to check by hand? The SEO module in CometWeb Insight, our website audit app, scores structured data as its own pillar on a 0–100 scale, next to meta and readability. In a project audit it does that across many crawled pages, so you can see which area drags your score down. It's also the fallback if the inspector above fails to load, although eligibility for a Google result is still Rich Results Test's call. Create a free account and run your first audit.
Three takeaways
- A green result answers its own layer's question, so a parser catches syntax in seconds, but whether the data is true and what Google read is yours to check.
- After deployment, test the published URL and record the region, because a missing SERP presentation can be about the market.
- Schema stays part of ordinary SEO, because in the Ahrefs study it didn't add citations for pages AI was already citing.
Tomorrow morning, run the URL of one of your product pages through both tools and compare the price in the JSON-LD with the price on the page.
Frequently asked questions
Do I have to clear every validator warning?
Clear a warning when the missing field has a real value. Check the rule and what the field means, and add a recommended property when it fits the page. Don't create an author, reviews or a price only to get a green status.
Does structured data validation guarantee indexing, a rich result or a higher position?
Validation confirms technical correctness, while Google decides on indexing, presentation and position. Rich Results Test doesn't settle every quality guideline. Structured data can help search engines interpret content and make some result presentations possible, but it doesn't replace quality, accessibility, internal linking or correct indexing.
Does schema have to be in the head?
JSON-LD can sit in the head or the body: Google accepts both, including JSON-LD generated by JavaScript. Access to the data and a correct implementation matter more than the section of the document.
Will a schema validator catch a wrong canonical?
A schema validator checks structured data, while the canonical is a separate HTML and indexing signal, so it usually won't catch it. Check the canonical in the page code, the sitemap, the redirects and URL Inspection in Search Console, especially after a URL migration.
Can I use several Schema.org types on one page?
Yes, several Schema.org types on one page are fine if each type describes a real element of the page and the relationships between objects are consistent. Don't add types only because they might produce an extra result. Surplus or contradictory blocks make interpretation harder.
What is the difference between Organization and LocalBusiness?
Organization describes an organisation or brand without requiring a local service address, while LocalBusiness is for a business operating at a specific location. Choose the type that matches the real business and the visible data, whatever result you hope to get in Google.
Sources and scope
My own experiment ran on 17 September 2026 and covers JSON parsers only. It doesn't test all of Schema.org, Google's services or the production CometWeb site. Check the current rules for Google features again before you deploy.
- W3C: JSON-LD 1.1.
- Google Search Central: General structured data guidelines.
- Google Search Central: Generate structured data with JavaScript.
- Google Search Central: Article structured data.
- Google Search Central: Product snippet structured data.
- Google Search Central: Breadcrumb structured data.
- Google Search Central: Latest documentation updates.
- Google Search Central: Changes to HowTo and FAQ rich results.
- Google Search Central: Farewell, Sitelinks Search Box.
- IETF / RFC Editor: RFC 8259, section 4.
- Google Search Central: Regional differences in Search experience.
- Ahrefs: We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved. (Louise Linehan, 11 May 2026).