Staging, test and abandoned installations

Every redesign, every major update, every test of a new feature commonly produces a second copy of a site somewhere — a staging environment, a test installation, an old version left running “just in case.” Once the project it was built for is finished, these copies are routinely forgotten, left running, unpatched, indefinitely. Nobody remembers they exist until something finds them.

Why a forgotten copy is a genuine risk, not merely clutter

A staging or test installation runs the same software as the live site, is frequently built from a full copy of the live database, and is very often given far less attention afterwards than the live site itself — updates stop being applied the moment nobody is actively using it for its original purpose. Automated scanning software makes no distinction between a “real” site and a forgotten test copy; it finds any reachable installation running vulnerable software, and a staging copy is exactly as reachable as the live site unless it was deliberately restricted.

How these accumulate without anyone deciding they should

A redesign project spins up a staging site to work on the new version, the new version launches, and the staging copy is never explicitly decommissioned — it simply continues existing at whatever address it was given. A developer sets up a quick test installation to try a plugin or a feature, the test finishes, and the installation is never removed. An old version of a site remains live at a subdomain after a migration to a new platform, because nobody was specifically tasked with removing it. None of these are deliberate decisions to leave a vulnerability in place; they are simply nobody’s job to clean up.

Why staging environments are often worse-protected than production, the live site

A staging or test copy is frequently excluded from the same monitoring, backup and update schedule applied to the live site, precisely because it is not considered “the real site” — which means it can sit running a long-outdated, vulnerable version of the CMS core, theme or plugins for months or years after the live site has been kept current. It may also carry a full copy of the live database, including customer data, meaning a compromise of the forgotten copy can expose exactly the same information a compromise of the live site would.

What to actually check across your staging environments for security

List every subdomain, staging address and test installation that has ever been set up for the site, going back through the its history if necessary by asking whoever has done past development work. For each one still reachable, confirm whether it is still genuinely needed — and if not, remove it entirely rather than leaving it running unattended. Where a staging environment is genuinely still needed for ongoing work, restrict access to it — a password wall or an IP restriction — rather than leaving it as openly reachable as the live site.

Why “just leave it, nobody will find it” is not a real defence

An unlisted address is not a hidden one. Automated scanning does not rely on a site being publicly linked or advertised; it probes ranges of addresses and subdomains directly, and a staging site at a guessable address is found the same way any other unpatched installation is found, regardless of whether a human was ever meant to stumble across it.

Why developers themselves sometimes lose track of these too

A developer working across many client projects can genuinely forget a test installation they set up months earlier for one specific, since-forgotten purpose — this is not always negligence on a business’s part; it is a natural consequence of how development work actually happens, spread across many sites and many small, temporary environments. Asking a developer directly, in writing, to list every environment ever created for a specific site is a fair and reasonable request, not an accusation.

Protecting a staging environment that is still genuinely needed from unauthorized access

Where ongoing development work requires a staging site to remain available, restricting it behind HTTP basic authentication or an IP allowlist, so only authorised people can even reach it, closes most of the exposure without removing the environment’s usefulness — a simple, standard technical measure most hosts and developers can configure in minutes.

Why search engines finding a staging site is its own, separate problem

Beyond the security exposure, a publicly reachable staging site risks being indexed by search engines, creating duplicate or premature content competing with the live site for the same search terms — an additional reason to restrict access to any staging environment rather than relying on it being simply unlinked from anywhere else.

A simple annual habit that catches this reliably

Asking, once a year as part of a routine review, “does anything exist online related to this site besides the live one,” and genuinely investigating the answer, is the single most reliable way to catch an abandoned environment before something else does.

A final, simple habit

Naming every environment as it is created, in a shared, dated list, is a small discipline that prevents the entire problem this page describes from ever accumulating in the first place.

Where to go from here

The general causes behind most compromises, of which an abandoned installation is one specific and common instance, are set out fully in why small-business websites get compromised. And keeping track of every environment associated with a site, not only the live one, is exactly the kind of task a competent ongoing arrangement should include — see web development services.