Staging site

A staging site is a working copy of your website, kept somewhere the public cannot reach it, where changes can be built and tested before they touch the version your customers use. It is the difference between finding out that a plugin update breaks the contact form and finding out from a customer who could not send one.

In short

• A private copy of the site for building and testing changes.
• Protect it with a password, not with a robots.txt rule.
• The classic failure is launching with search blocking still enabled.
• It only helps to the extent it resembles the live site.

The two accidents

Nearly all the harm involving staging sites comes from one of two mistakes, and neither is technically complicated. Both are silent, which is why they persist.

The first is the staging copy becoming visible. A duplicate of your entire website sitting at a public address, findable by anybody, sometimes with test content and half-finished pages on it. It happens when the only protection was a rule in robots.txt, which asks crawlers not to fetch the pages but does not stop the address appearing in results if anything at all links to it. That distinction is the subject of the robots.txt entry and it is the reason a password is the correct answer.

The second is the reverse and it is worse. Staging sites are normally built with search engine indexing switched off, which is correct. When the site goes live, somebody has to switch it back on. If nobody does, you have a perfect new website that instructs every search engine to ignore it. Because a relaunched site is expected to move around in the results for a while, the silence gets put down to that, and weeks pass before anybody connects the launch to the absence.

Checking for the second one

This takes a minute and is worth doing on the day of any launch and again a week later.

Open the live site, view the page source, and search it for the word noindex. If that appears in a robots meta tag, the site is telling search engines to stay away. On WordPress there is a second place to look, in the reading settings, where a single tick box does the same thing across the whole site.

Search Console will also tell you, in the page indexing report, though it takes longer to notice than you will.

Why staging does not catch everything

A staging site is only useful in proportion to how closely it matches the real one, and the gap tends to widen quietly. Content diverges as the live site is updated and staging is not. Integrations get pointed at test accounts, so payments and emails behave differently. Caching is often configured differently or switched off entirely, which hides exactly the performance problems you would want to find. Settings get changed on one side during debugging and never mirrored.

The practical answer is to refresh staging from the live site immediately before any significant piece of work, so the copy is current when it matters most, and to be sceptical of results from a staging site that has been sitting untouched for months.

The changeover

The moment of pushing changes live is the part most likely to lose something, and it deserves a plan rather than a decision made at the time. Content published on the live site while the work was happening does not exist on staging. Overwriting live with staging discards it, and on some setups that includes orders, form submissions and customer accounts. Agree in advance which direction each part travels, or simply freeze publishing for the changeover window, which is the simpler answer for most small businesses.

Afterwards, check the things nobody thinks to check: the contact form actually sends, the tracking is still installed, the payment process completes, old addresses still redirect where they should, and the indexing setting is correct.

Words you will hear

• Environment. A copy of the site. Live, staging and sometimes development for work in progress.
• Production. The live site. What customers see.
• Deploy or push. Moving changes from one environment to another.
• Rollback. Reverting to the previous version when something goes wrong. Worth confirming your host offers it.
• HTTP authentication. The browser password prompt. The right way to keep staging private.
• noindex. The instruction that keeps a site out of search results. Essential on staging and disastrous on live.

The launch check

Whoever presses the button should have a list, and it should be short enough that nobody skips it. Confirm the site is not blocking search engines. Submit the XML sitemap. Send yourself a message through the contact form and wait for it to arrive. Complete a test order if there is a checkout. Load three old addresses and confirm they redirect where they should.

Five checks, ten minutes, and they catch the failures that otherwise get discovered by a customer or by a report a month later.