500 Internal Server Error: What It Means and How to Fix It

You load your own site, and instead of your homepage you get a blank page with a line of text reading 500 Internal Server Error. No explanation, no stack trace, nothing to act on. For visitors, it looks like the site is simply gone, and for you it usually means the admin area is down too, so the one tool you’d normally reach for is unavailable.

The frustrating part is that a 500 is deliberately vague. It’s the server’s way of saying “something broke while I was handling your request, and I’m not going to tell you what.” The real detail exists, but it lives in your error log, not on the page your visitors see.

In this guide, we’ll explain what a 500 error actually is, what causes it most often, how to work through the fix in a sensible order, and the part most troubleshooting guides skip: how to tell when a 500 is a symptom of a compromised website rather than a simple configuration mistake.

Contents:

• What is a 500 internal server error?
• What does a 500 error look like on your site?
• What causes a 500 internal server error?
• Is a 500 error the website’s fault or my browser’s?
• How to fix a 500 internal server error, step by step
• How do you fix a 500 internal server error in WordPress?
• Can a hacked website cause a 500 error?
• Does a 500 error hurt SEO and visitors?
• How to reduce 500 errors going forward
• Wrapping up
• Frequently asked questions

A 500 internal server error is an HTTP status code the server returns when it encounters an unexpected condition that stops it from completing the request. That’s the whole definition, and it’s intentionally broad. The 5xx family means the problem is on the server side; the 500 specifically means the server couldn’t categorize the failure any further.

Compare that to its neighbors. A 502 means one server got a bad response from another server upstream, a 503 means the service is unavailable or overloaded, and a 504 means something upstream timed out. Those at least point you in a direction. A 500 doesn’t, it’s the catch-all.

It also helps to know what a 500 is not. It isn’t a browser problem, and it isn’t a DNS or network problem. The request reached your server and your server tried to answer it. Something in the middle of that attempt- maybe PHP, a configuration directive, a permission, or a database call, failed hard enough that there was no usable response to send back.

What does a 500 error look like on your site?

The wording changes depending on the web server, the host, and whether your application managed to render anything before it gave up. You may see any of these:

• 500 Internal Server Error
• HTTP Error 500
• HTTP 500 – Internal Server Error
• Internal Server Error. The server encountered an internal error or misconfiguration and was unable to complete your request
• A completely blank white page
• “There has been a critical error on this website” in WordPress

That last one matters. WordPress will sometimes catch a fatal PHP error and show its own message instead of letting the raw 500 through, which is friendlier but hides the status code. If that’s what you’re looking at, our walkthrough of “There Has Been a Critical Error on This Website” covers the same underlying failure from the WordPress side.

A blank page with no text at all is also commonly a 500, the server returned the status code but no body. Check the status code in your browser’s developer tools (the Network tab) or with a command-line request so you know what you’re actually dealing with.

What causes a 500 internal server error?

Almost every 500 traces back to one of a handful of causes. Here they are, roughly in the order we see them cause trouble on real sites.

A faulty plugin, extension, or theme. A plugin update introduces code your PHP version can’t run, two plugins define the same function, or a theme file calls something that no longer exists. PHP throws a fatal error, and a fatal error with nothing to catch it becomes a 500.

A corrupt or conflicting .htaccess file. On Apache, .htaccess controls rewrites, redirects, and various per-directory settings. One invalid directive, a typo, a rule copied from a different server, a PHP setting your host doesn’t allow to be set there, is enough to take down every URL under that directory.

PHP memory exhaustion or a PHP version mismatch. A script that needs more memory than the limit allows will die mid-request. So will code written for a different PHP version than the one your host is now running, which is a very common outcome after a host-initiated PHP upgrade.

Wrong file or directory permissions. If the web server can’t read a file it needs, or if a file or folder is set to permissions the server refuses to execute from, the request fails. Overly permissive settings cause the same result on hardened hosts, which surprises people.

A failing script or external dependency. A cron job, a custom integration, or an API call that hangs or returns garbage can produce an unhandled error. Database connection failures often surface as a 500 as well.

Something malicious. Injected PHP and modified .htaccess rules are two of the most common things attackers leave behind, and both can break a site outright. We’ll come back to this below because the troubleshooting path is different.

Is a 500 error the website’s fault or my browser’s?

It’s the website’s. A 500 is generated by the server, so the fix has to happen on the server or in the site’s code and configuration. No amount of clearing your browser cache will resolve a genuine 500.

That said, two things are worth ruling out before you start digging, because they take seconds. First, reload the page once. If an error was momentary (a brief resource spike, a dependency that recovered), it won’t repeat. Second, check the site from another network or device, or from an outside status-checking service. If it fails for everyone, it’s the server. If it fails only for you, you may be hitting a cached error response or a stale entry at a CDN or proxy layer, and purging that cache is the fix.

If the page loads for you but not for your visitors, you may be looking at a different problem entirely, something closer to the territory covered in “This Site Can’t Be Reached”.

How to fix a 500 internal server error, step by step

Work through these in order. The sequence is deliberate. It starts with the step that tells you the actual cause, then moves through the causes by how often they’re responsible.

1. Read your server’s error log – This is the single most valuable step, and it’s the one people skip. The log will usually name the file and line number that failed. Find it in your hosting control panel (often labeled “Error Log” or “Logs”), or at the path your host documents for Apache, Nginx, or PHP-FPM error logs. Our piece on website and server logs explains what’s in each type and why keeping them accessible matters.
2. Turn on application-level debug logging – If the server log is unhelpful, enable your platform’s own error logging so PHP notices and fatal errors get written to a file rather than discarded. In WordPress that means setting the debug and debug-log constants in wp-config.php. Log to a file andnd never display errors on screen on a live site, since error output can expose paths and other internals to anyone who triggers it.
3. Rule out .htaccess – Rename .htaccess to .htaccess_old and reload the site. If the error clears, the file was the problem. On WordPress, re-save your permalink settings to generate a clean one. On other platforms, re-add directives a few at a time until the error returns so you know which one broke it.
4. Deactivate plugins and switch to a default theme – If you can reach the admin area, deactivate all plugins, confirm the site loads, then reactivate one at a time. If you’re locked out, rename the plugins directory over SFTP to disable everything at once, then rename it back and disable individual plugin folders. Do the same with your active theme by temporarily switching to a default one.
5. Raise the PHP memory limit – If the log mentions allowed memory size being exhausted, increase memory_limit through your host’s PHP settings panel, ini, or wp-config.php. Treat this as a diagnostic, not a cure. If a plugin needs far more memory than the rest of your site combined, that plugin is the real issue.
6. Check which PHP version you’re running – If the error started right after a host-side upgrade (or right after you changed versions yourself), switch back temporarily to confirm that’s the cause, then update the code that can’t run on the new version. Staying on an unsupported PHP version indefinitely is its own risk, so treat the rollback as a window to fix things.
7. Verify file and directory permissions and ownership – On most shared hosts, files are expected at 644 and directories at 755, with everything owned by your hosting account’s user. A file sitting at 777, or owned by a user the web server doesn’t recognize, is both a functional problem and a security problem worth looking into.
8. Look at what changed recently – Check the modification times on your core, theme, and plugin files. A 500 that starts with no deployment, no update, and no configuration change on your part is a strong hint that something modified your files without you (see the next step).
9. Clear every cache in the chain – Purge your page cache, object cache, CDN, and any reverse proxy. Caches can hold a 500 response and keep serving it after the underlying fault is fixed.
10. Ask your host – If the log points at something outside your control, like a resource limit, a failing database server, a server-level module, your host can see layers you can’t. Give them the exact timestamp and the log line; it saves a round trip.

Before you change anything, take a full backup of files and database. Troubleshooting a 500 involves renaming and editing files that your site depends on, and you want a way back.

How do you fix a 500 internal server error in WordPress?

The order above still applies, but WordPress gives you a few extra places to look and a few extra ways in when the dashboard is unreachable.

Start by enabling debug logging in wp-config.php so fatal errors land in a log file inside wp-content instead of vanishing. Then disable plugins by renaming the wp-content/plugins folder over SFTP. WordPress will load with everything off, and if the site comes back you’ve confirmed a plugin is at fault. Rename the folder back, then rename individual plugin directories one by one to find the culprit.

If plugins aren’t it, switch themes the same way by renaming your active theme’s folder, which forces WordPress to fall back to a default theme. After that, regenerate .htaccess by deleting (or renaming) it and re-saving Settings → Permalinks once you have admin access again.

Two WordPress-specific causes are worth checking directly. Corrupted core files can be fixed by re-uploading a fresh copy of WordPress over SFTP, excluding wp-content and wp-config.php. And a failed or interrupted update can leave a .maintenance file in the site root. Deleting it releases the site.

If you’d rather not poke at a live site blind, do this work on a staging copy where enabling verbose errors carries no risk.

Can a hacked website cause a 500 error?

Yes, and this is the part generic troubleshooting guides tend to leave out. Malicious code is still code, and badly written or environment-mismatched malicious code breaks sites the same way a buggy plugin does.

We see a few patterns regularly. Injected PHP at the top of index.php, wp-config.php, or a theme’s functions.php can throw a fatal error, sometimes immediately, sometimes only after the host changes PHP versions and the injected code stops being valid. A modified .htaccess is just as common. Attackers add redirect rules, conditional directives keyed to user agent or referrer, or php_value and auto_prepend_file directives that the server rejects, and the whole directory tree starts returning 500s. Backdoors left behind after a cleanup, or a partially removed infection, can break things too. Half a function is worse than all of it.

A few signals suggest you’re looking at a compromise rather than a configuration mistake:

• The error appeared with no update, deployment, or settings change on your side.
• File modification timestamps on core, theme, or plugin files are recent and unexplained.
• The 500 only happens for some visitors, some user agents, or visitors arriving from search (cloaked malware often behaves conditionally).
• You find unfamiliar files, or .htaccess files in directories that shouldn’t have one.
• Your error log names a file or function you don’t recognize and can’t trace to anything you installed.

None of these is proof on its own. A recent timestamp can come from a legitimate automatic update, and conditional behavior can come from caching. But when the error log points at code you never wrote, stop troubleshooting and start investigating.

The practical move is to run a server-side scan or file integrity check that compares your core files against known-good versions, review .htaccess in every directory (not just the root), check for recently added admin users, and look at access logs around the timestamp of the first 500. If you do find an infection, clean the files, change every credential such as hosting, SFTP, database, and CMS admin, and then patch whatever let the attacker in, because restoring a clean backup over an unpatched vulnerability just resets the clock.

Does a 500 error hurt SEO and visitors?

A brief 500 that you catch and fix within minutes is unlikely to cause lasting damage. Search crawlers encounter transient server errors all the time and will generally come back and try again, which is exactly why 500 is a server-error code and not a “remove this page” instruction.

Sustained 500s are a different story. If crawlers keep hitting errors over days, affected URLs can drop out of the index, crawl frequency can fall, and depending on how your site is configured, error responses may get cached and served to real people long after you think you’ve fixed things. The business cost usually arrives before the search cost. A checkout that returns a 500 doesn’t convert, and a visitor who sees a server error rarely tries again.

So the goal isn’t only to clear the error, it’s to find out quickly when one appears. Uptime monitoring that alerts on 5xx responses, and a habit of actually reading your error logs, turn a multi-day outage into a short one. If you use Google Search Console, keep an eye on the server-error reports there as a second pair of eyes on crawler-visible failures.

How to reduce 500 errors going forward

Most 500s are preventable, and the preventive habits are unglamorous. Update plugins, themes, and PHP on a staging copy before production, one change at a time, so when something breaks you already know what caused it. Keep automated backups you’ve actually tested restoring.

Keep your error logs turned on and reachable. The difference between a ten-minute fix and an afternoon of guesswork is almost always whether you could read the log line that named the failing file.

Tighten the basics that double as both stability and security measures. Use sane file permissions, no world-writable directories, unique strong credentials for hosting and admin accounts, and as few plugins as you genuinely need. Fewer moving parts means fewer things that can throw a fatal error.

And treat unexplained 500s as worth a second look rather than a reload. A 500 you can’t account for is one of the clearer invitations to check your site’s integrity. See our guide to HTTP error 403 for a related status code that malware sometimes produces in the same way.

Wrapping up

A 500 internal server error tells you that your server failed, not why. Everything useful lives one layer down in the error log, and the fastest path through the problem is to read that log first and only then start renaming .htaccess, disabling plugins, and adjusting PHP settings.

Keep the second question in mind as you work. If nothing you did explains the failure and the log points at code you don’t recognize, you may be fixing the symptom of a compromise rather than a bug. Checking that early costs you a few minutes and can save you from cleaning the same site twice.

Frequently asked questions

What causes a 500 internal server error?

Most 500 errors come from a faulty plugin, extension, or theme, a corrupt .htaccess file, PHP memory exhaustion or a PHP version mismatch, incorrect file and directory permissions, or a script or database call that fails mid-request. Injected malicious code and malware-modified .htaccess rules can cause the same failure.

Is a 500 error the website’s fault or my browser’s?

It’s the website’s. A 500 is generated by the server after your request reaches it, so clearing your browser cache won’t help. The exception worth checking: a cached 500 response at a CDN, proxy, or page cache can keep showing the error after the real cause is fixed, so purge those caches.

Can a hacked website cause a 500 error?

Yes. Injected PHP in files like index.php or functions.php can throw a fatal error, and malware-modified .htaccess directives can break every URL in a directory. Treat a 500 that appeared with no update or change on your side, or that names unfamiliar code in your log, as worth investigating.

Does a 500 error hurt SEO?

A short-lived 500 usually doesn’t cause lasting harm, since crawlers retry server errors. Sustained errors are riskier: affected URLs can drop from the index and crawl rates can fall. Monitor for 5xx responses so outages stay short, and watch server-error reports in Google Search Console.

How do I find out what’s actually causing my 500 error?

Read your server’s error log, available in your hosting control panel or at the path your host documents for Apache, Nginx, or PHP-FPM. It usually names the failing file and line number. If it’s unhelpful, enable your application’s own debug logging to a file. Never display errors on a live site.

How is a 500 error different from a 502, 503, or 504?

All four are server-side errors. A 500 is the generic catch-all: the server failed and couldn’t categorize why. A 502 means a bad response from an upstream server, a 503 means the service is unavailable or overloaded, and a 504 means an upstream request timed out.