How to fix the 500 error in WordPress

Category: WordPress

The 500 error in WordPress usually shows up as a white screen, generic message, or HTTP ERROR 500 after updating a plugin, switching theme, or editing wp-config.php. The real cause is in the log or in WP_DEBUG; follow this flow to find it fast.

Before you start

  • Access to cPanel and to the WordPress admin (/wp-admin/) — if you can’t reach the admin, use File Manager or FTP.
  • Know what changed: plugin/theme update, manual file edit, migration, or PHP switch.
  • Recent backup from Backup Wizard or WP Toolkit.

Step 0 — Enable WP_DEBUG

Without debug enabled, the site only shows “Internal Server Error”. Edit wp-config.php from File Manager and add before /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the site: the log writes to wp-content/debug.log. There you’ll see the exact plugin, file and line.

Important: turn WP_DEBUG off when you’re done — it exposes sensitive information if it stays on in production.

Common causes in WordPress

1. Plugin conflict

A new (or just-updated) plugin breaks the site.

If you can’t reach the admin, disable them via File Manager:

  1. Go to wp-content/.
  2. Rename the plugins folder to plugins.off.
  3. Reload the site. If it loads, the problem is a plugin.
  4. Rename back to plugins and enter the admin (all are now deactivated).
  5. Activate one by one until the error reproduces.

2. Theme conflict

A theme with code incompatible with your PHP or with a key plugin.

If you can’t enter the admin, force the default theme via phpMyAdmin:

  1. Open the WordPress database.
  2. In the wp_options table look for template and stylesheet.
  3. Change both to twentytwentyfour (or whichever default theme exists in wp-content/themes/).
  4. Reload the site.

A cache plugin update or a hosting move leaves an .htaccess that mod_rewrite can’t parse.

  1. In File Manager go to the WordPress root.
  2. Rename .htaccess to .htaccess.old.
  3. Reload the site.
  4. If it loads, go to Settings → Permalinks and click Save Changes without touching anything — WordPress regenerates a clean .htaccess.

4. Exhausted PHP memory

debug.log shows Allowed memory size of … bytes exhausted.

Edit wp-config.php and add:

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

If the server limit is lower, also raise it from Select PHP Version → Options → memory_limit.

5. Incompatible PHP version

WordPress 6.x no longer officially supports PHP 7.4.

  1. In cPanel open Select PHP Version and switch to PHP 8.2 or 8.3.
  2. If an old plugin breaks under PHP 8, look for an update or replacement; staying on 7.4 is no longer a forward-looking option.

6. Damaged core files

Interrupted migration, FTP in binary mode, or malware deleted key files.

  1. Download the current version from https://wordpress.org/download/.
  2. Upload via FTP everything except wp-config.php and the wp-content/ folder.
  3. Overwrite wp-admin/ and wp-includes/ completely.

7. Database unreachable

debug.log shows Error establishing a database connection.

  1. Verify DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php.
  2. In MySQL Databases confirm the user has All Privileges.
  3. If the database hit its quota or got corrupted, support can repair it.
  1. Enable WP_DEBUG and check wp-content/debug.log.
  2. Rename plugins/ and test.
  3. Rename .htaccess and re-save permalinks.
  4. Raise WP_MEMORY_LIMIT.
  5. Switch PHP to 8.2/8.3.
  6. If nothing changes, upload clean core.
  7. Last resort: restore a backup from before the failure.

Final verification

  • The frontend returns 200 in incognito.
  • /wp-admin/ loads and lets you sign in.
  • wp-content/debug.log produces no new errors.
  • WP_DEBUG is turned off again.
  • Critical plugins are reactivated and working.

Common diagnostic mistakes

  • Leaving WP_DEBUG on in production: exposes paths and versions.
  • Reactivating all plugins at once: do it one by one or you won’t know which one was guilty.
  • Editing wp-config.php without a backup: always download a copy first.
  • Ignoring caches: purge LiteSpeed Cache, WP Rocket or Cloudflare after every test.
  • Trusting “it looks fine” without opening the log: if you didn’t read the log, you didn’t diagnose.

Still need help?

If this guide didn’t solve your issue, our team can help you via ticket.

Open ticket Go to my account