WordPress errors range from cryptic (“Cannot modify header information”) to alarming (“Error establishing a database connection”) to invisible (white screen of death). Most have a small number of causes you can identify and fix in minutes — if you know what the message means. This guide translates the common ones into plain English with the fixes that actually work.
Enable debugging first
Before troubleshooting, enable WP_DEBUG_LOG to capture errors in a file. Edit wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Errors now log to /wp-content/debug.log. Full debugging guide.
Always set DEBUG_DISPLAY to false on production. Errors visible to visitors leak paths and security info.
“White Screen of Death” — blank page, no error
Site shows completely blank page with no error message. PHP fatal error with display_errors off.
Common causes:
- Memory limit exceeded.
- Plugin or theme PHP error.
- Corrupted core files.
- Broken plugin update.
Fixes:
- Enable debug log; reload page; check what error appears.
- Disable all plugins (via cPanel File Manager, rename /wp-content/plugins to /plugins-temp). If site loads, plugin is the culprit. Restore directory; deactivate plugins one at a time to find the offender.
- Switch to default theme (Twenty Twenty-Four). If site works, your theme is the issue.
- Increase memory limit. Add to wp-config.php:
define('WP_MEMORY_LIMIT', '512M'); - Last resort: restore from JetBackup.
“Error establishing a database connection”
WordPress can’t reach its database.
Common causes:
- Database credentials wrong in wp-config.php.
- Database server down.
- Database corrupted.
- MySQL hit connection limit.
Fixes:
- Verify wp-config.php database credentials match what cPanel → MySQL Databases shows.
- Try logging into phpMyAdmin with same credentials. If you can’t, credentials wrong or database doesn’t exist.
- If credentials right, run WordPress’s auto-repair: visit yoursite.com/wp-admin/maint/repair.php.
- Check /tmp directory isn’t full (rare but causes MySQL to fail).
- If still broken: ticket support — server-side issue.
“Allowed memory size of X bytes exhausted”
PHP ran out of memory mid-execution.
Fix immediately:
Add to wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
For backend (admin):
define('WP_MAX_MEMORY_LIMIT', '512M');
If WP_MEMORY_LIMIT doesn’t help, server PHP memory_limit needs raising. MultiPHP INI Editor.
Investigate cause:
- Specific plugin causing memory bloat — Query Monitor reveals.
- Image import / WooCommerce bulk operation — temporarily raise limit, may not need permanently.
- Plugin memory leak — find newest installed plugin; disable and test.
“500 Internal Server Error”
Catch-all error meaning “something broke.” Need to look at error logs.
Common causes:
- .htaccess syntax error.
- PHP fatal error.
- File permissions wrong.
- ModSecurity rule blocking request.
Fixes:
- Check cPanel error log: cPanel → Metrics → Errors. Most recent line usually identifies the cause.
- Recently edited .htaccess? Restore old version or temporarily rename it; if site loads, .htaccess has bad syntax.
- Check file permissions: folders 755, files 644, wp-config.php 600.
- Recent plugin install/update? Deactivate to test.
“Cannot modify header information – headers already sent”
PHP tried to set HTTP headers after content already started sending.
Common cause: Extra whitespace at start or end of PHP file. Usually wp-config.php or functions.php has a blank line before <?php or after closing ?>.
Fix: The error message tells you which file. Open it. Remove whitespace before <?php; remove the closing ?> at end of file (PHP doesn’t require it).
“Briefly unavailable for scheduled maintenance”
WordPress is stuck in maintenance mode. Usually happens when a plugin/theme update was interrupted.
Fix: cPanel File Manager → site root → delete the file .maintenance (might be hidden, show hidden files first). Site comes back up.
“There has been a critical error on this website”
WordPress 5.2+ fatal error handler. WordPress emails the admin with recovery link.
Fix:
- Check admin email for “Your Site is Experiencing a Technical Issue” — contains recovery mode link.
- Click the link, login. WordPress enters recovery mode showing what’s broken.
- Usually a plugin’s recent update. Deactivate the culprit.
- If you don’t have email access, use cPanel File Manager to rename the plugin’s folder — WordPress auto-deactivates it.
“404 Not Found” on subpages (home works)
Home page loads but every other page shows 404.
Common cause: Permalinks broken. Usually after migration or .htaccess issue.
Fix:
- WP Admin → Settings → Permalinks → click Save Changes without changing anything. Regenerates .htaccess rules.
- If still broken, edit .htaccess and add standard WordPress block:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
“Failed to open stream: Permission denied”
PHP can’t read/write a specific file due to permissions.
Fix: The error message names the file. Check its permissions in cPanel File Manager. Folders should be 755; files 644; wp-config.php 600 (or 644).
“Maximum execution time exceeded”
A script ran past the time limit (default 30 seconds).
Fix: Raise via MultiPHP INI Editor or .user.ini:
max_execution_time = 300
If it keeps happening: a script is doing too much synchronously. Should be cron-based.
Common questions
“Where do I find error logs in cPanel?” cPanel → Metrics → Errors. Also /public_html/error_log file. Logs guide.
“I see an error but can’t log into WP admin to fix it.” Use File Manager via cPanel to deactivate plugins (rename folder), restore backup, or edit wp-config.php directly.
“Restored from backup but error keeps coming back.” Restoration didn’t include offending file, or cause is server-side. Ticket support.
“Error only happens for some users, not me.” Could be: cached old broken version, user-specific data issue, browser/region issue, plugin behaving differently for logged-in vs logged-out. Test from incognito browser or different network.
“How do I know which plugin caused the error?” Either check recent installs/updates, or systematically deactivate half at a time until error stops, then narrow down.
What’s next
- Debugging deeper: Error logs guide.
- Maintenance to prevent issues: WordPress maintenance.
- Memory tuning: PHP settings.
- Restore from backup: JetBackup.
Most WordPress errors fall into the categories above. The pattern is consistent: enable debug log, identify offender (usually a plugin), deactivate or fix, verify resolved. JetBackup is your safety net if fixes go sideways. Knowing what each error message means turns 30-minute panic sessions into 5-minute targeted fixes.
Was this helpful?
Thanks for your feedback!