Ecommerce SEO Audit: What to Check and in What Order

An ecommerce SEO audit, in practice, rarely needs paid tools. Most of what you need to check, Google already gives you for free in Search Console and Merchant Center — the problem isn't data access, it's the order you read it in. An audit that starts with product content has little value if a large part of the catalogue isn't indexed yet; an audit that starts with Core Web Vitals doesn't make sense if Google's crawlers aren't even reaching product pages because of misconfigured faceted navigation.

This article breaks an ecommerce SEO audit down into seven steps, in the order they matter — from indexing, through performance and rich results, to content and Merchant Center data — based on Google Search Console and Merchant Center Help documentation read on 1 October 2026. We cover a general audit of any website, regardless of industry, in the website audit article; this article focuses on what's different about an online store — thousands of URLs, filters, variants and Merchant Center requirements that a company site or blog doesn't have.

Why the order of an ecommerce SEO audit matters

Each of the seven steps below builds on the one before it: a higher step checks something that only makes sense once the lower one is already in order. That's why an ecommerce SEO audit started in the middle — say, with product content, or with how a page looks in search results — can end in fixes that change little, if the real cause sits a layer lower, in indexing or in URL structure.

Step 1: the Page indexing report

The first question in a store audit isn't about rankings — it's about whether a given product page has any chance of appearing at all. The Page indexing report in Search Console contains information about Google's indexing status for every URL Google knows about on your site, and shows "how many URLs on your site have been crawled and indexed by Google" (Search Console, Page indexing report, read 1 October 2026).

The two main statuses — Indexed and Not indexed — are only the start. For Not indexed, the report gives a specific reason: a server error, a robots.txt block, a noindex tag, a 404, or something else. In a store with a large catalogue, the pattern matters more than any single URL: if dozens of product pages share the same reason for not being indexed — say, the same URL parameter blocked in robots.txt — the problem is structural, not incidental.

The report also has a separate, less critical section covering issues that don't block indexing but limit how well Google can interpret and index your pages — worth checking after the main statuses, not before them.

If this step shows that a meaningful part of the catalogue isn't indexed because of filters and parameters, read the faceted navigation section below (step 4) before moving on — that's where we cover how Google recommends limiting filter indexing.

Step 2: the Core Web Vitals report — when to dig deeper

Next in line is performance. The Core Web Vitals report in Search Console "shows how your pages perform, based on real world usage data," and groups URLs by status ("Poor", "Need improvement", "Good"), by metric (LCP, INP, CLS), and by URL group — for instance, every product page built on the same template. Once a group has enough data for both LCP and CLS, its status is "its most poorly performing metric" — so a single poor metric is enough to mark the whole group as poor (Search Console, Core Web Vitals report, read 1 October 2026).

The data in this report comes from the CrUX report, which "gathers anonymized metrics about performance times from actual users visiting your URL (called field data)" — not from a one-off lab test. That's what separates it from a single run in Lighthouse, which measures a page under controlled conditions; PageSpeed Insights shows both — field data from CrUX and a Lighthouse test score. If the Search Console report shows a problem for a specific group of pages (say, every product page), only then does it make sense to dig into a single page in PageSpeed Insights, to see exactly what's weighing it down.

This "field data first, lab data second" order isn't arbitrary — it's Google's own advice: "Field data is determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users' individual experiences... Lab data is determined by loading a web page in a controlled environment with a predefined set of network and device conditions," and "if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts... it's the most accurate way to really understand what your users are struggling with" (web.dev, lab and field data differences, read 1 October 2026). In practice: don't start an audit with a one-off Lighthouse test of a random page — start with the Search Console report that shows which groups of pages actually have a problem for your real customers, and use lab data only to diagnose what in that page's code is causing the poor score.

We break down the mechanisms that hurt these metrics in a store, with a fix plan and a platform comparison from the HTTP Archive Web Almanac, in our article on Core Web Vitals for ecommerce. If you'd rather start with a one-off test of a specific page, use our website speed test.

Step 3: rich results — product snippet and merchant listing

The third step checks whether Google has enough data to show a product page as more than a plain title and description in search results. Two related rich-result types:

• Product snippet — used "for product pages where people can't directly purchase the product" — gives more room for reviews and detail; it requires structured data with name and at least one of review, aggregateRating or offers.
• Merchant listing — used for "pages where a shopper can purchase a product" — shows size, delivery, return policy, and always includes a price; it requires name, image and offers with a price above zero and a currency. Merchant listings require an Offer, while product snippets also accept an AggregateOffer (Search Central, merchant listing structured data, read 1 October 2026). Google notes "some overlap between the two product features": adding the properties required for merchant listings generally makes a product page eligible for product snippets as well (Search Central, product structured data, read 1 October 2026).

Search Console Help also covers the general rich-result tools: an overview report, an unparsable structured data report and the Rich Results Test. Its Shopping section lists a separate "Merchant opportunities" report, which "shows recommendations for improving how your online shop appears on Google," and a "Shipping and returns" setting under Settings > Shopping, which a store with a Merchant Center account only sees once that account is associated with the Search Console property (Search Console, Shopping reports, read 1 October 2026) — another reason to keep these two accounts linked rather than running them separately.

Missing a required property (say, priceCurrency inside offers) means the page doesn't qualify for that rich-result type — a different issue from the status in the Page indexing report. In an audit, it's worth going through gaps like this together with a developer, because structured data is usually generated by the product page template: one template fix covers every page that uses it.

Step 4: filters, duplicates and canonical URLs — a checklist

This is where a store generates the most URLs, and with them, many of the indexing problems from step 1. Check, in order:

• Faceted navigation. The most common implementation, based on URL parameters, "can generate infinite URL spaces," leading to two effects: over-crawling, because filtered URLs "seem to be novel" to crawlers, and slower indexing of new, useful pages, because crawlers waste time on useless filter combinations. The recommendation: "allow crawling of just the individual items' pages along with a dedicated listing page that shows all products without filters applied," and return an HTTP 404 status code for filter combinations that return no results. Weaker methods — rel=canonical and nofollow on filter links — are "generally less effective in the long term" than robots.txt rules and URL fragments (Search Central, managing faceted navigation, read 1 October 2026).
• Pagination. Each page of a product list should have a unique URL, for example with a ?page=n parameter; don't set the first page of a sequence as canonical for the rest — give each page its own canonical URL. Google "no longer uses" rel="next"/rel="prev" tags, "although these links may still be used by other search engines" — if they're still in your code from a few years back, they don't hurt, but they don't affect Google's indexing either (Search Central, pagination and incremental page loading, read 1 October 2026).
• Product variants (colour, size). Google asks you to "make sure that each variant can be identified by a separate URL" — as a path segment or a query parameter (Search Central, URL structure for ecommerce sites, read 1 October 2026). Google doesn't publish one rule saying "always canonicalise variants to a single base URL" — that's a business decision, depending on whether you want each colour to show up separately in search.
• Duplicates and the canonical URL. Canonicalization is "the process of selecting the representative – canonical – URL of a piece of content," and Google's own list of duplicate sources includes "the results of sorting and filtering functions of a category page" — the most common case in a store. Important caveat: a specified canonical preference "is a hint, not a rule" — Google also weighs "a handful of" other factors, among them HTTP vs. HTTPS, redirects, and sitemap presence (Search Central, what is canonicalization, read 1 October 2026).
• The "duplicate content penalty" myth. Current Google documentation (2026) puts it mildly: "your site will likely do just fine without specifying a canonical preference" (Search Central, consolidating duplicate URLs, read 1 October 2026) — rel="canonical" gives you control and saves crawl budget; it isn't protection against a penalty. The stronger, often-repeated statement that there's no penalty for duplicate content unless it's meant to deceive and manipulate rankings comes from a Google Search Central blog post from September 2008 and is no longer part of current documentation — treat it as historical context, not today's position.

The full explanation of URL structure, pagination, faceted navigation and duplicates in a store, with platform examples, is in our article on ecommerce SEO ranking.

Step 5: product and category content

The fifth step only makes sense once steps 1–4 already show indexed, technically sound pages — otherwise, improving content changes little in search results. Check whether product and category descriptions are "people-first content" — in Google's words, "content that's created primarily for people, and not to manipulate search engine rankings" (Search Central, creating helpful content, read 1 October 2026). If a large share of descriptions is generated automatically at scale with no added value, that's no longer a style question — it's a risk under the "scaled content abuse" policy Google introduced in March 2024.

The full checklist of what a product page should contain — Merchant Center character limits, image requirements, when category descriptions help versus hurt, and how to treat AI-generated content — is in product description SEO.

Step 6: diagnostics in Merchant Center

If a store uses Google Merchant Center — a product feed, free listings, or ads — the audit has to cover that account too, because errors here aren't visible in the standard indexing report. Check:

• product statuses and disapproval reasons — the landing page requirements say the price "should match your product data" and that the page must clearly show the product's availability (Merchant Center Help, landing page requirements, read 1 October 2026);
• policy warnings in account notifications — for some policies, such as unsupported Shopping content, Google states that violations "will not lead to immediate account suspension without prior warning" and that a warning "will be issued at least 7 days prior to any suspension of your account" (Merchant Center Help, unsupported Shopping content, read 1 October 2026) — but you only benefit from that window if you actually check the notifications;
• landing page compliance — a visible price matching the feed, a link to the specific product, nothing covering up the required information;
• the Search Console connection — without it, you won't see the "Shipping and returns" setting under Settings > Shopping.

Setting up a Merchant Center account from scratch, verifying your site and the difference between a feed and structured data are covered in a separate article on Google Merchant Center.

Step 7: do it yourself or hire an audit

There's no reliable, methodology-disclosed public average price for an ecommerce SEO audit in the EU or anywhere else — the reports checked for this research measure entirely different things (SEO specialists' salaries, a shop's visibility in one specific tool's index) or are agency marketing copy with ranges picked to generate leads, not sample-based data. So we don't give a price here — instead, you can go through steps 1–4 above yourself with our self-audit checklist, because they mostly require reading Google's free reports, not specialist tools.

Hiring an audit makes more sense when: the catalogue runs into thousands of URLs and an indexing problem has several overlapping causes at once (filters, variants, a platform migration); when you need help working out which of several simultaneous causes is behind a visibility drop; or when the reports point to a problem but you don't know which specific template or plugin element is causing it — that's work that takes a person's time, not just reading a report.

The practical difference between a checklist and a hired audit is exactly that interpretation step. A checklist says "check the Page indexing report and see if there are errors" — and that's enough to spot a problem. It doesn't tell you what to do next when there are several hundred errors at once, spread across several causes: some pages are blocked by a robots.txt rule added during a previous migration, others still carry a noindex tag left over from a test deployment, and the rest simply have no internal links pointing to them. Separating those causes, deciding which to fix first, and checking that a template fix doesn't break something else on every other page of the same type — that's work an outside specialist does faster than someone looking at these reports for the first time.