If you blog long enough, at some point you’re going to be faced with a sticky problem. You need to make a major change to your site, such as switch to a new CMS, upgrade a critical component or set up a new theme.
However, your live site already has a pretty lengthy history behind it and, most likely, a steady stream of traffic. This makes anything that you do on your main site a very public disaster waiting to happen.
Unfortunately though, many people don’t see the danger of working on their live site and, caught up in the thrill of making a big change, often times jump in and cause a great deal of damage to their sites.
Where one can be reckless and crazy with a site they haven’t yet pushed live, anything that you’ve invested time and energy into creating content for, not to mention building traffic for, needs to be treated with a great deal more care. One can’t simply jump into the code and start pulling things apart when visitors and search engines alike are watching closely, at least not without great risk.
In these situations, cooler heads have to prevail and a slower, more methodical approach is necessary. However, it’s an approach that it seems few bloggers have mastered.
Though most developers recognize the danger of working on a live site, many bloggers, especially those who are new to Web design, do not.
There are many reasons that doing major work on a live site is a bad idea, the first being that, if something goes horribly wrong, you can easily end up destroying your entire site. Considering that you are using your actual site with your active database, if something happens that causes data to become corrupted or deleted, you may find yourself having to restore from backups or without a site at all.
Of course, even if things don’t end so disastrously, even the best overhauls can cause a decent amount of site downtime and other hiccups. During the process of making these changes, your visitors may get site errors ranging from minor problems with the HTML code to missing pages or elements. To make matters even worse, the search engines will continue their work to index your site and, in doing so, may accidentally hit across a broken page, causing them to either index it incorrectly or not at all.
But even if things go perfectly, the burden you place on your server by making large changes to your site while other visitors are coming by can greatly slow down your site and frustrate your visitors as well as search engines. This says nothing about the confusion visitors will feel when every page view is slightly different
In short, making major changes to a live site is a bit like rearranging a large department store while it’s open. Even if you avoid burning the store down or having any serious accidents, you’re going to frustrate your visitors and anyone else who is coming through the door at that time.
In short, nothing good comes out of making such changes but, fortunately, there is a better way.
How to Avoid It
The obvious solution to this pitfall is to never, ever work on a live site. Though you can probably make minor tweaks such as adding/removing a social networking button or editing your sidebar slightly, any major changes, especially any that involve editing multiple files, needs to be done on a test site first.
In that regard, a test site is a critical component that virtually every blogger needs to have in their toolkit. Whether it’s a separate account on the service, a new folder on their hosting account or even a local installation of their site using either WAMP or MAMP, having a test version of your site or being able to set one up quickly is key to rolling out changes and upgrades effectively.
In that regard, major changes need to be treated with care and concern. As the recent backlash against the recent Gawker redesigns have shown, even if your redesign goes perfect from a technical standpoint, which theirs didn’t, it can still cause tremendous headaches and a visitor backlash.
- Develop Somewhere Else: First, develop your site away from your live version. Whether it’s another domain, a subfolder or somewhere else altogether, make sure that the code you’re working on never touches the code that your visitors are seeing.
- Test and Re-Test Carefully: Once you’re done, test your site heavily checking things such as loading time, the impact on server load and any other relevant potential issues. Focus on the technical and make sure that, after several days of testing that there are no glaring problems.
- Launch a Public Beta: Once you’re done making sure it doesn’t explode your server, consider offering a public beta of the site, especially if it changes it visually in a significant way. Using a subdirectory or subdomain, let your visitors, or a select group thereof, visit it and comment on it.
- Adjust as Necessary: The live test will likely expose a few additional technical issues and there may be some suggestions for improvement that you want or need to incorporate into it. Take the time to make your adjustments and get feedback on them, focusing on smaller and smaller problems until you have a site that is as ready as it can be.
- Push it Live: Once you’ve done that, just copy the new code over and launch the new site. At this point, the process should be, more or less, a copy and paste job. However, you may wish to warn your visitors of the time and date of the changeout to avoid any surprises.
The goal of this is not just to avoid any dangerous technical issues, but also to avoid reader backlash and uncertainty about the changes. Any time you make major adjustments to a site, no matter how important or beneficial they are, there’s a risk of blowback if readers aren’t aware of the changes and involved in the process at least somewhat.
In short, changing a site the right way enables your site to move forward, not backward, and let you move on from the changes quickly. It might be the slower system, but it is the faster one in the long run.
To be clear, this isn’t a process that you need to go through for every minor change. In fact, holding off on a security update to put it through this kind of testing process may put your site in more risk than it prevents.
Still, any major changes that you are launching, such as a new theme, a new CMS or anything similar needs to be tested thoroughly and done so away from the live site.
Simply put, toying too heavily with the code that currently runs your site not only puts you at risk of losing your site, but will also frustrate your visitors and may come back to bite you in the search engines. In short, it isn’t a risk worth taking, not when it’s a pitfall that is so easy to avoid.