Key takeaways
- Password protection is the safest way to keep a staging site out of Google.
- Robots.txt alone does not keep pages out of the index and hides any noindex tag.
- If staging gets indexed: protect it, then use the Removals tool for a fast temporary hide.
- On launch day, remove every block and check the live site with URL Inspection.
Staging site SEO is a small part of every web project and a common source of emergencies. This guide is the short version we use on client builds delivered through white label SEO and web development. The full process for a new design is in the website redesign SEO checklist, and for a domain change in the domain migration SEO checklist. This page only covers the staging environment and the moment it goes live.
Should a staging site be indexed by Google?
No. A staging or development site is a copy for testing, so it should never appear in search results. If indexed, it can show unfinished content to customers, compete with the live site for the same searches and leak pages or prices before launch. Every staging environment should be blocked from day one, not just before launch.
What is the best way to block a staging site from Google?
Password protection, usually HTTP authentication on the server or hosting panel. Google's robots.txt guide says that to keep a page out of Google you should block indexing with noindex or password-protect the page. A password also keeps out people, other crawlers and AI bots, and it cannot be copied to production by accident with the database.
| Method | Keeps it out of Google? | Main risk |
|---|---|---|
| Password (HTTP auth) | Yes, Google cannot fetch the pages | Forgetting to share access with testers |
| noindex tag or header | Yes, once Google crawls and sees it | Being copied to the live site at launch |
| robots.txt Disallow | No, URLs can still be indexed from links | Hides any noindex; often copied to production |
| IP allowlist | Yes, crawlers cannot reach it | Remote team members on changing IPs |
Google's introduction to robots.txt states plainly that robots.txt "is not a mechanism for keeping a web page out of Google." Its noindex documentation adds that for noindex to work, the page must not be blocked by robots.txt, because the crawler would never see the rule. If you use noindex, prefer the X-Robots-Tag HTTP header set at server level, so it lives in the staging server configuration rather than in the CMS database that gets migrated.
Is robots.txt enough to hide a staging site?
No. Robots.txt asks crawlers not to fetch pages, but a blocked URL can still be indexed if other pages link to it, and it may appear without a description. Worse, a Disallow rule stops Google from seeing any noindex tag on the same pages. Use robots.txt only for crawl control on live sites, never as the staging protection.
What do you do if a staging site got indexed?
First block access with a password, so the pages stop serving content. Then verify the staging host in Search Console and request a temporary removal with the Removals tool to hide the URLs quickly. A removal lasts about six months, so the password or noindex must stay in place to make it permanent. Do not rely on robots.txt.
Google's Removals tool documentation says a successful request lasts only about six months and that you must also delete the content, password-protect it or add noindex, and it warns against using robots.txt as the blocking method. Steps in order:
- Add HTTP authentication to the whole staging host.
- Verify the staging domain or subdomain as a Search Console property.
- Submit a temporary removal for the URL prefix of the staging site.
- Check that live pages are the ones showing for the client's brand searches.
- Find out how Google discovered staging (a link, a sitemap, a shared URL) and close that leak.
What should you check on launch day?
Remove every block that protected staging and confirm the live site is open to crawling: no site-wide noindex, no Disallow for the whole site, no password, correct canonical tags pointing to the live domain, and a sitemap with live URLs. Then test key pages with URL Inspection in Search Console and watch the Page indexing report for the next weeks.
Launch-day checklist we hand to the developer:
- robots.txt on the live domain allows crawling and lists the live sitemap.
- No noindex meta tag or X-Robots-Tag header on live pages (check the HTTP response, not just the HTML).
- CMS setting that discourages search engines is turned off, for example in WordPress.
- Canonical tags, hreflang and sitemap URLs use the live domain, not the staging host.
- Internal links and images do not point to the staging domain.
- Staging stays password protected after launch, since it will be reused.
- Live URL Inspection run on the home page and two key templates.
Use URL Inspection to run a live test and confirm the page is indexable, then follow the Page indexing report for pages excluded by noindex in the weeks after launch. WordPress builds have their own settings to check in our WordPress SEO checklist.
Common staging disasters on client sites
Noindex goes live
The staging noindex is migrated with the database and the new site drops out of results.
Duplicate site
An open staging subdomain is indexed and competes with the live pages.
Staging links
Live pages keep links, images or canonicals to the staging host.
Leaked launch
Unreleased products, prices or pages appear in search before the client announces them.
Every one of these has the same prevention: password on staging, server-level headers instead of CMS settings, and a written launch checklist signed off by both the developer and the SEO. In our technical work on large fleets of sites, where templates were rolled out to hundreds of dealership websites, the launch checklist mattered more than any single fix. Need a launch review under your brand? book a 30-minute call, or see our white label technical SEO.
Frequently asked questions
Should a staging site use a subdomain or a separate domain?
Either works if it is password protected. A separate domain reduces the chance of cookies or links mixing with the live site.
Do AI crawlers respect staging blocks?
A password blocks every crawler. Robots.txt rules depend on each crawler choosing to follow them.
Can we leave staging open for a client preview?
Share a password instead. A preview link without protection can be found and indexed.
Should the staging site have a sitemap?
It can for testing, but never submit it in Search Console and never reference it from the live robots.txt.
How fast does Google pick up a removed noindex?
Only after it recrawls the pages. Request indexing for key URLs and give it time.