Staging site

In practice

Most professional builds run at least two environments: production, which is the live site, and staging, which mirrors it closely enough that what you approve is what you get. Larger projects add a development environment where work is genuinely unstable. The value is that a mistake on staging costs an afternoon, while the same mistake on production costs whatever the site earns in the time it takes to notice.

Staging matters most during a website migration, because it's where you verify the parts that are hard to reverse: that content came across intact, that redirects resolve, that forms actually deliver. Testing those on the live site means testing them on your buyers.

The environment has to be blocked from search engines, or you end up competing with yourself: two near-identical sites, one of which nobody was supposed to see. That's normally done with password protection, and sometimes with a directive telling crawlers to stay out.

Which sets up one of the most common and most expensive launch mistakes there is. The block that protected staging gets deployed to production, and the new site goes live instructing search engines not to index it. Everything looks perfect to visitors. Rankings quietly disappear over the following weeks, and the cause is one line nobody thought to check because the site plainly works.

So add one item to every launch checklist, above the rest: after go-live, confirm the production site is crawlable and that no canonical tags still point at staging URLs. It takes two minutes and it's the difference between a launch and a quiet outage.