Testing a website after CMS and plugin updates

Updates are necessary. They fix security holes, keep the site compatible with newer versions of PHP and browsers, and add features. They also change code that your site depends on, and sometimes that change breaks something nobody thought to look at. The answer is not to stop updating; it is to test in a way that fits the size of the update.

Why updates break things

A website built on a content management system is a stack of parts from different authors: the CMS core, a theme, a set of plugins, the server's software, and any custom code. Each part assumes things about the others. When one part changes, an assumption can stop being true. Possible results include:

• A form plugin update changes the markup, and a custom style or script stops working.
• A theme update overwrites changes someone made directly to the theme's files.
• A plugin update requires a newer version of PHP than the server runs.
• Two plugins that worked together stop doing so when one changes how it loads.
• A caching or optimisation plugin combines scripts in a new way and breaks an interactive feature.

None of these show up as an error on the home page. The site looks fine; something behind it no longer works.

Automatic updates: know what is switched on

Find out which parts of your site update themselves. On WordPress, the documentation explains that since version 5.5, administrators "can manually opt-in for automatic updates theme by theme and plugin by plugin", and that "by default WordPress runs auto-updates twice per day". Other platforms, and some hosting providers, have their own automatic update settings.

Automatic updates are a reasonable choice for security fixes, especially on small sites without regular maintenance. But if updates happen automatically, testing has to happen on a schedule too, because nobody will be prompted to test after each one. A weekly or monthly check of the key flows covers that gap.

A regression routine that fits in an hour

Regression testing means checking that things which used to work still work. For a small site, the routine below covers the important ground without retesting everything.

1. Back up first Confirm a recent backup of files and database exists, and that you know how to restore it. A backup you have never restored is a hope, not a plan.
2. Read the release notes Skim the changelog for each update. Look for mentions of forms, payments, templates, PHP versions or features you use. A major version number change deserves more care than a small fix.
3. Update staging first Apply the updates to a staging copy of the site where one exists. If there is no staging site, update at a quiet time with the backup ready.
4. Run the critical flows Submit every form and confirm delivery. Complete any booking, sign-up or purchase flow in test mode. Log in and out if the site has accounts.
5. Check the affected templates Look at the pages the update could touch: if a gallery plugin changed, look at the galleries; if the theme changed, look at every template once, on a phone and a computer.
6. Look for errors Open the browser's developer tools on key pages and check the console for new red errors. Check the CMS's own site health or error log if it has one.
7. Update live and repeat Apply the same updates to the live site, then repeat the critical flows straight away.
8. Write it down Record what was updated, when, what was tested and the result. The next person will thank you.

Choosing the regression set

If you have written test cases, as described in our guide to test cases for small websites, pick a regression set from them. Good candidates:

• Every case marked high priority.
• Every case for a flow that brings in money, enquiries or bookings.
• Cases for any feature provided by the plugin or theme that was updated.
• Cases for anything that broke after a previous update.

Keep the set short enough that it actually gets run. A forty-case suite that is skipped because it takes all afternoon protects nothing; a ten-case set run every time protects a lot.

Bigger updates need bigger tests

Not all updates are equal. Scale the testing to the change:

When something breaks

If a test fails after an update:

1. Decide quickly whether it is serious. A broken enquiry form or checkout justifies rolling back; a misaligned icon does not.
2. If rolling back, restore the backup or revert the single update that caused the problem, then retest.
3. Write a bug report with the update details, so the developer or the plugin's author can reproduce it. The bug report generator has a field for evidence where version numbers belong.
4. Note the incident against the regression set, and add a test case for it if there was not one.

Monitoring between updates

Even with a good routine, something can fail between checks: a mail account password expires, a payment provider changes its settings, a certificate fails to renew. Two cheap safeguards help:

• Uptime monitoring that alerts someone when the site stops responding.
• A scheduled form test, either automated or a calendar reminder to send a test enquiry each week.

A sample update log

Keeping a log of updates and tests turns a vague memory into something you can check. A spreadsheet with these columns is enough:

The entries above are illustrative. The value of the log appears when something goes wrong weeks later: you can see what changed and when, and whether it was tested.

Updates you did not make

Not every change comes from your own update button. Hosting providers update server software, payment providers change their integrations, and third-party scripts loaded from other services change whenever their owners release new versions. You will not always be told. This is the main reason a scheduled check of the critical flows belongs alongside the routine for your own updates: it catches changes made by others.

When to bring in outside help

A small site with a careful owner can run this routine alone. Outside testing earns its cost around larger changes: a major CMS version, a redesign of key templates, a new booking or payment system, or a move to new hosting. At those points a fresh pair of eyes, working from written test cases, finds the problems that familiarity hides.

Sources

• Plugins and themes auto-updates, WordPress documentation

Sources were read on 4 November 2026.