A staging homepage that loads is weak update evidence. The test copy must match production runtime and exercise the features owned by the updated component, including saves, cron, email and integrations.
Build acceptance criteria before clicking Update. That prevents the absence of an obvious error from being mistaken for success.
Create a safe staging copy
Copy current production files/database with access controls. Disable indexing, production email, payments, webhooks and destructive external APIs.
Sanitise personal data where feasible and restrict staging users. Do not expose a cloned customer database on a public subdomain.
Record copy time because new production changes will not exist in staging.
Match the runtime
Use the same PHP version/extensions, MySQL/MariaDB, web server, WordPress configuration, cache and relevant DNS/SSL proxy path.
Parity checklist:
WordPress/core
active theme/plugins
PHP handler/limits
database storage/schema
cron
object/page cacheDocument unavoidable differences such as gateway sandbox.
Account for production data drift
Staging ages immediately after cloning. Record configuration/content changes made in production during testing and decide whether they affect compatibility.
Before deployment, compare component versions, PHP, theme, must-use plugins, drop-ins and relevant options again. Do not copy the staging database back to production to carry an update; that overwrites newer business data. Deploy code/config changes through the approved path and let only documented migrations run.
Include security and privacy checks
Verify the update does not broaden REST endpoints, file access, roles or administrator capabilities. Test anonymous access to private pages and confirm logs contain no new secrets.
Review consent and external requests when the release adds scripts/services. A functional update that bypasses permissions or privacy is not ready.
Preserve rollback material
Back up staging before update and retain exact old/new packages. Record database table counts and component schema versions where available.
Test restore of files and database on staging. A backup’s green status is not proof it can recover the site.
Keep the production rollback boundary narrow: code package versus database.
Read release information
Review changelog, minimum PHP/WordPress versions, security notes, removed functions and database migrations. Check dependency plugins and theme template overrides.
For major version jumps, test intermediate upgrades if the vendor requires them.
Do not rely solely on automatic compatibility scanners.
Apply one change at a time
Update the target component and allow documented migrations to finish. Capture PHP, browser, database and scheduled-action errors.
Avoid combining PHP, WordPress, theme and several plugin upgrades in one test; failure attribution becomes ambiguous.
Clear OPcache/generated assets only at the correct point, then test again after page cache warm-up.
Run feature-specific acceptance
Test login, roles, editor/save, media, search, navigation, REST/AJAX, cron and email. Exercise the updated plugin/theme’s exact business path.
For each test record:
input/state
expected outcome
observed outcome
log/request reference
pass/failInclude mobile, anonymous and logged-in behaviour where relevant.
Test failure and rollback
Simulate a safe failure path: invalid input, API unavailable or cancelled operation. Confirm errors are understandable and partial work is recoverable.
Roll back the component on staging and verify current data remains. If database downgrade fails, production needs a stronger maintenance/restore/merge plan.
Do not discover rollback incompatibility during the live outage.
Define a deployment decision gate
List blocking failures, acceptable known issues, approver and rollback threshold. A failed critical test cannot be waived by an unrelated successful homepage check.
Record exact package checksums and the window. If production crosses the threshold—new fatal, save failure or feature outage—execute the rehearsed rollback instead of debugging indefinitely in public.
Deploy with observation
Schedule production around business risk, take a fresh backup and apply the same tested package/procedure. Run smoke tests immediately.
Monitor PHP fatals, HTTP errors, cron and feature metrics through a representative period. Recurring care should preserve this acceptance suite and run it after every relevant release; staged evidence turns updates from guesswork into controlled change.