If the site shows a critical error, white screen, or 500 response immediately after updating the WordPress core, the core itself is not necessarily faulty. Incomplete update, plugin or template incompatibility, inappropriate PHP version, lack of disk space and incomplete database migration can be revealed at the same time as the upgrade. First, keep the current state and fresh data; Then isolate the layer that is actually giving the error.
Quick answer: Take backups of files and database, match exact time of failure with PHP log, check core files for completeness and existence .maintenance and leave plugins only for controlled testing. Full restore of the store database or installation of an old version of the kernel without checking for compatibility may destroy orders and schema changes.
Before each change, log the failed domain
- Open the home page, a post,
wp-admin, login and REST API separately. - HTTP code and the latest text Keep PHP error.
- Record previous and new version of WordPress, PHP and active plugins.
- Check free disk space and inode; Incomplete replacement of files in a full disk is common.
- In WooCommerce, specify the orders registered after the last backup.
If only the management is broken, but the cached pages are opened, do not take the healthy appearance of the site to mean the healthy PHP. cache may show old response.
Is the update incomplete?
When upgrading the core, WordPress temporarily creates a .maintenance file. If the process is interrupted, the maintenance message remains. Make sure no active upgrades are running and the kernel files are complete before deleting the file. Removing .maintenance will not repair a broken package.
With WP-CLI it is possible to check the integrity of official kernel distribution files without manual comparison:
wp core version
wp core verify-checksumsThe checksum command does not evaluate wp-content files or custom files. The additional file warning should also be interpreted with the actual deployment structure. If the kernel is incomplete, redeploy the same valid version and do not touch wp-content and wp-config.php.
Find the actual error from the log
PHP-FPM, Apache/Nginx and wp-content/debug.log logs in Read the breakdown time. The first line of project code in the stack trace is usually more useful than the general message at the bottom of the trace. Do not enable error display on the public site. If you need to temporarily enable WordPress registration, WP_DEBUG_DISPLAY should be turned off.
Symptoms like Call to undefined function or Deprecated do not have the same meaning: the first one may be fatal, but an old warning is not necessarily the reason for stopping the request. Bind the severity, timestamp, and broken request together.
Controlledly test plugin and theme incompatibilities
The new core may expose deprecated API, signature, or PHP behavior that the plugin previously depended on. If the trace shows the plugin name, temporarily disable the same plugin. When the cause is unknown, disable all plugins only for a short time and then activate them one by one. Consider the store, portal, webhook, subscription, and scheduled jobs when testing.
Test the template only when a healthy and compatible default template is installed. Changing the template on production may change widgets and appearance settings; staging is the right place for reproduction. For a more detailed breakdown, see also the Plugin Update Crash Guide.
Should we roll back a previous version of WordPress?
Core rollback is not a last resort diagnostic and should not be an automatic reaction. First, check the release notes, minimum PHP, and critical plugin compatibility. If downgrade is necessary, have a backup before upgrading, recovery plan and staging test. Just replace the kernel files from the official source; Do not restore the database to the old version just for the appearance of harmony.
In a site with live data, the file and the database have two different timelines. Restoring the database can remove the user, form, order and new settings. Before each restore, the RPO must be acceptable and the way to integrate new data should be clear.
Verification steps after recovery
- Check for new PHP error and status codes.
- Test logging and saving the post or product.
- Check cron, REST API, form and email as appropriate for the site.
- Run a safe test order scenario in the store.
- Refresh cache and OPcache on purpose only after a healthy version is deployed.
Errors that make recovery harder
- Copy the complete WordPress package to
wp-content. - Give general permission such as
777. - Change PHP, template, plugins and cache settings at the same time.
- Clear logs before registering the cause.
- Leave the site on the old and vulnerable kernel after temporary rollback.
When is expert intervention necessary?
If the database upgrade is stopped, the error moves between PHP-FPM and MySQL, or the site has a live order, continuing the test on production is risky. In the WordPress technical troubleshooting service, you can check the versions, logs and deployment path simultaneously. For a specific fatal message, WordPress Critical Error Guide also completes the diagnosis path.
FAQ
Is it enough to delete.maintenance?
only when the update is finished and the file remains. If the core files are incomplete or PHP is fatal, deleting it will not fix the cause.
Why is the public site open but the management is broken?
It is possible that the page cache gives an old answer or the management path executes different hooks and queries. Check the no-cache request and the backend log.
Is it possible to turn off auto-update permanently?
Permanent shutdown creates a security risk. It is better to define staging, recoverable backup and maintenance window.
Why is there still an error after rollback?
It is possible that the database has been migrated, OPcache has kept the previous code, or the main cause is the plugin and PHP. Measure the file, schema and cache separately.