Why is my page not indexed: twelve causes and how to tell them apart

Search Console usually tells you the reason before you start guessing, in a short phrase most people scroll past on the way to the "Request indexing" button. "Crawled, currently not indexed" and "Discovered, currently not indexed" are different problems with different fixes, and one of them is not a problem at all. Reading that line first turns an open-ended investigation into a check with four possible answers, and it takes about a minute.

Why is my page not indexed?

Because meeting the technical requirements does not entitle a page to enter: Google decides what it stores. On a new site the normal case is that part of it enters and it takes weeks; on a mid-authority site it is usually an inherited directive or a canonical pointing elsewhere; on a consolidated site it is content the system judges expendable.

Quick answer

• Read the reason Google gives in the URL Inspection tool before changing anything.
• A robots.txt block prevents Google from seeing your noindex, so the two together do the opposite of what is intended.
• "Discovered, currently not indexed" often means wait, not fix.
• Requesting indexing does not overrule a decision, it only asks for a re-check.

Before anything: read the reason

Open the URL Inspection tool in Search Console, paste the exact URL, and read the status line. Then use the live test, which fetches the page as it is right now rather than as it was when last crawled. Connecting Search Console is the prerequisite for all of this and it is item one on the basic SEO checklist for exactly this reason.

The gap between those two views resolves a surprising share of these cases on its own. A page fixed last week can still show the old reason, and a page that looks fine in your browser can fail the live test because the crawler sees something different.

Family 1: you asked for it without knowing

The largest family, and the one where the fix is one line.

A noindex tag inherited from staging. The site was built on a development server that blocked indexing, and the tag travelled to production with everything else. It is the single most common cause of a new site not appearing, and it is invisible in the browser.

A noindex in the HTTP header rather than the HTML. Same instruction, delivered where nobody looks. Viewing the page source shows nothing; the directive is in the response headers, and only a tool that inspects them will show it.

Blocked by robots.txt. This one has a trap worth stating carefully. Blocking a URL does not remove it from the index, because a blocked page cannot be read, and a page that cannot be read cannot be seen to carry a noindex. Combining the two is the standard way of guaranteeing a page stays indexed with no description under it. To remove a page, allow crawling and use noindex.

A canonical pointing at another URL. The page is telling Google that a different address is the real version, so the different address gets indexed instead. Frequently a template default nobody set deliberately.

Family 2: it cannot read the page

Server errors or slow responses. Timeouts and 5xx responses during crawls cause Google to back off. Intermittent failures are the difficult version, because the page works whenever you check it.

Content that only exists after JavaScript runs. The HTML arrives nearly empty and the text is assembled in the browser. Google can render, and rendering is queued separately and is not guaranteed on the schedule you would like. Compare what the live test sees against what your browser shows.

A page behind a login or a paywall. If the content requires a session, the crawler gets the door rather than the room.

Redirect chains and loops. Each hop loses something and long chains sometimes end in nothing being indexed at either end.

Family 3: it read the page and declined

This family is the uncomfortable one, because there is no setting to change.

"Crawled, currently not indexed." Google fetched the page, evaluated it and chose not to store it. On a small site this usually means the page adds nothing that is not already covered, either elsewhere on your site or on the ten sites already answering that query. The fix is editorial, not technical, and sometimes the correct fix is deleting the page. It is also the point where the question stops being about indexing and starts being about whether the page had a reason to exist, which is the subject of what SEO is and what it is for.

A duplicate where Google chose a different canonical. Your page was read, judged near-identical to another, and consolidated into it. Search Console names the URL that won, which is the useful part.

A soft 404. The page returns a success code while looking like an error or an empty result to Google. Thin pages, empty category listings and "no results found" screens produce this.

Family 4: it has not got there yet

"Discovered, currently not indexed." Google knows the URL exists and has not fetched it. On a new site this is normal and the answer is time. On an established site where it persists across many URLs, it is a signal about crawl priority: internal linking, sitemap accuracy and whether the site as a whole is worth frequent visits. The order in which those are worth checking is covered in the Spanish guide on technical SEO.

The order to check in

Cheapest first, because the cheap causes are also the most common.

1. Read the status in URL Inspection and run the live test.
2. Check for noindex, in the HTML and in the HTTP headers.
3. Read robots.txt.
4. Check the canonical the page declares.
5. Confirm the server responds quickly and consistently.
6. Compare the rendered content against the raw HTML.
7. Only then consider whether the page deserves to be indexed at all.

Most investigations end before step five. Starting at step seven, which is where the anxiety points, wastes weeks on rewriting a page whose problem was a tag.

When the answer is to wait

When the site is new. A new domain gets crawled sparingly until there is a reason to visit often, and no amount of manual requesting compresses that.

When the status is "Discovered" on a handful of URLs. That is the queue working, not a fault.

When a core update is in progress. Indexing decisions shift while one runs, and diagnosing during the movement produces conclusions that expire.

The three requirements, and the sentence that changes the diagnosis

Google publishes exactly three technical requirements for a page to be eligible: Googlebot is not blocked, the page returns an HTTP 200 status, and the page has indexable content in a supported format. That is the whole list. Domain age, word count and authority are not on it.

Then comes the line that reframes everything and that almost no article on this topic quotes: meeting those requirements does not mean a page will be indexed. It is on the same page. There is no right of entry.

That sentence explains the case that confuses people most, which is the page that is fast, linked, declared in the sitemap and still not in. It is not broken. Google has seen it and decided it does not add enough to store, and that decision does not reverse by requesting indexing again: it reverses by changing what is on the page, or by removing it.

One more distinction the documentation makes and that gets confused daily: blocking in robots.txt prevents crawling, but the URL can still appear in results. To keep a page out of the index you need noindex, which requires the opposite condition, that the page can be crawled so the directive is read.

Where each cause is checked

A directive stopping it, inherited from staging or from a plugin, which is the fastest to rule out and the most embarrassing to find late.

A canonical pointing elsewhere, in which case the page was not rejected but consolidated into another one.

Content that does not exist without JavaScript, which is the cause that takes longest to surface because the page looks fine in a browser.

Or Google seeing it and deciding it adds nothing, which is not an error and is not fixed by asking again. The report that tells you which of the four it is comes from how to set up Search Console, and the wider order of technical work is in basic SEO checklist.

If the page is a local landing page, the decision may be somewhere else entirely: local SEO for small business and Google Business Profile. What the whole discipline looks like from the top is in what is SEO.

The first page answers a status it then contradicts

Checked on 13 August 2026, the results that own this query are almost all about one Search Console status, Crawled - currently not indexed. Most of them say the same two things in the same article: that the status does not mean anything is broken and that resubmitting is not needed, and then a list of fixes that opens with robots.txt and noindex tags.

Those two do not belong to this status. A page blocked in robots.txt is reported as blocked by robots.txt. A page carrying a noindex tag is reported as excluded by that tag. Search Console names the reason before you start, which is the whole point of reading it first, and a page that reports "crawled" has already told you it was fetched and that neither of those applied.

The cost of that list is a morning. Someone reads it, opens the robots file, finds nothing wrong, opens the page source, finds no noindex, and ends up where they started with less patience. A cause list that ignores the status is a list for a different problem.

Mistakes that repeat

• Requesting indexing before reading the reason. It re-checks a decision, it does not overrule it.
• Blocking a page in robots.txt to remove it. It guarantees the opposite.
• Looking only at the HTML source. A noindex in the HTTP header is invisible there.
• Rewriting the page first. The cause is usually a tag, and the tag costs a minute.
• Treating one unindexed URL as isolated. Defects are patterns; find one and count the rest.
• Panicking at "Discovered, currently not indexed". On a new site that is the normal state.

Data and transparency

That the top results for this query concentrate on the crawled-currently-not-indexed status, and that several list robots.txt blocks and noindex tags among its causes while also stating the status does not indicate an error, is an own observation from 13 August 2026 and is recorded as a pattern in the results, not as a source.

That the three technical requirements are that Googlebot is not blocked, that the page returns HTTP 200 and that it has indexable content in a supported format, that meeting them does not guarantee indexing, and that blocking in robots.txt does not prevent a URL from appearing in results, comes from Google's public documentation on technical requirements, checked on 12 August 2026.

The status labels quoted here, including "Crawled, currently not indexed" and "Discovered, currently not indexed", and the behaviour that a URL blocked in robots.txt cannot be seen to carry a noindex directive, are documented publicly by Google in the Search Console help and the crawling documentation. The ordering of causes by frequency is operational judgment from audit work across a portfolio recording more than 300 million impressions a year in Search Console, not a distribution anyone publishes. No figure appears here for how long indexing takes: it varies by site and any single number would be invented. Verified as of August 2026.

What this changes

There is a pattern in how these investigations go wrong, and it is not technical.

The reason Google gives is short, unemotional and easy to scroll past, while the fear behind the question is large. So the effort goes to the large response, which is rewriting the page, when the answer was one line in a report that took a minute to read. Whenever a page is missing, the first question worth asking is not what is wrong with it, but what Google already said about it.

Frequently asked questions