We're previously discussed the necessity for staging environments in software development. In this excellent discussion they nicely define a staging environment as "the last step before something goes into production and is visible on the live site."

Whereas we previously talked about staging in terms of projects or apps, the need for some kind of almost-live server for reviewing website changes before going into production files is just as acute for websites, even small ones.


Benefits Of A Staging Website

In terms of a web project, think of staging as just a clone of the real website. It should have all of the same files, support files, media and directory structure as the live site.

There are obvious reasons why this is a good idea.

Testing - You have to test somewhere. Instead of just testing on a local computer (aka "local environment"), to accurately test how your site changes will look in other peoples' browsers coming from your servers is to have your update on your server and test it through a browser.

Other People Review - This isn't just for the web developer to test; other people should be reviewing changes and try them out as well. For starters, in professional development environments the tester should always be someone other than the same developer who made the changes. In other words, don't be the official tester of your own code. Having it on a staging server makes it easy and useful for your testers to see how it really behaves.

Non-developers or clients need to sign off on website changes. Regularly, we put client-requested changes in a staging version of their websites. It has to go through their review and approval before we go live. So, the staging area is their last place to check to see changes.

Allows For Multiple Browsers/OS - When it comes to web design, you've got to test in a variety of platforms and operating systems. It's too tempting to see things in one browser and say "It looks great" and rush out the new files. Even a brief testing protocol will make sure that the changes are viewed on mobile devices, tablets, laptops/desktops, in all major browsers, and at least on Apple, PC and Android platforms.


Second Location Of Web Files

For self-hosted or Linux web hosts, this doesn't have to be a very sophisticated or difficult process. You can just have an alternate folder called "/Staging/" where you have a whole second copy of your entire website. You upload your changes here first and voila: you have a staging site.

Cloud Hosting - We have a project hosted in Microsoft Azure where they have a great staging concept called "slots". You can read about this in detail from Microsoft but suffice it to say that once you like the changes you've published to and tested in a staging slot, then you just press a button to "swap" the Staging changes into your Production changes and you're done.

WordPress - In our previous article we gave some hints where to find reference materials for how to establish staging areas of your Word Press site. Here are a couple of great rundowns: https://wpengine.com/resources/what-is-a-staging-site-why-have-one and https://themeisle.com/blog/wordpress-staging-site/.


Make Sure Staging Isn't Public

You obviously don't want anybody but you and your testers to access your staging site. WordPress and cloud hosts like AWS and Azure have great stuff in place. But if you're doing this on your own self-hosted or old-school Linux paid host site then you need to make sure things are secure.

You can always password protect - the easiest way to do that would be at the directory level. If you're a cPanel shop, look at the Password-Protected Directories section of your dashboard.

You also want to make sure that Google can't crawl and index your staging area.

Make them uncrawlable. Your robots.txt file should exclude your staging area folder. We have some robots.txt file guidance here.


Testing Vs. Staging

Beware in discussions like this that "testing" and "staging" can start to get interchangeable in smaller design developments. When we develop a website for a smaller client, we just have the one staging site which we really could call "testing".

But we also like to think of a "testing" environment really means an area to test and try anything, especially just to look at specific purposes - and not really worry there if new code breaks other things on the site. "Staging" is the area where the whole site has to work (and be thoroughly re-tested).

Your staging area can still be hooked up to your live, production databases. This way, you could do your testing by having a couple of more trusted and experienced employees working in the staging area as real-time testing of the new changes.

Again, remember that "staging" can be seen as meaning "almost live".


Good Luck

You should be at least clear on the concept after reading this far. And with the cited references above, you likely are up for trying to set up your own staging area.

But if you need a little push in the right direction, we'd be happy to help so don't hesitate to reach out to us.