What is publication verification in an online store?

Here, to verify does not mean proving to Google that the domain is yours, the step that registers a property in Search Console, nor checking the facts in a text the way a journalist would. It is a different question, a more prosaic one: what you saved in your store's admin, is it on the page your customers, Google and AI assistants see? A price, a meta description or a block of structured data that stays in the database and never reaches the HTML does not exist for anyone outside. And the admin will not warn you: it keeps showing the saved value even if the published page says something else or says nothing.

How it works

Between the saved data and the public page there is a chain, and verification means reading the end of that chain, not the start. The data lives in the platform's database; a template or an extension inserts it into the HTML; the server sends that HTML, sometimes through a cache; and the browser or the web crawler runs the JavaScript and gets the final page. At every link the data can be lost along the way, and the platforms themselves document several of those points.

The template does not show what it does not know about. In Shopify, metafields do not show up on their own in the store: they have to be connected to theme sections or blocks from the editor, if the theme supports it, or referenced with Liquid code in the templates.⁠^{[1]Shopify Help Center. Displaying metafields on your online store} A metafield with a perfect value and no connection to the theme is saved data that is never published.

An installed extension is not an active extension. Shopify's app embed blocks, the route Shopify gives apps to add code to the head or the end of the page, are turned off by default when the app is installed. They are turned on in the theme editor, under Theme settings, in the app embeds section, and then Shopify injects them before the closing </head> or </body>.⁠^{[2]Shopify.dev. Configure theme app extensions} Until that step, the app can have all the data saved and the page can carry none of it. The entry on the Shopify app embed explains it in more detail.

JavaScript changes what you have to read. If a piece of data is inserted with JavaScript, it is not in the HTML the server sends but in the HTML that results from running it. Google renders the page and uses that rendered HTML to index it, but it can skip rendering if the page does not respond with a 200 status code or if it finds a noindex in the original HTML.⁠^{[3]Google Search Central. Understand JavaScript SEO basics} And for product markup it warns of something more specific: generating product markup with JavaScript can make Shopping crawls less frequent and less reliable, a problem for data that changes fast, like price and availability.⁠^{[4]Google Search Central. Merchant listing (Product, Offer) structured data}

Validating is not verifying. A validator checks that the code is well written; verification checks that the code is on your page. Google's rich results have their own validator: the Rich Results Test accepts a URL or a pasted code snippet, and only the first option looks at your published page.⁠^{[5]Search Console Help. Rich Results Test} Even so, a passed test validates the syntax of the rich result types Google supports, not that the page gets indexed or that the rich result ends up showing.⁠^{[5]Search Console Help. Rich Results Test} And Google asks for something no validator can check for you: that the markup describe content visible to the person reading the page and represent its main content.⁠^{[6]Google Search Central. General structured data guidelines}

Verification makes sense because search engines already compare what you tell them with what you publish, and you pay for the result of that comparison. Google Merchant Center checks the availability in your product data against that of the landing page, which it crawls, and when they do not match it can send warnings to the account or preemptively reject products. Among the causes it lists are outdated or contradictory structured data markup and inconsistencies between the landing page, the checkout process and the markup.⁠^{[7]Google Merchant Center Help. Inaccurate availability status due to inconsistency between feed and landing page}

In a store

A merchant changes four fields of a product page in the admin, saves them and publishes. An hour later they read the public page and compare. It is a fictional example: the values are made up to show how a verification is recorded, field by field.

Each row that differs has a different cause, and the table does not say which: it only says where to look. The old description usually points to a template that reads another field or to a cache; the JSON-LD price that does not match the visible one, to markup handwritten in the theme that nobody updates; the questions that do not appear, to an extension that has not been turned on. What matters is the format: three possible results per field (matches, differs, not present) and the date and time of the reading, because a verification with no date says nothing about tomorrow.

How to check it

1. Write down the exact value you saved, field by field, and the time you published. Without the reference value there is nothing to compare.
2. Open the public page in a private window and look for the value in the page source, the HTML as the server sends it. If it is not there, look in the browser's inspector, which shows the page after running the JavaScript: if it only shows up in the second, the data depends on rendering.
3. Look at the page as Google sees it. In Search Console, "Test live URL" and then "View tested page" give you the screenshot of the rendered page, the HTML and the HTTP headers Google got.⁠^{[8]Search Console Help. URL Inspection tool} Look for the same values there.
4. Test the URL, not the code, in the Rich Results Test to see which structured data Google detects on the published page.⁠^{[5]Search Console Help. Rich Results Test} Compare each value with what you saved, not just that there are no errors.
5. Repeat the reading after every change in the store: a new theme, a new app or a price edited in another system can undo what was fine yesterday. If you sell on Google Shopping, also check the Merchant Center diagnostics, which warn when the page and the product data do not match.⁠^{[7]Google Merchant Center Help. Inaccurate availability status due to inconsistency between feed and landing page} Some tools automate this reading; Clione, for example, reads the published product page on BigCommerce and Shopify and reports, signal by signal, what was rendered against what was sent.

Related concept: data drift

Verification answers "did it arrive?" at a specific moment. Data drift is what happens afterward: a value that was published correctly and stops being so because something changes it, such as a product management system that rewrites the field (what is called field overwrite), a theme update or an app that gets uninstalled. One is done when you publish; the other is watched by repeating the verification over time. And both are different from validating markup, which checks the code without looking at the page: the comparison validate markup vs verify publication puts them side by side.

To keep going, the measurement and verification reading path puts the other terms in order, and the guides from the metafield to the published page and from the widget to the published page follow the route of a piece of data on Shopify and on BigCommerce.