Menu

How to run an ecommerce SEO audit

The checks that actually move rankings on a large catalogue: faceted navigation, product page SEO, duplicate variants, crawl budget, and structured data.

Faizan Shaikh
Faizan Shaikh · Founder · 9 min read

An ecommerce SEO audit is not the same job as auditing a content site, and running a generic checklist over a large catalogue mostly produces noise. The problems that suppress ecommerce rankings are structural: too many URLs, too many near-identical pages, and crawl budget spent on combinations nobody searches for.

This is the order we work in, and the order matters. Fixing product copy while faceted navigation is generating half a million crawlable URLs is effort spent in the wrong place.

1. Count your indexable URLs before anything else

Start with the number, because it reframes everything that follows. Compare the count of URLs Google has indexed against the number of products you actually sell. A store with 4,000 products and 60,000 indexed URLs has a structural problem, and no amount of on-page work will outrun it.

The gap is almost always faceted navigation, pagination, internal search results, or session and tracking parameters generating unique URLs. Each of those consumes crawl budget that should be going to product and category pages.

Where to look

Search Console index coverage against your product count, then a crawl of the site to see what is actually linked. The crawl usually finds far more than the sitemap admits to.

What good looks like

Indexable URLs in the same order of magnitude as products plus categories plus editorial. Multiples of ten above that need explaining.

2. Faceted navigation SEO, the biggest single lever

Faceted navigation SEO comes down to one problem: filter combinations multiply. Colour, size, brand, price band and rating on one category produce thousands of URL permutations, and if they are crawlable and linked, Google will crawl them. Most return near-identical product sets, so they compete with each other and with the clean category page.

The fix is a deliberate decision per facet rather than a blanket rule. Some facets genuinely deserve indexable pages because people search for them: brand and category combinations usually do. Colour, price band and rating usually do not.

A workable default for facet handling
Facet typeHandlingWhy
Brand within categoryIndexable, own title and descriptionGenuine search demand for "brand + product type"
Single high-demand attributeIndexable if search volume justifies itCheck volume first; most do not justify it
Colour, size, rating, price bandnoindex, or blocked from crawling entirelyNear-zero search demand, high URL multiplication
Multiple facets combinedNot crawlableCombinatorial explosion with no demand behind it
Sort order and view togglesNot crawlableSame content, different order. Pure duplication

3. Product page SEO: variants are where it goes wrong

Product page SEO is mostly about deciding what constitutes a page. A shirt in eight colours can be one URL with a colour selector, or eight URLs. Both are defensible; what is not defensible is eight URLs with the same title, same description and same content bar one word.

If variants get their own URLs, each needs a genuine reason to exist as a separate page: distinct search demand, distinct imagery, distinct copy. Otherwise canonicalise them to the parent and let the selector handle it.

Beyond that, the on-page work is unglamorous and effective: unique descriptions rather than manufacturer boilerplate, complete Product and Offer structured data including price and availability, real images with meaningful alt text, and reviews where you genuinely have them.

Manufacturer descriptions

The single most common thin-content problem in ecommerce. Every retailer selling the product has the same paragraph. Rewriting even the top 20% by revenue is usually worth more than any technical fix.

Out-of-stock and discontinued products

Do not delete a page that has inbound links and rankings. Keep it, mark availability correctly in schema, and offer alternatives. Deleting it throws away the authority it accumulated.

Structured data completeness

Product with Offer, price, currency and availability is the minimum. Incomplete markup silently loses rich result eligibility rather than erroring.

4. Category pages are your ranking pages

For most stores, category pages have more search demand behind them than individual products, and they are consistently the most under-invested pages on the site.

A category page that is nothing but a product grid gives search engines almost no text to work with. Adding a genuinely useful introduction, buying guidance, and answers to the questions people ask before choosing is usually the highest-return content work available on an ecommerce site.

Put that content where it does not push the products below the fold. Buyers want the grid; search engines want the text. Both can be satisfied.

5. Speed, at catalogue scale

Ecommerce performance problems rarely show on a test page with twelve products. They show on a category page with sixty products, each with images, prices resolved live, and a review widget.

Test on your worst realistic page rather than your homepage. The usual culprits are unoptimised images, a review or personalisation script blocking rendering, and prices fetched per product at request time rather than cached.

The order matters

If you do nothing else in sequence, do this: count URLs, fix faceting, resolve variant duplication, then improve category content, then chase speed. Working the other way round is the most common reason an audit produces a long document and no ranking movement.

Common questions

How often should we run an ecommerce SEO audit?

A full structural audit once a year is usually enough for a stable catalogue, plus one after any significant change: a replatform, a redesign, a navigation change, or a large catalogue import. The structural issues covered here do not drift much on their own. What does need continuous monitoring rather than periodic auditing is the small set of numbers that reveal a new problem early: indexed URL count against product count, crawl stats, and Core Web Vitals field data. If indexed URLs jump by an order of magnitude, something started generating crawlable combinations and you want to know that in a fortnight rather than at the next annual review. Set those three up as monitoring and the audit becomes a deeper periodic exercise rather than the only time anyone looks.

Should product variants have their own URLs?

Only where each variant has genuine independent search demand, and for most catalogues that means no. The test is whether people search for the variant specifically: a shoe in a particular colourway that customers search by name justifies its own page, while a t-shirt in eight colours almost never does. When variants do get their own URLs they need distinct titles, distinct descriptions, and distinct imagery, otherwise you have created eight near-duplicate pages competing with each other and diluting the signals that should concentrate on one. When they do not, canonicalise variants to the parent product and let a selector handle the choice in the interface. The failure mode to avoid is the default many platforms ship with, which generates a URL per variant automatically and leaves every one of them indexable.

Will blocking faceted URLs lose us traffic?

Almost never, and it usually gains traffic, though the mechanism is indirect enough to be worth explaining. Faceted URLs rarely rank for anything valuable because they duplicate the category page they descend from, so blocking them removes pages that were not earning traffic. What you gain is crawl budget: Google spends its allocation on your products and categories rather than on colour-plus-price-band combinations, which means new and updated products get discovered faster. The exception is the small number of facets with real search demand behind them, typically brand within category. Those should stay indexable with their own titles and descriptions. Check volume before blocking rather than applying a blanket rule, and stage the change so you can observe the effect on crawl stats.