How to fix HTTP 500 "internal server error" on WordPress
TL;DR: HTTP 500 is a deliberately generic catch-all status code meaning "something went wrong on the server" without specifying what, and WordPress sites showing it can have any of several unrelated causes: a plugin or theme conflict, a corrupted .htaccess file, a PHP version incompatibility, exhausted memory (covered separately in our memory exhausted guide), or a corrupted core file. The error page itself gives you no diagnostic information; enabling and checking the actual error log is the only reliable way to identify which specific cause applies, and skipping this step in favor of guessing is why this particular error frustrates people longer than it needs to.
Why 500 tells you almost nothing on its own
HTTP status codes are grouped by category, and the 500 range specifically covers server-side errors as opposed to client-side errors (the 400 range) or successful responses (the 200 range), but within that broad category, 500 itself is the most generic possible code, essentially meaning "the server encountered an error and cannot be more specific through the status code alone." This is different from more specific error codes that at least narrow the category (a 502 specifically implicates a reverse proxy/upstream issue, covered in our Next.js 502 guide, or a 503 specifically suggesting the server is temporarily unavailable), which is why 500 specifically requires actual log investigation rather than the status code itself providing useful diagnostic direction.
Step 1: check the actual error log
Since the error page provides no useful diagnostic information on its own, the single highest-value action is enabling WordPress's debug logging (WP_DEBUG and WP_DEBUG_LOG set to true in wp-config.php, the same approach covered in our memory exhausted guide and admin white screen guide) and reproducing the error, then checking wp-content/debug.log for the specific underlying issue, which nearly always names a specific file, plugin, or PHP-level error rather than the generic 500 the browser shows.
If WordPress's own debug log does not capture anything useful (which can happen if the error occurs at a level below WordPress's own error handling, such as a server configuration issue), checking your hosting account's own PHP error log or server error log directly, usually accessible through your hosting control panel, is the next place to look, since this often captures errors that occur before WordPress's own logging mechanism engages.
Cause 1: a plugin or theme conflict
This is the most common cause by a meaningful margin, similar in nature to the admin-area white screen scenario but capable of affecting the entire site rather than just the admin context. A plugin or theme with a PHP-level fatal error, from a bug, an incompatibility with your current PHP version, or a conflict with another active plugin, can trigger a 500 error site-wide if the problematic code executes on every page load rather than only in an admin-specific context.
If the debug log points at a specific plugin's file, deactivating that plugin via FTP (renaming its folder in wp-content/plugins, since wp-admin access may itself be blocked by this error) typically resolves it immediately, confirming the cause directly and letting you investigate an update or alternative for that specific plugin with the site restored to working order in the meantime.
Cause 2: a corrupted .htaccess file
On Apache-based hosting, a corrupted or improperly formatted .htaccess file, whether from a manual edit gone wrong, a plugin that wrote an invalid rule, or file corruption during a migration, can cause the web server itself to fail processing requests entirely, producing a 500 error before WordPress's own code even begins executing, which is also why this specific cause sometimes does not appear in WordPress's own debug log at all, since the failure happens at a layer below WordPress.
The standard diagnostic step: rename your current .htaccess file (via FTP) to something like .htaccess-backup, then check whether the site recovers. If it does, the file was indeed the cause, and generating a fresh, default .htaccess file (WordPress regenerates a standard one automatically if you visit Settings → Permalinks and re-save, once the site is accessible again) resolves it, after which any genuinely necessary custom rules from the original file need to be manually re-added rather than assuming the default file alone covers everything the original contained.
Cause 3: a PHP version incompatibility
Particularly after a hosting migration or a server-side PHP version upgrade performed by your host, a plugin or theme using code patterns incompatible with the current PHP version (either code written for an older PHP version using since-removed functionality, or, less commonly, a plugin not yet updated for compatibility with a very recently released PHP version) can trigger fatal errors presenting as a 500.
Checking your current PHP version (visible in your hosting control panel, or via a temporary phpinfo file as covered in our image upload guide) against your plugins' and theme's stated minimum and maximum supported PHP versions helps identify this specific cause; if a recent PHP version change coincided with the error's start, this is worth investigating directly, either by reverting to the previous PHP version temporarily (if your host allows) while updating the incompatible plugin, or updating the plugin/theme to a version confirmed compatible with your current PHP version.
Cause 4: a corrupted core file
Similar to the corrupted-file scenario covered in our maintenance mode guide, an interrupted WordPress core update or a file corrupted during a migration can leave WordPress's own core files in an inconsistent state, capable of producing a 500 error if the corruption affects a file that executes on every page load. Re-uploading a fresh copy of WordPress core files via FTP (carefully excluding wp-content and wp-config.php, which contain your actual site content and configuration and should not be overwritten) resolves this specific cause directly if the debug log or elimination process points toward a core file issue rather than a plugin, theme, or .htaccess cause.
A diagnostic table
| Check | What it tells you |
|---|---|
| debug.log points to a specific plugin file | Cause 1: plugin/theme conflict |
| Renaming .htaccess resolves the error | Cause 2: corrupted .htaccess |
| Error started right after a PHP version change | Cause 3: PHP incompatibility |
| debug.log points to a WordPress core file, or none of the above apply | Cause 4: corrupted core file |
| debug.log shows nothing at all | Check hosting-level PHP/server error logs directly |
If the error log shows nothing useful
If both WordPress's own debug log and your hosting account's server-level error logs show nothing helpful, a systematic elimination process is the fallback: rename .htaccess first (fastest, lowest-effort check for Cause 2), then deactivate all plugins via FTP and reactivate one at a time while testing after each (isolating Cause 1), then switch to a default WordPress theme temporarily if plugin deactivation alone does not resolve it (isolating whether the theme itself is the cause), and finally consider a fresh core file upload if none of the above identify the issue (addressing Cause 4). Working through this systematically, rather than randomly trying fixes, ensures you do not miss the actual cause or waste time repeating ineffective attempts.
FAQs
Can I see the actual error without enabling debug logging, just by looking at the page?
Generally no on a properly configured production site, since displaying raw PHP errors directly to visitors is a security risk most hosts and WordPress configurations deliberately disable in production; enabling WP_DEBUG_LOG specifically (which logs to a file rather than displaying errors publicly) is the correct, safe way to see the actual underlying error without exposing it to visitors.
Is a 500 error always caused by something I or my developer changed recently?
Not always, though it is the most common pattern; a 500 error can also result from an automatic update (core, plugin, or theme auto-updates), a server-side change made by your host (a PHP version upgrade, for example), or in rarer cases, file corruption unrelated to any deliberate change, which is why checking recent changes is a good starting hypothesis but not something to assume with certainty before checking logs.
Does a 500 error mean my site has been hacked?
Not typically; while a compromise can in some cases produce this error (particularly if malicious code injected into a file causes a fatal PHP error), the far more common causes are the four covered in this guide, unrelated to any security compromise; if you have specific other reasons to suspect a hack (unfamiliar admin users, unexpected file changes), our hacked site guide covers that specific scenario separately.
How do I access my site's files if wp-admin itself is inaccessible due to the 500 error?
FTP/SFTP access, or your hosting control panel's file manager, works independently of WordPress's own admin interface, since it accesses the file system directly rather than going through WordPress's own (currently broken) code; this is the standard method for troubleshooting any error severe enough to make wp-admin itself inaccessible.
Will my hosting provider fix this for me automatically?
Some hosts, particularly managed WordPress hosting providers, offer direct troubleshooting support for exactly this kind of error as part of their service; checking your specific hosting plan's support scope and contacting them directly, especially if you are not comfortable working through the diagnostic steps yourself, is a reasonable and often faster path to resolution.
Does this error affect SEO if not fixed quickly?
Yes, a persistent 500 error makes the site completely inaccessible to search engine crawlers as well as visitors, which can lead to a temporary drop in search visibility or crawl frequency if the outage persists for an extended period, making prompt resolution important both for visitors and for search engine relationship reasons.
Can a caching plugin cause a 500 error?
Yes, in some cases, particularly if a caching plugin's own code has a bug or conflicts with another active plugin, similar to how any other plugin could be the Cause 1 culprit; if a caching plugin was recently installed or updated around when the error started, it is worth including in the plugin deactivation testing process rather than assuming caching plugins are exempt from being the cause.
Conclusion
HTTP 500 is deliberately uninformative on its own, and the productive path to fixing it always runs through checking the actual error log, WordPress's own debug log first, then hosting-level server logs if that shows nothing, rather than guessing at one of the four common causes without evidence. Plugin and theme conflicts are the most common cause by a wide margin, followed by corrupted .htaccess files, PHP version incompatibilities, and corrupted core files.
If logs provide no clear direction, a systematic elimination process, starting with the fastest checks (.htaccess rename) before moving to more involved ones (plugin-by-plugin deactivation), resolves the issue more reliably than randomly trying fixes in an arbitrary order.
HostCloud's hosting support can check server-level logs directly on your behalf within minutes, and our managed WordPress plans include PHP version management tools to avoid Cause 3 entirely during routine server updates. Plans start at ₹99 a month at https://hostcloud.in.