A WordPress critical error usually means PHP hit a fatal condition and stopped executing before WordPress could finish the request. Do not start randomly disabling plugins in the live dashboard, especially on a WooCommerce site. First, protect orders and data, identify the failing PHP process in the error log, then isolate the specific plugin, theme, update, or server mismatch causing the crash.
The message shown to visitors is deliberately vague: “There has been a critical error on this website.” The useful detail is normally in the administrator recovery email, your PHP error log, or WordPress debug log. A fast recovery depends on reading that detail rather than treating every critical error as a memory problem.
Contain the outage before troubleshooting
If the front end is down but wp-admin still works, enable maintenance mode only if visitors are seeing broken pages or failed transactions. For a store, verify checkout, payment callbacks, and order creation before making changes. A maintenance page is preferable to a checkout that appears to work but silently loses orders.
Before editing files or updating anything else, take a database and file backup. If your host provides snapshots, confirm the restore point predates the incident. A backup is not merely a safety net here. It lets you compare what changed, test a rollback on staging, and restore quickly if a fix creates a second problem.
If WordPress sent an email titled “Your Site is Experiencing a Technical Issue,” use its recovery-mode link. Recovery mode temporarily pauses the plugin or theme implicated in the crash for your administrator session. It is useful for getting back into wp-admin, but it is not proof that the named extension is the root cause. A plugin may fail because its dependency, PHP version, database table, or theme integration changed underneath it.
Find the real WordPress critical error
Turn on logging without displaying errors to public visitors. Add or confirm these constants in `wp-config.php`, above the line that says “That’s all, stop editing!”:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );Reproduce the failure once, then inspect `wp-content/debug.log`. Also check the PHP-FPM or web server error log in your hosting control panel. Server logs are often more complete, particularly when PHP runs out of memory, a process is killed, or a fatal error occurs before WordPress initializes.
Look for the first fatal error near the matching timestamp, not just the last line in a long log. Common examples include `Allowed memory size exhausted`, `Call to undefined function`, `Uncaught Error`, `Class not found`, and a failed database query. The file path matters. An error under `wp-content/plugins/plugin-name/` is a strong lead; an error in `wp-includes/` may still be caused by a plugin passing bad data into core.
For command-line access, this is often the cleanest first pass:
wp plugin status wp theme status wp core verify-checksums wp option get active_plugins --format=jsonRun WP-CLI from the WordPress document root and as the site’s correct system user. Avoid running it as root unless your server configuration explicitly requires it. Root-created cache files and uploads regularly create permission problems that look unrelated to the original failure.
Isolate plugins, themes, and recent changes
A critical error that appears immediately after an update is usually easier to solve than one that appears under traffic. Start with the most recent change: a plugin update, theme deployment, PHP version change, new must-use plugin, code snippet, or payment gateway configuration.
When wp-admin is available, deactivate the suspected plugin and retest the exact failing page or action. Do not stop at “the homepage loads.” Test the workflow that failed: checkout, product editing, scheduled task processing, REST API requests, or a form submission.
When wp-admin is unavailable, disable a plugin with WP-CLI:
wp plugin deactivate plugin-slugWithout WP-CLI, rename the plugin’s directory through SFTP or your file manager, for example from `woocommerce-gateway-example` to `woocommerce-gateway-example.disabled`. WordPress will deactivate it when it cannot find the folder. Rename it back only after you have a compatibility plan.
If no single plugin stands out, disable all standard plugins temporarily, then reactivate them one at a time. On a production store, do this on staging whenever possible. Bulk deactivation can disable payment, shipping, caching, security, and inventory integrations at once. That may clear the fatal error while creating a business outage of a different kind.
If plugins are not the cause, switch briefly to a current default WordPress theme. A child theme with an outdated WooCommerce template, a malformed `functions.php` change, or an old page-builder hook can produce a fatal error after core or WooCommerce updates. Also inspect `wp-content/mu-plugins`. Must-use plugins do not appear in the normal Plugins screen and cannot be deactivated there.
Fix PHP version and memory failures carefully
PHP compatibility failures are common after a host upgrades PHP. The error log may show deprecated code, type errors, missing functions, or a plugin calling behavior removed in the newer version. The correct fix is usually an updated extension, not permanently downgrading PHP. A temporary rollback can restore service while you test a compatible release, but old PHP eventually becomes a security liability.
Memory errors require more diagnosis than raising a number in `wp-config.php`. You can set a WordPress-side limit such as:
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' );That only works if PHP-FPM permits those limits. More importantly, a memory exhaustion message can indicate a runaway import, recursive code, an oversized autoloaded option, an expensive page-builder request, or too many concurrent PHP workers. Increasing memory may delay the next crash while increasing server pressure.
On busy WooCommerce sites, distinguish per-request memory from total capacity. Eight PHP workers using 512 MB each can consume 4 GB before MySQL, Redis, NGINX, and the operating system are counted. High-frequency CPU helps execute PHP faster, but it does not fix inefficient queries or uncontrolled worker concurrency.
Check database, cache, and filesystem causes
A fatal error may be secondary to a failed database connection or corrupted application state. Check whether MySQL is reachable, whether the database user still has privileges, and whether disk space or inode limits are exhausted. Full disks can prevent WordPress from writing cache files, session data, logs, and database temporary tables.
Clear only disposable caches after preserving evidence. This includes page cache, object cache, transients, and opcode cache where appropriate. Do not casually delete database tables or flush Redis on a high-traffic store without knowing what other applications use the instance. A shared object cache may hold sessions, rate-limit data, or queues.
If the error began after a core update, verify core files before reinstalling anything:
wp core verify-checksums wp core download --forceA forced core download replaces WordPress core files but should not overwrite `wp-content` or `wp-config.php`. Still, take the backup first. If checksums fail repeatedly, investigate permissions, compromised files, or a deployment process that modifies core.
Prevent the next critical error
The durable fix is a controlled update path: test plugin, theme, PHP, and WooCommerce changes on staging; record versions; deploy during a low-risk window; and retain a known-good rollback point. Automatic updates are useful for many sites, but blindly auto-updating revenue-critical extensions can be the wrong trade-off when custom code and payment flows are involved.
Keep debug logging off after diagnosis. A growing debug log can consume disk space and may record sensitive paths or request details. Monitor PHP fatal errors, disk utilization, database response time, and PHP worker saturation instead of waiting for a visitor to report a white screen.
Infrastructure also sets the margin for error. Fast CPU cores, isolated resources, server-level object caching, and hourly backups will not repair broken plugin code, but they reduce timeouts, make rollback safer, and give you enough operational visibility to find the real fault. WP Tango’s managed environment is built around that practical backstop, not the fiction that every WordPress problem can be solved by installing another plugin.
A critical error is a signal, not a diagnosis. Read the log, change one variable at a time, and validate the business workflow after every fix. That discipline is what turns a temporary recovery into a stable site.
