# What is publication verification in an online store?

> What publication verification is: checking that what you save in your store's admin reaches the public page, field by field, and how to do it.

URL: https://clione.ai/glossary/publication-verification/
Lang: en

Here, to verify does not mean proving to Google that the domain is yours, the step that registers a property in [Search Console](/glossary/google-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](/glossary/meta-description/) or a block of [structured data](/glossary/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](/glossary/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](/glossary/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](/glossary/shopify-liquid/) code in the templates.[^shopify-metafields-display] 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](/glossary/shopify-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>`.[^shopify-app-embeds] 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](/glossary/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.[^google-js-seo] 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](/glossary/price-and-availability/).[^google-merchant-listing]

**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](/glossary/rich-results/) have their own validator: the [Rich Results Test](/glossary/rich-results-test/) accepts a URL or a pasted code snippet, and only the first option looks at your published page.[^gsc-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.[^gsc-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.[^google-sd-policies]

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](/glossary/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.[^mc-availability-mismatch]

## In a store

A merchant changes four fields of a [product page](/glossary/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.

| Field (fictional example)                  | Value saved in the admin                  | Value on the published page               | Result      |
| ------------------------------------------ | ----------------------------------------- | ----------------------------------------- | ----------- |
| [Page title](/glossary/meta-title/)        | Waterproof 20 L urban backpack            | Waterproof 20 L urban backpack            | Matches     |
| Meta description                           | 20-liter backpack with a padded sleeve... | Designer urban backpack. Free shipping... | Differs     |
| Price in the [JSON-LD](/glossary/json-ld/) | 89.00                                     | 79.00                                     | Differs     |
| FAQ on the page                            | Five questions                            | None                                      | Not present |

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.


**A green Rich Results Test does not say your page carries that markup.** If you paste the code in snippet mode, the test validates what you pasted, not what your store serves; and even testing the URL, it validates the syntax, not that the data is the one you saved or that Google will show it.[^gsc-rich-results-test] Verifying is opening the published page and looking for the value.


## 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.[^gsc-url-inspection] 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.[^gsc-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.[^mc-availability-mismatch] 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](/glossary/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](/glossary/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](/comparisons/validate-vs-verify/) puts them side by side.

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