On this page
WordPress core, plugins and themes need regular updates, but a live change can break a payment flow, page builder or custom integration. A production update therefore needs a recoverable backup, compatibility review and functional test. This guide describes a staged workflow for a self-hosted WordPress site. Do not treat it as a reason to update every component simultaneously or to remove a plugin without checking what the site uses.
Prerequisites and change inventory
Identify the current WordPress, PHP, database, theme and plugin versions. Record which components are business-critical: checkout, forms, membership, multilingual pages, caching and email. List custom code and the person who maintains it. Confirm access to the hosting control panel, SFTP or deployment system and database backup. Test that the backup can restore into an isolated environment before touching the live site.
wp core version
wp plugin list --format=table
wp theme list --format=table
These read-only WP-CLI examples assume it is installed and run from the intended site directory. Verify the current path and site URL first. WP-CLI output may include internal plugin names and versions; share it only with authorized maintainers. If the host uses a managed WordPress service, follow its supported snapshot and update workflow instead of forcing WP-CLI onto it.
Build a restore point that covers the whole site
Back up the database and wp-content media, themes and plugins through the supported tool. Record backup time and checksum, storage location and the operator who can restore it. A file-only backup misses posts, orders and settings; a database-only backup misses uploads and custom code. For a busy WooCommerce site, consider orders placed during the update window and whether restoring the database would erase legitimate transactions. Reconcile payment records before any production rollback.
Create or refresh a staging copy with outbound email and payment actions disabled. Use a safe URL and noindex controls so search engines do not index the copy. Protect staging with authentication. Test the update there first, including PHP compatibility and the theme's key templates.
Update in a controlled sequence
Review changelogs and compatibility notes. Update one dependency group at a time in staging, test it, and capture the exact versions. Avoid updating core, every plugin, the theme and PHP all in one unexplained operation. WordPress documents both one-click and manual core update processes; choose the method supported by your host. Before production, announce the maintenance window and freeze content changes where practical.
If you use WP-CLI, the following is an illustration of an impactful operation, not a command to run during reading:
wp core update
Apply only after reviewing the target version and rollback plan. Check whether the update also requires a database upgrade, which can complicate code-only rollback. Keep an administrator session open and monitor error logs. Do not disable all security plugins or firewall policies to make an update complete.
Validate the customer journey
After an update, open the homepage, a representative article and the most important forms. For commerce, verify product pages, cart, checkout flow in a safe test mode, order emails and payment-webhook status without making a real charge. Check mobile layout and logged-in behavior. Review PHP errors, WordPress debug logs (if safely configured) and cache behavior. A successful “update complete” banner does not prove that the site works.
If a regression appears, identify which component changed. Restore files or the previous deployment artifact if the database is compatible. If database rollback is needed, assess transactions created after the backup; do not silently erase orders. Follow the host's tested restore procedure and document the incident.
Troubleshooting and maintenance
A site stuck in maintenance mode may indicate an interrupted update; investigate the update log and active process before removing .maintenance. A plugin conflict should be reproduced in staging, not solved by disabling all plugins in production. If a cache shows old assets after a successful update, invalidate the appropriate layer while preserving user sessions and checkout state. Monitor scheduled tasks and backup jobs after the update, not just the visible page.
FAQ: Should plugins auto-update? It depends on risk, support and your rollback ability; WordPress supports auto-updates, but critical sites still need monitoring. FAQ: Can a snapshot alone protect WooCommerce orders? Only if you account for orders and payments after the snapshot. Expected result: supported components are current, key workflows pass and a tested restore path remains available.
Related reading: WordPress cache troubleshooting and Linux backup planning. East4Serv managed hosting support can help plan safe releases.
Primary references: https://wordpress.org/documentation/article/updating-wordpress/ and https://wordpress.org/documentation/article/plugins-themes-auto-updates/.