Skip to main content

Verify signals on your storefront

Plans: Growth · Pro · Agency (Starter has read-only access to results from automatic background verifications)

After Clione enriches an entity and propagates the signals to your store, you want to confirm that the signals actually landed where they should. The Verification page is the in-dashboard tool for that.

Verification answers questions like:

  • Did the new meta description make it to the live product page?
  • Is the JSON-LD I see in the dashboard the same as what's in the page source?
  • Did Shopify accept the canonical URL change, or did it silently drop it?

Where it lives​

For each store, open the store from the sidebar, then click Verification (plan-gated; available on Growth and above).

The page shows:

  • A filter bar — pick entity types (products / categories / collections / pages), a score band (Pass / Warn / Fail), and which stores to include (if you're a multi-store tenant).
  • A table of recent verification runs with one row per entity.
  • A row click opens the detail modal: which signals were checked, which passed, which mismatched, and the raw values from both DB and storefront.

There's also a global URL Verifier (sidebar → URL Verifier) for one-off URL checks without an entity ID — covered separately in URL Verifier.

What "verification" actually checks​

For each entity, Clione fetches the live storefront HTML and compares against the enriched values stored in the database:

SignalWhat it checks
Meta title<title> tag matches the enriched meta_title.
Meta description<meta name="description"> matches the enriched description (truncation-aware on Shopify — see Connect Shopify).
Canonical URL<link rel="canonical"> matches the canonical the platform should return.
JSON-LDA <script type="application/ld+json"> block exists with the expected @type (Product, FAQPage, etc.) and the keywords + ID match.
OG tagsog:title, og:description, og:image are present and match (products only — categories/pages don't get OG on most platforms).
meta_keywords (BC only)The <meta name="keywords"> exists with the expected list (BC keeps this signal alive even though most search engines ignore it).

Each check is graded:

  • Pass — DB value matches what's on the page.
  • Warn — Field is present but partially mismatched (e.g. description truncated, or extra keywords appended).
  • Fail — Field missing or completely different.

The overall row grade is the worst of the per-signal grades.

Per-platform notes​

BigCommerce​

  • Verification needs to fetch your live storefront. If the storefront is password-protected (sandbox stores), pass a preview code.
    1. Open the failing entity in Verification.
    2. The detail modal shows a banner: "Storefront unreachable — looks like a password-protected store".
    3. Paste the preview code from BC admin (Settings → Storefront → Sandbox) and click Retry verification.
    4. Clione passes ?preview_code=... on the fetch and the page returns normally.
  • JSON-LD only verifies if the Schema Injector is installed. Without it, Clione marks JSON-LD as "Not installed" (not Fail) so you know it's a configuration issue, not a data issue.
  • Categories and Pages: Clione verifies title + description + meta_keywords + search_keywords. JSON-LD is not yet rendered on non-product entities, so it's not checked.

Shopify​

  • Verification fetches https://<your-shop>.myshopify.com/products/<handle> (or the configured custom domain if you set one under Store → Settings).
  • If you use a custom domain (shop.example.com), make sure it's set under Store → Settings → Storefront URL. Otherwise verification uses the .myshopify.com URL and may report mismatches if your theme renders differently on the two.
  • JSON-LD only verifies if the theme app block is enabled. Otherwise the metafield has the JSON-LD but the storefront never renders it — Clione marks JSON-LD as "Not rendered" (theme app block off).
  • Meta description truncation at 255 chars is a known platform limit. If your enriched description is 320 chars and the storefront shows 255, verification flags this as Warn, not Fail, because the truncation is expected.

Running a verification​

Verifications are automatic in the background after every propagation, but you can also trigger them on demand:

One entity​

  1. Open the entity (product / category / collection / page).
  2. Click the Verification tab.
  3. Click Run verification now.
  4. The result appears in the tab a few seconds later.

Many entities​

  1. Open the store's Verification page.
  2. Filter to the rows you want to re-check (e.g. by store, by score band, by entity type).
  3. Click Verify selected in the bulk bar.
  4. Track progress via the chip in the top bar.

Reading the detail modal​

Click any row to open the detail modal:

  • Summary panel — overall grade + per-signal grades.
  • Signal table — for each signal: the value in the database, the value on the storefront, and the diff highlighted character-by-character if they don't match.
  • Live URL — link to open the storefront page in a new tab.
  • Last run — timestamp of the most recent verification.
  • Re-push from DB — manually re-propagate the DB values to the storefront. Useful when verification flags a Fail caused by a propagation that quietly failed (e.g. transient 5xx from the platform API).

When verification reports "Fail" — diagnostic order​

  1. Has the entity been enriched at all? Open the entity → check the Enrichment tab. If empty, enrich first.
  2. Has the enrichment been propagated? Open the Propagation tab. The last propagation should show a green "Pushed" status. If it shows red, click Re-push to storefront.
  3. Is the storefront reachable? Try the live URL in incognito. If you see a password page, set a preview code (BC) or remove the password protection (Shopify).
  4. Is the Schema Injector (BC) / theme app block (Shopify) installed? Without it, JSON-LD will Fail even though the DB and propagation are healthy. See Schema Injector.
  5. Is your CDN cache holding the old version? Wait 5 minutes and re-run verification. For Shopify, CDN TTL is short (~60s). For BC, it depends on your theme's cache headers.
  6. Did the platform silently drop the field? Each platform has writability quirks (Shopify rejects descriptions > 255 chars on metafields, BC rejects malformed custom_url, etc.). The propagation tab shows the raw response from the platform — if it returned 200 OK but the field is empty, the field was rejected. Re-enrich with a shorter description or fix the source data.

Per-entity-type checks​

Not every entity type produces every signal. The table below shows what's checked per entity type per platform.

Entity typeTitleMeta descCanonicalJSON-LDOGmeta_keywords (BC)
Product (BC)✓✓✓✓✓✓
Product (Shopify)✓✓✓✓✓—
Category (BC)✓✓✓——✓
Collection (Shopify)✓✓✓———
Page (BC)✓✓✓——✓
Page (Shopify)✓✓✓———

JSON-LD on categories / collections / pages is on the roadmap but not yet generated.

Per-store thresholds​

Verification grades each entity row, but the store-level rollup applies thresholds:

  • Green storefront badge — at least 90% of verified entities are Pass.
  • Amber — 70-89% are Pass.
  • Red — below 70% Pass.

The badge appears on the Store Overview card so you can see at a glance which stores are healthy. Hover the badge to see the exact pass rate and a link to the failed rows.

Scheduling​

Background verifications run automatically on the following triggers:

  • 30 seconds after every enrichment + propagation cycle (per entity).
  • Once per day at 03:00 UTC for every store, as a baseline drift check.
  • On-demand from the Run verification now button.

If you want continuous polling (e.g. every hour), this isn't currently configurable — open a feature request via support.

Troubleshooting​

"Storefront unreachable" on a public store — DNS, firewall or geo-block. Try the live URL in incognito. If it loads for you, check whether your storefront blocks our datacenter IP — contact support to whitelist if needed.

Verification flags Pass but the storefront still shows the old description — Storefront CDN cache. Force-refresh (Ctrl/Cmd + Shift + R) or wait for the cache to expire. Verification fetches with cache-busting, so what Clione sees is the canonical origin response.

Same entity verifies Pass on one URL and Fail on the variant URL — Some themes vary meta tags per variant. Clione verifies the canonical product URL only. If you need variant-level verification, that's not supported today.

BigCommerce categories flagged Fail for canonical URL — BC categories don't always emit a canonical link in the head section by default. The Stencil theme controls this. Edit templates/pages/category.html and add {{> components/common/canonical}} to the head block. If you can't edit the theme, this signal will stay Warn (not Fail) — it doesn't block the rest.

Shopify storefront URL pointing to wrong location after Markets enabled — When you enable Shopify Markets with country-specific domains (e.g. de.example.com for Germany), the canonical URL emitted on each Market may differ. Set the Storefront URL under Store → Settings to the primary Market's URL, and Clione will verify against that. Other Markets are not verified today.

"Not installed" status persists after I install the Schema Injector — Status is cached for 5 minutes. Wait or click Refresh on the Schema Injector card. If it persists past 10 minutes, open the storefront page and view source — search for <!-- clione:jsonld -->. If the comment is present, re-run verification on one entity to force a re-check.

Verification API​

For programmatic access:

  • GET /api/v1/verifications?store=:storeId&entityType=:type — list verifications for a store.
  • POST /api/v1/verifications/run — trigger a verification batch (returns a job ID).
  • GET /api/v1/verifications/:id — single verification result with full per-signal breakdown.

See the developers section for auth.

Export​

The verification table has an Export CSV button. Columns:

  • Entity ID + name
  • Entity type
  • Platform
  • Storefront URL
  • Per-signal pass/fail
  • DB value vs storefront value (truncated to 200 chars)
  • Overall grade
  • Last verified timestamp

Use this for offline audits or for handing to an SEO consultant.

What the verifier doesn't check​

To set expectations:

  • Image alt text — present on the entity but not in scope for Verification. Pulse does check this.
  • Page-speed metrics (LCP, FID, CLS) — not in scope. Use Google PageSpeed Insights.
  • Internal link structure — not in scope.
  • hreflang mismatch across locales — not in scope for v1.
  • sitemap.xml presence — not in scope.
  • robots.txt correctness — partial: the verifier flags if the page itself is robots-blocked but doesn't audit the full robots policy.
  • Schema validity per Google rules — Verification confirms the JSON-LD block exists and matches the DB; it does not run the JSON-LD through Google's validator. Use the Google Rich Results test for that.

These are gaps we know about. Some will be added (Pulse already covers most), others stay out-of-scope by design.

Best practices​

  • Run Verification after every major catalog change (new product line, theme update, locale switch).
  • Treat a sudden spike in Fails as a regression — usually a theme update changed how meta tags render.
  • Don't ignore Warns — they often degrade silently into Fails on the next sync.
  • Re-verify after Schema Injector install — the first round of verifications run before the script propagated to the BC Scripts API cache.