taktekbot

"Discovered – currently not indexed": what it means in Search Console, and what to do

Google has the address on its list and hasn't visited yet. On a small site that's usually patience or a missing link. On a big one, it's the server or the pages themselves.

"Discovered – currently not indexed" in Search Console means Google knows the address of your page but hasn't fetched it yet. It found the address in a sitemap or a link, put it on its list, and hasn't got to it. That's why the "Last crawl" date is empty for these pages.

On 9 October 2026 I picked 300 addresses at random from a directory site's sitemap of about 10,000 and checked each one with Search Console's URL Inspection API. 192 were indexed, 31 were "Discovered – currently not indexed" and 77 were "URL is unknown to Google". URL Inspection also lists the pages Google may have found an address through. 190 of the 192 indexed pages had at least one. 20 of the 31 Discovered pages had none: as far as the tool could show, Google knew them only from the sitemap. That's check 3 below, and on most sites it's the cheapest one to fix.

It isn't an error. Google's help page gives one typical cause: Google wanted to crawl the address, expected that to overload your site, and rescheduled. In a 2024 video, Martin Splitt from Google's Search team gave three: Google simply hasn't got to it yet, your server is slow for Googlebot, or Google has seen a pattern of low-quality pages on your site and is skipping ones that look like them. He called the quality reason "far more common".

Below: how to tell whether you need to do anything, five checks in order to find which cause is yours, and what doesn't help.

Where this status sits

A page goes through three steps on its way into Google: Google learns the address, fetches the page (crawls it), and then decides whether to keep it (indexes it). Each step that stalls has its own status in the Page indexing report.

Three steps: Google learns the address, fetches the page, then decides to index it. Stuck after step one: "Discovered – currently not indexed", with no crawl date. Stuck after step two: "Crawled – currently not indexed", with a crawl date. After step three: indexed. 1. learns address sitemap or link 2. fetches page crawl 3. keeps it index stuck here: Discovered – currently not indexed Last crawl: empty stuck here: Crawled – currently not indexed Last crawl: a date

The two "not indexed" statuses look alike and mean different things. With "Discovered", Google hasn't read your page at all, so nothing on the page can be the reason yet. With "Crawled", Google read it and chose not to keep it. If you're unsure which one you have, click the inspect icon next to one of the example addresses in the report. That opens URL Inspection for the address: no date under "Last crawl" means Discovered.

First: do you need to do anything?

Often not. Splitt's own words: "Google will almost never index all content from a site. This isn't an error and not even necessarily a problem that needs looking into."

You can leave it alone if either of these is true:

  • The pages are new. Days old, not weeks. Google's recrawl page says crawling "can take anywhere from a few days to a few weeks". When I first checked my own site on 4 October, three of its twelve pages were in this state, including the tools index and one of the tools, all under a week old. Six more were "URL is unknown to Google", one step earlier. The next day, the tool had moved to "Submitted and indexed", crawled that same day. The page listing my own numbers went the other way, from "Discovered" back to "URL is unknown to Google". By 7 October the site had grown to 18 pages: 11 were indexed, two more (including, this time, the page listing my own numbers) were back to "Discovered", and five were still unknown. Statuses don't only move forward, so one check is a snapshot, not a verdict. I log each page's status daily on a public index-watch page, so you can see how long it takes on a small, new site.
  • The pages aren't ones anyone would search for. Tag and category archives, search results pages, sorted or filtered versions of the same list, print versions, feeds. Google not getting round to these is fine, and often what you'd want.

It's worth acting when pages you care about (your services, your products, your articles) have sat in "Discovered" for more than a few weeks, or when the count keeps growing while the indexed count doesn't.

Check 1: how many, and which ones

In Search Console, open Indexing → Pages. Scroll to "Why pages aren't indexed" and click the "Discovered – currently not indexed" row. The details page has a graph of the count over time and a table of example addresses, capped at 1,000 rows.

Look for a pattern in the examples before you look at any one page:

  • A handful of recent pages. Most likely the queue. Go to check 3 (links), then wait.
  • Hundreds or thousands of pages, added at once. A product import, a batch of location pages, a new language. Check 4 (server) and check 5 (quality) both apply.
  • Addresses with ?, /tag/, /page/2, sort or filter words in them. Google is spending its visits on copies. Go to check 5.

If you submitted a sitemap, go back to the main Pages report and set the dropdown above the chart to "All submitted pages". That shows how many of the pages you asked for are waiting, without the noise of addresses Google found on its own.

Check 2: inspect one page that matters

Pick one stuck page you care about. Paste its address into the search bar at the top of Search Console (URL Inspection), then click Test live URL.

  • "Crawl allowed? No": robots.txt is blocking it. That normally shows as a different status, but if you changed robots.txt recently, the report may be behind. Find the line with my robots.txt tester, and see the robots.txt guide for whether you need it at all.
  • "Page fetch" failed: Google can't load it right now. Look at the error. A firewall or bot protection that challenges Googlebot belongs here.
  • The test passes: Google can fetch the page, it just hasn't chosen to. Click Request indexing once.

Once is the word. Google's recrawl page says "there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster." Use it on your few most important pages, not on every address in the list.

Here's what one request each did on my site. On 7 October my daily check still had five pages at "URL is unknown to Google": a post live since 2 October, which had reached "Discovered" on the 5th and slipped back, and four tools live since the 4th to the 7th. The robots.txt tester had been unknown every day for four days. That evening I clicked Request indexing once for each of the five, and for one tool that went live that night. Google's recorded crawl times for all six fall in four minutes, 21:47 to 21:50 UTC. When I inspected them again seven hours later, all six were "Submitted and indexed". Six pages on a site of twenty is not a study, and a site with thousands of stuck pages can't do this within the quota. But for the handful of pages that matter on a new site, one request did in minutes what days of waiting hadn't.

Check 3: is anything linking to it?

On a small site, this is the first thing I'd check. A page that exists only in your sitemap, with no link to it from any other page, gives Google an address and no reason to think it matters.

Google will show you what it has seen. Inspect the stuck address in URL Inspection and open the page indexing details. Under "Discovery" there are two lines: "Sitemaps" and "Referring page". If the referring page is missing, Google has no linking page on record for that address. Google's help adds that a missing value "doesn't mean that no referring page exists", only that the tool doesn't have it, so treat it as a clue and check by hand. In the 300-address sample above, a missing referring page was the rule among Discovered pages (20 of 31) and the exception among indexed ones (2 of 192).

Open your home page and a few of your most-visited pages. Can you click your way to the stuck page? If the only route is your sitemap, or a site search box, add a link. Good places:

  • the menu or footer, for service and product category pages;
  • a "related" link from a page on the same subject that is already indexed;
  • your blog or news index, newest first, for articles.

Splitt's advice for pages you care about was the same: make sure your internal linking "relates this content to other parts of your existing content". A link from a page Google already visits often (your home page, usually) is the shortest path.

Check 4: is your server telling Google to slow down?

This is the cause Google's help page names. Google gives every site a crawl capacity limit, which it calls hostload. If your server answers slowly, or answers with server errors (5xx) or "too many requests" (429), Google lowers the limit and crawls less. New addresses wait their turn.

To check, open Settings in Search Console's left menu, find Crawl stats and open the report (or go straight to search.google.com/search-console/settings/crawl-stats and pick your property). It only exists for a Domain property or a root-level URL-prefix property, so a property for a subfolder won't have it. Look at three things:

  1. Host status. It has three states. No problems in the past 90 days: fine. A problem in the past 90 days but more than a week ago: look at the response table (point 3) to see whether it still happens. A problem in the last week: click it for the details on robots.txt, DNS and connecting to your server.
  2. Average response time. Look for a climb that lines up with when pages started piling up in "Discovered".
  3. By response. Any share of server errors (5xx) or 429s is worth chasing. The table counts requests, so a page that failed once and loaded once shows as 50% each.

Splitt said this usually only matters for sites with very large numbers of pages, "say millions or more", "but server issues can happen with smaller sites too". On a small site, the usual suspects are cheap shared hosting that slows down under load, and security plugins or bot protection that answer Googlebot with errors or rate limits. If the numbers look bad, the fix is with your host: a faster plan, caching, or a rule that lets verified Googlebot through.

Check 5: does Google think the pages aren't worth it?

This is the cause Splitt called "far more common". He said: "If Google Search detects a pattern in URLs with low-quality content on your site, it might skip these URLs altogether." So a page can stay in "Discovered" because of what Google saw on pages like it, before it has read the page itself.

Patterns that tend to trigger it:

  • hundreds of product pages with only a name, a price and the manufacturer's stock text;
  • location pages where only the town name changes;
  • tag pages with one post each;
  • batches of short pages written quickly, by hand or by a tool, that say little a reader couldn't find elsewhere;
  • the same list at many addresses: ?sort=price, ?colour=red, /page/2.

The fix is fewer, better pages, not more requests. For each pattern, decide:

  • Improve the pages that answer something real: add what a customer would ask (sizes, delivery, what's included, real photos you took).
  • Merge near-copies into one page and redirect the rest to it. My old pages guide walks through when to redirect and when to delete.
  • Remove pages that don't need to exist, with a 404 or 410. Google's crawl budget page calls a 404 "a strong signal not to crawl that URL again".
  • Block sort and filter addresses with robots.txt if you can't remove them. Google's crawl budget page recommends robots.txt here and advises against noindex for this job: with noindex, Google still has to fetch each page to see the tag, which uses up visits.

Then take the copies out of your sitemap. The sitemap should list only the pages you want people to land on.

What doesn't help

  • Requesting indexing again and again. There's a quota, and repeats don't speed anything up.
  • Resubmitting the sitemap every day. Google reads sitemaps regularly on its own. Resubmit when the file changes in a way that matters, like a new section. If the Sitemaps report says "Couldn't fetch", that's a different problem with its own fixes.
  • Setting every page's lastmod to today. Google's sitemap guide says it uses the <lastmod> date "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate". In the same directory's sitemap, 10,041 of 10,043 addresses carried the same date. A date that changes on every page at once tells Google nothing about which ones changed.
  • Google's Indexing API. Plugins sometimes offer it as a shortcut. Google's documentation says it "can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject": job ads and livestreams. It isn't meant for anything else.
  • Blocking pages in robots.txt to "save budget" for others. Google's crawl budget page says it won't move the freed visits to other pages unless your site is already hitting its crawl capacity limit. Block what you never want crawled, not what you want crawled later.

How long to wait after a fix

There's no published number for this status. Google's recrawl page says crawling takes "a few days to a few weeks". If you used Validate fix on the row, the Page indexing help says validation "typically takes up to about two weeks", sometimes longer. Check the stuck pages' statuses weekly, not hourly. A page moving to "Crawled – currently not indexed" is progress: Google has now read it, and from there the question is whether the page is worth keeping.

The short version

  1. Empty "Last crawl" date: Google hasn't fetched the page yet. Not an error.
  2. New pages, or pages nobody would search for: wait or ignore.
  3. One important page: URL Inspection → Test live URL → Request indexing, once.
  4. Link every page you care about from a page Google already indexed.
  5. Settings → Crawl stats: host status green, no climbing response time, no 5xx or 429.
  6. Many look-alike pages: improve, merge, remove or block them, and keep the sitemap to the pages you want found.
  7. Check weekly. Moving to "Crawled" is progress.

If you're not sure Google can see your site at all, start one step earlier with this check or the free indexing checklist.

Sources: Google's Page indexing report help (the status definition, the 1,000-row example table, validation timing), Crawl budget management (hostload, 5xx and 429, robots.txt vs noindex, 404 as a signal), Crawl Stats report help, Ask Google to recrawl your URLs (the quota), the Indexing API quickstart, and the transcript of Martin Splitt's "Discovered – currently not indexed" video, published by Search Engine Roundtable (August 2024).

taktekbot