Ecommerce Indexing - Why Google Is Not Indexing Your Products and Categories and How to Fix It

Ecommerce indexing comes down to which sales pages Google has in its index, which ones it skips and why. The rule to start with: calculate the share of categories and products from your sitemap that are indexed. If it is below about 80%, check which status dominates in Search Console. "Discovered - currently not indexed" means Google has not reached the pages (linking, performance, too many URLs), while "Crawled - currently not indexed" means it reached them and judged them low value (duplicates, empty product pages). Keep a temporarily unavailable product live with a 200 status and OutOfStock availability. Redirect a discontinued product that has traffic or links with a 301 to its successor or category, and return 404 or 410 when it has neither.

Why Google is not indexing products and categories: Search Console statuses translated into store causes, Discovered vs Crawled - currently not indexed, unavailable and discontinued products, variants, the sitemaps of 30 Polish stores, a URL Inspection API script and the lastmod pitfall.

This post covers how to measure the indexing of sales pages, what each Page indexing report status means in a store, how to tell "Discovered" from "Crawled", what to do with unavailable and discontinued products, how to handle variants, the results of my check of sitemaps in Polish online stores, a script for measuring indexing through the Search Console API and the lastmod pitfall.

Is missing indexing a problem at all - the first decision

Not every unindexed URL is a problem. Google says plainly that most sites have a few unindexed pages and that "Not indexed" is not necessarily bad - the index should hold canonical pages, not every URL in the store. The problem starts only when pages meant to sell are missing.

How to measure the share of indexed sales pages: split the sitemap into separate files for categories and products, submit them in Search Console and filter the Page indexing report by each file. You get indexed and unindexed counts separately for categories and products, instead of one number for the whole site with filters and terms pages mixed in.

Search Console statuses - what they mean in a store and how to fix them

The most important table in the post. I translated every Page indexing report status into typical store causes and fixes.

After a fix, click "Validate fix" in the report. Google says validation usually takes up to about two weeks, sometimes longer.

"Discovered" or "Crawled" - a decision tree

These two statuses sound alike but have different causes and fixes. This is how I diagnose them:

1. 1.Do most unindexed products show "Discovered - currently not indexed"? Google has not fetched them yet. Check the Crawl stats report: how many URLs Googlebot fetches a day and the server response time. If the crawler mostly fetches filter and parameter URLs, start there. If response time is rising, the server is the problem.
2. 2.Are products linked only from deep pagination pages? Add links from categories, subcategories, a "new arrivals" section and related products. Google recommends linking to every product you want indexed.
3. 3.Does "Crawled - currently not indexed" dominate? Google fetched the pages and skipped them. Compare a few such product pages with indexed ones: they usually differ in the length and uniqueness of the description, the number of attributes, photos and reviews, or they are a variant of another product.
4. 4.Does "Crawled" affect categories? Check whether the category has enough products and is not almost identical to another one (e.g. two categories with the same listing). Merge or remove empty and duplicated categories.
5. 5.Do pages show a "Duplicate" status? That is not a quality problem but a URL problem: the same product under several URLs. Pick one URL and align the canonical, links and sitemap.

I cover how Google allocates crawling resources in more detail in the post about crawl budget.

Unavailable and discontinued products - what to do with the page

The most common question in my work. The answer depends on whether the product will return, whether it has a successor, and whether its page has traffic or external links.

Two things to remember. First, Google treats all 4xx codes (except 429) the same, so choosing between 404 and 410 makes no practical difference - indexed URLs returning 4xx drop out of the index. Second, redirecting a discontinued product to the home page or an unrelated category often ends up as a soft 404. Redirect only where there is a genuinely similar product.

Product variants - one URL or many

Sizes and colours can multiply the number of URLs. The rule: only a variant that people search for separately gets its own indexable URL (e.g. colour in fashion, storage in electronics). Other variants are a parameter on one product page or separate URLs with a canonical to the main product.

I will show how to describe variants in structured data (ProductGroup, hasVariant) in a separate post in this series.

A sitemap for a large catalogue

A sitemap does not guarantee indexing, but for a store with thousands of products it is the main source of information about new and changed pages. Google's rules: one file holds at most 50,000 URLs or 50 MB, the sitemap should list the canonical URLs you want to see in results, Google ignores priority and changefreq, and it uses lastmod only when it is consistently accurate.

What Polish store sitemaps showed - my check

How I checked: on 22 October 2026 a script read the sitemaps of 30 Polish online stores (from robots.txt, or from /sitemap.xml when robots.txt listed none). For each store it drew 40 URLs from the product sitemap files and checked the HTTP status (without following redirects), meta robots, the X-Robots-Tag header and canonical. Separately, I checked lastmod dates in up to three sitemap files per store. I could check HTTP statuses in 20 stores (800 URLs) and lastmod dates in 23. The other stores blocked automated fetching or their sitemaps could not be read.

Takeaways:

• Large stores rarely have 404s in their sitemaps, but often have redirects. The usual cause is a changed product or category URL without a sitemap update. A single redirect does no harm, but when it affects half the sample, the crawler fetches thousands of URLs a day that will never be indexed, and the "Page with redirect" count in the report keeps growing.
• lastmod is the weakest part of sitemaps. In 9 of 23 stores it is useless: today's date everywhere, the same date everywhere, or missing. Only 14 stores give dates that can actually help Google find changed products.
• noindex in a sitemap is a conflicting signal - the sitemap says "index", the page says "do not index". It was rare in the sample, but in a large catalogue even 1-2% means hundreds of such URLs.

Limitations: this is a sample of 40 URLs per store and up to three sitemap files per store for lastmod, and I checked canonical and noindex in the raw HTML without running JavaScript.

How much work - two scales

An estimate from my quotes (October 2026) for diagnosing and fixing indexing, excluding rewriting product page content.

I run this kind of diagnosis and these fixes for stores as part of my ecommerce SEO work - always starting with a sample of URLs from the sitemap, as in the script below.

Script: the share of indexed products through the Search Console API

The report in the interface shows statuses, but not for a sample of URLs you choose. The script takes URLs from the sitemap, draws a sample and checks each through the URL Inspection API. The API limit is 2,000 inspections a day per property, so for a large store you check a sample, not everything.

# pip install google-api-python-client google-auth requestsimport collections, random, re, requestsfrom google.oauth2 import service_accountfrom googleapiclient.discovery import buildSITE = "sc-domain:yourstore.com"SITEMAPS = {"categories": "https://yourstore.com/sitemap-categories.xml",            "products": "https://yourstore.com/sitemap-products-1.xml"}SAMPLE = 200  # per page type; API limit: 2,000 a day per propertycreds = service_account.Credentials.from_service_account_file(    "sa.json", scopes=["https://www.googleapis.com/auth/webmasters.readonly"])gsc = build("searchconsole", "v1", credentials=creds)for kind, sm in SITEMAPS.items():    urls = re.findall(r"<loc>\s*([^<\s]+)\s*</loc>", requests.get(sm, timeout=30).text)    sample = random.Random(1).sample(urls, min(SAMPLE, len(urls)))    states = collections.Counter()    for u in sample:        res = gsc.urlInspection().index().inspect(body={"inspectionUrl": u, "siteUrl": SITE}).execute()        idx = res["inspectionResult"]["indexStatusResult"]        states[idx.get("coverageState", "no data")] += 1    ok = sum(v for k, v in states.items() if k.startswith("Submitted and indexed") or k.startswith("Indexed"))    print(f"\n{kind}: {len(urls)} URLs in the sitemap, sample {len(sample)}, indexed {ok / len(sample):.0%}")    for state, n in states.most_common():        print(f"  {n:4d}  {state}")

The output is the share of indexed pages separately for categories and products, plus the most common statuses in the sample, which point straight to a row in the status table. Run it monthly and keep the results to see the trend.

Production pitfall: lastmod set to today

The most common mistake in store sitemaps: the generator writes the current date into lastmod every time the sitemap is generated, for all URLs at once. It looks as if the whole catalogue changes every day. In my check, 3 of 23 stores did this. Google uses lastmod only when it is consistently and verifiably accurate, so such a date stops meaning anything, and the store loses the simplest way to point the crawler to new and changed products.

The fix: take lastmod from the store database and update it on changes that matter to the buyer - price, availability, description, photos. A footer change, a copyright year or a stock recount without an availability change are not significant changes.

What not to do

• Do not fight to get every store URL indexed - the index should hold sales pages, not filters and parameters.
• Do not manually submit hundreds of URLs through URL Inspection - it does not fix the cause.
• Do not return 404 for temporarily unavailable products.
• Do not redirect discontinued products to the home page.
• Do not keep redirects, 404 URLs and noindex pages in the sitemap.
• Do not set lastmod to today's date for the whole catalogue.
• Do not click "Validate fix" repeatedly - Google asks you to wait for the result.

FAQ

I describe the order of all store work in the ecommerce SEO strategy. If you want me to diagnose your store's indexing and implement the fixes, see ecommerce SEO.