The coverage report is the most underrated data in Search Console: which pages the search engine plans to index, which it excludes, which crawls errored — it keeps track of all of it. Ranking requires being indexed first, and many ranking problems had a red light flashing here long before; nobody just clicks in to look. If you’re not sure where to start, check the log-analysis-vs-coverage-report article.
Here’s the bottom line: coverage has four statuses. Focus on the pages in “Error” and “Excluded” that you didn’t deliberately set — pages that should rank but are completely absent are traffic black holes. Export URLs by status, debug in the order server → robots → canonical → content quality, and you can fix most collateral damage in a week.
Read the four statuses: what to do with each
“Valid” means indexed and displayable; “Discovered, not indexed” means the crawler knows the URL but hasn’t queued it, usually a content or crawl-budget shortfall; “Excluded” means not collected, actively or passively; “Error” means crawling or indexing failed outright. The first two are routine maintenance; the last two demand action.
| Status | Common causes | What to do |
|---|---|---|
| Valid | Normal indexation | Just watch the trend |
| Discovered, not indexed | Short on crawl budget or quality | Raise quality, add internal links |
| Excluded | noindex / canonical / redirect | Confirm each one is intentional |
| Error | 404 / 5xx / robots block | Highest-priority fix |
The most misread is “Excluded” — under it are a dozen sub-reasons mixed together: noindex, canonical pointing elsewhere, redirects, robots blocks. Some are deliberate, some are template bugs; you have to expand the sub-reasons and judge each one.
Order for locating frequent errors and fixing them
“Submitted URL has an issue” or “Not found” is usually a 404 or server 5xx. If the page should still exist, restore it; if it’s definitely retired, 301 it to the closest replacement. For batches of dead links and redirect loops, clear them in one pass following the dead-links and redirect-chain cleanup flow. “Excluded by noindex” mostly comes from a template mistake — forgetting to remove noindex from a test environment is a classic incident. “Duplicate content” uses canonical pointing to the authority page, written per the canonical tag reference. “Blocked by robots.txt” means going back to check whether robots.txt and sitemap mistakenly block an entire template directory.
When the count of errored pages suddenly jumps, it’s usually synchronized with a redesign, migration, or server fluctuation. Match against release records to find the timestamp — faster than guessing page by page. If organic traffic is also dropping in the same period, run the five-step organic traffic drop diagnosis in parallel.
Last week I handled one case: after an old site migrated, the sitemap wasn’t updated, and “Excluded” grew by 400+ URLs overnight, all pointing at the old domain. One 301 plus re-submitting the sitemap, the error curve dropped by day 7, and 300+ pages were rescued.
Crawl budget: why pages stay stuck in “Discovered, not indexed”
Many sites are stuck here not because of bad content but because of insufficient crawl budget. The budget has two parts: the crawl rate the server can withstand (crawl quota), and the pages’ link authority and duplication level (crawl demand); if either is low, crawlers won’t bother coming back.
Operationally, first cut noise URLs: block meaningless filter, sort, and session parameters, let the sitemap hold only canonical pages, then use internal links to concentrate authority on core pages. Also measure server response for real — if a key template’s first byte exceeds 800 ms, the crawl quota gets automatically lowered.
- Export the “Discovered, not indexed” list and see whether it concentrates on certain template or parameter URL types
- Canonical highly duplicated filter pages to the main list, or noindex them directly
- Give orphan pages 3–5 body internal links from related articles
- Compress template first-byte time, fixing the slowest template first
Two hidden traps: soft 404s and canonical conflicts
A soft 404 is content that’s already dead but still returns 200 — like “product discontinued” or “no search results” empty pages. The coverage report records them as valid, and the search engine eventually treats them as low quality. Use URL Inspection to see the actual status code; don’t judge by looks.
Canonical conflict is sneakier: if an article’s canonical points at the homepage or an unrelated page, Google collects it per the canonical — the page you thought was indexed never entered the index. Batch-scan the canonical field; pagination and parameter-filtered pages are especially easy to configure wrong.
- Do dead pages return 404 or 410 instead of a 200 soft success
- Does each page’s canonical point at itself or a clear authority page
- Does robots.txt mistakenly block template paths or static assets
- Can every URL in the sitemap open, with no multi-level redirects
Close the loop with URL Inspection
After fixing, don’t just wait for the report to refresh. Open “URL Inspection”, paste in the URL, and look at three things: the canonical URL Google chose, the indexation status, and the last crawl time. After confirming, click “Request Indexing” — it’s days faster than waiting in queue. The quota is limited, so push important pages only.
Schedule the whole round of fixes with this table:
| Timeline | Action | Acceptance bar |
|---|---|---|
| Day 1 | Fix canonical conflicts and soft 404s | Status codes and canonical URLs correct |
| Day 2–3 | Update and re-submit the sitemap | No dead links in the sitemap |
| Day 7 | Re-check error and excluded curves | Error page count drops |
| Day 14 | Re-inspect remaining collateral pages | Valid page count rises |
Log every case as one row (URL, problem, action, re-check date) — next time the same alarm fires, check against the table and save half the time.
Watch trends, not single-day screenshots
Coverage’s value lives in the curve, not the snapshot. If valid pages don’t move for two straight weeks, newly published content isn’t getting indexed normally — the problem is usually in sitemap submission, internal links, or crawl budget, not the article itself. If the excluded curve suddenly jumps a notch, compare what went live in that same period.
Five things to run through before landing
Open the coverage report and export all URLs under “Error” and “Excluded” into a table; label each as “intentional” or “collateral”, fixing collateral ones in the order server → robots → canonical → content; clear the collateral pages this week, confirm with URL Inspection, and request indexing; update the sitemap and re-submit, confirming no 404s or multi-level redirects; revisit the curves on days 7 and 14 to confirm the valid count rises. Run through these five and the coverage red light goes dark.
