The technical SEO audit playbook
Store SEO problems are structural more than editorial: crawl waste, facet chaos, orphaned products, invalid markup. The audit’s value is not the finding — it is the fix order.
Generic audit tools produce four hundred issues and no plan. A store audit worth running asks a sharper set of questions — is crawl budget going to pages that convert, does the index match the catalogue, does the markup validate, is the store fast where users actually are — and orders the fixes by traffic at risk. This playbook runs that audit and, more importantly, the triage after it.
Stage 1: Crawl and indexation reality
Crawl the store the way a search engine does, then compare three sets: pages that exist, pages being crawled, and pages indexed. The gaps are the findings. Facet URLs consuming crawl budget, product pages orphaned from any internal link, soft-404 collections, redirect chains from years of replatforming — every store past a certain age has all four.
Crawlable URL inventory versus the intended catalogue — the two diverge more than anyone expects
Faceted navigation: which filter combinations are crawlable, indexable, and actually deserve to be
Orphaned products, redirect chains, and soft 404s enumerated
Index coverage per template type — products, collections, content
Stage 2: The layers that gate performance
Structured data validated across templates — not spot-checked, validated, because one template error multiplies across every page using it. Rendering checked: what the crawler receives versus what you meant to serve, the classic silent failure on script-heavy themes and headless builds. Speed read from field data per template. hreflang integrity for multi-locale stores. Each layer is mechanical to check and expensive to leave broken.
Stage 3: Triage by traffic at risk, then re-audit on schedule
Four hundred issues collapse into a short ordered list when weighted by traffic at risk: template-level fixes first (one fix, catalogue-wide effect), then high-value page fixes, then the long tail. Ship in that order, verify in Search Console, and schedule the re-audit — because theme updates, app installs, and catalogue growth regenerate technical debt continuously. An audit is a snapshot; the schedule is the asset.
How it works
Crawl and compare
Store crawled as an engine sees it; existence, crawl, and index sets diffed for the real findings.
Validate the gating layers
Structured data, rendering, field speed, and hreflang checked template by template.
Fix by leverage, re-audit by schedule
Template-level first, high-value pages next, verified in Search Console, repeated on cadence.
What you get
Crawl budget redirected from facet noise to revenue pages
An index that matches the catalogue you actually sell
Markup that validates across every template, not most
Technical debt caught by schedule instead of by traffic loss
Handled by these agents
Frequently asked questions
How often should a store re-audit?
Full audit quarterly; continuous monitoring for the failure-prone layers — structured data validity, index coverage, speed regressions — because those break silently between audits. After any replatform or major theme change: immediately.
What is the single most common store finding?
Uncontrolled faceted navigation — thousands of crawlable filter permutations diluting crawl budget and duplicating content. Fixing it is template-level work with catalogue-wide effect, which is why it usually tops the triage.
Do I need an audit if traffic looks fine?
Rising traffic hides structural waste; the audit tells you what you are leaving unclaimed. And the failure modes worth catching — deindexation from a bad robots change, markup invalidation from a theme update — announce themselves through traffic only after weeks of damage.
Which agents run this?
Visibility owns the crawl, validation, and triage; Ops supplies field speed data; Builder ships the template fixes. The re-audit cadence and last-known-good state live in shared memory, so regressions are diffs, not mysteries.
Keep reading
E-commerce SEO at scale
Metadata, structured data, and content across a whole catalogue — not just the top twenty pages.
Structure internal links
An internal link architecture that spreads authority to revenue pages — maintained, not decayed.
Improve store page speed
A field-data-first speed programme: measure real users, fix by layer, prevent regression.
Product launch checklist
The complete launch sequence — page, tracking, search, email — as a checklist that runs itself.
Put the team to work on your store
Connect your storefront, analytics, and email stack, set a goal, and let the agents run the work end to end. Start on the free plan with your own model key.