Short answer: the plugin setting only controls the tag the plugin prints. Google obeys whatever the page actually sends, and that can come from somewhere else: the WordPress Reading setting, a per-post override, a second plugin or theme, or an X-Robots-Tag header added by the server or CDN. Look at the live HTML and the response headers, not the settings screen, and the real source is usually found within ten minutes.
Why can a post be noindex when Yoast or Rank Math says index?
Google decides from the page it fetches. Its documentation says a noindex rule can be delivered either as a meta tag in the HTML or as an X-Robots-Tag HTTP header, and that if several rules conflict, the most restrictive one applies. So one stray noindex anywhere in the response wins, even if the plugin prints index, follow right beside it.
The plugin screen is only a view of what that one plugin intends to output. It cannot see what other code, the web server or a CDN adds afterwards.
Where does the noindex actually come from?
Work through these in order. They cover most cases on client sites.
| Source | How to spot it | Fix |
|---|---|---|
| Settings, Reading, "Discourage search engines" | Box is ticked. WordPress adds a robots noindex tag sitewide. | Untick it and save. |
| Per-post override | The Advanced section of the Yoast or Rank Math box on that one post is set to noindex. | Reset it to the default or to index. |
| Post type or Rank Math Robots Meta setting | Every post of that type is affected. In Rank Math, check Titles and Meta, Posts, and whether custom robots meta is switched on with Noindex ticked. | Turn custom robots off or untick Noindex. |
| Second plugin or theme | Two robots meta tags in the HTML, or a tag that survives after you change the SEO plugin. | Disable the other source, or remove its wp_robots filter. |
| Server or CDN header | The tag is not in the HTML, but the response headers carry X-Robots-Tag: noindex. | Remove the header rule in Nginx, Apache, a Cloudflare rule or the host panel. |
| Cache | The settings are fixed but the old HTML is still served. | Purge page cache and CDN cache, then recheck. |
The Reading setting is the classic cause after a staging site goes live. WordPress documents it on its Reading screen page, and the output goes through the wp_robots filter, which any plugin or theme can change.
How do I check the live page in under a minute?
Fetch the page the way a crawler does. This prints the response headers and any robots meta tag in the HTML:
curl -sI https://client-site.example/blog/some-post/ | grep -i x-robots-tag
curl -s https://client-site.example/blog/some-post/ | grep -i '<meta name="robots"'An example of what a problem looks like (illustrative output):
x-robots-tag: noindex, nofollow
<meta name='robots' content='index, follow, max-image-preview:large' />The HTML says index, but the header says noindex, so the page is not indexable. The plugin is innocent here. The header was added at the server or CDN. If you would rather not use a terminal, the free noindex checker shows both the meta tag and the header for any URL.
Then confirm what Google saw. In Search Console, run the URL Inspection tool and read the Indexing section. It states whether indexing is allowed and whether the page was "Excluded by 'noindex' tag". Use "Test live URL" after your fix to see the current state rather than the last crawl.
What are the exact fix steps?
- Run the two curl commands above on one affected post and one that works. Compare them.
- If the header carries
noindex, find where it is set: web server config,.htaccess, a Cloudflare Transform or Response Header rule, or the host's control panel. Remove it there. - If the meta tag carries
noindex, check Settings, Reading first. Then check the post's Advanced box, then the post type settings in the SEO plugin. - If you see two robots tags, disable plugins one at a time on a staging copy until the extra tag disappears.
- Purge every cache layer: the cache plugin, the host cache and the CDN.
- Repeat the curl check, then use "Test live URL" and "Request indexing" in Search Console for the key pages.
Google's own page on blocking indexing adds one caution: the page must be crawlable for Google to see that the noindex was removed, so do not leave it blocked in robots.txt while you fix it.
What do I tell the client?
Keep it short and factual. For example: "Some of your posts were telling Google not to list them. The cause was a setting outside the SEO plugin, which is why the plugin looked fine. It is removed now, we have asked Google to recrawl the key pages, and recovery usually takes days to a few weeks. We will keep checking the pages each day." Do not promise a ranking date. Google decides when to recrawl and reindex.
How does quietwatch catch this every day?
quietwatch fetches your client pages daily and reads the live response, both the meta robots tag and the X-Robots-Tag header, so a noindex that appears after a plugin update, a migration or a CDN change is flagged the same day. See what quietwatch checks every day for the full list. The free tool above is the place to start with one URL.