Problem
Discovered currently not indexed on an ecommerce site: how to fix it
This status means Google knows the address exists and has not crawled it. It is a decision about priority, not an error you can appeal. On a store it almost always means one of two things: the site is producing more addresses than its authority and server capacity justify crawling, or the pages in question look, from their links and their neighbours, like they will not be worth the request.
By CartKernel · Last reviewed 2026-09-07
Does this look familiar?
- A large group of product or collection addresses sits in this status in the coverage report
- The affected pages have never been crawled, so there is no last crawl date to inspect
- New products stay in this status for weeks while older pages are recrawled regularly
- The count grew after a catalogue expansion, a filter rollout or a bulk import
- Requesting indexing for individual pages works, but the group as a whole does not move
- Server response times are slow under crawler load, or the host limits request rates
Causes, ranked
Why it happens, most common first
Check them in this order. The first two account for most cases we open.
- most common
The site publishes far more addresses than it can support
Filter combinations, sort parameters, collection scoped product paths and internal search results all compete for the same crawl activity as real products. When the address space runs into hundreds of thousands, the newest and least linked pages are the ones left waiting.
- most common
The pages are weakly linked from the site
A product reachable only through a sitemap, or sitting on the fifth page of a paginated collection, receives almost no internal signal. Crawl priority follows links, so pages with few internal paths to them queue behind pages with many.
- common
The server is slow or unreliable under crawler load
Crawl rate adapts to how the site responds. Slow responses, timeouts or error rates during crawling cause the rate to be reduced, which lengthens the queue for everything. This is common on shared hosting and on stores with heavy uncached category pages.
- common
The pages resemble ones already judged low value
When many similar addresses have already been crawled and found thin or duplicative, the remaining ones inherit a low expectation. Catalogues built from a supplier feed with identical descriptions and near identical variants are the usual case.
- common
The sitemap is stale, oversized or inaccurate
A sitemap listing redirected, removed or non canonical addresses wastes the signal it is meant to carry. One enormous file, or a file that never updates its dates, gives no useful priority information for a large catalogue.
- occasional
The site is new or has little external authority
Crawl capacity is allocated in proportion to how established a site appears. A recently launched store with a large catalogue will always find that most of it waits, regardless of how well the pages are built.
The fix
In this order
Each step is something you can do today. Do them in sequence; skipping ahead is how a review fails twice.
Prevent it next time
- Add every new product to at least one collection and one related products module at launch
- Keep sitemaps generated from canonical, indexable addresses only, split by page type
- Watch crawl statistics for response time and error rate as an ongoing health metric
- Decide the indexing rule for any new address pattern before it is built
Separate the pages you want indexed from the noise
Export the affected addresses and group them by pattern. Filters, parameters and duplicates should not be indexed at all and need excluding rather than promoting. Only the genuine product and category pages belong on the list you work on.
Reduce the address space competing for attention
Apply indexing directives to filter combinations, point display variations at their canonical, stop linking internal search results, and remove parameter addresses from sitemaps. Every address you retire returns capacity to the pages that matter.
Link the waiting pages properly
Add the affected products to relevant collections, feature them in related product modules, link them from category copy where appropriate, and shorten the click depth so no product sits more than three steps from the homepage.
Rebuild the sitemaps to be accurate and split
Generate sitemaps containing only canonical, indexable, live addresses, split into files by page type, with modification dates that reflect real changes. Submit them and monitor the indexed count per file, which turns the report into a diagnostic.
Make the server fast under crawler load
Check crawl statistics for average response time and error rate, then reduce both. Cache category pages, resolve slow database queries, and lift host request limits. A faster site is crawled more, which is the most direct lever available.
Improve the pages so they are worth the crawl
Replace supplier text with descriptions that carry your own specifics, add attributes shoppers filter on, include images and shipping detail, and give near identical variants a reason to exist as separate pages or consolidate them.
Prompt discovery for a representative sample
Use the inspection tool to request indexing for a handful of the affected pages. This is not a scalable fix, but if the sampled pages index and hold, it confirms the pages themselves are acceptable and the problem is priority.
Track the count monthly and expect slow movement
Record the number in this status each month alongside total indexed pages and average crawl response time. Improvement shows as the status count falling steadily rather than clearing at once, over a period of months.
When to get help
Get help when a large share of the catalogue has never been crawled and the store depends on organic traffic for products that cannot be advertised profitably. Resolving it needs a crawl budget analysis using server logs, a decision about which pages should exist at all, and often a change to how the catalogue is structured rather than a set of on page edits. That work pays off most on stores with tens of thousands of products, where the difference between a crawled and an uncrawled catalogue is most of the addressable demand.
Free. We reply within one business day.
How is this different from crawled currently not indexed?
Discovered means the page has not been fetched at all, so the issue is crawl priority. Crawled means it was fetched and then not selected for the index, so the issue is the page itself: thin content, duplication or low value relative to what is already indexed. The fixes barely overlap.
Will requesting indexing for every affected URL solve it?
No. The inspection tool is rate limited and designed for individual checks, and pages pushed through it can drop back out if the underlying priority problem remains. Use it to test whether a sample indexes, then spend the effort on links, crawl capacity and page quality.
Does adding pages to a sitemap make them get crawled?
A sitemap helps discovery but does not create priority. Pages already discovered are, by definition, already known. What changes priority is internal linking, site speed, reducing competing addresses and giving the page something worth fetching.
How long should improvement take on a large catalogue?
Expect months. Crawl rate adjusts gradually, and a catalogue of tens of thousands of pages takes time to work through even at a healthy rate. Judge progress on the trend in the status count and in crawl requests per day rather than on any single week.
Services that fix it for good
Related problems, answers and terms
Stop the leak.
A free Growth Analysis finds what is broken and ranks it by the revenue it costs you.