Staging site indexed in Google: getting the copy out and keeping it out

Confirm what is indexed

Search Google for site:staging.example.com. Try the other likely hostnames too: dev., test., stage., beta., your host's temporary domain, and any agency preview domain. Note roughly how many results each returns.

Then check what protection the staging site has now:

curl -sI https://staging.example.com/ | grep -iE "^HTTP|x-robots-tag|www-authenticate"
curl -s https://staging.example.com/ | grep -io '<meta[^>]*name=.robots.[^>]*>'
curl -s https://staging.example.com/robots.txt

A 200 with no noindex anywhere means it is fully open.

Step 1: hide it now with a removal request

1. Add the staging hostname as a property in Search Console and verify it. A URL-prefix property verified by HTML file or meta tag is quickest. If you have a Domain property for example.com, the subdomain is already covered.
2. Open Indexing → Removals → New request.
3. Enter the staging root, choose Remove all URLs with this prefix and submit.

The pages disappear from results quickly, typically within a day. The request is temporary, lasting about six months, so it buys time for the permanent fix; it is not the fix.

Step 2: lock the site

HTTP authentication is the dependable protection. Every request without credentials gets a 401, so nothing can be crawled or indexed, and nobody stumbles on unfinished work.

Apache, in the staging site's .htaccess:

AuthType Basic
AuthName "Staging"
AuthUserFile /path/outside/webroot/.htpasswd
Require valid-user

nginx:

auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd;

Many hosts offer the same as a "password protect" toggle for staging environments. IP allowlisting is an equally good alternative for teams on fixed addresses.

Once the removal request has hidden the pages and authentication is in place, the indexed copies expire for good: Google's later recrawls get a 401 and drop the URLs.

Why the "Discourage search engines" checkbox is not enough here

Settings → Reading → Discourage search engines from indexing this site is the standard setting for a staging copy, and it should be on. But understand what it does. WordPress adds noindex to every page. With Hydrogen SEO active, the plugin also serves Disallow: / in robots.txt while the box is ticked.

For a staging site that was never indexed, that combination keeps it out. For one that is already indexed, the Disallow stops Google recrawling, so it cannot see the new noindex, and the existing listings can linger as indexed, though blocked by robots.txt. That is why the sequence above uses a removal request plus authentication instead of relying on the checkbox.

The checkbox carries a second risk in the other direction: it travels with the database. Pushing staging to production with the box ticked noindexes the live site. Hydrogen SEO's site health score flags this as "Site is hidden from search engines"; check it after every deployment. The symptoms are covered under page set to noindex.

Step 3: check the live site for staging leftovers

A staging copy often gets indexed because production pointed at it. On the live site, look for the staging hostname in:

• canonical tags and og:url; see canonical points to the wrong domain
• the XML sitemap and the Sitemap: line in robots.txt
• internal links, menus and image URLs in content
• hreflang tags and schema markup

curl -s https://example.com/ | grep -c "staging.example.com"

Any count above zero needs a search-replace in the database.

What not to do

• Do not 301 the staging host to production while the staging site is still in use; you will lock yourself out of it. A redirect is appropriate only when retiring the hostname.
• Do not rely on an obscure URL. Unlinked is not undiscoverable.
• Do not allow Googlebot through the authentication "so it can see the noindex". A 401 is already a complete answer.
• Do not copy production's robots.txt and sitemap settings to staging without checking which host they name.

Preventing a repeat

Make protection part of how staging sites are created: authentication switched on before WordPress is installed or cloned, the Discourage setting ticked, outgoing email disabled, and a deployment checklist item to untick Discourage on production and confirm the live site's canonical host. If your host creates staging copies automatically, check whether it applies a password by default.

Confirm the staging site is gone and locked

Repeat the site: search after a few days; it should return nothing. Request the staging homepage without credentials and confirm 401:

curl -s -o /dev/null -w "%{http_code}\n" https://staging.example.com/

In the staging property's Page indexing report, URLs move to "Blocked due to unauthorized request (401)", which is the intended final state. On production, run the free SEO audit on the homepage to confirm it is not set to noindex and that a canonical tag is present.