Common WordPress Error Messages and How to Fix Each One

WordPress errors tend to arrive straight after something changed. You updated a plugin, moved host, pasted a snippet into functions.php or let PHP upgrade itself, and now the site shows one line of text where your homepage used to be. That line is usually vague on purpose, because WordPress hides the technical detail from visitors.

This guide covers the messages people search for most, what each one actually means and the order we would try the fixes in. Start with a backup, or at the very least download wp-config.php and .htaccess before you edit them, so you can put the originals back if a step makes things worse.

Find the error

Almost every WordPress error message is a cover for a PHP error that WordPress has chosen not to print. The quickest way to stop guessing is to make WordPress write that error to a log file.

Open wp-config.php in your host's file manager or over SFTP. Find the line that says "That's all, stop editing" and add these three lines above it:

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

Reload the broken page, then open wp-content/debug.log. The newest entries are at the bottom. Look for a line starting with "PHP Fatal error" and read the file path in it. A path inside wp-content/plugins names the plugin, and a path inside wp-content/themes names the theme.

Turn this off again when you are done. The WordPress handbook says the debug tools are meant for local and staging sites, and debug.log sits in a folder that is often readable from the web, so delete the file as well.

If debug.log stays empty, the failure happens before WordPress gets far enough to write anything. Check the PHP error log in your hosting control panel instead. Many hosts also drop a file called error_log into the folder where the error happened.

Critical error

This is what replaced the old white screen of death. WordPress 5.2 added a handler for fatal PHP errors. In current versions, when a plugin or theme crashes, visitors see "There has been a critical error on this website." If you are on the login page or in the dashboard, the message adds "Please check your site admin email inbox for instructions."

That email goes to the address under Settings, General. It names the plugin or theme that crashed and includes a recovery mode link. The link logs you into a version of the dashboard where the faulty extension is paused, so you can deactivate it, roll it back or update it. In the current WordPress code the email is sent at most once a day by default, and the link stays valid for 24 hours.

Plenty of people never get that email. Shared hosts often send WordPress mail from an address that spam filters reject. If nothing arrives, do the same job by hand:

1. In the file manager, rename wp-content/plugins to plugins.hold.
2. Log in at /wp-login.php. WordPress will report that the plugins are missing and deactivate them.
3. Rename the folder back to plugins, then reactivate plugins one at a time and reload the site after each one.
4. If the site still fails with every plugin off, rename the active theme's folder in wp-content/themes. WordPress falls back to a default theme if one is installed.

The plugin that brings the error back is your culprit. Leave it off and check its changelog or support forum for a fix.

To send future recovery emails somewhere other than the admin address, add define( 'RECOVERY_MODE_EMAIL', 'you@yourdomain.com' ); to wp-config.php with your own address in it. Two WordPress.org support threads listed below got the same advice from the forum volunteers, and it is good advice. Read debug.log first, then switch plugins and the theme off.

Database connection

"Error establishing a database connection" means WordPress could not log in to MySQL or MariaDB. Either the details in wp-config.php are wrong or the database server is not answering. Nothing on the site will load until it can connect, the dashboard included.

1. Open wp-config.php and compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST with the database screen in your hosting panel. After a migration this mismatch is the usual cause. DB_HOST is often localhost, but some hosts give you a separate hostname.
2. If everything matches, reset the database user's password in the panel and paste the new one into wp-config.php. That rules out a stray space or a character you cannot see.
3. If the error comes and goes on its own, the database server is overloaded or running out of connections. You can't see that from WordPress. Send your host the times it happened and ask them to check the database logs.
4. If the dashboard says tables need repairing, add define( 'WP_ALLOW_REPAIR', true ); and visit /wp-admin/maint/repair.php.

That repair page works without a login, since a corrupt database usually stops you logging in. Anyone who finds it can run it too. Take the line out as soon as the repair finishes.

500 error

An HTTP 500 Internal Server Error means the server hit a problem it could not describe. Chrome words it as "This page isn't working" with HTTP ERROR 500 underneath. On a WordPress site there are three usual causes. A broken .htaccess file, a PHP fatal error, or PHP running out of memory.

Rename .htaccess in the site's root folder to .htaccess_old and reload. If the site comes back, go to Settings, Permalinks and click Save Changes without changing anything, which writes a clean file. If it doesn't come back, rename the file back and turn on the debug log from the first section.

If the log shows nothing useful, re-upload the wp-admin and wp-includes folders from a fresh download of the same WordPress version. That replaces core files only. Your content, plugins and wp-config.php are not touched.

A "Premature end of script headers" line in the Apache error log is the same family of problem. PHP died before it sent anything back, usually from a timeout or the memory limit.

502 and 504

These two come from the web server or proxy sitting in front of PHP, not from WordPress. You will mostly see them on Nginx hosting, where Nginx hands each request to PHP-FPM.

A 502 Bad Gateway means Nginx got nothing usable back. PHP-FPM may be stopped, every worker may be busy, or the worker handling your request crashed. A 504 Gateway Timeout means PHP took longer than Nginx would wait, and the default for fastcgi_read_timeout is 60 seconds.

On shared or managed hosting you cannot change any of this, so give support the exact time and page. On your own server, check that PHP-FPM is running and read its log. If 502s come and go as traffic rises, pm.max_children is probably too low for the visitors you get, and the PHP manual describes it as the limit on simultaneous requests. Raise it only as far as your RAM allows. Also check request_terminate_timeout, because PHP-FPM kills any worker that runs past it and long imports then end in a 502.

403 and login

A 403 Forbidden is the server refusing the request outright. On WordPress the usual reasons are file permissions that are too strict, a deny rule in .htaccess, or a firewall rule such as ModSecurity blocking something that looked suspicious.

On shared hosting that runs PHP as your own user, the WordPress handbook recommends 755 or 750 for folders and 644 or 640 for files, with wp-config.php at 440 or 400. Never set anything to 777 to make an error go away. If the 403 only appears when you save a post or upload a file, ask your host which firewall rule fired, because that is a rule on their side.

"Sorry, you are not allowed to access this page" looks similar but comes from WordPress itself. You are logged in, and your account lacks the capability that screen needs. After a migration the usual cause is a changed table prefix. The $table_prefix value in wp-config.php has to match your table names, and the wp_capabilities and wp_user_level rows in the usermeta table must start with that same prefix.

The other common cause is boring. You bookmarked a settings page that belonged to a plugin you have since removed.

404 errors

If the homepage loads but every post and page returns a 404, the rewrite rules are missing. Go to Settings, Permalinks and click Save Changes. That rebuilds them, and on Apache it rewrites the WordPress block in .htaccess.

"The requested URL was not found on this server" is Apache's wording, not WordPress's. It tells you the request never reached WordPress. Either .htaccess is missing its rules or mod_rewrite is switched off, and on most hosting only the host can turn mod_rewrite on. Nginx ignores .htaccess entirely, so on Nginx the site's server block needs a try_files line that passes unknown URLs to index.php.

A custom post type that 404s right after you add it needs the same Permalinks save to register its addresses.

Memory exhausted

The full message reads something like "Allowed memory size of 268435456 bytes exhausted". The number is the current limit in bytes. 134217728 is 128 MB and 268435456 is 256 MB.

WordPress asks for 40 MB on a single site and 64 MB on multisite, and it only ever raises PHP's limit, never lowers it. PHP's own default is 128 MB. So the ceiling you have hit is almost always the one your host set. Add this to wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

This only works if the host lets PHP change memory_limit while it runs. If the figure in the error stays the same after the edit, the host has capped it. Raise memory_limit in your panel's PHP settings, or ask support to do it.

Memory is not always the real problem. If the error points at the same plugin file every time, or you already have 512 MB, something is looping or loading far too much data at once, and more memory only delays the crash.

Syntax errors

"Parse error: syntax error, unexpected" means PHP could not read a file at all. The message gives you the file and the line number. Most often it is a snippet somebody pasted into functions.php with a missing bracket or curly quotes from a web page. Open that file in the file manager and undo the edit, because the theme editor in the dashboard is unreachable while the site is down.

When the file belongs to a plugin you never edited, the plugin probably needs a newer PHP version than your server runs. WordPress currently recommends PHP 8.3 or greater. If you run one of our themes, the PremiumPress v12 requirements page lists the PHP and database versions it supports.

"Cannot modify header information, headers already sent" is a related one. Something printed output too early, usually a blank line or space before the opening PHP tag in wp-config.php, or a file saved as UTF-8 with BOM. Re-save it as plain UTF-8 with nothing before the tag.

FAQ

Sources

All checked on 7 October 2026.

• WordPress Advanced Administration Handbook: Common WordPress Errors
• WordPress Advanced Administration Handbook: Debugging in WordPress
• WordPress Advanced Administration Handbook: Editing wp-config.php
• WordPress Advanced Administration Handbook: Changing File Permissions
• WordPress.org Documentation: FAQ Troubleshooting
• Make WordPress Core: Fatal Error Recovery Mode in 5.2
• WordPress.org: Requirements
• PHP Manual: core php.ini directives, memory_limit
• PHP Manual: PHP-FPM configuration
• nginx documentation: ngx_http_fastcgi_module
• WordPress.org support: WordPress critical error
• WordPress.org support: Can not access wp_admin
• WordPress.org support: WordPress could not establish a secure connection to WordPress.org
• PremiumPress v12 documentation: Requirements