Discovered, Currently Not Indexed: It's Not Crawl Budget

"Discovered, currently not indexed" means Google knows your URL exists and hasn't fetched it yet. Google's own explanation is a scheduling one: "Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl." [1] Nobody has looked at your content. The page is sitting in a queue.

Almost every guide answers this with crawl-budget optimization. Google scopes that work to sites with 1 million or more pages, or 10,000+ pages changing daily. [2] If your site is smaller than that, and it almost certainly is, you're being handed a fix for a problem you don't have.

This post gives you the split that decides what to actually do (crawl capacity versus crawl demand), the link-counting rule with the stopping condition nobody publishes, and the reason Search Console structurally cannot tell you whether a page is under-linked.

TL;DR:

• Google's crawl budget guide opens by telling most readers to leave: "If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide." [2]
• Crawl budget has two halves. Capacity is your server's tolerance. Demand is whether Google thinks the URL is worth fetching. Small sites virtually never hit the capacity ceiling, so the lever is demand, and the two have opposite fixes.
• "Add internal links" is a hypothesis, not a diagnosis. Search Console's Links report shows the pages linked the MOST, so the under-linked page you're hunting is the one it cannot show you.
• Count contextual in-body links only. Nav, footer, and sitemap entries don't count. At roughly three real ones, stop: more links won't move a page whose problem is demand or age.

What does "discovered, currently not indexed" mean?

Google found the URL, usually through your sitemap or a link, and put it in the crawl queue without fetching it. No evaluation of your content has happened, because the content has never been retrieved. That's the entire difference from the status where Google did fetch and declined, and it's why the two need different first moves.

The practical consequence: nothing about your page's writing quality is being judged yet. Rewriting a page stuck here is work aimed at a gate it hasn't reached. What's being judged is whether the URL is worth Google's time to go get, which is a different question with different inputs.

Is crawl budget actually the cause?

Usually not, and Google says so before the topic even starts. The crawl budget guide's opening line is a filter: "If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide." [2] The thresholds it names are large sites of 1 million or more unique pages, or medium-plus sites of 10,000+ pages with content changing daily. [2]

Hold your own site against that. A few hundred pages, or a few thousand, publishing weekly, is one to three orders of magnitude below the line where Google itself says the topic applies. Yet the standard remedies for this status are drawn straight from the large-site playbook: prune low-value URLs, flatten faceted navigation, speed up server response, tighten the sitemap.

None of those are bad practices. They're just aimed at the wrong half of the machine, and that's the distinction worth carrying, because it changes what you do on Monday morning.

What holds a page in the discovered queue instead?

Crawl demand, which is a different mechanism from crawl capacity. Google splits them explicitly. The crawl capacity limit (Google also calls it hostload) "limits the total amount of time your server spends holding connections open for Google," and it moves with your server's response times and error rate. Crawl demand is set by three things Google names directly: "Perceived inventory," "Popularity," and "Staleness." [2]

Read those two definitions side by side and the fix splits cleanly:

• Capacity is an infrastructure problem. Slow responses and 5xx errors make Google back off. This is real, and it's the one that genuinely bites large sites. If your server is healthy and you publish weekly, this is not your bottleneck.
• Demand is a signals problem. Google says popular URLs "tend to be crawled more often," and that without guidance it "tries to crawl all or most of the URLs that it knows about." [2] A URL nothing points to, on a site with no particular authority, is a low-priority item in a queue, not a blocked page.

So on a small site the honest reading is: Google isn't struggling to reach your page. It hasn't decided the page is worth the trip. Speeding up a server that was never the constraint changes nothing about that.

How do you fix discovered, currently not indexed?

Give the URL a reason to be fetched, then stop. In practice that means confirming the page is genuinely under-linked, adding one good contextual link from a relevant page that already earns traffic, and making sure the URL is in a clean sitemap. Google is direct about why a link is the lever here: it "uses links as a signal when determining the relevancy of pages and to find new pages to crawl." [4] The part every guide omits is where to stop, which is what turns this from a check into an afternoon of busywork.

The counting rule first, because most people count wrong:

• Only contextual in-body links count. A link inside the prose of a related page is the signal. Navigation, footer, and sitemap entries are not, because they appear on every page and tell Google nothing about this URL specifically.
• Roughly three real inbound links is enough. Past that, more links won't help, because a well-linked page still sitting in the queue is telling you the cause is demand or simple maturation, not discoverability. That's the point to accept the page and move on rather than keep adding.
• One good link beats five. Pick the most topically relevant strong page, not every strong page. Fanning every high-traffic page out to every unindexed URL dilutes the sources and reads as manufactured.
• Prefer a source that isn't already saturated. A page carrying a large pile of internal links passes less through each one. Reach for a less-loaded neighbour.
• Write the anchor as natural, descriptive words. Google's guidance is that "Good anchor text is descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to," and it warns against cramming keywords in, because "keyword stuffing is a violation of our spam policies." [4] A forced exact-match anchor repeated across a site works against you, not for you. The anchor-text discipline for pushing a page up applies here unchanged.

This is exactly how we built our own version of this check, and the stopping rule was the deliberate part. The obvious implementation is to list every unindexed URL and tell the user to add links, which generates work with no end condition and no way to know it helped. Ours refuses to state the link theory as a diagnosis at all: it says weak internal linking is a common cause, then says it cannot see your link graph, so treat it as a hypothesis and verify in the repo before adding anything. It also flags a suggested source page when that page is already carrying too many internal links, because the failure mode we most wanted to avoid was a tool cheerfully instructing someone to wire every strong page to every orphan.

Why can't Search Console show you an under-linked page?

Because its Links report is sorted the wrong way for this job. Google describes the internal section as a way to "see which of your pages is linked the most from within your own site." [3] It's a most-linked ranking, capped at 1,000 rows. [3] The page you're hunting is the one with almost no internal links, which is precisely the page that does not appear on a list of your most-linked pages.

A page with zero internal links is absent from that report entirely. Its absence is the finding, and an absence is not something a report surfaces.

That's the structural reason "add internal links" survives as universal advice while staying unverifiable inside Search Console: the data to check it isn't there in a usable shape. The URL Inspection referring-URLs sample doesn't close the gap either, since it's a partial sample and frequently comes back blank for pages that are linked perfectly well. Read a blank there as "no information," never as "orphaned."

The place the answer does exist is your own codebase or CMS, where you can grep for the URL and count real contextual links in seconds. That's an odd thing for an SEO tool to admit, and it's the honest shape of the problem.

When is the honest answer just patience?

When the site is young, the page is new, and the queue is simply doing its job. Google's wording describes a postponement, not a rejection: the page "was found by Google, but not crawled yet," and Google "rescheduled the crawl." [1] There's a concrete tell that confirms you're reading the status correctly, and it's worth knowing because it costs nothing to check: Google notes "this is why the last crawl date is empty on the report." [1] An empty last-crawl date means exactly what the label says. A date sitting there means you're looking at something else.

A page published last week on a site publishing weekly is not a defect, and treating every queued URL as a fault manufactures work that would have resolved itself.

Two situations change that reading:

• The page matters and it's been weeks. A page you can prove is valuable, still queued long after its siblings were crawled, is worth one contextual link and a sitemap check. Not five links and a server audit.
• The count is large and the pages are templated. Hundreds of thin, near-identical URLs sitting in the queue is the one case where the large-site advice starts to apply to a smaller site, because you've manufactured the inventory problem yourself. The fix is fewer URLs, not more links, and deciding which page survives a consolidation is the relevant call.

On our own account this has stayed a non-issue, which is itself the useful data point: 38 of 38 known URLs indexed, with new posts crawled within a day or two of publishing. Google's guide says that if your pages "seem to be crawled the same day that they are published, you don't need to read this guide," [2] and a site that small with a clean sitemap and real internal linking is the case the guide is describing. We read that account publicly for 30 days, and the indexing panel was the quietest thing on it.

Checking this without counting links by hand

By hand, the verification loop is the part that gets abandoned. You open the coverage report, expand the discovered group, get a list of URLs with no priority order, and then, for each one, you'd have to search your own codebase to work out whether it's genuinely under-linked or just young. That last step is the one that decides whether you should do anything, and it's the one that gets skipped, which is how sites end up with link spam pointed at pages that were only ever waiting.

QueryScope reads this from your editor, which is the one place both halves of the question live at once: it brings the queued URLs and your strongest pages over from Search Console, and your agent already has the repo open to count the real inbound links and confirm the hypothesis before touching anything. It names the pages worth checking rather than the whole list, and it says out loud when a suggested source is already over-linked. Splitting that from the rest of the coverage pile is the job the unindexed-pages check does. For the one-line meaning of each coverage state, the Search Console glossary defines them with their caveats.

Sources

• Google Search Console Help, Page Indexing report ("Discovered - currently not indexed: Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl"). [1]
• Google Search Central, Large site owner's guide to managing your crawl budget ("If your site doesn't have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don't need to read this guide"; thresholds of "1 million+ unique pages" and "10,000+ unique pages with very rapidly changing content (daily)"; the crawl capacity limit "limits the total amount of time your server spends holding connections open for Google"; crawl demand factors "Perceived inventory", "Popularity", "Staleness"). [2]
• Google Search Console Help, Links report ("See which of your pages is linked the most from within your own site"; "Tables are limited to 1,000 rows"). [3]
• Google Search Central, SEO link best practices ("Google uses links as a signal when determining the relevancy of pages and to find new pages to crawl"; "Good anchor text is descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to"; "keyword stuffing is a violation of our spam policies"). [4]