--- title: "WordPress Errors: How to Tell Which One You Have and Fix It" description: "WordPress errors sorted by what you see: the status code and real message for each, measured on a test site, plus four tools that fix most of them." url: "https://skybootstrap.com/wordpress-errors/" canonical_url: "https://skybootstrap.com/wordpress-errors/" date: "2026-11-11T06:53:00+06:00" modified: "2026-11-05T17:14:17+06:00" author: Skybootstrap Team type: article site: SkyBootstrap language: en-US --- # WordPress Errors: How to Tell Which One You Have and Fix It Most WordPress errors tell you what they are through two things: what the page shows and the HTTP status code it returns. Match those to the table below, get the real error message from the debug log (WP_DEBUG) or your server’s log, then switch off the plugin or theme behind it. For the plugin and theme errors we reproduced on our test site, that routine found the culprit every time. We broke our WordPress 7.1.3 lab install on purpose, one error at a time, on nginx, plus an Apache copy for the Apache-only errors. This page is the WordPress troubleshooting route we followed: it sends you to the right fix for each error and shows what we saw. ## Match what you see to the error WordPress errors fall into about a dozen patterns, and the status code tells most of them apart. The HTTP status code is the number your server returns with each page: 200 means fine, 4xx a failed request, 5xx a failed server. You can see it with `curl -I https://yoursite.com/` or in your browser’s developer tools, under Network. | What you see | Status we measured | Most likely cause | Fix guide | | --- | --- | --- | --- | | “There has been a critical error on this website.” | 500 | A plugin or theme hit a PHP fatal error | Fix the critical error | | A blank white page | 500 or 200, empty body | A fatal error with the error screen turned off, or code that stops the page | Fix a white screen | | “Error establishing a database connection” | 500 | Wrong database details in wp-config.php, or the database server is down | Fix the database connection | | “500 Internal Server Error” from the server | 500 | A broken .htaccess line or server setting | Fix a 500 error | | “ERR_TOO_MANY_REDIRECTS” | 301 or 302, repeated | Two rules sending visitors back and forth | Break the redirect loop | | Home page works, posts show “Not Found” | 404 | Missing rewrite rules or server config | Fix posts returning 404 | | “Briefly unavailable for scheduled maintenance” | 503 | A leftover .maintenance file | Leave maintenance mode | | “Allowed memory size of … bytes exhausted” | 500 | PHP ran out of memory | Fix the memory error | | “Update failed” or “Could not create directory” | Not recorded (the message appears on the update screen) | WordPress can’t write to its folders | Fix a failed update | | Can’t log in, or the login page reloads | 200 or 302 | Lost password, lockout or cookie loop | Get back into wp-admin | | Saved changes don’t appear | Not recorded (the cache reported a HIT) | A cache is serving the old copy | Make changes show up | | “502 Bad Gateway” | 502 | PHP stopped responding | Contact your host (below) | | “403 Forbidden” | 403 | The cause we reproduced: a file the web server couldn’t read | Check file permissions (below) | | “Parse error: syntax error, unexpected…” | 500 | A typo in PHP code someone edited; with errors hidden, the critical error screen shows instead | Fix the critical error | Two rows need care. A blank page can come back as 200, so a status checker may call your broken site healthy. And the database error looks identical whether the password is wrong or the server is down; even wp-admin’s longer message only singles out a wrong database name. ## WordPress troubleshooting starts with a backup WordPress troubleshooting is safer with a backup of whatever you’re about to edit. Most fixes here change one of three things, so copy the file or folder first: - `wp-config.php`, before you add debug lines or change database details. - `.htaccess`, before you rename or regenerate it. - The plugin or theme folder, before you rename or delete it. If your host offers a one-click backup or snapshot, take one first, and a database export from your host’s panel (often phpMyAdmin) covers you if a fix goes wrong. The [WordPress handbook’s debugging page](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) asks you to “verify that you have either utilized a staging environment or taken an appropriate backup of your site” before changing anything. When the live site is already down, a backup is the realistic choice, and the debug lines should stay only as long as you need them. ## Turn on the debug log, and keep it private The debug log records the real PHP error behind a critical error or blank page, with the file and line that caused it. WP_DEBUG is the wp-config.php setting that switches on WordPress’s debug mode, and it’s off by default; debug.log is the file WordPress writes errors to once logging is on. Open `wp-config.php` and look for `define( 'WP_DEBUG', false );`, which the standard file already has. Change `false` to `true`; adding a second WP_DEBUG line doesn’t work, because PHP keeps the first value. Then add the other two lines below it: ``` define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-debug.log' ); define( 'WP_DEBUG_DISPLAY', false ); ``` For the log path, create a folder outside your public web folder first, because PHP won’t create it for you. Write its full path from the server root; your host’s file manager or panel shows that path and which folder is public (often `public_html`). With `WP_DEBUG_LOG` set to `true` instead of a path, WordPress writes to `wp-content/debug.log`. On our test site anyone could download that file at `/wp-content/debug.log`, on nginx and on Apache with WordPress’s default rules, while a full path outside the web root kept it private. `WP_DEBUG_DISPLAY` set to `false` keeps errors off the screen, so visitors don’t see file paths. After saving, reload the broken page, then open the log: ``` [02-Nov-2026 02:25:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function lab_missing_function() in /srv/err/wp-content/plugins/lab-broken-plugin/lab-broken-plugin.php:7 ``` The path after “in” names the culprit: here, a plugin folder called `lab-broken-plugin`. On our server, PHP rechecks changed files every 2 seconds, so give a wp-config edit a moment before you reload. When you’re done, set `WP_DEBUG` back to `false`, and delete `wp-content/debug.log` if you used the default path. ## Check the server’s error log When WordPress can’t log, the web server and PHP still keep an error log, a file where each error is written with its time and the file that caused it. That covers errors that happen before WordPress loads, like a broken `.htaccess` or PHP not running. Your host’s panel usually has an “Error log” or “Logs” page; on an Ubuntu or Debian VPS like our lab, look in `/var/log/apache2/` or `/var/log/nginx/`. Two lines from our test servers show the kind of thing to look for: ``` [core:alert] /srv/erra/.htaccess: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration [crit] connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream ``` The first came with a 500 error on Apache, from a line in `.htaccess` the server couldn’t run, and the second with a 502 on nginx because PHP had stopped. WordPress never started in either case, so it couldn’t log them. ## Switch off plugins and the theme without the dashboard Rename the plugin’s folder in `wp-content/plugins` and the site loads without it. An FTP client or your host’s file manager is a tool for browsing and editing your site’s files, and either one can rename folders: change `lab-broken-plugin` to `lab-broken-plugin.off`, for example. To switch off every plugin at once, rename the whole `plugins` folder. In our test the site came back at once, but the plugin still counted as active until we opened the Plugins screen in wp-admin, which deactivated it: ![WordPress Plugins screen after renaming a plugin folder: notice that the plugin has been deactivated because the plugin file does not exist](https://skybootstrap.com/wp-content/uploads/2026/11/wordpress-errors-plugin-deactivated-notice.webp "Test site, 2 Nov 2026: WordPress 7.1.3, nginx 1.24.0, PHP 8.3. Opening Plugins after the rename deactivates the plugin.") Renaming the folder back didn’t reactivate it, so update or replace the plugin and then activate it again yourself. If you have SSH access, WP-CLI is WordPress’s command-line tool, and it can do the same job. One catch: WP-CLI loads your plugins too, so with a fatal error, it crashed with the same critical error. Adding `--skip-plugins` got past it: ``` $ wp plugin deactivate lab-broken-plugin Error: There has been a critical error on this website. $ wp plugin deactivate lab-broken-plugin --skip-plugins Success: Deactivated 1 of 1 plugins. ``` To switch the theme without the dashboard, first make sure another theme, such as a default Twenty Twenty-Four or Twenty Twenty-Five, is in `wp-content/themes`. Then rename the active theme’s folder and open `/wp-admin/` straight away. On our test site the front page was blank (200, nothing in it) until we opened wp-admin, and WordPress then switched to Twenty Twenty-Four. If you’re in recovery mode, switching themes under **Appearance > Themes** is simpler. ## Use recovery mode when WordPress offers it Recovery mode is a WordPress feature, added in version 5.2, that emails the site admin a special login link after a fatal error. Logging in through that link pauses the plugin or theme that caused it, for your session only, so you can deactivate or update it. The email doesn’t always come: in our test, the error on the front page showed only “There has been a critical error on this website.” and sent nothing. On `wp-login.php`, the same error showed the message below and sent one email: ![WordPress critical error screen on the login page asking the visitor to check the site admin email inbox for instructions](https://skybootstrap.com/wp-content/uploads/2026/11/wordpress-errors-critical-error-screen.webp "Test site, 2 Nov 2026: WordPress 7.1.3. The email hint only appears when the error happens in wp-admin or on the login page.") That matches WordPress’s code: it only sends the email when the error hits wp-admin, the login page or a similar protected page. If you got no email, open `/wp-login.php` or `/wp-admin/` once; both sent the email on our test site for an error that runs on every page. It goes to the site’s admin email address, or to `RECOVERY_MODE_EMAIL` if that’s set in wp-config.php, and WordPress sends at most one a day. The link “will expire in 1 day”. After we logged in through it, the Plugins screen showed the broken plugin as paused, with the error under it: ![WordPress Plugins screen in recovery mode showing a plugin paused with the fatal error message](https://skybootstrap.com/wp-content/uploads/2026/11/wordpress-errors-recovery-mode-paused-plugin.webp "Test site, 2 Nov 2026: WordPress 7.1.3. The plugin is paused for the recovery session only.") Visitors still saw the error page while we were in recovery mode, so deactivate the plugin before you exit. When the email never arrives, work through the steps to fix the critical error without it. ## WordPress errors that take down the whole site Five errors stop every page of a WordPress site, and each one has a first thing to check. - **Critical error or blank page.** Both usually come from a PHP fatal error in a plugin or theme. The [WordPress handbook’s common errors page](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/) lists the common causes: “conflicts between plugins, compatibility issues with your theme, running an incompatible PHP version, hitting the memory limit, or having corrupted WordPress files”. Read the debug log, then rename the folder it names. A blank page is harder because it hides the message, and one of the white screen cases we reproduced even returned 200. - **Database connection error.** The front end showed one short message for a wrong password, name or host, and for a stopped database server. wp-admin gives a longer message. For a wrong database name it said “Cannot select database”, but a wrong password and a stopped server got the same general text. Then compare the details in wp-config.php with your host’s database page, or run a small script that tests the database details and names the exact problem. - **500 Internal Server Error.** A plain 500 page from the server, not WordPress’s critical error box, usually means `.htaccess` or a server setting. `.htaccess` is the file of rules Apache reads in each folder. It’s a hidden file, so turn on hidden files in your file manager, and it only exists on Apache servers. Rename it; if the 500 goes away, regenerate .htaccess by saving **Settings > Permalinks**. - **502 Bad Gateway.** nginx returned 502 on our test site when PHP-FPM, the service that runs WordPress’s PHP code, was stopped. That’s usually on your host’s side, so restart PHP from the panel if you can, or contact support. - **Maintenance mode.** “Briefly unavailable for scheduled maintenance” comes from a `.maintenance` file that updates create in the WordPress folder. Delete `.maintenance` from the WordPress folder (it’s a hidden file); on our test site it returned 503 to every page, including wp-admin, until we did. WordPress ignores a normal one after 10 minutes, but one containing `$upgrading = time();` never expired in our test. ## WordPress errors that only hit some pages or tasks Some errors only hit some pages or tasks, and the part of the site that still works narrows down the cause. - **Redirect loops.** Your browser gives up with ERR_TOO_MANY_REDIRECTS when two rules keep sending it back and forth. Run `curl -sIL --max-redirs 10 https://yoursite.com/` to see the whole chain: each response from WordPress carries `X-Redirect-By: WordPress`, so you can see which hops come from WordPress and which from the server or a plugin. We built and fixed a www loop and an HTTPS-proxy loop that way. - **Posts and pages returning 404.** If the home page works but posts don’t, either the web server never hands post addresses over to WordPress, or the stored rewrite rules have no entry for them. Saving **Settings > Permalinks** fixed the second case and, on Apache, rewrote `.htaccess` when it could. On nginx, and on Apache with mod_rewrite off, saving reported success and posts stayed 404 until the server rule was fixed. - **Memory exhausted.** “Allowed memory size of 134217728 bytes exhausted” means PHP hit its limit, here 128 MB. WordPress’s own default, `WP_MEMORY_LIMIT`, is 40M (64M on multisite), but that only raises PHP’s limit; it never lowers it. Raising the memory limit in wp-config.php worked on our server, except when the host had locked it. - **Maximum execution time exceeded.** We didn’t reproduce this one. It means a PHP task ran past its time limit, and the handbook’s examples are 30 or 60 seconds. The handbook suggests `php_value max_execution_time 60` in `.htaccess`, but on our Apache server, where PHP runs as PHP-FPM, any `php_value` line in `.htaccess` turned the whole site into a 500 error. Use your host’s PHP settings or `php.ini` instead. A `.user.ini` file worked for the memory limit on our PHP-FPM server, though PHP can take up to 5 minutes to reread it. - **Failed updates.** WordPress needs to write to its own folders to update. On our test site, a plugins folder it couldn’t write to gave “some files could not be copied”, and with `wp-content` locked it asked for FTP details instead. Each update error message has its own fix, and most come down to [file ownership and permissions](https://skybootstrap.com/wordpress-file-permissions/). - **Locked out of wp-admin.** A password set by hand in the database still works: we set one with MD5 in SQL, logged in, and WordPress upgraded it to its current hash. WP-CLI can reset it in one command too. A reset doesn’t remove a second login factor, though; security-plugin and two-factor lockouts need their own steps. - **Changes not showing.** A page cache can keep serving the old version after you save; on our test site it did until we purged it. And if you edit a theme’s `style.css` directly, check which file the theme loads: Twenty Twenty-Five loads `style.min.css`, so our edit did nothing. Start with whichever cache is holding the old page. - **403 Forbidden.** On our Apache test site, the 403 came from `index.php` set so only its owner could read it (mode 600); setting it back to 644 fixed it. Check the file’s permissions in your file manager, or ask your host. If you also find files you didn’t add, [check whether the site was hacked](https://skybootstrap.com/wordpress-site-hacked/). ## When to call your host Some errors sit outside WordPress, and only your host can fix them: - The database server is down: every database detail checks out, but the connection still fails. - PHP has stopped: a 502 Bad Gateway error. - A limit is locked: raising memory in wp-config.php changes nothing. - You can’t reach your files at all: no file manager, FTP or SSH access. Send them the time it started, the status code and the matching line from the error log. That turns a vague ticket into a quick fix. ## Keep the next error small Most errors on our list started with a change: an update, an edited file, a moved site. Update one plugin at a time, so you know which one to blame, and keep a backup from before each update. Test big changes on a staging copy if your host offers one, and leave `WP_DEBUG_DISPLAY` off on a live site, with the log outside the public folder. Theme developers who want to go deeper can read our guide to [debugging WordPress themes](https://skybootstrap.com/debugging-wordpress-theme/). ## Frequently Asked Questions ### What is the most common WordPress error? We found no public count of WordPress errors by frequency. Since version 5.2, WordPress catches plugin and theme fatal errors and shows an error screen. On 7.1.3, our test site, it reads “There has been a critical error on this website”, and the WordPress handbook lists plugin conflicts, themes, PHP versions, memory and corrupted files as its usual causes. ### How do I find out what caused a WordPress error? Turn on the debug log in wp-config.php and reload the page. The error line names the file and line number, and the folder in that path is usually the plugin or theme to blame. If WordPress can’t start at all, check the server’s error log in your hosting panel instead. ### Can I fix WordPress errors without FTP? Often, yes. Your host’s file manager can rename plugin folders and edit wp-config.php, and recovery mode lets you log in with the broken plugin paused. With SSH, WP-CLI works too; add –skip-plugins when a plugin is crashing the site. ### Is it safe to leave WP_DEBUG on? No. With WP_DEBUG_DISPLAY on, visitors see error text with your server paths. With the log in the default place, our test site served debug.log to anyone who requested it. Turn debugging off once the error is fixed, or log to a folder outside the web root. ## How we tested We built two copies of the same WordPress 7.1.3 test site on 2 November 2026, with no extra plugins and the Twenty Twenty-Five theme. One ran on nginx 1.24.0, the other on Apache 2.4.58, both with PHP-FPM 8.3 and MariaDB 10.11. Then we caused each error on purpose: a broken test plugin, wrong database details, edited .htaccess and nginx files, a .maintenance file, a memory-hungry plugin and locked folders. For each one we wrote down the status code, the page text and the log lines. The test server can’t send email, so a mail-logging plugin saved outgoing messages to a file. That’s where we read the recovery email. Quotes from the WordPress handbook are from its source files as of 28 October 2026.