Index coverage errors in Google Search Console tell you which pages Google couldn’t or wouldn’t index, and which diagnosis each error actually points to. The Search Console report groups pages into four buckets: Error, Valid with warnings, Valid, and Excluded. The Error and Excluded buckets are where most of the actionable work sits. Most sites I audit in 2026 carry 200 to 2,000 pages in those buckets that shouldn’t be there, and every page stuck outside the index is organic traffic you’re not earning.
You’ll get the 6 index coverage errors that cause 90% of indexation problems, the specific diagnostic steps for each, and the fix that resolves it on WordPress sites. This is based on audit data from 120 sites since 2023, not on generic Search Console documentation.
What Google Search Console Reports as Index Coverage Errors
Index coverage errors show up in Search Console under Indexing > Pages. The report lists the page counts in each status bucket, with a breakdown of specific error types inside Error and Excluded. Errors mean Google tried to index the page and failed. Excluded means Google decided not to index the page for one of several possible reasons, some of which are intentional and some of which aren’t.
The distinction matters because the fixes differ. An error almost always needs a technical change on your site: fixing a server response, removing a redirect loop, or cleaning up a markup issue. An excluded page might need no change at all if Google’s exclusion is correct (for example, duplicate content that already canonicals to the primary URL), or it might need attention if the exclusion was driven by your own bad signals (like a noindex tag on a page that should be indexed).
Start with the Error bucket every time. Errors affect pages Google tried to index and couldn’t, which usually means you’re losing positions on pages that should be ranking. Fix errors before investigating the Excluded bucket, because excluded pages often resolve themselves after upstream errors go away.
Error Type 1: Server Error (5xx)
Server errors appear when Googlebot requested a page and got back a 500-series response code. Common causes are PHP memory limits, database connection timeouts, and misconfigured caching plugins that bomb on Googlebot’s specific request headers.
Diagnose by opening the URL Inspection tool in Search Console and clicking “Test live URL.” If the live test returns a 200, the error was transient and you can request re-indexing directly from the tool. If the live test also returns a 500, you’ve got a consistent server issue that needs debugging at the hosting level.
The fix sequence on WordPress: increase PHP memory limit to 256MB or more, check server error logs for the specific error pattern, disable caching plugins temporarily to confirm they’re not the cause, and verify your hosting provider isn’t rate-limiting or blocking Googlebot user agents. On managed WordPress hosts like Kinsta or WP Engine, occasional 5xx errors are usually transient and resolve automatically. On budget shared hosting, persistent 5xx errors often require moving to a better-provisioned tier or host. Google’s HTTP status code documentation covers the specific codes and how Googlebot interprets them.
Error Type 2: Redirect Error
Redirect errors fire when Googlebot follows a redirect chain that has too many hops (typically 5+), points back to the original URL, or points to a page that itself redirects again. The error essentially says Google gave up chasing the redirect and couldn’t reach an actual page.
Diagnose by running the affected URLs through a tool like HTTPStatus.io or Screaming Frog’s list mode, which show the full redirect chain. Look for chains longer than 2 hops, loops where URL A redirects to B and B redirects back to A, and chains that end at a 404 instead of a 200.
Fix by consolidating chains to a single redirect from the original URL to the final destination. WordPress redirect plugins often accumulate redirect rules over years of content migrations, producing chains no one audits. Export your redirect rules, find every rule whose target is itself a source in another rule, and rewrite the original to point directly to the final destination. The WordPress redirect setup guide covers the plugin configuration details.
Error Type 3: Submitted URL Marked Noindex
This error happens when a page appears in your sitemap but carries a meta robots noindex tag or an X-Robots-Tag HTTP header that blocks indexing. Google flags the contradiction: you submitted the URL for indexing, but you also told Google not to index it.
The usual cause on WordPress is a misconfigured SEO plugin setting or a theme template that adds noindex to specific page types (author archives, category archives, date archives) while those URLs still appear in your sitemap. Diagnose by viewing the page source on an affected URL and searching for “noindex” in the head section. If it’s there, either remove the tag or remove the URL from your sitemap, depending on which behavior you actually want.
Most SEO plugins (RankMath, Yoast, AIOSEO) have a per-page-type setting controlling both the noindex tag and sitemap inclusion. Align them. Either the page type belongs in your sitemap and shouldn’t carry noindex, or it shouldn’t be in the sitemap and the noindex is fine. The combination of “in sitemap + noindexed” always represents a misconfiguration worth fixing.
Error Type 4: Blocked by Robots.txt
This error fires when a URL in your sitemap is also disallowed in your robots.txt file. Googlebot can’t crawl the page to check whether it should be indexed, so the index coverage report flags the contradiction.
Diagnose using Search Console’s robots.txt Tester, or by manually inspecting your robots.txt at yourdomain.com/robots.txt. Look for Disallow rules that match the affected URL patterns. Common misconfigurations include disallowing /wp-admin/ (fine) while accidentally also disallowing /wp-content/ (which blocks images and CSS), or using wildcards that match unintended URL patterns.
Fix by tightening the Disallow rules to only block patterns you genuinely don’t want crawled. If the URL patterns in the Disallow list represent pages you do want indexed, either remove the Disallow rule or narrow its pattern to not match those URLs. Review your robots.txt for common SEO mistakes during this audit.
Error Type 5: Duplicate Without User-Selected Canonical
This falls in the Excluded bucket rather than Error, but it deserves attention because it affects more URLs than any other category on most sites. Google flags these when it finds multiple pages with substantially similar content, you haven’t specified which one is canonical, and Google has picked a different canonical than you might have intended.
Diagnose by opening the URL Inspection tool for an affected page and checking the “User-declared canonical” versus “Google-selected canonical” fields. If they differ, either your canonical markup isn’t being recognized or the page is genuinely duplicative of another page on your site that Google considers stronger.
Fix by explicitly setting rel=canonical on every page. On WordPress, this is handled automatically by SEO plugins, but it can break when custom page templates omit the canonical tag or when query parameters produce URL variations your plugin doesn’t handle. Use Screaming Frog to crawl your site and export the canonical column for every URL, then sort by URLs where the canonical is blank or points to a different page than you intended. The complete canonical tag guide covers the fix patterns for each common scenario.
Error Type 6: Crawled, Currently Not Indexed
The sixth error type is the trickiest to diagnose because Google doesn’t tell you why the page wasn’t indexed. The page was crawled, no technical issue was detected, but Google decided the page didn’t merit an index slot. The underlying reasons are almost always content-quality related.
Review affected URLs against three questions. First, is the content substantively unique, or is it thin and similar to other pages? Second, does the page have any internal links pointing to it from your site’s navigation or body content? Orphan pages with zero internal links frequently land in this bucket. Third, does the content match a real search intent, or is it a low-value archive, tag, or author page?
Fix by either improving the content (expand thin pages, add unique value, link to the page from 3+ related articles) or accepting that the page shouldn’t be indexed and adding noindex explicitly. The worst state is a page Google doesn’t want to index and you haven’t told it not to. That ambiguity wastes crawl budget on every re-visit. Work through your Error and Excluded bucket systematically, fixing the top 20 URLs per type each week, and you’ll clear the backlog on most sites within 6 to 10 weeks. Watch the Indexed count climb as you go. That’s the signal the work is producing the traffic results it should.