Why Your Page Is Not Indexed in Google Search Console

Read the exact status string first

Search Console does not lump every missing URL into one bucket. Under Indexing, then Pages, then the reasons listed below the chart, it hands you a precise label. The two you will see most often for a URL that refuses to show up are 'Discovered - currently not indexed' and 'Crawled - currently not indexed'. They look almost identical. They are not. One means Google has not even fetched your content yet. The other means it fetched it, looked at it, and passed.

I treat that one-word difference, discovered versus crawled, as the whole diagnosis. Everything downstream depends on it, so I never start rewriting meta tags or copy until I know which of the two labels I am actually looking at.

Discovered, currently not indexed: a priority signal

The page was found by Google, but not crawled yet.

That is Google's own wording. It found the URL, probably through your sitemap or an internal link, then chose not to fetch it right away. The help doc says the crawl was usually rescheduled because fetching it was expected to overload the site. On a 500-visitor hobby project that server-load reason rarely holds literally. What it really signals is priority: Google has your address, and it has decided your address is not worth the trip yet.

This is a demand problem, not a rejection. The engine has not judged your writing because it has not read your writing. The lever here is convincing it the URL is worth fetching. That means stronger internal links pointing at it, a clean sitemap that does not bury it among thousands of low-value paths, and enough overall site signal that the crawler wants to come back. New and sparse projects sit in this state constantly, and often the honest answer is that you wait while the rest of the domain earns some trust.

Crawled, currently not indexed: a quality verdict

This label is the harder pill. Google fetched the URL, read it, and decided not to keep it. The help text is blunt: it may or may not be listed in future, and there is no point resubmitting. There is no server-load excuse here. The engine spent the resource, evaluated the content, and the answer was no.

In my experience this is almost always a quality or duplication verdict. The page might be thin, it might say what forty other results already say better, it might be a near-duplicate of another URL on your own domain, or it might read as templated filler. Google's own people have said the quiet part out loud on this. John Mueller and Martin Splitt have described mass crawled-not-indexed patterns as a signal that the system doubts a whole site's quality, and they named undifferentiated, machine-generated content as a live example of what sets it off.

The fix is editorial, not technical. Make the page genuinely better than the alternatives already ranking, or merge it into a stronger page and redirect. Resubmitting the same thin writing and hitting Request Indexing again just asks the same question and earns the same answer.

Crawl budget is almost certainly not your problem

Every forum thread about this eventually blames crawl budget. For nearly every reader of this page, that is the wrong suspect. Google's own large-site documentation says crawl budget only becomes a real constraint for sites with roughly a million or more unique URLs that change weekly, or medium sites above ten thousand URLs that change every day. Gary Illyes has confirmed that million-page figure has not moved in years, and Google frames those numbers as rough estimates rather than hard cutoffs.

If your project has two hundred pages, you do not have a budget ceiling. You have a demand or a quality issue wearing a budget costume. I have made this mistake myself, fiddling with robots rules and crawl-delay settings on a tiny site, when the actual problem was that my writing was not worth listing. Do not optimize a constraint you do not have.

The young-domain wait is real, even if the sandbox is a myth

There is a stubborn idea that Google drops every new domain into a sandbox for a few months. Google has said there is no formal sandbox filter, and I believe them. But something real is happening, and pretending otherwise does not help you. Mueller has described it as a lag: a brand-new domain has no history, no link reputation, and no engagement data, so the algorithms have to guess where it belongs and tend to guess cautiously.

The practical upshot is the same whether or not you call it a sandbox. A domain registered last month, with three backlinks and no track record, gets crawled slowly and listed reluctantly. That is not a defect in your page. It is the cost of being new. The uncomfortable answer that most SEO blogs will not give you is that a chunk of this is simply time, and there is no button that skips it.

What actually moves a page into the index

Once you know which status you have, the levers are short and unglamorous. None of them are secrets, and none of them work overnight.

• Internal links. A page that nothing else on your site links to looks unimportant, because by your own site's logic it is. Link to it from your home page, your relevant hub pages, and related posts. This is the cheapest fix for a discovered-but-unfetched URL.
• A clean sitemap. Submit an XML sitemap that lists only canonical, indexable URLs. Google treats it as a discovery and priority hint, not an order to list, so do not pad it with tag archives and thin pagination that dilute the signal.
• External links. A couple of genuine links from sites Google already trusts do more for a young domain than any amount of on-page tweaking. They are also the hardest to earn, which is exactly why they carry weight.
• Fewer, better pages. Consolidating ten thin URLs into three strong ones raises the average quality Google sees, and site-level quality is part of how it decides how much of you to list at all.
• Actual crawlability. Confirm the page returns a 200, is not blocked in robots.txt, carries no stray noindex tag, and canonicalizes to itself. This is rarely the root cause once ruled out, but it is worth ruling out first.

How I check whether any of this is working

Indexation is a lagging number, so I watch two things. In Search Console I track how many pages move from not-listed into the index over weeks, not days, and I lean on the URL Inspection tool for specific pages rather than trusting the aggregate chart, which updates slowly.

The second thing I watch is whether the pages that do get picked up actually earn anything. A URL in the index that brings no visitors and no signups is not a win, it is a vanity metric. I built Conclick, my own analytics tool, partly to answer that: which listed pages bring real traffic, and which of those visitors turn into revenue. It measures without cookies and is built on the open-source Umami engine, which I mention because I would rather be straight about the lineage than pretend I wrote every line from scratch. Whatever you use, tie your indexing effort back to outcomes, or you will keep celebrating pages that rank for nothing.