Ecommerce SEO Checklist: A Test for Every Item

A checklist without a test is a list of opinions. "Optimise your product titles" cannot be ticked off, because nothing tells you whether you did it or whether it worked. That is the shape of almost every ecommerce SEO checklist ranking today, and it is why store owners work through one, feel productive, and see nothing change in Search Console three months later.

This one is built the other way round. Every item has a command or a report that returns a yes or a no, and the items are ordered by what they cost you to fix. An unindexable collection page costs ten minutes and blocks everything downstream. Rewriting 400 product descriptions costs three weekends and moves nothing if the pages are still blocked.

It is written for the person who runs the store and does the SEO themselves, on Shopify, WooCommerce, BigCommerce or something custom. You do not need an agency to run any of it, and every command below runs in a terminal against a live URL.

Five ecommerce SEO checklists, measured

The five pages holding the top five organic positions for "ecommerce seo checklist" in the United States were read end to end before this article was written. Together they run to roughly 22,000 words.

Not one of the five contains a single line of JSON-LD you could paste into a theme. Not one contains a command that proves an item passed. Two of the five were published in 2023 and still rank, which tells you how little the field refreshes.

The clearest symptom sits at position four. The siteimprove page carries a section heading reading "Parameter handling in Google Search Console". That tool has not existed since April 2022, which is covered below with the announcement date.

Start by finding which layer is broken

Before you touch anything, decide which of four layers is failing, because the fix for each is different and they are not interchangeable. A page can be unreachable, reachable but unindexed, indexed but unranked, or ranked but unclicked.

Search Console answers this in two reports. The Page Indexing report tells you whether URLs are indexed and gives the reason string when they are not. The Performance report, filtered by page, tells you whether an indexed URL earns impressions, and whether those impressions turn into clicks.

Run the split by URL pattern, because a store's problems are almost never uniform across the catalog. Filter Performance by page with a regex that separates the layers:

Page > Custom (regex) > /products/
Page > Custom (regex) > /collections/
Page > Custom (regex) > /blogs?/

If /products/ URLs show impressions and no clicks, the problem is titles and snippets. If they show no impressions at all, the problem is upstream, and the reason strings in the Page Indexing report name it precisely. Treat "Crawled - currently not indexed" and "Discovered - currently not indexed" as different diagnoses, not as the same complaint.

One number is worth writing down before you start: how many URLs the store has, and how many of those you actually want in the index. Most stores cannot answer the second half, and that gap is the whole faceted navigation problem.

Layer one: can Google fetch the page at all

Four commands settle this per URL. Run them against a product page, a collection page, and the homepage, and keep the output.

The status code and the final URL after redirects:

curl -sI -o /dev/null -L \
  -w "%{http_code} %{num_redirects} %{url_effective}\n" \
  "https://example.com/products/merino-crew"

Anything other than a single 200 with zero redirects on a canonical product URL is a finding. A chain of two or three redirects on every product link is common after a platform migration, and it is invisible in a browser.

The canonical and the robots meta tag, as the crawler receives them:

curl -s "https://example.com/products/merino-crew" \
  | grep -Eio '<link[^>]+rel="canonical"[^>]*>|<meta[^>]+name="robots"[^>]*>'

The header-based directive, which never appears in the HTML and is the one people miss:

curl -sI "https://example.com/products/merino-crew" | grep -i "x-robots-tag"

And the robots.txt file, read in full rather than skimmed:

curl -s https://example.com/robots.txt

Two rules about that last file are worth stating plainly. Google's documentation says a robots.txt file is "not a mechanism for keeping a web page out of Google". A disallowed URL can still be indexed on the strength of links pointing at it, showing up without a snippet. And a noindex tag on a page that robots.txt disallows will never be read, because the crawler never fetches the page to see it.

On Shopify, robots.txt is generated for you and can be edited through a robots.txt.liquid template. Shopify's own documentation says it "strongly recommended to use the provided Liquid objects whenever possible", because "the default rules are updated regularly". Replacing the whole file with plain text freezes it at the day you wrote it.

Layer two: collections, filters and pagination

This layer is where stores lose crawl budget, and it is the layer the ranking checklists treat most vaguely. Google's faceted navigation guidance was last updated on 2025-12-18 and it is unusually direct about the mechanisms.

If you do not want filter combinations in search results, the guidance is to "use robots.txt to disallow crawling of faceted navigation URLs". The second supported option is URL fragments, which work because "Google Search generally doesn't support URL fragments in crawling and indexing".

What the guidance explicitly downgrades is the advice you will read everywhere else. On rel="canonical" and rel="nofollow" for filter URLs, Google says these "are generally less effective in the long term". On nofollow specifically, there is a condition almost nobody meets: "Every anchor pointing to a specific URL must have the rel="nofollow" attribute in order for it to be effective." One filter link in a mobile drawer without the attribute undoes the whole scheme.

Test what your store actually emits. Load a collection page, apply two filters, and check whether the result has its own crawlable URL:

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://example.com/collections/tees?color=black&size=m"

A 200 here means the combination is a real page a crawler can reach. Multiply the values in each filter to see how many pages you just created. Three filters with eight, six and five values is 240 URLs per collection, before sort order.

Pagination has its own rule, and it is the item most stores get backwards. Google's ecommerce pagination guidance, updated 2025-12-10, says to "give each page a unique URL. For example, include a ?page=n query parameter". Then it says the thing that contradicts a decade of plugin defaults: "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL."

Check yours in one line:

curl -s "https://example.com/collections/tees?page=2" \
  | grep -Eio '<link[^>]+rel="canonical"[^>]*>'

If that returns a canonical pointing at page one, products that only appear on page two have no indexed home. On a 900-product catalog with 24 per page, that is 876 products relying on the sitemap alone to be found.

The URL structure guidance from the same set is worth one pass too. Google recommends "Add descriptive words in URL paths", prefers ?key=value over bare values, and says to avoid "temporary parameters, such as session-IDs, tracking codes, user-relative values (location=nearby, time=last-week), and the current time".

Layer three: product pages and their markup

A product page has two jobs in search, and the markup only helps with one of them. Structured data does not make a page rank; it decides how the result is drawn once the page already ranks. Google's product documentation states it directly: "Google does not guarantee that features that consume structured data will show up in search results."

The required set is small. For a product snippet, the Product type needs name, plus at least one of review, aggregateRating or offers. For merchant listing experiences the bar is higher: name, image, and a nested offers carrying price (or priceSpecification.price) and priceCurrency in three-letter ISO 4217 format.

Two recommended properties are worth the effort because they change what the result shows. shippingDetails exists to "Share shipping costs, especially free shipping, so shoppers understand the total cost", and hasMerchantReturnPolicy carries "Nested information about the return policies". Here is a complete block using both:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Merino Crew Sweater",
  "image": ["https://example.com/img/merino-crew-1200.jpg"],
  "brand": { "@type": "Brand", "name": "Example" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/merino-crew",
    "price": "89.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "0",
        "currency": "USD"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "US",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

Every type and enumeration above resolves on schema.org. That is worth checking before you ship markup, because plausible-sounding types often do not exist:

for t in Product ProductGroup MerchantReturnPolicy OfferShippingDetails; do
  printf "%s %s\n" "$t" \
    "$(curl -s -o /dev/null -w '%{http_code}' https://schema.org/$t)"
done

If the same garment sells in four colours and five sizes, the variant question arrives next. Google's product variant documentation, last updated 2026-09-08, uses ProductGroup with variesBy, hasVariant and productGroupID, and it accepts exactly six values for variesBy: color, size, suggestedAge, suggestedGender, material and pattern.

The URL rule for variants is the part that breaks stores. When a variant is selected with an optional query parameter, Google's ecommerce URL guidance says to "use the URL with the query parameter omitted as the canonical URL". When all variants live on one page, "There must be only one distinct canonical URL for the overall ProductGroup that all variants belong to". A deeper treatment of which query families a product page can realistically win is in the product page SEO article.

Extract what your theme is currently emitting before you add anything:

curl -s "https://example.com/products/merino-crew" \
  | python3 -c "import sys,re,json
html = sys.stdin.read()
for block in re.findall(r'<script[^>]+application/ld\+json[^>]*>(.*?)</script>', html, re.S):
    try:
        data = json.loads(block)
    except Exception as e:
        print('INVALID JSON-LD:', e); continue
    items = data if isinstance(data, list) else [data]
    for item in items:
        print(item.get('@type'), '->', sorted(item.keys()))"

Most themes already ship a Product block. Adding a second one by hand is how stores end up with two conflicting prices on one page.

Layer four: the pages your catalog cannot be

A catalog can only answer queries that name a product or a category. Everything else a buyer types before they know what to buy has nowhere to land, and this is the single largest untapped surface on most stores.

Google's ecommerce structured data guidance, updated 2025-12-10, names the types that matter beyond products: BreadcrumbList "To help Google understand the hierarchy of pages on your site", Organization for business details including return policies, and Review and VideoObject where they apply. The reasoning it gives is the point: "shoppers may be at different stages in their shopping journey and looking for more than just product pages".

Which query families a store can actually win with content, and which are a waste of a weekend, is worked through in content marketing for ecommerce. If you have decided to publish and need the topics themselves, ecommerce blog ideas covers how to derive them from your own product data rather than from a list of formats.

For a store that already has an archive, the audit comes before the writing. Sorting existing posts into keep, update, merge and delete is covered in the content audit article, and it usually removes more pages than it adds.

Five items Google retired that are still on the checklists

Each of these appears on at least one page currently ranking in the top ten for this keyword. Each has a dated, first-party correction.

1. Configure URL parameters in Search Console. The URL Parameters tool was deprecated on 28 March 2022 with one month's notice, so it has been gone since April 2022. Google's reason was blunt: "only about 1% of the parameter configurations currently specified in the URL Parameters tool are useful for crawling". The replacement named in the announcement is "robots.txt rules".

2. Add rel="next" and rel="prev" to paginated collections. Google's current pagination page says plainly: "Google no longer uses these tags, although these links may still be used by other search engines." Harmless to keep, pointless to add, and not a checklist item.

3. Canonicalise page two to page one. Covered above, and it is the inverse of Google's stated guidance. It is worth a separate line here because plugin defaults still do it silently.

4. Control filter URLs with canonicals and nofollow. Google's own words are that these "are generally less effective in the long term" than robots.txt or fragments. Use them if you like, but do not tick a box that says the crawl problem is solved.

5. Publish an AI text file so you appear in AI Overviews. Google's AI features documentation, updated 2025-12-10, says: "You don't need to create new machine readable files, AI text files, or markup to appear in these features." The eligibility rule is the ordinary one: "A page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements."

That fifth item has a measurement consequence worth knowing. Traffic from AI features is "included in the overall search traffic in Search Console", reported in the Performance report under the Web search type, so it is not a separate number you can isolate by default. What can be measured, and how, is covered in answer engine optimization.

Speed, at the percentile Google actually uses

Three metrics, three thresholds, and one detail that changes how you read them. Largest Contentful Paint should occur within 2.5 seconds. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should be 0.1 or less.

The detail is the percentile. Assessment happens "at the 75th percentile of page loads, segmented across mobile and desktop devices". Your laptop on office wifi is not the 75th percentile of a store whose buyers are on phones, which is why a lab score of 98 sits next to a failing field assessment without contradiction.

For a store, the usual culprits are ordered and boring. Hero images served larger than they render, a carousel that shifts the page as it initialises, and four analytics scripts loading before the product image. Fix in that order, and measure with field data rather than a single lab run.

The hours each of these tasks actually costs a non-specialist are itemised in DIY SEO for small business, which is the honest comparison point before anyone quotes you for the same work. If you are weighing that quote, what SEO costs breaks down the line items.

The checklist, in the order that costs least

Work down this list. Do not start item four before item one returns a clean result, because items four onwards only pay off on pages that are reachable.

1. curl -sI -L every page template. Confirm one 200, zero redirects, no X-Robots-Tag: noindex.
2. Read robots.txt in full. Confirm nothing you want indexed is disallowed, and that nothing disallowed carries a noindex you expect to work.
3. Confirm the canonical on each template is self-referencing, and that page two of a collection is not canonicalised to page one.
4. Count the URLs your filters can generate. Decide which combinations you want crawled, and disallow the rest in robots.txt.
5. Confirm every paginated page has a unique URL with a ?page=n style parameter and a crawlable link to the next page.
6. Check the sitemap returns the URLs you decided to keep, and nothing you just disallowed.
7. Extract the JSON-LD your theme emits. Confirm name, image and a valid offers with price and priceCurrency.
8. Add shippingDetails and hasMerchantReturnPolicy if free shipping or free returns are true for you.
9. If products have variants, decide the URL pattern first, then add ProductGroup with variesBy.
10. Split the Performance report by /products/, /collections/ and content URLs. Note which layer has impressions without clicks.
11. Rewrite titles only for URLs that already earn impressions. Everything else is guessing.
12. Measure the three Core Web Vitals in field data, at the 75th percentile, on mobile.
13. Decide which pre-purchase queries your catalog structurally cannot answer, and plan pages for them.

Items one to six are a morning and they unblock everything else. Items seven to nine are an afternoon in a theme file. Items ten to thirteen are the ongoing work, and they are the only ones that need a calendar.

On timing: none of this produces a schedule you can promise. Crawling, indexing and ranking each move on their own clock, results will vary by store and by market, and no one can guarantee a position. How long SEO takes sets out which of those gates are actually datable in Search Console, and which are not. What the checks above buy you is the ability to tell a real problem from a waiting game, which is a different and more useful thing than a forecast.

Running this by hand once is a morning. Running it every month across a growing catalog is where people quit, and which parts of it can honestly be scripted is worth reading before you build anything. If the store is new and the question is where any traffic comes from at all, start with how to get traffic to your website instead of a technical audit.

FAQ

How do you do SEO for an ecommerce site?

In four layers, in order. Make the pages fetchable and indexable, control which filter and pagination URLs exist, get the product markup right, then build the pages your catalog cannot be. Most stores invert this and start on product descriptions, which is work done on pages that may not be indexed.

What are some good SEO checklists to use?

Judge one by whether its items can be verified. If an item cannot be turned into a command, a Search Console report or a number, it is advice rather than a checklist line. The checklists ranking for this query are largely unverifiable in that sense, and two of the top five still carry advice about a Search Console tool removed in April 2022.

What is the 80/20 rule in SEO?

It is a borrowed heuristic, not a Google concept, and on a store it usually means indexability and site structure account for most of the outcome while on-page copy accounts for the rest. It is useful as an ordering principle and it is not a measured ratio. Nobody has published a real distribution, so treat any specific split as invented.

What are the 5 C's of ecommerce?

They are a retail business framework (commonly company, customers, competitors, collaborators and climate, with variations), not a search concept. They appear in this SERP because the query shares vocabulary, not because they affect indexing. If you came for that, it will not help your rankings either way.

How often should I run an ecommerce SEO audit?

Layers one and two whenever the theme, platform or URL structure changes, because those are the events that break them. Markup when you add a product type. The Performance report split monthly, since that is the report that tells you whether anything you did was worth doing.

Do I need Search Console access to use this checklist?

The curl checks in layers one to three run against any public URL without access. Everything involving impressions, clicks and indexing reasons needs verified Search Console access to the property, and there is no substitute for it. Verify the property first if you have not.