Google Search Console Coverage Report — A Complete Guide

The Coverage report is buried inside Google Search Console under the "Indexing" section, and many site owners open it once, see a wall of Excluded URLs, and close it without taking any action. That's a missed opportunity. The report tells you exactly which pages Google is and isn't indexing, and why — information that's otherwise invisible without direct access to Googlebot's decision log.

The challenge is interpreting what each status actually means and knowing which issues are worth acting on versus which are intentional. Not every Excluded URL is a problem. Not every Error has the same urgency. This guide walks through each status, explains what causes it, and tells you where to focus your effort first.

The Four Status Categories

Every URL Google has encountered is assigned to one of four top-level statuses. Here's what each means and what action, if any, is required.

Error Statuses — Fix These First

Error statuses mean Google tried to index the page and couldn't. Every URL with an Error status is receiving no organic search traffic from that URL. These are the highest priority to fix.

Server error (5xx): Google requested the page and your server returned a 5xx error — 500 Internal Server Error, 503 Service Unavailable, 504 Gateway Timeout, and so on. These pages receive no rankings. Fix your server infrastructure first; if the errors are intermittent (Googlebot hitting during a deployment window), set up a maintenance page that returns a 503 with a Retry-After header so Googlebot knows to come back.

Redirect error: A redirect loop, a chain that is too long (Google gives up after around 10 hops), or a redirect that terminates at an error page. Use the Redirect Tracer to map the exact chain for any flagged URL and identify exactly where it breaks or loops. A common cause is a URL in the sitemap that was redirected after a site migration but the sitemap was never updated to point to the final destination.

Submitted URL not found (404): A URL you submitted in your XML sitemap returns a 404. Either restore the page with its original content, set up a 301 redirect to the most relevant live page, or remove the URL from your sitemap. Leaving 404 URLs in a sitemap signals poor site hygiene and wastes crawl budget.

Submitted URL seems to be a Soft 404: The page returns HTTP 200 but Google determined it has no meaningful content. Common causes: empty category pages ("No products found"), "no results" search result pages, auto-generated thin pages with only a title and boilerplate text. Add real, substantive content to these pages, or remove them from the sitemap and consider a 301 redirect to a relevant parent page.

Submitted URL has crawl issue: A catch-all for various crawl-level problems that don't fit the other categories. Click into the specific URL in GSC to see the exact issue reported — it could be a DNS resolution failure, a connection timeout, or an unusual response code. The "Inspect URL" feature in GSC will show you what Googlebot actually saw when it tried to fetch the page.

Excluded Statuses — Which to Investigate

Not all Excluded is bad. Some exclusions are deliberate — you told Google not to index the page and it complied. The key is distinguishing between intentional exclusions and ones where Google made a decision you didn't expect.

Intentional — usually fine to leave alone:

"Excluded by 'noindex' tag": You added <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header to this page. If that was deliberate (login pages, admin pages, thin auto-generated pages), this is working as intended.

"Blocked by robots.txt": Your robots.txt file has a Disallow rule covering this URL. Google respects the rule and doesn't index it. If you didn't intend to block this URL, check your robots.txt file — prefix matching often catches more than intended.

"Canonicalised": This URL has a <link rel="canonical"> tag pointing to a different URL, and Google is deferring to that canonical. If you set the canonical intentionally, this is correct behaviour.

"Duplicate without user-selected canonical": Google found near-duplicate content at multiple URLs and chose its own canonical — one you didn't specify. Usually harmless if Google picked the right URL, but worth checking that it chose the right one.

Investigate these:

"Discovered — currently not indexed": Google knows the page exists (via a link or sitemap) but hasn't crawled it yet or has chosen not to prioritise it. This is often a crawl budget issue on larger sites, or a signal that Google doesn't consider the page important enough to crawl. Improve internal linking to these pages so they receive more PageRank signals; ensure they're included in your sitemap; and most importantly, ensure the pages have substantial, original content that justifies crawling.

"Crawled — currently not indexed": The hardest status to fix. Google crawled the page, processed it, and decided it wasn't worth including in the index. The most common causes: thin content with little original information, near-duplicate content that closely matches an existing indexed page, content that Google considers low-quality or auto-generated, or pages that appear to be soft 404s even though they return 200. The fix almost always involves significantly improving the content — adding depth, original analysis, structured data, and genuine user value. Removing the page and redirecting to a stronger related page is sometimes the better choice.

"Alternate page with proper canonical tag": This URL exists alongside another URL that you've designated as the canonical. Check that the canonical URL you specified is correct and is itself indexed as Valid. If the canonical is wrong, update it.

"Duplicate, Google chose different canonical than user": You specified a canonical pointing to URL A, but Google chose URL B instead. This usually means Google's signals (backlinks, internal links, content similarity) are stronger for URL B than URL A. Investigate why Google prefers the other URL — it may have more inbound links or be referenced more heavily from your own site. Strengthen your preferred canonical with internal links and ensure it has the stronger content.

Warning Statuses

"Indexed, though blocked by robots.txt": The page is in the index despite a robots.txt Disallow rule covering it. This happens because Google can infer a page's existence from external backlinks without crawling it. If you want this page definitively out of search results, robots.txt blocking alone is not sufficient — you need to also add a noindex directive. The catch: if robots.txt blocks crawling, Googlebot can't see the noindex tag. The recommended approach is to temporarily allow crawling, let Google see the noindex, then re-block with robots.txt.

"Page indexed without content": Google indexed the page but found no readable text content. A common cause on JavaScript-heavy sites is that Googlebot didn't render the JavaScript that populates the page's content. Use the "Inspect URL" tool in GSC to see Googlebot's rendered view of the page — compare it to what you see in your browser. If the rendered view is blank or missing content, you need to either server-side render the content or ensure your JavaScript is rendering within a timeframe Googlebot will wait for.

Using the Coverage Report Effectively

The raw numbers tell you less than the trend and the mix. Here's how to get the most out of the report.

1. Sort by URL count. GSC groups URLs by status reason. The reason with the most affected URLs is your highest-impact fix. If "Discovered — currently not indexed" has 3,000 URLs and "Server error (5xx)" has 12, start with the server errors in absolute terms — but weigh which fix is actually achievable and impactful.

2. Track the "Submitted and indexed" count. This is your core health metric: how many of your sitemap-submitted URLs are actually indexed. It should grow over time. A sudden drop is a red alert — Googlebot may have encountered a new error, a robots.txt change, or a mass noindex deployment.

3. Cross-reference with the Sitemap report. GSC's Sitemap report shows how many URLs from each submitted sitemap are indexed. Sitemap-submitted URLs appearing as Excluded in the Coverage report are the highest priority to investigate — they represent pages you explicitly said you wanted indexed, but Google declined.

4. Use "Inspect URL" on specific problem URLs. Clicking into an individual URL in the Coverage report gives you access to the URL Inspection tool. This shows Googlebot's actual rendered view of the page, the date Google last crawled it, the HTTP response code it received, and the indexing decision. This is the ground truth for diagnosing any individual URL issue.

5. Monitor trends over time. A spike in Errors or a sudden drop in Valid URLs is the earliest signal of a site problem — often faster than a rankings drop or a manual review notification. Set a reminder to check the Coverage report at least once a week on active sites.

Diagnosing With External Tools

GSC tells you what Google decided. External tools help you understand why — and fix the underlying issues before Google's next crawl.

ByteWaveNetwork Sitemap Validator: Fetches your XML sitemap and checks every URL for 404 responses, noindex tags, and canonical mismatches — the same conditions the Coverage report flags as Errors. Run it before submitting a new or updated sitemap to GSC, and again whenever the Coverage report shows a spike in Errors. It's the fastest way to catch sitemap hygiene issues without waiting for Googlebot's next crawl cycle.

ByteWaveNetwork SEO Analyzer: Crawls your entire site and surfaces noindex tags, canonical mismatches, missing canonical tags, and near-duplicate content — the content-quality signals behind "Crawled — currently not indexed." If a cluster of pages shares that status, an SEO Analyzer crawl will often reveal the common thread: they all have the same thin description, the same boilerplate structure, or a canonical pointing somewhere unexpected.

ByteWaveNetwork Redirect Tracer: For any URL showing "Redirect error" in the Coverage report, paste it into the Redirect Tracer to map the exact chain. You'll see every hop, every status code, and the final destination — or where the chain breaks into a loop or terminates at an error. This is faster and more reliable than manually following redirects in a browser, which may be affected by cookies or session state that Googlebot doesn't have.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.