Technical health & indexability

Audience: Merchant·Plan: starter·Read: 9 min·Updated: 2026-08-03

In 30 seconds

• Every page found by the crawler lands in exactly one of eight indexability buckets — indexable, noindex, canonicalised, blocked by robots, redirect, error, duplicate, or unknown.
• A crawl regression is a scored comparison between two crawls of the same site. It opens an incident with a severity level, an SLA clock, and a change timeline of what your store did in that window.
• Blast radius is measured in real clicks and revenue from Search Console, matched on the full URL path.
• The page tells you when it cannot be trusted: a crawl of the wrong hostname, a crawl older than seven days, or no Search Console run all raise a warning instead of quietly showing a number.
• Everything here comes from a crawl. No crawl, no data — and a crawl of the wrong host is worse than no crawl at all.

How to use it

1. Check the health banner first. If the page is warning you about the crawl (wrong host, stale, no Search Console run), fix that before reading anything else. Those warnings exist precisely because the numbers below them would otherwise look confident and be wrong.
2. Read the eight-bucket split. It answers one question: of the pages we can reach, how many can Google actually index?
3. Open a bucket to see the individual URLs, and why each landed there.
4. Work the regression incidents in severity order. Each one carries what changed in your store during the crawl window.
5. Re-crawl from this tab once you have made fixes — the trigger is on the page, you do not need to leave for the Crawler tab.

⏱ Continuous · 💳 Starter+ · 🎯 Find pages Google cannot index, before they cost you traffic

The eight indexability buckets

Every crawled URL is classified into exactly one bucket. The classification is derived from what the page itself declares — its status code, its robots meta, its canonical tag — not from a guess.

Bucket	What it means	Typical cause
Indexable	Google can crawl it and index it	Healthy
Noindex	The page tells Google not to index it	A robots meta tag or X-Robots-Tag header
Canonicalised	The page points at a different URL as the canonical version	Variant/filter URLs, or a theme that hard-codes one canonical
Blocked	robots.txt forbids crawling it	A disallow rule, often broader than intended
Redirect	The URL responds 3xx	Moved or normalised URLs
Error	4xx or 5xx	Deleted products, broken handles, upstream failures
Duplicate	Several URLs return byte-identical content	Collapsed into clusters by content hash
Unknown	We could not classify it	Truncated or failed fetch

Two details matter when you read this card:

• The counts are the real totals. The drill-down list is capped for readability, but the bucket counts and the share bar are computed over the whole crawl. A store with 504 canonicalised pages shows 504.
• The duplicate bucket is grouped, not listed. Duplicates are collapsed by content hash into clusters — "7 URLs share this body" — because a flat list of identical pages tells you nothing about which one to keep.

A crawl of the wrong hostname invalidates this whole page

If your store sells on a custom domain but the crawl ran against the .myshopify.com mirror, the mirror will be canonicalised to the custom domain on almost every page. The result reads as "503 of 504 pages canonicalised, 0 indexable" — which describes the mirror perfectly and your real store not at all.

The tab detects this by comparing the canonical host it found against the host it crawled, and raises a warning rather than rendering the number. If you see it, point the crawl at your live domain and re-run.

Crawl regressions

A regression is the scored difference between two crawls of the same site.

The diff keys pages on their full normalised URL, which makes host consistency load-bearing: comparing a custom-domain crawl against a mirror crawl reports the entire previous site as lost and the entire current site as new. The comparison therefore prefers a previous crawl of the same host, looking back through the last ten, and when it cannot find one the incident says so in a banner rather than presenting a phantom as a finding.

Each incident carries:

Field	What it tells you
Score	A weighted total across the change types — pages lost, status-code moves, canonical/robots changes, title and meta churn
Explanation	The per-signal breakdown that produces that score, so the number is reproducible rather than opaque
Level	critical · high · medium · low — drives the SLA clock
Blast radius	Clicks and revenue attached to the affected URLs over the recent Search Console window
Change timeline	What changed in your store during the crawl window
Recurrence	Whether this same incident shape has happened before, and how many times in a row

Blast radius is matched on the full path

Search Console reports performance per URL. Matching a crawl finding to that data on the product handle alone merges /products/winter-throw with /collections/winter-throw — so a 404'd collection would inherit a healthy product's clicks and look catastrophic. Matching is done on the full path, with handle matching kept only as a documented fallback. When the fallback was used, the incident drawer says so.

The change timeline

The most useful question about a regression is "what did we change?". The timeline joins everything the platform already records onto the crawl window:

• Bulk changesets (collapsed per batch, not one row per product)
• Crawl remediation actions applied from this suite
• Product SEO revisions
• Schema markup versions published
• robots.txt snapshots — but only when the hash actually moved. A snapshot is not a change, and a store with exactly one snapshot ever has no baseline to compare against, so no claim is made
• Sitemap rebuilds
• Curated audit-log actions

A source that fails to load is never rendered as "nothing changed." The panel reports "1 source could not be read" instead — the distinction between no changes and we could not look is the entire value of the panel.

Two categories are permanent blind spots and are listed as such: app installs, and edits made directly in Shopify admin rather than through this suite.

Beta · Requires re-consent

Theme change tracking

Theme publishes and edits to the live theme can be correlated into the timeline too, but this needs a permission your store may not have granted yet. The permission was added after many stores installed, and Shopify does not apply scope changes retroactively.

The blind-spot list reflects the real state, per store, in three forms:

State	What it means
Not granted	The theme permission has not been authorised — re-authorise the app to enable it
Granted, not delivering	The permission is granted but no theme events have arrived; correlation is still blind
Live	Theme publishes and live-theme edits appear in the timeline

The middle state exists deliberately. Telling a merchant who has just re-consented that theme changes are tracked, while nothing actually lands, would be a worse lie than the honest "not granted".

Note that edits to draft and development themes are filtered out — only the published theme is correlated, because a designer working in a dev theme is not a cause of a live regression.

Triage and SLA

Incidents get an SLA clock keyed to their level:

Level	Time to resolve
Critical	4 hours
High	24 hours
Medium	72 hours
Low	7 days
None	No clock

The clock arms on first touch, not on creation — an incident nobody has looked at yet is not "already breached". If an incident is picked up after its notional due date, the clock re-bases to now rather than opening in breach. Incidents with no owner still breach; there is no way to dodge the clock by not assigning it.

You can resolve or dismiss up to 50 incidents at once, snooze an incident, and group recurring incidents into a streak so that the same weekly false positive does not read as five separate emergencies.

Alerts and incidents round-trip: an alert about a regression links straight to the incident drawer, and resolving or dismissing the incident closes the linked alerts. Reopening it reopens them.

Running a crawl from this tab

The crawl trigger lives on the page. It goes through the same rate limiting and SSRF protection as the Crawler tab, and while a crawl is in flight the tab refreshes itself every 20 seconds — pausing when the browser tab is in the background, so an open tab overnight does not poll for hours.

Crawl schedules are still configured on the Crawler tab; this tab triggers a one-off run.

When the numbers are not trustworthy

The tab surfaces its own limits rather than hiding them:

Warning	What it means	What to do
Wrong-host crawl	The crawl ran against a different hostname than your canonical domain	Re-crawl your live domain
Crawl is stale	The most recent crawl is more than seven days old	Re-crawl, or set up a schedule
No Search Console run	Blast radius and click figures have no source	Connect Search Console
Host mismatch forcing path matching	Search Console and the crawl disagree on hostname, so URLs are matched on path alone	Align the crawl host
Crawl in flight	A crawl is running; figures are from the previous one	Wait for it to finish

Health signals are cached for ten minutes to keep the page fast. The crawl-in-flight indicator is deliberately not cached — a stale "no crawl running" is exactly the wrong thing to show someone who just pressed the button.

Plan tiers

Capability	Free	Starter	Pro	Agency	Enterprise
Eight-bucket indexability report	✓	✓	✓	✓	✓
Bucket drill-down and duplicate clusters	✓	✓	✓	✓	✓
Crawl-regression incidents	✓	✓	✓	✓	✓
Change timeline (deploy correlation)	—	✓	✓	✓	✓
Blast radius in clicks and revenue	—	✓	✓	✓	✓
SLA triage, bulk resolve, snooze	—	✓	✓	✓	✓
Scheduled crawls	—	✓	✓	✓	✓

Blast radius and the change timeline both depend on the Search Console connection, which opens at Starter.

Best practices

• Crawl your live domain, always. Every other number on this page is downstream of that one choice.
• Set a schedule rather than crawling by hand. A comparison needs two crawls of the same host; ad-hoc crawls of whatever URL was in the box produce incomparable pairs.
• Treat the canonicalised bucket as a design question, not an error. Some canonicalisation is correct. A sudden jump in it is what matters.
• Read the change timeline before assuming Google changed something. Most regressions are self-inflicted and the window usually contains the cause.
• Do not bulk-dismiss on a wrong-host crawl. You will be dismissing findings about a site you do not sell on, and the real ones with them.

See also

• Site crawler — how crawls are configured, scheduled and scoped
• Site audit — the 35-signal page-level audit and broken links
• Sitemap — what you are telling Google to crawl in the first place
• Risk register — technical findings rolled into one prioritised backlog
• Digest and alerts — how regression alerts reach you