Verify signals on your storefront
Plans: Growth · Pro · Agency. Starter doesn't include Verification.
After you publish an entity, you want to know that its signals actually landed — and that they're still there next week. Verification re-reads your storefront and your platform and compares what it finds with what Clione published.
It answers questions like:
- Is the meta description I published still on the live page?
- Did a theme update remove the JSON-LD?
- Did a PIM or ERP sync overwrite the meta fields Clione wrote?
For a step-by-step walkthrough, see the Verify tutorial.
Where it lives
Open the store and click Verification in the store sidebar. The page shows:
- Four cards. Verification score, Drifted and Cadence each have a
?that explains them:- Verification score — the share of checked signals found intact, averaged over the latest check of each entity in the last 30 days. Green at 90 or above, amber from 50 to 89, red below 50.
- Entities checked — products, categories, collections and pages with published signals.
- Drifted — entities that lost a signal since their previous check.
- Cadence — how often your plan re-checks the store (Daily on Growth, Pro and Agency), and when it last did.
- Check history — one row per entity per check, newest first, for all four entity types. Filter by entity type, or tick Drift only. Each row shows the entity, its score (… of … signals), the signals that drifted, whether the check was Scheduled or Manual, and when it ran.
- Verify now (owners and admins) — checks the store right away. Progress shows in the bar at the bottom of the screen and the table refreshes when it finishes.
What gets checked
Only entities that have been published at least once are checked — a signal that was never published can't be missing.
- Products — Clione fetches the live product page and reads the signals back, plus a read-back through your platform's API.
- Categories, collections and pages — Clione reads the entity back through your platform's API.
- Headless storefronts — Clione fetches the page the way a crawler would and reads the signals from its HTML.
The signals checked are the ones Clione published for that entity: JSON-LD, meta title, meta description, keywords and FAQs, as they apply to each entity type and platform.
Reading a row
Click a row to see every signal that was checked, the URL that was read (Open checked URL), and each signal's status:
| Status | Meaning |
|---|---|
| OK | Found, and it matches what Clione published. |
| Missing | Nothing there, or the field is empty. |
| Changed | Something else is there instead. |
| Not checked | Clione couldn't read the platform this time. This is never counted as drift. |
Drift alerts
Clione re-checks your published entities on its own, on your plan's cadence (once a day). Each run checks up to 50 published entities per store: the most recently updated of each entity type.
Drift is the case this exists for: a signal that was OK on the previous check is now Missing or Changed. That's what a theme update, an uninstalled app or a PIM overwriting the meta fields looks like from the outside — and nothing else tells you.
When a check finds drift, the organization's owners get:
- a notification in the bell saying that published signals went missing on the store, naming the entities and signals, with a link to the store's Verification page;
- an email, according to their notification email settings.
To fix it, open the entity and publish the missing signal again from its Publish tab. If a PIM keeps overwriting the fields, exclude the meta fields from that sync.
Checking on demand
- One entity — open it, go to the Publish tab and click Verify.
- The whole store — Verification → Verify now.
Enriching never triggers a check: there's nothing to verify until you publish.
Per-platform notes
BigCommerce
- JSON-LD reaches your storefront through a BigCommerce Widget API placement per published entity, rendered server-side by Stencil. A missing JSON-LD on a published entity is a real finding — usually a theme change or a removed widget.
- If your storefront is password-protected (sandbox stores), enter your BigCommerce Preview Code on the product's Publish tab so Clione can read the page. The field appears there, on products only, after a Verify can't reach the storefront. To find the code: BigCommerce admin → Storefront → My Themes → Advanced on your active theme → copy the Preview Code.
Shopify
- JSON-LD on the storefront depends on the Clione SEO app embed of Clione's Shopify app being on in your live theme. If it's off, the data is in Shopify but the page doesn't render it. See Schema Injector — Shopify.
- If your storefront is password-protected, Clione can't read the live page. Remove the password under Online Store → Preferences.
When a signal is missing — diagnostic order
- Was the entity published? Open its Publish tab. If it was never published, publish it.
- Can the storefront be reached? Open the live URL in an incognito window. A password page means you need a preview code (BigCommerce) or to remove the password (Shopify).
- Is the storefront piece on? BigCommerce: the Schema Injector for the FAQ accordion. Shopify: the Clione SEO and Clione FAQ app embeds.
- Did something overwrite it? A Changed status after an OK usually means a PIM, ERP or another app wrote the field. Fix the source, then publish again.
- Is a cache holding the old page? Wait a few minutes and click Verify again.
What Verification doesn't check
Verification confirms that what Clione published is present and unchanged. It doesn't validate your structured data against Google's rules — use Google's Rich Results Test for that — and it doesn't measure page speed, internal links, sitemaps or robots.txt.
Best practices
- Click Verify now after a theme change, an app install or a PIM sync, to confirm nothing was lost.
- Treat a sudden drop in the score as a regression — it usually means a theme update or a sync changed how the fields are written.