Ecommerce SEO (What’s Actually Different From Regular SEO)

Ecommerce SEO gets treated like regular SEO with a shopping cart attached, and that assumption is what tanks category rankings once a store passes a few hundred SKUs. The real difference is scale: faceted navigation, product variants, and stock changes create URL and duplicate-content problems a five-page brochure site never runs into. This post covers what actually changes at real product volume: faceted navigation, canonical versus noindex calls, product schema, and pages for products that no longer exist.

What Actually Makes Ecommerce SEO Different

Ecommerce SEO is regular SEO applied to a catalog that can run from a few hundred product pages to several hundred thousand, generated dynamically from a product feed rather than written one page at a time. That volume is the actual difference – a blog with fifty posts never generates the kind of URL sprawl a mid-sized store creates from color, size, and price filters alone.

The problems that actually define ecommerce SEO are almost all URL-architecture problems, not content problems – duplicate content from faceted navigation, thin or near-empty filtered pages, product data that needs structured markup to be understood at scale, and inventory that changes weekly instead of yearly. Writing better product descriptions matters, but it’s rarely the highest-leverage fix on a site with an architecture problem underneath it.

I’ve audited SaaS platforms with feature-comparison pages that hit the exact same faceted-navigation pattern ecommerce sites do, just dressed up as feature filters instead of size and color options. The mechanism is identical: a filter creates a new URL, the new URL gets crawled, and if nothing manages that process, crawl budget goes to filter combinations instead of the pages actually meant to rank.

Most of that URL volume doesn’t come from someone building pages by hand – it comes from a product feed or a PIM (product information management) system pushing thousands of SKUs through a handful of shared templates. That’s efficient for the business, but it also means a single template bug or a badly configured filter duplicates the same problem across an entire category at once, not just one page.

Faceted Navigation Is the Root of Most Ecommerce Crawl Problems

Google’s own documentation on canonicalization names the exact mechanism: duplicate content commonly stems from a category page’s sorting and filtering functions. That’s faceted navigation in one sentence – a category page with five filter dimensions and several values each can generate thousands of unique URLs showing near-identical product grids.

Each of those URLs gets crawled unless something stops it, and on a large catalog that adds up to real crawl-budget waste – Googlebot spending its daily allowance on `?color=red&size=medium` instead of the pages actually meant to rank. The size of the problem scales with the number of filter dimensions, not the number of products – five filters with four values each is already over a thousand possible combinations from a single category page.

Holistic SEO’s own guide on duplicate content makes the same point from the crawl side: unmanaged paging and faceted navigation causes what it describes as a rapid ranking decline once crawl quota gets exhausted on combinations nobody actually searches for, rather than the canonical category and product pages that need the crawl budget most.

Pagination compounds the same issue – a category with forty products and twenty per page creates a second and third page of the same core content, each a legitimate thin-content flag if nothing on that page is framed differently from page one. Google retired its URL Parameters tool in Search Console back in 2022, which means canonical tags, robots.txt, and internal linking are now the only real levers left for telling it which parameter combinations matter.

Internal site search is the other classic case: a `?q=blue+shoes` search-results URL that ends up linked externally or picked up from a stray sitemap entry can end up competing with the real category page for the same query. Blocking internal search URLs in robots.txt outright is a five-minute fix I still find missing on stores that have been live for years.

Search Console’s crawl stats report is the fastest way to check whether any of this is actually happening on a given site – a crawl-request count wildly disproportionate to the number of indexed pages, or a crawled-but-not-indexed count that dwarfs the indexed one, is almost always faceted or parameter URLs on a catalog of any real size.

Canonical Tags, Noindex, and Robots.txt: Picking the Right Fix

Three mechanisms fix faceted-navigation duplication, and picking the wrong one for the wrong URL pattern is the most common ecommerce technical mistake I come across. None of the three is universally correct – the right choice depends on whether the filtered page has any independent search demand of its own.

Approach	What it does	Use it when	Risk if misused
Canonical tag	Signals the preferred version, but the filtered URL still gets crawled	The filter has zero independent search demand (e.g. a sort-order parameter)	Google treats it as a hint, not a rule – and it doesn’t save crawl budget on its own
Noindex, follow	Removes the page from the index, still passes internal link equity through	The filter has some browsing value but no ranking need (e.g. a single mid-tier size filter)	The page still gets crawled every time – same crawl-budget cost as a canonical
Robots.txt disallow	Blocks the URL pattern from being crawled at all	High-volume, low-value multi-filter combinations that need neither indexing nor crawling	Google can’t see a canonical or noindex tag on a blocked page, so never stack those directives on the same URL pattern

My rule of thumb, tested across a handful of large catalogs: single-filter pages with genuine standalone search volume – a specific brand or color as its own landing page – get a real, unique page and a self-referencing canonical, sometimes their own short piece of category copy. Multi-filter combinations with no search demand get blocked in robots.txt outright, not noindexed, because noindex still costs a crawl every time Googlebot revisits it.

A pattern I run into constantly: a store correctly canonicalizes every color-filtered URL back to the base category page, then undermines it by linking to those same filtered URLs from a shop-by-color widget or a size guide anyway. A canonical tag fixes indexing, not crawling – if a filtered URL isn’t meant to exist independently, don’t link to it from anywhere on the site either.

Category and Product Page Content That Actually Ranks

A category page with nothing but a product grid and zero unique text above it is the single most common thin-content flag I find on ecommerce audits, even on sites with genuinely good products. Google still needs text to understand what a category is about beyond the product titles pulled from a feed.

Title tags and heading structure work the same way on a category page as anywhere else, just at a hundred times the scale – I’ve covered the mechanics of that in more depth in a separate breakdown of the on-page elements that actually move rankings, and every rule there applies to a templated category page just as much as a hand-written blog post.

The practical fix I use most often: 150-300 words of genuinely useful category copy – what the products are for, how to choose between the main variants, a buying consideration specific to that category – placed above or beside the product grid, not buried in a collapsed accordion nobody reads and search engines weight less.

Matching Category and Product Pages to the Right Search Intent

Category and product pages compete for different search intent, and conflating them is a common cause of ecommerce keyword cannibalization. A broad term like “running shoes” belongs to the category page – a browsing, comparison-stage query – while a specific model name belongs to the product page, where someone already decided what they want.

The clearest sign of cannibalization on an ecommerce site is a best-selling product page outranking its own category page for the broad category term, which usually means the category page’s own text and internal-linking signals are weaker than a single product buried under it. Strengthening the category page itself, rather than fighting the product page’s ranking, is almost always the right fix.

Long-tail, attribute-specific terms – “waterproof running shoes size 11”, “blue leather running shoes” – are where a filtered page, when it’s allowed to be indexed at all, can genuinely compete, since nobody searches the broad and the attribute-specific version for the same reason. That’s the real test for whether a filter combination deserves its own indexable page: does it match a distinct search intent, not just a real product attribute.

Internal Linking Between Category and Product Pages

Internal linking works differently on a catalog site than on a blog, because most links between pages are template-generated – breadcrumbs, related products, category navigation – rather than placed by hand inside body copy. The templates themselves are the internal-linking strategy, so a weak template affects every page built from it at once.

Breadcrumb navigation is the single highest-value template-generated internal link on an ecommerce site, because it gives users a path back to the category and gives Google an unambiguous signal about where a product sits in the site’s topical hierarchy. Breadcrumb schema markup makes that hierarchy explicit in the search snippet too, often replacing the raw URL a searcher would otherwise see.

Related-product and similar-items modules are worth auditing for one specific failure: if they render client-side after the page loads and never appear in the initial HTML, a crawler that doesn’t execute that JavaScript never sees them, and the internal links inside do nothing for SEO even though they look identical to a shopper. Rendering those links server-side, or at least including them in the initial HTML response, is the fix.

Multi-Currency and Multi-Region Ecommerce SEO

This is where ecommerce SEO overlaps directly with the international-market work I do across iGaming, SaaS, and Fintech, and it’s worth calling out because most ecommerce SEO advice ignores it entirely. A currency switcher that changes prices via JavaScript without changing the URL shows Googlebot the exact same page and currency for every region, no matter how many currencies a shopper can select from the dropdown.

The fix is the same one that applies to any multi-market site: separate, crawlable URLs per region or currency – subdirectories or ccTLDs, not a client-side toggle – connected with hreflang tags. Without that, Google indexes one version, usually whichever currency the server defaults to for its own crawl location, and every other region’s pricing stays invisible to search.

In my experience, this is the most common gap on ecommerce sites expanding into new markets: a new currency option gets added in a sprint, and the fact that it needs its own indexable URL structure, not just a dropdown, never makes it into the same conversation. This isn’t only a ranking issue – a shopper who lands on a page still priced in USD after searching in their own language and currency assumes the store doesn’t actually ship to their market, and bounces before finding out otherwise.

Product Schema and Structured Data

Product pages are one of the clearest cases where structured data earns its keep: Product, Offer, and AggregateRating schema tell Google the price, availability, and rating explicitly, instead of leaving it to infer that from a page template that might change without warning.

Product schema with a price or availability field that doesn’t match what a shopper actually sees on the page is a trust violation Google’s own guidelines call out directly, not a minor technicality – the same principle I’ve written about for schema generally in a full breakdown of how to implement structured data correctly.

On a catalog with automated price feeds, this is where I see the most drift: a caching layer or a stale feed sync leaves the schema showing yesterday’s price or an in-stock status for something that sold out an hour ago. Whatever generates your product pages should pull schema values from the same live source as the visible price, not a separately cached copy.

This matters beyond organic search too – if you also run Google Shopping campaigns, Merchant Center pulls from the same product feed that should be feeding your schema, and a mismatch between the two shows up as a disapproved listing in Merchant Center before it ever shows up as a ranking problem in organic search. Treating the feed as the single source of truth for both channels catches drift earlier.

Review and AggregateRating schema carry the same requirement FAQ schema does: the reviews being marked up have to actually be visible on the page, not aggregated from a separate reviews platform and stamped onto a page that shows nothing itself. Markup without matching visible content is a policy violation in Google’s own guidelines, not a gray area worth risking.

What to Do When a Product Goes Out of Stock or Gets Discontinued

This is a problem regular SEO doesn’t have, and most stores handle it badly by default. A temporarily out-of-stock product should almost never return a 404 or get deleted – the page usually still has backlinks, indexed history, and search demand attached to it, and killing it throws all of that away for what might be a two-week restock.

For genuinely discontinued products, a 301 redirect to the closest replacement or the parent category is the right move, not a blanket redirect to the homepage. A homepage redirect tells Google nothing about relevance and reads as a soft 404 to a shopper who clicked a specific product link expecting that product.

What I actually recommend, in order: keep temporarily unavailable products live with clear back-in-stock messaging and, where genuinely relevant, links to close substitutes; redirect permanently discontinued products to the nearest real replacement; only redirect to a category page when no single product is a close enough match to justify a direct substitute.

An out-of-stock page with no price, no add-to-cart button, and no alternative products reads to a crawler like a not-found state even with a 200 status code, which is exactly what Google’s systems classify as a soft 404. A clear message, a restock estimate where you have one, and links to two or three close substitutes avoids that classification entirely.

Page Speed and Crawl Efficiency at Scale

Everything in what actually moves Core Web Vitals scores applies to ecommerce, but image-heavy product galleries and third-party review/chat widgets make it a harder problem to solve here than on a typical content site.

Crawl depth matters more on a large catalog than most site owners realize – if a product page sits six clicks deep from the homepage through a category-then-filter path, it gets crawled less often and discovered slower after any change. I’ve fixed this on catalogs by adding a small number of well-placed cross-category links rather than restructuring navigation entirely.

Unmanaged faceted URLs quietly drag down Core Web Vitals field data too, since real-user measurement covers every page visitors actually load, filtered variants included, not just the canonical ones you’d prefer Google judge the site by. A slow filter combination nobody optimized for still counts against the aggregate.

Segmented XML sitemaps, split by category rather than one giant sitemap file, make it far easier to spot indexing gaps in Search Console – a category with a coverage report full of errors is immediately visible instead of buried in a single 50,000-URL file. This is standard crawl-budget hygiene I covered in more depth in how crawl budget and indexing actually work, and it matters more here because the URL count is so much higher.

Mobile matters more on a catalog site than on a typical content site too, since most retail traffic and Google’s own indexing are mobile-first. The mobile version of a product page needs the exact same schema, price, and availability as desktop – a stripped-down mobile template missing structured data is invisible to the mobile crawl that increasingly is the only crawl that counts.

A Practical Ecommerce SEO Checklist

When I audit a store, this is roughly the order I go through:

• Are single-value filters with real search demand getting their own indexable page, and are multi-filter combinations blocked in robots.txt?
• Does every category page have unique text beyond the product grid, not just inherited product titles?
• Does Product schema pull price and availability from the same live source as the visible page, not a stale cache?
• Are out-of-stock products kept live with clear messaging instead of 404ing or redirecting to the homepage?
• Is the XML sitemap segmented by category so indexing gaps are visible in Search Console?
• Can every product page be reached in three clicks or fewer from the homepage?

Most stores fail on the first two items specifically – faceted navigation left unmanaged, and category pages with nothing but a grid. Both are architecture fixes, not content rewrites, which is exactly why they get skipped in favor of writing more product descriptions that were never the actual problem, and exactly why they’re usually still unresolved the next time I re-audit the same site a year later.

Where I’d Start

If I only had time to fix one thing on an ecommerce site, it would be the faceted-navigation strategy before anything else on this list – it’s the single highest-leverage fix because it’s usually costing crawl budget on every category page at once, not just one page at a time. The multi-currency gap runs a close second for stores actually operating in more than one market – it stays invisible until you check whether non-default-currency pages exist as real, crawlable URLs at all, and on most stores they don’t.

Ecommerce SEO isn’t a different discipline from the SEO fundamentals that apply everywhere else. It’s the same fundamentals under enough URL volume that mistakes invisible on a five-page site become the reason a five-thousand-product catalog can’t get its best category pages crawled, let alone ranked. Fix the architecture first, and the content work you were already planning to do actually has somewhere to land.