500 error: what it is, how to fix it and what Google does

A 500 error (500 Internal Server Error) is the response a server sends when something failed inside and it cannot explain what. This is how I picture it: Black Friday is a month away, someone pushes a change on a Thursday at 6 p.m., the website loads perfectly from the office and everyone goes home. What nobody saw is that category pages with two active filters have been returning a 500 error since that moment, and that Googlebot has spent the whole night requesting them.

The guides ranking on Google today explain well what an internal server error is and how to fix it in WordPress. My take, after reviewing large sites, is that the 500 error that costs the most is the one nobody sees from the office: the one that shows up on a single template, with certain parameters or only for bots. You find it by cross-checking Search Console with the server logs, and you prioritize it based on the URLs that sell. Here is what it means, what causes it, how to fix it and what Google does when it finds one.

What is a 500 error?

The 500 error is an HTTP status code from the 5xx family, the server errors. It says something pretty vague: the server received your request, tried to process it, ran into a situation it does not know how to handle and cannot be more specific. That is why it is called "generic": it is the drawer where failures without their own code end up.

The analogy that works best for me is calling a restaurant to book a table and hearing "we had a problem in the kitchen" right before they hang up. The restaurant exists and your call got through. Something burned inside and nobody is going to tell you what.

The message changes with the web server and the site's configuration. The most common ones:

• 500 Internal Server Error
• HTTP 500
• HTTP Error 500
• Internal Server Error
• A screen with the brand's logo that says "something went wrong"

If the server runs Microsoft IIS, it sometimes shows up with decimals (500.19, 500.13) that point to a more concrete cause, such as an invalid configuration or an overloaded server. Google does not care about that design: it reads the status code the URL returns and decides what to do based on that.

What causes a 500 error?

The causes repeat from site to site:

• Code errors. An unhandled exception, a syntax error or a freshly deployed change that breaks a function. On large sites it is the most frequent cause, and it almost always lines up with a deploy.

• A misconfigured .htaccess file. On Apache servers, one line with bad syntax in the .htaccess file is enough for the whole site to return 500.

• File and folder permissions. If the server cannot read or execute a file because permissions are set wrong, it responds with an error.

• PHP memory limit. A process that needs more than it was given crashes. Raising the memory limit fixes the problem for a while, although it usually hides a script that is consuming too much.

• Timeout. A script that calls an external service and does not get an answer in time can end in a 500.

• Plugins and themes. In WordPress, an incompatible plugin, a half-finished update or a badly coded theme are the classic cause. It is what repeats most on small and mid-sized websites.

• Database. A failing connection, credentials that changed or a query that is too slow leave the page without the data it needs to load.

• Server resources. CPU or RAM maxed out by a traffic peak, a heavy process or a bot requesting URLs nonstop. If it happens every time there is a campaign, the resources in your hosting plan fell short.

There is one cause guides rarely mention and that I see often on enterprise sites: URLs that only fail with certain parameters. The product page works, but the same page with a tracking parameter, a filter combination nobody tested or a pagination page that does not exist blows up with a 500 error. From the office the website looks flawless, because no user browses those URLs by hand. Googlebot does.

What should you do if you see a 500 error on someone else's site?

If the error shows up on a website that is not yours, the problem is on the server side and as a user you cannot fix it. Your options are limited:

1. Reload the page after a few seconds. Often the failure was momentary.

2. Clear that site's cache and cookies in your browser. It is rarely the cause, but it is quick to rule out.

3. If you were paying, do not reload. Check your email or your bank first, because the order may have gone through even if the confirmation did not load, and reloading could duplicate the purchase.

4. Let the site know if the error persists after a while. Their team may not have noticed, especially if the problem only affects some users.

Some guides still recommend viewing the copy stored in Google's cache. That option no longer exists: Google retired its cache in 2024. If you really need the content, the alternative is to look up the URL in the Wayback Machine, which keeps archived copies of many sites.

How do you fix a 500 error on your site?

If the site is yours, before touching anything answer two questions: since when is it happening and on which URLs (the whole site, one template or only certain parameter combinations). With that clear, this is the order I would follow to fix the error:

1. Check what changed. A deploy, a plugin update, a new rule in .htaccess, a change in the server configuration. If the 500 error started right after, rolling back that change is the fastest way to fix things while you investigate.

2. Read the error logs. The Apache or NGINX error file, and debug.log if you use WordPress, usually tell you which script failed, on which line and at what time. Reload the failing URL while you watch the file and you will see the new line appear.

3. Check the .htaccess file. Rename it and load the site. If the error goes away, the problem is there: restore a previous version or fix the rule you added.

4. Check permissions. The usual setup is 755 for folders and 644 for files. Never leave 777 as a fix, because it is a security problem.

5. Look at memory and PHP. If the logs mention "memory exhausted", raise the memory limit as a temporary patch and then find out which process is eating it. Also confirm that your PHP version is compatible with your CMS and plugins.

6. Test the database connection. Credentials, available space, slow queries and the configuration of the file that stores the access details.

7. Check external services. If the page depends on an API or a third-party service, confirm it is responding and that the code handles the timeout properly.

8. Escalate to your hosting provider. If none of the above works or you cannot access the logs, write to support with the exact time, the affected URLs and what you already tried. A good hosting provider can review resources, processes and configuration you cannot see.

How long does a 500 error last? It depends on the cause: a conflicting plugin gets fixed in minutes, while a database or infrastructure problem can take hours, and often fixing it depends more on your hosting than on you.

How do you fix a 500 error in WordPress?

In WordPress the usual suspect is a plugin. The process I follow to fix the problem:

1. Deactivate all plugins from the dashboard. If you cannot log in, rename the wp-content/plugins folder over FTP or from your hosting's file manager.

2. Reactivate them one by one until the error comes back. The last one you activated is the culprit: update it, replace it or delete it.

3. Temporarily switch to a default theme if the problem persists with every plugin turned off.

4. Raise the limit in the wp-config.php file if the logs show that memory ran out.

5. Regenerate the .htaccess file by saving the permalinks again in the WordPress settings.

6. Restore a backup if nothing works and you have a recent one.

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

They look alike on screen, but they tell the browser and Google different things:

For Google, the 500, 502 and 503 end up in the same 5xx drawer. The difference is intent: if you are taking the website down on purpose, the 503 error is the right one because it is temporary and explicitly says "come back later". John Mueller, from Google, endorsed an order of preference for an outage this month: 503, then 500, then 403, then 404 and, at the very end, a 200 with an error page. We covered it in full in the article on the 503.

A 404 error, on the other hand, says the content does not exist, and most of the time it does not need fixing (I wrote about it in a guide on the 404 error for Ahrefs in Spanish). A 500 error almost always does, because that URL should work and something is breaking it.

Does a 500 error affect SEO?

It depends on how long it lasts and how many URLs it touches. A 500 error lasting a few minutes on a website carries no weight. The risk shows up when it stretches into days or settles into an entire template. This is what Google documents about 5xx errors in its guide to HTTP status codes:

• Googlebot temporarily slows down crawling, and the slowdown is proportional to the number of URLs returning errors.

• Content that arrives with a 5xx is ignored: Google does not update anything on that URL while it fails.

• URLs already in the index are preserved for a while, but if they keep failing they eventually drop out. Google does not give an exact timeframe.

• When the server responds with 200 again, crawling gradually picks back up.

In other words, the question for your team is how many hours and on which URLs. A ten-minute 500 on the blog is invisible to rankings. A two-week 500 on your best-selling product pages is a different problem.

There is one case that worries me more than the honest 500: the broken page that returns 200. It happens a lot on JavaScript sites, where the API that loads the products fails, the browser shows the user "something went wrong" and the server still delivers a 200. For Google that is a valid, empty URL. Google flags it as a soft 404 when it sees a 200 that looks like an error, and in the worst case it indexes it with the message inside. A 500 error at least warns that something is wrong. If your team works with code generators or JavaScript frameworks, the article on vibe coding covers more of these risks.

How do you know whether Google is seeing 500 errors?

Here is the difference between the error you see and the one Google sees. For the second one there are three reports in Search Console and one source outside it:

1. Page indexing report. Under Indexing > Pages, the reason "Server error (5xx)" lists the URLs Google could not index because of that problem. Look at when it started to rise and at the example URLs: if they share a pattern (filters, pagination, a folder), you already have a lead.

2. Crawl stats. Under Settings > Crawl stats, the breakdown by response shows what share of Googlebot's requests ended in a server error. A jump in 500 errors there, with no announced maintenance, deserves an investigation before it grows.

3. URL inspection. The live test shows which code Google receives today on a specific URL. It is useful to confirm the fix worked.

4. Web server logs. This is the method we use in enterprise site audits: we take 30 days of logs, filter real Googlebot visits (verified, not anyone claiming the name) and group errors by template: product pages, categories, filters, internal search. A 500 error scattered at random is usually load. One concentrated in a template is usually a programming bug.

An illustrative example: a site with 300,000 Googlebot requests a month where 4% end in a 500 error, and 90% of those errors land on category URLs with two or more filters. The fix means correcting the filter logic and, while you are at it, deciding whether those combinations should be crawlable at all (that is what robots.txt and the crawl budget conversation are for).

Watch out for the 500 error that only bots see. Sometimes a CDN or a firewall with a different configuration for certain user agents serves Googlebot a response users never get, and the other way around: the CDN can hide a 500 from the origin behind a cached copy. That is why opening the website in your browser is not enough to declare everything is fine. Once the URLs return 200 again, check their status with how to index a page on Google.

How do you keep a 500 error from coming back?

Prevention is less fun, but it saves nights:

• Website availability monitoring with alerts, so you find out before your customers do. Even better if it measures the error rate by template or page type (product, cart, checkout), because "there are errors somewhere" does not help you prioritize.

• Response time alerts. A server that slows down usually gives a warning before it crashes from lack of resources.

• Staging before production. Every WordPress, plugin, theme or code update gets tested in a staging environment first, including the odd URLs: combined filters, parameters, deep pagination.

• Recent backups and a deploy rollback plan anyone on the team can run.

• A test crawl before peaks. If Black Friday is coming, crawl the site with an audit tool a week before and filter the 5xx responses. Black Friday SEO has the data on when the clicks arrive.

• A technical review in every migration or website redesign. That is where most errors appear, because rush, a new server and rules copied by hand come together. The checklist for redesigning your website has the rest.

What I would check this week

Open Search Console and look at two things: the "Server error (5xx)" reason in the page indexing report and the breakdown by response in Crawl stats for the last 90 days. If there are URLs with a 500 error, sort them by template and cross that list with the pages that sell the most. To fix what matters first, start there, even if there are only a few. It takes twenty minutes and it is a lot cheaper than finding out in the December report.