· WPbyAI Research · WordPress Maintenance · 6 min read
WordPress Maintenance Checklist: What to Check Before and After an Update
Use this practical checklist to prepare a WordPress update, test the pages and forms that matter, and recover when something goes wrong.
A WordPress update is complete when the site still does the work your customers need. That means checking the pages, forms, navigation, and other important actions after the software changes.
This checklist is for small business websites and the people responsible for maintaining them. Use it for planned WordPress, plugin, or theme updates, and adapt the checks to the features your site actually uses. A brochure site needs fewer checks than a store, booking site, or membership service.
Before you update
Record what works today
Write down the update you intend to make and the current WordPress, theme, and affected plugin versions. Open the important pages and try the main customer action before changing anything. Keep a few screenshots and note any existing faults so you can tell whether a problem is new.
For a service business, that action might be sending an inquiry. For an exporter, it might be finding a product specification and requesting a quotation. Choose the journey that matters to your business.
Confirm your backup and recovery route
The WordPress update guide recommends backing up before starting so the site can be restored if something goes wrong. Check that the latest backup finished successfully and identify the person who can restore it.
A typical WordPress site needs both its files and its database to recover fully, as the official backup handbook explains. Confirm that themes, plugins, uploaded media, content, and settings are covered. Keep an accessible copy outside the server being updated, and arrange a restore test in a separate environment if the recovery method has never been tested.
For a site receiving orders, bookings, or inquiries, identify what could arrive after the backup. Restoring an older database can remove those newer records. Agree how to preserve or reconcile them before a restore becomes necessary.
Read the update notes and choose a time
Check the affected software’s release notes for requirements, compatibility changes, or a database update. Choose a time when someone can run the checks and respond to problems. A security fix may need a quicker response than an ordinary feature release; assess it promptly instead of automatically waiting for the next monthly slot.
Test the update on a preview copy
A staging site is a separate copy used to try changes before visitors encounter them. Use a recent copy with relevant versions and content. Keep it access-controlled and prevent test email, payments, or external integrations from contacting real customers.
Apply the intended update and run the checks below. For more complex sites, follow the software provider’s instructions. WooCommerce’s update guide specifically recommends staging tests covering product pages, cart, checkout, payments, shipping, taxes, and order emails.
Record exactly which versions passed. If you then apply a different set of updates to the live site, the earlier result no longer covers that set. Our guide to previewing WordPress changes explains what a useful preview should preserve; the plugin compatibility guide explains why a plugin listing alone does not prove compatibility.
If your host offers no staging facility, ask what testing and recovery options are available before a substantial change.
Check the live site after updating
Open it as a visitor
Check the public site while logged out. Review the homepage and representative inner pages, including a contact page and any pages using the updated plugin or template. Look for missing images, unexpected colors, altered spacing, and text that has become difficult to read.
Refresh the relevant caches after the update, following your host’s instructions. WordPress’s update documentation notes that cached pages can continue showing the old result. Check the public version again afterward.
Try the mobile layout and navigation
Use a phone, or a narrow browser window followed by a phone check when possible. Open the menu, follow important links, and check that buttons remain usable. Look for clipped headings, overlapping sections, or a page that scrolls sideways.
Complete the main customer action
Submit a clearly labeled test inquiry using an address you control. Confirm the visible result, check whether the submission was saved where expected, and verify email delivery if the form promises it. A success message alone does not tell you whether the email arrived.
For a store, use an appropriate test payment method and verify the order result. Booking and membership sites need equivalent checks for their own critical actions. Coordinate tests so they do not create unintended charges or customer notifications.
Check editing and search settings
Sign in and confirm that the editor loads. Open a draft to check that normal editing still works without changing published content just to test it.
If the update affects your theme, page builder, or search plugin, also inspect page titles, important URLs, redirects, and indexing settings. Check that a staging restriction has not reached the public site. Save the outcome and any remaining issue with the update record.
A checklist you can copy
Use a separate copy for each update. Mark an item complete only after checking it; write “not applicable” with a reason where needed.
| When | Check | What to record |
|---|---|---|
| Before | Current site works | Key pages and customer action checked; existing faults noted |
| Before | Update scope is clear | Software names, current versions, and intended versions |
| Before | Backup is usable | Completion time, file and database coverage, storage location |
| Before | Recovery is understood | Restore method, responsible person, and handling of newer data |
| Preview | Intended update is tested | Versions tested and any difference from the live environment |
| After | Pages display correctly | Homepage, inner pages, images, and typography checked |
| After | Mobile and navigation work | Menu, links, buttons, and narrow-screen layout checked |
| After | Main customer action works | Test inquiry, order, booking, or other relevant result |
| After | Editing and search settings work | Editor access and affected search settings checked |
| Finish | Result is recorded | Completion time, reviewer, unresolved issues, and next action |
If an update causes a problem
Pause further changes and record the first failing page or action, the time, and the versions involved. Keep the error message or screenshot. Ask the responsible developer or host to determine whether a configuration fix, a compatible software version, or a restore is appropriate.
Use the recovery method established before the update. Account for any new orders, submissions, or content before replacing database data. After recovery, repeat the relevant visitor checks and investigate the failed update on staging before trying it again.
Agree who does the checks
Whether your team maintains the site or pays a provider, assign each task to someone. Ask which checks are included in the service and what happens when one fails. Our WordPress maintenance cost guide helps compare the hosting, tools, and human work involved.
WPbyAI’s approach to WordPress changes centers on reviewing a scoped change before accepting it. You can describe an existing-site project for a private pilot review. Production updates, ongoing maintenance, and emergency response need their own agreed owner and scope.