How to Avoid WordPress Update Anxiety With an Updates Process

WordPress update anxiety is real. That feeling you get just after pushing ‘update now’ in the WordPress back end. I like most WordPress users have been burned in the past by sites crashing or disappearing after doing what should be routine updates.

The risk is it leads people to not update WordPress at all and that makes the problem a lot worse. What you want is do be regularly updating the core and plugins as opposed to waiting months or years and having everything on the site requiring an upgrade. That was almost certainly end badly!

WP Master exists in many ways to help customers avoid this anxiety. We do it by creating and following an updates policy for each website we look after. Whether you use us or a WordPress support provider or not, you should have a process, and here’s how you go about it.

Before you start

First off you need a few things:

A Backup process

It’s absolutely essential that you have a solid backup process for your site. Here are a few best practice considerations:

1. Run backups at the server level not inside WordPress. I avoid WordPress backup plugins whenever possible for 2 main reason. Firstly they create massive files up on the server adding bloat to your site and making it harder to do lots of things on the server (such as backups, setting up staging sites etc). It’s quite common for backup plugins to have 10s of huge backup files that are also being backed up by the server. Secondly if your updates break WordPress and you can’t log into WordPress as a result, how are you going to restore the site? Avoid them if you can.
2. Have automated recurring backups, ideally daily. Most hosts will have this set up but be absolutely sure they do before you assume they do.
3. Have a way of easily running a backup manually because you will have to do this before you do any updates. Ideally you can click a button on the server and it clearly shows you what was backed up, how big the backup file was etc.
4. Have a way of easily restoring a site if you need to.
5. Have backups sent to a different server. You could do this in lots of ways, we always keep an offsite copy of client sites in case of emergency, but the best bet is having this happen via your hosts automated backups.

Managed hosting is the best for these features, I’ve mentioned Cloudways on here before, it does all of the things above via s super simple interface.

Related: The benefits of managed WordPress hosting providers like Cloudways

Roles

It’s super critical that you understand who does what when it comes to running WordPress updates. I’ve seen lots of scenarios here like clients doing some updates, developers doing some, multiple developers working on the site at once (without knowledge). You don’t’ want this to be messy. Clearly document who does what so there is no confusion. When we sign up clients at WP Master we put together a shared Google doc with the client that documents things like this and specifically says who is responsible for doing what when it comes to running updates. I don’t mind either way who does what but it just has to be understood.

Analytics

Google Analytics is a very useful tool here because ideally you want to be doing updates during a quiet period for the site. With Universal Analytics I use this report (you can copy it) for telling me the busy times for the site. I haven’t gotten around to finding a similar solution for GA4 yet but the realtime feature is very handy, I generally have that open whenever I’m working on the site so you get a feel for the busy times. Also a lot of the time it’s common sense and the website owner has a good handle on the busy times. For ecommerce sites you can look at the orders frequency too which is a handy tip. You don’t want sites going down when orders are coming through.

An understanding of how critical the site is and the risk tolerance of the client

No two sites are equal and no 2 website owners are equal. I have a different approach for all of my sites, depending on how critical the site is. Some I’m happy to run updates with very little prep. Others I’m super careful with. This all should be considered in putting together your updates policy.

Agree on an updates approach

Generally when we sign up clients we give them 3 options when it comes to doing updates.

1. Run the upgrades live and if they break the site, restore it to the backed up version. I wouldn’t recommend this approach often but it’s an option for a low traffic / low revenue site where the site going down isn’t a huge issue.
2. We set up a staging site (effectively a copy of the live website) locally on my local computer and I run the upgrades, make sure everything works OK and if they do that gives us the confidence to run them up on the server. This is a quick way to do it because working locally is super quick once you’ve got the site set up. That said, the customer can’t see the site which is sometimes an important part. Plus I can never mimic the hosting environment perfectly so there is still a fair risk of things being different up on the live site.
3. Duplicate the site and create a staging site up on the server to use to test running the upgrades (or better still use managed hosting with a staging feature). With this option the developer and the client can both have a look at the site afterwards and be comfortable before the updates are run on the live site. You are also mimicking the live server environment perfectly so the risk of things being different on the live site are limited. This is the best practice approach and the approach I’d take for a higher traffic / revenue / risk site but is probably overkill for smaller less critical sites.

Related: When and how to set up a staging site for WordPress

Running updates

So with that all said, here is a bit of a process for doing the actual updates. This process is written as me being the developer working on a client’s site but if you are doing it yourself you can tweak it.

1. Choose a time when you assume the site is quiet (this will be in your notes doc from the process above).
2. Get the customer on live chat or message when you are ready to go (we use Whatsapp and live chat).
3. Have a senior developer on hand in case things break (if it’s a super critical site).
4. Take a manual backup and ensure the size looks right and there are no issues.
5. Check with client make sure there is no reason for extra traffic on the site (like an email blast or a sale).
6. Check on Analytics realtime to make sure the site is reasonably quiet (less than 5 visitors – this number will be specific to the tolerance of the client). 
7. Do upgrades weekly or more often at quiet times.
8. Look through the plugins list and look for whether or not the plugins have been tested with the latest version of WordPress (that’s a handy new feature). If they haven’t it doesn’t necessarily mean you don’t do the update but it’s another data point.
9. Update plugins one by one on the staging site, doing a quick test of the site after each update (more on this below).
10. Update the WordPress core and give the site a bigger test.
11. If all of that goes seamlessly, repeat the process on the live site.

There is some contention around whether to update the WordPress core or plugins first. I can see both sides of it. I tend to do plugins first because it feels like a smaller step and reversing the decision is a little bit easier than running the full core update. But it does depend on the site and there is certainly a case for doing the WordPress core first (WP Beginner recommend this method).

In conclusion WordPress update anxiety is a real thing but with the help of good support and a good process it can be heavily reduced.

If you are an Australian business who wants help with WordPress check out our plans here. If you are interested in more content like this, check out the rest of the WP Master blog.

Photo by Elisa Ventur on Unsplash