--- title: "How to Read Search Console's Indexing Report" description: "A plain walkthrough of the Page indexing report in Google Search Console: which statuses need fixing, which are noise, and what to check monthly." date: 2026-08-26 updated: 2026-08-26 tags: [seo wednesday, search console, indexing] url: "https://drivenhost.com/blog/search-console-indexing-report" author: DrivenHost --- Search Console will tell you exactly which of your pages Google has stored and which it has skipped. Most owners open the Page indexing report, see a red line trending upward, and close the tab. That is a shame, because this report is the closest thing you get to a log file written from Google's side of the connection. This week we walk through it the way we would read it for a customer. ## Start with the ratio, not the red line The top of the report shows two counts: indexed pages and pages that are not indexed. The second number is usually much larger, and that alarms people who have never looked before. It should not. A normal WordPress site generates far more URLs than it has real pages. Tag archives, paginated category pages, author archives, feeds, attachment pages, search result URLs, all of them are URLs Google can find and mostly should ignore. So the useful question is not "why are 400 pages not indexed", it is "are the 60 pages I actually wrote all in the indexed bucket". Count your published posts and pages in wp-admin, compare, and work from the gap. ## The statuses worth acting on Click into the not-indexed list and you get statuses. These are the ones we treat as real work. **Server error (5xx).** Google tried to fetch the page and your server failed. This is the one status that is squarely a hosting problem, and it is worth checking the [DrivenHost status page](/status) and your own error logs for the same timestamps. A handful of 5xx entries during a plugin update is nothing. A steady stream means something on the site is falling over under crawl load, often a heavy plugin or a database query that times out. **Crawled, currently not indexed.** Google fetched the page, read it, and decided not to keep it. There is no technical fault to fix here. It is a quality judgment, and it usually lands on thin pages, near-duplicate service pages written for slightly different towns, or posts that repeat what three other posts on the site already say. Merge them, expand the best one, or accept that the page exists for humans and not for search. **Discovered, currently not indexed.** Google knows the URL exists but has not fetched it yet. On a small site this often clears itself in a couple of weeks. When it lingers across hundreds of URLs, it is usually a sign that crawling your site is slow or expensive, so Google is rationing. Faster responses genuinely help here, which is the practical end of what we covered in [site speed and SEO](/blog/speed-and-seo), and so does cutting the number of junk URLs you expose in the first place. **Duplicate without user-selected canonical.** Two or more URLs serve near-identical content and you have not told Google which one is the original. Set a canonical tag, or better, stop generating the duplicate. **Soft 404.** The page returns a 200 status but looks empty or looks like an error to Google. Empty archive pages and broken shortcodes are the usual culprits. ## The statuses that are usually fine Plenty of entries in that list are the system working correctly. "Excluded by noindex tag" is fine if you added the noindex on purpose. "Alternate page with proper canonical tag" means your canonicals are doing their job. "Page with redirect" is expected for a while after you change URLs, and if you are mid-move our notes on [doing redirects properly](/blog/redirects-done-right) still apply. "Blocked by robots.txt" only matters if you blocked something by accident. Our rule of thumb: open the URL list behind a status and read the actual addresses. If they are pages you would send a customer to, fix them. If they are `?replytocom=` variants and tag archives, close the tab and go do something useful. ## Inspect before you change anything The URL Inspection tool at the top of Search Console is the part people skip. Paste in one problem URL and it shows you when Google last crawled it, which canonical Google chose (not the one you declared, the one it picked), and whether the page rendered. Run the live test and read the rendered HTML. We have lost count of the times a page looked perfect in a browser and came back to Google as a nearly empty shell because a caching plugin or a JavaScript builder was serving something different to a bot. Use Request Indexing sparingly. It queues a recrawl, nothing more, and hammering it does not make a page rank. ## Make it a fifteen minute habit Once a month is enough for most sites. Open the report, compare the indexed count with last month, click the two largest not-indexed statuses, inspect three URLs from each, and either fix the cause or write off the status as noise. When you do fix something, hit Validate Fix so Google reprocesses the batch, then leave it alone. Validation runs take days, sometimes a few weeks, and refreshing the report daily changes nothing except your mood. If your report is filling up with server errors or crawl slowdowns you cannot explain from the site side, that part is our fence to mend. Open a ticket with [our support team](/support) and we will read the server logs alongside you.