500 Internal Server Error: Start With the Error Log
A 500 Internal Server Error means a web server encountered an unexpected condition and could not complete a request. It is an HTTP status code, a number a server uses to describe the result of a browser request, but it does not identify the underlying failure. The wider 5xx group covers server-side errors: 502 indicates a bad reply from an upstream server, 503 means a service is unavailable or overloaded, and 504 indicates that an upstream request timed out. A 500 is the catch-all response when the server cannot classify the problem more precisely.
The request has already reached the website, so a genuine 500 is not caused by the visitor's browser, Domain Name System (DNS) resolution or local network. Clearing the browser cache will not repair the server. The visible result may be a message such as “500 Internal Server Error” or “HTTP Error 500,” a completely blank page, or WordPress's “There has been a critical error on this website.” WordPress can display that last message after catching a fatal PHP error, which is a failure that forces a PHP script to stop. A blank response can still carry a 500 code, which owners can confirm through the Network panel in browser developer tools or with a command-line request.
Before making server changes, reload once and test from another device, network or outside status-checking service. A brief resource spike or recovered dependency may make the failure temporary. If everyone sees the error, the problem is on the server. If it affects only one visitor, a CDN, proxy or page cache may be retaining an old error response. A CDN, or content delivery network, stores copies of website content closer to visitors. Purging the relevant cache may resolve that limited case.
Common causes include incompatible plugins, extensions or themes, such as code that cannot run on the installed PHP version or two components declaring the same function. On Apache servers, a malformed .htaccess file can break every address beneath its directory because this file controls redirects, URL rewriting and other local settings. A typo, unsupported directive or setting copied from another server may be enough. Other causes include exhausted PHP memory, a PHP version mismatch after an upgrade, database connection failures, hanging integrations, broken scheduled tasks and invalid responses from an external application programming interface.
File access can also be responsible. The server may be unable to read a required file, or a hardened hosting environment may reject excessively open permissions. On many shared hosts, files are expected to use permission mode 644 and directories 755, with ownership assigned to the hosting account's user. A file set to 777, which permits broad access, or owned by an unrecognised user can create both operational and security concerns. The correct values can vary by hosting setup, so owners should follow their provider's documentation.
Read the error log first. An error log is a server record of failures, and it will often identify the file and line where processing stopped. Hosting control panels commonly expose it under Logs or Error Log, while providers may document separate locations for Apache, Nginx or PHP-FPM records. If that information is insufficient, enable the application's own debug logging. In WordPress, the debug and debug-log constants in wp-config.php can write fatal errors and notices to a file. Never show verbose errors publicly on a live website because they can reveal internal file paths and other implementation details.
Take a complete backup of the files and database before editing or renaming anything. Next, rename .htaccess to .htaccess_old and test again. If the site returns, WordPress users can create a clean file by saving Settings, then Permalinks. Other applications should restore directives gradually until the faulty one is identified. To test plugins, deactivate all of them and enable each one separately. When the dashboard is inaccessible, use SFTP, an encrypted method of transferring files, to rename wp-content/plugins, then restore the folder name and test individual plugin directories. Rename the active theme folder to make WordPress fall back to a default theme.
If the log reports exhausted memory, raise PHP's memory limit through the hosting controls, configuration or wp-config.php only as a diagnostic step. A component consuming far more memory than the rest of the website remains the underlying problem. If failure followed a PHP upgrade, temporarily return to the previous version to confirm compatibility, then update the incompatible code. An unsupported PHP release should not become a permanent solution. Also review permissions, ownership and recent file modification times, clear page, object, CDN and reverse-proxy caches, and give the host the exact error time and log entry if the evidence points to a database service, module or resource restriction outside the account owner's control.
WordPress has two further recovery paths. Corrupted core files can be replaced by uploading a fresh WordPress copy over SFTP while preserving wp-content and wp-config.php. An interrupted update may leave a .maintenance file in the website root; removing that file releases the site. Riskier diagnosis, including verbose error output, is better performed on a staging copy, which is a private duplicate used for testing before production.
A 500 can also indicate a compromised website. Sucuri reports patterns including injected PHP at the beginning of index.php, wp-config.php or a theme's functions.php. Such code may fail immediately or after a PHP change makes it incompatible. Attackers may also alter .htaccess with redirects, visitor-dependent rules, php_value settings or auto_prepend_file directives that the server rejects. Damaged backdoors and incomplete malware removal can produce the same result.
Warning signs include an error with no preceding update or configuration change, unexplained recent modification times, failures limited to certain visitors or people arriving from search, unfamiliar files, unexpected .htaccess files, and log entries naming unknown code. None proves compromise alone because automatic updates and caching can create similar clues. If unfamiliar code appears, run a server-side malware scan or file-integrity comparison against known-good core files, inspect .htaccess files in every directory, review recently created administrator accounts and examine access logs around the first recorded failure. After confirming an infection, remove malicious files, change hosting, SFTP, database and CMS administrator credentials, and patch the original entry point. Restoring a clean backup without closing the vulnerability can allow another infection.
A short outage is unlikely to create lasting search damage because crawlers generally retry server errors.