Staging site SEO: keep the dev site out, let the live site in.

Two staging mistakes cost agencies the most: the staging site gets indexed and competes with the live one, or the block from staging travels to production on launch day. Both are easy to prevent with one rule and one checklist.

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.

MethodKeeps it out of Google?Main risk
Password (HTTP auth)Yes, Google cannot fetch the pagesForgetting to share access with testers
noindex tag or headerYes, once Google crawls and sees itBeing copied to the live site at launch
robots.txt DisallowNo, URLs can still be indexed from linksHides any noindex; often copied to production
IP allowlistYes, crawlers cannot reach itRemote 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.

Juan José Giraldo, senior white label SEO specialist

About the author

Juan José Giraldo is a senior SEO specialist with 5+ years of experience. He works on technical and local SEO for 600+ US car dealerships and supervises the SEO of 18 US e-commerce stores. He runs White Label SEO LATAM from Medellín, Colombia, and delivers white label SEO for agencies in the US, UK, Canada and Australia. Read more · LinkedIn.

Sources

  1. Google Search Central, Introduction to robots.txt
  2. Google Search Central, Block Search indexing with noindex
  3. Search Console Help, Removals and SafeSearch reports tool
  4. Search Console Help, URL Inspection tool
  5. Search Console Help, Page indexing report

Ready to test a pilot client?

Book a 30-minute call. You get an honest read on fit, scope and price, with no obligation.