Discovered – Currently Not Indexed: Why Google Hasn’t Crawled Your Page Yet

The short answer

“Discovered – currently not indexed” means Google knows the URL exists — it found it in your sitemap or in a link — but hasn’t crawled it yet. No one at Google has looked at the page’s content, so this isn’t a verdict on it. Google’s explanation in the Page indexing report is that it wanted to crawl the URL but expected that to overload the site, so it rescheduled. On small sites that’s rarely the literal reason; more often the page simply hasn’t earned a place near the front of the crawl queue. New pages usually clear it on their own within a few weeks. If a lot of URLs sit here for a long time, the fix is to give Google fewer, better URLs to choose from and clearer signals about which ones matter.

Discovered vs. Crawled: the difference that matters

The two statuses look alike, and the fixes are different, so it’s worth being precise:

If your URLs are in the other bucket, the guide to Crawled – currently not indexed covers that case.

What it looks like on a real site

On 23 October 2026, URL Inspection on this site reported our YouTube Description Generator as Discovered – currently not indexed. It’s listed in the sitemap, but there was no last-crawl date and Google listed no referring pages: it knew the URL from the sitemap and had not fetched it once.

A useful contrast from the same day: the Hash Generator, whose only referrer Google listed was also the sitemap, was Submitted and indexed. So “sitemap only” doesn’t doom a page — but it does leave it at the mercy of how Google prioritises the rest of your site. Pages with links from indexed, visited pages get picked up first. That’s the lever you control.

Why Google hasn’t crawled it yet

• Too many URLs competing for attention. Parameter URLs, filtered and sorted listings, tag archives, calendar pages and session IDs multiply the number of addresses Google could fetch. Google’s crawl budget guide calls perceived inventory the factor you can most control, and says duplicate or unwanted URLs waste crawling time.
• Weak internal linking. A URL Google only knows from the sitemap has nothing telling it the page matters. Links from pages that are indexed and get traffic move it up the queue.
• A noisy sitemap. Sitemaps full of redirects, 404s, noindexed or canonicalised-away URLs teach Google that your sitemap isn’t a reliable list of pages worth crawling.
• A slow or struggling server. This is the case Google’s wording describes literally. The crawl budget guide says slow responses, server errors and rate-limiting responses such as HTTP 429 lower how much Google is willing to crawl.
• Site-wide quality signals. If many pages Google already crawled weren’t worth indexing, it has less reason to hurry for the next ones. On a small site that keeps publishing pages that land here, look at the quality of the pages that were crawled.

Is this a crawl budget problem?

Usually not, unless your site is big. Google’s crawl budget guide says it’s written for sites with roughly a million or more unique pages that change weekly, or 10,000+ pages that change daily — and for sites with a large share of URLs in this exact status. If you run a 300-page site, Google can crawl all of it easily; a backlog here is about priority, not capacity. The fixes overlap, though: fewer junk URLs, faster responses and better links help sites of every size.

When to wait and when to act

Wait if the URLs are new (published in the last two to four weeks), there are only a few of them, and the count isn’t growing. Google’s own guidance is that crawling can take anywhere from a few days to a few weeks.

Act if important pages have been here for more than a month, if the number in this row keeps climbing, or if it’s large compared with the number of pages you actually have. A row with 40,000 URLs on a site with 2,000 real pages points at URL bloat, not at those 2,000 pages.

How to fix it

Quick checks from a terminal

# How many URLs does the sitemap list?
curl -s https://example.com/sitemap.xml | grep -c "<loc>"

# Do they all answer 200? (prints anything that doesn't)
curl -s https://example.com/sitemap.xml | grep -o "<loc>[^<]*" | sed 's/<loc>//' \
  | xargs -n1 -P8 curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" | grep -v "^200"

# How fast does the server answer? (time to first byte, in seconds)
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/

Without a terminal, the Robots.txt Checker shows which paths you block, the Broken Link Checker finds dead internal links on a page, and the Page Speed Check measures how quickly the server responds.

Why “Request indexing” and “Validate fix” don’t solve it

Both feel like the obvious button to press, and both have limits. Request indexing puts one URL in a priority queue — useful for a few pages, but it’s capped and doesn’t change why the rest are waiting. Google is also explicit that requesting a crawl doesn’t guarantee the page will be included in search results at all.

Validate fix asks Google to recheck every URL in the row. Google says validation typically takes up to about two weeks and sometimes much longer, and it can only pass once the URLs are actually crawled. Start it after you’ve cleaned the sitemap and fixed internal links, not instead of doing so.

When it’s fine to ignore

If the URLs in this row are ones you don’t want in search — filtered listings, internal search results, old paginated pages — their sitting here costs you nothing as long as the count isn’t exploding. Google’s help page for the report says not to expect every URL on a site to be indexed. Focus on the pages you’d want a searcher to land on.

If your Page indexing report shows other reasons too, the overview of every “Why pages aren’t indexed” reason explains each one, and the XML sitemap guide covers the sitemap errors Google actually cares about.