You published something. Search Console says it is not indexed, and the reason is a sentence that sounds like a fault.

Usually it is not a fault. It is a queue, and there is a difference between the two that decides everything about what you do next.

There are more than a dozen statuses in the Page indexing report. I read every one on Google's own help page and wrote down what it says. Then I sorted them into three piles, because there are only three:

a queue       Google knows about it and has not got to it yet. Wait, and help it.
your fault    Something on your site is broken. Fix it, and it is fixable today.
by design     Nothing is wrong. This page should not be indexed. Leave it alone.

Getting the pile wrong is why people spend three weeks "fixing" a page that was never broken.

The three piles, and how to tell which one you are in

A queue looks like waiting. The date is empty, or the page was read and not kept. Nothing is red. Nothing fails. The page is simply not important enough yet, in Google's ordering of the world.

Your fault looks like a specific break. A 404. A soft 404. A 401. A 500. A redirect that loops. You can point at it, you can reproduce it in a browser, and when you fix it the status changes on the next crawl.

By design looks confusing but is correct. A duplicate page Google correctly declined to index. An AMP version pointing at the desktop page. A redirect. A page you told Google to ignore. These read like errors and are not.

"Discovered - currently not indexed"

This is the first gate. It means Google found your URL and has not opened it yet.

Google's own words:

"The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report."

The empty "Last crawled" date is not a bug and not a clue. Google says it is empty by design, in the definition above. Hundreds of forum posts are people trying to work out a thing the page already told them.

What it means in practice: the URL exists, Google can see it exists, and Google has decided not to spend a crawl on it yet.

This is a queue.

A product page stuck here has a live test that passes, is in the sitemap, and is linked from the homepage. That describes almost every post about this status, and it is not contradictory. Passing the test only proves there is nothing wrong. It does not prove Google wants to spend a crawl on you yet.

"Crawled - currently not indexed"

This is the second gate, and it is a different thing wearing a similar name.

"The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling."

"No need to resubmit this URL for crawling." Google says that in the definition itself, and it is the sentence that makes most of the advice you will read about this status wrong. People write guides telling you to request indexing. Google's own page about the status tells you the request is not needed.

Only one thing changed between the two statuses and it matters: the page was opened. In "Discovered" Google has not looked. In "Crawled" Google looked, kept a copy, and then decided not to add it to the index.

This is also a queue, but a longer one. Google has an opinion about the page now, and the way to change an opinion is to change the page. The opinion is about value, and I went through what Google means by that, because it is not length.

Why the report and the URL Inspection tool disagree

This one confuses people badly enough that they assume one of the two tools is lying.

They are not. They are answering at different times.

The report is not live. It fills in as Google crawls, and it can sit on an old status for a while after the page has changed. Google says the totals are accurate from its point of view, and that small differences happen.

The live test is live. When you click "Test live URL", Google fetches the page right then and answers about what it just saw.

So a page can show as not indexed in the report and be available to Google right now. Both are true. The report is a history, the test is a snapshot, and the report catches up when it catches up.

One more difference, from Google's page on redirects:

"The live URL Inspection test follows redirects and then tests the final URL, although the live test doesn't indicate that it is following a redirect."

So if you test a URL that redirects, the green result describes the place it landed, not the URL you typed. That has fooled a lot of people into thinking a redirect was fine.

What "Request indexing" actually does

It asks. That is all it does. It puts the URL in a queue for Google to consider, and Google may consider it whenever it likes.

Three things worth knowing:

It does not force anything. There is no button on earth that makes Google index a page today.

For "Crawled - currently not indexed", Google says it is unnecessary. That is in the definition, quoted above.

There is a practical limit. Publishers report about ten requests a day before the tool stops accepting more. On a new site with 400 URLs that is not a plan.

The honest use of the button is one URL at a time, on a page that matters, after you have fixed whatever was wrong with it. Pressing it repeatedly on a page that has nothing wrong with it changes nothing, because there was nothing to change.

What "Validate fix" does, and when it does nothing

If you have clicked it and watched a spinner for two weeks, this is why.

Google's own page on validation says four useful things:

"It might not always make sense to fix and validate a specific issue on your website: for example, URLs blocked by robots.txt are probably intentionally blocked. Use your judgment when deciding whether to address a given issue."

"Do not click Validate fix again until validation has succeeded or failed."

"Validation typically takes up to about two weeks, but in some cases can take much longer."

"You can also fix issues without validating; Google updates your instance count whenever it crawls a page with known issues, whether or not you explicitly requested fix validation."

Read the last one again. You do not have to validate. Google updates the count when it crawls. The button exists for issues where Google can check a specific thing on the page, like a missing tag.

And here is the part that matters most for this article: "Discovered" and "Crawled" are not broken things to validate. They are positions in a queue. There is no fault for validation to look for, so clicking the button starts a two week timer that reports on nothing.

A publisher in one thread describes exactly this and gets the right answer from another:

"I clicked on 'Validate Fix' but it's been over 2 weeks and it's still 'validating'."

"Validate Fix will not solve the problem anyway."

The statuses that are not errors, in Google's words

These five read like faults. Every one of them is correct behaviour.

One word appears in three of the names below, so it is worth having in plain English first. Google calls the main version of a page the canonical, and a page that copies another one a duplicate. When Google says it chose a canonical for your page, it means it picked which of your pages is the real one.

Alternate page with proper canonical tag

"This page correctly points to the canonical page, which is indexed, so there is nothing you need to do."

Nothing. Google wrote that.

Duplicate without user-selected canonical

"Google has chosen the other page as the canonical for this page, and so will not serve this page in Search."

"This is not an error, but is working as intended, because Google does not serve duplicate pages."

Fix it only if Google picked the wrong page. Then say which one you want, or make the two pages genuinely different.

Duplicate, Google chose different canonical than user

You told Google page A is the main one. Google thinks page B is. Google keeps B. To investigate, compare three things: the page you are looking at, the canonical you declared, and the canonical Google chose. The report shows both.

Page with redirect

"This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed."

That is the point of a redirect. What matters is the target, and Google says the target might or might not be indexed depending on what it thinks of it.

Indexed, though blocked by robots.txt

"The page was indexed despite being blocked by your website's robots.txt file."

This is the trap your own robots.txt can set: you block crawling, and the URL still shows up, because Google found a link to it somewhere else and indexed it without reading it. If you want a page gone, a robots.txt block is the wrong tool. It has to be a noindex tag, and Google has to be allowed in to read it. I made that mistake on this site and wrote down what robots.txt actually does.

The statuses that are your fault

These you can fix today, and each one has one cause.

Not found (404)                      the page is gone or the URL is wrong
Soft 404                             the page says "not found" to a person
                                     but returns 200 to Google
Blocked due to unauthorized           the page needs a login. Google cannot get in
request (401)
Blocked due to access                 the server refuses Google. A firewall or rule
forbidden (403)
Server error (5xx)                    the server broke, or timed out, or was busy
Redirect error                        a redirect chain that never lands
URL blocked due to other 4xx issue    a status Google does not have a bucket for

A soft 404 is the one people do not believe. Their page says "Sorry, no results" in friendly letters, and they think that is a 404. It is not. A 404 is a status code, and a person reading the page never sees it. If the page says not found but answers with a 200, Google calls it soft, and that is a real problem rather than a queue.

Server errors are worth checking twice before you change anything, because Google says the crawl and your test can disagree:

"Note that server errors can be transient, so your live test might succeed when Google's crawl failed due to a server error."

Warnings are not statuses

At the bottom of the report there is a second table headed page experience. Google is clear about what it means:

"Warnings are listed in the Improve page experience table on the summary page of the Page indexing report. These issues don't prevent a page from being indexed, but they do reduce Google's ability to understand and index your pages."

They do not block indexing. They make everything slower and less certain. Worth fixing, not worth panicking about, and not the reason your page is missing.

Why a page sits in the queue for weeks

Nobody can promise you a date. What can be said is what the pages that move have in common, and it is not the button.

1. The links to it are not in the HTML you serve. This is the biggest one and it is invisible in a browser. A site whose homepage builds its links with JavaScript after the page loads can look perfect to you and contain nothing a crawler can follow. One publisher tracked 60,000 URLs stuck in the queue and found exactly that:

"The homepage had zero internal links to any content page. Everything was rendered client-side after hydration, so the served HTML of the root had nothing crawlable."

2. The links exist but come from pages Google does not value yet. A link from a page Google has crawled once carries less than a link from a page Google trusts. If every link to a new page comes from pages that are themselves new, the chain has no anchor. Links from pages that already get impressions work better than links from menus and tag pages.

3. The pages look like each other. A template with only the name swapped is close to a duplicate. Google has never published a line telling you where that line sits, and I counted the phrase it uses in thin content is a phrase Google never defines. Google describes the pressure it is under on the sitemaps pages, and the flip side is this: a hundred pages that are 95 percent the same give Google no reason to crawl the second hundred.

4. The site asks for too much. Thousands of thin URLs, tag pages, filter combinations and old junk tell Google there is a lot to get through. Google has a limited amount of crawling to hand out. Spend it on pages nobody wants, and the pages people do want wait longer.

5. The site is new and has no history. This is not a punishment and there is no dial to turn. A domain with no visitors, no links and no crawl history gets crawled carefully and slowly at first. That is what it looks like while it is happening.

What actually helps, in order

1  Look at the HTML you serve, not the page in your browser. If the links to a stuck
   page are not in that HTML, nothing else on this list matters yet.
2  Link to the stuck page from a page Google already crawls and already shows to
   people. One good link beats five tag pages.
3  Make the page different from its neighbours, above the fold, where a person
   decides whether to stay.
4  Build a hub page that describes the group and links to every page in it. Hubs
   get crawled because they are useful, and they carry links with them.
5  Take the weak pages out of your sitemap. The sitemap is a list of what matters,
   and a list of everything is a list of nothing.
6  Then leave it alone and check once a week. Checking hourly produces nothing
   except a headache.

And look at what is missing from it. Requesting indexing again. Re-submitting the sitemap. Validating a fix for a status that has nothing to validate.

One more thing, from a thread about a 700,000 page site, said by someone who was not being kind and was also not wrong:

"Good news: the agents produced 700,000 pages. Bad news: Google noticed."

If you generated pages in bulk, the queue is not a malfunction. It is Google deciding, slowly, that it does not want them.

What this site's own report said

I am writing this with a report of my own open, which is the only reason I trust the order above.

2 URLs in "Crawled - currently not indexed"
  http://toprast.com/         last crawled 10 October 2026
  https://toprast.com/        last crawled 10 October 2026
First detected 10 October 2026

Both URLs are the same page. One is the http version, which redirects to the https version. So my report says "2" about one page, and one of those two is a redirect that should never be indexed on its own. That is the "Page with redirect" status sitting in a different pile than a reader would expect.

And the date explains the rest. 10 October was the day this site came out from behind the password I had on it while building. Google crawled it, got a login prompt, and wrote down what it could get, which was nothing. The next crawl will find a public site with articles. There is nothing to fix, and there was never anything wrong with the page.

I know that because I checked the other side too. On 13 October, Googlebot had fetched eight of the ten articles that existed then, in 205 requests, and Search Console shows one of those articles already ranking. So the site is not invisible and nothing is blocked. One page is in a queue, with a date on it that says why.

That is what most of these statuses look like when you actually read them. Not a fault. A date, a reason, and a wait.

The short version

There are only three piles. A queue, a fault, and by design. Almost everything people panic about is a queue or by design.

"Discovered - currently not indexed" means Google knows the URL and has not opened it. The empty crawl date is normal, and Google says so in the definition.

"Crawled - currently not indexed" means Google opened it and chose not to keep it. The same definition says there is no need to resubmit it for crawling.

The report is a history and the live test is a snapshot, so they can disagree without either being wrong.

"Validate fix" runs for up to two weeks and does nothing for a status that is not a fault. You do not have to validate at all. Google updates the count when it crawls.

Page with a redirect, duplicate pages, and alternate versions are correct. Google says so, in the same sentences people quote as faults.

A 404, a soft 404, a 401, a 403, a 500 and a redirect loop are your fault and are fixable today.

And a page that stays in the queue for weeks usually has one of five causes: links that only exist after JavaScript runs, links from pages Google does not value, pages that look like each other, a site that asked for too much, or a domain with no history. None of them are fixed by pressing a button again.

Sources

  • Search Console Help, Page indexing report
  • Search Console Help, URL Inspection tool
  • Search Console Help, Sitemaps
  • Public threads on r/SEO, r/TechSEO, r/bigseo and r/seogrowth between June 2025 and October 2026, quoted as what publishers report, not as policy