Discovered – currently not indexed in Search Console: what it means and what fixed it

"Discovered – currently not indexed" means Google knows the URL exists but has not fetched it yet. On my portfolio, 50 project pages landed in that bucket at once, because a batch of thin, near-identical pages made Google spend no crawl effort on any of them. Cutting down to fewer, better pages got them moving, and below are the details and the mistakes I made on the way.

What does "Discovered – currently not indexed" mean?#

Google found the URL, usually through a sitemap or a link, and put it in a queue. It has not crawled it. That differs from "Crawled – currently not indexed", where Google fetched the page and decided not to keep it.

So the status says nothing about your page's content yet, because Google never looked at it. It says Google chose not to spend a request on it. Two things push that decision: how worth crawling the site as a whole looks, and how many URLs showed up at once.

Why were 50 of my pages stuck there?#

The 2026-08-09 Search Console export showed the not-indexed count jumping from 6 to 56 on 2026-07-25. Indexed pages had been frozen at 7 since 2026-07-01. The deploy on 2026-07-25 had cross-linked every project page, so all 53 appeared in front of Google at the same time.

About half of those pages were synced from the READMEs of old tutorial repositories. With code blocks stripped, they had between 22 and 190 words of prose, and several were byte-identical to each other. Google read the batch as thin, near-duplicate filler. It spent no crawl budget on any of it, including the projects that had real content.

A site's good pages get judged alongside its bad ones. If you add dozens of weak URLs at once, the strong ones queue behind them.

How do I fix pages stuck in Discovered – currently not indexed?#

I fixed it in two passes.

1. Pages under a word floor, MIN_INDEXABLE_WORDS, set to 200, render noindex, follow and drop out of the sitemap and every other discovery surface. That cut the set I was asking Google to index from 53 to 32.
2. I wrote a hand-authored overview for the stub pages. It survives my README sync script, renders above the synced README, and counts toward the threshold. Twenty sidecars got one. The final state was 53 indexable pages and 0 noindex.

My first pass was only the first step. I noindexed 21 pages and reported the problem as solved. That relieved the crawl-budget symptom, but it also gave up on a third of the portfolio. Writing real content was the option that raised the indexed count (52 versus 32), and I should have offered it together with the threshold.

What does the "fewer, better pages" rule look like in code?#

One predicate answers the question, and every surface imports it. The sitemap, the page's robots meta, llms.txt and the IndexNow submission all ask it:

export const MIN_INDEXABLE_WORDS = 200
 
export function isIndexableSidecar(sidecar: {
  overview?: string
  body: string
  seoIndex?: boolean
}): boolean {
  // An explicit override wins in either direction.
  if (typeof sidecar.seoIndex === 'boolean') return sidecar.seoIndex
  const words = countProseWords(`${sidecar.overview ?? ''}\n\n${sidecar.body}`)
  return words >= MIN_INDEXABLE_WORDS
}

listIndexableProjects() filters the project list through that function. Anything that promotes pages to Google reads that list, so no caller can disagree with the page's own robots tag.

The single predicate earned its place the hard way. For a while the word-count arithmetic was inlined in two files, and IndexNow counted the README body but not the new overview. It silently dropped three pages the sitemap listed. A build step that compares sitemap membership against each page's rendered <meta robots>, llms.txt and the IndexNow set caught it on its first run. Without that check, it would have turned into a Search Console mystery weeks later.

You can see the resulting pages on /projects, and the site itself is described in the portfolio case study.

Should I click "Request indexing" on every URL in the report?#

No, and this is where I wasted the most time. Request Indexing has a small daily quota, about 10 a day, and the Pages report that lists your stuck URLs lags the live index.

On 2026-11-03 the Pages report showed 49 indexed and 24 not: 12 "Discovered", 6 "Crawled, not indexed", 4 redirects and 2 alternate canonicals. Live URL Inspection told a different story:

• Of the 12 "Discovered" URLs, 11 were already on Google or had been requested the night before. Only /projects/portfolio had never been crawled.
• Of the 6 "Crawled, not indexed" URLs, 5 were OG images and the favicon, which I noindex on purpose. The sixth, /projects/rafiq, was on Google.
• The redirects were the http and apex variants of the home page, which is expected.

I had spent a request on /projects/angular-todo straight from the report's list, and it was already on Google. The Pages report can be days to weeks behind.

The same thing happened on a second site of mine. Six translated pages were listed as "Discovered, not indexed". Live inspection showed five of the six were already on Google, so one request was enough.

My rule now: inspect each URL live first, and request indexing only for the ones Google reports as unknown.

Does the Request Indexing quota reset at midnight?#

I assumed it did and told myself the queue would be free the next day. One request went through at the start of the day, and then "Quota exceeded" came back. The quota frees as each request from the previous day ages out, so it works as a rolling window. Spread the queue across the day.

The quota is also per Google account, shared by every property you own. My other site hit "Quota exceeded" after 2 requests because the portfolio had used the rest.

On 2026-10-17 I requested indexing for 11 pages before the 12th returned "Quota exceeded".

What is the difference between "Something went wrong" and "Quota exceeded"?#

"Quota exceeded" is the only quota message. On the seventh request of one session I got "Oops! Something went wrong ... Please try again later." and read it as the quota again. A single retry after dismissing it went through. Retry once before assuming you are out of quota.

What does "No referring sitemaps detected" mean?#

For a page Google has never seen, the inspection can say "No referring sitemaps detected". I took that for a missing sitemap entry. The live sitemap had the URL, and Google had not re-read the sitemap since I added the page. Check your live sitemap before changing code.

What changed in the numbers?#

Search Console between 2026-10-09 and 2026-10-17, after the fixes above:

By 2026-11-03 the Pages report showed 49 indexed. The redirects, a ?ref canonical and the noindexed images in the remaining rows were working as designed.

What should I check first on my own site?#

1. Open each URL in URL Inspection and read the live status. The Pages report is a lagging summary.
2. Count the words of real prose on the pages in the bucket. If a large share are stubs or copies of each other, that is your answer.
3. Decide per page: write real content for it, or mark it noindex, follow and take it out of your sitemap and internal link lists.
4. Keep one function that decides what is indexable, and have the sitemap, the robots tag and any submission scripts all call it.
5. Request indexing only for URLs that inspection reports as unknown to Google, and spread the requests across days.

I also checked the site before blaming Google. A crawl of all 59 sitemap URLs on production with a Googlebot user agent returned a 200 on every page, each with a self-canonical, index, follow and one <h1>, and no duplicate titles or descriptions. When the site is clean and the bucket is still full, the cause is usually page quality or volume.