A Search Console warning is only useful once you know which page it affects and what that page is supposed to do. A 404 on an old URL with no replacement may be fine. A 404 on your main service page is urgent. The same distinction applies to “not indexed”: the number alone won’t tell you what to fix.
The most effective workflow starts with important URLs, not a quest to clear every warning. Use the Page indexing report to find patterns, URL Inspection to test representative pages, Crawl Stats when access looks unreliable, and Performance to see where search visibility is being lost. Then fix the underlying cause and check whether the result changed.
Set a baseline before opening the issue reports
First, make sure you’re looking at the right property. A Domain property includes subdomains and both HTTP and HTTPS; a URL-prefix property includes only URLs that match its specified prefix. If Search Console appears to be missing a section of your site, check the property selection before treating the gap as an indexing problem.
Next, make a short list of pages that should earn search traffic: the homepage, major category or service pages, key products, and articles that support them. Note which have been published or changed recently. This gives you a test set for the reports. Without it, you can spend hours investigating filtered URLs and old redirects while a valuable page stays out of the index.
Open Performance → Search results and record a baseline for clicks and impressions over a useful period. Compare it with the preceding period, or use a longer view if your business is seasonal. Don’t diagnose a drop from the site-wide chart alone. Your first question is whether it affects the whole site, one section, or a few URLs.
Triage the Page indexing report by intent
In Indexing → Pages, open “Why pages aren’t indexed.” Each row groups URLs by a reported reason; click a reason to see its trend and example URLs. The examples are a starting sample, not necessarily a complete inventory. To check a particular URL, use URL Inspection rather than searching for it in the report.
Your target is not 100% indexing. It’s the indexing of the preferred, or canonical, version of each important page. Redirects, duplicate URLs, removed pages, and deliberately excluded pages can all appear under “Not indexed” without needing repair. Look for a sudden increase in a reason affecting pages you intend to show in Search.
These common statuses call for different responses:
| Report reason | What to check and do |
|---|---|
| Server error (5xx) or redirect error | Test affected URLs. Fix the server response or redirect path, especially if key pages are involved. |
URL blocked by robots.txt or URL marked noindex |
Decide whether the restriction is intentional. If the page should be searchable, remove the relevant block or directive. |
| Not found (404) | Restore a page that should still exist. If it moved and has a clear replacement, redirect it. If it is gone without a replacement, a 404 may be correct. |
| Soft 404 | Check what Google sees. A missing-page message served with a successful response should return a real 404; a genuine page may need its content or rendering fixed. |
| Discovered – currently not indexed | Google knows the URL but hasn’t crawled it. Check how it is linked, whether it belongs in the sitemap, and whether crawl availability is a problem. |
| Crawled – currently not indexed | Google crawled it but hasn’t indexed it. Review the page itself and any near-duplicates; repeatedly requesting another crawl isn’t the fix. |
| Duplicate or alternate page | Inspect the URL Google chose as canonical. Leave expected duplicates alone; investigate only if Google selected the wrong page for your purpose. |
Those distinctions matter. Google’s indexing-status descriptions do not treat every excluded URL as an error, and a robots.txt block is not a dependable way to keep a URL out of search results: Google can sometimes index a known URL without crawling its contents. If exclusion is the goal, use a method suited to that goal rather than adding more crawl blocks.
For a manageable audit, group affected URLs by page type. If 300 product filters are marked duplicate and two product categories are marked noindex, the two categories are probably the first job. Check several URLs from the same template, not just the first example; a template or publishing setting may explain the whole group.
Use URL Inspection to separate an old report from a live problem
Paste an affected URL into the inspection bar. Review its reported index status, last crawl, crawl accessibility, indexing permissions, and Google-selected canonical. Then click Test live URL to see whether the page is accessible after any changes you’ve made. If rendering is suspect, examine the tested page and its loaded resources.
The distinction between the indexed result and the live test is crucial. The indexed result reflects what Google last recorded; the live test checks the page available for testing now. A successful live test does not prove Google will index the page, and it cannot predict which duplicate Google will choose as canonical. URL Inspection documents those limits, so don’t close an indexing issue solely because the live test passes.
Suppose a service page is reported as noindex, but the live test no longer finds that directive. Check when Google last crawled it. If the directive was removed afterward, the likely next step is to let Google recrawl the fixed page—not to change the page again.
Check whether Google can reach the site reliably
If many important URLs suddenly show access errors, or discovery stalls across a section, go to Settings → Crawl stats. Start with Host status, then examine crawl responses around the time the problem began. A rise in server errors, DNS failures, or robots.txt availability problems deserves attention before you rewrite page copy.
Crawl Stats shows requests and examples, not a complete, searchable crawl history for every URL. It is available on root-level properties, and Google describes it as an advanced report that smaller sites generally need not monitor closely. For a specific missing page, URL Inspection is usually the better first stop; for a pattern of serving failures, Crawl Stats shows host availability and response trends.
When you find a pattern, follow it to the system responsible. A run of 5xx responses may point to hosting or an overloaded application. Redirect errors call for checking the full path a URL takes. Unexpected robots.txt failures call for testing the file’s availability, not merely reading its rules. Work with whoever controls the server or site template and retest representative URLs after the change. Don’t label every 404 in Crawl Stats a failure; a removed page can return 404 correctly.
Also check Sitemaps when important URLs appear undiscovered or a newly published section is slow to appear. The Sitemaps report shows whether Google could fetch a submitted sitemap; filtering Page indexing by sitemap helps you examine the URLs it contains. Keep the sitemap focused on the preferred URLs you want indexed. Successful sitemap processing means Google read it—not that every listed page has been crawled or indexed.
Use Performance to find content problems—not invent technical ones
Once important pages are accessible and their index status makes sense, return to Performance → Search results. Turn on clicks, impressions, click-through rate (CTR), and average position. Compare periods, then open Pages and sort by the change in clicks. Filter to an affected page and switch to Queries to see which searches changed. You can also select a query first, then open Pages to see which URLs appeared for it.
Read combinations of signals, not isolated metrics:
- Impressions and clicks both fell. Check whether the loss is broad or confined to a URL or topic. Review indexing and crawl reports for a matching change; if there isn’t one, examine search demand and the page’s usefulness for affected queries.
- Impressions held steady but clicks fell. Look at the queries and the result shown for them. A page title or snippet that poorly describes the answer may be worth improving, but don’t promise a CTR gain from an edit.
- A page earns impressions for the wrong questions. Review whether its content actually answers those searches. If it doesn’t, strengthen the page’s focus or create a genuinely useful page for the distinct need.
- One query shows an unexpected URL. Compare the pages that appear for it. Decide which page should serve that intent, then check their content, internal links, and canonical signals before changing either one.
This is where site-wide averages mislead. Average position blends searches with different rankings, and a low CTR is less informative without looking at the queries behind it. Google’s Performance workflow lets you compare changes by page and query; use that detail to frame a specific fix rather than treating a single metric as a diagnosis.
If a traffic drop has no matching crawl or indexing problem, resist adding technical fixes just to do something. Google’s traffic-drop guidance distinguishes technical issues from changes in rankings and search demand. Compare similar periods and inspect the affected queries before deciding which explanation fits.
Fix the cause, then verify the outcome
Keep a small issue log: affected page or template, report reason, intended index status, suspected cause, change made, and date. Rank work by the value of the affected pages and the scope of the fault. A site-wide access failure comes before a low-CTR article; an accidentally excluded service page comes before harmless duplicate filter URLs.
After a technical change, test a few affected pages live. For a single important updated URL, Request indexing in URL Inspection can prompt another crawl. For many new or changed pages, make sure the sitemap is accurate. A recrawl request does not guarantee indexing, so there’s little value in resubmitting an unchanged page over and over.
If you fixed every instance of a reported issue, use Validate fix on its details page and watch the result. Google can also update issue counts through normal recrawling without a validation request. Finally, check the outcome that justified the work: whether the preferred pages were indexed and whether their clicks and impressions changed over a comparable period. A cleared warning is progress; recovered visibility is the result you were working for.