Skip to content
Website Rescue Rescue

Server Errors

500 Internal Server Error

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

500

A 500 Internal Server Error means the server reached your site but crashed while handling the request — commonly a PHP fatal, bad `.htaccess`, wrong permissions, or exhausted memory on WordPress. Read the error log first, then isolate plugins and theme and repair `.htaccess` or memory — do not keep refreshing and hoping.

HTTP 500 is a generic server-side failure. On WordPress sites it usually traces to PHP code, `.htaccess`, file permissions, or resource limits. This guide gives a safe order of diagnosis so you fix the real fault instead of changing random settings while the site stays down.

Intermediate

What the error means

HTTP 500 is a catch-all status: the browser contacted the origin (or a proxy in front of it), but something failed before a normal response could be finished. Unlike 502 or Cloudflare 522, which often mean a gateway could not talk to PHP or the origin in time, 500 usually means the application or web server configuration errored while processing. On WordPress, the same fatal that produces a white screen or critical-error message may instead surface as a branded host 500 page.

Common symptoms

  • Visitors see “500 Internal Server Error” or a host-branded error page
  • wp-admin fails with the same status, or only certain URLs return 500
  • Error logs show PHP fatal errors, memory exhaustion, or `.htaccess` complaints
  • The problem started right after a plugin, theme, core, or PHP update
  • Intermittent 500s that worsen under traffic or on checkout/heavy pages
  • Symptoms alternate with a blank white screen for the same underlying fatal
  • DevTools Network confirms status 500 (not 502, 503, or 522)

Most likely causes

  1. 01 PHP fatal error from a plugin, theme, or custom code
  2. 02 Corrupt or misconfigured `.htaccess` (bad rewrite or security rule)
  3. 03 Incorrect file or folder permissions or ownership after a migration
  4. 04 PHP memory limit too low for your plugin and builder stack
  5. 05 Database or upstream failure surfaced as a generic 500 by the host
  6. 06 Broken server directives after a host, Apache/nginx, or PHP-FPM change
  7. 07 Opcode cache serving broken bytecode after a partial plugin update

What changed before the problem started

  • Plugin, theme, or WordPress update
  • New rewrite rules, security hardening, or manual `.htaccess` edits
  • PHP version or memory limit change
  • File permission “fix” that set 777 or overly restrictive modes
  • Traffic spike exposing a fatal only under load
  • Deployment or migration that copied bad config files

Troubleshooting steps

  1. 01

    Confirm the status code, then read server error logs first

    In DevTools → Network, verify the response is really 500. Then in cPanel, Plesk, Cloudways, or your host’s log viewer, find the PHP fatal or configuration error at that timestamp. The file path usually names the plugin, theme, or line of code responsible — start there instead of guessing.

  2. 02

    Rename the plugins folder to isolate conflicts

    Via FTP or File Manager, rename `wp-content/plugins` to `plugins.disabled`. If the site loads, rename back and disable plugin folders one at a time until the 500 returns. Deactivation by rename does not delete settings stored in the database.

  3. 03

    Switch to a default theme

    Rename your active theme folder in `wp-content/themes`. WordPress falls back to a default theme — if the site works, the theme or its child setup is involved. Re-test key pages after switching.

  4. 04

    Restore or regenerate `.htaccess`

    Download a backup of `.htaccess`, then replace it with WordPress defaults (or rename the broken file and visit Settings → Permalinks → Save once admin works). A single bad rewrite or security rule can 500 every URL at once.

  5. 05

    Raise PHP memory when logs show exhaustion

    Add `define('WP_MEMORY_LIMIT', '256M');` to `wp-config.php` if logs show memory errors, and confirm the host PHP memory_limit is not lower. Folders should usually be 755 and files 644 — never leave production at 777.

  6. 06

    Enable WP_DEBUG_LOG temporarily

    Set WP_DEBUG and WP_DEBUG_LOG true with WP_DEBUG_DISPLAY false. Reproduce the 500 and read `wp-content/debug.log` for the stack trace. Turn display off so visitors never see internals.

When to stop troubleshooting

Call for help if logs point to core corruption you cannot safely replace, you cannot access files or the database, the site serves mixed 500/200 responses under load, or checkout and lead capture are down beyond your maintenance window. A 500 during revenue hours warrants dispatch when DIY isolation exceeds your access or comfort.

Information to collect before requesting help

  • 01 Exact URL returning 500 and whether wp-admin is affected
  • 02 Status code from DevTools (confirm it is really 500)
  • 03 Host error log and debug.log excerpts
  • 04 Recent plugin, theme, PHP, or `.htaccess` changes
  • 05 Whether renaming plugins or `.htaccess` changed the symptom
  • 06 Whether a CDN or Cloudflare sits in front of the origin
  • 07 PHP version, memory_limit, and hosting provider name

How a professional repairs the problem

A technician confirms the true status code, reads origin logs to the fatal or config fault, isolates plugin/theme/`.htaccess` causes, corrects permissions and PHP limits, and verifies stable responses under a quick load check — escalating to PHP-FPM or edge-timeout playbooks when the failure is actually upstream connectivity rather than application code.

Frequently asked questions

Is a 500 error always caused by WordPress? +
No. Any server-side app can return 500. On WordPress sites the usual suspects are PHP code, `.htaccess`, permissions, or the database — but server misconfiguration at the host level can also trigger it.
Will renaming plugins delete my settings? +
No. Deactivating by renaming folders only stops code from loading. Plugin settings stay in the database until you uninstall the plugin properly from wp-admin.
Can a bad `.htaccess` cause 500 on every page? +
Yes. A syntax error or conflicting rewrite rule in `.htaccess` often breaks the entire site at once. Restoring a known-good file or regenerating permalinks fixes many cases.
How is 500 different from 502 or 503? +
500 means your application or server config crashed while handling the request. 502 usually means a gateway (like nginx → PHP-FPM) could not get a valid response. 503 means the server is temporarily unavailable or overloaded.
How is 500 different from Cloudflare 522? +
522 means Cloudflare could not get a timely TCP response from your origin. You may still see problems “through Cloudflare,” but the fix targets origin uptime, firewall, and network path — not necessarily a WordPress PHP fatal.
Should I increase PHP memory limit permanently? +
Raise it enough to clear legitimate errors (often 256M for busy WordPress sites), but if one plugin constantly exhausts memory, fix or replace that plugin rather than endlessly raising limits.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.