A WordPress update is not finished when the dashboard says it succeeded. That message tells you the package process completed. It does not tell you whether a visitor can submit the contact form, a customer can check out, scheduled work still runs, or an editor can update a page.
You need a short acceptance test built around what the site actually does. The goal is not to click every link. It is to prove that the site's critical paths survived the change and that you can recognize a partial failure before a visitor reports it.
Know what changed before you test
Record the WordPress core, plugin, theme, or PHP versions that changed, when the update ran, who approved it, and what recovery point exists. If several components were updated together, note that too. It makes later isolation harder, but at least the evidence will be honest.
WordPress recommends keeping core, plugins, and themes current, and its update documentation warns that core updates affect the files and folders in the main installation. That is why the first post-update question should be "What changed?" rather than "Does the homepage open?"
Test the visitor's critical path
Choose the few actions that make the site useful to the business. Depending on the site, that may include:
- opening the homepage and a representative interior page;
- using primary navigation on mobile and desktop;
- submitting a real controlled contact-form test;
- completing a test purchase or reaching the payment handoff;
- signing in to a member area;
- using site search, scheduling, downloads, or another key feature.
Test the outcome, not merely the button. A form is not proven because it displays a success message; confirm the entry, notification, and human handoff using the contact-form proof chain. A checkout is not proven because the cart loads; use the approved safe transaction method and verify the downstream record when that workflow is available.
Check the page types most likely to differ
Do not let one good homepage represent the whole site. Test a normal page, a post, an archive or search result, and any custom template tied to revenue or support. Look for missing styling, broken layouts, error messages, duplicate headings, empty dynamic areas, and interactions that work only while you are logged in.
Use a private browser window or a logged-out session for visitor-facing checks. Then test the administrative path separately. Caches and permissions can make the same site behave differently for an administrator and a customer.
Verify the administrative path
Open the editor for a noncritical draft or use an approved test object. Confirm that the block editor, media selection, preview, and save process behave normally. If the site depends on scheduled events, imports, feeds, API connections, or background processing, inspect the supported status and logs for those systems instead of assuming they run because the front end appears.
WordPress's Site Health screen can surface background-update, loopback, REST, plugin, theme, PHP, and configuration signals. Capture new warnings, but distinguish a pre-existing recommendation from an update-caused defect.
Review errors in the right time window
Check approved application and server logs for the update window and the acceptance tests you just ran. Match errors to a timestamp, URL, action, and user condition. A large old log is not proof that the update failed, and a clean browser console is not proof that server-side processing succeeded.
If debugging must be enabled, use a staging environment or an appropriate backup first. WordPress's debugging guidance also explains that errors can be logged without displaying them to visitors. Do not leave sensitive debug output exposed on a production page.
Record a pass, fail, or unresolved result
For each critical path, record:
- what you tested;
- the data or account used;
- the expected result;
- the observed result;
- supporting evidence;
- the owner of any defect;
- whether the update can remain or should be rolled back.
"Looks good" is hard to use during an incident. A small test record lets the next person see what was proven and what was never checked. If one important path is unresolved, the update is not fully accepted even when the rest of the site works.
The finish line is evidence that the site can still do its important work. Build that acceptance list into your regular WordPress maintenance routine, and adjust it whenever the site gains a new critical feature.