Most WordPress errors are one of a small number of failures wearing different clothing. A white page, a 500, a database connection error and "briefly unavailable for scheduled maintenance" have different causes, but the diagnosis always starts the same way: find out what the server actually said, rather than what the browser chose to show you. This guide covers the errors you are most likely to meet, in the order of how often they occur, and each one starts with how to see the real message.
First: make WordPress tell you what went wrong
A blank white page is not an error message. It is WordPress failing before it could print one. Turn on error logging and the blank page usually becomes a single line naming the exact file and line number, which turns an afternoon of guessing into a two-minute fix.
Add this to wp-config.php, above the line that says to stop editing:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY set to false is important on a live site: errors go to wp-content/debug.log instead of appearing on the page for visitors. Reload the broken page, then read that file; the last entry is almost always the cause.
Turn all three back off when you are finished. Leaving debug logging on indefinitely grows the file without limit and can expose paths if the display setting is ever flipped.
The white screen of death
A completely blank page means PHP stopped before producing output. With the debug log on, you will normally see either a fatal error naming a file, or a memory exhaustion message.
If it names a plugin file, that plugin is the cause. You cannot deactivate it from the dashboard if the dashboard is also blank, so rename its folder inside wp-content/plugins over SFTP or File Manager, adding -off to the end is enough. WordPress cannot find the plugin, treats it as deactivated, and the site returns.
If it names a theme file, switch themes the same way by renaming the active theme's folder. WordPress falls back to a default theme. The site will look wrong, and it will load, which is what you need to work.
If the log is empty and the page is still blank, the failure happened before PHP could write anything. A syntax error in wp-config.php after a manual edit is the classic case. Restore that file from a backup.
Memory limit exhausted
The message names a byte count and a file. The file is usually innocent. It is simply the code that happened to be running when the last available memory was used, so do not assume that plugin is at fault.
Raise the limit in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
If nothing changes, the ceiling is being set below that at the server level and WordPress cannot raise it past that point. That is a hosting-side setting rather than something to fight in application code.
Treat repeated memory exhaustion as a symptom, not a problem to be raised away. A site that needed 128M last month and needs 512M today has usually acquired a plugin doing something expensive, and raising the number hides that until it stops working again.
Error establishing a database connection
This one is unambiguous: WordPress could not reach the database. There are only a few causes.
The credentials in wp-config.php no longer match, typically after a migration where the database user was recreated with a different name. Check DB_NAME, DB_USER, DB_PASSWORD and DB_HOST against what exists in cPanel. On Ahosting DB_HOST is localhost.
Or the database user exists but has not been added to the database with privileges, which happens easily when a database is created by hand. Adding the user to the database in cPanel fixes it.
Or the database server is genuinely down or overloaded, in which case other sites on the account will fail at the same time. That is a support ticket, not a configuration problem.
A corrupted table is rarer and produces a slightly different message that mentions repair. WordPress can attempt a repair if you temporarily enable it:
define( 'WP_ALLOW_REPAIR', true );
Visit /wp-admin/maint/repair.php, run the repair, then remove that line immediately: the page is deliberately accessible without logging in while the constant is set.
500 internal server error
A 500 is the web server saying something failed without saying what. The debug log is often empty for a 500, because the failure can happen before PHP starts.
The most common cause is a broken .htaccess file. Rename it to .htaccess-old and reload. If the site comes back, regenerate the rules by opening Settings then Permalinks in the dashboard and saving without changing anything.
If that is not it, the host error log is the place to look, not the debug log. Understanding cPanel error logs goes over where it lives and how to read it.
Briefly unavailable for scheduled maintenance
WordPress writes a file named .maintenance in the site root while it updates, and deletes it when finished. If an update is interrupted, the file stays and every visitor sees the maintenance notice forever.
Delete .maintenance from the site root. The site returns immediately. Then check whether the interrupted update actually completed, go to Dashboard then Updates and re-run anything still listed, because a half-applied update leaves mismatched files.
Locked out of wp-admin
If the front end works and only the admin area fails, it is usually a plugin. Rename the whole wp-content/plugins folder to plugins-off, which deactivates everything at once and lets you log in. Rename it back, then reactivate plugins one at a time until it breaks again.
If you cannot log in because of the password instead of an error, reset it directly in the database through phpMyAdmin. Managing MySQL databases with phpMyAdmin goes into getting in; the value goes in the user_pass column of wp_users, and you must select MD5 in the function dropdown so WordPress can read it.
Too many redirects
The browser gives up after a loop. Nearly always this is a mismatch between the site URL and what the server is doing, WordPress set to http:// while the server redirects everything to https://, so each one sends the visitor back to the other.
Set both values to the same scheme in wp-config.php, which overrides whatever is stored in the database:
define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );
Be consistent about www as well. Half the redirect loops in existence are a site set to the bare domain behind a rule that forces www.
Rules that make all of this faster
- Read the log before changing anything. Guessing costs more time than reading.
- Change one thing, then reload. Two changes at once means you learn nothing.
- Take a copy before editing
wp-config.phpor.htaccess. - Renaming a folder is a safe, instant way to disable a plugin or theme.
- If several unrelated sites broke at once, it is not your code.
If a site is erroring under traffic rather than constantly, the cause is usually resource exhaustion instead of a bug. Optimizing WordPress performance walks through that pattern and how to tell the two apart.
If the error is that you cannot reach the admin area at all, How to Recover When You Are Locked Out of WP Admin works through the causes fastest-first.
The database connection error has its own set of causes, and the exact wording names the fix. See How to Fix Error Establishing a Database Connection.
A blank page with an allowed-size line in the log is a different problem from a fatal error. How to Fix the WordPress Memory Limit Error picks it up from there.
When the error does not name a culprit, halving the plugin list finds it in about five checks rather than thirty. How to Find Which Plugin Is Causing a Problem deals with the method.
A white screen is not an absence of information. The error exists and is simply not being shown. How to Debug WordPress with WP_DEBUG and Logs walks through writing it to a file instead.
If the site is not merely broken but gone, the first instruction is to stop and change nothing. For what to do instead, see How to Recover a WordPress Site with No Backup.