WordPress Update Checklist: Back Up, Test and Verify
An update is complete when the site’s important tasks still work. An “updated successfully” message confirms one step of the process. A business also needs to know that staff can edit content, visitors can submit enquiries and customers can finish the relevant transaction.
Use this checklist to organize a maintenance release. For an existing failure, use plugin conflict troubleshooting or the website outage checklist. PHP runtime changes have their own PHP upgrade checklist.
Define the update and its owner
List the current and intended versions of WordPress core, the active theme and the affected plugins. Read the relevant release notes, required dependencies and vendor instructions. Record who applies the update, who checks the result and who can approve a recovery action.
Do not assume your hosting subscription includes all of this work. Use the security responsibility checklist to separate server maintenance from application updates. Ask the maintainer how an urgent security release changes the usual testing schedule; an indefinitely postponed update is not a maintenance plan.
Establish a recovery point before changing production
WordPress’s update documentation recommends a backup before updating and explains that an update can require a database upgrade. Confirm the recovery scope rather than treating a download of one plugin folder as a complete rollback.
Record the live backup time, included files and database, access method and person who can restore. Check the retention window and whether the procedure has been rehearsed using the restore-test checklist. For a store, establish how newer transactions would be preserved or reconciled before authorizing a database replacement.
| Workflow | What to verify | Useful evidence |
|---|---|---|
| Public pages | Important routes, navigation and media work on mobile and desktop. | Example URLs and before-and-after observations. |
| Staff editing | An authorized user can save and preview a harmless draft. | Editor, account role and result. |
| Enquiry form | The form result and expected staff notification both arrive. | Labeled test enquiry and recipient confirmation. |
| Store checkout | The selected payment test flow produces the intended order result. | Sandbox order and gateway references. |
| Background work | Relevant scheduled actions or integration tasks complete. | Job reference, observation time and result. |
Rehearse on a suitable staging copy
Use a recent copy and record when it was created. Check its runtime and relevant configuration against production so the result is meaningful. Apply the staging isolation checklist before tests that could send email, contact external systems or trigger payments.
Follow the component vendor’s required update sequence. Where dependencies allow it, keep changes in identifiable steps and record the result after each one. If a workflow fails, stop the release and retain the failing version combination for investigation. Changing everything again can erase the evidence that explains the failure.
Release with a clear stop condition
Choose a time when the maintainer and verification owner are available. Record which visitors or staff may be affected, the expected interruption and the criteria for pausing the work. Review the host’s deployment method with the staging guide; testing an update on a copy does not make replacing the live database appropriate.
If WordPress or a plugin requests a database migration, follow its supported procedure. Do not assume that putting older files back reverses every data change. Ask the maintainer to choose a recovery method compatible with both the application and the current business records.
Verify production and close the change
Repeat the acceptance checks on the live site. Check the relevant cache layers with their owner when stale output obscures the result; the caching guide explains their different jobs. For a WooCommerce release, use the test-order checklist to plan the isolated rehearsal and any separately authorized production verification.
Keep the version record, backup reference, test results and unresolved issues together. Set the next review date and confirm who receives update alerts. Use the support-ticket checklist if the host or software vendor needs reproducible evidence.
Use a business function as the stop condition
For a hypothetical update, define a stop condition such as a controlled enquiry failing to save or a test checkout losing its expected result. Record a passing baseline before the change and repeat the same case afterward. If it fails, retain the version combination and evidence for investigation. Do not continue unrelated updates while the release’s required outcome remains unresolved.
Sources and scope
Official WordPress update documentation checked October 5, 2026. Acceptance criteria and the maintenance record are HRL’s recommendations. This page does not report updates performed on a reader’s site or certify a particular plugin combination.