Establish whether the page should be public
Start with the exact URL and an explicit publication decision. A preview, private document or unapproved landing page should not become crawlable merely because someone wants more traffic. Confirm that the public origin, contact information and factual review are complete before investigating a page intended for search discovery.
For that approved page, record whether a signed-out visitor can access it, its final URL after redirects and its response status. An account-only page, an error response and a public page with an indexing directive are separate conditions. Keep the first failing condition visible rather than describing all of them as an SEO problem.
Read noindex from both places
Google documents noindex in an HTML meta tag or an HTTP response header. Its guidance also says a crawler must be able to access the resource to discover the directive. Check the published response headers and HTML, because a hosting layer can add a header independently of the page template. [1]
Record the actual values in the worksheet. If the page source no longer contains noindex but the response still carries X-Robots-Tag: noindex, the source edit did not remove the effective instruction. Ask the owner of the relevant hosting or deployment setting to inspect it. Avoid changing unrelated pages that intentionally remain excluded.
Understand the robots.txt distinction
Google describes robots.txt as a way to manage crawler requests. It is not a reliable way to keep a web page out of search results, and it is not a privacy control. A blocked URL can still be known through links even when its content is not crawled. [2]
For a page that should remain private, use appropriate access controls rather than treating a crawler preference as protection. For an approved public page, compare the applicable robots.txt rule with its intended crawl state. Do not remove a whole-site restriction until you understand why it exists and which other resources it covers.
Worked example: a preview rule survived the launch
Imagine an invented public guide returning HTTP 200. Its HTML has no noindex tag, but the deployment injects a noindex response header. The robots file also blocks the guide path. The first observation is not proof of eligibility: the header remains, and the crawler cannot inspect it while blocked.
The proposed repair is a scoped publication configuration change for the approved guide, followed by fresh checks of the response and applicable crawl rule. Other previews retain their protections. This simulated example is not a live diagnosis of your site and does not justify deleting every robots rule or removing authentication from staging.
Verify eligibility without promising discovery
Google recommends URL Inspection and indexing reports for checking what its crawler received and diagnosing noindex behavior. Where you control the property, inspect the precise URL after the technical correction and retain the result date. A request for another crawl is not a receipt proving the page entered the index. [1]
Use separate worksheet states for publicly reachable, crawl permitted, no unintended exclusion found and observed indexed. Leave the final state unknown until the relevant report establishes it. A technically eligible page can still remain unindexed, and indexing does not promise rankings or visitors. This research guide covers the configuration distinction; content quality, duplication, canonical selection and broader search performance require their own evidence.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Google Search Central: Block Search indexing with noindex Accessed 2026-09-14
- Google Search Central: Introduction to robots.txt Accessed 2026-09-14
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.
