A WordPress update should be a bounded change with checks before and after, plus a usable way back. An available update is a reason to plan the change, not proof that your particular theme, plugins and host will work together afterwards.
Use the English update worksheet to record intended checks and actual observations.
Record the starting combination
Note WordPress, PHP, theme and plugin versions, the operator and time. Identify business-critical tasks such as forms, downloads, administration and any booking or payment flow. A screenshot does not establish the function behind it.
Identify a matching file-and-database recovery set stored outside production and who can restore it. Use a separate backup restore test when that evidence is missing. Ensure another authorised person can access the instructions.
Keep the update group small and justified
Do not change every layer together if you need to identify the cause of a failure. Group components only when their dependency requires it. Review release and compatibility information for the actual versions; it is not a substitute for checking your combination.
Isolate the update test
Prepare protected staging for important workflows. Confirm it uses its own database and controlled mail, payment and scheduled-job configuration. Updating a copy that still writes to production defeats the separation.
Repeat the same functional checks
| Check | Required observation after the change |
|---|---|
| Homepage | Intended content loads without an application error |
| Form | A new identifiable test reaches the safe destination once |
| Download | The expected file opens and is not empty |
| Administration | Authorised login and the selected task work |
| Unknown URL | A useful not-found response rather than an unexpected server error |
Use the same controlled test data before and after. Save URL, time and outcome without copying unnecessary personal information. A green form message alone is insufficient.
Fictional failed update
Imagine five checks on a brochure site. After a plugin update, the homepage, download and login work, but form delivery fails and the not-found route produces a server error. Three pass and two fail; the decision is rejection, not “mostly successful”.
The operator restores staging, investigates one cause and repeats the affected checks. Both failed rows remain open until the restored baseline and the separate update attempt meet their requirements. This is a tabletop example, not an observed customer update.
Make the production decision separately
A staging pass does not itself authorise release. Name the production operator and rollback decision-maker, take an appropriately current recovery set and repeat required checks after the live change. At a failed required check, use the agreed recovery boundary instead of layering another update over an unexplained failure.
Carry the evidence into maintenance
Keep update acceptance and backup recovery evidence separate: one proves the new combination's tested functions, the other its tested return path. Assign ongoing checks through the maintenance checklist. The maintenance cost guide helps scope recurring responsibilities.