Staging a change without touching the live site

Testing on the live site is the most expensive habit on a hosting network, because a mistake is multiplied by however many sites you then repeat it on. A staging copy costs a few minutes to make and turns a risky change into a boring one.

What staging is for

• A platform or plugin update you are not certain about.
• A theme change that touches templates.
• A PHP version move on a site with old code.
• Anything you intend to roll out across many sites, tested once before it becomes thirty problems.

That last use is the one that pays for itself. Your staging site is not really protecting one site; it is protecting the pattern you are about to apply everywhere.

Keep it out of search results

The one genuine risk of staging is a duplicate of your site being indexed. Two things prevent it, and use both rather than choosing:

1. Block crawling at the server level, with password protection on the staging location. This is stronger than a robots directive because it does not depend on anyone honouring it.
2. Set the copy to discourage indexing in the application's own settings, as a second layer.

Do not rely on the staging URL being obscure. Certificate transparency logs make new hostnames public, so an unlisted subdomain is not private.

Where to put it

Options, roughly in order of preference:

• A subdomain on the same account. Simple, and it shares the account's PHP version, which is often exactly what you are testing.
• A separate account. Better when you are testing something account level, such as a different PHP version or a different limit.
• Never on a different site's account. It borrows that site's resources and its ceiling.

Remember that a staging copy consumes disk, inodes and backup weight on whatever account it lives on, which counts toward the ceilings described in Platform and Limits. Several forgotten staging copies are a common cause of an account quietly running out of room.

The realism problem

A staging copy is useful in proportion to how much it resembles production. Three things commonly differ and each hides a class of bug:

• Content volume. A copy with fifty posts does not reveal what breaks at fifty thousand.
• Caching. If staging has caching off and production has it on, you are testing two different systems.
• Integrations. Payment, mail and third party services usually point at test endpoints or nothing at all.

Be explicit about which of these differ, so that a clean test is not mistaken for a guarantee.

Going live

Two routes, and the second is safer than it sounds:

1. Push the change back. Apply the same change to production having proven it. Good for configuration and code, poor for anything involving content, since production has moved on.
2. Promote the copy. Make staging the live site. Requires that no content was written to production during testing, which is why testing windows should be short.

Either way, take a backup of production immediately before, not the night before.

Then delete it

Old staging copies are stale code with no maintenance, sitting on your account, sometimes indexed, occasionally still running cron jobs against a live database. Remove the copy when the test is finished. If you need staging permanently, keep one and refresh it rather than accumulating dated copies.

The subdomain and protection interfaces are documented at docs.cpanel.net. For rolling a tested change across many sites afterwards, see Running Your Estate.