Search Console said your page is not indexed.

Every reason in the Page indexing report means something specific, and the fixes have almost nothing in common. Pick the one Google gave you: what it actually means, what causes it, how to clear it, and a live check that tells you whether it is still true right now.

§ errors

Pick the reason Google gave you.

Every label is copied verbatim from Search Console, so it should match what you are looking at -- all but one from the Page indexing report, and “URL is unknown to Google” from URL Inspection, which is the only place it appears. The tag on each card says whether it is worth acting on: blocking means a page you want indexed is not, usually fine means Google is doing what you asked it to, and judgement call means nothing technical is broken.

01Excluded by 'noindex' tagGoogle found this page, crawled it, and was told not to index it. Here is where that instruction comes from, the four places it hides, and how to confirm it is gone.blocking 02Blocked by robots.txtGoogle was told not to fetch this URL at all. Here is which line of your robots.txt is doing it, why the page can still appear in search anyway, and how to fix it correctly.blocking 03Redirect errorGoogle followed a redirect from this URL and never arrived anywhere usable. Here is what breaks a redirect chain, and how to see the whole chain the way a crawler does.blocking 04Blocked due to access forbidden (403)Your server let Googlebot ask, then refused to answer. Usually a bot-management rule rather than anything you configured on purpose. Here is how to tell.blocking 05Server error (5xx)Google asked for the page and your server failed to produce it. Often intermittent, often only under crawl load, and the most urgent of the indexing errors.blocking 06Page with redirectUsually not a problem. Google is telling you the redirect worked and it indexed the destination instead. Here is how to tell the harmless case from the one worth fixing.usually fine 07Alternate page with proper canonical tagThe clearest good news in the Page indexing report. Google found your canonical tag, agreed with it, and indexed the page you nominated. Here is when it is worth a second look anyway.usually fine 08Duplicate without user-selected canonicalGoogle found several URLs with the same content, you did not say which one counts, so it picked for you. Here is how to take the decision back.blocking 09Duplicate, Google chose different canonical than userYou declared a canonical and Google overruled it. That only happens when your other signals disagree with your tag. Here is how to find the contradiction.blocking 10Soft 404Your server says 200 and your page says the content is gone. Google believes the page, not the status code, and refuses to index either.blocking 11URL is unknown to GoogleGoogle has never seen this URL. Nothing is broken and nothing is blocked; there is simply no route to it. Here is how to build one.blocking 12Crawled - currently not indexedThe most common and least actionable row in the report. Google fetched the page, read it, and decided not to index it. No tool can verify a fix for this one, including ours.judgement call 13Discovered - currently not indexedGoogle knows this URL exists and has not fetched it yet. Unlike its near-namesake, this one usually has a measurable cause: your server is slow, or you are asking for more crawling than you have earned.blocking

§ crawled vs indexed

The distinction that explains most of these.

Crawling and indexing are separate steps, and every error in the report is a failure at one of them. Crawling is Google fetching the URL. Indexing is Google deciding to store it and serve it in results. A page can be crawled and not indexed, and a page can be indexed without ever being successfully crawled.

That is why the two most common fixes contradict each other. Blocking a URL in robots.txt stops the crawl, which also stops Google seeing any noindex directive on the page, so the URL can stay in the index indefinitely, listed with no description. If you want a page out of search results, it has to stay crawlable so Google can read the instruction telling it to leave.

Work out which step failed before you change anything. Blocked by robots.txt and access forbidden (403) are crawl failures. Excluded by noindex is an indexing decision Google made because you asked it to.

Then there is the row that is neither. Crawled - currently not indexed means the crawl succeeded and Google read the page and decided against it. It is the most common row in most accounts and the only one where no checker, ours included, can confirm a fix. What a checker can do there is rule out the technical causes so you stop looking for a bug that is not there.

§ faq

Questions, answered.

What does "Page is not indexed" mean in Search Console?

It means the URL is not in Google's index and therefore cannot appear in search results. Search Console groups these URLs by reason, and the reason is what matters: some are instructions you gave Google on purpose, some are infrastructure failures, and some are judgements Google made about the page. The label on the row tells you which, and each one has a different fix.

Why does Search Console show an error I already fixed?

Because the report describes the last time Google crawled the URL, not its current state. There is no live check in Search Console. After you deploy a fix, use Validate Fix on the affected row to requeue those URLs, then expect days rather than minutes. Until the recrawl happens the old status stands, which is why it is worth verifying the page directly rather than trusting the report to be current.

Are all indexing errors worth fixing?

No. "Excluded by noindex tag" on your checkout confirmation page, or "Page with redirect" on a URL you deliberately moved, are both the system working as intended. Read the affected URL list before you change anything. The errors worth acting on are the ones covering pages you expect to rank.

How do I stop these errors happening in the first place?

Check the page before it ships rather than after Google does. Most rows here have a technical cause you can catch at deploy time: a noindex directive, a robots.txt rule, a redirect loop, a status code. LintPage runs those checks against a URL or a staging environment in about 30 seconds, which is the difference between catching a stray noindex in review and finding it in Search Console six weeks later. The rows that are Google's judgement rather than your configuration, such as "Crawled - currently not indexed", cannot be predicted this way. What a pre-deploy check does there is rule out the technical blockers, so what is left really is the quality call.

LintPage is not affiliated with, endorsed by, or connected to Google. Google Search Console is a Google product; the error strings on these pages are quoted so you can find the one you are looking at.

§ before the next deploy

Every error here is detectable before you ship.

Search Console tells you weeks after the fact. LintPage runs 60 checks against a URL in about 30 seconds. Free, no signup.

run a full scan →