Discovered - Currently Not Indexed: Why Google Won't Crawl

You opened the Page indexing report, and there it is: a stack of URLs sitting under Discovered - currently not indexed. Your writer wants to rewrite them. Your agency wants to sell you a content refresh. Both are about to burn a month of your budget on the wrong problem.

Before anything else, check you are reading the right row. Two statuses look almost identical and they have opposite fixes. If your report says Crawled - currently not indexed, Google read the page and passed on it - that is a quality and duplication problem, and you want the fix for 'Crawled - currently not indexed' instead. Stay here only if the word is Discovered.

What does 'Discovered - currently not indexed' actually mean?

It means Google knows your URL exists and has never fetched it - not once. Google's Page indexing report documentation defines the status as 'The page was found by Google, but not crawled yet,' and adds: 'Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.'

That empty last-crawl date is the whole diagnosis. Open the URL in the URL Inspection tool and look at 'Last crawl' - the field Google defines as 'the last time this page was crawled by Google.' Blank means Googlebot has read zero words of that page. Everything you believe about how good the page is, is information Google does not have.

Same report, same panel, two different jobs. Confusing them is how a plumbing site ends up rewriting 40 service pages Google never opened.

Why is rewriting the page a waste of time here?

Because the rewrite changes an input Google never sampled: zero of your words have reached Googlebot, so a better H1, a longer body, and a shinier FAQ all land in a file nobody has downloaded.

There is one honest wrinkle. Google's crawl-budget documentation says Googlebot's demand 'varies based on a site's size, update frequency, page quality, and relevance, compared to other sites.' Quality is in there - but at the site level, judged on the pages Google has already crawled. So sitewide quality can suppress crawl demand for a page Google has not read yet. What cannot help is polishing the specific unread URL.

Practical translation: if 60 of your 80 pages are indexed and thin, fix or delete those 60. That is a crawl-demand move. Rewriting the 20 unread ones is not.

How many clicks from the homepage is your page - and why does that decide it?

Google publishes no click-depth threshold, so treat this as an operator rule, not a law: we keep every page we want indexed within 3 clicks of the homepage with at least one in-content link from an already-indexed page. Pages at 4+ clicks with zero inbound internal links are the ones that sit in Discovered for months.

A URL that only exists in your XML sitemap is discovered. It is not endorsed. The sitemap tells Google the page exists; internal links tell Google you think it matters. A blog post reachable only from page 6 of a paginated archive is, in crawl terms, an orphan with a birth certificate.

• Crawl your own site (Screaming Frog free tier does 500 URLs) and sort by 'Crawl Depth.' Anything at depth 4+ is a suspect.
• Cross-reference: export the Discovered - currently not indexed list from Search Console and match it against the depth-4+ list. The overlap is your work order.
• Give each stranded URL 2-3 real in-content links from indexed pages that already get impressions - not a footer link block, not a 'related posts' widget.
• Build hub pages. One indexed hub linking to 15 stranded URLs beats 15 orphans linked from nowhere.
• Re-crawl in 7 days and confirm depth actually dropped. Half the time the link went in a component that renders client-side and Googlebot never saw it.

This is bread-and-butter technical SEO, and it is the single highest-yield hour on a stuck site. Our technical SEO audit walkthrough covers the crawl-and-map process end to end.

Does a small site even have a crawl budget problem?

Almost never on page count alone - Google's crawl-budget guide is aimed at sites with 1 million+ unique pages changing weekly, or 10,000+ pages changing daily, and it opens by saying that if 'your pages seem to be crawled the same day that they are published, you don't need to read this guide.'

But read the third bullet of who that guide is for: 'Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed.' No size floor. Google is explicitly telling small sites with this status that they are in scope. Your 200-page site does not have a capacity problem - it has a demand problem.

Google lists three drivers of crawl demand: perceived inventory, popularity ('URLs that are more popular on the Internet tend to be crawled more often'), and staleness. A domain launched six months ago has almost no popularity signal. Nothing on your side of the screen fixes that overnight, and any agency promising it does is selling you something.

One sanity check first. Google's own Page indexing docs say that if your site has 'fewer than 500 pages, you probably don't need to use this report' - a site: search for the URL is faster. Confirm the page is genuinely absent from the index before you spend a month on it.

Will submitting a sitemap or using IndexNow force a crawl?

No. Google's sitemap documentation says it flatly: 'Keep in mind that submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site.' A sitemap is how a URL became Discovered in the first place. Resubmitting it repeats a message Google already received.

The Request Indexing button is not a queue-jump either. Google states that 'requesting a recrawl multiple times for the same URL won't get it crawled any faster,' that crawling 'can take anywhere from a few days to a few weeks,' and that 'requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all.'

IndexNow does not solve it for Google. The protocol's own FAQ lists the participating endpoints - Bing, Yandex, Naver, Seznam.cz, Yep and Amazon. Google is not among them. Wire IndexNow up anyway (it is 20 minutes and it helps on Bing), but do not expect it to move a single row in your Search Console report. IndexNow also notes that every submitted URL 'counts toward your site's crawl quota.'

• Do: keep the sitemap accurate and give it an honest lastmod date. Google's crawl guide recommends the lastmod tag - and a faked one teaches Google to ignore your dates.
• Do: remove indexed-but-dead URLs. Google says 'a 404 status code is a strong signal not to crawl that URL again.'
• Do not: resubmit the same sitemap weekly and call it work. It is the SEO equivalent of pressing the elevator button harder.
• Do not: paste 300 URLs into Request Indexing. There is a per-day quota, and it does not raise crawl demand.

Is your server too slow for Googlebot to bother?

It can be, and Google is unusually direct about it: it calculates a crawl capacity limit per host, and 'if the site responds quickly for a while, the limit goes up... If the site slows down or responds with server errors, the limit goes down and Google crawls less.' Remember Google's own definition of the status - the crawl was rescheduled because it 'was expected to overload the site.'

The metric that matters here is server response time and error rate, not your Lighthouse score. Open Settings, then Crawl stats, in Search Console and look at average response time, host status, and the share of 5xx responses. A shared-hosting WordPress install answering in 1.8 seconds under load is telling Googlebot to come back later.

Google's fix list is two items long: 'add more server resources' if you are seeing Hostload exceeded, and make pages efficient to load, because 'if Google can load and render your pages faster, we might be able to read more content from your site.' Move to real hosting, cache aggressively, and cut render-blocking work - our Core Web Vitals guide covers the front-end half.

When is the right move to wait and stop publishing?

If your Discovered pile is growing faster than your indexed count, stop publishing for 30 days. Nobody in this industry will say that out loud because nobody bills for it, but you are adding to a queue Google is already declining to work through.

Google names perceived inventory as the crawl-demand factor 'that you can positively control the most,' and warns that duplicate or unwanted URLs waste 'a lot of Google crawling time on your site.' Every filter URL, tag archive, thin location page and near-duplicate service page is competing with the page you actually care about - and on a fresh domain, the total crawl allocation is small.

So spend the 30 days pruning instead of producing: consolidate near-duplicate pages, 404 or 410 the dead ones, robots.txt the faceted junk, and cut the templated location pages you cloned by find-and-replace. Publishing 20 more posts into a site Google is not crawling is not a content strategy - it is a bigger queue. The service business SEO checklist has the pruning list.

What does the fix look like week by week?

Four weeks, and the first one contains no writing at all. If nothing moves by day 30, the problem is not the page - it is site-level authority and inventory, and the honest answer is that it takes longer.

Expect days, not hours. Google says crawling 'can take anywhere from a few days to a few weeks' even when you ask nicely. Judge the fix at day 30, not day 3.

If your indexing report is a mess and you want a straight answer on whether this is depth, inventory, or a hosting problem, that is exactly what our technical SEO service exists for - month-to-month, no lock-in, no ranking guarantees. Get my free audit and we will tell you which of the three it is before you spend a dollar with anyone.