Why Are Product Pages Not Indexed? Fixing Ecommerce Indexing Issues in Search Console

Why are product pages not indexed?

Product pages not indexed by Google usually fall into one of three cases: Google never found the URL, Google crawled it but judged it not worth indexing, or Google picked another URL as the canonical version. The blocker can be technical, such as noindex or JavaScript, or it can be about content, such as duplicate descriptions.

In practice, I see this problem in almost every online store audit. For example, the owner uploads hundreds of products, yet Search Console lists a large share of them as not indexed. In most cases there is no single dramatic error. Instead, several small issues stack on top of each other.

I have worked in SEO since 2012. This article does not cover ecommerce SEO in general; I wrote a separate guide to ecommerce SEO for product and category pages. Here I focus only on diagnosis: what each status means, which causes are specific to product pages, and how you fix them step by step with the URL Inspection tool.

Where do you see indexing problems for your store?

Your first stop is the Page indexing report in Search Console. The report splits every URL Google knows into two groups: indexed and not indexed. Under the not indexed group, each row names the reason that kept those URLs out of the index.

I recommend one habit here. Read the report for product pages, not for the whole site. The easiest way, in practice, is to submit a separate sitemap that contains only product URLs. Then you can filter the report by that sitemap and look at products alone. Otherwise, filter pages, tag archives and internal search URLs crowd the picture.

If you are new to the tool, I explain the main screens in my Google Search Console guide. The official definitions of every status live on Google's Page indexing report help page.

• Indexed count: Does it roughly match your number of live products?
• Largest reason row: The center of gravity of the problem usually sits here.
• Example URLs: Pick five to ten products under each reason and open them one by one.
• Timeline: Did the number jump overnight or grow slowly? A sudden jump often points to a release error.

What does each Search Console status mean for a product page?

The status names look alike at first glance. However, each one describes a block at a different stage: discovery, crawling, canonical selection or the final indexing decision. The table below summarizes the statuses I meet most often in online stores, with typical causes and a first move.

Therefore, treat the table as a starting point, not as a verdict. The same status can come from two different causes in two different stores. So confirm every row by opening the example URLs underneath it.

What does "Crawled - currently not indexed" mean?

This status tells you that Googlebot visited the page and then decided not to index it for now. In other words, there is no access problem. Google saw the page and passed on it. Google's help page also notes that these URLs may get indexed later and that you do not need to resubmit them for crawling.

In ecommerce, the most common reason is content value, because buyers compare the same items everywhere. Hundreds of stores copy the manufacturer's description word for word. From Google's point of view, most of those pages repeat each other. Therefore it sees no separate reason to add your version.

These are the first things I check in practice:

1. Does the product description appear word for word on other sites?
2. Does the page show decision points such as price, stock, delivery and returns?
3. Does the product get links from its category page and from related products?
4. Do several URLs of the same product compete in the index?

That said, the status can be temporary for a brand new store. As the site gains authority, Google tends to index more pages. Still, do not wait for a list that stays flat for months to fix itself. Make a concrete change on the content and linking side instead.

What does "Discovered - currently not indexed" mean?

Here Google knows the URL but has not crawled it yet. According to the official explanation, Google wanted to crawl the page but postponed it to avoid overloading the site. That is why the last crawl date in the report stays empty.

In a large catalog, a growing row usually signals wasted crawl budget. If Googlebot spends its time on filter combinations, sort parameters and session IDs, new products never get their turn. I explain how parameters spread crawling thin in my article on URL parameters and SEO.

Server response time also plays a role. A slow server leads Google to lower its crawl rate. I cover why crawl frequency drops and which signals to watch in the article on why Googlebot crawls less, so I will not repeat it here.

In short, when this row grows, ask two questions first. Am I showing Google unnecessary URLs? And do my products receive strong enough internal links? In most stores, both answers reveal room for improvement.

How do you read duplicate and canonical statuses?

When Google finds several URLs with the same content, it picks one as the canonical version and leaves the others out of the index. This is not a penalty, however. It is the normal process that keeps the same product from showing up five times in the results. The trouble starts when Google picks a URL you did not intend.

"Duplicate, Google chose different canonical than user" describes exactly that. Your canonical tag points to URL A, yet Google selects URL B. The usual cause is conflicting signals: internal links go to B, the sitemap lists B, and only the canonical tag says A.

My advice is to bring every signal together on one URL:

• Point the canonical tag at the clean product URL you want in the index.
• Send category pages and menu links to that same URL.
• List only that URL in the sitemap.
• Send any old addresses to it with a permanent 301 redirect.

On the other hand, "Alternate page with proper canonical tag" is usually not a problem. It means Google accepted the canonical you declared. If that list holds only variant or parameter URLs, and none of your main product URLs, you can relax.

How do noindex and robots.txt hide products?

Many teams mix up these two blockers, but they work differently. A noindex rule tells Google to crawl the page but keep it out of the index. robots.txt blocks crawling itself, so Google never reads the content. As a result, Google cannot see a noindex tag on a page that robots.txt blocks.

In online stores, however, noindex often arrives by accident. A team builds the shop on a staging site with search engines switched off, and nobody switches them back on at launch. Some plugins also add noindex to products that are out of stock or show a zero price. When I see the noindex row jump after a theme update, I check these settings first.

On the robots.txt side, broad patterns cause the most damage. For example, a rule meant to block cart and filter URLs can also catch a folder that product URLs share. Test which URLs a rule affects before you publish it. For a clean start, you can use the robots.txt generator.

Finally, remember the X-Robots-Tag in the HTTP header. The page source may look clean while the server response carries a hidden noindex. The live test in the URL Inspection tool shows this clearly.

Why do soft 404 errors hit product pages so often?

A soft 404 happens when the server returns a 200 (success) code but the page content says the page does not exist. According to Google's documentation on HTTP status codes, empty pages and pages without main content can also fall into this group. Google leaves these URLs out of the index and flags them as Soft 404 in the report.

On product pages, soft 404s have three typical sources, and each one needs a different fix. First, templates that say "product not found" for a discontinued item but still return 200. Second, themes that hide the description, price and images once stock runs out, which leaves an almost empty page. Third, pages whose content never loads when JavaScript throws an error.

Therefore, the fix depends on the real state of the product. If the product will come back, keep the page full and state the stock status clearly. If the product is gone for good, either return a real 404 or 410, or redirect with a 301 to a close replacement. You can read the full explanation in Google's documentation on HTTP status codes.

Also, avoid redirecting everything to the homepage in bulk. Google may treat irrelevant redirects as soft 404s too. When you build the mapping list, the redirect mapping tool speeds things up.

Why are out of stock product pages not indexed?

When you find out of stock product pages not indexed, the cause is rarely the stock itself. It is what happens to the page when stock runs out. Google does not drop an out of stock product on its own. However, if the page empties, returns an error code or receives noindex, it will fall out of the index.

Google's ecommerce documentation draws a clear line for temporary shortages: keep the page live, mark the product as out of stock and update availability in your structured data. Google's guide on pausing an online business also states that 403, 404 or 410 codes will remove URLs from Search.

That is why I want these elements to stay on a page whose stock has run out:

• Product name, description, images and specifications.
• A clear out of stock notice and, if known, an expected return date.
• A back in stock notification form.
• Links to similar and alternative products.
• Current availability in the Product structured data.

Instead of writing structured data by hand, you can build it with the schema generator and add it to your theme. A product that leaves the range permanently is a separate decision. You handle it with the 404, 410 or 301 options from the soft 404 section.

Why are variant product pages not indexed?

Most store owners who find variant product pages not indexed in Search Console share the same setup. Every color and size gets its own URL, but the content is nearly identical. As a result, Google treats these URLs as duplicates and picks one as canonical. The rest pile up in the duplicate rows.

Google's ecommerce URL structure guide accepts two patterns for variants: a path segment (/t-shirt/green) or a query parameter (/t-shirt?color=green). If you use optional parameters, it recommends the URL without the parameter as the canonical. The guide also carries an important warning: Google does not use fragment identifiers that start with # for indexing.

So if you show a variant only through a fragment such as #black, Google sees a single page. You can read the details in Google's guide to ecommerce URL structure.

In practice, I ask one question: do people search for this variant on its own? When color changes the search intent, as in "red evening dress", a separate variant page with unique content makes sense. For options like size, which rarely change intent, one main product URL is enough. That way you concentrate authority on one page instead of splitting it.

How do thin and duplicate descriptions affect indexing?

Put simply, thin content is a page that tells the reader nothing new. On a product page, that usually means three lines of manufacturer text, one image and a price. When Google chooses between dozens of pages selling the same item, it prefers the one that adds original information.

Keep this in proportion, though. Writing 1,000 words for every product is neither realistic nor necessary. What matters is that the page answers a real buyer's questions. For example, on a shoe page, fit notes, materials, care advice and return terms beat a long promotional text.

In a large catalog, prioritize. First, rewrite descriptions for best sellers and high margin products. Next, build a shared template for each category that defines which facts every product page must include. I describe the building blocks of a strong product page in my ecommerce product page guide.

Reviews also add unique text. Real customer reviews give every product page natural wording that competitors lack. That said, if the review block loads later through JavaScript, check separately whether that value actually reaches Google.

Does Google see content that JavaScript loads?

Google can process JavaScript, but the process has two stages and it is not always flawless. Google first crawls the HTML and then queues the page for rendering. If price, description or the product list appear only after JavaScript runs, an error or a timeout can hide that content from Google.

For instance, the riskiest ecommerce setup ties the whole product description or category list to an API call. If the API responds slowly, Google sees an empty template. The result often ends up as a soft 404.

The check is simple. Run the live test in the URL Inspection tool and open the tested page. Does the rendered HTML include the product name, price and description? Next, does the screenshot look complete? Finally, does the console show errors? These three questions separate most JavaScript issues within minutes.

Instead, the lasting fix is to render critical content on the server. Product name, price, description and category links should arrive in the first HTML response. I cover the speed and user experience side of JavaScript in the article on how JavaScript affects site speed.

How does weak internal linking leave products orphaned?

Put simply, an orphan page receives no links from any other page on the site. Google can learn about such a product only from the sitemap. It also tends to treat an unlinked page as unimportant. That is why orphan products often sit in the Discovered or Crawled rows.

In ecommerce, the most common cause is pagination that relies on buttons and "load more". Google's pagination guide is clear: its crawlers do not click buttons and generally do not trigger JavaScript that needs user action. So if page two of a category opens only through a button, Google may never reach the products on it.

Google recommends linking from each page to the next with a href tags and giving every page its own URL and its own canonical. It also advises against making the first page the canonical for the whole series. You can find the details in Google's pagination guide.

Beyond pagination, related product blocks, "customers also bought" sections and links from blog posts open extra paths to products. I explain how I plan this structure in my internal linking strategy article.

How much does a sitemap help product discovery?

A sitemap helps discovery, but it does not guarantee indexing. You tell Google that these URLs exist and matter to you; Google still makes the call. Even so, a well built sitemap helps a large catalog get new products discovered much faster.

For example, these are the product sitemap mistakes I see most often: discontinued URLs that return 404, old addresses that redirect, pages that carry noindex and variants whose canonical points elsewhere. As long as these URLs stay in the sitemap, you send Google mixed signals. The sitemap should list only canonical, indexable URLs that return a 200 code.

Another tip: use separate sitemaps for products, categories and content. Then you can track the indexing rate of products on its own in the Page indexing report. When a product changes, update the lastmod value honestly. I explain how in the article on the sitemap lastmod tag.

If you have no sitemap solution yet, start with the XML sitemap generator. For large stores, though, the platform itself should generate the sitemap automatically from the product database.

How do you diagnose a product URL step by step with URL Inspection?

The report gives you the big picture; the URL Inspection tool tells the story of a single product. In practice, the tool offers two views: the indexed version and the live test. The indexed version shows what Google last knew, while the live test shows the page as it is right now.

1. Enter the URL: Paste the full product address into the inspection bar at the top of Search Console.
2. Read the status: Does it say "URL is on Google" or "URL is not on Google"? Note the reason and the last crawl date.
3. Compare canonicals: Do the user-declared canonical and the Google-selected canonical match?
4. Run the live test: Does robots.txt or noindex block the page right now?
5. View the tested page: Check the HTML for product content, the HTTP response for X-Robots-Tag and the console for errors.
6. Fix and test again: Solve the issue at its source, then rerun the live test.
7. Request indexing: For important products, submit an indexing request.

Google's help page adds a few warnings. "URL is on Google" does not guarantee that the page will appear in results. The live test does not guarantee indexing either; it only shows that nothing blocks the URL. See the URL Inspection tool help page for details.

When do indexing requests and fix validation actually help?

An indexing request suits a handful of important pages; it is not a bulk fix. Google states that there is a daily limit on requests. It also says that a request does not guarantee indexing and that the process can take much longer than a day. Sending requests one by one for hundreds of products wastes your time.

For bulk issues, the right tool is the Validate fix button in the Page indexing report. You press it after you have fixed the issue behind a reason row across all affected URLs. Google then rechecks those URLs and notifies you of the outcome. The help page notes that this can take several days or longer.

My workflow looks like this. First, I find the root cause through example URLs. Then I fix it at template or settings level and check five to ten URLs with the live test. If everything looks clean, I start validation. For the few most critical products, I also send an indexing request.

Also note that validation rarely makes sense for crawled but unindexed pages. There is no technical error there; Google made a value judgment. You shrink that row over weeks through better content and internal links.

Which product URLs do not need to be in the index?

Getting every URL indexed is not the goal, because some pages add no search value. On the contrary, keeping unnecessary URLs out helps Google crawl your important products better. Trying to push the not indexed count to zero is therefore the wrong target.

These URL types can stay out of the index without any harm:

• Filter and sort combinations, such as sort by price or multi color filters.
• Variant URLs that point to the main product with a canonical tag.
• Cart, checkout, account and wishlist pages.
• Internal search result pages.
• Old products that left the range for good and return 404 or 410.

What matters is that your real selling product URLs do not sit on this list. When I read the report, I always ask the same question: among the excluded URLs, is there a product I want customers to find on Google? If the answer is no, that row is not a problem; it is a healthy filter.

How do you prioritize fixes for product pages not indexed?

Several answers can be true at once when you find product pages not indexed. So I order the work by impact. You handle site wide blockers first, then template errors, and content quality last.

1. Site wide blockers: Global noindex, broad robots.txt rules, server errors.
2. Template errors: Pages that empty out when stock ends, wrong canonicals, content tied to JavaScript.
3. Discovery issues: Button based pagination, orphan products, a messy sitemap.
4. Duplicate management: A clear strategy for variants and parameters.
5. Content value: Original descriptions, starting with best sellers.

As a result, this order lets you rescue the most products with the least effort. A single theme setting can bring back hundreds of products at once. Content work, by contrast, moves product by product and pays off more slowly.

Why do products disappear after a migration or redesign?

In practice, a large share of indexing problems start right after a platform change or a theme refresh. The URL structure changes, old addresses lack redirects or end up in chains, and the new theme outputs canonical tags differently. The date of a sudden spike in the report often matches the release date.

In that situation, my first step is to compare the old and new URL lists. Does every old product address reach the right new address in one hop? Redirect chains slow crawling and weaken signals; I cover them in the article on redirect chains. For the full move, see my website migration SEO checklist.

Add three checks to every post migration list: does the new theme carry noindex, do canonical tags point to the right URLs, and does the sitemap list the new addresses? These three checks prevent most migration related index losses.

When should you bring in professional help?

In a store with a few hundred products, you can apply the steps above yourself. Once the catalog reaches tens of thousands of products, however, issues start to overlap. Log analysis, template level development and platform settings all come into play at the same time.

A few signs tell you it is time to get help: the crawled but not indexed list has not shrunk for months, validation keeps failing, or product traffic does not recover after a migration. In our SEO consulting work, my team and I first read the indexing report and server logs together, then plan fixes by impact.

If broader store growth is also on the table, we look at catalog structure, product data and marketplace balance as part of our ecommerce consulting. The goal always stays the same: products that sell should be easy to find on Google.

Conclusion: indexing is a quality decision

Above all, Google does not promise to index every page of any site. It makes a separate decision for each product page, and accessibility, uniqueness and value all shape that decision. Removing technical blockers is the first half of the job. The second half is making the page worth indexing.

To sum up, keep this sequence in mind. Filter the report with a product sitemap, start with the largest reason row, open example URLs in the URL Inspection tool and fix issues at the source. Then start validation and track the outcome weekly.

With this discipline, the not indexed list turns into a meaningful filter over time. What remains there are URLs you keep out on purpose, while your selling products take their place in search.