There aren't many things more frustrating for a website owner than having unplanned downtime on your site. Typically this leads to frantic emails, phone calls, chat sessions with your hosting company, and scrambling to figure out what went wrong. This is a scary place to be in as you wonder how long the site will be down, how many visitors (or customers) you are losing, and what it will cost you. Let's talk about some processes that can help to reduce the possibility of a broken site and hopefully get your site back up and running faster when it does happen.
Backups, backups, backups
You need to have backups of your site. Any decent web host either includes a backup service as part of their hosting package or has it as a premium add-on for a small fee. Your site should be backed up daily, and if something goes wrong it shouldn't take you more than a few minutes to restore your site from backup. This works great on sites whose content is not changing every hour or minute but can be more complex for very active ecommerce stores or blogs because restoring from the backend means anything that changed on the site since the last daily backup (maybe 8, 12, or even 20 hours earlier) is lost. If you are on a web host that doesn’t have an acceptable backup tool available you could look at something like ManageWP which has a great backup feature.
Having that daily backup is a great insurance policy, but I think that it’s the bare minimum you should be doing to maintain a stable site, if you care about your site at all.
Staging sites can save your bacon
WordPress core updates and plugin updates keep your site secure and compatible with the latest server technologies (php, mysql, etc). They also may fix bugs you didn’t even know existed on your site or in your ecommerce store. But running those updates on your production (live) site without first testing them on a staging server is very risky. If you have no staging site I beg you to take a backup snapshot right before doing those updates, but you reduce your risk of a broken site by testing updates on a staging site first.
A staging site is like a copy of your live site but the staging site isn’t open to the public, and if things break there you can take your time to fix them and figure out what went wrong without the stress of the public (and Google) seeing your broken site. I recommend running WordPress core and plugin updates on a staging site first and testing the key functionality to make sure that nothing is busted. If something is not working after you perform an update I typically will look at the change logs for the plugin or WordPress and see if anything in there stands out in relation to the issue I am experiencing. After that I usually turn on WordPress debugging and see if some new errors are showing up related to the updates I recently performed.
One thing you will want keep in mind when working with a staging site is to make sure it isn’t charging credit cards or sending customers emails. Change any ecommerce payment gateways to be in test mode, indicate to search engines that you don’t want your staging site indexed, and if you have plugins doing automatic posting to social media turn them off.
Version control is magical
A few months ago I was on a call with a client where they told me their site was down for 45 minutes. This site gets thousands of visitors a day and probably turned away hundreds of visitors in those 45 minutes. The deployment (publishing) of code to your live (public) site should be done with care and a well thought out process.
Version control systems, like GIT, force developers to be more intentional when making code changes and provide everyone involved with a clear history of who modified the code, exactly what changed, and when it changed. With version control in place, there are even ways to roll back the broken code to a previous time when the site was working properly.
If can be a hassle to set up GIT initially, but the benefits and subsequent peace of mind definitely outweigh the extra work. GIT will not solve all your problems and should be paired with a solid deployment process, but I strongly recommend its usage for any site serious about uptime and stability.
Let’s talk some more about how to run a solid WordPress site
We would love to hear from you if you have any great tips to share on setting up a stable WordPress site, questions about the topics above or WordPress in general.