A typical corporate site has 30–50 pages. An online store has 3,000 products, 40 categories and tens of thousands of addresses generated by filters. E-commerce SEO starts from that difference in scale: the central question here isn't "how do we write this" but "which pages do we point Google's time at". Answer it wrong and Google spends its crawl on thousands of filter URLs while never reaching the category page that actually sells.
- The number of indexed URLs in Search Console is far higher than your real product count.
- Product pages appear in Google but category pages don't — even though categories are where the revenue is.
- Thousands of URLs have piled up under "Discovered — currently not indexed".
- The same product exists at several addresses because of colour and size variants.
- Out-of-stock products get deleted and the site fills up with 404s.
- Products don't show in the Google Shopping tab or in image search.
How store SEO differs
The gap between e-commerce SEO and ordinary site optimisation isn't technical — it's economic. In a store every page carries its own revenue potential, and the resource is finite.
| Ordinary site | Online store | |
|---|---|---|
| URL count | Dozens, managed by hand | Tens of thousands, generated automatically |
| Main risk | Not enough content | Uncontrolled URL sprawl and duplication |
| Revenue gateway | The service page | Category pages, not products |
| Volatility | Pages stay stable for months | Stock, prices and range change daily |
| Structured data | Desirable | Mandatory — Shopping and image search depend on it |
The third row surprises most people: in stores, the bulk of organic revenue comes from category pages, not individual products. "Women's winter boots" lands on a category; "Nike Air Max 270 size 42" lands on a single product. The first query has many times the volume of the second.
The four layers of a store
E-commerce SEO treats a store not as one website but as four distinct layers. Each has its own purpose, its own risk and its own metric.
Layer 1 — Category pages (the revenue gateway)
Three lines of work here: shaping the category hierarchy around actual search demand, writing unique descriptive copy for each category, and surfacing the highest-revenue categories through internal linking. Google recommends readable URL structures — the documentation says plainly: "Add descriptive words in URL paths" and, where parameters are used, "Use ?key=value URL parameters rather than ?value, where possible".
The most common mistake we see: a category page containing nothing but a product grid, without a single line of text. Such a page never answers Google's question of what it is about.
Layer 2 — Filters and faceted navigation (the expensive risk)
Colour, size, brand, price range — every filter creates a new URL, and combinations grow geometrically. Google recognises this as a problem and explains why: "the crawlers will typically access a very large number of faceted navigation URLs", with the result that "crawlers have less time to spend on new, useful URLs". This gets its own section below.
Layer 3 — Product pages
Copying the supplier's description verbatim is the most widespread source of duplication in stores — the same text sits on hundreds of sites. Our work here: a unique description structure, correct canonicalisation of variants (colour, size), image optimisation and structured data. Google maintains separate documentation for variants: product variants.
Layer 4 — Pagination and "load more"
Category listings are usually split across several pages. Google's e-commerce documentation is specific: give each page its own unique URL, link pages sequentially with <a href>, and — note this — "Don't use the first page of a paginated sequence as the canonical page." In other words, page 2 of a product listing should not canonicalise to page 1; each page should be self-canonical.
The old rel="next" / rel="prev" tags are now pointless: "Google no longer uses these tags." Infinite scroll and "load more" buttons are JavaScript-driven, so Google asks for an extra safeguard — a sitemap or a Merchant Center feed that makes every product discoverable.
The filter explosion, in numbers
This is the single most expensive problem in e-commerce SEO, and it's easy to demonstrate arithmetically. Suppose a category has five filters, each with four options:
| Filters selected | URL variants produced |
|---|---|
| 1 filter | 20 |
| 2 filters | 160 |
| 3 filters | 640 |
| Add sorting and pagination | tens of thousands |
Multiply that across 40 categories and the picture is clear: Google's crawl resource goes to filter combinations of no practical value instead of real products. Google separately warns that changing parameters can create an infinite URL space: "The crawler may think your site contains an infinite number of pages if your URLs include a continually changing value such as a timestamp."
rel="nofollow" and rel="canonical" approaches are described as "generally less effective in the long term". The recommended route is to prevent crawling in the first place: "Use robots.txt to disallow crawling of faceted navigation URLs." And if your filter mechanism is built on URL fragments (#), the problem never arises — "it will have no impact on crawling".In practice the solution is shaped by the store: which filters have genuine search demand (those become indexable landing pages), and which are purely a convenience (those are closed off from crawling). The split is made on revenue potential, which is why a template rule never solves it. We extract the real state of filter URLs with a Screaming Frog crawl and compare it against what Google actually sees in Search Console. The official methodology: Google — managing faceted navigation crawling.
What to do with out-of-stock products
This is the question we get most often in online store SEO, and there is no universal answer — the decision depends on the product's future. The rule we apply:
| Situation | Correct handling | Why |
|---|---|---|
| Temporarily out, coming back | Keep the page (200), show stock status, offer alternatives | Earned positions and links are preserved |
| Model discontinued, successor exists | 301 to the new model | Link equity and traffic pass to the successor |
| Withdrawn entirely, no replacement | 301 to the category, or 410 | Gives Google a definitive signal; crawl isn't wasted |
| Created by mistake / never sold | 410 | Removes it from the index faster than a 404 |
The worst option is deleting thousands of products at once and filling the site with 404s. The SEO meaning of status codes is covered separately: 404, 410 and soft 404, 301 vs 302.
Structured data and Google's product surfaces
In e-commerce SEO, structured data isn't cosmetic — it's the entry ticket to Google's product surfaces. Google lists these types as relevant to e-commerce: Product and ProductGroup (for variants), Review, BreadcrumbList, Organization, LocalBusiness and VideoObject.
Where product data can appear is documented too: product snippets in Google Search, Google Images, Google Lens, the Shopping tab and Maps. But there's a condition — markup on the site is not enough for the Shopping tab: "If you want your products to be found in the Google Shopping tab, upload your products to Google Merchant Center." Structured data and a Merchant Center feed don't replace each other; they work together.
We verify markup with the Rich Results Test. The full requirement list: Product structured data. Connecting entities to each other is a topic of its own: schema markup and entity linking.
What we measure in e-commerce SEO
"Organic traffic went up" is not an e-commerce SEO report — the question is always which category produced how much revenue. Our measurement set, and which symptom we look at with which tool:
| Symptom / question | Tool |
|---|---|
| How many URLs Google knows, how many are indexed | Search Console — page indexing report |
| The real count of filter and duplicate URLs | A full Screaming Frog crawl |
| Whether product markup is read correctly | Rich Results Test |
| Products rejected in the feed | Merchant Center diagnostics |
| Category page load speed | PageSpeed Insights |
| Organic revenue and conversion by category | GA4 — e-commerce events |
Three numbers always appear together in the report: the share of products indexed, organic revenue by category, and organic's share of total revenue. A list of rankings on its own doesn't count as a report.
How we work
"Fix everything at once" doesn't work in an e-commerce SEO project, because most changes need developer resource. So the order follows revenue potential:
- The leak map. A full crawl matched against Search Console: how many URLs exist, how many are valuable, and where the crawl resource is going.
- Crawl control. Filter strategy, robots.txt rules, sitemap hygiene. This step is the fastest and highest-impact part.
- Category work. Hierarchy, copy, internal linking — this is where the main revenue source opens up.
- Products and structured data. Fixes at template level: done once, applied to thousands of pages.
- The seasonal cycle. Collection, sale and season pages are prepared in advance, because indexing takes time.
If the technical side runs deep, it's combined with the separate technical SEO package; for continuous monthly management the work moves into the SEO service format.
Frequently asked questions
Should filter pages be indexed?
Some of them, yes. Combinations with genuine search demand ("black winter boots") should become dedicated landing pages and be indexed. The rest — the hundreds of combinations nobody searches for — should be closed off from crawling. The decision rests on demand data, not on a template.
Can we use the supplier's product descriptions?
There's no technical prohibition, but the same text sitting on dozens of stores lowers that page's chance of standing out. The practical fix: write the first paragraph and key features uniquely, and leave the technical specification table as it is.
Should page 2 of a category be noindexed?
Google's e-commerce documentation doesn't recommend that — it advises giving each page a unique URL and its own canonical, and explicitly forbids canonicalising to the first page. Since each page of a product listing carries different products, that makes sense.
How many products before e-commerce SEO is worth it?
Demand decides, not product count. A 200-product store in a well-searched niche earns more than a 20,000-product store with no demand behind it. The first step is demand research: semantic keyword research.
Is SEO enough to appear in Shopping?
No. Google's documentation is explicit: to be found in the Shopping tab, products must be uploaded to Merchant Center. Site markup works for Search and Images; Shopping needs the feed.
Is our platform (Shopify, WooCommerce, OpenCart) holding us back?
Usually not. Every platform has its limits, but all of them offer a route to filter control, canonicalisation and structured data. We only propose a platform change when a real technical barrier is identified.