E-commerce SEO Consulting

Why a store is a different problem from a website

Two things separate catalog work from everything else, and both are consequences of scale rather than of technique.

Defects are template-level. Nobody hand-writes forty thousand product pages; they come out of a template. So a defect in that template appears on forty thousand URLs at once and disappears from all of them in one release. The unit of work is the template, and priority is set by how many revenue-carrying URLs a template governs — not by which individual page looks worst in a crawl report.

The URL inventory moves on its own. Products go out of stock, come back, get discontinued, get merged into a variant group, get renamed by a merchandiser who has never thought about a redirect. A site's URL set is stable. A catalog's is not, which is why this is retained work rather than a project. And on top of that, filters generate URLs faster than any crawler will work through.

Faceted navigation, and the crawl explosion it causes

Faceted navigation is the filtering interface on a category page — size, color, brand, price band. Each combination usually produces a URL, and combinations multiply: a category with six filters can generate more URLs than the store has products.

Google describes the mechanism precisely: because the URLs created by faceted navigation "seem to be novel and crawlers can't determine whether the URLs are going to be useful without crawling first, the crawlers will typically access a very large number of faceted navigation URLs before the crawlers' processes determine the URLs are in fact useless."

So the first decision is editorial, not technical: which filtered views are worth having in the index at all? Usually a small number are — a brand within a category, sometimes a size — and the rest are not.

Where facet URLs should not be indexed, Google's preferred controls are a robots.txt disallow on the parameter combinations, URL fragments such as #products=fish which it does not crawl, and rel="canonical" to the unfiltered view. Worth knowing, because it contradicts a great deal of received wisdom: Google states that rel="nofollow" and rel="canonical" are "generally less effective in the long term" than the first two for this.

Where facet URLs should be indexed: use a standard & separator with ordinary key=value encoding, keep filter ordering consistent, and return 404 for empty result sets rather than a "no products found" page carrying a 200. Reference: Google on faceted navigation.

Deciding what belongs in the index at all

Most stores have never written this down, which is why the sitemap, the canonical tags, the internal links and the robots file disagree. Half of e-commerce technical work is making those four agree. The policy has to settle, in writing:

• Category and subcategory pages. Which levels are indexable, and what a category page contains besides a product grid. A grid alone rarely earns the term the category is named after.
• Paginated views. Whether page two onward is indexable, and what each canonical points at. Pointing every paginated page at page one hides the products that appear only deeper in the sequence.
• Product variants. Whether each color and size gets its own URL, or one page carries them as options. Both are defensible. Splitting them without differentiating anything but the swatch produces near-identical competing pages.
• Internal search results, excluded almost always and leaking into the crawl almost as often.

Out of stock, discontinued, and the pages you are about to delete

Availability is where catalog SEO is quietly won and lost, because the decision is made by an inventory system rather than by anyone thinking about search.

Start with markup, since the values are not negotiable. Google accepts a single ItemAvailability value from a fixed list: InStock, OutOfStock, BackOrder, PreOrder, Discontinued, SoldOut, LimitedAvailability, OnlineOnly, InStoreOnly, PreSale. Short names without the https://schema.org/ prefix work too. Temporary unavailability is OutOfStock; permanent is Discontinued or SoldOut.

The page decision is separate. If the product is returning, keep the URL indexable and give the visitor something to do. If it is permanently gone and has a genuine equivalent, redirect there; redirecting to a category because there is nowhere better is a deliberate decision, not a default. If it is gone with no replacement, Google's crawl-budget documentation is explicit that a 404 or 410 for permanently removed pages is "a strong signal not to crawl that URL again." The failure to avoid is a soft 404: a live-looking page carrying a 200 status with no product on it, which is the default behavior of a surprising number of platforms.

One constraint people trip over: Google's e-commerce launch guidance states, verbatim, "Don't disable add-to-cart functionality as a way to stopping users from purchasing products. Google may use add-to-cart as a part of verifying the final price details."

Product structured data, and which of the two experiences you are marking up

Google splits Product markup into two experiences with different requirements. Merchant listings are for pages where a customer can buy from you directly. Product snippets are for product pages where people cannot directly purchase, and they carry more options for review information.

A merchant listing requires name, image and offers, and within offers either price or priceSpecification.price — which must be greater than zero — plus a three-letter ISO 4217 priceCurrency. A price of zero is invalid, which catches out stores that render an empty price on unavailable items. Recommended at product level: brand.name, sku, a GTIN identifier, mpn, color, size, aggregateRating, and isVariantOf pointing at a ProductGroup. At offer level: availability, itemCondition, priceValidUntil as an ISO 8601 date, shippingDetails and hasMerchantReturnPolicy.

Those last two are structured objects, not free text: shipping details carry a rate, a destination and a delivery time split into handling and transit; a return policy carries the applicable country, the policy category, the window in days, the method and the fees. Where one consistent returns practice applies, Google prefers it declared globally under Organization markup rather than repeated on every offer.

A product snippet needs only name plus one of review, aggregateRating or offers. Reference: Google's merchant listing documentation.

The platform sets the ceiling, and it is worth knowing where yours is

Some recommendations are impossible on some platforms. Knowing that before the roadmap is written saves a quarter.

Shopify

URL paths are forced: products under /products/, collections under /collections/, with no hierarchical product URLs. A product in several collections is reachable at /products/item and at each /collections/x/products/item variant; Shopify canonicalizes to the /products/ version, but internal links on collection pages point at the collection-scoped URLs by default. That mismatch between the canonical signal and the internal-link signal is the most common Shopify finding there is. Variants share meta: there is no native support for separate meta titles and descriptions per variant. robots.txt is editable through a robots.txt.liquid theme template, though Shopify recommends keeping its Liquid objects in place because "the default rules are updated regularly." Sitemaps cannot be customized. Standard plans cap redirects at 100,000. And server logs are unavailable, so Googlebot log analysis is not possible at all: a hard limit on audit depth, and one to state before the work starts.

Adobe Commerce and Magento

More flexible, with a support lifecycle that creates dated deadlines. Adobe gives three years of standard support from general availability, plus one further year of extended support at no cost for 2.4.6 and 2.4.7. Against its published lifecycle policy: 2.4.5's extended support ends 12 August 2026, and 2.4.6's standard support ended 11 August 2026 with extended support to 30 August 2027. Adobe has also stated that from 1 June 2027 it will not maintain Cloud environments running unsupported versions. Confirm those dates against Adobe's page rather than this paragraph.

Everything else

The method is identical anywhere: what the templates generate, what the platform will let you change, and where the indexation policy has to bend around the second. But I will not assert specifics about WooCommerce or BigCommerce URL handling and filter behavior that I have not verified against a current build, because platform detail one version out of date is worse than none. There, the first step is establishing what your installation actually produces.

How this is engaged, and what makes one store more work than another

Retained, because the catalog changes continuously and a fixed scope would be a snapshot of a moving object. Where the store is small and stable, a one-off audit is the better purchase and I will say so. What drives the effort:

• Template count more than product count. Ten thousand products from four templates is less work than two thousand from thirty.
• How many filters exist, and how the platform builds their URLs.
• Platform. Whether a fix is a theme change, a core change, or not permitted at all.
• Whether structured data is generated centrally — one template change, or an app per field.
• Release cadence. A weekly deploy and a quarterly one produce very different roadmaps from identical findings.

The first pass — indexation policy, facet handling, availability and markup — usually takes six to ten weeks to specify in full. After that each month is specifications written, work handed to whoever builds, then verification that what shipped behaves as specified. Verification is not a formality: template changes routinely ship at a fraction of what the spec described, and the missing part is often the one that mattered.

When you do not need this, and how you will know it is working

If the store has a few hundred products, no filtering to speak of, and one product template, this is not your problem and nobody should sell it to you as one. Crawl budget in particular is not your constraint at that size. Buy a one-off technical audit and spend the difference on the product pages themselves. If traffic arrives and does not convert, that is a merchandising or checkout problem. If the catalog is about to be replatformed, do the migration planning first.

Judging the work: indexed product and category URLs against the URLs you intended to be indexed, which is the honest measure of whether the indexation policy is holding. Then crawl distribution, which should shift from filter combinations toward products and categories. Then impressions and clicks at the level of category groupings rather than individual products, whose performance is dominated by whether the item is in stock. Revenue is the objective, but it moves for seasonal and merchandising reasons unrelated to any of this, so it is read alongside the others and never alone.

Frequently Asked Questions

Published 2026-08-11