Ecommerce SEO for catalogs that outgrew their own crawl budget

Category page SEO starts with demand, not the merchandising menu

Catalog navigation is usually built to mirror how the buying team organizes inventory: supplier, department, season, then a long tail of collections created for a campaign and never retired. Search demand is organized differently. People query by attribute, use case, compatibility, size, material and price band, and those clusters exist whether or not your taxonomy has a page for them.

The work starts by pulling the full demand set for the catalog in Ahrefs, reconciling it against what Google Search Console already shows the site earning impressions for, and classifying every cluster by intent. That produces an architecture map rather than a keyword list:

• Collections that exist and should stay, with the query cluster each one owns written down so two pages stop competing for the same term
• Collections that should be created, because demand is there and no URL currently answers it
• Collections that should be merged or retired, with redirects planned before anything is deleted

A collection that earns a URL also earns more than a product grid. It needs a short buying frame that answers the comparison the shopper is actually making, internal links up to its parent and across to siblings, and title, H1 and meta patterns set at template level so one deploy touches the whole catalog. That template-scale approach is covered in depth on on-page SEO.

Faceted navigation: index, noindex or block

Faceted navigation multiplies rather than adds. Ten filter groups with a handful of values each, combinable in any order and stackable with sort and view parameters, produce more URL permutations than the catalog has products. On a catalog site of any size, that is normal, and every permutation is a URL Googlebot is entitled to request.

The decision is made per facet, not with one site-wide rule:

• Indexable. A facet value with repeated, independent search demand and enough inventory behind it to hold a page: brand, primary attribute, often color. It gets a clean static path rather than a query string, a self-referencing canonical, a distinct title and H1, a place in the XML sitemap, and real anchor links pointing at it.
• Noindex, follow. Useful to shoppers, no demand of its own: multi-select combinations, in-stock toggles, narrow price bands. Crawlable so equity keeps moving, kept out of the index.
• Blocked or stripped. Sort order, view mode, items per page, session and tracking parameters generate no new content, so the cheapest control is disallowing the pattern in robots.txt or never emitting the link at all.

One thing worth being blunt about: rel=canonical is a hint about which URL to index, not an instruction to stop crawling. If the crawl needs to stop, robots.txt or link suppression is the lever. The finished rule set is reconciled against index coverage and server logs during the technical SEO audit, and against Google's own SEO starter guide conventions for URL structure.

Variant duplication, pagination and infinite scroll

Three separate mechanics cause the same two symptoms: one product living at many URLs, or deep products reachable at none.

Variants. Size and color options that append ?variant= or spawn separate product URLs split ranking signals across near-identical pages. The default is one canonical product URL with variants selected on-page. The exception is a variant with genuine standalone demand, where the page then needs its own title, description, imagery and schema to justify being indexed separately rather than being a color swap of its parent.

Pagination. Page two onward should be crawlable, self-canonical and indexable unless there is a reason otherwise. Canonicalizing every paginated page back to page one is the common mistake, and it strands everything past the first 24 products. Google stopped using rel=next and rel=prev as an indexing signal, so the working alternative is depth: narrower collections and indexable facet pages that shorten the path to any given SKU.

Infinite scroll. A grid that appends products through JavaScript with no URL change gives the crawler nothing to follow. The fix is a paginated URL equivalent behind the scroll, with server-rendered anchor tags, so every product is reachable without executing a click. The same rendering check applies to any headless storefront, which is why rendering is tested on templates rather than assumed.

Product schema that matches the merchant feed, character for character

Product markup is not a ranking widget. It is a contract between three things that have to agree: what the page shows, what the JSON-LD declares, and what the product feed submits to Merchant Center.

The fields that matter are unglamorous. name, sku, gtin or mpn, brand, and an offers block carrying price, priceCurrency, availability, and shipping and return details where they apply. Implemented as JSON-LD in the page head, in the format Google documents for structured data, generated from the same product API that builds the feed rather than hand-maintained in a theme file.

Mismatches are where the damage happens. A price in the feed that includes tax while the markup does not, a currency set by geolocation that the crawler never sees, an availability value cached from an hour ago, or a stale JSON-LD block injected by a review app on top of the theme's own: each of these produces price or availability mismatch disapprovals in Merchant Center, and disapproved items lose free listings and shopping surfaces regardless of how the organic listing performs.

So the schema build includes deduplication of competing markup blocks, a single generation source, validation across a sample of SKUs rather than one demo product, and a recheck after any theme or app change.

Out-of-stock and discontinued URLs

Deleting a product URL deletes the links pointing at it. On a catalog with real turnover, doing that for years quietly erodes the authority the whole domain rests on. The policy below gets written into the engagement and handed to whoever runs merchandising, because the decision is usually made in the PIM, not by an SEO.

• Temporarily out of stock. Keep the URL live and returning 200, keep it indexed, set availability to OutOfStock in the markup, and use the page for a restock alert plus links to close alternatives.
• Discontinued with a direct successor. 301 to the successor product, never to the homepage or a generic collection, which Google is likely to treat as a soft 404.
• Discontinued with no successor but with links or traffic. 301 to the closest parent collection, or keep the page live as an archive stating the product is no longer made, with alternatives listed.
• No links, no traffic, no successor. 410, deliberately, so the index clears rather than the URL lingering.
• Seasonal. Never delete. Re-merchandise the same URL each year so it accumulates history instead of restarting.

Equity earned through link building is expensive, and a redirect map costs a fraction of replacing it.

Platform specifics: Shopify, Shopify Plus, WooCommerce and BigCommerce

Platform decides which fixes are cheap and which need a workaround.

Shopify. Products are reachable at both /products/handle and /collections/x/products/handle, so canonical handling in the theme needs checking rather than assuming. Filters from Search and Discovery emit filter. parameters, tag collections generate /collections/x/tag-y, and /collections/all is live by default. robots.txt.liquid is editable, so parameter patterns can be disallowed, and metafields are the right home for schema values that should not live in theme markup. Shopify SEO work is mostly Liquid template work plus app audit, since server config is not exposed.

Shopify Plus. Adds markets, multiple storefronts and B2B catalogs, which turns hreflang and cross-storefront duplication into the main structural questions.

WooCommerce. Full server control, and the usual problem is stacking: an SEO plugin, the theme and WooCommerce each emitting Product markup. Attribute archives such as /pa_color/ are indexable by default, ?orderby and ?add-to-cart need handling, and theme weight is the common cause of failing field data, measured against the Core Web Vitals metrics rather than a lab score.

BigCommerce. Stencil templating, product filtering parameters, and a built-in 301 manager that makes the URL lifecycle policy above straightforward to apply. Stores with physical locations also get local SEO in scope.

Measurement: revenue per URL cluster in GA4 and BigQuery

Session counts do not tell you whether category page SEO paid for itself. Revenue per URL cluster does.

The setup: GA4 ecommerce events verified end to end, including view_item_list, select_item, add_to_cart and purchase, so the listing pages get credit for the products they introduce. GA4 is then exported to BigQuery and joined to the Search Console bulk export by URL, which removes the sampling and row limits that make in-interface analysis unreliable at catalog scale.

Every URL is tagged into a cluster: brand collection, attribute collection, product detail, indexable facet, editorial. From there the reporting answers questions that actually change decisions:

• Which collection clusters generate revenue per indexed URL, and which are index bloat with a price tag
• Which products earn organic entrances but sit three clicks from any collection
• Which facet pages, now indexed, convert well enough to justify more of them
• Which discontinued redirects retained their traffic and which lost it

That feeds a Looker Studio dashboard updated daily, plus a monthly written memo. It also feeds editorial priorities, since the clusters with demand and no converting page are the brief list handed to SEO content strategy. Scope and reporting cadence per tier are set out on the pricing page, and expected outcomes are always forecasts, as our disclaimer states.