Staging or preview site indexed by Google: remove it and prevent it
To remove an indexed staging site, password-protect it or add noindex, use the Removals tool for speed, and never block it in robots.txt first.
LLaunchScaler·Published ·7 min read
To remove a staging or preview site from Google, make every staging page either require a password or send a noindex, then file a Search Console Removals request if you need it gone within a day. Do not block the staging site in robots.txt while it is still indexed: that stops Google recrawling the pages, so it never sees the noindex or the password prompt that would remove them.
The permanent fix is access control. A staging site nobody can load without logging in cannot be indexed, and it has no setting that can leak into production.
Why did Google index my staging site?
Google indexed it because it could reach it and nothing told it not to. Staging hostnames get discovered from links in pull requests, shared screenshots, analytics referrers, sitemaps generated with the wrong base URL, or production canonicals that name the staging host. If the site answers 200 without a login or a noindex, it is indexable like any other site.
Check how much is indexed by searching site:staging.yoursite.com (or site:your-project.vercel.app) in Google. Then look for how Google found it:
Production pages whose <link rel="canonical">, og:url or sitemap entries use the staging hostname because a build-time site URL variable held the staging value.
A staging domain assigned on a platform that only protects its generated preview URLs.
A staging site linked from a public issue tracker, changelog, docs page or status page.
An old staging copy on a forgotten subdomain that nobody switched off.
Vercel is a common case. It "adds an X-Robots-Tag: noindex HTTP response header to every Preview Deployment automatically," but its documentation also says it "omits X-Robots-Tag: noindex when a custom domain is assigned to a non-production branch," on the assumption that such a domain is an intentional staging site. staging.yoursite.com pointed at a preview branch is therefore indexable unless you add your own protection. Confirm it with and look for in the output.
Questions, answered
What people ask about this
01
How do I remove a staging site from Google?
Put the staging site behind a password or IP allowlist, or send a noindex on every page, so Google drops it on its next crawl. For speed, verify the staging hostname in Search Console and file a Removals request, which hides URLs within about a day for roughly six months.
Why does blocking staging in robots.txt make it worse?
Blocking an indexed staging site in robots.txt makes it worse because Google stops fetching the pages and so never learns they should be removed. Google's documentation is explicit: if a page is blocked by robots.txt, "the crawler will never see the noindex rule," and a blocked page "can still be indexed if linked to from other sites."
The result is a staging site that stays in results as bare URLs without a description, and nothing you add to the pages can reach Google. Search Console reports these as "Indexed, though blocked by robots.txt"; the indexed though blocked by robots.txt guide explains the status.
robots.txt is for managing crawl load, not for keeping pages out of Google. Google's removal guidance says it directly: "Don't use robots.txt as a way to block your page." Add a Disallow rule only after the staging URLs have dropped out of the index, if at all.
How do you remove an indexed staging site from Google?
Remove it with a method Google can see on its next crawl (a password, a 404 or 410, or a noindex), and add a Removals request if you need the URLs hidden quickly. The Removals request is temporary; the method on the pages is what keeps them out.
Method
What Google sees
Speed
Lasts
Password or login on staging
401 or a login page
On each page's next crawl
Permanently, while protection stays on
IP allowlist
403 to Googlebot
On each page's next crawl
Permanently
X-Robots-Tag: noindex on every staging response
200 with a noindex header
On each page's next crawl
Permanently, while the header stays
Delete the staging site
404 or 410
On each page's next crawl
Permanently
Search Console Removals request
Nothing new; Google hides the URLs
Within about a day
About six months
Google's status code documentation explains why protection works: for 4xx responses other than 429, "the indexing pipeline removes the URL from the index if it was previously indexed." A 401 from a password prompt is a 4xx.
The difference between a 401 and a login page matters. If your app redirects signed-out visitors to its own /login page and that page answers 200, every staging URL becomes a redirect to one indexable login page, which can itself show up in results. HTTP basic auth or platform-level protection answers with a 401 on the original URL, which is the signal you want.
Follow these steps in order:
Turn on access control for the staging hostname. On Vercel, Deployment Protection with Standard Protection "protects all domains except production domains," using Vercel Authentication or Password Protection (on Pro, $20 per month per protected project, per Vercel's pricing table). On other hosts, use HTTP basic auth or your platform's access rules.
If you cannot protect it, send X-Robots-Tag: noindex on every staging response, from the host config rather than the app, so it covers files and API routes too.
Remove any Disallow rule for the staging host from its robots.txt so Google can recrawl and see the change.
Verify the staging hostname as a URL-prefix property in Search Console. Google requires that "the URL must be in a Search Console property that you own."
In Removals, create a request with "Remove all URLs with this prefix" for the staging root. Google says this hides URLs "within a day" and that "a successful request lasts only about six months."
Check site:staging.yoursite.com weekly until it returns nothing.
What if the staging copy ranks instead of your production site?
When staging and production serve the same content, Google treats them as duplicates and picks one URL as canonical. If it picks the staging URL, your production page drops out of results in its favour. Removing staging with a 401 or noindex hands the choice back to production on the next crawls.
Confirm which URL Google chose before and after the fix. In Search Console, inspect a production URL in URL Inspection and compare the User-declared canonical with the Google-selected canonical. If the Google-selected canonical is a staging URL, the fix above is urgent, and every production signal should name production: the canonical tag, the sitemap, internal links and redirects. Google's canonical documentation lists redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one, so fix the tags and redirects first.
Once staging returns 401 or noindex, request indexing for your most important production URLs so Google recrawls them sooner. The Google-selected canonical can only change after Google recrawls a page, so pages it has not revisited will still show the old choice.
How do you stop staging being indexed again?
Keep staging private by default, keep its settings out of production, and make sure production never points at it. Most repeat incidents come from a new staging domain, a new project, or a build variable that changed, so the controls belong in the platform and the pipeline rather than in someone's memory.
Protect every non-production hostname with a login. Treat noindex as a second layer, not the only one.
Set the site URL used for canonicals, sitemaps and og:url from the production domain explicitly, never from a variable that defaults to the current deployment's URL.
Run a post-deploy check on production that fails if a canonical or sitemap entry contains the staging hostname: curl -s https://yoursite.com/sitemap.xml | grep -c staging.
Never link staging from anything public, including issue trackers on public repositories and docs.
When you retire a staging subdomain, delete its DNS record or make it return 410.
Should staging pages have canonical tags pointing at production?
Only when the staging page really is the same page as the production URL it names. A canonical tells Google which URL to index; Google calls it "a strong signal that the specified URL should become canonical." Pointing staging canonicals at production is a weak safety net, not protection, and it goes wrong when staging holds unreleased content.
If a staging page carries new pricing, a draft launch page or copy that is not live yet, a canonical to the production URL declares two different pages to be duplicates. Google's documentation also warns against sending mixed signals: "Don't specify different URLs as canonical for the same page using different canonicalization techniques." Protected staging does not need canonicals for search at all, because Google cannot load it.
The more damaging mistake runs the other way: production canonicals that name staging URLs. That asks Google to prefer the staging copy over your real pages. It usually happens in generated apps and templates that read the site URL from the deployment environment; SEO for apps built with v0 covers setting metadataBase so a generated Next.js app builds its canonicals from the production domain. The mirror-image incident, where staging settings reach production, is in noindex shipped to production.
Catch a staging leak on production before Google does
The staging side is fixed by access control. The production side needs checking on every change: a canonical pointing at a different host, a noindex that crossed over from staging, a sitemap full of the wrong URLs. LaunchScaler Watch re-scans your production site every two weeks for $29/mo, including the scan's canonical and noindex checks, emails a diff showing which checks moved and the evidence behind each, runs uptime checks on your health endpoint, and alerts you when a check drops below the bar. Start watching.
Not while it is indexed. A robots.txt block stops Google crawling the pages, so it never sees the noindex or the password prompt that would remove them, and blocked URLs can stay in results without a description.
03
Are Vercel preview deployments indexed by Google?
Not by default. Vercel adds an X-Robots-Tag: noindex header to every preview deployment, but it omits that header when a custom domain is assigned to a non-production branch, so a staging domain on Vercel needs its own protection.
04
Does a noindex on staging hurt my production site?
No, a noindex only applies to the pages that send it. The risk is the reverse: staging settings such as a noindex or a staging canonical URL being copied into production during a deploy.
05
How long does the Search Console Removals tool last?
Google says a successful request lasts only about six months. After that the URLs can appear again unless the pages return 404 or 410, are password-protected or carry a noindex.
Eight website change monitoring tools, from LaunchScaler Watch to Visualping and Distill.io, judged on whether they catch the changes that cost rankings.
