An ecommerce SEO audit is a full crawl and review of how search engines find, read and rank a store's category and product pages. It covers eight areas: indexation, faceted navigation, categories, products, site structure, template speed, structured data and AI shopping visibility. The output is a fix list weighted by revenue, not a list of every error.
That last sentence is the one most store owners have never been given. A generic site audit exported from a crawler produces 200 rows of warnings and no sense of which ten matter. An ecommerce audit has to answer a narrower question: which pages make money, which of them cannot be found or read properly and what single change fixes the most of them at once.
This article sets out what we check, in the order we check it and why each step sits where it does. If you run a store on Shopify, WooCommerce, BigCommerce or a headless stack, the areas are the same; the fixes differ by platform.
What an ecommerce SEO audit is and what it is not
A store is not a brochure site with more pages. Three things make it a different audit:
- Catalogue scale. A store with 400 products and 30 collections can generate 50,000 URLs once filters, sorts and variants are counted. Most of them should not be indexed.
- Constant change. Products go out of stock, get discontinued, change price. The audit has to look at how the store handles those states, not just how it looks today.
- Product data. Price, availability, variants and reviews are structured data problems as much as content problems. Google's own ecommerce guidance treats them as a separate discipline for that reason.
So the audit is not a crawler export, a keyword list or a speed score. It is the three put together and ranked against revenue.
1. Crawl and indexation
What we check. Three lists, compared against each other: the URLs a crawler can reach, the URLs in the XML sitemap and the URLs Google reports as indexed in Search Console. The gaps between those lists are where the store is leaking.
Why first. Nothing later in the audit matters for a page Google has not indexed. A store that has indexed 40,000 filter pages has buried its 400 products among them.
The Search Console reports to read first, in this order, using the Page indexing report:
- Page with redirect. Usually old product URLs after a replatform. Fine if they point at the right replacement; a problem if they chain or point at the homepage.
- Duplicate without user-selected canonical. Google chose a different canonical than the store did, or the store set none. On a store this is almost always variant and filter URLs.
- Crawled, currently not indexed. Google reached the page and decided not to keep it. On a store this means thin category pages, near-duplicate products or parameter URLs.
- Discovered, currently not indexed. Google knows the URL exists and has not bothered to fetch it. This is a crawl budget signal. On large catalogues it is the one to watch (see our note on crawl budget).
We also look for session IDs, tracking parameters and internal search result pages leaking into the index. They inflate the indexed count and dilute everything else.
2. Faceted navigation and duplicate URLs
What we check. Every filter and sort control on category pages and what URL each one produces. Then: which of those URLs are indexable, which are canonicalised back to the category, which are blocked and whether the choices are consistent.
Why it matters. Filters multiply. Size, colour, brand, price range and sort order on one collection of 50 products can produce thousands of URLs with the same products in a different order. Google's faceted navigation guidance is explicit that most of these should not be crawled or indexed.
The judgement call is which facets deserve to be indexable. A facet earns its own indexable page when real people search for the combination ("women's trail running shoes size 9" does get searched; "sort by price descending" does not) and the page has enough distinct products to be useful. Everything else gets a canonical back to the parent category, a noindex or a robots.txt rule. The audit records which of the three the store is using and whether it is applied consistently.
We cover the full method, platform by platform, in the faceted navigation guide later in this series.
3. Category pages
What we check. For each category and collection: does it target a keyword with measurable demand, does it have enough copy to be understood as a page about that topic and is it linked to from the navigation and from related categories?
Why it matters. Category pages are where the commercial head terms live. "Men's running shoes" is a category query. A store whose categories are a product grid with a one-line heading is asking Google to rank a page with almost no text against competitors who have written 300 words and an FAQ.
Common findings: categories that duplicate each other ("Sale" and "Clearance"), categories with three products, categories that exist only in a mega-menu and have no inbound links anywhere else and category copy pushed below the grid where nobody reads it. We also check whether the category hierarchy matches how customers actually search, which the keyword mapping article in this series covers.
4. Product pages
What we check. Copy originality, variant handling, out-of-stock and discontinued behaviour and structured data.
Why it matters. Most product copy on most stores is the manufacturer's description, which means the same paragraph exists on every retailer selling that product. Google has no reason to rank one copy over another, so it ranks the one with the most authority, which is rarely the smaller store.
Variants are the second trap. A product in six colours can exist at seven URLs. The audit checks that variants canonicalise to one product URL (or are deliberately indexable, with distinct content, where variant searches exist).
Out-of-stock handling is the third. A product that is temporarily out of stock should stay indexed with its availability marked; a discontinued product should 301 to its replacement or its category, not return a 200 "sold out" page forever or a 404 with no redirect. We read a sample of each state and see what the store actually does.
Structured data: Product markup with Offer, price, priceCurrency and availability, validated against Google's Product structured data documentation. We also check it against Search Console's Merchant listings report where the store is eligible.
5. Site structure and internal links
What we check. Click depth from the homepage to every revenue page, breadcrumb consistency, orphaned products and whether pagination is crawlable.
Why it matters. A product four clicks from the homepage with one inbound link is a product Google will crawl rarely and rank poorly. On large catalogues, click depth is often the difference between a product being indexed and sitting in "Discovered, currently not indexed".
Pagination gets its own check because so many stores break it. Infinite scroll with no paginated URLs, "load more" buttons that fetch via JavaScript only or paginated pages canonicalised to page one all mean products beyond the first page are effectively invisible. Google's pagination guidance for ecommerce sets out what crawlable pagination needs.
6. Speed on templates, not pages
What we check. Core Web Vitals field data (from the Chrome UX Report via Search Console) for the category template and the product template, then lab tests on representative pages of each to find what is slow.
Why templates. A store has two or three templates and thousands of pages. A fix to the product template applies to every product. Auditing pages one by one is how speed work turns into a 200-row report nobody actions.
The usual culprits on stores: app and third-party scripts (reviews widgets, chat, personalisation, tracking pixels) that load before the product image; uncompressed hero images; and themes that ship the whole JavaScript bundle to every page. We list the scripts by weight and by what they are for, so the owner can decide which ones earn their place.
7. Structured data and merchant listings
What we check. Whether the store's Product markup is valid and complete, whether Search Console shows Merchant listings and Product snippets eligibility and whether Organization and BreadcrumbList markup are present and consistent.
Why it matters. Structured data is how price, availability and ratings appear in results. It is also how AI shopping surfaces read a product. The common errors are mundane: missing priceCurrency, availability left as "InStock" on sold-out items, review markup with no reviews behind it and markup that disagrees with what the page shows. Each of those can cost the rich result. We cover the broader logic in our note on schema mapping.
8. AI shopping visibility
What we check. For ten category prompts a shopper would type into ChatGPT, Perplexity or Google AI Mode ("best trail running shoes for wet weather Australia"), whether the store or its products are mentioned and which sources the answer cites instead.
Why it is in the audit now. Shoppers can now ask an AI assistant which product to buy. Those answers draw on a short list of sources: retailer product pages with clean structured data, review sites and comparison articles. If a store appears nowhere in those sources, no amount of ranking work changes the AI answer. We record the baseline so progress can be measured, using the method in our guide to AI visibility tracking. The final article in this series covers how to get products into those answers.
Score your store in two minutes
How we prioritise what we find
Every finding goes into one table:
| Issue | Pages affected | Revenue at stake | Effort | Priority |
|---|---|---|---|---|
| Filter URLs indexable | Every collection that uses filters | Indirect: crawl budget and dilution across every category | Medium (one template rule) | 1 |
| Heavy third-party scripts on the product template | Every product page | Direct: conversion on every product page | Medium | 2 |
| Categories with no inbound links except the mega-menu | Those categories and their products | Direct, when they cover the store's highest-volume terms | Low | 3 |
| Discontinued products return 200 "sold out" pages | Every retired product URL | Low per page, but they hold link equity the replacements need | Low | 4 |
| Manufacturer copy on product pages | Every product using supplier descriptions | High over time, slow to fix | High | 5 (programme, not a fix) |
Two rules decide the order:
- Template-level fixes first. One change to the collection template fixes every collection. A fix that touches one page goes to the bottom unless that page is the top earner.
- Revenue pages before everything else. We weight by the store's own sales data where the owner shares it. Where they do not, we weight by Search Console clicks.
This is how the programmatic work for 2XU was sequenced: fixing the templates first made it possible to add 800+ indexed pages in six months. Over the same period, organic revenue rose 50% and average order value rose 53%. The audit came before any new page was built. You can read the 2XU case study for the detail.
Doing it yourself versus getting help
A store owner can do a real first pass with two free tools:
- Search Console. Read the Page indexing report and the Core Web Vitals report. If "not indexed" pages far outnumber indexed ones, faceted navigation is the likely cause.
- A crawler. Screaming Frog's free tier crawls 500 URLs, which is enough to see how filters, variants and pagination behave on a sample of categories.
The signs a store has outgrown the self-audit:
- A catalogue large enough that the gap between crawled and indexed starts costing real pages.
- Multiple regions or currencies, where hreflang and duplicate catalogues come into play.
- A platform migration coming, where the audit becomes the redirect map and the thing that protects the revenue through the move.
- Products that rank but do not appear in any AI shopping answer, which is a structured data and third-party coverage problem rather than a ranking one.
If any of those describe your store, the next step is an audit of the full catalogue. Request an ecommerce SEO audit and we crawl the whole store, read the Search Console history and send back a revenue-weighted fix list in the format above. The audit is the first stage of the Ecommerce SEO add-on, scoped on catalogue size. It also stands on its own if you only want the list.
Common questions
How long does an ecommerce SEO audit take?
For a store under 10,000 URLs, about two weeks from access to the fix list: a week for the crawl, log and Search Console reads, a week for analysis and prioritisation. Larger catalogues and multi-region stores take longer because the crawl itself does.
What access do you need?
Search Console (full user), Google Analytics 4 (viewer) and read access to the storefront. Server log access helps for crawl budget work but is not essential for a first audit. We never need admin access to the store platform for the audit itself.
Is a Shopify SEO audit different from a general ecommerce audit?
The eight areas are the same. What differs is where the problems sit: on Shopify, collection and tag URLs, the /collections/<name>/products/<handle> duplicate path, variant parameters and app scripts dominate. The checklist is the same; the fixes are platform-specific.
How often should a store be audited?
A full audit once a year or before any migration, plus a quarterly check of the Page indexing report and Core Web Vitals, which catches most regressions early.
Does the audit cover AI shopping results?
Yes. Section 8 records whether the store appears in ChatGPT, Perplexity and Google AI Mode answers for ten category prompts and which sources those answers cite instead. That baseline is what later work is measured against.
This guide is part of the Technical SEO series. Start with What is Technical SEO? The Enterprise Architecture Guide.