How to Fix Common WordPress Errors

This guide helps you diagnose and fix the errors that most often take a WordPress site offline: the white screen of death, the 500 internal server error, "error establishing a database connection", posts that suddenly return 404 Not Found, exhausted memory, a PHP syntax error after editing a file, being locked out of the admin dashboard, and a site stuck in maintenance mode. For each error you get the same three things: what you actually see, the likely cause, and a clear fix. It is written for Noiz hosting clients who run WordPress and want to get back online quickly, whether you have dashboard access or not.

Most of these errors look alarming but come from a small number of root causes: a bad plugin or theme, a broken file, a server limit, or wrong database details. Work through the relevant section calmly and in order, and you will usually be back within a few minutes.

Last reviewed: 27 July 2026, against WordPress 7.0.2 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation linked below.

Official Documentation Reference

• Common WordPress errors (Advanced Administration Handbook): the official catalogue of error messages and first-line fixes.
• Debugging in WordPress: the authoritative reference for WP_DEBUG, the debug log, and reading the actual error behind a blank page.
• Recovery Mode: how WordPress pauses a faulty plugin or theme and emails you a safe login link after a fatal error.
• Editing wp-config.php: the full list of configuration constants used throughout this guide, including database, memory and repair settings.
• Reset your password: every method for regaining a login, from the email link to editing the database directly.
• Customize permalinks: how WordPress builds post and page URLs, relevant to 404 errors.

Prerequisites

• You know how to log in to the WordPress admin dashboard. Some fixes below need it; the rest deliberately work without it.
• A way to reach your site's files: an SFTP or FTP client, or the File Manager in your hosting control panel. Several fixes involve editing or renaming files such as wp-config.php, .htaccess and folders inside wp-content.
• A recent backup, or the ability to make one before you start. On Noiz managed plans a backup is taken for you and Noiz support can restore it; even so, copy any file to your own computer before you edit it.

The Troubleshooting Toolkit

Almost every fix in this guide relies on one of five basic techniques. Learn these once here, and each error section stays short. Read this section first even if you are in a hurry, because these are the tools that turn a mysterious blank page into a solved problem.

1. Back up before you touch anything

Before editing a file or a database, make sure you can undo it. Download a copy of any file to your computer before you change it, so you can put the original back if the fix does not work. Do not start deleting or rewriting files on a live site with no way back.

2. Reach your files without the dashboard

When WordPress will not load, you fix it from the files instead. Connect with an SFTP or FTP client, or open the File Manager in your hosting control panel. The two locations you will use most are the site's root folder, which contains wp-config.php and .htaccess, and the wp-content folder, which contains plugins and themes.

3. Turn on the debug log to see the real error

A blank page or a generic "critical error" hides the actual problem. Turn on WordPress debugging to write the real message to a log file. Edit wp-config.php and, just above the line that reads /* That's all, stop editing! Happy blogging. */, add:

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

Reload the site once, then open wp-content/debug.log. The last few lines usually name the exact file and line number causing the fault, which almost always points at a specific plugin or theme. Keeping WP_DEBUG_DISPLAY set to false means visitors never see the raw errors while you investigate. When you have finished, set all three values back to false so the log stops growing on a live site.

4. Deactivate every plugin without the dashboard

A faulty or conflicting plugin is the single most common cause of these errors, and you can switch them all off from the files. Using SFTP or File Manager, open wp-content and rename the plugins folder to something like plugins-off. WordPress can no longer find any plugin, so it deactivates them all. If your site returns, a plugin was the culprit: rename the folder back to plugins, then reactivate plugins one at a time from the dashboard until the error reappears, and the last one you switched on is the offender.

5. Rule out the active theme

If disabling plugins does not help, test the theme the same way. In wp-content/themes, rename the folder of your active theme. WordPress falls back to one of the default themes that ship with it (the Twenty-something series). If the site recovers, the problem is in your theme, often a broken change in its functions.php file.

The White Screen of Death (Critical Error)

What you see: a plain white page with no content, or the message "There has been a critical error on this website." On the admin side you may see "There has been a critical error on this website. Please check your site admin email inbox for instructions."

Likely cause: a fatal PHP error, almost always from a plugin or theme that is incompatible, broken, or has just been updated, or from exhausted memory. The white page is simply WordPress failing to finish loading.

How to fix it:

Modern WordPress tries to rescue you automatically through Recovery Mode. When it detects a fatal error on a normal page load, it emails your site administrator address a special login link. Clicking that link logs you in with the faulty plugin or theme paused for your session only, so your dashboard loads and shows a notice naming the component at fault. Deactivate or fix that plugin or theme, then choose Exit Recovery Mode from the toolbar.

The recovery email does not always arrive. It is sent directly by the web server before your mail plugins load, so it can be filtered as spam or blocked entirely. If it does not turn up within a few minutes, or you cannot access the admin email, fix it manually instead:

1. Turn on the debug log (toolkit step 3) and reload the site to capture the exact error into wp-content/debug.log.
2. Read the last lines of the log. If they name a plugin, deactivate that plugin by renaming its folder inside wp-content/plugins. If they name your theme, rename the theme folder (toolkit steps 4 and 5).
3. If the log points at memory, raise the limit as described in the memory section below.
4. Reload the site. Once it returns, reactivate components one at a time to confirm which one broke and update or replace it.

PHP Syntax Error After Editing a File

What you see: a message such as Parse error: syntax error, unexpected '}' in /path/to/file.php on line 42, or a white screen and critical error, immediately after you edited a theme or plugin file.

Likely cause: a small mistake in PHP code, a missing bracket, semicolon or quote, usually added through the built-in Appearance then Theme File Editor, or Plugins then Plugin File Editor. A single stray character can take the whole site down, and because the same fatal error blocks the editor, you often cannot undo the change from inside WordPress.

How to fix it:

1. Note the file and line number in the error message. That is exactly where the mistake is.
2. Open that file over SFTP or in File Manager and correct the change. If you are not sure what you altered, replace the file with the copy you backed up beforehand, or with a fresh copy of the same plugin or theme.
3. Save, upload, and reload the site.

To avoid this class of error, do not edit live code through the built-in file editors. Disabling them is a standard hardening step covered in the WordPress Security Checklist. Make code changes in a staging copy or through a proper editor over SFTP, where a mistake is easy to reverse.

Allowed Memory Size Exhausted (Memory Limit)

What you see: a white screen, a 500 error, or a message like Fatal error: Allowed memory size of 268435456 bytes exhausted in the page or the debug log.

Likely cause: a page or task needed more memory than WordPress was allowed to use. Heavy plugins, large imports, image processing, or page builders can push a site past its limit.

How to fix it:

Raise the memory WordPress may request. Edit wp-config.php and add this line above the "stop editing" line:

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

For memory-hungry admin tasks such as bulk imports you can also add define( 'WP_MAX_MEMORY_LIMIT', '512M' );, which applies only inside the dashboard.

There is an important limit to understand: WordPress can never use more memory than the server's own PHP memory_limit allows. If the server cap is lower than the value you set here, raising the WordPress constant alone changes nothing. On Noiz hosting the PHP memory limit is generous by default, and if a genuine task needs more, Noiz support can lift the server-side limit for you. Before requesting more memory, check whether a single badly behaved plugin is the real cause, because unlimited memory only hides a leak rather than fixing it.

500 Internal Server Error

What you see: a browser or server page reading "500 Internal Server Error", often on every page including /wp-admin.

Likely cause: a deliberately vague server-side error. In WordPress it is usually a corrupted .htaccess file, exhausted memory, a plugin or theme conflict, a damaged core file, or an incompatible PHP version.

How to fix it, in order:

1. Turn on the debug log (toolkit step 3) and reload. The real error is often written there even when the browser shows only "500".
2. Rule out .htaccess. In the site's root folder, rename .htaccess to htaccess-old, then reload. If the site returns, the file was corrupt: log in and go to Settings then Permalinks and click Save Changes, which writes a fresh, correct .htaccess.
3. Deactivate all plugins, then the theme, using toolkit steps 4 and 5.
4. Raise the memory limit as shown above, in case the 500 is really memory exhaustion.
5. Check the PHP version. WordPress 7.0 requires at least PHP 7.4 and works best on PHP 8.3 or newer; a very old or mismatched PHP version can throw 500 errors. Your hosting control panel shows and changes the PHP version for the site.

A 500 error is the one case where the server's own error log is the fastest route to the cause, because it records the underlying reason the public page hides. On Noiz managed plans, Noiz support can read that server log and tell you exactly which file or limit is responsible.

Error Establishing a Database Connection

What you see: a page that simply says "Error establishing a database connection" and nothing else.

Likely cause: WordPress cannot reach or log in to its database. The usual reasons are wrong database details in wp-config.php (very common straight after a site move or host change), a database server that is down or overloaded, or a corrupted database.

How to fix it:

1. Check the database details first. Open wp-config.php and confirm these four values match the database exactly:

   define( 'DB_NAME', 'your_database_name' );
   define( 'DB_USER', 'your_database_user' );
   define( 'DB_PASSWORD', 'your_database_password' );
   define( 'DB_HOST', 'localhost' );

   The database name, user and password come from your hosting account, not from anything you choose freely. DB_HOST is localhost on most setups, but some hosts use a specific hostname, so use the value shown in your Noiz hosting details rather than assuming. A single wrong character here produces this exact error.
2. If the details are correct, the database server itself may be down or overloaded, for example during a traffic spike. Wait a few minutes and try again.
3. If the message hints that the database is corrupt, use the built-in repair tool. Add this line to wp-config.php:

   define( 'WP_ALLOW_REPAIR', true );

   Then visit https://yourdomain.com/wp-admin/maint/repair.php (replace yourdomain.com with your own domain) and click Repair Database. When it finishes, remove that line again. The repair page works without a login on purpose, so leaving it enabled is a security hole.

If the credentials are correct and the repair tool does not help, the problem is on the database server itself. On Noiz hosting, open a ticket and Noiz support can check whether the database service is healthy and whether your account has hit a database size limit.

Posts and Pages Return 404 Not Found

What you see: the homepage works, but clicking into individual posts or pages gives a "404 Not Found" error, even though the content clearly exists.

Likely cause: the permalink rewrite rules that map friendly URLs to your content have been lost or corrupted, commonly after a site move, a change of permalink settings, or a damaged .htaccess file.

How to fix it:

1. Log in and go to Settings then Permalinks. Do not change anything; just click Save Changes. This alone regenerates the rewrite rules and, on Apache servers, rewrites the .htaccess file. It resolves the great majority of permalink 404s.
2. If that does not work, on the same screen select Plain, click Save Changes, then switch back to your preferred structure such as Post name and click Save Changes again to force a clean rebuild.
3. If the URLs still fail and your server uses .htaccess, the file may be missing or unwritable. Confirm the root folder contains an .htaccess file with the standard WordPress block:

   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   </IfModule>
   # END WordPress

WordPress relies on the web server being set up to allow pretty permalinks. On Noiz hosting that is already configured, so re-saving permalinks is normally all you need. If only one specific page returns a 404 while the rest work, the cause is usually a clash between that page's slug and another item, or a stale cache, rather than the rewrite rules.

Locked Out of the Admin Dashboard

What you see: you cannot log in at /wp-admin. This covers a forgotten password, a login page that reloads without letting you in, a "too many failed attempts" lockout, or a redirect loop.

Likely cause: a forgotten or changed password, a broken site email so the reset link never arrives, a plugin or theme conflict blocking the login page, or a security lockout after repeated failed attempts.

How to fix it, by situation:

• Forgotten password, email working: use the Lost your password? link on the login page. WordPress emails you a reset link, the simplest fix by far.
• Reset email never arrives: the site's outgoing mail is likely not configured, so use another method from the official Reset your password guide. If you have database access, you can set a new password directly in the wp_users table through phpMyAdmin. On Noiz managed plans, support can reset the password on the database for you.
• A fatal error blocks login: if the login page shows a critical error rather than a password prompt, treat it as a white screen: check the recovery email and, if needed, deactivate plugins and the theme from the files (toolkit steps 4 and 5).
• Locked out by failed attempts: a security plugin may block your address after several wrong passwords. Wait for the lockout window to pass, or clear the lockout by temporarily deactivating that security plugin from the files.
• Login page keeps redirecting: a redirect loop often comes from an incorrect site address setting or a corrupted .htaccess. Rename .htaccess to test it, and confirm the site address is right before making further changes.

Stuck in Maintenance Mode

What you see: every page shows "Briefly unavailable for scheduled maintenance. Check back in a minute." and never recovers.

Likely cause: an update was interrupted. When WordPress updates itself, a plugin, or a theme, it creates a hidden file named .maintenance in the site's root folder and deletes it the moment the update finishes. If the update stalls, times out, or you navigate away, the file is left behind and the site stays locked in maintenance mode.

How to fix it:

1. Connect over SFTP or open File Manager and go to the site's root folder, the same folder that contains wp-config.php.
2. Find the file named .maintenance. It may be hidden, so enable "show hidden files" in your client or File Manager if you do not see it.
3. Delete .maintenance. This is safe and immediately releases the site from maintenance mode.
4. Reload the site. If your browser still shows the maintenance page, clear its cache and reload.

Because the interruption may have left an update half-finished, log in afterwards and check Dashboard then Updates, and re-run any update that did not complete. To avoid a repeat, update plugins and themes in small batches rather than all at once, so a single slow update is less likely to time out. If the .maintenance file reappears on its own after you delete it, an update process is still running or a plugin is recreating it, and that plugin is the next thing to investigate.

When to Contact Noiz Support

Work through the relevant section above and you can resolve most WordPress errors yourself. Some faults, though, sit on the server rather than in your site, for example a database server problem, a hard PHP limit, or an error only the server log reveals. On Noiz managed hosting, support can read the server error logs, restore a recent backup, adjust PHP settings, reset a locked account through the database, and reach your files for you.

If you get stuck, open a support ticket with the Noiz support team and include your domain name, the exact error text you see (a screenshot is ideal), and, crucially, what changed just before the error appeared: a plugin or theme update, a core update, a file edit, or a site move. That last detail is usually what points straight at the cause.