# Validating structured data vs verifying it's published

> Validating vs verifying structured data: what each one checks, with which tool, and why valid JSON-LD can still be missing from your product page.

URL: https://clione.ai/comparisons/validate-vs-verify/
Lang: en

| Criterion         | Validating the markup                                                  | Verifying publication                                                      |
| ----------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| The question      | Is it well formed, and does it follow the rules?                       | Is it on the published page, and does it say the same thing as the page?   |
| What it reads     | The code you give it, or a URL's code at that moment[^rrt-help]        | The page your store serves, compared with what you saved                   |
| With what         | A vocabulary validator and Google's test[^google-test-sd]              | The source code, the rendered page and URL Inspection[^gsc-url-inspection] |
| What it finds     | Syntax and vocabulary errors, and missing required properties          | A value that is missing, different, or doesn't match what's on screen      |
| What it can't see | Whether the markup describes what the reader sees[^google-sd-policies] | Whether the markup is well formed: that's validating                       |
| When              | Before publishing, and with every template change                      | After publishing, and with every change in the store                       |
| The result        | Valid, valid with warnings, or invalid                                 | Matches, differs, or missing                                               |

If you landed here looking for the difference between validating and verifying, you probably have a green test result and a doubt: if the markup is valid, why don't you see it on your [product page](/glossary/product-page/), or why doesn't it do what you expected? These are two different checks on a store's [structured data](/glossary/structured-data/). **Validating asks whether the code is well formed; verifying asks whether that code is actually on the page your store serves**, and whether it says the same thing the page does. Google itself lines them up in its documentation: test the markup during development, and monitor the pages after they're published.[^google-sd-intro]

## The question each one answers

**Validating means checking the code against a set of rules**, and there are two sets, with a tool for each.

The first is the [Schema.org](/glossary/schema-org/) vocabulary, what the industry calls [schema markup](/glossary/schema-markup/). The tool that checks it is the [Schema Markup Validator](/glossary/schema-markup-validator/). When Google moved that tool to a domain serving the Schema.org community, it said its main purpose would be checking the syntax of the markup and whether it conforms to Schema.org standards, and that it would stop checking Google Search rich result types.[^sdtt-update] Worth knowing: Schema.org is deliberately flexible, so validators may warn about ambiguous data but aren't obliged to treat an unexpected structure as an error.[^schemaorg-datamodel]

The second is Google's own requirements, the ones that decide whether a page qualifies for [rich results](/glossary/rich-results/). The tool that checks them is the [Rich Results Test](/glossary/rich-results-test/), which Google presents as its official tool for seeing which rich results a page's structured data can generate.[^google-test-sd] One example of those rules: for a product page to qualify for [merchant listings](/glossary/merchant-listings/), Google requires a name, an image and an [Offer](/glossary/offer-schema/) with a price above zero and its currency.[^google-merchant-listing]

**Verifying means checking the page, not the code.** [Publication verification](/glossary/publication-verification/) reads the page your store serves and compares what it finds with what you saved: the value is there, it's different, or it's missing. It also asks a question no validation tool answers: whether the markup says the same thing as the page. Google asks you not to mark up content that readers can't see, and wants the markup to be a true representation of the page content. It also warns that **these quality guidelines aren't easily testable with an automated tool**.[^google-sd-policies] For its AI features it sums it up in one line: structured data should match the visible text on the page.[^google-ai-features]

## What each one reads: the code or the page

The confusion starts here, because validation tools also accept a URL. The Rich Results Test takes two kinds of input: a URL, or a code snippet you paste.[^rrt-help] With the snippet, it validates exactly what you pasted, and that may not be what your store serves. With the URL, it visits the page as Google-InspectionTool, not logged in, and shows the rendered code; if [`robots.txt`](/glossary/robots-txt/) blocks it or the page isn't public, it can't be tested.[^rrt-help] If your markup is generated with JavaScript, Google recommends testing the URL rather than the code, because code mode has limitations with JavaScript.[^google-js-sd]

Testing the URL gets close to verifying: it confirms that the published page carries markup and that Google can read it. What it doesn't tell you is whether the values are the ones you saved, or whether they match what the shopper sees. A price in the markup that differs from the one on the product page isn't a syntax error, and Google notes that its tools catch most technical errors, not quality ones.[^google-sd-policies]

The tool that comes closest to verification is URL Inspection in [Search Console](/glossary/google-search-console/). It tells two versions of your page apart: **the indexed version, which is the last one Google crawled and not today's**, and the live test, which can differ from the indexed version if you've changed something since. "View tested page" shows a screenshot of the rendered page, its HTML and its HTTP headers.[^gsc-url-inspection] It has two limits: it only works on URLs in a property you own, and a passing live test doesn't guarantee the page will appear in search results.[^gsc-url-inspection]

## Where valid markup gets lost

A [JSON-LD](/glossary/json-ld/) block can pass both validations and never reach the product page. Between the code and the published page there's a chain, and **the platforms themselves document each link in it**:

- **An extension that isn't turned on.** [Shopify app embed](/glossary/shopify-app-embed/) blocks are off by default when the app is installed. You turn them on in the theme editor, under Theme settings, and only then are they injected before the closing `</head>` or `</body>` tag.[^shopify-app-embeds]
- **JavaScript.** Google processes the structured data that's in the DOM when it renders the page,[^google-js-sd] and it uses the rendered HTML to index the page, but it may skip [JavaScript rendering](/glossary/javascript-rendering/) if the page doesn't return a 200 status code or if the original HTML carries a `noindex`. Since not every [bot](/glossary/web-crawler/) runs JavaScript, Google still recommends [server-side rendering](/glossary/server-side-rendering/) or prerendering.[^google-js-seo]
- **Product markup generated with JavaScript.** Google warns that dynamically generated markup can make Shopping crawls less frequent and less reliable, a problem for fast-changing data like availability and price, and recommends putting it in the initial HTML.[^google-merchant-listing]
- **Access.** Google asks you not to block pages with structured data from [Googlebot](/glossary/googlebot/), whether with `robots.txt`, `noindex` or any other access control.[^google-sd-policies]
- **Caching and outdated markup.** [Google Merchant Center](/glossary/google-merchant-center/) lists outdated markup, conflicting information on the site and caching delays among the reasons a product's availability may not match its page.[^mc-availability-mismatch]

In none of these cases does code validation fail. Publication fails, and only someone who reads the page sees it.

## What happens if you only do one

**Only validating.** You're left with correct code and no certainty about the store. Google puts it in writing: it doesn't guarantee your structured data will show up in search results, even if the page is marked up correctly according to the Rich Results Test.[^google-sd-policies] And someone else is comparing on their own: Merchant Center checks the availability in your product data against the landing page, and when they don't match it can send warnings to the account or disapprove products preemptively.[^mc-availability-mismatch]

**Only verifying.** You know the markup is on the page, but not whether it works. Search Console calls an item invalid when it has at least one critical issue,[^gsc-rich-reports] and a product page whose markup has no image doesn't qualify for merchant listings even if the photo shows on the page.[^google-merchant-listing] Validation catches that; reading the page doesn't.

Search Console's rich result reports seem to cover both, because they read your site after crawling it. Not quite: **they show a sample of the detected items, not the full list**, and for a page that doesn't appear there, Google points you to URL Inspection.[^gsc-rich-reports]


**A green test on pasted code doesn't mean your product page carries that markup.** In snippet mode, the test validates what you pasted, not what your store serves.[^rrt-help] It works the other way too: seeing the block in the product page's source code doesn't mean it's valid, or that its values match the page. They're two questions, and each tool answers its own.


## The order Google gives

Google sets out the order in its introduction to structured data: check the markup with the Rich Results Test during development, and with the rich result status reports after publishing, because **pages can break after they're published, through templating or serving issues**.[^google-sd-intro] Its merchant listing documentation makes the sequence concrete: validate with the test, publish a few pages first, use URL Inspection to see how Google sees them, and check that neither `robots.txt`, a `noindex` nor a login is blocking Google.[^google-merchant-listing]

In a store, that becomes:

1. **Validate before publishing**, with the Schema Markup Validator for the vocabulary and the Rich Results Test for Google's requirements.[^google-test-sd]
2. **Publish, then test the URL, not the code**, so the test reads what your store serves.[^google-js-sd]
3. **Compare the values by hand.** Open the published page, find the markup's name, [price and availability](/glossary/price-and-availability/) in the HTML, and compare them with what the product page shows and with what you saved. No automated tool makes that comparison for you.[^google-sd-policies]
4. **Look at the page the way Google does**, with the live test in URL Inspection.[^gsc-url-inspection]
5. **Repeat the verification** after every theme, app or price change. What drifts over time without anyone touching the product page has a name of its own: [data drift](/glossary/data-drift/).

To do it on a specific product page, the guide to [auditing a product page's structured data](/guides/audit-product-page-structured-data/) walks through it step by step.

## Pick where to start

You don't choose between validating and verifying. You choose the one you're missing.

- **Validate first** if you're about to change the product template, install an app that writes markup, or write it by hand. A syntax error gets fixed before it reaches any product page.
- **Verify first** if the markup is already published and something doesn't add up: the test comes back green and Google doesn't show the rich result, Merchant Center flags differences between your data and the page, or the price in the markup isn't the one on the product page.
- **Do both** every time you change something that touches the product page.

Verifying one product page by hand is manageable; verifying a whole catalog, every time something changes, is a different job. Some tools do that reading for you. Clione, for example, reads the published product page, reports signal by signal what rendered against what was sent, checks it again on a regular cadence and alerts you when a verified signal disappears from the page.

To keep going, the [measurement and verification reading path](/learn/measurement-and-verification/) puts the terms in this comparison in order, along with the ones behind them.