Staging site indexed by Google: what to do

One link is enough to get a staging site indexed

A staging site (also called preproduction, test or dev) is a copy of the site where changes are prepared before they go live. It often lives on a subdomain such as staging.example.com, and it is sometimes left open to everyone so the client or the team can look at it without a login.

Google doesn't need to be told about it. It finds URLs through links on pages it already knows, and through sitemaps. One link to the copy is enough: published by mistake on the live site, left in a public ticket, shared on a page Google reads. If the copy carries over the live site's robots.txt, which usually allows the whole site, nothing stops Google once it gets there.

Living on a subdomain doesn't protect it: to Google, it is a public address like any other.

Two sites with the same content, and Google keeps one

A staging site repeats the live site's text, titles and images. To Google these are duplicate pages: it groups them and keeps one, the one it considers most representative. It decides from its own signals, and on some pages the copy can win.

Our own site ran into a version of this, with no staging site involved: a copy of the home page served at the root was indexed instead of the two language home pages, even though no internal link pointed to it. The guide on a website that isn't showing on Google tells that story.

A copy can also show what isn't ready: prices not yet announced, placeholder text, test pages, an offer still in the works. It sometimes runs with development settings, which reveal more and protect less than the live site's.

Password, noindex or robots.txt: which one removes the copy

Google describes three ways to remove a page permanently from its results: delete it so the server answers 404 or 410, block access to it, for example with a password, or mark it noindex. Its Removals tool in Search Console only hides a URL for about six months: it buys time, it doesn't replace any of the three.

A disallow rule in robots.txt, often recommended for staging, isn't one of them. It stops Google from reading the pages, not from keeping them: a URL Google already knows can stay in results, without a description. And a noindex rule only works if the page isn't blocked by robots.txt. The guide on blocking crawling versus deindexing covers that trap.

A password is the protection that holds. Required by the server, it makes every page answer 401, a response Google lists among the reasons a page is not indexed, and the copy stays closed to everyone who shouldn't see it, crawlers included. A noindex rule takes the copy out of results but leaves it open to anyone who has the URL.

Close the copy, then list all the others

A staging site is often run by the agency, freelancer or team building the site. Most of what follows are requests to make of them, and decisions that are yours.

1. Have the copy closed with a password the server asks for, on every page. Google eventually drops it from results, and nobody can open it anymore without being allowed to.
2. In the meantime, have its URLs hidden with the Removals tool in Search Console. It only works within a Search Console property you own: set up for the whole domain, that property also covers staging subdomains. The hiding lasts about six months, which gives the password time to take effect.
3. Ask for a list of every copy of the site: staging, testing, demo, old version. Each one gets closed the same way.
4. Have links to the copy removed, both on the live site and in documents you publish.
5. For your next site, write into the order that staging is closed from the day it is created, and check it at handover like everything else.

Putting a password on a staging site is usually a setting at the host or in the server configuration, without touching the site. The job grows when the copy has been out in the open for a long time: outside links point to it, pages on the live site link to it, or the two sites have drifted apart and nobody is sure which one is current. You then have to find what leads to the copy, redirect to the live site what should go there, and decide what becomes of the staging site itself.

When the copy was opened by the agency or freelancer who built the site, closing it is part of a clean handover. The guide on checking a website an agency delivered covers what the audit reports on a site that has just been handed over.

Staging, test, dev: the copies searched for, and those set aside

The audit looks for copies where teams usually put them: six subdomain names commonly given to staging, such as staging, test or dev, on the site's domain. For each one, a page that answers isn't enough to report it.

• The response code. A subdomain that doesn't exist, or that asks for a password, is not reported: a protected staging site is a well-kept one.
• The weight of the page served, compared with the live home page. A much lighter page is a holding page or a login screen, not a copy, and it is set aside. This check exists because our rule once wrongly reported a page of a few hundred bytes that only said "DEV".
• The content, judged by a person: a copy of the site, or a separate site with a reason to live under that name (a demo, a blog, another application)? Only a copy is reported.
• The closures already in place: a noindex rule, or a robots.txt that disallows everything. The audit checks for them before concluding that a copy can be indexed.

The finding belongs to SEO, but it also concerns security: an open staging site exposes an environment that isn't set up like production. When the copy shows sensitive data or features, the report says so in its summary.

The line between staging and production can also be crossed the other way. Neither of the two published samples has a public staging site. But the report on an online store lists, among the third-party services on its pages, a resource served from the staging subdomain of a buy-now-pay-later partner, loaded on the pages of the live site. The report puts it among the points to address: the live site loads a resource from a test environment that belongs to another company.

The audit only finds copies placed under these usual names, which is why the list you ask your provider for still matters. In our audits, a public, indexable copy of the live site remains a one-off.