Ecommerce SEO for online stores

Every filter your storefront offers multiplies the URL space. Four filters with five values each is 625 combinations per collection before pagination, and a crawler will happily spend weeks on them. Meanwhile the pages you want indexed get visited monthly.

The fix is a triage, not a blanket rule. Filters with genuine search demand behind them, usually brand, material, size or use case, get indexable URLs with their own copy. Filters that only refine, like price sliders and sort order, get blocked or canonicalised. Combinations of two or more facets almost never earn indexation, whatever the platform's default is.

We write this as a spec at template level: which parameter patterns are crawlable, which are indexable, what the canonical points at, and what pagination does. Then whoever maintains the store implements it. We do not build or rebuild storefronts, and an SEO agency offering to rewrite your theme is quoting for work it should not be doing.

Someone searching for a product category wants a set of options. Google knows that, which is why category SERPs return listing pages and marketplaces rather than individual product detail pages. Optimising a single product page for a category term is the most common wasted effort in ecommerce SEO.

So the collection page has to be a page. Copy that says what the category is and how to choose within it, placed where it is readable rather than dumped below the footer. Internal links from related collections. A URL that survives a replatform. And enough differentiation between adjacent collections that they are not competing with each other, which is the same cannibalisation problem every site has, just at 200x the volume.

Product pages still matter. They win long-tail model numbers, comparison queries and anything with a specification in it. They are simply not where the category battle happens.

Product discovery is moving into conversations. "A dishwasher-safe pan under $150 that works on induction" is a query no keyword strategy captures, and the assistant answering it is reading structured product data, retailer pages and third-party reviews, then naming two or three options.

Being one of those options depends on things that are unglamorous and mostly not on your product page today: complete and consistent specifications, an entity the engine can resolve to your brand rather than to a reseller listing your SKUs, and independent sources corroborating what you say. Where a marketplace listing of your product is better structured than your own page, the assistant will cite the marketplace.

This is the same GEO work we do everywhere else, applied to a catalogue. The difference is volume: the fixes are template-level rather than page-level, which is the one respect in which ecommerce is easier than a services site.

There is no ecommerce case study on this site. Our published work is a renovation contractor, an interior design studio, an appliance repair company and a consumer iOS app, and none of them run a catalogue.

What transfers is most of the method. NovelMaker was a product-facts and category-definition problem, which is the same work a store needs on its collection and specification pages. YaDesign was entity resolution across two markets, which is what stops a brand fragmenting across its own site, its marketplace listings and its resellers. The technical crawl work is discipline we do on every engagement.

What does not transfer is proof. If you want an agency that can show you a store it took from x to y, we are not it yet, and you should ask for that. If you want the crawl and structure problem diagnosed properly first, the $2,000 audit covers a store as it covers any site, and it is priced and scoped the same either way.