E-Commerce SEO: Category Pages, Product Pages, and Faceted Navigation

Architecture Decides Your Ceiling Before Content Decides Your Rank

E-commerce SEO has a different shape than SEO for a service business. A law firm ranks or doesn’t rank a dozen pages; a store ranks or doesn’t rank thousands, almost all generated from two or three templates. You don’t win by hand-optimizing individual pages — you win by getting three structural decisions right: how category pages are built, how the product template behaves at scale, and what happens to the URL space when shoppers start filtering.

Those decisions interact. A great category page buried under a broken faceted navigation won’t get crawled often enough to matter. Every audit we run on an underperforming store traces back to one of these pillars — and usually to the fact that nobody made the decision deliberately; the platform made it by default. Shopify decides your URL structure for you (every product under /products/, every collection under /collections/). WooCommerce decides almost nothing, which is its own trap: a default install plus a page builder plus a filtering plugin produces a URL space nobody designed.

This article works through the pillars in order of commercial weight, then the supporting layer: structured data and merchant feeds, duplicate descriptions, out-of-stock handling, and the internal links that connect content to commerce.

Category Pages Are the Real Money Pages

The instinct is to treat product pages as the heroes — they’re where the buy button lives. But look at what people actually search. Someone typing a full product name into Google already knows what they want, and that query is usually dominated by the brand itself and the big marketplaces. The winnable volume sits one level up: “waterproof hiking boots,” “mid-century walnut dresser.” Those are category queries, and for most stores we work on, category and collection pages have a higher organic ceiling than every product page combined.

Treat them accordingly. A category page that’s nothing but a product grid and a paginated footer is a thin page wearing a commercial keyword. The pages that rank carry more: a title and heading that match how people search rather than internal taxonomy (“Hiking Boots” beats “Footwear › Outdoor › Boots — Page 1”), copy that genuinely helps a buyer choose — fit, materials, what separates the sub-types — and links to adjacent and child categories so the page sits inside a visible hierarchy. The copy should read like a knowledgeable shop assistant, not a keyword deposit: a short intro up top, deeper buying guidance below the grid, products still above the fold on mobile.

The other category decision is granularity. Every distinct way customers search is a candidate for its own indexable category: not just “dressers” but “walnut dressers” if the query exists and you have the inventory. On Shopify that means real collections; on WooCommerce, product categories and attributes promoted into landing pages deliberately. The test is honest demand plus honest depth: search volume you’ve verified, and enough products that the page isn’t three items and an apology.

Product Pages: You’re Optimizing a Template, Not a Page

With a catalog of any size, you will never hand-write SEO for every product page, and you shouldn’t try. The leverage is in the template. Get one decision right and it multiplies across two thousand URLs; get it wrong and it multiplies the same way.

Start with the title pattern. The product name alone is rarely how anyone searches, so the template should assemble titles from the attributes buyers actually use — brand, product name, the one or two attributes that disambiguate (size, material, pack count) — in a consistent order. Same for meta descriptions: a pattern built from real fields beats both an empty tag and duplicated boilerplate.

Then variants, the classic template fork. A shirt in five colors can be one URL with a color picker, or five URLs. The default answer is one URL per product, because it concentrates signals instead of splitting them five ways. The exception is when people search for the variant itself — “green velvet sofa” is its own query with its own demand, and a variant with its own search market can earn its own indexable URL, title, and copy. Shopify’s variant model handles the consolidated case natively; the moment an app generates separate indexable URLs per variant, you’ve made the exception your default, usually without noticing.

Finally, the parts of the template that aren’t words: a stable URL that doesn’t change when the product gets recategorized (Shopify’s collection-prefixed product URLs canonicalize to the bare /products/ URL for exactly this reason — don’t fight it), unique photography with descriptive alt text, and reviews. Customer reviews and Q&A are the only scalable source of unique, query-matching text on a product page, which makes a review program a content strategy, not just a trust widget.

Faceted Navigation: The Crawl Trap Hiding in Your Filters

Faceted navigation — the sidebar of filters for size, color, brand, price — is the single most common way stores destroy their own crawl efficiency. The math is the problem. Ten brands, eight sizes, six colors, four price bands, plus sort orders and pagination, and one category page mints tens of thousands of URL combinations, nearly all near-duplicates of each other. Google will happily spend its crawl budget wandering through them instead of revisiting the pages that make you money.

The symptoms show up in Search Console first: indexed-page counts wildly above your real catalog size, important pages stuck in “Discovered — currently not indexed,” crawl stats dominated by parameterized URLs. WooCommerce’s default filter widgets produce exactly this with query strings; on Shopify, filtered collection URLs and tag pages multiply the URL space the same way.

The fix starts with a sorting exercise, not a tool. Walk through every facet and put it in one of three buckets. Bucket one: facets that map to real search demand — “nike running shoes,” “leather office chairs.” These deserve to be indexable: a clean URL, a unique title, ideally a line of unique copy — effectively a category page generated by a filter. Bucket two: facets that help shoppers but have no search market — price sliders, sort orders, in-stock toggles, most multi-facet combinations. These should exist for users and be invisible to crawlers. Bucket three: combinatorial junk, the three-filters-deep permutations no human ever lands on from search. These shouldn’t be crawlable at all.

Most platforms’ defaults put everything in bucket two’s gray zone and let Google sort it out. Google sorts it out badly. The bucket assignment is the strategy; the next section is the toolkit for enforcing it.

The Toolkit: Canonical, Noindex, and Robots.txt Do Different Jobs

Three tools control what happens to filtered and parameterized URLs, and they are not interchangeable. Most faceted-navigation messes come from using the wrong one — or all three at once on the same URL, which sends contradictory signals.

The canonical tag is a consolidation hint. A filtered URL canonicalized to its parent category tells Google “treat my signals as belonging to that page.” It’s the right tool for bucket two: sort orders, view options, single facets with no search demand. Two caveats. It’s a hint, not a directive — Google ignores canonicals when the pages differ too much. And canonical tags don’t save crawl budget: Google still has to fetch the URL to read the tag.

Noindex is an eviction notice: the page can be crawled but won’t be indexed. It’s the cleaner answer when canonical hints get ignored, and the right tool for pages that must exist but should never rank — internal search results being the classic example. It carries the same trade-off: noindex only works if the page is crawled, so it spends crawl budget rather than saving it. And a long-term noindexed page eventually gets crawled less and its links counted for less, so don’t noindex anything whose internal links you’re relying on.

Robots.txt is the only tool that actually saves crawl: disallowed paths don’t get fetched at all. That makes it the right answer for bucket three, typically by disallowing the parameter patterns that mark multi-facet URLs. The trade-off is bluntness: a blocked URL can still appear in the index as a bare URL if something links to it, and Google can’t see canonicals or noindex tags on pages it’s forbidden to fetch — so never block a pattern you’re simultaneously trying to canonicalize or noindex. Pick one signal per URL class, send it cleanly, and write the decision down per facet, because the next platform migration will ask you to make it again.

Product Schema and Merchant Center: Feeding the Shopping Surfaces

Product structured data is the closest thing e-commerce SEO has to a free upgrade. Correct Product markup — name, image, price, currency, availability, and review data where it genuinely exists — makes product pages eligible for results that show price and star rating in the snippet, and it feeds the product knowledge surfaces Google keeps expanding. The implementation rules are unforgiving in a useful way: the markup must match what’s visibly on the page, price and availability must be current, and review markup must reflect real reviews collected on that product. Shopify themes generally emit Product markup out of the box — verify it rather than trust it, because apps love to inject a second, conflicting block. On WooCommerce the core plugin outputs basic markup and quality varies with the theme; run your top templates through the Rich Results Test instead of assuming.

The second half of this story is the merchant feed, the half SEO teams skip because it grew up in the paid-ads department. A Google Merchant Center feed isn’t just for Shopping ads anymore — it powers free product listings across the Shopping tab and other surfaces, and Google increasingly reconciles what your page says, what your markup says, and what your feed says. When they disagree — feed says in stock, page says sold out — you get disapprovals and lose eligibility. Treat the feed, the schema, and the visible page as one system with one source of truth, refreshed on the same schedule. Both Shopify and WooCommerce have official channel integrations that sync the catalog automatically; use them, because the failure mode of a hand-maintained feed is always staleness, and staleness is exactly what gets you suspended.

The Manufacturer Description Problem (and What to Do at Scale)

If you resell other brands’ products, your default product copy is the manufacturer’s description — the same paragraph that appears on the manufacturer’s own site and on every other retailer carrying the SKU. Google has seen that paragraph hundreds of times. It won’t penalize you for it, but it has no reason to rank your copy over anyone else’s, and a catalog that is all syndicated text is competing on domain strength alone. Against marketplaces and big-box retailers, that’s a losing hand.

The answer is not “rewrite every description” — at two thousand SKUs that advice is a way of doing nothing. The answer is triage. Sort the catalog by revenue, margin, and organic potential, and rewrite the top slice properly: who the product is for, how it compares to the alternatives you also sell, sizing and compatibility answers pulled from support tickets. That last source is underrated; your support inbox is a list of exactly what the page failed to answer.

For the long tail, change the ratio of unique to duplicated text instead of replacing the text. Keep the manufacturer specs — they’re accurate and shoppers want them — but wrap them in elements only you have: reviews collected on your site, a Q&A module, your own photography, delivery and returns specifics. A page that is mostly house content around a block of manufacturer specs reads as your page; the inverse reads as a syndication endpoint.

The same triage logic handles thin products generally. Variants masquerading as products get consolidated. Discontinued lines get retired deliberately (next section). And genuinely marginal products that will never earn a rewrite can stay indexed inside an otherwise strong catalog — the goal is shifting the site’s center of gravity, not uniform perfection.

Out of Stock, Seasonal, and Discontinued: Don’t Burn URLs That Earned Rankings

Product pages accumulate equity slowly — links, rankings, history — and inventory churn is where stores throw it away. The right move depends on which of three situations you’re in, and the most common mistake is using one policy for all three.

Temporarily out of stock: do almost nothing. Keep the page live and indexed, update the schema and feed to reflect availability, and add a restock-notification signup so the traffic isn’t wasted. Deleting a page over a two-week stockout trades a permanent asset for a tidy-looking catalog. Seasonal products are the same case on a calendar: the worst pattern is deleting the Christmas category in January and rebuilding it in November, starting from zero each year while competitors’ pages compound. Keep seasonal URLs stable year-round and refresh the inventory when it returns.

Permanently discontinued with a successor: 301 to the closest genuine replacement — the new model, or the variant that superseded it. The key word is genuine. Redirecting every dead product to the homepage or a broad category is treated as a soft 404, because the destination doesn’t satisfy the intent that earned the links.

Permanently discontinued with no successor: let it 404 or 410 honestly, after checking for backlinks worth preserving — if they exist, the closest relevant category is a defensible redirect target. What you must not do is leave the page returning 200 with an empty template and a “no longer available” message at scale. That’s a soft-404 farm, and it’s the most common hygiene finding in our e-commerce audits. Write the policy once — in stock, stockout, seasonal, superseded, gone — wire it into the platform’s product lifecycle, and the decision stops being made differently by whoever archived the product that day.

Internal Linking: The Bridge From Content to Commerce

Everything above concerns the commercial catalog. The last pillar is what connects your content to it — because most stores that invest in a blog build a library that links enthusiastically to itself and to external sources, and almost never to the pages that sell things. The result is two disconnected sites sharing a domain: a content cluster that earns links and rankings, and a catalog that receives none of that authority.

The pattern that fixes it is the buying guide as a hub. Every meaningful category deserves one piece of genuinely useful decision content — how to choose, how to size, what the trade-offs are — linking down to the category page and the specific products it discusses, with descriptive anchors (“insulated winter hiking boots,” not “check out our selection”), and the category page linking back up. Informational queries land on the guide; the guide passes shoppers and authority to the money pages.

Within the catalog, template-level links matter most: breadcrumbs on every product page (with breadcrumb schema), parent and sibling category links on every category page, and server-rendered related-products modules — if your recommendations widget builds its links client-side, Google may see none of them.

If you take one action from this article, run the comparison that exposes all three pillars at once: crawl your site, list pages by internal links received, and put that against pages ranked by revenue. On a healthy store the lists rhyme. On most stores they don’t, and the gap between them is your roadmap — architecture first, templates second, filters contained, and content finally pointed at the pages that pay for it.