WordPress 500 Internal Server Error

How to Fix It — Step by Step

1. Regenerate your .htaccess file
   Log into your hosting file manager or FTP client and navigate to your WordPress root folder. Rename .htaccess to .htaccess_old — do not delete it. Then, if your dashboard is accessible, go to Settings → Permalinks and click Save Changes. WordPress will write a clean .htaccess automatically.

   You should see: Your site loads normally. If it does, the old .htaccess file was corrupted. You can safely delete .htaccess_old.

2. Deactivate all plugins at once
   Via FTP or file manager, go to wp-content/plugins/ and rename the entire plugins folder to plugins_disabled. WordPress will auto-deactivate everything because the folder no longer exists.

   You should see: The site loads (likely with a stripped-down look). That confirms a plugin is the culprit. Rename the folder back to plugins, then reactivate plugins one at a time — testing after each — until the 500 returns and reveals the bad actor.

3. Switch to a default WordPress theme
   In wp-content/themes/, rename your active theme’s folder (e.g., my-theme → my-theme_old). WordPress will fall back to the most recent default theme it can find, such as Twenty Twenty-Four.

   You should see: If the site loads cleanly, your theme’s code is the problem. Restore the folder name, then inspect the theme’s functions.php for recent edits or contact the theme developer.

4. Increase the PHP memory limit
   Open wp-config.php and add the following line directly above the /* That's all, stop editing! */ comment:

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

   You should see: The site loads if memory exhaustion was the root cause. If your host caps memory below 256M, you’ll need to contact them to raise the server-level limit.

5. Enable debug mode and read the error log
   In wp-config.php, add these three lines:

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

   Then check /wp-content/debug.log for the actual PHP error. Your host’s error_log file in the root directory is another place to look.

   You should see: A specific error message naming the exact file and line number that caused the crash — this eliminates all guesswork and points you straight to the fix.