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

What is a 500 Internal Server Error?

A 500 Internal Server Error is a generic HTTP status code. It means the server hit an unexpected condition and could not find a more specific 5xx code to describe it. The problem sits on the server side. Most of the time the cause is a broken configuration, too little memory, or application code that fails.

We wrote this guide for website and store owners, and for developers who manage their own VPS or cPanel account. The goal is simple: when you see a 500 error, you follow a clear diagnostic order instead of deleting files at random.

We are a digital marketing and web team, not a hosting company. So this guide leans on the MDN status code reference, RFC 9110, and the official WordPress, Apache and cPanel documentation. If we were not sure about a command or a default value, we left it out.

Who is responsible for a 500 error: the visitor, the site owner or the server admin?

In short, the answer is the server side. MDN says that visitors who see 500 errors are hitting issues that server owners or administrators must investigate. Still, each role can do something useful.

• Visitor: Reload the page once, wait a few minutes, then try again. Beyond that there is nothing to fix, because the problem is not on your device.
• Site owner: First, think about what changed right before the error. For example, a plugin update, a theme switch or a new code file is often the culprit.
• Server admin: Then read the error log, test the configuration and check resource usage.

On shared hosting, your hosting provider is the server admin. So some steps belong to them alone. On a VPS, however, that role is yours.

What does a 500 error look like on screen?

First, the text you see depends on the server, the browser and the theme. Sometimes you get a plain "500 Internal Server Error" line. Other times, the browser shows its own message, such as "this page isn't working". Some sites also use a custom-designed error page.

So check the HTTP status code, not the wording. The Network tab in your browser's developer tools shows it. On the command line, this command prints the real code:

curl -I https://example.com/

For example, if the first line of the output reads HTTP/2 500, the server really returns a 500. Also note that a page can show an error message and still answer with a 200 code. That is a soft error, and it is a separate problem for Google. Our soft 404 guide covers it in detail.

For a quick check of whether your site loads at all, try our is it down tool.

What are the most common causes of a 500 Internal Server Error?

MDN lists improper server configuration, out-of-memory problems, unhandled exceptions and improper file permissions as possible causes. In practice, this list narrows to a handful of concrete scenarios. The table below pairs each cause with its typical symptom and the first place to look.

These six causes cover many cases, but we do not claim they cover every case. Still, the error log always gives a more precise answer than any table.

Where should you start diagnosing a 500 Internal Server Error?

Random trial and error turns one problem into two, because every change adds a new variable. So start with the step that carries the least risk and gives the most information. The order below is therefore the most sensible flow in most situations.

1. Find out whether the error hits the whole site or a single page.
2. Then read the error log and note the message.
3. Next, undo the change you made right before the error.
4. Disable the .htaccess file temporarily.
5. After that, check the PHP version and the plugins.
6. Look at the memory limit and the file permissions.
7. If nothing works, write to hosting support and include the log line.

Retest the page after every step. That way, you know which step fixed the problem, and you save time when the same error returns.

What if the 500 error only appears on certain pages?

The scope of the error is the fastest way to narrow down the cause. An error on the whole site usually points to a shared file, such as .htaccess, wp-config.php or the PHP configuration. However, an error on a single page points to the plugin, template or database query that page uses.

To find the scope, ask these questions in order:

• Does the home page load, or does only one address fail?
• Does the admin area load? If it does, then the problem may sit in a front-end plugin or theme.
• Does the error appear only when you submit a form or reach the payment step?
• Do logged-in and logged-out visitors see the same result?

Here is a hypothetical flow, not a real case: the home page loads, but product pages return a 500. In that situation, you suspect the product template or the product plugin. So instead of touching the whole site, you deactivate only the related plugin.

How can a cache or CDN hide or prolong a 500 error?

You can fix the problem and still see a 500 on screen. A caching plugin, a server cache or a CDN may have stored the error page, because caches keep what they last received. So do not trust the result until you clear the cache.

The reverse also happens. However, a cache can make some pages of a broken site look healthy. You then miss the problem, while pages without a cached copy fail. Test in the browser and on the command line.

curl -I "https://example.com/page/?test=1"

A random parameter often forces a fresh request, but this behavior is not the same on every setup. For the logic of caching on the PHP side, read our OPcache guide.

If you use a CDN, separate two cases: the error comes from the CDN, or it comes from your origin server. Also, the page that appears usually tells you who produced the error.

Where do you find the error log?

The error log is the most valuable source for a 500 diagnosis. So the Apache documentation also tells you to check the httpd error log when you get server errors. In other words, the log shows what broke, in which file and on which line.

In cPanel, the Errors screen under Metrics shows up to the 300 most recent web server error entries, in reverse chronological order. However, your host may have disabled this feature. Also, some setups create an error_log file in your site folder where PHP writes; whether it exists depends on the configuration.

On a VPS, though, the log location depends on the distribution and the configuration. To find the right path, look at the ErrorLog directive in Apache or the error_log directive in Nginx. You can read the last lines like this:

tail -n 50 /path/to/error.log

Replace the path above with the real file path from your own configuration. To watch the log live until the error repeats, you can use tail -f.

How does a broken .htaccess file cause a 500 error?

According to the WordPress documentation, the most likely issue is a corrupted .htaccess file. The Apache documentation also shows that a wrongly written directive writes lines such as "bad flag delimiters" or "not allowed here" to the log, and the server returns a 500. So a single wrong character can take down the whole site.

For diagnosis, do not delete the file. Instead, rename it. In your site root, use FTP or the cPanel File Manager and follow these steps:

1. Rename .htaccess to .htaccess_old.
2. Then reload the site. If the error disappears, this file is the culprit.
3. Finally, on WordPress, open Settings, then Permalinks, and click save. WordPress generates a fresh file.

For example, a standard WordPress file looks like this. Any lines outside this block in your own file may have been added later:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Renaming the file also removes your security and redirect rules. So keep the old file, find the faulty line, and fix only that line.

Can a PHP version or plugin mismatch cause a 500 error?

Yes. If an old plugin or theme calls a feature that a newer PHP version removed, PHP cannot run and the server may return a 500. The reverse happens too, so keep both directions in mind: new code may need a feature that an older PHP version lacks. Therefore the log usually records this as a fatal error.

When the error starts after an update, follow this order:

• Find the path of the file that throws the error in the log. A path under wp-content/plugins points to a plugin, and one under themes points to the theme.
• Then switch the PHP version to the previous one in your hosting panel and test again.
• Check which PHP versions the plugin or theme developer supports.

We cover the cPanel steps for changing the PHP version in a separate sibling article, so we do not repeat them here. For PHP performance, see our OPcache settings guide.

On a production site, take a backup before you switch versions. Rolling back the version is an escape, not a fix. In practice, the real goal is to run compatible code.

Can a low memory_limit trigger a 500 error?

It can. If a PHP script exceeds the memory it is allowed to use, then it stops. The log usually contains a message saying the allowed memory size is exhausted. MDN also lists out-of-memory problems among the possible causes of a 500.

Instead of guessing, the WordPress documentation suggests raising the PHP memory limit through wp-config.php. The line below is only an example value, because your real need depends on your plugins:

define( 'WP_MEMORY_LIMIT', '256M' );

Add this line to wp-config.php before the "That's all, stop editing!" comment. If your host sets a global upper limit, this line alone may not be enough. In that case, raise the memory_limit value in php.ini or in the panel settings.

Raising the limit again and again is not a fix, though. If one plugin keeps growing, however, that plugin is the real problem. For related slowdown symptoms, read our article on server-side causes of a slow website.

Should file and folder permissions be 755 and 644?

On most shared hosting, 755 for folders and 644 for files is a common and safe starting point. MDN lists improper file permissions among the causes of a 500. Also, some hosting setups also reject very open permissions, such as 777, for security reasons, and that can show up as a 500.

On your own VPS, or on an account with SSH access, run these commands only inside the site folder:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

First confirm which folder you are in with pwd. If you run the commands in the wrong folder, you can break the permissions of system files. Also, sensitive files such as wp-config.php may need stricter permissions, so follow your host's advice.

File ownership matters too, because permissions alone do not decide access. If the files belong to the wrong user, the server cannot run them even when the permission numbers are right. So hosting support usually solves this faster.

How do you disable plugins and themes on WordPress?

If you cannot reach the admin area, you disable plugins at the file level. The WordPress documentation suggests deactivating all plugins first to see whether the problem comes from a plugin. Then it suggests switching to a default theme.

1. First, open the wp-content folder with FTP or the File Manager.
2. Then rename the plugins folder to plugins_old. All plugins go inactive.
3. Next, reload the site. If the error is gone, rename the folder back and enable the plugins one by one.
4. If the error stays, then rename the active theme's folder under themes. WordPress falls back to a default theme.

If you have SSH access and WP-CLI, this command deactivates all plugins:

wp plugin deactivate --all

If that still does not help, the WordPress documentation also suggests re-uploading the wp-admin and wp-includes folders from a fresh install. Do not touch your wp-content folder or your wp-config.php file.

How do you turn on WordPress debugging with WP_DEBUG?

If the server log does not tell you enough, you can switch on WordPress's own error log. Instead, the official debugging documentation introduces three constants. WP_DEBUG is the main switch, WP_DEBUG_LOG writes errors to a file, and WP_DEBUG_DISPLAY decides whether errors show on the page.

The setup recommended in that documentation logs errors but hides them from visitors:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Add these lines to wp-config.php before the "That's all, stop editing!" comment. Then the records go to the debug.log file in the wp-content folder.

The documentation also warns you: debugging tools are not recommended on live sites, and they are meant for local and staging installs. Still, if you must use them on a live site, switch them off as soon as you finish. Delete debug.log too, because the file can contain details such as file paths.

How do you fix a 500 Internal Server Error in cPanel?

On cPanel shared hosting, your tools are limited. Even so, most 500 cases fall to these tools. Work in order and test the site after each step.

1. First, open the Errors screen under Metrics and read the latest entries.
2. Show hidden files in the File Manager, find .htaccess and rename it.
3. Then check the PHP version and its extensions.
4. Check your disk and inode usage. So a full account cannot write new files.
5. Disable plugins or the theme at the file level, as described above.
6. Finally, consider restoring the last backup. If you have no backup routine yet, read our website backup strategy guide.

If none of these steps works, copy the log line and send it to hosting support. Also, the support team sees server limits and configuration far faster than you can.

How do you diagnose a 500 error on a VPS with Apache or Nginx?

On a VPS, you carry full responsibility for the server. First, test the syntax of the configuration. The command apachectl -t for Apache, or nginx -t for Nginx, tells you whether the configuration files contain errors. These commands may need privileges, so add sudo in front when they do.

Next, look at the resource state:

free -h
df -h
df -i

The first command shows memory, the second shows disk space, and the third shows the inode count. So if memory ran out or the disk filled up, the server can throw unexpected errors.

If you use PHP-FPM, then check whether the service runs with systemctl status. The service name changes with the distribution and the PHP version, so confirm the name on your own system. If an application server sits behind Nginx, you must separate upstream 502 and 504 errors from a 500.

Before every configuration change, copy the file first. After the change, always test the syntax before you reload the service.

Do database problems cause a 500 error?

Sometimes they do, but WordPress usually shows a separate message for a database connection problem. Still, depending on your application and configuration, the same problem can also appear as a 500. So if you see a database-related line in the log, follow that path too.

These are the points to check:

• Are the database name, user and host in wp-config.php correct?
• Did the database user's password change recently?
• Did your hosting account run out of database quota or disk space?
• Does the database server run? On shared hosting, only your provider can see that.

Also, if a plugin sends a faulty query to the database, the error still lands in the log. For the backup and restore side, take a look at our database backup guide. Be careful when you store passwords in such files, and never write them anywhere public.

How do you track a 500 error in Search Console?

Even after you fix the error, Google needs time to notice. The Page indexing report in Search Console lists pages that could not be indexed because of a server error (5xx) under a separate heading. The Crawl stats report also shows how server responses developed over time.

After the fix, follow these steps:

1. Run a live test on an affected address with the URL Inspection tool.
2. If the page returns 200, start validation for the matching issue in the report.
3. Watch the crawl stats for a few days.
4. If the error returns, match the log entries against the time stamps.

We cannot say how long Google needs to finish validation. The report interface may also change over time, so confirm the menu names in your own account. For the basics, see our Search Console guide.

What happens to users and Google during a 500 Internal Server Error?

For visitors the effect is obvious: pages do not load, carts do not complete and forms do not send. In e-commerce, that means lost orders. We cannot predict how many orders you would lose, but the longer the error lasts, the bigger the loss.

On the Google side, the official documentation is clear. 5xx and 429 errors make Google's crawlers slow down crawling temporarily. Google ignores any content it receives from a URL that returns a 5xx status code. As more URLs return server errors, the crawl rate drops in proportion.

A persistent error is more serious. According to the documentation, the indexing pipeline removes URLs that persistently return a server error from the index. The documentation gives no exact time frame. Once the server returns 2xx again, Google gradually raises the crawl rate.

To understand why crawling slows down, read our article on why Googlebot crawls less. To read server logs, our log file analyzer helps.

What is the difference between 500, 502, 503 and 401?

Each code describes a different problem, so do not apply the same fix to all of them. A 500 is a generic server error. Meanwhile, a 502 and a 503 point to different places in the server chain. In contrast, a 401 is not a server fault at all; it is an authentication state.

We are preparing separate sibling articles for each of these codes. Here we only show the difference, because each one has its own diagnostic order. RFC 9110 is the primary source for the boundaries between the codes.

For a 403 that comes from a firewall, see our article on ModSecurity and 403 errors.

When should you leave the problem to your hosting provider?

Not every 500 error is yours to fix. In some cases, the right move is to write to hosting support without wasting time. To be honest, a wrong intervention can turn a small problem into a big one.

• You have no access to the error log, and the Errors screen is disabled in the panel.
• The error started on several of your sites at the same time. The problem most likely sits on the server.
• A log message mentions disk, quota or server services.
• You cannot read configuration files and you run a live store.
• You have no backup. Back up first, then intervene.

In your support ticket, include the time the error started, the change you made before that time, the line you copied from the log, and the steps you tried. With this information, the fix comes faster.

How do you stop a 500 error from coming back?

Fixing the error is only half the job. To keep it from returning, you need a few routines. They do not need a big investment, but they do need discipline.

• Staging site: Test updates on a copy first, then move them to the live site.
• Backup: Take a backup before changes, and test a restore at least once.
• Version fit: Check plugin and theme support before you change the PHP version.
• Monitoring: Set up a monitoring service that checks the status code of your site regularly.
• Change log: Write down what you changed and when.

Hosting choice matters as well, because resource limits and support quality shape how often these errors appear. For selection criteria, read our guide to choosing web hosting.

What should you avoid while troubleshooting?

Hasty moves make problems bigger. So treat the risks below as a checklist.

• Never delete files: A rename can be undone, and a deletion cannot.
• Avoid 777 permissions: It creates a security risk and can make the error worse on some setups.
• Keep error display off on a live site: Error details on the page can expose file paths.
• Always work with a backup: Back up first, then change.
• Change one thing at a time: Otherwise you will not know which change worked.

The last rule matters most: if you change five things at once, you cannot learn the cause.

How do you record the root cause after the fix?

Do not close the topic just because the error is gone. If you do not know the cause, the same problem comes back, maybe at a worse moment. A short incident note saves time for your team and for you later.

The note only needs these headings:

• When did the error start and when did it end?
• What were the log message and the affected file?
• Which change came right before the error?
• What fixed it in the end?
• Which new rule did you add to prevent it?

For example, if a plugin update caused the error, you make it a rule to test updates on staging first. That way the same error does not reach the live site a second time. Also, the note works as evidence when you write to a hosting provider.

Even small businesses benefit from this habit. In other words, the aim is not a perfect process but avoiding the same error twice. So keep the note short, but write one for every incident.

What is a quick checklist for a 500 error?

In short, a 500 Internal Server Error is a generic server error, and you find the answer in the error log. The list below gathers this whole article at a glance. When the error hits, follow it from top to bottom.

1. Confirm the status code. Is it really a 500?
2. Check whether it hits one page or the whole site.
3. Read the error log.
4. Undo the last change.
5. Test by renaming the .htaccess file.
6. Disable plugins and the theme.
7. Check the PHP version and the memory_limit value.
8. Check file permissions.
9. Look at disk and memory state.
10. If you cannot solve it, write to hosting support with the log line.

You can also read the sources behind this guide yourself: the Google Search Central HTTP and network errors page, the WordPress common errors page, the Apache .htaccess tutorial, the WordPress debugging page and the cPanel Errors page.