Find and Remove an Accidental Noindex in WordPress

Fetch the page the way a logged-out visitor gets it and read two places: the robots meta tag in the HTML and the X-Robots-Tag HTTP header. The exact value, and which of the two carries it, points to the layer that added the noindex: WordPress’s own visibility setting, an SEO plugin, the theme, the server, or a cached copy. Change it at that layer, purge caches, retest, and then ask Google to recrawl.

This guide is for a noindex you did not intend. If you want to keep a page out of search on purpose, Keep a Page Out of Search covers the settings.

Confirm the noindex is still there

In Search Console, the Page Indexing report lists the page under “URL marked ‘noindex’.” Google’s Page Indexing report help, checked September 27, 2026, describes it: “When Google tried to index the page it encountered a ‘noindex’ directive and therefore did not index it.”

That describes Google’s last crawl. Inspect the URL and run Test live URL, then read Indexing allowed? in the result. If the live test says indexing is allowed and Crawl allowed? also says yes, the noindex has already been removed and Google has not recrawled; skip to the last section. If the live test still finds noindex, keep going. Check both fields, because Google’s URL Inspection help, checked September 27, 2026, says a page blocked by robots.txt always shows indexing as allowed “because Google can’t see and respect any noindex directives.”

Read the HTML and the headers

Google accepts noindex in two forms. Its noindex documentation, checked September 27, 2026, shows a meta tag, <meta name="robots" content="noindex"> (or name="googlebot" for Google only), and an HTTP header, X-Robots-Tag: noindex. Check both from a terminal, which sends no login cookie:

curl -sIL https://example.com/some-page/ | grep -i "x-robots-tag"
curl -sL https://example.com/some-page/ | grep -io "<meta[^>]*name=[\"']\?\(robots\|googlebot\)[^>]*>"

Then open the page in a private window and search the source for robots. Note every robots tag you find, not just the first. Google’s robots meta tag specification, checked September 27, 2026, says that “in the case of conflicting robots rules, the more restrictive rule applies,” so a single stray noindex wins over an index elsewhere on the page. The same page says none is equivalent to noindex, nofollow, so search for that too.

Also test a second page of the same type and one of a different type, such as a post, a page, and a category archive. Whether the noindex appears on one page, one type, or everywhere narrows the source quickly.

Match the output to the layer that wrote it

Rule out the first row before anything else, because it affects the whole site. The WordPress Reading Settings documentation, checked September 27, 2026, says that since WordPress 5.3 the discourage option generates a noindex,nofollow robots meta tag in the page head, and that “it is up to search engines to honor your request.” Migration and cloning tools copy database settings, so a staging site’s ticked box can travel with it.

If you use WP Visibility, it adds its directives to WordPress’s own robots meta tag rather than printing a second one, and it does not override the discourage setting there: when that box is ticked, every page stays noindex whatever the per-post setting says. A page noindexed by WP Visibility’s own per-post or site-wide settings gets exactly noindex, follow (or noindex, nofollow) in that tag and no canonical link. Its per-post control is Search engine indexing in the Indexing panel of the WP Visibility editor sidebar; the post settings also show a Hide from search engines toggle under Search visibility that sets the same noindex. The site-wide switches for post types, taxonomies, and archives are in the Indexing section of its settings. Internal search results, date archives, and post format archives are noindexed there by default. The wp visibility audit command fails its blog_public check when the discourage box is ticked, which is a fast way to rule the first row in or out; see Run the Site Audit.

Fix it at that layer

Change the setting where the noindex originates. Changing a different layer either does nothing or hides the real cause until the next deploy.

1. WordPress setting. Untick the discourage box on the production site only. If you deploy from staging, add a step to your launch checklist so the next migration does not reintroduce it.
2. SEO plugin, per post. Set the post back to the plugin’s default or to an explicit index value. In WP Visibility, Default inherits the site rules and Index overrides a noindexed post type.
3. SEO plugin, site rules. Untick the post type, taxonomy, or archive that should be indexable. Leave intentional exclusions, such as internal search results, where they are.
4. Theme or second plugin. Remove the hardcoded tag through a child theme, or deactivate the duplicate SEO plugin after migrating its settings.
5. Server or CDN header. Remove the directive from the server configuration or the edge rule, or ask your host to. An SEO plugin cannot remove a header added after WordPress sends the response.

Do not add a robots.txt block while you work. Google’s noindex documentation says that for noindex to be seen at all, the page “must not be blocked by a robots.txt file,” and the same holds when you want Google to notice that the noindex is gone: a blocked page cannot be recrawled. If you find a robots.txt block alongside the noindex, see Fix a robots.txt block.

Retest the public response, then recrawl

1. Purge every cache between the visitor and WordPress: the caching plugin, the host’s server cache, and any CDN.
2. Repeat both curl commands and view the source in a private window. You want no noindex in the header or the HTML.
3. Run Test live URL again and confirm Indexing allowed? now reports that indexing is allowed and Crawl allowed? reports that crawling is allowed.
4. Click Request indexing for the most important pages. Google’s URL Inspection help, checked September 27, 2026, notes a daily limit and says a request does not guarantee indexing.
5. If many URLs were affected, open “URL marked ‘noindex’” in the Page Indexing report and click Validate fix. Google says validation typically takes up to about two weeks and sometimes much longer.

Google’s noindex documentation also says that, depending on a page’s importance, “it may take months for Googlebot to revisit a page.” Record the date you fixed the output so later reports can be read against it.

Before you finish, confirm:

• The fix was made at the layer that produced the noindex, and you wrote down which one.
• Intentional exclusions, such as search results and thank-you pages, are still noindexed.
• No robots.txt rule blocks the pages you just made indexable.
• Caches were purged, and the anonymous response was retested after the purge.
• The launch or deployment checklist now includes the discourage setting.

For how this status fits among the other reasons Google reports, see the indexing triage guide.