Fix WordPress Technical Difficulties and Critical Errors

For a WordPress critical error, first check the recovery email and the server error log, then reverse the smallest change that explains the failure. If you have no email or cannot open the dashboard, use the hosting panel or SFTP to collect the error and isolate the named component. Preserve the current database before restoring anything on a site that takes orders or bookings.

The older “The site is experiencing technical difficulties” screen, the newer critical-error message and a blank white page are symptoms. They do not tell you whether the cause is a plugin, a theme, a failed update, memory exhaustion or a server problem. WordPress documents both critical errors and white screens; the next useful evidence is the underlying error and when it began.

Choose the recovery route you can actually use

If the browser shows a database connection error, a hosting suspension or a gateway error, include that exact message. A 502 or white screen alone is not proof of a plugin conflict.

1. Preserve the current state and record the trigger

Write down the time and timezone, affected URL, whether /wp-admin/ works, and the last known change. Useful triggers include a plugin update, a snippet edit, a PHP switch, a large import or a hosting migration. Take a screenshot without exposing customer details.

Ask the host to preserve a current file and database snapshot before making changes. Keep the last working backup as well. Record one change at a time so that you can connect a result to an action.

If the site accepts orders, protect the order history

An old database backup represents an old business state. Restoring it over production can remove orders, accounts, form entries and stock changes received since that backup. Payment activity can also exist at the payment provider even when a website request failed.

WooCommerce’s backup guidance distinguishes website files from the database that holds store data. Before a restore, ask the developer to record the newest orders and payment events, preserve the current database, and decide how recent transactions will be retained or reconciled. An XML content export is not a complete store backup.

Do not attempt to preserve orders by copying only the WordPress posts tables: WooCommerce HPOS can use dedicated authoritative order tables. If an update changed a database schema, a file-only rollback also needs compatibility review. WooCommerce warns about mismatched versions and database state.

A narrow code or configuration repair may avoid a full database restore. For a store with uncertain payment status, agree whether to pause new checkout attempts while investigating, and reconcile existing attempts before asking customers to retry.

2. Use Recovery Mode when the email arrives

Check the administration email account, spam folder and hosting mail logs. Follow the recovery link only after checking that it belongs to your website. Keep the link private, then log in with your normal authorized account.

In Recovery Mode, record the component name and error notice. A paused component is paused for the recovery client, so the dashboard loading does not establish that visitors can use the website. WordPress’s Recovery Mode documentation explains this session scope.

Choose a fix appropriate to that component: correct a recent code edit, apply a maintained compatible release on staging, or deliberately deactivate it if the site can function without it. Deactivating a payment, membership or booking plugin affects the service it provides. Test those consequences before reopening the affected journey.

Exit Recovery Mode and test in a separate logged-out browser session. WordPress’s fatal-error recovery explanation distinguishes a component paused for recovery from a normal deactivation that affects the whole site.

3. No recovery email or no admin access: get the private log

A missing email does not mean WordPress found no error. Delivery can fail, the address can be outdated, or the failure can occur outside the part of a request that supports recovery. Start with the host’s PHP error log for the exact timestamp. It may contain the evidence without any configuration edit.

If more logging is needed, have the host supply an absolute, writable path outside the web document root. Back up wp-config.php, edit its existing definitions rather than adding duplicates, and place the temporary settings before WordPress loads:

// Replace this path with a private, writable path supplied by your host.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/private/path/wordpress-error.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );

Use straight quotes in a plain-text editor. Do not paste a complete replacement wp-config.php over the site’s database credentials and keys. Our wp-config generator can help explain individual options; it does not know your production configuration.

WordPress’s debugging reference supports a custom log path and hidden error display. Reproduce the failing action once, record its time, then restore the previous debug settings. Read the relevant entries through the host or SFTP. Retain only what is needed under your normal log policy.

Logs can contain filesystem paths, submitted data and other private information. Send a redacted excerpt privately to the maintainer instead of publishing a full log. If no entry appears, ask the host whether PHP starts successfully, the path is writable, and the failure is in a web-server or worker log instead. A log in wp-content is not private merely because it is called debug.log.

4. Match the evidence to the smallest reversible action

These are diagnostic routes, not automatic fixes for every error. The file named by a fatal error is where execution failed; it may be calling a missing dependency rather than being the original cause.

Deactivate one identified ordinary plugin

If you have SFTP or a hosting file manager and the log identifies a normal plugin, record its exact directory name. Temporarily rename only that directory, for example:

wp-content/plugins/example-plugin
    becomes
wp-content/plugins/example-plugin.disabled

Keep a note of the original name. Request the failing page again and check the log. If the same error continues, stop broad changes and collect the new evidence. Renaming a directory does not run an uninstall, but the plugin’s functionality is unavailable while its code cannot load.

Do not start by deleting the plugin, renaming all of wp-content, or editing serialized database options. After restoring the directory name, check the plugin’s activation state in the dashboard rather than assuming it is active. WordPress describes folder renaming as a fallback when administrative access is unavailable.

For a developer with WP-CLI, the equivalent targeted operation can be:

wp --path=/absolute/path/to/wordpress --skip-plugins --skip-themes plugin deactivate example-plugin

Replace the path and slug first. The WP-CLI command reference documents plugin deactivation and bootstrap flags. --skip-plugins does not skip must-use plugins. A network-activated plugin, must-use plugin or drop-in such as object-cache.php needs a separate host or network-admin assessment; an ordinary plugin command is not a universal bypass.

If the failing component is the active theme, correct the last edit or test a switch to an installed compatible theme on staging. Do not remove the only working theme or assume a switch preserves the current site’s templates and functionality.

5. If this started after a PHP update

Compare the active web PHP version and extensions with the previous configuration. A shell’s php -v can describe a different runtime. If admin works, use Tools → Site Health → Info → Server and compare it with the domain’s hosting settings.

Our PHP Version Checker reports public clues when available; it cannot establish private package revisions. The PHP Upgrade Readiness Checker helps structure the application checks. Use the WordPress PHP recommendation and extension guide to investigate the specific compatibility gap.

Do not restore an old, vulnerable PHP build as a default recovery step. Ask the host to confirm the security update or vendor backport on any alternative runtime. The current PHP security notice explains why changing a branch and applying its security fixes are separate decisions. PHP’s release archive is the upstream source for those notices.

Recent PHP security releases also introduced hard memory termination behavior. A worker that hits a hard limit may exit before WordPress can write its usual shutdown log or send recovery mail. Ask the host to inspect worker stderr when relevant; PHP documents that distinction.

6. Prove recovery outside the dashboard

After the repair, exit Recovery Mode and check the original failing action in a logged-out session. Test the functionality of anything you temporarily disabled, plus login, forms and their delivery, editing and scheduled work. For a store, include cart, checkout, payment callbacks, order status, emails and inventory using an agreed test method.

Read new logs at the test timestamps. Confirm that new orders and customer changes remain present. Restore temporary debugging settings, retain the change record, and monitor the affected workflow. A homepage returning successfully does not prove that a checkout or background task recovered.

Download the recovery handoff checklist to collect the symptoms, current-state backup, change and acceptance checks in one place.

Get help recovering the site

Send the site address, the time the problem began, the last known change and a redacted error excerpt. Our Website Fix Sprint can cover an agreed repair priority after assessment; live-store recovery, legacy code and suspected compromise may need a different scope.

If a PHP change caused the failure, see the WordPress PHP update service for host coordination and post-update checks. Compatibility repairs are assessed separately. We confirm the scope, price and timeline before starting.

Get help with my WordPress error