How to find every accidentally noindexed page on a WordPress site
Noindex is a single word in a meta tag or an HTTP header, and nothing about a normal page view shows you it's there. Here's where it actually comes from and how to find every instance, not just the one you already suspect.
A page can be published, linked from your navigation, and still carry a directive telling search engines to skip it entirely. Nothing in the WordPress editor flags this. The post looks exactly like every other published post.
This isn't rare. It's the most common way a site loses pages from Google without anyone noticing until traffic on that page quietly goes to zero.
The three places noindex actually comes from
Noindex reaches a page through one of three unrelated mechanisms, and knowing which one you're dealing with changes where you look.
The most common is WordPress's own site-wide setting: Settings → Reading → "Discourage search engines from indexing this site." It's meant for a site still in development, and it adds a noindex directive to every page's <head> until someone unchecks it — which is easy to forget after a staging-to-production launch.
The second is a per-post toggle in whichever SEO plugin is active — Yoast's "Allow search engines to show this Post in search results?" or Rank Math's equivalent robots-meta control. Set intentionally on one post, it's usually fine. Set by a bulk-edit action, an import script that carried a default value, or a copy-paste from a template post, it silently spreads.
The third is easy to miss entirely: an X-Robots-Tag HTTP response header, set at the server or CDN layer rather than in WordPress at all. It never appears in the page source, and most SEO plugins have no way to see it because they only control what WordPress renders into the page. It's a common leftover from a staging environment's blanket noindex rule that didn't get removed at launch.
Checking one URL
For the first two mechanisms, view the page source and search for <meta name="robots">. If it contains noindex, that's your answer, and it tells you nothing about which of the two settings caused it — you'd still need to check Settings → Reading and the post's own SEO panel.
The X-Robots-Tag header won't show up there at all, since it's a response header, not markup. Content Signal's free page checker reads both in one fetch — the meta tag and the response header — and tells you which one is actually blocking the page, since they call for different fixes.
Why Search Console's URL Inspection isn't the same check
Google Search Console's Live Test reflects what Google's crawler saw the last time it visited, which can lag the page's current state by days. If you just fixed a noindex tag, Search Console may still show the old, blocked result until the next crawl.
Checking the live page directly tells you what's being served right now. Both views matter — one tells you what's true today, the other tells you what Google currently believes.
Why checking pages one at a time doesn't scale
A single bulk-edit action, a theme migration, or a plugin update with a changed default can noindex dozens of posts in one step, and there's no notification when it happens. The only way to know is to check — and checking a few hundred published posts one URL at a time isn't something anyone actually does on a recurring basis.
- A staging clone pushed to production with "Discourage search engines" still checked.
- A bulk-edit action applied to the wrong filtered view of posts.
- An SEO plugin migration that reset per-post robots settings to a new default.
- A CDN rule written for a maintenance window that never got removed.
What the free plugin adds
The free Content Signal WordPress plugin scans every published post and page locally, no account or external request, and flags every one where the SEO metadata contains a noindex directive on content that's supposed to be public. It compares each scan against the previous one, so a newly introduced noindex shows up as a new finding instead of disappearing into a static list.
It reads the same per-post and site-wide settings the plugin-toggle and site-wide checkbox mechanisms control — it doesn't fetch each page's HTTP headers, since that would require an external request the local audit deliberately avoids. That's exactly the gap the page checker's server-header check fills for a single URL you already suspect.
Frequently asked questions
If I fix a noindex tag, does the page come back to Google immediately?
No. Removing the directive only makes the page eligible for indexing again — Google still needs to recrawl it. Request indexing for the specific URL in Search Console to speed that up rather than waiting for the next scheduled crawl.
Can a page be noindexed for some search engines and not others?
Only through robots.txt rules scoped to a specific crawler's user-agent. A meta robots or X-Robots-Tag noindex directive applies to every compliant crawler that reads it — there's no per-engine version of that mechanism.
Does the site-wide "Discourage search engines" checkbox noindex pages retroactively, or only going forward?
It's not retroactive in the sense of deleting anything — it's a live setting that adds the noindex directive to every page render for as long as it stays checked. Unchecking it removes the directive from the very next page load; no historical cleanup is needed.
Check whether a single URL has this problem right now, free, at the page checker. To catch it across every published post and page, install the free plugin.