How to Check WordPress for a Leftover Noindex Setting

After a WordPress launch or migration, check Settings → Reading and Site Health, then inspect the live homepage and representative URLs for a robots meta directive and an X-Robots-Tag response header. Check robots.txt separately: it controls crawler access, while noindex is an indexing instruction. A URL Inspection live test and the indexed-version report answer different questions.

This sequence is for WordPress site owners and developers verifying that a staging instruction did not carry over to the live site. Clearing WordPress’s setting does not prove that every page is free of noindex. A theme, plugin, server, CDN, or URL-specific configuration may also supply a directive.

Check WordPress’s search-engine visibility setting

In the live WordPress dashboard, open Settings → Reading and check “Discourage search engines from indexing this site.” If it is selected unintentionally, clear it and save the setting. Then open Tools → Site Health and check whether Site Health reports that the site is discouraging search engines. WordPress says this status points to the Reading setting.

WordPress documents that enabling the checkbox generates a robots meta tag containing noindex,nofollow when the theme uses wp_head. WordPress also says this setting does not block normal visitor access. The qualification matters: custom theme code or other site changes can affect what appears in the page output. See WordPress Documentation: Settings Reading Screen and WordPress Documentation: Site Health Screen.

Treat these as WordPress-side checks, not proof about every live URL. A clear setting and a healthy Site Health status do not replace inspection of the pages and their HTTP response headers.

Inspect live pages and response headers

Choose representative URLs. Check the homepage and at least one important URL from each relevant page type, such as a service page, post, or product page. Include any URL reported as having an indexing problem.
Inspect the HTML. Open each live URL and view its page source or rendered output. Look for a robots meta tag containing noindex. Record the URL and the directive you find—or that you found none.
Inspect the response headers. In browser developer tools, use the Network panel to inspect the page request and its response headers. Look for X-Robots-Tag and check whether it contains noindex. This header can apply to non-HTML resources too, according to Google Search Central: Robots Meta Tags and X-Robots-Tag.
Check robots.txt access. Review the robots.txt file served by the exact live host and identify the rules that apply to the URL. Record the response and relevant rules; do not assume that a page visible to a visitor is necessarily accessible to a crawler.

Save the page output and response headers as evidence. If the URL redirects, check the destination users and crawlers reach as well as any relevant earlier response in the redirect path.

Use the result to choose the next check

What you find	What it means	Next action
A robots.txt rule blocks the URL	This is a crawl-access restriction, not a `noindex` directive. Google explains that a blocked URL may still be indexed, and the crawler may not be able to read a `noindex` instruction on that page.	Confirm whether the block is intentional. If it is not, review and correct the applicable robots.txt rule, then check the URL’s live access again.
The URL is crawlable, but its HTML contains `noindex`	The instruction is in the page output. The Reading setting is one possible source, but it is not the only one.	Check the WordPress setting, then investigate theme and plugin configuration or URL-specific output. Recheck the live HTML after any change.
The URL is crawlable, but its response has `X-Robots-Tag: noindex`	The instruction is in the HTTP response headers rather than necessarily in the HTML.	Trace the response to the relevant server, CDN, or other configuration. Recheck the response headers after changing it.
You find both a crawl block and a `noindex` instruction	The block may prevent Google from reading the page-level instruction.	Review whether crawling should be allowed first. Then verify the HTML and headers independently; changing only one does not establish that the other is gone.

Google distinguishes robots.txt crawl rules from robots meta and X-Robots-Tag indexing instructions in Google Crawling Infrastructure: How Google Interprets robots.txt and Google Search Central: Robots Meta Tags and X-Robots-Tag. Keep the checks separate: allowing crawling does not itself remove noindex, and a crawl block can stop Google from seeing an instruction on the page.

Check live access and indexed status separately

In Search Console, use URL Inspection for the exact live URL. Run the live test to check what the inspection tool can access at test time. If the test succeeds, inspect the available raw HTML and HTTP headers for that tested page. Compare them with your own page and header evidence.

Then review the indexed-version information separately. It reflects Google’s most recently indexed version, which may differ from the current live page. A successful live test does not mean the URL is indexed, will be indexed, or will appear in search results; Google says the test does not check every indexing condition. Search Console Help: URL Inspection Tool documents both views and these limitations.

Hypothetical: staging discouragement carried into launch

Hypothetical: A staging WordPress site had the “Discourage search engines from indexing this site” box selected. During launch week, the owner checks the live site’s Reading setting and Site Health, then inspects the homepage, a key landing page, and a representative post. The checks find no unintended noindex in those pages’ HTML or response headers, and the applicable robots.txt rules do not block those URLs.

That evidence supports a narrower conclusion: the checked live URLs are not showing the staging instruction in those places, and the reviewed rules do not block their crawling. It does not establish that every URL is clear or that Google has indexed them. Inspect other page types and URL-specific cases, then use Search Console’s indexed-version report to track Google’s reported status.

Launch-week verification checklist

Record the live WordPress Reading setting and the Site Health status.
For each representative URL, save the live page source or rendered output and note whether it contains a robots meta noindex.
Record the URL’s HTTP response headers and whether X-Robots-Tag contains noindex.
Save the robots.txt response and the applicable rules; record crawl access separately from page directives.
Record the Search Console live-test result and, when available, the tested HTML and headers.
Record the indexed-version report as a separate status, along with the date checked.
After a fix, repeat the relevant live checks and note what changed and where the instruction came from, if identified.
Check the indexed-version report again later. Do not treat a successful live test as proof that Google has recrawled or indexed the URL.

Which representative URL types will you include in your launch-week check: the homepage, product pages, posts, service pages, or another page type?

Sources

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.