Discovered, Currently Not Indexed: Why Google Has Not Crawled Your Pages

“Discovered, currently not indexed” in Google Search Console means Google knows the URL exists but has not crawled it yet. It found the link somewhere, usually in your sitemap or on another page, and put it in a queue. It has not fetched the page, so it has not judged its content. That makes this status different from “Crawled, currently not indexed”, where Google read the page and decided not to index it.

The distinction matters because the fixes are different. When a page has been crawled and rejected, the question is about the page itself. When a page has only been discovered, the question is about your site as a whole: how much Google wants to crawl it, how easily it can, and how clearly you are signalling which URLs matter.

What Google is actually telling you

Google’s own documentation describes this status as a URL that was found but not yet crawled, often because crawling the site at that moment was expected to overload it, so the crawl was rescheduled. In practice, the server load explanation applies to a small share of sites. For most small and mid-sized business websites, a long list of discovered but unindexed URLs points to one of three things.

The first is low crawl demand. Google decides how often to crawl a site partly on how popular and how frequently updated it appears to be. A new domain, or a site with few links pointing to it, simply gets less attention.

The second is a crawl queue full of URLs that should not be there. Filter parameters, tag archives, internal search results, paginated duplicates and old staging URLs can all compete for the same limited attention as your real pages.

The third is weak internal signals. If a page is only reachable through the sitemap and almost nothing on your own site links to it, Google has little reason to treat it as important.

When you can safely ignore it

Not every URL in this report needs fixing. Before doing any work, export the list and sort it into three groups.

• URLs you do not want indexed. Parameter URLs, feed URLs, attachment pages, cart and account pages. These should be removed from sitemaps and, where appropriate, blocked or consolidated. Their presence is a symptom, not a goal.
• Recently published pages. A blog post or product page published in the last week or two may simply be waiting. Check again before acting.
• Pages that matter and have been waiting for weeks. Service pages, key category pages and substantial articles. These are the ones worth investigating.

If the third group is small and the first group is large, your problem is mostly housekeeping. If the third group is large, you have a crawl prioritisation problem.

Diagnosing the cause

Check how your sitemap is built

A sitemap should list the canonical, indexable URLs you want in search. Many CMS setups generate sitemaps that include tag pages, author archives, image attachment URLs or pages marked noindex. Each of those sends Google a mixed message. Open the sitemap index, review each child sitemap, and confirm that every URL type in it is one you want ranked.

Look at the Crawl Stats report

Under Settings in Search Console, the Crawl Stats report shows total crawl requests, average response time and the breakdown of what Googlebot fetched. Two patterns are worth looking for. A high average response time, often above one second, suggests the server is slowing crawling down. A large share of requests going to parameter URLs, redirects or 404s suggests crawl attention is being wasted.

Count internal links to the affected pages

Pick ten important URLs from the discovered list and check how many internal links each one receives from crawlable pages. Search Console’s Links report, or a crawler such as Screaming Frog, will show this. Pages with zero or one internal link are common in this report. Pages linked from the main navigation or from strong existing articles rarely are.

Consider the site’s overall quality signals

If a site publishes a large number of similar pages in a short period, Google may slow crawling while it assesses whether that content is worth the effort. This is common after bulk publishing location pages or programmatically generated product variants. The pages are not rejected yet. They are simply not a priority.

How to fix it, in order of impact

Start with the changes that remove noise, then strengthen the pages that matter.

Clean the sitemap. Remove noindexed, redirected, canonicalised and low-value URL types. A sitemap of 300 strong URLs is more useful than one of 3,000 mixed URLs.

Reduce crawlable duplicates. Faceted filters and sort parameters are the usual offenders on ecommerce sites. Consolidate them with canonical tags, stop linking to unnecessary parameter combinations, and use robots.txt rules carefully for URL patterns that should never be crawled. Be cautious here: blocking a URL in robots.txt stops crawling but does not remove an already indexed URL, and it prevents Google from seeing a canonical tag on that page.

Link to important pages from pages Google already crawls. Add contextual links from your homepage, relevant service pages and established articles. One well placed link from a frequently crawled page usually does more than a sitemap resubmission.

Improve server response. If Crawl Stats shows slow responses, look at hosting, caching and heavy plugins. Our guide on why a website is slow covers the common causes on WordPress and Shopify sites.

Request indexing selectively. The URL Inspection tool lets you request indexing for individual URLs, with a daily limit. Use it for genuinely important pages after the fixes above, not as a substitute for them.

What not to do

Resubmitting the same sitemap repeatedly does not speed anything up. Third party “instant indexing” services that ping Google through unofficial routes are unreliable at best. Google’s Indexing API is officially supported only for job posting and livestream structured data pages, so using it for blog posts or service pages is outside its intended use.

Deleting pages because they are stuck in this report can also be a mistake. If the page is useful and simply under-linked, the fix is better linking, not removal.

How long should recovery take?

After cleaning sitemaps and improving internal links, most sites see the discovered list start to shrink within a few weeks, though there is no fixed timeline. Large sites with heavy duplication can take longer because Google has to recrawl and reassess many URL patterns. Track the count weekly in the Page indexing report and, more importantly, check whether your priority pages have moved into the indexed group.

If pages move from “discovered” to “crawled, currently not indexed”, that is progress of a kind. Google is now reading them, and the next question becomes content quality and duplication, which we cover in our guide to crawled, currently not indexed.

Getting important pages crawled and indexed

A persistent “discovered” list is usually a sign that the site’s structure is asking Google to do too much guessing. Fixing it involves sitemap configuration, crawl waste, internal linking and server performance working together, which is why it tends to sit with technical SEO rather than content.

If your key service, product or category pages have been waiting for weeks and you are not sure where crawl attention is going, our technical SEO service starts with exactly that analysis: what Google is crawling, what it is ignoring and which changes will move your priority pages into the index first.