An online store is a database rendered as web pages. That is the single most useful thing to hold in mind when doing ecommerce SEO, because it means almost every problem and every fix is a template or a rule, not an edit. If product pages have weak titles, the fix is the title template. If the crawler is wasting its budget on filter combinations, the fix is a crawl rule. If categories do not rank, the fix is usually architecture, not a paragraph of text at the bottom of the page.
Category architecture: where most of the organic revenue lives
For most stores, category and subcategory pages earn more organic revenue than product pages. They match the queries people use when they do not yet know which product they want ("running shoes for men", "cotton kurta sets", "mixer grinder 750 watt"), and those queries have far more volume than any single product name. If the category layer is wrong, nothing you do at the product level will compensate.
Categories should mirror demand, not the ERP
Stores usually inherit a taxonomy from the catalogue system or the merchandising team. Those taxonomies are organised by supplier, by internal department, or by whoever set them up first. Search demand is organised by how people describe what they want. The two rarely match. Start from the query data: cluster the non-brand queries in your space, and let the clusters tell you which categories and subcategories need to exist as pages. My keyword research guide covers the clustering; the point here is that the taxonomy follows the clusters, not the other way around.
Depth: three levels is usually enough
Home, category, subcategory, product. Sometimes one more level for very large catalogues. Beyond that, pages are too far from the homepage to accumulate link signals, and the subcategories are too narrow to have demand. If you are at five levels, you are probably encoding attributes (colour, size, brand) as categories, and those belong in filters. And where two categories satisfy the same intent ("men's running shoes" and "running shoes for men"), merge them; where one serves two intents, split it.
- Home
- Category
- Subcategory
- Product
Faceted navigation and crawl control
Filters (facets) are the biggest technical risk in ecommerce SEO. A category with ten filter dimensions, each with several values, can generate millions of URL combinations. Each one is a page the crawler can request. Most of them are near-duplicates of the category page. Left uncontrolled, they consume crawl budget, dilute signals across thousands of URLs, and fill the index with pages nobody wants.
The right approach has two halves: decide which facet combinations deserve to be indexable pages, and prevent the rest from being crawled or indexed.
Which facets deserve pages
A facet combination deserves to be an indexable page when there is search demand for it as a distinct intent and the resulting page has enough products to be useful. "Running shoes, size 9" has no distinct demand; nobody searches for it. "Running shoes, Nike" does. "Running shoes, under 2000" often does in India, where price-bracketed queries are common. These are the combinations to promote to proper pages with their own clean URLs, titles, and content.
Controlling the rest
| Mechanism | What it does | When I use it | What goes wrong |
|---|---|---|---|
| Canonical to the base category | Tells Google the filtered URL is a variant of the category page | Filters that reorder or narrow slightly (sort, size, availability) | Google treats canonical as a hint; it still crawls the URLs, and ignores the canonical if the pages differ too much |
| Robots meta noindex | Keeps the page out of the index but still crawlable | Combinations that must stay reachable for users but have no search value | Does not save crawl budget; over time, noindexed pages' links may carry less weight |
| robots.txt disallow on parameter patterns | Stops crawling of matching URLs entirely | Deep combinations, sort orders, session or tracking parameters | Blocked URLs can still be indexed if linked externally; cannot pass signals; easy to over-block and hide real pages |
| Filters that do not create URLs (JS state, POST, fragments) | Filtering happens without a crawlable URL | Attribute filters with no search value, on platforms that support it | Hides facet pages you did want indexed; can break shareable links for users |
Most stores need a combination: clean indexable URLs for the facets that earn pages, canonicals for shallow variants, and robots.txt rules for the deep combinations and sort parameters. Test any robots rules with a robots.txt tester before deploying; a single mis-ordered pattern can block the entire category tree, and I have seen it happen on a Friday evening deployment.
Product page templates
A product page template is a set of rules that generates the title, description, headings, body structure, structured data and internal links from the product record. Getting the template right fixes every product page at once; getting it wrong breaks them all at once.
Title and H1
The template should produce a title that reads like how people search for the product: brand, product name, key attribute, category. "Boat Airdopes 141 Bluetooth Earbuds with 42H Playtime" is better than "Airdopes 141 | Boat | Buy Online". Put the differentiating attributes early, because titles are truncated in results. Check with a snippet preview. Avoid appending the store name to every title if the product name is already long; it costs characters and adds nothing for a non-brand query.
Body content
Manufacturer descriptions are duplicated across every retailer selling the product. A page built only from them has nothing to distinguish it. The template should have slots for original content: a short summary written for the store's customer, a specification table rendered from structured attributes (which is both useful and unique in combination), and questions answered from customer support.
Variants and canonicals
A T-shirt in six colours and five sizes is one product or thirty, depending on how the platform models it. For SEO, the question is whether each variant should be its own indexable page.
The rule I use: a variant gets its own indexable URL only when people search for it distinctly and the page can be meaningfully different. Colour often qualifies ("black formal shirt"), size almost never does, and material or capacity sometimes does ("1 TB" vs "2 TB" of the same drive). Everything else canonicalises to the parent product.
Implementation matters. If variant selection changes the URL but not the content, canonicalise to the parent. If it changes the URL and the page shows a different image, title and price, it can be a distinct page, but it needs a distinct title and a link from the parent. If selection does not change the URL, make sure the default variant the crawler sees is in stock and representative. My guide to canonical tags covers the edge cases.
Out-of-stock and discontinued products
Stock changes constantly, and each state needs a rule. Deleting a product page the moment it goes out of stock is the worst option, because it discards the page's rankings and links, and the product usually comes back.
Temporarily out of stock
Keep the page live, indexable, with the same URL. Show the stock status clearly, offer a back-in-stock notification, and link to in-stock alternatives in the same category. Update the
Offeravailability in structured data toOutOfStock. Do not noindex; the page will be back.Discontinued, with a direct replacement
301 redirect the old product URL to the replacement product. Carry the content over where useful. This preserves most of the signal and gives the searcher what they actually want.
Discontinued, no replacement
If the page has traffic or links, keep it live with a clear "no longer available" notice and strong links to the parent category and closest alternatives; consider removing it from the sitemap. If it has neither, 410 it and remove it from internal links. Redirecting hundreds of dead products to the homepage or a category page is treated as a soft 404 and wastes the effort.
Internal linking at scale
With tens of thousands of pages, internal linking has to be rule-driven. The rules decide which pages get links from where, and the goal is that the pages with the most commercial value receive the most and the best-placed links.
The main levers:
- Navigation. The mega menu determines which categories get a link from every page. Put the categories that matter commercially in it; keep it from ballooning to hundreds of links, which dilutes everything.
- Category-to-subcategory blocks. Each category page should link to its subcategories and to the promoted facet pages, in the HTML, above the product grid.
- Template links on product pages. Breadcrumbs (marked up with
BreadcrumbList), the parent category, and related products chosen by real relationships rather than at random, so product pages feed category authority instead of sitting as leaves.
I measure the result with a crawl: inbound internal link count per URL, grouped by page type, compared to revenue per page type. If product pages have more inbound links on average than category pages, or if the most profitable subcategory is three clicks deeper than a dead one, the rules need changing. The internal linking at scale experiment tests exactly these rule changes, and the internal linking framework is the method.
Product structured data and merchant listings
Product structured data (Product with Offer, AggregateRating where real, and Review) is what makes price, availability and rating appear in search results, and it feeds Google's merchant listing experiences. For an ecommerce store it is not optional.
Things that go wrong, in order of frequency:
- Price in the markup does not match the price on the page (discount shown visually, list price in markup, or the reverse). This triggers manual actions.
- Availability in the markup is static while the real stock changes.
- Variant products have one
Productblock with a single price while the page shows a range; useProductGroupand variant markup, or at least anAggregateOffer.
Beyond structured data, Google Merchant Center listings surface products in Shopping and in free listings whether or not you run ads. Submitting a feed from the same product data as the site, with identical prices and availability, is the simplest high-return action available to most Indian stores, and it is frequently skipped because it sits between the SEO and paid teams. I test which markup produces visible rich results in the schema experiment.
Content for categories
The "category description" is the most misused piece of ecommerce content: keyword-dense text hidden below the grid, written for the crawler, read by nobody. It does little and can hurt.
What works instead is content that helps the person choosing. A short, honest intro above the grid saying what the category contains and who it suits. A buying guide section (how to choose a mixer grinder: wattage, jar material, warranty, service network) placed below the grid or on a linked guide page. Answers to the questions support receives about that category. Comparison tables where the category contains genuinely different types. This content earns the category page long-tail queries the grid alone never would, and it supports the informational pages that link to it. My content SEO guide covers the briefing process for this.
Marketplace versus D2C
Many Indian brands sell both on their own store and on marketplaces (Amazon, Flipkart, Myntra, Nykaa and category-specific ones). The marketplaces usually outrank the brand's own store for the brand's own product names, because they have overwhelming authority and often better product pages.
The D2C store cannot win on identical product pages. It can win on things the marketplace cannot do: category and comparison content written with the brand's expertise, bundles and configurations marketplaces do not list, the brand's own story and support, and the long tail of non-brand category queries where the marketplace page is generic. The strategy is therefore to make the store the best source for the category, not just a second place to buy the product. The brand-name queries will follow once the store is clearly the authority on the subject.
Platform notes
Shopify
Fast to launch and mostly sound by default, with a few structural constraints. URL structure is fixed (/collections/, /products/), and the same product reachable under multiple collection paths is canonicalised to /products/ automatically, which is correct. Tag-based collection filtering creates crawlable URLs that usually need controlling. The main risks are apps injecting render-blocking scripts and duplicate structured data, and themes that load product content via JavaScript. Check what the crawler actually sees.
Magento (Adobe Commerce)
Flexible and dangerous. Layered navigation produces facet URLs by default and must be configured deliberately; category paths in product URLs create duplicates unless disabled; and the default canonical and robots settings vary by version and extension. Performance is often poor without serious hosting and caching work, which affects Core Web Vitals.
Custom and headless builds
Full control, so every rule above must be built rather than configured. The common failure is a JavaScript front end (React, Next.js, Vue, Nuxt) that renders product and category content client-side, leaving the crawler with empty templates or inconsistent content. Server-side rendering or static generation for all indexable pages is the baseline. I cover the diagnostics in my JavaScript SEO guide and test rendering behaviour in the rendering experiment.
Frequently asked questions
Should I index filter pages or not?
Index the combinations that have distinct demand and enough products to be useful, with clean URLs and proper titles. Canonicalise shallow variants to the category and block deep combinations from crawling. "Index all" and "index none" are both wrong.
Why do marketplaces outrank my own store for my own products?
More authority, more complete product pages, more reviews. Competing on identical product pages is a losing strategy. Make the store the authoritative source for the category with content the marketplace listing cannot carry; brand-name rankings tend to follow.
What do I do with thousands of out-of-stock product pages?
Classify them. Temporarily out of stock: keep live with alternatives. Discontinued with a replacement: redirect to it. Discontinued with no replacement: keep if it has traffic or links, otherwise 410. Mass-redirecting everything to the homepage is treated as a soft 404 and gains nothing.
Do category descriptions help ranking?
Keyword blocks hidden under the grid barely help and sometimes hurt. Content that helps the person choose (a short intro, a buying guide, answers to real questions) earns long-tail queries and supports the category page. Write for the shopper and the ranking follows.
How do I measure ecommerce SEO properly?
Organic revenue by landing page type, with non-brand and brand separated. Category pages, product pages and content pages behave differently and should be reported separately. Rankings and traffic are diagnostics; the number the business cares about is revenue from non-brand organic sessions.
Where this connects
The Technical SEO Audit Framework is the procedure I use to audit a store's crawl, index and template layer before any of the above is changed. The internal linking at scale experiment tests rule-driven linking of the kind described here. The technical SEO and content architecture case study shows architecture and templates fixed together on a large site. If you want this done for your store, see my ecommerce SEO service.