On this page (6 sections)
A 500 internal server error means your server hit a problem it could not classify while answering a request, and it returned no explanation. Visitors see a blank page or a short error line, and the admin area is often down too, so the tools you would normally use to investigate are out of reach.
This guide is for site owners, agencies and developers. It is a troubleshooting explainer, not a report on a specific vulnerability. The status-code background comes from a recent Sucuri guide to the 500 error, the only published source we reviewed for this topic. The step-by-step order of work and the checks below are our own general guidance.
What a 500 error tells you
The 5xx family of status codes points at the server rather than the visitor. A 500 is the catch-all for failures the server could not categorize further. Its neighbors are more specific: Sucuri describes a 502 as a bad response from an upstream server, a 503 as an unavailable or overloaded service, and a 504 as an upstream timeout.
It also rules things out. Because the request reached your server and the server tried to answer, this is not a browser, DNS or network problem. Something during that attempt failed badly enough that no usable response existed. Sucuri lists PHP, a configuration directive, a permission or a database call as typical places for that to happen.
What it looks like
The wording depends on the web server and host. You may see 500 Internal Server Error, HTTP Error 500, a message about an internal error or misconfiguration, or a blank white page. WordPress sometimes catches a fatal PHP error and shows "There has been a critical error on this website" instead, which hides the status code but reflects the same kind of failure. To confirm what you are dealing with, use your browser's developer tools (Network tab) or a command-line request.
curl -sI https://example.com/ | head -n 1The most common causes
Sucuri reports that almost every 500 traces back to a handful of causes:
- A faulty plugin, extension or theme. An update can bring code your PHP version cannot run, two plugins can define the same function, or a theme can call something that no longer exists. A fatal PHP error with nothing to catch it becomes a 500.
- A corrupt or conflicting .htaccess file on Apache. One invalid directive, a typo, a rule copied from another server, or a PHP setting your host does not allow there can take down every URL under that directory.
- PHP memory exhaustion or a PHP version mismatch, a common result of a host-initiated PHP upgrade.
- Wrong file or directory permissions, including overly permissive settings on hardened hosts.
- A failing script or external dependency, such as a cron job, custom integration or API call that hangs or returns bad data. Database connection failures can also surface this way.
How to fix it, in a sensible order
Start with evidence, then change one thing at a time so you know what actually fixed it.
- Read the error log first. The real detail lives there. Your host's control panel usually exposes it, or you can read it over SSH.
- Think about what changed just before the error: a plugin or theme update, an edit to .htaccess, a PHP version change, a new integration.
- If the log points to a plugin or theme, disable it and reload. If you cannot reach the admin area, rename its folder over SFTP or your host's file manager.
- If the log or timing points to .htaccess, keep a copy of the file, then test with a minimal known-good version.
- Check the PHP version and memory limit against what your code needs, and consider reverting a recent PHP upgrade if the log shows version errors.
- Review file and folder permissions on the files named in the log.
- Retest the status code after each change and note what worked.
sudo tail -n 50 -f /var/log/apache2/error.logsudo tail -n 50 -f /var/log/nginx/error.logWordPress specifics
On WordPress the usual suspects are plugins and themes. If wp-admin is unreachable, WP-CLI can list what is installed and deactivate a suspect plugin without the dashboard.
wp plugin listwp plugin deactivate plugin-nameWhen a 500 may point to a compromise
Most 500s are configuration or code mistakes. Sucuri's guide also addresses how to tell when a 500 is a symptom of a compromised website rather than a simple configuration mistake. We could not review the full text of that section, so the signs below are our own general guidance, not Sucuri's findings, and none of them is proof of a hack on its own.
- The error appeared with no update or edit on your side.
- The log names files you do not recognize or did not change.
- Files or an .htaccess rule changed recently without your involvement.
- New admin users, unexpected redirects or other odd behavior appear alongside the error.
If several of these apply, shift from troubleshooting to incident response. Our guides on checking whether a website is hacked and what to do when a website is hacked cover the next steps, and the free malware scanner gives an outside-in check. Outside-in scans cannot see everything on the server, as explained in what outside-in malware detection can and cannot see.
What to do now
0 of 8 done
Monitoring afterwards
A 500 is often noticed late, because it may affect only some URLs. Uptime checks that alert on error status codes shorten that gap. See uptime monitoring explained for the basics, or Webforta Monitor if you want hosted checks. Test plugin and theme updates on a staging copy where possible, and review the error log after each update. For more guides, browse the security learning hub.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.