WordPress updates without fear

Why updates break sites

WordPress is a core plus a dozen or several dozen plugins from different authors plus a theme, often with changes the agency made directly in its files. Each update changes one piece, and the rest has to fit around it. The most common failures: a plugin incompatible with the new PHP version, two plugins that do the same thing after an update, and a theme update that overwrites the agency’s changes. All three are predictable if you update in order and check after each step.

The routine, step by step

1. A backup of files and database. Not “the host takes backups”, but a copy you can see, downloaded or stored off the server. And tested: at least once, restore the site from it onto a staging copy so you know it works. A backup nobody has tested is a hope, not a backup.
2. A staging copy of the site. Most hosts offer a staging feature: a clone of the site at a separate address. If yours does not, one can be made by hand in a subdirectory or locally. Everything below happens there first.
3. A list of what you have. PHP version, WordPress version, the list of plugins with the date the author last updated each, the theme and whether it has a child theme. A plugin its author has not touched for two years is a candidate for replacement, not for updating.
4. The order: PHP, core, plugins, theme. First check whether the plugins declare compatibility with the new PHP version, then change it in the hosting panel (it can be reverted with one click). Then WordPress core. Then plugins, one at a time, starting with the ones the business depends on: shop, forms, payments. The theme last, and only if the agency’s changes live in a child theme or there are none.
5. A check after each step, not after all of them at once. Otherwise you do not know which step broke the site.
6. Production. Once the staging copy works: the same order on the live site, outside busy hours, with a backup taken immediately beforehand.

What to check after an update

• The home page and the three most important subpages: layout, menu, images.
• The contact form: send a test enquiry and check it arrived by email and in the CRM, if one is connected.
• The shop: add a product to the basket, go through to payment, and where possible place a test order.
• Logging in to the admin and to a customer account in the shop.
• The mobile version, on at least one phone.
• Speed: the same measurement before and after. An update that makes the site load twice as slowly is not finished.
• The PHP error log on the hosting: warnings that were not there yesterday.

When to stop

There are situations where it is better to pause and ask for help than to “try once more”:

• You have no backup, or you do not know whether it works.
• A critical error appears after an update and you do not know which plugin causes it.
• The theme has changes made directly in its files, with no child theme. An update will wipe them.
• A jump of two PHP versions at once, or a plugin whose release notes say “breaking change” or “migration”.
• The shop is mid-promotion, or it is the day before an important deadline. Updates can wait a week; an outage cannot.

How often

What	How often
Security patches for core and plugins	Within a few days of release
Routine plugin updates	Once a month, in one batch
Major WordPress and PHP versions	A month after release, once plugins have caught up
Backup restore test	Once a quarter

This routine takes an hour or two a month and is exactly what I do as part of monthly care, alongside monitoring and a pool of small changes.