Search Console’s Page indexing report lists every reason Google gives for not indexing a URL on your site. Some are errors to fix today; many are Google confirming it did what you asked. This guide goes through each status a WordPress site is likely to see, says whether it needs fixing, and links to the guide and free tool for the fix.
Open the report under Indexing → Pages. The chart shows indexed and not-indexed pages over time; the table under Why pages aren’t indexed lists each reason with the number of affected URLs and a validation column. Click a reason to see example URLs, inspect any of them, or start validation once you have fixed it.
Every status at a glance
| Status | What it means | Fix it? | Guide |
|---|---|---|---|
| Excluded by ‘noindex’ tag | The page asks not to be indexed | Yes, if the page should be in Google | Not showing up on Google |
| Blocked by robots.txt | robots.txt stops Googlebot crawling the URL | Yes, if the page should be in Google | Not showing up on Google |
| Not found (404) | The URL returns 404 (Google treats a 410 the same) | Only URLs with traffic, links or internal links | Fix 404 errors |
| Soft 404 | Returns 200 but looks like an error or is nearly empty | Yes | Fix 404 errors |
| Page with redirect | The URL redirects; only the target can be indexed | Usually not | Fix 404 errors |
| Redirect error | A loop, a chain too long or a bad target | Yes | Fix 404 errors |
| Server error (5xx) | The server failed | Yes | Fix 404 errors |
| Duplicate without user-selected canonical | A duplicate with no canonical; Google picked another URL | If Google picked the wrong one | Canonical statuses |
| Alternate page with proper canonical tag | The page points to another canonical and Google agreed | Usually not | Canonical statuses |
| Duplicate, Google chose different canonical than user | Google overrode your canonical | Yes, if your choice was right | Canonical statuses |
| Discovered – currently not indexed | Google knows the URL but has not crawled it | If the page matters | Discovered and crawled |
| Crawled – currently not indexed | Crawled, not indexed for now | If the page matters | Discovered and crawled |
| Blocked due to unauthorized request (401) | Login or password required | Yes, if it should be public | Not showing up on Google |
| Blocked due to access forbidden (403) | The server refused Googlebot | Yes, if it should be public | Not showing up on Google |
| Blocked due to other 4xx issue | Another 4xx status | Yes | Fix 404 errors |
| Blocked by page removal tool | A removal request in Search Console hides the URL | Yes, if the request was a mistake | Not showing up on Google |
Two more statuses describe pages that are indexed but have a problem: Indexed, though blocked by robots.txt and Page indexed without content. Both are covered below.
A 15-minute weekly check
You do not need to read every status every week. This order catches what matters:
- Look at the chart first. A sudden drop in indexed pages, or a jump in not-indexed ones, matters more than any single status. Note the date it started.
- Sanity-check the indexed count. A site with 300 posts and 40 pages should have somewhere around 350 indexed URLs once you add the homepage and main categories. Far more usually means archives, attachment pages or parameter URLs are being indexed; far fewer means something is blocking posts.
- Sort the “Why pages aren’t indexed” table by pages and look for reasons that grew since last week. A growing reason with a shared URL pattern is a setting; a handful of unrelated URLs is normal churn.
- Open one example URL per growing reason in URL Inspection and run Test live URL. If the live test is fine, the report is catching up. If not, you have found the cause.
- Leave the rest. Statuses that describe your own choices, such as noindexed tags or redirected old URLs, do not need a visit every week.
Statuses caused by your settings
Excluded by ‘noindex’ tag. Google found a noindex in a robots meta tag or an X-Robots-Tag header. On WordPress, check Settings → Reading → Search engine visibility first, then your SEO plugin’s settings for the post and for its content type. Fine for pages you noindexed on purpose, such as thin tag archives. The noindex and nofollow guide explains the directives.
Blocked by robots.txt. A Disallow rule matches the URL. Blocking crawling does not remove a page from Google, which is why you may also see Indexed, though blocked by robots.txt as a warning on indexed pages. To keep a page out of Google, allow crawling and use noindex. See the WordPress robots.txt guide and noindex vs robots.txt.
Blocked due to unauthorized request (401), access forbidden (403) or other 4xx. Something stopped Googlebot: a password, a login wall, a firewall or a security plugin. Make public pages public to everyone, including crawlers. If only some requests fail, look at the firewall’s rate limits and its rules for bots; a security plugin that blocks unfamiliar user agents or whole countries can catch Googlebot.
Blocked by page removal tool. Someone with access to the property asked Google to hide the URL under Indexing → Removals. Temporary removals last about six months. If it was a mistake, open the request’s menu there and choose Cancel request.
Missing, moved and broken pages
Not found (404). Normal for deleted pages. Redirect the ones that had traffic or links to the closest live page, leave the rest, and remove internal links to them.
Soft 404. The page answers 200 but looks empty or like an error: empty archives, internal search results, themes that show “not found” without the status code. Return a real 404, noindex, or add the missing content.
Page with redirect. Google followed the redirect and left this URL out of the index; the target may be indexed instead. Only update sitemaps and internal links that still point at the old URL.
Redirect error and server error (5xx). Loops, long chains and failing servers. The redirect checker shows every hop; server errors are a hosting conversation.
All of these are covered in how to fix 404 errors in Google Search Console.
Duplicates and canonicals
WordPress serves the same content at more than one URL more often than you would think: http and https, www and not, tag and attachment pages, parameter URLs. The three canonical statuses tell you which URL Google picked and whether that agrees with your canonical tag. Start with the canonical statuses guide, and read canonical tags for duplicate content for how the tag works. The canonical checker reads the tag on any page.
Pages Google has not indexed yet
Discovered – currently not indexed and Crawled – currently not indexed are not caused by a setting. Google either has not got to the page or did not think it worth indexing. The fixes are internal links from pages that get traffic, merging overlapping posts, improving thin pages, and keeping low-value URLs out of the sitemap. See discovered – currently not indexed. The sitemap checker validates your sitemap and samples the URLs it lists for errors, redirects and noindex.
Indexed, but with a problem
Indexed, though blocked by robots.txt. Google indexed the URL from links pointing at it, but robots.txt stops it reading the page, so the result shows no description. If you want the page in Google, remove the Disallow rule so it can be crawled. If you want it out, remove the Disallow rule too, then add noindex: Google has to crawl the page to see the noindex.
Page indexed without content. Google indexed the URL but could not read anything on it. Google’s help names two likely reasons: the page is cloaked, showing Google something different from visitors, or it is in a format Google cannot index. It is not a robots.txt block. On WordPress, test the URL live and open View tested page → Screenshot: a blank screenshot points to a firewall or CDN serving Googlebot an empty response or a challenge page.
Sitemaps
Under Indexing → Sitemaps, a status such as Couldn’t fetch or Sitemap could not be read means Google could not load or parse the file. WordPress sitemaps live at /sitemap_index.xml (Yoast SEO, Rank Math) or /wp-sitemap.xml (WordPress alone). Check the address in robots.txt, then run it through the sitemap checker for XML errors.
After a page is indexed
Indexed is not the finish line. A page Google shows often but that few people click is losing traffic in plain sight. Find those pages with the CTR calculator, judge them with what is a good click-through rate, and rewrite the snippet with the guides to changing your WordPress SEO title and Yoast meta descriptions. The title and meta description checker shows where Google would likely cut them.
Two checks outside the Page indexing report are worth running on important pages too: the image alt text checker for missing or file-name alt text, and, on a store, the WooCommerce SEO checker for product pages.
How validation works
When you have fixed a status, click it in Indexing → Pages and choose Validate fix. Search Console rechecks the URLs listed under that status over the following days or weeks and shows the validation as started, then passed or failed. Before starting, confirm one fixed URL with URL Inspection → Test live URL. Do not validate statuses that list URLs you mean to keep excluded (noindexed archives, redirected old URLs); they will stay in the report, correctly.
Troubleshooting the report itself
Indexed pages dropped sharply in one week. Check the site-wide causes before anything else: the “Discourage search engines” box (some migration and staging plugins switch it on), a robots.txt change, or a burst of server errors in Settings → Crawl stats. The date on the chart tells you which deploy or plugin update to look at.
The example list stops at 1,000 URLs. That is the report’s limit. To see a different sample, add a URL-prefix property for a section, such as https://yourdomain.com/blog/; it gets its own report and its own examples.
A URL you fixed still appears under the old status. The report reflects Google’s last crawl of each URL. Test it live; if the live test is fine, wait for the recrawl or start validation.
The numbers do not match your sitemap. The report covers every URL Google knows about, not just the ones in your sitemap. Use the filter above the chart to switch between All known pages and All submitted pages, or a single sitemap.
How RankHive handles this
On a connected WordPress site, RankHive reads your Search Console every week, inspects your posts and pages with URL Inspection data, and turns what it finds into drafted fixes: a canonical, a redirect where one page should be merged into another, a robots.txt rule, internal links to a page Google is skipping, a new title for a page few people click. Each draft shows the current value next to the proposed one. Nothing changes until you approve it; then the RankHive plugin writes it to WordPress, into Yoast SEO, Rank Math or SEOPress where the field belongs to them, and the Change Log keeps a Revert button for every change. RankHive works on posts and pages, not WooCommerce products.
Related reading
- WordPress technical SEO: the settings behind most of these statuses.
- Technical SEO audit checklist: a full pass, in order.
- From Search Console data to shipped WordPress fixes: turning reports into changes.
- WooCommerce SEO: store-specific indexing problems.
Your job is to fix the statuses that keep pages you want out of Google, and leave the ones that describe your own choices. Work through them by hand with the guides above, or let RankHive check your Search Console each week and ship the fixes after you approve them.