Discovered – currently not indexed: what it means and how to fix it

Short answer: Google knows your URL exists — from your sitemap or a link — but has decided not to fetch it yet. It is not an error, there is nothing to validate, and on a small site it is almost never the "crawl budget" problem most guides tell you to fix. It is a demand problem: Google hasn't seen a reason to spend a fetch on that URL. The levers that actually move it are internal links from pages Google already crawls, an honest sitemap, and content Google's past visits to your domain make it want more of.

You shipped the page. It's in the sitemap. Search Console has known about it for three weeks. And the Page indexing report just says "Discovered – currently not indexed" with no button to press.

---

If you build for the web long enough, you will meet this status. It's the most passive-aggressive line in Search Console: Google is telling you it knows your page exists and has chosen not to look at it. This site has met it too — for weeks, most of the posts on this blog sat in exactly this state while only our homepage got crawled. What follows is the honest version of what the status means, why the standard "crawl budget" advice mostly doesn't apply to you, and what we actually changed on this site in response.

What the status actually means

Google's index pipeline is a sequence: it learns a URL exists, crawls it, indexes it, and only then can the page rank. "Discovered – currently not indexed" means the pipeline stopped at stage one. Google found the URL — usually via your sitemap or a link — and put it in the crawl queue, but hasn't fetched it.

Google's own documentation describes it as: Google found the URL, but crawling it was expected to overload the site, so the crawl was rescheduled. Read that generously — for most small sites, "rescheduled" is doing a lot of work. Your server is not overloaded by one fetch of one blog post. What the wording papers over is prioritization: every URL Google knows about competes for crawl attention, and yours didn't make the cut yet.

It's worth being precise about the neighboring status, because the diagnosis is different:

Status	What Google did	What it usually signals	Primary lever
Discovered – currently not indexed	Found the URL, never fetched it	Low crawl demand for the URL — Google isn't convinced it's worth a fetch	Internal links, sitemap accuracy, domain-level quality
Crawled – currently not indexed	Fetched the page, declined to index it	Google read the content and judged it not worth storing (thin, duplicate, or low-value)	The content itself, canonicals, consolidation

If you're in the first row, the problem is upstream of your content — Google hasn't read it. If you're in the second, Google read it and passed, which is a harder conversation.

Why "crawl budget" is probably not your problem

Nearly every guide on this status leads with crawl budget. Google's own crawl-budget documentation is unusually blunt about who it applies to: sites with roughly a million-plus unique pages whose content changes weekly, or ten-thousand-plus pages changing daily. Google says everyone else doesn't need the guide at all — keep the sitemap current and move on.

If your site is a SaaS marketing page, a documentation site, or a blog with forty URLs, you do not have a crawl budget problem. Google could crawl your entire site in seconds without noticing the cost. You have a crawl demand problem: Google allocates fetches where its models predict value, and its prediction for your URLs is built from your domain's history — what it found the last times it crawled you, who links to you, and how your pages connect to each other.

That reframe matters because it changes what you do next. Budget problems are about removing waste (faceted URLs, redirect chains, parameter sprawl). Demand problems are about adding evidence that your URLs are worth fetching.

What actually drives crawl demand on a small site

Three things, roughly in order of how much you control them this sprint:

1. Internal links from pages Google already crawls. Discovery via a sitemap alone is weak evidence — a sitemap says "this exists," while a link from a page Google values says "this matters." If your only crawled-and-ranking page is your homepage and your posts are only reachable through an index page Google rarely visits, your posts are two hops from the only authority you have.

2. A sitemap that tells the truth. lastmod dates that update on every deploy regardless of whether content changed teach Google to ignore your lastmod. Real dates, only for real changes, make the sitemap a signal instead of noise.

3. Domain-level quality history. Google's crawl scheduling is informed by what previous crawls of your site found. A domain that has served thin, duplicated, or near-empty pages (a client-rendered app that gives the crawler an empty <div> counts) accumulates a prior that new URLs from this domain aren't worth rushing to fetch. This is the slow variable — it moves over weeks and months, not days.

External links move crawl demand too — often dramatically — but you can't ship a backlink in a pull request, so this post treats them as out of scope.

What we changed on this site

This blog is the dogfood case. Search Console showed our homepage crawled and ranking for our brand name, while individual posts sat in "Discovered – currently not indexed." Classic shape: a young domain, all of its authority concentrated on one page, and posts linked only from a /blog index the crawler had little reason to revisit.

The fix we shipped was structural, not content: a "From the blog" section on the homepage that links directly to the newest three posts as plain, crawlable <a href> links baked into the prerendered HTML. That takes every new post from two hops away from our strongest page to one hop, and puts the links on the one URL Google reliably re-crawls. We also keep per-URL lastmod honest in the sitemap and prerender every public route so the crawler gets full HTML on the first wave, not an empty SPA shell.

We're saying this carefully: this is the standard, mechanically-sound lever, and it's what Google's guidance points at — but indexing changes take weeks to show up, so we're treating it like any other deploy: merged on a known date, watched for a changepoint. That's the same discipline we'd suggest for your fix.

The checklist

For a page stuck in "Discovered – currently not indexed":

1. Confirm it's still true. URL Inspection → check "Last crawl." The report lags; the page may have been crawled since.
2. Link to it from your most-crawled page. Homepage, top docs page, whatever ranks. A real <a href> in server-delivered HTML, not an onClick handler.
3. Get it within two clicks of the homepage. Orphaned pages and deep hierarchies are exactly what this status eats.
4. Check what the crawler gets. curl the URL and look at the raw HTML. If the content isn't there without JavaScript, you're asking Google to spend a fetch and a render on a URL it already doubts.
5. Make the sitemap honest. Correct lastmod, no dead URLs, no redirected URLs.
6. Use "Request indexing" — once, and honestly. It nudges one URL into the queue. It does not fix the demand problem, and mashing it weekly does nothing.
7. Don't mass-publish onto a cold domain. Fifty pages at once on a site Google barely crawls is how you fill this report. Ship at the rate your crawl demand supports.
8. Prune what you wouldn't defend. If a URL pattern is thin or duplicative, consolidate or noindex it — it's dragging down the prior for everything else.

How long it takes, and when to worry

Set expectations in weeks. Even after you ship the fix, Google has to re-crawl your linking page, notice the new links, schedule the target URLs, fetch them, and index them — the same multi-stage lag that applies to every code change Google has to notice. Two to four weeks of patience after a structural fix is normal, not a sign it failed.

Worry when the pattern is wrong, not when the count is nonzero: important money pages stuck for months, the count climbing steadily as you publish, or whole URL patterns never leaving the report. A handful of new posts passing through this status on a young domain is the system working as designed — slowly.

Frequently asked questions

Is "Discovered – currently not indexed" bad?

It's neutral-to-mildly-negative. For new pages on a young or small site, it's the normal waiting room and usually resolves on its own. It becomes a real signal when important pages sit in it for months or the count grows in proportion to everything you publish — that's Google telling you its demand for your URLs is lower than your publishing rate.

How do I force Google to index my page?

You can't force it — there is no API or button that guarantees indexing. "Request indexing" in URL Inspection nudges one URL into the crawl queue and is worth doing once for an important page. The durable fix is raising crawl demand: internal links from your strongest pages, honest sitemaps, and a domain history of pages worth indexing.

How long does "Discovered – currently not indexed" take to resolve?

Anywhere from days to months, and it scales with how much Google values your domain. On this site — a young domain — new posts have sat in the status for multiple weeks. After shipping a structural fix (like linking the stuck pages from your homepage), give it two to four weeks before judging the result.

What's the difference between "Discovered" and "Crawled – currently not indexed"?

"Discovered" means Google never fetched the page — the problem is upstream of your content, in crawl demand. "Crawled" means Google fetched it, read it, and declined to index it — the problem is the content itself or duplication. The second is the tougher diagnosis, because Google has already seen what you're offering.

Does requesting indexing in Search Console actually work?

As a nudge, yes: it moves a URL up the crawl queue, and for a single important page it often shortens the wait. As a strategy, no: it doesn't change why the URL was deprioritized, it's rate-limited, and repeating it for the same URL adds nothing. If you're requesting indexing for dozens of URLs, the thing that needs fixing is your site's crawl demand, not the queue position.

---

The uncomfortable truth about this status is that it's Google pricing your URLs, and the price moves slowly. The good news for engineers: the levers are code — link architecture, sitemap accuracy, what your HTML serves on first fetch — which means the fix ships in a pull request and lands on a date you know. Whether it worked shows up in Search Console weeks later, which is exactly the attribution gap Code Results exists to close: it watches your rankings for changepoints and traces them back to the PR that caused them. The beta is open.