You open the Page Indexing report in Search Console expecting a quick check-in, and instead you're looking at a list of labels that sound like error codes from a language you half-remember: "Crawled - currently not indexed," "Duplicate without user-selected canonical," "Alternate page with proper canonical tag." Some of these are genuine problems. Some are Google doing exactly what you asked it to. The report doesn't tell you which is which — it just hands you the count and moves on.
Most GSC guides either explain one error in isolation or gloss over the whole report with "just fix your errors." Neither approach helps when you're staring at nine different statuses and need to know which ones are actually costing you traffic. This guide goes through the report the way you'd actually use it: status by status, cause by cause, fix by fix.
Google Search Console's Page Indexing report sorts every crawled URL into a status: Error, Valid with warning, Valid, or Excluded. Error means Google tried to index the page and failed. Excluded usually means Google chose not to index it, often intentionally. Fixing GSC issues means matching each specific status to its cause — a blanket fix applied across every red label will solve some problems and misfire on others.
What is the Page Indexing report?
The Page Indexing report (formerly called the Coverage report) is Search Console's record of every URL on your site that Google has discovered, and what happened when it tried to crawl and index each one. Every URL lands in exactly one status per report, and those statuses fall into four broad groups.
- Error. Google tried to index the page and could not, due to a server response, a block, or a broken configuration.
- Valid with warning. The page is indexed, but something about it — usually a robots.txt conflict — deserves a second look.
- Valid. The page is indexed with no issues Google flagged.
- Excluded. Google chose not to index the page, which is frequently the correct outcome rather than a problem to solve.
The report groups URLs by these detailed statuses rather than the four broad categories alone, which is why the same "problem" — a page not showing up in search — can trace back to a dozen different root causes.
Why these statuses matter
Treating every red label in the report the same way wastes effort and, sometimes, breaks pages that were working as intended:
- Errors directly cost visibility. A page stuck in Error status cannot rank, no matter how good the content is, until the underlying cause is resolved.
- Not every exclusion is a problem. A noindex tag you added on purpose, or a duplicate page correctly pointing its canonical elsewhere, is Excluded working as designed.
- Some statuses reflect crawl budget, not content quality. "Discovered - currently not indexed" often means Google hasn't gotten to a page yet, not that the page is bad.
- Misreading a status can cause new damage. Removing a canonical tag to "fix" an alternate-page status can break an intentional hreflang or mobile/desktop pairing.
Step-by-step: working through the report
- Open Indexing → Pages in Search Console. Start with the summary chart rather than the raw URL list.
- Prioritize true Errors first. Server errors, redirect errors, and 404s on pages you actually want indexed cost the most and are usually the fastest to confirm.
- Click into a status to see sample URLs. Google shows a representative sample, not the full list, so treat these as examples of a pattern rather than an exhaustive audit.
- Run the URL Inspection tool on one example. This shows the live crawl result and often reveals the exact cause — a redirect chain, a robots.txt rule, a response code.
- Fix the root cause across the whole pattern. If the cause is a template issue, correcting one URL and requesting indexing won't resolve the others in that status.
- Click Validate Fix only once the fix is live sitewide. Validating early, before the underlying template or server issue is actually resolved, burns the validation attempt.
- Recheck after Google's re-crawl window. Validation runs on Google's schedule, typically resolving over one to two weeks rather than instantly.
Error by error: what each status means
1. Server error (5xx)
Google's crawler received a server-side error when requesting the page. This is almost always a hosting or application issue — an overloaded server, a misconfigured route, or a temporary outage during a traffic spike or deployment.
2. Redirect error
Google followed a redirect and hit a problem: a redirect chain that's too long, a redirect loop, or a redirect pointing to an invalid URL. Flattening redirects to a single hop per URL resolves most of these.
3. Blocked by robots.txt
The page is disallowed in robots.txt, so Google won't crawl it, even if it's linked from elsewhere on the site. This is only a problem if the page was blocked unintentionally, often by a rule left over from a staging environment.
4. Marked 'noindex'
The page itself instructs Google not to index it, either via a meta tag or an HTTP header. Correct for thank-you pages or internal search results; a mistake when it turns up on pages meant to rank.
5. Soft 404
The server returned a 200 OK status, but the page's content looks like a "not found" page to Google — thin, empty, or a generic message. Common on out-of-stock product pages or broken template fallbacks.
6. Duplicate without user-selected canonical
Multiple URLs serve near-identical content and none of them has a canonical tag telling Google which one is preferred, so Google picks one on its own — not always the one you'd choose.
7. Duplicate, Google chose different canonical than user
You did set a canonical tag, but Google's own signals — internal links, sitemaps, backlink patterns — pointed it toward a different URL as the "real" version instead.
8. Crawled / Discovered - currently not indexed
Google has either crawled the page and decided not to index it yet, or knows it exists but hasn't crawled it at all. Both often reflect crawl budget and perceived priority rather than a defect in the page itself.
Real-world examples
How these statuses show up in practice, across different kinds of sites:
The pattern across all four: the fix is almost never "resubmit the URL." It's finding the template, server condition, or tag rule producing the whole cluster of affected pages.
GSC status severity compared
Not every status deserves the same urgency. Here's how to triage the most common ones.
| Status | Category | Typical priority | Usually needs a fix? |
|---|---|---|---|
| Server error (5xx) | Error | High | Yes, almost always |
| Redirect error | Error | High | Yes, almost always |
| Duplicate, no canonical | Excluded | Medium | Yes, if the wrong page is preferred |
| Soft 404 | Excluded | Medium | Yes, on pages meant to rank |
| Discovered - not indexed | Excluded | Low | Often no, especially on large sites |
| Alternate page, proper canonical | Excluded | Low | No, usually intentional (hreflang/mobile pairs) |
Fix hreflang-related canonical errors — free
If your "Alternate page with proper canonical tag" or duplicate-canonical statuses trace back to a badly-linked international or language cluster, the Rebrixe Hreflang Generator builds a complete, return-tag-safe set of hreflang link tags for every page in the set, including x-default. No account, no watermark.