500 Internal Server Error in WordPress: find the cause before you guess

TL;DR: A 500 error means the server encountered a fault it could not describe, and the generic page you see is deliberately uninformative for security reasons. The actual reason is almost always sitting in your PHP error log with a filename and a line number.

Nearly every guide to this error tells you to start deactivating plugins. That is guessing, and on a site with thirty plugins it can take an hour. Reading the log takes two minutes and usually names the exact file. Start there, and use the trial-and-error methods only when no log is available.

What a 500 error actually is

HTTP 500 is a server-side error status meaning something went wrong while processing the request, and the server could not produce a more specific response.

The vagueness is intentional. Detailed error output on a public page would leak file paths, code structure and configuration details useful to an attacker, so production servers suppress it and show a generic page instead.

That detail still exists. It is written to the error log rather than displayed.

For WordPress specifically, a 500 usually means a PHP fatal error: the script hit something it could not recover from and stopped. Common triggers are calling a function that does not exist, a class conflict between two plugins, exhausting the memory limit, a syntax error in edited code, or a fatal incompatibility with the PHP version.

It can also come from the web server rather than PHP: an invalid directive in .htaccess, a permissions problem preventing a file from being read or executed, or a misconfigured PHP-FPM pool.

The important distinction: 500 means the server failed, whereas a white screen with no error status usually means PHP died with display errors off, and a 503 means the server is up but temporarily unable to handle the request, typically resource limits.

Identifying which you actually have narrows the search considerably.

Step one: read the error log

This is the step that turns an hour of guessing into a two-minute fix, and it is the step most people skip.

Where to find it. On shared hosting, look for an error log in your control panel's file manager or a dedicated error log section, usually in the account root or the site's directory, often named error_log. On a VPS, PHP-FPM and web server error logs live under /var/log/, with locations varying by distribution and configuration.

What you are looking for. The most recent entries, timestamped around when the error occurred. A PHP fatal error entry includes the error type, a message, the file path and the line number.

That file path is usually the answer. If it points into wp-content/plugins/some-plugin/, you have found your culprit without deactivating anything.

Common entries and what they mean:

An "allowed memory size exhausted" message means you are out of PHP memory. Go to the memory section.

A "call to undefined function" or "call to undefined method" usually means a plugin expecting another component that is missing, deactivated, or a different version.

A "cannot redeclare" message means two pieces of code define the same function, which is a classic plugin conflict.

A syntax or parse error names the exact file and line, and if you recently edited something, that is where you look.

A "maximum execution time exceeded" message means a script ran too long, often an import, backup or migration.

If the log is empty or missing, error logging may be disabled. Move to step two.

Step two: enable WordPress debug logging

When the server log is unavailable or unhelpful, WordPress can write its own.

Add to wp-config.php, above the line that says to stop editing:

define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);

This logs errors to wp-content/debug.log without displaying them to visitors, which matters because displaying errors publicly leaks information.

Reload the failing page, then read the log. The most recent entries describe what happened.

Remove these constants once you are done. Leaving debug logging on in production grows a log file indefinitely and writes potentially sensitive detail to a location that may be publicly readable. If you must leave it on temporarily, move the log outside the web root.

If your site is completely down and you cannot reach the admin area, you can still edit wp-config.php over SFTP or through your host's file manager. That is usually how this whole process starts.

Cause: plugin or theme fatal error

The most common cause, and once the log names the file, the fix is straightforward.

If the log names a plugin, deactivate it. Without admin access, rename the plugin's folder in wp-content/plugins/ via SFTP or file manager. WordPress cannot load a plugin whose directory it cannot find, and it deactivates it automatically. The site should come back immediately.

If the log names a theme file, switch to a default theme by renaming the active theme's folder. WordPress falls back to a default theme if one is present.

If the log names a core file, the fault is usually still a plugin, because plugin code executes within core functions. Look at the full stack trace rather than only the top line.

Common triggers: a plugin update that introduced a bug or a new dependency, two plugins declaring the same function, a plugin update that requires a newer PHP version, a manual edit to functions.php with a syntax error, or a plugin updated while a dependency was not.

If you edited functions.php and the site died immediately afterwards, that is your cause with near certainty. Restore the previous version. This is also the argument for using a snippets manager rather than editing functions.php directly, since a snippets plugin can usually disable a broken snippet without taking the site down.

Once the site is back, resolve properly rather than leaving the plugin disabled indefinitely. Check for an update, check the support forum for a known issue, or find a replacement if it is abandoned. A plugin that fataled once and is left deactivated is also a plugin you should probably delete.

Cause: PHP memory exhausted

The log says allowed memory size exhausted, naming a byte figure.

PHP limits how much memory a script may use. When a script exceeds it, PHP terminates and the server returns a 500.

The immediate fix: raise the limit. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or raise memory_limit in your PHP configuration if you have access. Many hosts also expose a PHP settings panel.

Note that WP_MEMORY_LIMIT cannot exceed the server-level memory_limit, so if the server caps you at 128M, setting 256M in wp-config.php achieves nothing. Check both.

But treat this as diagnostic rather than a solution. A normal WordPress page load does not need vast amounts of memory. If you are exhausting 256M, something is wrong.

Common real causes: a plugin loading an entire large dataset into memory rather than processing it in batches. An import or migration handling a large file in one pass. Image processing on very large uploads, since resizing a high-resolution image is memory-intensive. A plugin conflict causing an infinite loop. Or simply too many plugins each holding their own footprint.

Which operation fails matters. If only imports or bulk actions fail, raising the limit is a reasonable answer since those are genuinely heavy. If normal page loads exhaust memory, raising the limit postpones the problem rather than fixing it, and you should find the plugin responsible.

On a VPS, also check whether the server has swap configured. Without it, memory pressure produces process kills rather than slowdowns, as covered in the new VPS checklist.

Cause: corrupted or invalid .htaccess

On Apache and LiteSpeed, .htaccess holds rewrite rules and configuration directives. An invalid directive produces a 500 on every request.

When this happens: after editing .htaccess manually, after a plugin wrote rules to it, after a migration where rules referenced the old server, or after a security plugin added directives your server does not support.

The test: rename .htaccess to .htaccess-old via SFTP or file manager and reload the site. If the error clears, the file was the cause.

Then regenerate a clean one. In WordPress, go to Settings, Permalinks, and save without changing anything. WordPress writes a fresh default .htaccess. Then re-add any custom rules you actually need, one at a time, testing after each.

Common offenders: a directive requiring an Apache module your server does not have loaded, duplicate rewrite blocks from multiple plugins each writing their own, a rule copied from a tutorial written for a different server configuration, or a caching plugin's rules left behind after the plugin was removed.

On nginx, there is no .htaccess, and equivalent misconfiguration lives in the server configuration, which requires server access to fix and produces errors in the nginx error log rather than PHP's.

Keep a known-good copy of .htaccess somewhere outside the site. It makes this a thirty-second fix rather than a reconstruction.

Cause	Log signal	Typical trigger	First action
Plugin fatal	Fatal error naming plugin path	Update, conflict, dependency	Rename plugin folder
Theme fatal	Fatal error in theme file	Theme update, functions.php edit	Rename theme folder
Memory exhausted	Allowed memory size exhausted	Heavy plugin, import, image processing	Raise limit, then find cause
Invalid .htaccess	Server log, not PHP log	Manual edit, plugin rules, migration	Rename file, regenerate
Permissions	Permission denied in log	Bad migration, wrong chmod	Reset to 755/644
PHP version	Undefined function, deprecated syntax	PHP upgrade by host	Revert version, update plugin
Execution timeout	Maximum execution time exceeded	Import, backup, migration	Raise limit for that task
Corrupted core file	Include or require failure	Failed update, disk issue	Reinstall core

Cause: file permissions

Incorrect permissions prevent the server from reading or executing files, producing a 500.

Correct values: directories 755, files 644, wp-config.php at 600 or 640.

Never 777. It appears in old forum advice as a fix for upload problems and it is world-writable, which on shared hosting is a genuine security exposure. Some servers also refuse to execute scripts with permissions that loose, so 777 can cause the very error it was suggested to fix.

When permissions break: after a migration where the transfer method did not preserve them, after a manual chmod, after extracting an archive as the wrong user, or after a restore.

Also check ownership, not just permissions. On a VPS, files owned by the wrong user can be unreadable by the web server process even with correct permissions. This is a frequent post-migration issue and it does not show up in a permissions listing.

Fixing at scale: set directories and files separately rather than applying one mode recursively to everything, since applying 755 to files makes them executable and applying 644 to directories makes them unusable.

Cause: PHP version incompatibility

Hosts upgrade PHP versions, sometimes automatically, and code that worked on the old version can fatal on the new one.

The signal: the error appeared without you changing anything, and the log shows undefined function calls or syntax errors in a plugin or theme you have not touched.

Check your current PHP version in the hosting panel or the WordPress site health screen.

The immediate fix: revert to the previous PHP version if your host allows it, which most do. This restores the site while you resolve the underlying issue.

Then fix properly. Update the plugin or theme that is incompatible, since the maintained ones will have released a compatible version. Replace it if it is abandoned, because an abandoned plugin blocking a PHP upgrade will keep you on an unsupported version indefinitely, which is a security problem in itself.

Test PHP upgrades on staging rather than discovering incompatibility on production. A PHP upgrade is exactly the kind of change staging exists for, and it is one of the few changes that can take down an entire site instantly.

Do not stay on an end-of-life PHP version to avoid this work. Unsupported PHP receives no security patches, and the tradeoff is not close.

When you have no log access

Some budget hosting exposes no logs at all. Then you fall back to elimination, and the order below minimises wasted time.

Rename .htaccess first. Fastest test, one file, immediate answer.

Deactivate all plugins at once by renaming wp-content/plugins to plugins-off. If the site returns, a plugin is responsible. Rename the folder back, then reactivate plugins one at a time, checking after each. Binary search is faster on a large site: enable half, test, then halve again.

Switch theme by renaming the active theme's folder, so WordPress falls back to a default.

Raise the memory limit temporarily to test whether memory is the constraint.

Reinstall core. Download a fresh copy of your WordPress version and overwrite everything except wp-content and wp-config.php. This resolves corrupted core files from a failed update.

Check wp-config.php for syntax errors, particularly if you recently edited it. A stray character breaks everything.

Restore from backup if all of the above fails and you have a known-good copy. Restoring is often faster than continued diagnosis, and this is where a tested backup earns its keep.

Contact your host. They can see logs you cannot, and for a server-level cause they are the only route. Give them the time the error occurred and what you have already tried.

FAQs

What does a 500 Internal Server Error mean in WordPress?

It means the server hit a fault it could not describe more specifically, usually a PHP fatal error. The generic page is intentional, since detailed error output would leak file paths and configuration to attackers. The actual detail, including file and line number, is written to the error log rather than displayed.

How do I find the cause of a 500 error?

Read the PHP error log first. On shared hosting it is usually accessible through the control panel, often named error_log in the account or site root. On a VPS, check PHP-FPM and web server logs under /var/log/. If no log is available, enable WP_DEBUG_LOG in wp-config.php to write errors to wp-content/debug.log.

How do I deactivate plugins without admin access?

Rename the wp-content/plugins folder to something else via SFTP or your host's file manager, which deactivates everything at once. To isolate a single plugin, rename just that plugin's directory. WordPress deactivates any plugin whose folder it cannot find, so the site should return immediately.

What causes allowed memory size exhausted errors?

A script exceeded PHP's memory limit, commonly from a plugin loading a large dataset in one pass, an import or migration processing a big file, image processing on very large uploads, or a plugin conflict causing a loop. Raising WP_MEMORY_LIMIT is the immediate fix, but if normal page loads exhaust memory, find the responsible plugin rather than raising the ceiling.

How do I fix a corrupted .htaccess file?

Rename it to .htaccess-old via SFTP and reload the site. If the error clears, that file was the cause. Regenerate a clean one by going to Settings, Permalinks and saving without changes, then re-add your custom rules one at a time, testing after each addition.

What file permissions should WordPress have?

Directories 755, files 644, and wp-config.php at 600 or 640. Never use 777, which is world-writable and a genuine security exposure, and which some servers refuse to execute anyway. On a VPS also check file ownership, since files owned by the wrong user are unreadable by the web server even with correct permissions.

Why did my site break after a PHP version upgrade?

Because a plugin or theme uses code that is invalid or removed in the newer PHP version, producing a fatal error. Revert to the previous PHP version if your host allows it, then update or replace the incompatible component. Do not remain on an end-of-life PHP version permanently, since it receives no security patches.

What is the difference between a 500 error and a white screen?

A 500 returns an explicit server error status, usually from a PHP fatal error or a web server configuration problem. A white screen with no error status typically means PHP died with display errors disabled and no error page configured. The diagnostic approach is similar, but the distinction can point you toward server configuration versus PHP.

Can a plugin update cause a 500 error?

Yes, frequently. An update can introduce a bug, require a newer PHP version, conflict with another plugin declaring the same function, or depend on a component that was not updated alongside it. This is the primary argument for testing updates on staging rather than applying them directly to a live site.

Why did editing functions.php break my whole site?

Because functions.php is loaded on every request, so a syntax error there is a fatal error on every page including the admin area. Restore the previous version via SFTP. Using a code snippets plugin instead is safer, since a snippets manager can typically disable a broken snippet without taking the entire site down.

Is a 500 error the same as a 503?

No. A 500 means the server encountered a fault while processing the request, typically a PHP fatal error. A 503 means the server is functioning but temporarily unable to handle the request, usually because of resource limits, throttling, or a service being unavailable. They point at different investigations.

Should I just restore from backup?

It is a legitimate and often faster choice, particularly if you have a known-good recent backup and cannot access logs. The caveat is that restoring without understanding the cause means it can recur, especially if the trigger was a plugin update that will be applied again. Restore to get back online, then diagnose on staging.

Conclusion

Almost every guide to this error starts with deactivating plugins. That is the last resort, not the first step.

The log has the answer, usually with a file path and a line number, and reading it takes two minutes against an hour of toggling things off. If your host exposes no logs, enable WP_DEBUG_LOG and get one.

Once you have the file path, most cases resolve immediately: rename the plugin folder, restore the edited file, revert the PHP version. The diagnosis is the work; the fix is usually seconds.

The two causes worth recognising by pattern alone are memory exhaustion, where raising the limit is diagnostic rather than curative if normal page loads are failing, and PHP version incompatibility, which appears without you changing anything because your host upgraded on their schedule.

Afterwards, close the loop rather than leaving a plugin disabled indefinitely. And keep a copy of .htaccess and wp-config.php somewhere outside the site, because those two files turn a stressful outage into a thirty-second recovery.

HostCloud gives you error log access from the control panel, PHP version selection with one-click rollback, one-click staging for testing updates safely, and automated daily backups you can restore yourself. Plans from ₹99 a month at https://hostcloud.in.