Taking a website out of staging

A staging site is a working copy of a website on a separate address, used to build and review before anything reaches the public. Moving from staging to live is a step, and it fails in two opposite directions.

The live site is still hidden. The instruction that kept the staging copy out of search results was carried across to production. The site looks perfect to every visitor and does not appear in search results at all. This is the most common cause of “our new website is not on Google” in the first weeks after a launch.

The staging site is still public. The copy was never hidden, or the protection was removed during testing and not restored. It gets discovered, indexed, and competes with the real site for the business’s own name.

Both are invisible from the front end of either site, which is why they persist.

The two mechanisms and what each does

Mechanism	Hides from search	Hides from people	Fails how
Noindex instruction	Yes	No	Carried into production, or removed too early
Robots.txt block	Prevents fetching, not results	No	Also blocks the noindex from being read
Password or authentication	Yes	Yes	Removed for a client review and not restored
IP restriction	Yes	Yes	Locks out the client, so it gets disabled

The only mechanism that is reliable in both directions is authentication. A staging site behind a password cannot be indexed because it cannot be fetched, and cannot be read by anyone who should not read it.

The combination that specifically does not work is a robots.txt block plus a noindex instruction. Blocking the address prevents a crawler from fetching the page, and it therefore never reads the noindex. That interaction is covered on robots.txt and noindex.

Why the staging copy is a business problem, not just a technical one

Three consequences, in increasing order of seriousness.

Duplication. Two complete copies of a site at two addresses. A search engine picks one, and it may pick the wrong one.

Wrong content in public. Staging carries drafts: unapproved prices, placeholder copy, services that were being considered and rejected. Any of it may be indexed and cached, and a cached page persists after the source is removed.

Real data in an unprotected place. Staging environments are often copies of production databases, which means real customer records on a server with weaker protections and no monitoring. Where that data is personal information, the obligations under the Privacy Act attach to it in the staging copy exactly as they do in production. That is a privacy question rather than a search question, and it is the reason a password on staging is not a nicety.

Removing a staging site that has been indexed

Prevention is a password. Removal, once it has happened, is a sequence and it is slower.

1. Put authentication in front of the staging site immediately, so nothing further is fetched.
2. Verify the staging domain in a search console and request removal of the addresses.
3. Where the staging copy is going to remain reachable, redirect it to the production equivalent.
4. Confirm over the following weeks that the addresses have dropped out.

Step 1 first, always. Requesting removal of a site that is still serving pages is a repair that keeps getting undone.

Where the staging environment copies of a production site come from

A staging site is not always something somebody set up deliberately, which is part of why they are forgotten.

Hosting control panels frequently offer a one-click copy of a live site for testing, and each click creates a complete public copy at a new address. A migration between hosts leaves the old installation running until somebody removes it. A developer working locally may push a copy to a subdomain for a client to review and never take it down.

The result is that a business can own three or four complete copies of its website without anyone having decided to. Asking how many exist, and where, is a reasonable question to put to whoever maintains the site.

The launch checklist entries

Four separate lines, each with an owner, because they fail independently.

• The production site carries no indexing instruction inherited from staging.
• The production robots.txt is the production one, not the staging one.
• Staging is behind authentication and stays there.
• Canonical addresses in production point at production, not at the staging domain.

The fourth is the one most often missed after the first three are handled, and it produces a site that quietly declares another domain to be the real one. That mechanism is on canonical addresses.

How to check both the staging site and the live production site in five minutes

For the live site: search for a distinctive sentence from your home page, in quotes. If nothing comes back a fortnight after launch, check for an indexing instruction before assuming anything else.

For the staging copy: search for your business name plus a word that would only appear on a development address, and separately try the addresses your supplier used during the build. If a copy answers without asking for a password, that is the finding.

Whose responsibility this is

It belongs to whoever performs the launch, and it belongs in the handover documentation, because the person who set staging up is often not the person who maintains the site a year later. Where staging remains in use for ongoing changes, it becomes a standing item rather than a one-off, which is part of what an ongoing arrangement covers — what website maintenance actually is sets out where that boundary usually sits.

What to do next

Ask your supplier for the address of the staging site and try it yourself. If it loads without a password, that is a conversation to have today rather than at the next launch. The rest of the build-side obligations are on what a new website owes search engines, and the technical scope generally is on development as an ongoing engagement.