How do I check my staging site is not indexed?

`site:staging.example.com` in Google returns pages from that hostname if it is indexed. A result is reliable evidence; no result is not proof of absence.

If the staging host is a verified property in Search Console, URL Inspection gives the authoritative answer per URL.

Check the pattern rather than one page: a staging environment leaks as a whole, so if one page is indexed there are usually many.

Search for a distinctive phrase from your own content in quotes. That finds the staging copy even when the hostname is not what you expected.

Check every non-production hostname you operate, not just the one called staging: preview deployments, demo environments and per-branch URLs are the same exposure under different names.

robots.txt stops a fetch, not an index entry. Google documents that a blocked URL can still be indexed on the strength of links pointing at it.

The result is the worst outcome available: the staging URL appears in results with no description, and you cannot remove it because the crawler cannot read a `noindex` it is not allowed to fetch.

The file is also public and names the paths you consider sensitive, which is an invitation on an environment that should not be public at all.

So a `Disallow: /` on staging is not protection. It is the configuration that produces the hardest version of this problem.

The same reasoning rules out relying on a `nofollow` on the links pointing at staging: it is a hint about one link, not a property of the destination.

HTTP authentication in front of the whole environment. A crawler receives 401 and has nothing to index. This is the only measure that is not advisory.

IP allow-listing, where the environment is only reachable from your own network or VPN. Equally non-advisory.

A `noindex` header on every response, as a second layer for the case where authentication is accidentally removed.

Not linking to it from anywhere public, which is a precaution rather than a control — links leak through shared documents, chat previews and browser sync.

Authentication and a `noindex` header together is the configuration that survives one mistake.

Allow crawling. The `noindex` has to be readable, so any robots.txt block must come off first.

Serve `X-Robots-Tag: noindex` on every response from the staging host. The header form covers non-HTML files too.

Request removal in Search Console for the staging property, which is faster than waiting for a re-crawl.

Once the URLs are gone from the index, put authentication in front and leave it there. Only then is blocking in robots.txt harmless, and by that point it is also unnecessary.

A link from a production page, usually in a template, an environment-aware asset URL, or a hard-coded absolute address someone forgot to make relative.

A sitemap on staging listing staging URLs, submitted or simply discovered.

Canonical tags on staging pointing at staging rather than production, which tells a crawler the staging URL is the real one.

Links shared in public issue trackers, pull request descriptions and chat channels that generate link previews.

Certificate Transparency logs, which publish every hostname a publicly trusted certificate was issued for — including `staging.example.com`.

Predictable naming. A crawler that knows `example.com` can try `staging.example.com` without discovering a link anywhere, and some do.

Running a crawl against the staging hostname shows what an anonymous visitor receives. If it returns 200 and readable HTML, so does a crawler.

VeriFixScan reports `seo.noindex` for the directive on each crawled page and `seo.robots_txt` for the file, which is where the contradictory combination shows up.

A scan that cannot reach the site at all — because authentication refuses it — is the result you want on a staging environment.

It cannot tell you whether a search engine has already indexed the host. That is a `site:` query and Search Console, and neither is something an external scan can answer.