WordPress Troubleshooting: How to Fix Critical Errors, 500 Errors and More

Most WordPress errors come from a small number of causes: a plugin or theme conflict, a PHP error, a corrupted configuration file, a database connection problem or a server limit. The messages look alarming, but the fixes usually follow the same pattern: find out what changed, read the actual error, and isolate the component that caused it.

Start with this question: what changed just before the problem began? An update, a new plugin, a PHP version change, a host migration or edited code explains the large majority of cases. If you know what changed, you can often undo it in minutes.

WordPress also helps more than it used to. Since WordPress 5.2, a fatal error triggers an email to the site's admin address with a special recovery mode link, so you can log in with the broken plugin or theme paused. Since 6.6, a plugin auto-update that causes a fatal error is rolled back automatically.

This guide walks through the most common errors, how to debug safely, and how to find plugin conflicts without making things worse on a live site.

Before you start: protect the site

1. Back up first, if the site allows it. Even a broken site's files and database can be copied through your host or SFTP. See our WordPress backups guide.
2. Get access outside WordPress. You will need SFTP or your host's file manager, and ideally database access (phpMyAdmin or similar). If WordPress is down, the dashboard will not help.
3. Work on staging when possible. If the live site still works but something is wrong, reproduce it on a staging site rather than experimenting on live.
4. Change one thing at a time, and write down what you changed so you can undo it.

Quick reference: common errors and first fixes

These match the advice in the official common WordPress errors documentation.

"There has been a critical error on this website"

This message replaced the old blank white screen for many fatal errors. It means PHP hit an error it could not recover from, usually in a plugin or theme.

Use recovery mode

When a fatal error happens, WordPress emails the site's admin address (and the network super admin on multisite) with details of the error and a secret link. Clicking it starts recovery mode, a session in which the plugin or theme causing the error is paused for you only, so you can log in to the dashboard. From there you can deactivate, update or replace the faulty extension. Visitors still see the error until you fix it.

If the email never arrives, check spam, then confirm the admin email under Settings > General once you get access. Sites that cannot send email at all should have a mail delivery plugin or service configured; otherwise this safety net does not work.

If recovery mode is not available

Turn on the debug log (next section) to see the exact error, or deactivate plugins over SFTP as described below.

Debugging safely with WP_DEBUG

WordPress has built-in debugging constants that you set in wp-config.php. The official debugging documentation warns that WP_DEBUG and the other debug tools are not recommended on live sites; they are meant for local and staging installs. If you must debug production briefly, log errors to a file and do not display them on screen. A safe set of lines, placed above the "That's all, stop editing!" comment:

• define( 'WP_DEBUG', true ); turns on debug mode.
• define( 'WP_DEBUG_LOG', true ); writes errors to wp-content/debug.log by default.
• define( 'WP_DEBUG_DISPLAY', false ); stops errors from printing into pages. The default is true, which is why you set it explicitly.

Reproduce the problem, then open debug.log. Fatal errors name the file and line. A path like wp-content/plugins/plugin-name/ tells you exactly which plugin failed.

Two cautions:

• The default debug.log location is inside the web root, and log files can contain file paths and other details useful to attackers. Turn debugging off and delete the log once you are done, or point WP_DEBUG_LOG to a path outside the web root.
• Do not leave debug mode on. Besides the security exposure, the log can grow large over time.

Your host's PHP error log and web server error log are also worth checking, especially for 500 errors that happen before WordPress loads.

Finding plugin and theme conflicts

A conflict happens when a plugin, theme or custom code breaks because of another component, a WordPress update or a PHP change. To find it:

If you can reach the dashboard

1. Switch to a default theme such as Twenty Twenty-Five (the current bundled default as of October 2026). If the problem disappears, the theme is involved.
2. Deactivate all plugins. If the problem disappears, reactivate them one at a time, checking after each, until it returns. The last plugin activated is the trigger, though the real cause may be its interaction with another one.

On a live site this disrupts visitors. Do it on staging when you can. The Health Check & Troubleshooting plugin from WordPress.org offers a "troubleshooting mode" that disables plugins and uses a default theme only for your user session. Note that as of October 2026 its directory listing shows it was last tested with WordPress 6.6, so try it on staging first.

If you cannot reach the dashboard

1. Connect by SFTP or the host's file manager.
2. Rename wp-content/plugins to plugins_old. WordPress deactivates every plugin it can no longer find.
3. If the site loads, rename the folder back to plugins, then rename individual plugin folders one at a time to find the culprit.
4. To rule out the theme, rename the active theme's folder. WordPress falls back to a default theme if one is installed.

Once you know the cause, check for an update, read the plugin's support forum, or replace it. For deeper development issues, see our post on common WordPress development errors.

500 Internal Server Error

A 500 error is the server saying something failed without saying what. Work through these in order:

1. .htaccess: on Apache servers, the official docs name a corrupted .htaccess file as the most likely cause. Rename it to .htaccess_old. If the site loads, go to Settings > Permalinks and click Save to generate a fresh one.
2. Plugins and theme: isolate them as described above.
3. Memory and limits: check the server error log for memory or timeout messages.
4. File permissions: incorrect permissions after a migration can cause 500s. Your host can reset them.
5. PHP version: if the error started after a PHP change, switch back and test compatibility. See our WordPress PHP versions guide.

"Error establishing a database connection"

WordPress cannot reach its database. Check these:

1. Credentials: open wp-config.php and confirm DB_NAME, DB_USER, DB_PASSWORD and DB_HOST match what your host shows. This often breaks after a migration or a password change.
2. Database server: if the details are right, the database server may be down or overloaded, or you may have hit a quota. The official docs suggest contacting your host.
3. Corrupted tables: if the front end shows the error but the admin asks you to repair the database, WordPress has a built-in repair tool enabled with WP_ALLOW_REPAIR. The repair page works without logging in, so remove the constant as soon as you finish.

If this error appears together with spam pages, unknown admin users or redirects, treat it as a possible hack. See our guide to a hacked WordPress site.

Other errors you may see

Stuck in maintenance mode

During updates WordPress creates a .maintenance file in the site root. If the update is interrupted, the file stays and visitors see "Briefly unavailable for scheduled maintenance." Delete the file, then check that the update completed and re-run it if needed.

Memory exhausted

The message "Allowed memory size of ... bytes exhausted" means PHP ran out of memory. You can raise WP_MEMORY_LIMIT in wp-config.php, but only up to the limit your host allows. If a single plugin uses enormous memory, fix that rather than raising limits indefinitely.

Login loops and redirects

Repeated redirects to the login page often come from wrong site URLs after a migration, cookie or caching issues, or HTTPS settings. Check the WordPress Address and Site Address values, clear caches and cookies, and check any security plugin's login protections.

Site looks broken but no error

Missing styles or broken layouts usually point to caching, a CDN serving old files, or a page-builder or theme update. Clear every cache layer first.

Preventing the next emergency

• Keep automatic backups running and test a restore occasionally.
• Test major updates on staging. Our guide to WordPress updates covers a safe routine.
• Remove plugins you do not use.
• Make sure the admin email address is monitored and the site can send email, so recovery mode messages reach you.
• Monitor uptime so you hear about problems before customers do.

Conclusion

Most WordPress errors yield to the same method: find what changed, read the real error in a log, isolate plugins and the theme, and fix one thing at a time. Use recovery mode when you get the email, debug with logging rather than on-screen errors, and keep backups ready. For more guides, see our WordPress hub. If a problem is beyond a quick fix, eSEOspace's website maintenance services include troubleshooting and repair.

Frequently asked questions