Fix WordPress errorsNarrow down white screens, 500 errors and database errors systematically

Published on October 20, 2026

First rule: do not rush

Before you change anything, two steps:

1. Take a backup - even of the broken state. That sounds absurd, but it matters: if a repair attempt makes things worse, you at least want to get back to where you started. The Plesk backup manager does that in a few minutes.
2. Write down what happened last. An update, a new plugin, a changed setting, a PHP version change? In the vast majority of cases, that is exactly where the cause lies - and the search becomes much shorter if you start with the last intervention instead of a general troubleshooting session.

Important to know: we do not create automatic backups for you. A backup only exists if you have created it.

Switch on the debug log

A white page is so unpleasant because it reveals nothing. That can be changed: WordPress can write errors to a file instead of swallowing them. Open wp-config.php in the document root - via FTP or via the file manager in Plesk - and enter above the line with /* That's all, stop editing! */:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

The third line is the decisive one: it makes sure the messages are not visible to visitors, but only end up in the file wp-content/debug.log. Then open the faulty page once and open the file - the last line names the file and line number where it gets stuck. Usually, the name of the offending plugin is already in the path.

In addition, it is worth looking at the server logs: in Plesk, under Logs, you will find the web server's error log, which contains something even when WordPress itself no longer starts at all.

White screen or "critical error"

Both are the same problem in two presentations: a PHP error aborts execution. In the overwhelming majority of cases, the cause is a plugin or a theme - and this is how to narrow it down:

1. Switch off all plugins at once. If you can still get into the backend, do it there. If not: rename the directory wp-content/plugins to plugins-off via FTP. WordPress then finds no extensions and deactivates all of them.
2. Check the site. If it runs again, it was a plugin. Rename the directory back - all plugins are now deactivated but present.
3. Switch them back on one at a time and open the site after each step. The plugin with which the error returns is the culprit.
4. If the error remains even without plugins, it is the theme. Switch to a default theme as a test, such as Twenty Twenty-Four.

Once you have found the culprit, the solution is usually an update - or, if the plugin has not been maintained for years, a replacement. A plugin that no longer runs with a current PHP version will cause problems in the future too.

500 Internal Server Error

The 500 is not a WordPress error in the narrower sense, but the web server's message that the request could not be processed. The three most common causes:

• Faulty .htaccess. Rename the file as a test. If the site is reachable afterwards, that was it - let WordPress create a new one under Settings > Permalinks by simply saving there. More on this in the guide .htaccess & redirects.
• Memory exhausted. Enter in wp-config.php:
  define('WP_MEMORY_LIMIT', '256M');
  If that is not enough, the memory limit can also be raised in the domain's PHP settings.
• Damaged core files. After an aborted update. Download a fresh WordPress copy and completely replace the directories wp-admin and wp-includes - your content lives in wp-content and in the database and remains untouched.

Error establishing a database connection

This message is unambiguous: WordPress cannot reach its database. Check in order:

1. Credentials in wp-config.php. Database name, user and password must match exactly what is stored in Plesk under Databases. The host there is usually localhost.
2. Password changed recently? A database password newly set in Plesk must also be entered in wp-config.php - that does not happen automatically.
3. Does the database exist? Open phpMyAdmin from Plesk and check whether the tables are really there. After an incomplete move, they are occasionally missing.

If the error only occurs intermittently while the site otherwise runs, that points more to an overloaded application than to wrong credentials - then the guide Speed up your website is worth a look.

Further common error patterns

Prevention: test on a copy

Most of these errors occur with updates - and can be avoided by not trying updates out on the live site. The WordPress Toolkit in Plesk brings everything you need for this:

• Cloning. A complete copy of the site, usually on a subdomain. There, you apply the update and see whether something breaks.
• Automatic updates. Can be set separately for core, plugins and themes. Applying core security updates automatically is the right choice in almost all cases.
• Security check. Checks the installation against a list of known vulnerabilities and hardens it on request.

And the basic rule that replaces all others: a backup before every major update. Two minutes beforehand can save you a whole evening afterwards - the setup is described in the guide Create & restore backups.

Frequently asked questions