eCommerce SEO in India: The Technical Foundations Most Stores Get Wrong

Quick answer: eCommerce SEO in India fails on four technical foundations far more often than on content. Faceted navigation generates millions of crawlable URLs that exhaust crawl budget. Product schema breaks because most Indian catalogues have no GTINs. Discontinued and out-of-stock products are deleted, destroying accumulated link equity. And Core Web Vitals are tested on a MacBook rather than the mid-range Android over 4G that Googlebot actually simulates. Fix these four and content starts working.

Key takeaways

• A store with four filters and sixty categories can generate over three million crawlable URLs. Googlebot will crawl them instead of your products.

• Most Indian products have no GTIN. Product schema still works — use sku, mpn and brand, and declare the absence correctly rather than inventing identifiers.

• Deleting a discontinued product throws away every link it ever earned. There is a correct action for each of six lifecycle states, and 404 is rarely it.

• Your store is indexed as it renders on a mid-range Android over a throttled connection, not as it looks on your laptop.

• At 4,000 SKUs with 24 products per page, your deepest products sit eight clicks from the homepage. Google treats click depth as an importance signal.

Most Indian eCommerce stores that are unhappy with organic traffic are producing content to fix a problem that content cannot fix.

The blog gets started. Category descriptions get written. Product copy gets expanded. Six months later traffic has barely moved, and the conclusion drawn is that SEO does not work for this category.

What is usually happening underneath: Googlebot is spending the majority of its crawl allocation on filter combinations that will never rank, product pages sit eight clicks deep, half the catalogue has invalid structured data because nobody could supply a GTIN, and every discontinued SKU has been deleted along with the links it earned.

Content sits on top of technical foundations. When the foundations are wrong, more content is more weight on a floor that will not hold it.

This guide covers the four foundations, with the specific decisions each requires. It assumes you have a real catalogue — hundreds to tens of thousands of SKUs — and it is written for the Indian market, which has structural differences that global SEO guides do not address.

Why eCommerce SEO Is a Different Discipline

A blog has a hundred URLs. A store has a hundred thousand, most of which you did not deliberately create.

Three properties make commerce SEO distinct:

URLs multiply without permission. Filters, sort orders, pagination, session parameters and tracking tags generate combinations automatically. A content site's URL count is authored. A store's URL count is emergent, and it grows faster than anyone monitors.

Inventory changes underneath the index. Products go out of stock, get discontinued, get renamed, get merged. Every one of those events is an SEO decision, and most stores make them by default rather than by policy.

The templates carry the ranking, not the pages. You are not optimising a thousand pages. You are optimising four templates — category, product, search results, and home — which then render a thousand times. A fault in a template is a fault at catalogue scale, and a fix at template level is a fix at catalogue scale. That asymmetry is the most useful thing to understand about commerce SEO.

Foundation 1: The Crawl Budget Problem

Do the multiplication

Take a moderately filtered clothing store. Four facets on a category page:

• Size: 6 values

• Colour: 12 values

• Brand: 40 values

• Price band: 5 values

Any combination is selectable, so combinations available on one category page: 6 × 12 × 40 × 5 = 14,400.

Now multiply by 60 categories: 864,000 URLs.

Add four sort orders: 3,456,000.

Add pagination across each of those: comfortably past ten million crawlable URLs for a store with perhaps 4,000 actual products.

Googlebot does not have infinite patience. It allocates a crawl budget based on your site's authority and server responsiveness, and it will spend that budget on whatever it finds. If it finds ten million filter combinations, it crawls filter combinations. Your new products wait weeks to be discovered, and your updated prices sit stale in the index.

This is the single most common cause of poor organic performance in Indian eCommerce, and it is invisible unless you look at crawl stats.

The facet decision matrix

Every facet needs a deliberate decision. Three options exist: index it, allow crawling but keep it out of the index, or prevent crawling entirely.

The rule underneath the table: a facet earns indexation only if people search for that combination in those words. "Nike running shoes" is a query. "Blue running shoes size 9 under ₹3000 sorted by price" is not.

Two mistakes worth naming

Using noindex where you needed disallow. A noindex page still gets crawled — that is how Google reads the tag. If your problem is crawl budget rather than index bloat, noindex does not solve it. Block at the crawl layer.

Canonicalising page 2 to page 1. Google deprecated rel=next/rel=prev support years ago, and the common overcorrection is pointing every paginated page at page 1. This tells Google the products on pages 2 through 40 do not exist. Each paginated page should canonical to itself and remain indexable.

Foundation 2: Site Architecture and the Orphan SKU Problem

Count your click depth

Take your deepest product. Count the clicks from the homepage.

At 4,000 SKUs with 24 products per listing page, a category with 800 products runs to 34 pages. A product on page 30 sits: home → category → subcategory → page 30 → product. Google reaches it by paginating through twenty-nine intermediate pages, and treats that distance as a signal that the product is unimportant.

Target: every product within four clicks of the homepage. Beyond five, expect indexation to become unreliable.

What actually fixes depth

That last one is underused. Separate sitemaps for products, categories and blog content let you read indexation rates per segment in Search Console. When 94% of categories are indexed but 41% of products are, you have located your problem in one glance.

Category pages carry more weight than product pages

Counter-intuitive for most store owners, and consistently true in commerce.

Category and subcategory pages target the higher-volume commercial queries ("cotton bedsheets online", "industrial safety gloves"). Product pages target long-tail and brand queries. Most Indian stores invest their content effort in product descriptions and leave category pages as a bare grid with an H1.

Reverse that priority. A category page deserves: a distinct H1, 150–300 words of genuinely useful introductory content positioned so it does not push products below the fold, internal links to relevant subcategories and buying guides, and FAQ content addressing what buyers in that category actually ask.

Foundation 3: Product Schema, and the India GTIN Problem

Why this section exists

Product structured data is what makes rich results possible — price, availability, review stars, and eligibility for Google's merchant experiences. Google's product structured data documentation sets the requirements.

Those requirements assume a product identifier: a GTIN, EAN, UPC or ISBN. Most Indian catalogues do not have one.

Domestic manufacturers, D2C brands, artisan and handmade categories, industrial and made-to-order goods, private-label products — none of these reliably carry a global trade identifier. This is a structural feature of the Indian market and it causes two failure modes.

Failure mode one: inventing identifiers

Someone populates the GTIN field with an internal SKU code to clear a validation warning. This is worse than leaving it blank. An invalid GTIN is a data quality problem that can affect eligibility, and it will not match anything in Google's product graph.

Failure mode two: leaving structured data out entirely

Equally damaging. Rich results are lost across the whole catalogue because one optional field could not be filled.

What to do instead

Use the identifiers you genuinely have, and declare the absence correctly.

json

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Handloom Cotton Bedsheet — King",
  "sku": "AK-BSK-4412",
  "mpn": "BSK-4412",
  "brand": { "@type": "Brand", "name": "Your Brand" },
  "description": "...",
  "image": ["https://..."],
  "offers": {
    "@type": "Offer",
    "url": "https://...",
    "priceCurrency": "INR",
    "price": "2499.00",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": { "@type": "OfferShippingDetails" },
    "hasMerchantReturnPolicy": { "@type": "MerchantReturnPolicy" }
  }
}

Rules for Indian catalogues:

• sku and mpn are valid identifiers. Populate both where you have them

• brand is required for products without a GTIN — never leave it empty

• In Google Merchant Center, set identifier_exists to false rather than fabricating a GTIN

• If you sell branded goods manufactured by someone else, the GTIN usually does exist — get it from the manufacturer rather than declaring absence

Variants: the decision most stores get wrong

A shirt in five colours and six sizes is thirty variants. Should each be a URL?

Default to one URL with variants. Split only where the variant attribute is genuinely a search term with volume behind it, and only if you will give the split page distinct content.

Use offers as a single Offer for a single price, or AggregateOffer with lowPrice and highPrice where variants differ.

Price and availability freshness

Structured data showing a price that does not match the page is a quality problem, and it is common on stores where schema is generated at build time and prices change dynamically.

Render schema from the same source as the visible price, at request time. Verify availability flips to OutOfStock when stock hits zero, and that priceValidUntil is not sitting in the past across the catalogue.

Want to know which of these four is actually costing you traffic? We run technical eCommerce audits that produce a crawl budget breakdown, a facet indexation map, a schema validity report across the catalogue, and Core Web Vitals by template — with a prioritised fix list your developers can work from.Book a technical SEO review →

Foundation 4: The Product Lifecycle Ledger

Every product eventually stops being sold. What you do at that moment decides whether you keep the link equity it accumulated over three years, or throw it away.

Most stores delete. Deleting is almost always wrong.

The seasonal rule is worth emphasising

Indian retail runs on cycles — Diwali, wedding season, monsoon, back-to-school, Republic Day sales. Stores routinely create a fresh URL each year (/diwali-sale-2026) and let last year's die.

That page spent a season earning links and rankings. Keeping one permanent URL (/diwali-sale) and refreshing its content annually means it enters each season with the authority of every previous season behind it. By year three, the difference is substantial.

Auditing your ledger

Run this quarterly: export all URLs returning 404 or 410 in the last quarter, cross-reference against Search Console for pages that had impressions or clicks, and against your backlink data for pages with referring domains. Anything that appears on either list was deleted in error. Restore it or redirect it.

Core Web Vitals, by Template

Speed work fails when it is treated as a site-wide project. It is a per-template problem, because each commerce template fails differently.

The fixes that actually move numbers on commerce sites

Reserve space for everything injected after load. Review widgets, offer banners, trust badges, sticky add-to-cart. Every one of these is a CLS incident when it arrives without a reserved box. On product templates this is usually the single biggest win available.

Preload the LCP image and never lazy-load it. The hero image on a product page and the first row of a category grid should load eagerly with fetchpriority="high". Lazy-loading the LCP element is the most common self-inflicted performance wound in commerce.

Serve modern formats at correct dimensions. WebP or AVIF, sized per breakpoint. A 3,840px product image delivered to a 390px viewport is bytes spent to make the page slower.

Audit third-party scripts quarterly. Analytics, chat, reviews, personalisation, retargeting, A/B testing. Commerce stores accumulate these and never remove any. Each one is main-thread work that shows up in INP.

Debounce filter interactions. On listing pages, re-rendering a 48-product grid on every checkbox click is the leading INP failure in commerce.

Measure against Core Web Vitals thresholds using field data in Search Console, not lab scores. Lab data tells you what is possible; field data tells you what your customers experience.

The India Context: What Global Guides Miss

Your store is indexed as it renders on a mid-range Android

Google indexes the mobile rendering of your site, on a simulated device that is considerably slower than the laptop your developers test on.

Practical consequences most Indian stores have not checked:

• Content loaded by JavaScript on scroll or interaction may never be seen by the crawler. Product descriptions inside collapsed accordions are usually fine if present in the DOM; content fetched only on tab click frequently is not

• If your mobile template shows less content than desktop, the reduced version is what gets indexed

• Structured data must be present in the mobile rendering

Test properly: throttle to slow 4G in Chrome DevTools, emulate a mid-range Android, and use the URL Inspection tool in Search Console to view the rendered HTML Google actually sees. Not a Lighthouse score on office wifi.

Query language is mixed and increasingly voice-driven

Indian commerce search runs across English, transliterated Hindi and regional languages, frequently mixed within a single query. Voice search is a growing share, which shifts queries towards natural-language phrasing and questions.

What this means practically: your product and category content should include the terms customers actually use, including colloquial and regional product names where they differ from catalogue names. A product listed as "Ethnic Wear Set" while customers search "salwar suit" is invisible for the demand that exists.

FAQ content answering full-sentence questions on category pages captures voice and long-tail demand that keyword-stuffed product copy does not.

COD, returns and trust signals affect commerce rankings indirectly

Not a ranking factor, but a conversion and engagement factor that shows up in behavioural signals. Indian buyers check return policy, COD availability and delivery timelines before purchasing. Surfacing these clearly on product pages — and marking up hasMerchantReturnPolicy and shippingDetails in schema — improves both rich result eligibility and on-page conversion.

Measuring the Right Things

Rankings and sessions are lagging indicators and poor diagnostics. For commerce, monitor these:

Server log analysis is the highest-value and least-used technique in Indian eCommerce SEO. It is the only way to see precisely what Googlebot is spending its time on. Most stores that run it for the first time discover that the majority of crawl activity is going to URLs nobody would want indexed.

A Real Scenario: When Structure Was the Whole Problem

A multi-brand beauty retailer had been adding brands steadily to stay competitive. Each new brand brought categories; categories bred subcategories; and the store quietly became something customers could not navigate. Conversion showed it before anyone diagnosed why.

The instinct was that the store needed more content and more traffic. The actual requirement was structural: seven core categories and more than sixty subcategories rebuilt around how customers shop a multi-brand catalogue, with merchandising logic designed in rather than bolted on.

The SEO lesson generalises well beyond beauty. Category architecture is simultaneously the customer's navigation and the crawler's map. When it fits how people search, both improve at once. When it does not, no amount of content compensates, because the content is being added to a structure that cannot distribute it.

Read the full case study →

Frequently Asked Questions

What is eCommerce SEO?

eCommerce SEO is the practice of making an online store's category, product and content pages discoverable and rankable in search. It differs from standard SEO because stores generate enormous numbers of URLs automatically through filters and pagination, inventory changes constantly beneath the index, and optimisation happens at template level rather than page level — a fault in a product template is a fault repeated across the whole catalogue.

How do I handle faceted navigation for SEO?

Decide per facet. Index only combinations people actually search for, such as brand within a category. Apply noindex, follow to single low-demand attributes so equity still flows to products. Block crawling entirely for any two-or-more facet combination, sort orders and tracking parameters. Remember that noindex pages are still crawled — if crawl budget is the problem, you must block at the crawl layer rather than the index layer.

Can I use product schema without a GTIN?

Yes. Use sku, mpn and brand as identifiers, and in Google Merchant Center set identifier_exists to false rather than fabricating a value. Most Indian D2C, handmade, industrial and private-label products have no GTIN, and inventing one is worse than declaring its absence. If you resell branded goods manufactured elsewhere, the GTIN usually does exist — request it from the manufacturer.

Should I delete discontinued products from my store?

Rarely. If a direct replacement exists, 301 to it. If the product has traffic or backlinks but no replacement, keep the page live at HTTP 200, mark it discontinued and link to alternatives. Only issue a 410 when the product has no traffic and no backlinks. Deleting a product that accumulated links over years discards that equity permanently.

What should I do with out-of-stock products?

Keep them live and indexed at HTTP 200, set schema availability to OutOfStock, show an expected restock date, offer a notify-me option and surface alternatives. Removing or redirecting a temporarily unavailable product forfeits rankings and links you will want back when it returns to stock.

How many products should I show per category page?

48 to 72 for most catalogues, up from the common default of 24. This directly reduces pagination depth and brings deep products closer to the homepage. Lazy-load images below the fold so the increased count does not damage LCP, and never lazy-load the first row.

Does site speed affect eCommerce rankings in India?

Core Web Vitals are a ranking signal, and they matter more in India because a large share of traffic arrives on mid-range Android devices over variable mobile networks — which is close to how Googlebot renders your site. Measure field data in Search Console by template group rather than lab scores on a laptop, and fix the worst-performing template first.

How do I know if crawl budget is my problem?

Check Search Console crawl stats for requests by URL type, and run server log analysis. If the majority of Googlebot activity is going to filter combinations, sort orders or parameter URLs rather than products and categories, crawl budget is being wasted. A second signal: new products taking weeks rather than days to appear in the index.

Should each product variant have its own URL?

Default to one URL with selectable variants, which consolidates equity. Split into separate URLs only where the variant attribute is genuinely how people search — colour often is, size almost never is — and only if you will give the split pages distinct content. Dozens of near-identical variant URLs create thin duplication.

What is the most common technical SEO mistake in Indian eCommerce stores?

Leaving faceted navigation fully crawlable. A store with four filters across sixty categories can generate millions of URLs, and Googlebot spends its allocation there instead of on products. The second most common is deleting discontinued products, which discards years of accumulated link equity in a single database operation.

Where This Leaves You

If organic traffic is disappointing and the response so far has been more content, run these four checks before writing another word.

Look at your crawl stats and see what Googlebot is actually spending its time on. Count the clicks to your deepest product. Validate product schema across a sample of the catalogue, not one URL. Pull Core Web Vitals field data grouped by template.

In most Indian stores at least two of those four return something uncomfortable, and fixing them is template-level work — which means the fix applies across the entire catalogue at once. That is the leverage in commerce SEO, and it is why technical foundations return more than content does until they are sound.

Once they are sound, content works, because there is finally a structure capable of distributing it.

We run technical eCommerce audits as a scoped engagement, producing a crawl budget breakdown, facet indexation map, catalogue-wide schema validity report and Core Web Vitals by template — with a prioritised fix list written for developers rather than marketers. As an eCommerce development company in India that builds custom commerce platforms, we treat search architecture as an engineering deliverable rather than something to add afterwards.

Akoode holds a 4.9 rating from 110 Google reviews and 5.0 out of 5 on GoodFirms, and is reviewed on Clutch 5/5

Book a technical SEO review →

Related reading

• eCommerce development company in India — our services

• Shopify vs custom eCommerce development: when migrating actually pays

• eCommerce development cost in India: 2026 pricing guide

• B2B eCommerce development in India

• Digital marketing and SEO services