500 Error on a Website: How to Fix It — Step-by-Step Guide
Wondering how to fix 500 internal server error on a website? It often shows up not on a calm weekday, but right when traffic spikes, an ad campaign launches, or right after another update. Error 500 means an internal server error: the page did not return a response, but the browser did not get an exact reason either — just a generic failure signal. It is frustrating, but it can be diagnosed. Almost always.
The good news is that a 500 error rarely appears out of nowhere. Most often it is caused by broken code, a failed PHP process, a damaged .htaccess file, conflicting plugins or a theme, or a server hitting memory and execution-time limits. The host can also be the culprit. Or the latest commit.
If the site already brings in leads or sales, even 10 minutes of downtime hurts both revenue and trust. That is why the order of actions matters more than guesswork: first isolate the problem, then change settings. No chaos.
1. What a 500 error means and why it appears
Internal Server Error is not a diagnosis, but an umbrella term for several failures. The server received the request, tried to process it, and ran into a problem it could not show to the user in a proper way. Outwardly, it all looks the same: a white page, an error message, sometimes a blank screen.
There are 5 most common causes. The first is a PHP code error after editing a template or function. The second is incorrect rules in .htaccess. The third is a plugin or theme conflict. The fourth is a lack of resources: memory_limit, max_execution_time, CPU time. The fifth is a server- or hosting-side failure. And there is a sixth, very ordinary one: file permissions are set incorrectly.
On WordPress and similar CMS platforms, this is especially noticeable after updates. One plugin updates, another does not, cache remains old, and the theme calls a function that has already been removed. The result is a short but unpleasant cascade. Error 500 likes that kind of combination, which is why WordPress 500 error troubleshooting often starts with updates, cache, and compatibility checks.
If the site is built as a web application, the chain can be longer: API, task queue, database, external payment service. In projects like that, it is useful to think ahead about website security and backup recovery logic, because one incident without event logs turns troubleshooting into guesswork.
2. First, check where exactly the error occurs
The first step is to understand the scope. Is the 500 error only on one page? Or on the entire site? Or maybe it appears in the admin area while the public-facing part still loads? These 3 cases point to different causes, and that scope check is the fastest website 500 error fix starting point.
If the error appears only on one page, look for local code: a shortcode, widget, form, custom template, or embedded script. If the whole site is down, check .htaccess, PHP, and system limits. If the admin area does not open, inspect plugins and the theme. After an update, the issue is often hiding there.
A 500 error also often appears after moving to a new host. PHP settings may differ, folder permissions may differ too, and old config rules do not always fit the new environment. One migration. One surprise.
It helps to note when everything broke: after installing a plugin, changing the theme, switching the PHP version, or moving the site. That small timeline saves hours. Sometimes a whole day.
3. How to check .htaccess and plugins
.htaccess is a common culprit. One wrong directive is enough for the server to start returning 500 errors on almost every page. Especially if redirects, caching rules, or pretty permalinks were edited manually.
The simplest test is to temporarily rename the .htaccess file, for example to .htaccess_old. If the site comes back to life, you have likely found the cause. Then create a new file and resave the permalink settings in the CMS admin panel. In WordPress, this is done through the Permalinks section, without manually copying rules.
If the error disappears after recreating the rules, it is better not to bring the old file back. It may still contain an extra line, for example from an old plugin that has already been removed. One extra directive can bring down the entire site. Not just in theory.
When a site uses a complex redirect structure, especially after a redesign, it is worth checking in advance how old URLs and canonical links behave. For projects with a structural refresh, it can help to read about how to choose a web studio for a website redesign, so you do not end up with confusion in server rules and internal routes.
4. Disable plugins and check the theme
If .htaccess is clean, move on to plugins. On WordPress, this is quick: rename the plugins folder through the file manager or FTP. All plugins will be disabled at once. If the 500 error disappears, the cause is one of them.
Then enable the plugins one by one. Check the site after each activation. That is how you find the conflicting module, even if there are 17 of them. Tedious? Yes. Works? Also yes.
Typical offenders are caching, security, SEO, page builder plugins, and any extensions that interfere with routing or content generation. Sometimes the problem is not the plugin itself, but an outdated version of it. That tends to surface especially after an update.
Do the same with the theme: temporarily switch to the CMS default theme. If the admin area is unavailable, rename the active theme folder through FTP so the system falls back to a backup option. If the 500 error disappears, the theme contains a broken template, an incompatible hook, or an old function call.
When the site is tied to external services, such as payments, the integration code can sometimes trigger the error. In such cases, it helps to assess the payment flow and update risks in advance. For example, take a look at how much it costs to connect Stripe to a website if you have similar integration and redirect logic.
5. Check PHP errors and server limits
If plugins and the theme are not the issue, look at the logs. PHP error logs usually show which file, line, or function failed. Sometimes they say it directly: Allowed memory size exhausted. Sometimes: fatal error. Sometimes: nothing at all, which is worse.
Logs may be in the hosting control panel, in a separate site folder, or in the server’s system reports. Different providers store them in different places, so the hosting panel is usually necessary here. Check at least 2 places: the site error log and the account system log.
Now to PHP settings. Look for memory_limit, max_execution_time, upload_max_filesize, post_max_size, and the PHP version. If the site started crashing after a PHP version upgrade, rolling back to a compatible version often solves it. If memory is too low, a heavy page, import, or plugin simply does not have enough time to finish.
The memory_limit setting is especially important for stores and large catalogs. One product export can use up the full resource pool. One import form can too. If the site uses analytics, queues, background tasks, and monitoring, it is worth having a site analytics and monitoring platform · as part of your observation stack, so you can see outages from logs rather than from a customer complaint.
If you are not sure where to check the settings, ask your host to show the current PHP configuration and server limits. Verify not only the PHP version, but also the actual memory limit, execution time, and upload size. It is surprising how often the problem is just one value.
6. Clear the cache and review recent changes
Cache can hide both the problem and the fact that it is gone. So after making changes, clear the site cache, browser cache, and CDN cache if you use one. Otherwise you will be looking at an old version of the error and thinking nothing changed.
First clear the cache in the CMS panel or in the caching plugin. Then clear the browser cache, preferably in incognito mode. If the site is served through a CDN, purge that too. Three places, three caches, one result — only after a full clear can you trust the test.
Next, review the latest changes. Added a new block? Changed a function in the template? Uploaded a fresh file to the library? Roll back the last change and test again. A 500 error often appears after one small line of code, not after a “major update.”
In projects with ongoing support, these issues are usually less common because code and settings changes go through control. If your site is active and regularly improved, the article on website support after launch can help you see how not to let cache and updates drift into an outage state.
Also check whether the CDN broke after SSL changes, redirects, or a security policy update. One wrong response header can trigger a 500 error for only part of your users. And that is much harder to catch.
7. What to do if the 500 error will not go away
If the site is still crashing after all checks, it is time to work systematically. Start by contacting hosting support and request logs for the exact time of the failure. Give the hour, date, and the page where the 500 error occurred. Without that, support will take longer to find it.
Then check file and folder permissions. People often set folders to 777 “temporarily” and then forget to change them back. That is bad practice, and not only because of the 500 error: the server may block such permissions for security reasons. Files and directories should have correct permissions.
If you have a fresh backup, restore the working version of the site and see whether the failure disappears. This is especially useful after a bad core, plugin, or server migration update. One rollback saves more time than trying to manually fix 12 incompatible changes.
When the site matters to the business, do not delay recovery. Sometimes it is cheaper to restore yesterday’s copy than to spend half a day hunting for one line of code. And if the project relies on external requests, forms, and APIs, check the network side too: sometimes the problem is not in the CMS, but in the infrastructure. For cases like that, a private network infrastructure can help when part of the complexity moves into a controlled environment.
The last practical step is to temporarily switch the site to a minimal configuration. Keep only the core, one theme, one working plugin, and the basic rules. If the 500 error disappears in that mode, add components back one at a time. That way you will find the problematic element without unnecessary guesswork. It is slow, but honest.
