Server Errors
500 Internal Server Error
Last reviewed
Direct answer
500A 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.
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
- 01 PHP fatal error from a plugin, theme, or custom code
- 02 Corrupt or misconfigured `.htaccess` (bad rewrite or security rule)
- 03 Incorrect file or folder permissions or ownership after a migration
- 04 PHP memory limit too low for your plugin and builder stack
- 05 Database or upstream failure surfaced as a generic 500 by the host
- 06 Broken server directives after a host, Apache/nginx, or PHP-FPM change
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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? +
Will renaming plugins delete my settings? +
Can a bad `.htaccess` cause 500 on every page? +
How is 500 different from 502 or 503? +
How is 500 different from Cloudflare 522? +
Should I increase PHP memory limit permanently? +
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.