Every status in Google's Page Indexing report, translated

Google’s Page Indexing report sorts every URL it knows about on your site into 18 named statuses across three tiers: 15 reasons a URL is not indexed, 2 warnings for pages that are indexed but that Google struggled to read, and 1 for a page that simply worked.¹ Most guides read that first tier as a queue of defects to work through, which is where the trouble starts. On this site it is mostly a record of decisions I made deliberately, and I can put a number on it. Of the 245 URLs a crawler can discover here, meaning an automated program like Googlebot that visits and reads pages, 105 were built so they can never be indexed. If you read your own report as a fault list, you will spend your week fixing things that were never broken.

105 of the 245 URLs a crawler can find on this site are engineered never to be indexed. That is 43%, and it is correct.

What does the Page Indexing report actually count?

The Page Indexing report counts URLs, not pages, and sorts them into three tiers. The largest holds 15 reasons a URL is not indexed, ranging from a server error to a canonical tag. A second tier holds 2 warnings, where the page is indexed but Google had trouble reading it. The third says the page worked.¹

Two terms carry the rest of this piece. Being indexed means a page sits in Google’s database of results it can show. A canonical tag is a line of markup naming a different page as the real version among near-duplicates.

The 15 arrive under a heading that reads like a fault list, and that presentation is what misleads people. A status describes what happened when Google met your URL. It carries no opinion about whether what happened was good.

Why are most “not indexed” URLs supposed to be there?

Most not-indexed URLs are excluded because a site instructed Google to exclude them. A canonical tag naming a different page, a redirect to somewhere better, a noindex header on a duplicate, each one is an instruction someone wrote on purpose, and Google obeying it produces a row in the not-indexed list.

Google is direct about this in its own documentation. Its entry for the noindex status reads, in full seriousness, “If you do not want this page indexed, congratulations!”¹

I call this pattern engineered exclusion: a URL a site deliberately publishes in a state that guarantees it can never be indexed. Naming it matters because the report gives you no way to separate it from failure. A 500 error and a working canonical tag both land in the same not-indexed bucket. One of them cost you a page and the other one saved you from a duplicate.

How many URLs does this site deliberately keep out of the index?

This site publishes 140 HTML pages and 105 plain-markdown twins, counted from the built output on September 1, 2026, and every twin is engineered exclusion. Each article and pulse page ships a second copy at /<path>/index.md so AI assistants can read clean text without parsing HTML. All 105 return X-Robots-Tag: noindex, pinned in public/_headers.

That noindex arrives as a header, an instruction the server attaches to its response. It never appears in the page itself, so viewing source will not show it to you.

Those twins are linked from their HTML pages, so Google finds them by ordinary crawling, and none appear in the sitemap, the file that lists a site’s pages for search engines.

The 140 HTML pages and 105 twins together give 245 discoverable URLs, of which 105 can never be indexed. Every one lands under the status Google now labels “URL marked ‘noindex’”.¹ A stranger opening this property’s report would see a not-indexed count covering roughly 43% of the site and reasonably assume something had gone wrong.

The exact figures moved while I wrote this, which is the point in miniature. Publishing this article added one HTML page and one twin, so the counts above already include it. The ratio is the durable part, because the architecture guarantees it: every article ships exactly one twin, so the excluded share climbs toward half the site and stays there by design.

Which statuses mean you should do nothing?

Three statuses describe a site working correctly, and all three are common. “URL marked ‘noindex’” means Google found your instruction and obeyed it. Naming a different page as the real one gets you “Alternate page with proper canonical tag”, with Google agreeing to the swap. A “Page with redirect” simply forwards elsewhere, so the destination is what gets indexed.¹

Each of these grows as a site matures. Every redirect you have ever set up eventually appears in that third bucket. Watching the number climb and treating the climb as decay gets the causation backwards, since a site with no redirects is usually a site that has never reorganized anything.

Which statuses are worth a second look?

Six statuses are ambiguous, and they are the ones worth your attention. “Crawled - currently not indexed” means Google read the page and declined to index it, which is a judgment about quality or demand and not a technical fault you can patch.¹ “Discovered - currently not indexed” is different and more useful.

“Discovered - currently not indexed” means Google knows the URL exists and has not fetched it yet. Google’s own explanation is that it wanted to crawl the URL but expected the request to overload the site, so it rescheduled.¹ A jump in this status is a capacity signal, and it belongs next to your server response times, which is the ground the crawl budget piece covers in depth.

The other four in this tier are “URL blocked by robots.txt”, the two duplicate statuses, and “Not found (404)”. Robots.txt is the text file at a site’s root that lists which paths crawlers may request. None of the four is automatically wrong. A robots.txt block on an admin path is correct, whereas the same block across a whole product section is a catastrophe wearing the same label. The status cannot tell you which you have, so you have to know your own intent before you open the report.

Which statuses need fixing today?

Six statuses are close to unambiguous faults, and each is named after an HTTP status code. “Server error (5xx)” and “Redirect error” mean Google could not complete the request. Your server reported success on a “Soft 404” while the page itself apologized for being missing, and Google recommends a real 404 for pages that are genuinely gone.¹ Refusal covers the last three, where 401, 403 and other 4xx responses all mean Google was turned away.

A status code is the three-digit number a server sends back with every page it serves. The 200 in the challenge-screen case below is the one that says everything worked.

The 403 case deserves singling out, because Google’s documentation on it is unusually blunt. Googlebot, Google’s own crawler, never provides credentials, so a server returning 403 to it is responding incorrectly.¹

Bot management is where that goes wrong, and it can fail in either direction. A rule that refuses Googlebot outright produces the 403 status above. A rule that serves Googlebot a challenge page with a 200 status instead produces no status at all in this report. Google simply indexes the challenge page as though it were your real content, a failure I covered in the piece on challenge screens. The first failure is loud in this report and the second one is invisible in it, so the report alone will never tell you your bot rules are wrong.

Which statuses mean a page is indexed and still broken?

Two statuses sit in a separate warning tier, and they are the mirror image of a URL that is correctly absent from the index. “Indexed, though blocked by robots.txt” means Google indexed a page it was never allowed to fetch, using only the text of links pointing at it, so the result carries almost no useful snippet. “Page indexed without content” means Google reached the page and could not read what was on it.¹

Both are easy to miss because they never appear in the not-indexed count anyone watches. Google files them in a different table on the summary page, under “Improve page experience”.¹ A site can therefore run a clean not-indexed number while quietly serving Google pages it cannot read, which is the failure the fault-list reading is least equipped to catch.

Why do the status names in most guides not match your report?

Google has changed the wording of several statuses, and published advice lags behind. I found the drift in my own back catalogue while writing this, in two different forms. The crawl budget piece writes the status as “Discovered, currently not indexed” with a comma, six times, while Google’s live documentation on September 1, 2026 punctuates it “Discovered - currently not indexed” with a hyphen.¹

Do not over-correct from that, which I nearly did. While checking the same drift against the robots piece, I concluded its “Indexed, though blocked by robots.txt” was another retired label. It is not. The phrase is live and current, sitting in the warning tier, and my search missed it because the page renders a space before that comma. So one article here is a punctuation version behind and the other is exactly right, which is the useful lesson: check the label against the page rather than against your memory of the page, and make sure your check would survive the page’s own markup.

Match on meaning instead of on the string. A guide that tells you to filter your report for an exact label will send you hunting a row that no longer carries that name, and the behavior underneath it has not changed at all.

What does a noindex actually require to work?

A noindex instruction only works if Google can fetch the page and read it. Google states the condition directly, saying that for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.² Blocking a URL in robots.txt and adding a noindex to it accomplishes nothing, because the crawler never arrives to see the second instruction.

Blocking a URL and then adding a noindex to it is the single most common way a deliberate exclusion turns into an accidental indexation, and it has its own piece here on why a robots.txt Disallow is not a noindex.

How do you read your own report in ten minutes?

Open the Page Indexing report and sort every status into three tiers before you look at a single count. Tier one is work already finished, meaning the noindex, canonical and redirect statuses, so record the number and move on. Tier three is server errors, redirect errors, soft 404s and the access refusals, and every one of those gets a URL inspection today. Tier two is everything else, and it needs one question answered.

URL inspection is Search Console’s tool for checking how Google sees one specific address.

That question is whether you meant it.

Once you have actually fixed something in tier three, the button you want is Validate Fix rather than Request Indexing, and the difference between them is its own piece here on what validation actually does.

Then do the part almost nobody does. Write down, before you look, roughly how many URLs your site publishes on purpose that can never be indexed. Count your redirects, your canonicalized variants, your parameter URLs, and any machine-readable twins like the ones here. Compare that estimate against your not-indexed total. If the two are close, your report is healthy and its scary heading was the only problem. If your not-indexed count is far larger than anything you can account for, the gap is the actual finding, and it is worth more than any individual status ever will be.