Verifying a WordPress major upgrade — a 7-step post-upgrade checklist

You followed the step-by-step WP-CLI procedure from W4, the terminal printed "Success: Core updated successfully," and the session is over. Stopping there is the most common place for post-upgrade problems to slip through undetected.

WP-CLI's "success" means the core files were replaced. It doesn't mean the site is working. Whether the database migration completed cleanly, whether plugins are compatible with the new core, whether forms submit, whether carts process — these require human verification after the command finishes.

This checklist pairs with the pre-upgrade checklist from W1. Where W4 covers what to run, this covers what to check when the running is done.

Why "updated successfully" isn't enough

A successful WP-CLI command doesn't guarantee:

• Plugin combinations behave correctly under the new core
• PHP warnings or notices aren't being silently swallowed (WordPress can display "Updated successfully" while non-fatal errors are firing in the background)
• Interactive features — forms, search, authentication — still work end-to-end
• Cached content isn't serving old file versions

The five failure patterns in W3 share a common trait: they often aren't noticed immediately after the upgrade, but hours later or at the next user interaction. The longer verification is deferred, the harder the problem is to trace back to its source.

Order of verification — highest impact first

Check in order of "what would hurt users most if it's broken." This way, if you find a problem, you can make a rollback decision before working through lower-priority items. Each step is a go/no-go gate.

STEP 1 — Re-run core file integrity check

Run wp core verify-checksums a second time, after the upgrade is complete.

# Confirm the final version
wp core version

# Verify core files against WordPress.org checksums
wp core verify-checksums

This catches any file corruption that may have occurred during the update process. A clean result prints "Success: WordPress installation verifies against checksums." If discrepancies appear, wp core download --force reinstalls the correct files.

This is the same command used during the W4 upgrade sequence. Running it again at the end confirms the final state, not just the state after one intermediate step.

STEP 2 — Admin dashboard login and plugin status

Log in to /wp-admin/ and check:

• Dashboard loads without a white screen or 500 error
• Posts, pages, and media list without errors
• The Plugins page — all plugins that were active before the upgrade are still active

That last check matters most. WordPress sometimes force-deactivates plugins when it detects a compatibility problem with the new core. From the command line:

# List active plugins — compare against pre-upgrade state
wp plugin list --status=active --format=table

# Check for anything that got deactivated
wp plugin list --status=inactive --format=table

If the active count is lower than before the upgrade, investigate which plugin was deactivated and why before continuing.

STEP 3 — Front-end page loads and JavaScript errors

Check HTTP status on key pages, then open the browser console.

# HTTP status check on key pages
curl -s -o /dev/null -w "%{http_code}" "https://example.com/"
curl -s -o /dev/null -w "%{http_code}" "https://example.com/contact/"
curl -s -o /dev/null -w "%{http_code}" "https://example.com/shop/"

The browser console check (F12 → Console) is as important as the HTTP check. W3's pattern 2 — the jQuery version cascade — typically surfaces as JavaScript errors in the console while the page appears to load normally. A page that looks fine can have a completely broken interactive layer underneath.

Pages to prioritize:

STEP 4 — Form and interaction testing

Test the site's core interactive flows manually.

• Contact form: submit → confirmation screen → verify the notification email arrives
• Search: enter a keyword, confirm results appear
• Login / registration: authenticate through the login form
• Comments: if enabled, post a test comment

This step can't be replaced by WP-CLI. Prepare a test account and email address in advance. Form plugins (Contact Form 7, WPForms, etc.) are sensitive to core JavaScript changes — a submit button that does nothing is a common post-upgrade symptom that only shows up when you actually press it.

STEP 5 — E-commerce and booking flow (where applicable)

For sites running WooCommerce, booking systems, or membership services, complete a test transaction.

• Add a product to cart and adjust quantity
• Proceed through checkout
• Confirm the payment form renders correctly (card input fields, gateway widgets)
• Complete a test payment using the payment gateway's test mode (Stripe test mode, etc.)

"Checkout page loads" is not sufficient — verify that the payment goes through. E-commerce plugins interact deeply with core JavaScript and are among the most likely places for post-upgrade breakage, especially when page builders or gateway plugins are also in the mix.

Skip this step for non-transactional sites.

STEP 6 — PHP error log review

A site can appear fully functional while PHP errors accumulate in the background. Check the logs.

# Check whether WP_DEBUG_LOG is active
wp eval 'echo defined("WP_DEBUG_LOG") && WP_DEBUG_LOG ? "debug log: on" : "debug log: off";'

# If active, get the content directory path and check debug.log
wp eval 'echo WP_CONTENT_DIR;'

# Check PHP error logs via SSH (path varies by host)
tail -100 ~/logs/php_errors.log 2>/dev/null

As covered in the PHP 8.2+ deprecated noise post, a PHP version and core combination change can introduce new Deprecated warnings that weren't present before. These aren't fatal, but they can corrupt WP-CLI JSON output and affect admin functionality. Check whether the error log volume has changed significantly after the upgrade compared to before.

STEP 7 — Cache purge and recheck

Caching plugins (W3 Total Cache, WP Fastest Cache, WP Super Cache) and server-level page caches can serve stale content after an upgrade. Purge them, then recheck the front end.

# Plugin cache flush — command varies by plugin
wp cache flush
wp w3-total-cache flush all 2>/dev/null
wp super-cache flush 2>/dev/null

For server-level caches (configured through the hosting control panel), use the panel's manual purge option. After purging, run the STEP 3 checks again to confirm the current version of the site is being served.

When something fails

If any step surfaces a problem, the rollback path is in W4's rollback section:

• Core problem → wp core update --version=X.X --force to revert to the previous version
• Plugin problem → wp plugin install <name> --version=X.X.X --force to roll back a specific plugin

If WP-CLI itself stops responding after a plugin change, the --skip-plugins --skip-themes rescue flag from A1 lets you start WP-CLI without loading plugins — useful for running rollback commands when the normal startup sequence is broken.

Per the halt-after-core-rollback design from A2: once core is rolled back, stop plugin updates until core is stable again. Adding more changes to an uncertain state makes subsequent diagnosis harder.

Summary

The W series in full:

"The upgrade completed" and "the site is confirmed working" are different states. W4 gets you through the first. This checklist closes the gap to the second.