Ghost Domains and Shared Logins: A Preview Environment Health Check

Most web teams can tell you exactly how many production sites they run. Ask about preview environments and the room goes quiet. There's the staging site the agency set up, the branch previews your host generates automatically, the old subdomain that still resolves, the one your former developer kept for testing the checkout. None of them are on a diagram. Several of them are probably still awake.

That's not a scandal, it's just how things drift. Previews get spun up in a hurry because someone needed to show a page to a director before lunch, and nobody thinks of a temporary URL as an asset that needs managing. But a preview environment is a website. It has a login, a database, a set of integrations and, quite often, a copy of your real content. Treat it like one.

Here's how to run the audit without turning it into a three-week project.

Start with a list, not a feeling

You can't audit what you haven't written down. Before you touch a single setting, build an inventory. Some good places to dig:

• Your DNS provider. Every A record, CNAME and stray subdomain. Sort by last modified and raise an eyebrow at anything older than your current website.
• Your hosting accounts. Cloud platforms, managed WordPress hosts, Netlify, Vercel, Azure, AWS — anywhere a preview URL can be generated without a ticket.
• Browser bookmarks and the team's saved passwords in whatever password manager you use. People bookmark staging sites and then forget they exist.
• Invoices. If you're paying for a server, there's something on it.
• Your CMS itself. Many platforms list environments, deployment targets or preview configurations in their settings. That list is a confession.

Expect to find more than you guessed. The usual suspects are a staging. subdomain, a platform-generated URL with a random string in it, and an agency-hosted copy that was never formally handed over.

Three questions for every environment

Once the list exists, each entry gets the same three questions. Who owns it? What data is in it? Who can get to it?

If the answer to the first one is "the agency, I think" or "it was Dave's", you've found your problem. Unowned environments are where the odd stuff happens, because nobody feels responsible for noticing it.

Authentication: the padlock and the spare key

Preview environments have a habit of missing the security upgrades that production got years ago. Single sign-on rolled out across the main site, but the staging box still uses a shared username and password that lives in a spreadsheet. Multi-factor authentication is mandatory for staff, except for the service account that runs the preview build.

Things worth checking, environment by environment:

• Is access through your identity provider, or through a local login that doesn't know when someone leaves?
• Are the credentials shared? If four people use the same password, you have no audit trail and no way to revoke one person's access.
• Is there HTTP basic auth, and is the password still the one from the original setup?
• Is there an IP allowlist, and does it still match the offices and VPN ranges you actually use?
• Are former staff, contractors and agencies still on the list?

The NCSC's guidance on access control is dull and correct: least privilege, individual accounts, and a clear process for removing people. Previews are exactly where that discipline slips.

The accidental audience

A preview environment that's reachable from the internet is one search engine crawl away from being public. Usually it isn't indexed, because nobody links to it. Usually isn't the same as never.

Check for noindex directives in the page headers, an X-Robots-Tag response header, and a [robots.txt](https://en.wikipedia.org/wiki/Robots.txt) that disallows everything. But don't treat robots.txt as security — it's a request, not a lock. If the site must stay private, put authentication in front of it.

Then do the obvious thing: search for your organisation's name alongside the words staging, test, dev and preview, and see what turns up in Google and Bing. Search for distinctive strings from your own content too. It's a five-minute job that occasionally produces a very long afternoon.

Production data doesn't travel light

Many staging sites are refreshed from the live database, which means they hold real names, real email addresses, sometimes real enquiries and, in the wrong setup, special category data. Under UK GDPR, copying personal data into a test environment needs a lawful basis and a purpose — "so the developer can see the page with content in it" is a purpose, but it comes with obligations.

The realistic options are anonymising the copy, using a subset of records, or generating synthetic content. Whichever you pick, write down what happens to the copy afterwards, because "we'll wipe it once testing is done" is the most frequently broken promise in web operations. Also check whether preview environments appear in your backup schedule. A deleted database has a funny way of living on in a snapshot.

Integrations that don't know they're in a rehearsal

This is the section that causes the sharpest intake of breath. Preview sites inherit configuration from production and keep talking to the outside world.

• Payment providers in live mode, taking real card payments on a test site.
• Email and SMS services sending genuine messages to genuine customers.
• CRM webhooks creating duplicate leads or overwriting records.
• Analytics tracking preview traffic and skewing your reporting.
• Address lookups, translation APIs and AI services quietly billing per request.

Go through the configuration and confirm that every third-party service is using a test key, a sandbox account or is switched off entirely. Then add a note to your deployment checklist so the next person doesn't have to rediscover it.

Give every environment a kill date

An environment without an end date is a permanent environment. You just haven't admitted it yet.

For each entry on your list, assign a named owner and a review date. If it's genuinely needed, keep it, and record why. If it isn't, decommission it properly: remove the DNS record, revoke the certificate, close the hosting account, delete the credentials, retire the repository and note it in your asset register. Half-finished decommissioning is how ghost domains are born.

A sensible rhythm is a quick pass each quarter, with a fuller review before major projects or platform changes. Doing it in November, ahead of the Christmas change freeze, is a good habit — you'll thank yourself in January.

Keep the ledger somewhere visible

A spreadsheet is fine. Columns: environment name, URL, host, owner, authentication method, data classification, integrations, last reviewed, planned retirement. Share it with the people who deploy, not just the people who plan.

The point isn't tidiness for its own sake. It's that a preview environment is a small, real website with real credentials and sometimes real data. Knowing how many you have, and who's looking after them, is the difference between a managed estate and a collection of surprises.