What an ecommerce SEO audit should actually check

The order that makes an ecommerce SEO audit useful: indexation, crawl paths, canonicals, templates, product data, speed, then on-page.

Reviewed for accuracy by Teo Yordanov · September 2026

What an ecommerce SEO audit should actually check

Order of operations matters more than completeness in an ecommerce SEO audit. The documents clients show us when they arrive routinely run to ninety-something pages, with a section for every category of technical SEO you could name: crawl, indexation, speed, structured data, on-page, content, links, and no indication anywhere of which of the forty-odd findings would actually move something. The marketing manager reads the first six pages and never opens the rest.

An ecommerce SEO audit is only as useful as the order it runs in. Fixing a page's content before its indexation is sorted wastes the work, because Google can't credit good copy on a page it isn't crawling or indexing correctly in the first place. The order that holds regardless of platform runs from the structural layer down to the smallest one: indexation (what's actually in Google's index), crawl paths and faceted URLs, canonical tags, page templates, product data quality, speed, structured data, and only then on-page content and keywords. This article walks through what to check at each step, why the sequence holds on Shopify, Magento and WordPress alike, what a useful audit deliverable looks like instead of a document nobody reads, and when a full audit isn't actually the right tool. It's a sequencing guide, not a line-by-line audit template.

Order first, completeness second

The order matters because each layer in a store sits underneath the one above it. A perfectly written product title does nothing if the page it's on isn't being indexed. A clean canonical tag does nothing if the crawl path feeding Google that URL is still broken. Every audit I run, whether it's a Shopify storefront, a Magento catalogue or a WordPress build, follows the same eight-step order for this reason. I've run it on Periodico, a headless Shopify build, and on 18 Carati, a Magento 2.4 catalogue, two stores that don't share a line of templating logic between them, and the sequence held on both: what's actually indexed, before what's feeding the crawl queue, before canonicals, whichever platform is generating the mess underneath. The tools change per platform (Magento's module stack complicates it in its own specific way; each platform locks down a different layer), the sequence doesn't.

The rule underneath all eight steps: check things at the template level before checking them page by page. Fixing one template fixes every page built from it. Fixing one page fixes nothing else on the site. An audit that opens by flagging thirty individual meta descriptions, when the underlying template is the actual problem, has spent thirty items' worth of attention on one fix repeated thirty times.

1. Indexation: what's actually in Google's index

Before touching anything, confirm what Google actually has. The Page indexing report in Search Console shows what's indexed, what's excluded and why, and it's worth reading in full before assuming what the problem is (source: support.google.com/webmasters/answer/7440203). More than once, the finding at this step wasn't "not enough pages are indexed", it was the opposite: thousands of filtered, paginated or parameter URLs sitting in the index that were never meant to be there, quietly diluting whatever authority the real product and category pages could otherwise hold. You can't prioritise a problem you haven't confirmed exists, and indexation is the only step that tells you what Google is actually working with rather than what you assume it's working with.

2. Crawl paths and faceted URLs

Once you know what's indexed, the next question is where it came from. Faceted navigation, the filter sidebar on a category page, colour, size, price, material, generates a fresh URL for nearly every combination a shopper can select. On a catalogue of any real size the crawlable combination count can run well past the number of actual products, and it's the single most common source of crawl waste I find on ecommerce audits, whatever platform sits underneath it (source: developers.google.com/crawling/docs/crawl-budget). The fix at this step isn't the canonical tag yet, that's next, it's confirming Google isn't being invited to crawl combinations that were never going to earn a page of their own. Internal links, sitemaps and robots rules all feed this, and all three need checking together, not just whichever one looks broken first.

3. Canonicals

Canonical tags decide which of several similar URLs Google should treat as the real one, and they're where step two gets fixed properly rather than just papered over. Treating a correct canonical as the whole fix is the single most common misstep at this step. It isn't: a canonical tells Google which page to index, it does nothing to stop Google crawling the others first (source: developers.google.com/search/docs/crawling-indexing/canonicalization). A filtered URL with a perfect canonical pointing back to its category page still costs crawl budget every time Google fetches it to discover that canonical. Check both halves: is the canonical pointing where it should, and is crawl access to the wrong version closed off as well.

4. Templates before individual pages

This is the step I've seen save the most time on a large catalogue, and the one most audits skip past to get to something that feels more concrete. Before auditing individual product or category pages, I check what the template they're built from is doing: duplicate title patterns, missing or duplicated H1s, meta description formulas that repeat the same sentence with one word swapped, structured data present on one page type and silently absent from another. A template issue found on page one of a crawl is the same issue on page four thousand. Finding it at the template level and fixing it once is most of the reason step order matters more than checklist completeness.

5. Product data quality

With templates sound, the next layer down is the data feeding them: product titles, descriptions, images, identifiers, and availability and price accuracy where that's surfaced to Google. Thin or manufacturer-supplied descriptions duplicated across dozens of near-identical products are the most common finding I see at this step, and they're a genuinely different problem from a template issue: the template is fine, the content sitting inside it isn't. This is also the step where feed data, the same information a Shopping feed relies on, and on-page content tend to quietly diverge, and checking that they still agree is worth doing here rather than assuming they do.

6. Speed, once the structural layer is sorted

Speed and Core Web Vitals get checked here, not earlier, because a genuinely slow page is worth fixing regardless of what an audit finds, but a speed finding raised before the structural layer is sorted often gets misdiagnosed. I've seen a layout shift caused by a late-loading reviews widget get blamed on an unoptimised hero image, because the two look identical until you've already ruled out what's happening earlier on the page. In my experience Core Web Vitals behave as a minor, tie-breaking ranking signal on their own; the bigger cost of a slow, shifting page is usually conversion, not ranking, which is worth saying plainly so speed doesn't get treated as the headline finding when it rarely is.

7. Structured data

Structured data is the JSON-LD markup that tells Google what a page actually contains, and I check it once the page itself is sound, because schema describing content that isn't there yet just adds a second layer of inaccuracy on top of the first (source: developers.google.com/search/docs/appearance/structured-data/intro-structured-data). Product and offer schema is usually present in some form on most modern builds by this point; what's more often missing is breadcrumb, FAQ or review schema, and consistency between what the schema claims, price, availability, rating, and what's actually visible on the page. A mismatch here does more than fail to help: where the same data feeds a Shopping feed, it's a common trigger for Merchant Centre disapprovals, which turns an SEO finding into a paid media problem overnight.

8. On-page content and keywords, last

On-page content is where most audits start: titles, headings, keyword placement, internal anchor text, whatever is most visible on the page and easiest to have an opinion about without any tooling. In this order, I put it last, because none of it matters if the seven steps above it aren't sound. A beautifully written product title on a page Google isn't indexing, or is indexing under the wrong canonical, or is loading three seconds slower than the category page next to it, isn't being read by anyone it was written for. On-page work is where an audit's value compounds, but only once everything underneath it already works, which is why I run it last rather than first.

What a useful audit deliverable looks like

None of the above needs to produce a document nobody reads. In my experience, the audits that actually get acted on rank three or four findings by expected impact and stop there, with everything else logged but not competing for attention. A ninety-page PDF with forty equally-weighted findings puts the same visual space against a missing alt tag as it does against a genuinely serious indexation problem, and a reader with limited time reasonably assumes the document is padded rather than prioritised. What makes a report useful is the ranking, not the length: three findings a reader can act on in an afternoon beat forty that all look equally urgent.

When a full audit is the wrong tool

A full audit isn't the right call in every situation. If there's one known blocking issue, say a site deindexed after a migration or a robots.txt file accidentally disallowing more than it should, that's a targeted diagnostic, not a full sequence through eight layers. If traffic looks fine but revenue doesn't, I'd point at conversion before visibility, which is a different piece of work entirely, closer to CRO than to SEO. And if a store is genuinely new, with little indexed history and no real crawl or content volume yet, a full audit mostly confirms there's nothing to find. That time is better spent getting the foundations right from the start: indexation, crawl access, canonicals, rather than auditing a shop that has nothing there yet.

If you're weighing up whether a full audit or a narrower fix is the right next step, that's the diagnosis work behind BYLT's SEO service.

Sources.

  1. Optimize your crawl budgetGoogle for Developers (accessed August 2026)
  2. What is canonicalizationGoogle Search Central (accessed August 2026)
  3. Page indexing reportGoogle Search Console Help (accessed August 2026)
  4. Intro to how structured data markup worksGoogle Search Central (accessed August 2026)

Frequently asked questions.

What should an ecommerce SEO audit actually cover?
Eight layers, in order: what's currently in Google's index, the crawl paths and faceted URLs feeding that index, canonical tags, page templates, product data quality, page speed, structured data, and on-page content and keywords last. Most audits cover all eight; few run them in an order that makes the findings useful.
How is an ecommerce SEO audit different from a general SEO audit?
The mechanics are the same. What's different is scale and the specific failure modes: faceted navigation multiplying URLs, product data quality across hundreds or thousands of near-identical pages, and structured data, price, availability, reviews, that has to stay accurate against a live catalogue rather than a handful of static pages.
Do I need a full audit, or can I fix things one at a time?
Only if nobody has actually confirmed which layer the problem sits in. A single known issue, like a robots.txt rule blocking more than it should, is worth fixing directly rather than running a full sequence. The full eight-step order earns its keep when the real problem is genuinely unclear.
Why does my audit report contradict itself between two crawls run days apart?
Usually caching. Some platforms, Magento in particular, serve more than one HTML variant of the same URL depending on cache state, so a single fetch isn't reliable evidence on its own. Fetching the same URL more than once before drawing a conclusion is worth the extra few minutes.
How often should an ecommerce SEO audit be repeated?
There's no fixed interval that applies generally, it depends on how often the catalogue, platform or templates change. A store that's stable month to month needs far less frequent auditing than one going through a migration, a new filtering system, or a large seasonal catalogue expansion.
What's the single most common thing an ecommerce SEO audit finds?
In the accounts I've audited, it's URLs that were never meant to exist: faceted navigation combinations, parameter variants, duplicate category paths. They sit in the crawl queue or the index using up attention the real product and category pages need instead.