Updates keep a WordPress site secure, but an update can also break a page, a form or a checkout. The way to get the benefit without the risk is a routine that you follow every time. This is ours, in plain words. Use it for your own site, or compare it with what any provider tells you they do.
Before you start
- Make sure a recent backup exists and that you know how to restore it.
- Pick a quiet time for a store or a busy site.
- Note what the site looks like now: your home page, a key page and your main form, so you can compare.
The routine
- Test on a copy where you can. A staging copy is a private clone of your site. Updates run there first.
- Update WordPress core first. Everything else depends on it.
- Update the theme next, then check the pages.
- Update plugins in small groups. Check the site after each group, not only at the end.
- Test what matters. Your key pages, your contact or booking form, and, on a store, a test order.
- Release. Apply the same updates to the live site, or release the staging copy.
- Look again. A short recheck after release catches what only shows up on the live site.
How it differs by plan
| Step | Essential | Business | Priority |
|---|---|---|---|
| Recent backup confirmed first | Yes | Yes | Yes |
| Tested on a staging copy | No, updated live | Yes | Yes |
| Engineer checks every update | No | No | Yes |
| Test order on a store | No | Monthly | Monthly |
What to do when an update breaks something
- Do not panic and do not click around. Note exactly what is wrong and where.
- Undo the last change. If you updated plugins in groups, you know which group to roll back.
- Restore from the backup if undoing is not enough.
- Find the cause before trying again. Often it is a plugin that has not kept pace with WordPress, or two plugins that clash.
- Write down what happened. It makes the next update safer.
The updates we do not apply blindly
A plugin that its maker has not updated for a long time, or a heavily customised theme, can break when touched. In those cases we tell you what we found, what the risk is and what we suggest, and we wait for your yes before changing it.
Why updates go wrong
- Plugin conflicts. Two plugins that worked together stop doing so after one of them changes.
- Old code. A plugin or theme that has not kept pace with WordPress breaks on a newer version.
- Customisations. Changes made directly to a theme or plugin are overwritten by an update.
- Hosting limits. A server with too little memory or an old PHP version fails mid-update.
- Skipping versions. Updating after a long gap means several changes land at once.
Security updates and feature updates
Not every update is equally urgent. A security fix should be applied promptly, because the weakness it closes becomes public knowledge once the fix is released. A feature update can wait for a convenient moment and a staging test. A good routine separates the two, and does not leave security updates sitting for weeks.
Automatic updates: yes or no?
| For | Against | |
|---|---|---|
| Let WordPress update itself | Security fixes arrive quickly, and nothing is forgotten | An update can break the site with nobody watching, and you only find out later |
| Update by hand on a schedule | You check the result each time | It depends on someone remembering |
A middle path is common: let small security releases apply on their own, and handle larger updates by hand after a backup and a check.
What to watch on a store
On a WooCommerce store an update that breaks the checkout costs orders. Before updating, pick a quiet hour. After updating, place a test order from the cart to the confirmation email, and look at an order in the admin to be sure it was recorded. If you cannot test on a copy, keep the window short and the backup recent.
Keep a record
Write down what you updated, when, and what you checked. When something breaks next month, a short log of what changed is the fastest way to find the cause.
A sample update log
| Date | What was updated | What was checked | Result |
|---|---|---|---|
| First Tuesday | WordPress core, theme | Home page, contact form | Passed |
| First Tuesday | Plugin group A: forms and SEO | Contact form sent a test message | Passed |
| First Tuesday | Plugin group B: store and payments | Test order from cart to confirmation | One issue found, rolled back, reported |
This is an example of the kind of record that makes the next update easier. A short log like this also helps whoever looks after the site next.
When not to update
- Right before a sale or a launch.
- When no recent backup exists. Take one first.
- On a Friday evening, if nobody can fix a problem over the weekend.
- When you cannot test the result and the site is important.
How to explain updates to someone else
If you report to a manager or a client, keep it simple: what was updated, why it matters, what was checked and whether anything needs a decision. A short note is more useful than a long list of version numbers.
Preparing a staging copy
A useful staging copy is a recent clone of the site, not an old one. It needs the files, the database and the same theme and plugin versions. It should not send real emails or take real payments, so check that email and payment settings are in test mode. After testing, remember that changes made on staging do not appear on the live site unless you repeat them or release the staging copy.
Rolling back in more detail
- Stop. Note the time and exactly what changed.
- Deactivate the plugin you updated last, and test the site.
- If the site recovers, roll that plugin back to its previous version, or leave it off while you find a fix.
- If it does not recover, restore the files and the database from the backup taken before the update.
- Test again, and only then put the site back in service.
The first day after an update
- Look at your form submissions and order emails for anything unusual.
- Watch your uptime and error alerts.
- Ask whoever uses the site daily whether anything feels different.
A word on the PHP version
WordPress sites run on a version of PHP chosen by the host. Old versions stop receiving security fixes. Moving to a newer one can break old plugins, so test it on a staging copy first, and do it as a separate step from your regular updates.
Get the one-page version
Print the routine as a single page and keep it next to your desk: the WordPress update checklist. To see how this fits into the rest of the work, read what we handle on a WordPress site.
