GSC Pages Report: Indexing Status by URL

The Pages report inside Google Search Console (Indexing > Pages) is the single most important diagnostic surface in SEO. It tells you, URL by URL, whether Google has indexed your page — and if not, exactly why. Master this report and you can systematically diagnose every indexing problem on your site, validate fixes, and turn a stagnant crawl into a healthy one. This guide covers what each metric means, how to read the reasons, and the workflow to actually move the numbers.

1. What Is the GSC Pages Report?

The Pages report lives under Indexing > Pages in Google Search Console. It used to be called the Index Coverage report — Google renamed and restructured it in 2022 — but the core function is identical: show you the indexing status of every URL Google has discovered on your site.

It distinguishes between URLs Google has crawled, URLs it has indexed, and URLs it has chosen not to index — with a specific reason for each excluded URL. Unlike the older Coverage report's four-bucket breakdown (Valid, Valid with warnings, Error, Excluded), the Pages report uses a cleaner two-state model: Indexed vs Not indexed, with detailed reasons inside each.

2. The Two Top-Level Numbers: Indexed vs Not Indexed

At the top of the report you see two big counts. Indexed = pages Google has stored in its index and is eligible to show in search results. Not indexed = pages Google knows about but has chosen not to include. The ratio between these two numbers is the single best top-line health metric for your site's technical SEO.

For a healthy small-to-mid site, you'd expect 70–95% of intentionally-public URLs to be indexed. A drop into the 50% range, or a Not-indexed count an order of magnitude higher than Indexed, signals systemic issues — duplicate content, thin pages, crawl budget waste, or noindex tags fired by mistake. Watch the trendline weekly; sudden gaps usually map to a deploy.

3. Reading the "Why pages aren't indexed" Reasons

Below the chart, GSC lists every reason a page might not be indexed, with a count next to each. Severity varies enormously. Some reasons are benign ("Page with redirect" on a redirect chain you control). Some are catastrophic ("Submitted URL marked noindex" on a page you intend to rank). Knowing which is which is half the job.

Sort the reasons by count, then by severity. A 3,000-page "Discovered — currently not indexed" bucket is a much bigger problem than a 12-page "Soft 404" bucket, even though the soft 404 looks scarier. Always start with the high-volume, ranking-eligible buckets first.

4. Most Common Reasons and How to Fix

Discovered — currently not indexed: Google found the URL (probably via your sitemap) but hasn't crawled it yet. Cause is usually crawl budget pressure or low perceived priority. Fix by improving internal links, removing low-value URLs from the sitemap, and shipping fewer-but-better pages.

Crawled — currently not indexed: Google fetched the page but decided not to index it. This is a quality signal. Fix the page: more depth, original content, clear topical fit, fewer duplicates of the same template.

Duplicate, Google chose different canonical: Google indexed a different URL it considers canonical for the same content. Audit your canonical tags, hreflang, internal linking, and parameter handling.

Soft 404: Google sees a "not found" page returning a 200 status. Fix by returning a real 404 or 410, or by making the page actually have meaningful content.

5. The Sitemap Filter Inside Pages Report

At the top of the Pages report there's a filter dropdown for "All known pages" vs "All submitted pages" (i.e. URLs in your sitemap). This filter is enormously useful and often overlooked. Toggle to submitted-only to focus on URLs you explicitly want indexed.

The two views often disagree in revealing ways. Pages can be indexed without being in your sitemap (Google found them via internal or external links). Pages in your sitemap can be excluded from the index (which is a real problem because you've actively claimed they should rank). The gap between submitted and indexed is your priority work queue.

6. How to Use the Report to Find Quick Wins

Click into any reason to see up to 1,000 example URLs. Look for patterns: same path prefix, same template, same query string, same publish date. A pattern means a single fix will move dozens or hundreds of URLs at once.

Combine the Pages report with the Performance report to identify which excluded URLs would actually drive traffic if indexed. A "Crawled — currently not indexed" URL that has zero search demand isn't worth fixing. The same status on a URL that already gets impressions on a related query is a top priority.

7. Validate Fix Workflow

Once you've fixed the underlying cause, click "Validate Fix" inside the specific reason's detail page. This tells Google to re-evaluate the affected URLs on a priority queue. Validation typically takes 1–4 weeks and shows progress (Pending, Passed, Failed) inside GSC.

If validation fails, GSC tells you exactly which URLs still trigger the issue — making the second pass much faster. Don't hit "Validate Fix" until you're confident the deploy is live and propagated; a failed validation locks you into a cooldown before you can retry.

8. Pages Report vs URL Inspection Tool

The Pages report is bulk diagnostics: thousands of URLs, sorted by reason, exportable. The URL Inspection Tool is single-URL deep diagnostics: live test, last-crawl info, rendered HTML, structured data parsing, mobile usability for that one URL.

Workflow: use Pages to find the patterns and pick a representative URL. Then use URL Inspection on that URL to confirm the live status, request a fresh crawl after a fix, and read the "coverage" details with full granularity. Pages tells you what; URL Inspection tells you why for one specific case.

9. Exporting and Tracking Over Time

The UI exports up to 1,000 URLs per reason. For full-site visibility, use the Search Console API (the urlInspection.index.inspect and bulk indexing-status endpoints) to pull every URL programmatically. Schedule a weekly export into BigQuery or a spreadsheet for trend tracking.

What you want to monitor: total indexed count, gap between submitted and indexed, growth in any specific Not-indexed reason. A reason that suddenly grows by 10x week-over-week almost always maps to a recent deploy. Catching that early is the difference between a one-day rollback and a two-month traffic loss.

10. Common Mistakes Reading This Report

Mistake 1: Assuming indexed = ranking. Indexed only means Google has the page in its database and is eligible to show it. It says nothing about whether the page actually ranks for any query. Cross-reference with the Performance report.

Mistake 2: Panicking about every excluded URL. Many exclusions are correct — duplicate URLs you canonicalized, redirect chains you intentionally built, parameter URLs you'd never want indexed. Sort by intent, not by count.

Mistake 3: Ignoring data freshness. The Pages report lags by 2–7 days. A fix you shipped yesterday won't reflect until next week. Plan validation cycles accordingly and don't over-react to the first chart you see post-deploy.