Discovered - Currently Not Indexed? 26 Pages We Checked

On the afternoon of October 20 we re-inspected the sitemap of the card game site we run. Of the 718 URLs that returned a result (two more returned an API error), 20 came back "Discovered - currently not indexed." Four were its story pages, all of which drew their first crawler request in our server log on October 14. Seven were card pages and eight were short glossary entries, two page types Google had already indexed 145 and 77 times on the same site.

Across our three content sites we found 26 pages with the status among 1,863 URLs that returned a result. Length didn't set them apart, and nothing blocked them. What did differ was Google's own list of links: for 5 of the 26 it named a page that links to them, against 1,138 of the 1,761 indexed pages in the same run.

What the status means

Google's Page indexing report gives one sentence for the status: "The page was found by Google, but not crawled yet." Then the usual reason, the overload one quoted above, and a note: "This is why the last crawl date is empty on the report." So unlike crawled, currently not indexed, where Google read the page and left it out, here Google hasn't read it at all. Nothing on the page can have been judged yet.

Google calls its crawl budget guide "an advanced guide intended primarily for" large sites (1 million+ pages) and sites with 10,000+ pages that change daily, and adds a third group: "Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed." For everyone else it says "keeping your sitemap up to date and checking the Page Indexing report regularly is adequate." The same guide says "Every site starts with the same default, conservative crawl capacity limit," which goes up if "the site remains healthy" and down with slow responses, 5xx errors or 429 rate limits.

Our reading: on a site with a few hundred or a few thousand pages, a handful of discovered URLs is the queue working as designed. We'd start worrying when the count grows week after week, or when a page you need has sat there for more than a month.

What 26 pages on our sites had in common

The three sites are a manhwa and anime site, a game news site and a card game site, all running since April or May. On October 20 we put every sitemap URL of the first and third through URL Inspection. The game news site's URLs had already been through a morning run, so we kept the afternoon run to 557 of its 1,262: every URL outside its blog, plus the blog URLs its sitemap dates September 15 or later, to stay inside what we took to be the day's quota. Three of the calls returned an API error, which leaves 1,863 results. We fetched the sitemaps again for this run, so the counts differ slightly from our morning census in the crawled, not indexed post (720 card game URLs instead of 722, 1,262 game news URLs instead of 1,314). Then we fetched each of the 26 discovered pages, looked them up in Search Console's performance data and searched our server's access log for them.

Our log starts on October 6, so "Oct 6" means the page existed by then, and the date is the first request from a crawler, not the day the page was made. Ten of the 26 first show up on October 11 or later: the four story pages and six of the card pages. For those, the plainest explanation is age. For 7 of the 10, URL Inspection lists no sitemap either, so Google knew the URL but showed neither a sitemap nor a linking page for it.

The links stand out more. URL Inspection lists the pages Google knows that link to a URL. It listed at least one for 1,138 of the 1,761 indexed pages in our run (65%) and for 5 of the 26 discovered ones. On the card game site the gap was sharper: 115 of its 145 indexed card pages had a linking page listed, and none of the 7 discovered card pages did. Google may have crawled the linking pages before any links to the new cards were added, so this shows what Google knew, not why it chose. Even so, it's the difference we'd act on first.

Length wasn't the difference. The discovered glossary entries ran 42 to 63 words; ten random indexed glossary entries on the same site ran 34 to 89. The discovered card pages had 173 to 231 words, the ten indexed ones we sampled 131 to 237. Every one of the 26 answered 200, carried "index, follow" and named itself as canonical.

Overload didn't explain it either, as far as our log shows. From October 6 to 19, Googlebot requests that we could verify against Google's published IP ranges numbered 33,944 across all the sites on our server. Forty-four got a 5xx error (0.13%), and none got a 429. That count leaves out 8,287 more requests that used Googlebot's name: 2,484 came through Cloudflare, which shows its own addresses, and 5,803 came from addresses that aren't on Google's list.

Two pages that don't fit the definition

Two of the 26 didn't behave like pages Google had never read. One manhwa article from June, 3,149 words long, was fetched by a verified Googlebot on October 13 and got a normal 200. A week later URL Inspection still called it discovered, with no crawl date; none of the 26 had one. A card game article from June 8 had 158 impressions in Search Console, all between June 8 and 23, which it could only get from Google's index. It now shows as discovered too.

We can't tell from Search Console why either happened. What it shows us is that the status is a stored label, and a page's real history can be different. Before rewriting a page because of this status, we'd search the access log for Googlebot requests to that URL. If Google fetched it recently, the label may simply be behind.

What we'd do, in order

1. 1Check the ageUnder two weeks old and in the sitemap: wait
   →
2. 2Link from crawled pagesHome, category or a related article Google already reads
   →
3. 3Trim the inventoryNoindex or drop URLs you don't need found
   →
4. 4Check the server5xx, 429 and slow responses lower the crawl limit
   →
5. 5Ask for the few that matterRequest indexing once per important page

For a new page in a sitemap, we'd give it time first. If it's still discovered after two weeks, link to it from a page Google crawls often: the home page, a category page or a related article that's already indexed. Google's crawl budget guide calls the number of URLs it knows about "Perceived inventory" and says "This is the factor that you can positively control the most." Duplicate, thin or unneeded URLs in the sitemap take crawl time from the pages you care about, so we'd noindex them or drop them from the sitemap.

Request Indexing works one page at a time, and Google says "There is a daily limit to how many index requests you can submit," so save it for pages that earn money or answer a question people ask. On elmrank.com, one launch post was still "Discovered" the morning after it went live; we requested indexing that morning, and Googlebot fetched it 17.2 hours after it had gone live (our post on indexing times has the rest). In August, u/Sweaty-Drop4846 told r/bigseo that new landing pages on their site, which gets about 3 million clicks every 90 days, had stayed discovered for six months: "If I request indexing by hand (URL Inspection), it gets crawled and indexed within minutes, every time." They listed "stronger internal links to new pages" among the things they had tried that didn't help. The post had 5 points when archived. A reply from u/mastafied, at 3 points, said "URL Inspection bypasses the crawl scheduler completely, so it only proves the page is fetchable, not that the scheduler ever wanted it," and that what helped their site was internal links "from URLs google already crawls daily." In that reply's account, what counts is where the link comes from.

• Open Indexing, then Pages, in Search Console and list the URLs under "Discovered - currently not indexed"
• Note each URL's age: anything under two weeks that is in your sitemap can wait
• Run URL Inspection on the older ones and look for a listed referring page
• Add a link to each page you want indexed from a page that is already indexed and crawled often
• Remove URLs you don't need in search from the sitemap, or noindex them
• Search your access log for Googlebot requests to the URL before you rewrite anything
• Check your server's 5xx and 429 responses to Googlebot, and its response times in the Crawl stats report
• Request indexing once for the pages that matter most, then check again in a week

How we handle this for a client

Crawling and indexing fixes are part of the technical work in the first month of our plan ($500): an SEO and GEO audit, then fixes to crawling, indexing, speed, schema and site structure, made by us in your code. After that, $300 a month covers up to 30 articles, ongoing fixes, hosting and a monthly report with your Search Console clicks and impressions; our sample report is filled in with one of our own sites. We write the internal links for each article we publish. We don't promise that every page gets indexed; the one result our terms promise is about Google clicks. The technical SEO page lists what the fixes cover.

Corrected October 22, 2026: an earlier version said the daily inspection quota didn't allow a second full run on the game news site. We cut that run to 557 URLs ourselves, before calling the API, because we expected the quota to run out.

How we know this

Written by Tyler Phan. Every source below was read on the date shown; the page was last reviewed on Oct 22, 2026.

1. Search Console Help, Page indexing report, accessed Oct 20, 2026
2. Google Search Central, Crawl budget management for large sites (last updated July 22, 2026), accessed Oct 20, 2026
3. Search Console Help, URL Inspection tool (Request indexing and its daily limit), accessed Oct 20, 2026
4. Google, Googlebot IP ranges (googlebot.json, created Oct 19, 2026), accessed Oct 20, 2026
5. r/bigseo, New pages stuck in "Discovered – currently not indexed" for 6 months (post by u/Sweaty-Drop4846, comment by u/mastafied), accessed Oct 20, 2026
6. Elmrank, URL Inspection of sitemap URLs on the three sites we run (Search Console API, Oct 20, 2026; 1,863 results), with each Discovered page's impressions, page check and server log lines, accessed Oct 20, 2026

Send us your site.

We reply within 12 hours with what we'd fix first. Then we run it for you, technical SEO and content: $500 for the first month, then $300 a month for up to 30 articles. You don't need any technical knowledge, and you can cancel any time.

Get my free first-fix listSee what's included