What's the difference between validating markup and verifying it's published?

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, or why doesn't it do what you expected? These are two different checks on a store's 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.⁠^{[5]Google Search Central. Introduction to structured data markup in Google Search}

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 vocabulary, what the industry calls schema markup. The tool that checks it is the 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.⁠^{[6]Google Search Central Blog (December 15, 2020, updated in 2021). An update on the Structured Data Testing Tool} 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.⁠^{[7]Schema.org. Data model}

The second is Google's own requirements, the ones that decide whether a page qualifies for rich results. The tool that checks them is the Rich Results Test, which Google presents as its official tool for seeing which rich results a page's structured data can generate.⁠^{[2]Google Search Central. Schema Markup Testing Tool} One example of those rules: for a product page to qualify for merchant listings, Google requires a name, an image and an Offer with a price above zero and its currency.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}

Verifying means checking the page, not the code. 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.⁠^{[4]Google Search Central. General structured data guidelines} For its AI features it sums it up in one line: structured data should match the visible text on the page.⁠^{[9]Google Search Central. AI features and your website}

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.⁠^{[1]Search Console Help. Rich Results Test} 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 blocks it or the page isn't public, it can't be tested.⁠^{[1]Search Console Help. Rich Results Test} If your markup is generated with JavaScript, Google recommends testing the URL rather than the code, because code mode has limitations with JavaScript.⁠^{[10]Google Search Central. Generate structured data with JavaScript}

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.⁠^{[4]Google Search Central. General structured data guidelines}

The tool that comes closest to verification is URL Inspection in 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.⁠^{[3]Search Console Help. URL Inspection tool} 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.⁠^{[3]Search Console Help. URL Inspection tool}

Where valid markup gets lost

A 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 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.⁠^{[11]Shopify.dev. Configure theme app extensions}
• JavaScript. Google processes the structured data that's in the DOM when it renders the page,⁠^{[10]Google Search Central. Generate structured data with JavaScript} and it uses the rendered HTML to index the page, but it may skip JavaScript rendering if the page doesn't return a 200 status code or if the original HTML carries a noindex. Since not every bot runs JavaScript, Google still recommends server-side rendering or prerendering.⁠^{[12]Google Search Central. Understand JavaScript SEO basics}
• 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.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}
• Access. Google asks you not to block pages with structured data from Googlebot, whether with robots.txt, noindex or any other access control.⁠^{[4]Google Search Central. General structured data guidelines}
• Caching and outdated markup. 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.⁠^{[13]Google Merchant Center Help. Inaccurate availability status due to inconsistency between feed and landing page}

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.⁠^{[4]Google Search Central. General structured data guidelines} 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.⁠^{[13]Google Merchant Center Help. Inaccurate availability status due to inconsistency between feed and landing page}

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,⁠^{[14]Search Console Help. Rich result report overview} and a product page whose markup has no image doesn't qualify for merchant listings even if the photo shows on the page.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data} 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.⁠^{[14]Search Console Help. Rich result report overview}

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.⁠^{[5]Google Search Central. Introduction to structured data markup in Google Search} 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.⁠^{[8]Google Search Central. Merchant listing (Product, Offer) structured data}

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.⁠^{[2]Google Search Central. Schema Markup Testing Tool}
2. Publish, then test the URL, not the code, so the test reads what your store serves.⁠^{[10]Google Search Central. Generate structured data with JavaScript}
3. Compare the values by hand. Open the published page, find the markup's name, 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.⁠^{[4]Google Search Central. General structured data guidelines}
4. Look at the page the way Google does, with the live test in URL Inspection.⁠^{[3]Search Console Help. URL Inspection tool}
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.

To do it on a specific product page, the guide to auditing a product page's 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 puts the terms in this comparison in order, along with the ones behind them.