Ecommerce SEO: why it is not the same as normal SEO

A marketer who has spent a few years doing SEO on a content site moves into ecommerce and reaches for the same playbook: audit the pages that already rank, rewrite the weak ones, get a handful of links, watch positions climb. Three months in, rankings are flat and Search Console has started flagging duplicate content on URLs nobody remembers creating: filtered category pages with three colour options and a price range stacked on the end. The playbook assumes something that is only true on a content site: that every indexed page exists because someone decided to write it. That assumption is what breaks first on a catalogue.

Ecommerce SEO (search optimisation for a store, where most URLs are generated automatically from product and category data rather than written by a person) is a different discipline from content-site SEO, not a harder version of it. On a blog or a marketing site, every page exists because someone chose to publish it, so the work is mostly about making individual pages better. On a store, most pages exist because a platform combined a product with a variant, a category, or a filter, so most of the work is deciding which of those combinations deserves to be in the index at all. This article covers why crawl budget behaves differently once a catalogue gets large, how product and category pages answer different questions, the thin and duplicate product page problem, out-of-stock handling, internal linking on a large catalogue, faceted navigation and index bloat, and where content-marketing SEO advice does and does not transfer.

If that is you, someone who has run SEO on a content site, a blog, a SaaS marketing site, a publisher, and has just inherited a store, the rest of this article works through where the two disciplines actually diverge, not how to configure canonical tags or structured data.

Who decided each page should exist, and why it matters more than anything else

On a content site, the number of pages roughly equals the number of decisions someone made to publish something. On a store, the number of pages is closer to products multiplied by variants, multiplied by every category a product sits in, multiplied by every filter combination a shopper can apply. A catalogue of 800 products with three sizes and four colours already implies close to 10,000 variant URLs before a single category or filter is layered on top, and nobody sat down and decided any one of those combinations should exist.

The first thing I check on a catalogue I have just inherited, before touching a single page, is how many of its URLs were a deliberate publishing decision and how many are just what the platform generated because the data allowed it. Content-site SEO optimises the first kind. Ecommerce SEO has to sort the two apart before it can do anything else with either.

Crawl budget: rarely the problem on a blog, real on a catalogue

Google's own guidance on this is specific about scale. Its crawl budget management guide is aimed at "large sites (1 million+ unique pages) with content that changes moderately often" and "medium or larger sites (10,000+ unique pages) with very rapidly changing content." Google is explicit that these are rough estimates rather than exact thresholds, and that a site whose pages get crawled the same day they are published does not need to think about crawl budget at all.

(source: https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)

A 40-post blog will never cross that line. A catalogue with variant and filter URLs can cross it faster than the product count suggests, because every sort order and every filter combination is technically a new URL Googlebot can find and crawl. When that happens, Googlebot spends part of its visit re-crawling filter permutations of a category page instead of finding the products added last week. I have seen this on catalogues well under the 10,000-page mark once filters and pagination are counted properly, which is the detail most marketers moving from content sites miss: the product count on the page is not the URL count Google actually sees.

Product pages and category pages answer different questions

Content-site SEO usually optimises one kind of page against one kind of intent, an article against an informational query. Ecommerce has two page types doing structurally different jobs, and treating them the same is a common and avoidable mistake.

A product page answers "should I buy this specific item": one SKU, one price, one set of specs, one stock status. A category page answers "show me what's available": it is a comparison and navigation page, and its job is to help someone narrow down, not to convert on the page itself.

The mistake shows up as product pages padded with generic descriptive paragraphs that read like blog content, while the buying signals (price, stock, delivery, reviews) sit further down the page than the search intent justifies. On 18 Carati, the jewellery catalogue we run SEO for on Magento, price, certification and stock status are the elements we've pushed toward the top of the product page, with the descriptive copy doing its work further down, not the other way round.

Optimising every product page instead of deciding which should exist

Someone with a content-site background who inherits a catalogue usually falls into the same trap, one I've watched play out repeatedly: they treat every product page as a page to optimise (a better title tag, a better meta description, a paragraph of unique copy) when the first decision is actually whether that page should be indexed at all.

A catalogue with heavy variant duplication, forty near-identical URLs sharing one manufacturer description because they differ only by size or colour, does not get better by writing forty better titles. It gets better by deciding which of those forty URLs is the version worth ranking, and either canonicalising, consolidating, or noindexing the rest. Content-site SEO has no equivalent decision to make, because a content site does not generate near-duplicate pages automatically.

Out-of-stock pages: a problem content SEO does not have

A blog post does not go "out of stock." A product does, and what happens to that URL next has no clean parallel in content-site SEO.

Google's structured data documentation for products includes an availability property specifically so a page can be marked in stock, out of stock, or preorder without removing it (source: https://developers.google.com/search/docs/appearance/structured-data/product). In practice the decision is really about the product, not the page: if the item is likely to come back, I leave the URL live, mark it out of stock in the schema, and show genuinely similar alternatives rather than an empty page. If it is genuinely discontinued, the page has done its job and either gets redirected to the category it sat in, or is allowed to 404 once it stops earning impressions. What I would avoid either way is the default a lot of platforms ship with: silently pulling or unpublishing the page the moment stock hits zero, which throws away a URL that may still have rankings and demand behind it.

Internal linking works differently once it is mostly automated

On a content site, internal links are placed by a person: this article links to that one because the connection is useful. On a store, most internal links come from navigation, breadcrumbs, and a related-products widget generated by the platform, not chosen by anyone.

I have pulled the internal-links report on more than one catalogue and found the opposite of what the client expected: a generic related-products block spreads link equity evenly across the whole catalogue instead of concentrating it on the pages that should actually rank: the best sellers, the categories with real search demand. The fix is not more links, it is more deliberate ones: category pages should link down into the subcategories and products that deserve the traffic, not whatever the algorithm decided is "related" by attribute match.

Faceted navigation is usually the largest source of index bloat

Filters (colour, size, price range, material) are one of the quickest ways a store multiplies its own URL count, and Google's own documentation names this specifically: duplicate content commonly comes from "site functions: for example, the results of sorting and filtering functions of a category page" (source: https://developers.google.com/search/docs/crawling-indexing/canonicalization). Google also states plainly that duplicate content is not a spam violation, but that multiple URLs for effectively the same page still hurt crawl efficiency and split whatever signals the real page should be accumulating.

The judgement is not "index every filter" or "noindex every filter." Some filter combinations have genuine, searchable demand of their own, a carat range on a jewellery site, a colour on a fashion category, and blanket-canonicalising those back to the parent throws away real traffic. Most combinations, three filters stacked together, do not, and should canonicalise to the unfiltered category. That decision has to be made filter by filter against real search demand, not applied as one rule across the whole catalogue. It is worth remembering that Google treats the canonical tag as a hint rather than an instruction, so even a well-reasoned canonicalisation strategy is a strong signal, not a guarantee.

Where content-marketing advice does and does not transfer

Most of what content-site SEO teaches, write more, get links, improve topical depth, assumes the indexation problem is already solved. On an unmanaged catalogue it is not, so content work stacked on top of it is decorating a house with a structural problem: it can make the visible parts look better without fixing why the site is not ranking. I have seen a client commission a full buying-guide programme while forty near-duplicate variant pages sat unresolved underneath it: the guides ranked fine, the product pages did not move.

Content marketing still has a real place on a store. Buying guides, comparison pages, and size or care content sit outside the product catalogue entirely and behave exactly like content-site pages, because they are hand-written pages answering informational intent rather than platform-generated pages answering transactional intent. The distinction that matters is which bucket a given page is in, not whether "more content" is the answer.

When this framework is the wrong one to reach for

A catalogue of a few hundred SKUs, hand-curated, with no meaningful filter or variant explosion, does not need any of this. If every product page is a deliberate, distinct listing and there is no faceted navigation generating extra URLs, the standard content-site playbook, better copy, better titles, a few genuine links, is close enough to the whole job. Building an elaborate canonicalisation strategy for a catalogue that size is solving a problem that does not exist yet.

The other case where this changes shape is a headless build. On Periodico, the storefront we built as a headless Next.js front end on Shopify, canonicalisation and collection-page rendering are things we control directly in code rather than working around whatever a theme decides. That removes a lot of the automatic duplication a themed platform generates by default, though it replaces it with a different job: making sure the custom logic actually does what a good theme would have done anyway. Which of these limits are genuinely platform defaults and which are just an unmanaged-catalogue problem varies by platform, which is the split our platform-by-platform comparison covers.

What to check first if you have just inherited a catalogue

Before writing a single new product description, compare how many URLs Search Console and the XML sitemap think exist against how many products are actually sold. In my experience a gap of roughly ten times or more means variants and filters are generating pages nobody decided to create, and that gap, not the copy, is where the real work starts. Our ecommerce SEO audit checklist walks through that check in the order that actually finds it, and once the indexation picture is clear, building the strategy around it is the next decision.

If you want a second read on where a specific catalogue's indexation is leaking, that is the first thing we look at in an SEO audit at BYLT, and it is most of what an ecommerce SEO engagement actually does before any content work begins.