Running & Maintaining a Site

Staging Environment

Definition

Staging sits between your own machine and the live site. It exists because a page can work perfectly when opened from a local folder and still break once it is served over HTTP — absolute paths that only resolve on your computer, a case-sensitive filename that Windows forgave and the server will not, a script blocked as mixed content, a font that fails because of CORS. The rule that makes staging worth having is that it should match production in the ways that matter: the same host, the same build output, the same file layout. A copy on a different platform with different behaviour tells you very little. For a static site this is cheap — the staging environment is another published copy at another address, and on hosts that offer a deploy preview per change you get one automatically.

Why It Matters

The alternative is testing in public, which works right up until it does not. A broken stylesheet is visible to every visitor for as long as it takes someone to notice, and to a crawler that happens to be mid-visit. Staging also changes how people behave: when there is a safe place to look, a client reviews a draft properly instead of approving a description of it, and typos get caught by someone other than the person who wrote them. The cost is one extra address and two minutes per change; the saving is every incident that never happens.

How It Works

Publish the build to a second address — something like acme-staging rather than acme — and keep it out of search by password-protecting it, which is more reliable than a robots.txt file that only well-behaved crawlers obey. Deploy the exact artefact you intend to ship, not a rebuild, so that what you check is what goes live. Then run the same short list every time: the homepage and two deep pages, one asset of each type, the 404 page, a hard refresh to defeat caching, and a phone-width viewport. Keep staging data harmless — real customer records do not belong on a copy with weaker access control. When it passes, promote the same files to the production environment rather than repeating the upload from a different source, and remember to delete stale staging copies, because an old one left indexed becomes a duplicate of your live site.

Real-World Example

A recruitment firm publishes a benefits handbook at aldermere-benefits.99helpers.site. Every revision goes first to aldermere-benefits-staging.99helpers.site with password protection on, where two colleagues read it before anything is promoted. In one revision the staging copy shows every image broken, because the export had written paths beginning with a drive letter from the designer's laptop. That version would have been live for an afternoon before anyone said anything; instead it is fixed in ten minutes and the public address never sees it.

Common Mistakes

  • Leaving the staging copy public and unprotected, so search engines index it and the site competes with itself for its own pages
  • Staging on a different host or configuration from production, which hides exactly the class of bug staging exists to catch
  • Rebuilding for production instead of promoting the files that were tested, so the artefact that was checked is not the artefact that ships
  • Accumulating old staging addresses that nobody owns — each one an out-of-date copy of the site still answering requests

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →