E-commerce SEO audit: checklist, costs and retest

Product variants, sorting options and filters can give an online store thousands of possible URLs. Many of them show almost the same products. Before changing canonicals or indexing rules, I decide which kinds of pages should be eligible to appear in search results.

That decision has to cover categories, products, filters, pagination and language versions separately. In the worked example, five filters can produce 7,559 URL combinations. This is a calculation based on possible filter values, not a measurement from a particular store.

An e-commerce SEO audit starts with a map of page types

An e-commerce SEO audit is a check of the whole system that generates URLs and product data. It covers categories, filters, variants, pagination, internal search and stock states. On top of that come JavaScript, Product markup, the Merchant Center feed and the performance of your most important templates. You'll record your map with its scope and date in the audit scope card (Polish-language template), and here's an example.

Your store may have different types, so start with an inventory of templates and parameters. Google describes e-commerce structure mainly through the relationships between pages and the links that connect them. A sitemap and a Merchant Center feed help Google discover URLs, but you build the architecture with links.

1. Every URL type in the store has a recorded target state

For each group of URLs in your store, record in the URL indexation matrix (Polish-language template) whether Google should fetch and index it, what its canonical is, whether it's in the sitemap, where links to it come from and what Search Console confirms. That record separates four questions that are easy to mix up.

robots.txt controls crawling, meaning whether a bot fetches the page at all. noindex only works once the crawler can read the directive, so on a URL blocked in robots.txt Google won't see it.

In your Search Console, compare the user-declared canonical with the Google-selected one. Trace a mismatch through the signals: redirects and internal links first, then the sitemap and the tag. The SEO module in CometWeb Insight, our website audit app, catches these barriers earlier, along with the canonical and HTTP status.

2. Filters and sorting have a controlled URL space

Faceted navigation, meaning narrowing a listing by product attributes, is useful to your shoppers, but a badly designed one creates practically unlimited sets of URLs. Google's faceted navigation documentation names the risk explicitly: overcrawling, which means crawl spent on URLs you don't need, and slower discovery of valuable pages.

Index only the filters with their own demand

A filtered combination deserves an indexable URL when you can answer "yes" to each of these.

• Does anyone actually search for this combination, meaning is there real search intent behind it?
• Is the filtered result stable over time, with enough products in it?
• Can the landing page offer more than the same list with a different parameter?

The remaining states have to work for your shoppers and get a separate crawl and indexation policy. Blanket noindex on every filter won't sort this out, because some filters answer their own demand and should have a stable URL.

The same filter state has one URL

A store platform can produce these addresses for the same filter state:

?brand=acme&color=black&size=m
?size=m&brand=acme&color=black
?color=black&size=m&brand=acme

That's the same selection, so your router should keep one parameter order. In an illustrative example, five different parameters have 120 possible orderings. How many of them your store actually generates depends on the router, so test parameter normalization explicitly. I got the number from the intro with a script.

It's pure combinatorics on an example, without a crawl of any store. The research pack has the example (Polish-language page), the script and the saved result.

Limit filter crawling with a separate policy

A canonical consolidates duplicates, but a crawler can still visit the variants. Filters the crawler shouldn't fetch need their own crawl policy, and filters meant for the index need stable URLs and a correct response for empty combinations.

3. Every product is reachable through links, pagination included

The rule that "a product must be at most four clicks from the home page" gets passed around the industry, but Google doesn't publish such a threshold. What does hold: every important product in your store has to be reachable through ordinary <a href> links.

Infinite scroll and a "Load more" button are fine as long as the rest of your catalogue also has its own URLs and links. Google's pagination documentation recommends separate URLs for result pages, connected by links. Googlebot follows links; it doesn't press buttons.

Run a quick test and open page two of your listing in a new tab. If it doesn't have its own URL, the crawler doesn't have one either.

4. Product variants have a canonical that matches the page model

You can handle color or size on a single page or at separate URLs. Google's product variant documentation covers both models for ProductGroup and Product.

• One URL, where the selected variant changes the price and availability in the interface, along with the images and SKU.
• Separate URLs, where each variant has a stable URL and its own Product data, and the ProductGroup, hasVariant and variesBy relationships are consistent.

The canonical decision follows from the page model and the intent. I wouldn't apply "every variant points to the parent" blindly, because a variant with its own demand may need its own URL.

5. The page, the schema and Merchant Center give the same product data

Google recommends sharing product data through structured data on the page, a Merchant Center feed or both at once. According to Google's Product structured data documentation, using both can widen eligibility, so compare at least these fields in your audit.

Product snippets and merchant listings have different requirements, so a gap in one column is an error only for some features. On 14 April 2026 Google published another update to the Merchant Center product data specification, including new shipping attributes at the product level. So your audit report should record the version and date of the specification you checked.

6. JavaScript renders the same price and availability

Google's JavaScript SEO basics describe how JavaScript gets rendered and how JSON-LD can be generated on the client side. A price your script adds is fine as long as the rendered result is consistent, and you check that in order:

1. what's in the initial HTML response, and what ends up in the DOM after rendering;
2. whether any of the resources needed for rendering are blocked;
3. whether the Product data matches the visible price and availability, including after a variant change;
4. what the Rich Results Test and URL Inspection show for the same page.

You can check the first point for free: Ctrl+U shows the initial HTML, and the Elements tab in DevTools shows the DOM after rendering. Be most careful with prices fetched from an API and with geo-pricing.

7. Unavailable and discontinued products have separate rules

If the product will come back, the page stays and shows the stock state, and you update availability and the feed. Merchant Center's availability help page then points to out_of_stock if the store isn't accepting orders for it.

With a product discontinued for good, what matters is what the old page still gives the shopper.

• There's a successor that meets the same need, so consider a redirect.
• The page is still useful, because it has informational value or demand, so you can keep it without the option to buy.
• Nothing is left, and then 404/410 is the correct state for a removed resource.

Mass-redirecting discontinued products to the home page loses the meaning of the previous address. An unintended 404 on a product that should still exist is more often the real error. Merchant Center's help page on unavailable landing pages warns that an unavailable landing page can remove the product from ads and free listings until the page works again.

8. A category matches an intent and has a range

There's no universal minimum word count for a category, so judge it by whether it matches an intent, helps the shopper choose a product and has enough products. Also check whether empty categories and filter combinations create thin pages, meaning pages with no real content.

9. Sitemaps, canonicals and parameters follow one policy

Your sitemap should contain the URLs you want indexed, and typical conflicts with that rule look like this.

• the sitemap contains a URL with noindex or a redirect, or sometimes a parameterized variant whose canonical points elsewhere;
• discontinued products stay in the sitemap for months;
• several hosts or language versions declare conflicting canonicals.

I recently had this kind of mismatch on cometweb.io, where the sitemap listed 281 URLs, but my crawler reached only 273. The missing 8 were old posts hidden from the blog with a category filter the sitemap generator didn't know about.

After the change, these URLs return 200 with noindex, follow and have been removed from the sitemap. A store can have the same pattern across many more URLs, including discontinued products and categories intentionally hidden from search.

For a larger store I'd split the sitemap by page type, because the sitemaps report in Search Console then shows each type separately. I show how to keep these signals in line in the guide on how to set canonicals and the sitemap together with robots.txt.

10. A multilingual store gets a separate audit of markets and URLs

With several markets, you check separate URLs for languages or countries and hreflang, the markup that labels a page's language versions. Add currency, shipping with returns and a Merchant Center feed for each country. The same SKU in two markets is two states, because the price and the ability to buy can differ.

11. Performance is measured by template and scenario

Measure store performance separately in at least five scenarios: a category, a product page with a large gallery, a product with variants, a listing after a filter and the most important public step before checkout.

The Core Web Vitals that matter are LCP (how fast the largest element shows up), INP (how fast the page responds) and CLS (how much the layout shifts). Look for causes in the LCP resource and scripts, and in a store also in the work done when a variant changes. The Performance module in Insight separates CrUX field data from Lighthouse lab measurements, and when data is missing, it shows the reason instead of a zero. I described the before/after procedure in the guide to speeding up your website.

12. Crawler, Search Console and Merchant Center data go side by side

Each of these sources answers a different question, so base any "this URL is missing" conclusion you draw on at least two of them.

Crawl in Insight groups repeated issues by template, and you'll find more on the Insight Crawl page. It may miss pages behind a login, and for a crawl with custom extraction Screaming Frog is still the better tool.

How much does an e-commerce SEO audit cost in 2026?

In September 2026, public Polish price lists started at 4,900 PLN net for an online-store audit (Semgence), with an indicative 2,500–8,000 PLN net for an extensive e-commerce site and over 10,000 PLN for very large stores (Ansite).

These are Polish agencies (CometWeb's home market) quoting in złoty (PLN) net of VAT. I haven't collected comparable English-language offers or converted the prices into USD or EUR, so read them as an illustration of how scope drives price, not as a benchmark for your market.

The stated scope of the Semgence price list covers the technical side and content, plus the link profile and competitors. The Ansite range is one provider's estimate from an update dated 8 August 2026 (Ansite on audit costs). You can't derive a market median from examples like these.

What changes the cost of a store audit most

When you compare quotes, ask the provider which of these points their offer covers.

1. the number and types of templates, the number of products and the size of the URL space;
2. the number of markets and languages, Merchant Center with its feeds, and server logs;
3. manual tests of filters and variants, rendering included, plus a retest included in the price;
4. content and competitors or only the technical side, with priorities and tasks in the output and help with implementation.

An "audit of 100,000 URLs" can be shallower than an audit of twelve representative scenarios with rendering and Search Console data. It's the list of checks they run that describes the scope you get. I'd open the conversation with point 3, because manual tests and the retest are what check whether the fixes work.

What the e-commerce SEO audit output should look like

Every significant finding in your report gets eight fields: the problem, the scope, the evidence, the impact with a confidence level, the recommendation, the owner, the acceptance condition and the retest. Here's an example.

The row above only illustrates the format and isn't a result of a CometWeb or client audit. The numbers in a real report must come from the store you audited. To hand the result to a client, use the structure from the client-ready website audit report.

Store audit retest: what to check after implementation

A store retest has four parts, and you close the task only when all of them pass.

• Filters produce the number of discovered combinations the plan expected, the chosen landing pages still get indexed and parameters keep a stable order.
• Variants open at the right URLs, and your schema agrees with the price and availability.
• Products have availability that matches your page and your feed, and redirects lead to genuine successors.
• Google data gets checked in the Rich Results Test, in Search Console after a recrawl and in Merchant Center after the feed syncs.

You can record the before and after conditions in the retest card (Polish-language template). In Insight you can put two crawls side by side and check a single link with the "Check again" button.

Three takeaways

1. Map first, errors second. The decision about every URL type organizes the rest of the audit, but your template can break it in the next deploy.
2. Filters multiply URLs. In the example, five filters give 7,559 states of a category. A canonical consolidates them, but you limit crawling with a separate policy.
3. The retest closes the audit. When you get a quote, ask about manual tests and the retest first, because they're what show whether the fixes work.

Tomorrow morning, list your store's page types and mark next to each one whether it should be in the index. If you want a crawl of your store with a priority list and a comparison of runs after each release, create a free Insight account.

If you do this differently and it works, write to me at maciej@cometweb.io.

Frequently asked questions about e-commerce SEO audits

Sources

1. Google: Managing crawling of faceted navigation URLs.
2. Google: Pagination, incremental page loading, and Search.
3. Google: Product variant structured data.
4. Google: Share your product data with Google.
5. Google: Product structured data.
6. Google Merchant Center: product data specification update 2026.
7. Google: JavaScript SEO basics.
8. Google Merchant Center: availability.
9. Google Merchant Center: product page unavailable.
10. Semgence: SEO audit, price list and scope 2026 (in Polish).
11. Ansite: How much does an SEO audit cost? (in Polish).
12. Google: e-commerce website navigation structure.

The research pack templates are in Polish. This article does not guarantee higher rankings, more sales or eligibility for any Google feature.