Guides · 2026-09-30 · By VSNARY | Emmanuel Orta · 0 views

Staging site leak: how a staging host ends up in live pages

How a managed host's staging hostname gets into production page source, what a leaked staging copy costs, how to find it from outside and how to close it without breaking the workflow.

Managed WordPress hosts give every site a staging copy on a hostname of their own: something.cloudwaysapps.com, something.wpengine.com, something.kinsta.cloud, something.pantheonsite.io. The copy is meant to be private. It stops being private the moment the production page's source references it, because a crawler that reads the production page now has the staging hostname, and a staging hostname that answers 200 is a second copy of the site with no canonical pointing home. This guide is how the reference gets into the page, how to find it from outside, what a leaked staging host does to the production site's standing, and how to close it without breaking the workflow that created it.

How the hostname ends up in production #

Almost always by a search-and-replace that missed. A site is built or restored on the staging host, then pushed to production with a database replace of the staging URL for the live one. Anything the replace did not reach keeps the old host: a serialised option a plugin stored, an image URL inside a page builder's JSON, a hard-coded asset path in a theme file, a CSS url() in a saved stylesheet. The page renders correctly because the staging host serves the asset, so nobody notices. The scanner notices because it reads the source rather than the render: it searches the first 200 KB of the homepage for an absolute URL on one of the four staging domains and reports STAGING_LEAK (0.1% of scans) with the host it found.

What the leak costs #

Three things, in order of how often they happen. First, the staging copy is discoverable. Any crawler that follows the reference reaches a host that usually answers 200 with a full copy of the site, and unless that host sends noindex or requires authentication, it is a duplicate of every page with a different hostname. Second, the production page depends on it: an image or script loaded from the staging host breaks the day the host is deleted or the staging copy is refreshed. Third, and the one that reaches the business, a staging copy is often out of date, and an engine that reads a price, a phone number or an address from the staging host has read last month's.

Finding it from outside #

Fetch the production homepage and search the response body, not the browser's rendered DOM, for the four staging domains. Then fetch a few deep pages the same way; the homepage is where the scanner looks, but a page-builder template used on inner pages can carry the reference where the homepage does not. If a host is found, fetch it directly and read three things: the status, whether an X-Robots-Tag: noindex or a meta robots tag is present, and whether it demands authentication. A staging host that answers 200 with no noindex and no login is the case to close first.

Closing it #

Fix the reference and fix the host, in that order. For the reference, run a serialisation-aware search-and-replace across the database for the staging hostname, then grep the theme directory, then re-read the rendered source to confirm nothing remains. For the host, most managed platforms offer a password or basic-auth toggle on staging environments; turn it on. If the platform does not, send X-Robots-Tag: noindex, nofollow from the staging host's server configuration, which a crawler honours without reading the page, and disallow everything in the staging host's own robots.txt as a second layer, remembering that robots.txt alone does not remove a URL that is already linked.

Reading the finding #

The report names the staging host it found in the source and nothing more, because that is all the homepage proves. It does not fetch the staging host, does not assert that the host is indexable, and does not count how many references there are; one is enough to make the host discoverable. Treat the finding as a pointer: the reference is the symptom, the host's exposure is the risk, and the two are fixed separately. A site that has moved hosts recently and kept the old platform's staging copy alive is the common case, and the old platform's host is the one to check first, since nobody is logging in to it any more.

The related case: your own hostname, twice #

A staging leak is a foreign host serving your site. The nearer relative is your own host serving it twice: www and the bare domain both answering 200 with the same page and neither redirecting to the other. The scanner reports that as HOST_DUPLICATE_200 (3.3% of scans) when the www host stays on www and returns a page within 15 percent of the apex's size, and it is covered in full in the canonical URL guide, with the case where it was found on a site whose canonical tag was correct in its own post. The two findings share a fix philosophy: one host answers, every other host redirects to it.

Preventing the next one #

Make the search-and-replace part of the push, not a step someone remembers, and make it serialisation-aware. Keep staging behind authentication permanently rather than toggling it. And after every push, run the outside check above: it takes a minute, and a scan on crawlcheck.io runs the homepage half of it on every report. The share of scans carrying each finding is on the dataset page.

Questions this post answers

What is a staging leak?

A production page whose source references the site's staging hostname on a managed host such as cloudwaysapps.com, wpengine.com, kinsta.cloud or pantheonsite.io. A crawler that reads the page learns the staging host, which is usually a full, indexable copy of the site.

How does the staging hostname get into a live page?

A search-and-replace that missed during the push to production: a serialised plugin option, page-builder JSON with escaped slashes, a theme file, saved custom CSS or an image srcset. The page renders because the staging host still serves the asset.

Is robots.txt on the staging host enough?

No. robots.txt stops crawling, not indexing of a URL that is already linked. Put the staging host behind authentication, or send X-Robots-Tag: noindex from its server configuration, and use robots.txt only as a second layer.

What does the scanner actually search?

The first 200 KB of the homepage source for an absolute URL on one of the four staging domains. It reads the bytes the server sent, not the rendered page, so a reference that renders fine is still found.

What is the difference between STAGING_LEAK and HOST_DUPLICATE_200?

A staging leak is a foreign host serving your site. HOST_DUPLICATE_200 is your own www and bare hostnames both answering 200 with the same page and neither redirecting. Both have the same fix philosophy: one host answers, the rest redirect.

Why is an out-of-date staging copy a business problem?

An engine that reads a price, phone number or address from the staging host has read an old version, and a duplicate with a different hostname competes with the real page for the same query.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All guides · The dataset · How the dataset works