A 500 Internal Server Error is an HTTP status code returned when the web server encountered an unexpected condition that prevented it from fulfilling the request. It's a generic server-side fault — the server broke, but it does not say exactly why. Persistent 500s stop pages from being indexed and can trigger Google to reduce your crawl rate.
Every 500 you serve to Googlebot is a page it couldn't crawl. A handful is fine. A steady stream tells Google your site is unreliable, and it will pull back on crawl budget until the errors stop.
What is a 500 Internal Server Error?
A 500 is the catch-all HTTP response for any server-side fault that doesn't fit a more specific code. When the server ran into an exception, a misconfiguration, or a broken dependency, it returns 500 Internal Server Error along with (ideally) an error page.
500 belongs to the 5xx family of HTTP status codes:
- 500 Internal Server Error — generic server fault
- 501 Not Implemented — server doesn't support the request method
- 502 Bad Gateway — upstream server returned an invalid response
- 503 Service Unavailable — server temporarily overloaded or in maintenance
- 504 Gateway Timeout — upstream server didn't respond in time
Google treats persistent 5xx errors as a signal to slow down crawling to avoid overloading a struggling server. If a URL returns 500 repeatedly, Google will eventually drop it from the index. Widespread 500s across the site can trigger a full crawl-rate reduction.
Why 500 errors matter for SEO
500 errors are silent revenue killers. Users see a broken page and leave. Google sees an unreliable page and stops trusting the URL.
- Crawlers back off. Repeated 500s tell Googlebot the server can't handle its normal crawl rate. Google reduces frequency, which means new pages get indexed slower.
- Rankings decay. A URL returning 500 consistently gets dropped from the index. Any ranking the page had disappears within days.
- Users bounce. A 500 error page is the least helpful thing a visitor can see. Bounce rates spike and any conversion path goes dead.
- Revenue leakage. On ecommerce and lead-gen sites, every 500 during checkout or form submission is money that walked out the door.
How a 500 error works
The failure happens after the request reaches the server — often after the application starts processing it. Here is the shape of that exchange.
GET /products/blue-widget/ HTTP/1.1
Host: example.com
# Server hits an exception mid-execution
HTTP/1.1 500 Internal Server Error
Content-Type: text/html
# Body may be blank, a stack trace, or a friendly error page
Where 500s originate
The chain is application code → framework → web server → response. A 500 can be thrown at any layer:
- Application exception (unhandled null, database timeout, missing env var)
- Framework middleware failing to bootstrap
- Web server misconfiguration in
.htaccessor Nginx conf - Reverse proxy or CDN passing through an upstream failure
Server logs are the fastest way to find the actual cause — the visible page rarely tells you which layer failed.
500 vs the other 5xx errors
| Status | Meaning | Common cause | SEO handling |
|---|---|---|---|
| 500 Internal Server Error | Generic server fault | Code exception, misconfig | Crawl slows, then de-indexes |
| 502 Bad Gateway | Bad response from upstream | Proxy or load balancer issue | Same as 500 if persistent |
| 503 Service Unavailable | Temporarily unavailable | Maintenance, overload | Google respects as temporary |
| 504 Gateway Timeout | Upstream did not respond in time | Slow database or API | Treated as reliability issue |
| 404 Not Found | Resource does not exist | URL deleted or wrong | Normal, de-indexed over time |
Real 500 error examples
1. Deploy breaks database connection
A Friday deploy ships a new env-var setup, but the production database URL is missing. Every request that touches the database returns 500. Googlebot hits 12,000 500s over the weekend before the on-call rolls it back Monday morning. Rankings on the affected URLs drop noticeably by Wednesday.
2. SSL certificate expiry cascade
The API certificate expires overnight. The main site's product pages call the API on render. The API call throws, gets caught by generic error middleware, and every product page returns 500. Traffic craters for 6 hours until the certificate is renewed.
3. Memory limit exhausted on shared hosting
A viral blog post drives 40x normal traffic. The WordPress site on shared hosting hits its PHP memory limit and starts returning intermittent 500s. Half the visitors see a broken site; the other half get through. Google records inconsistent responses and crawl-rate drops.
4. Broken .htaccess rewrite
A "quick" edit to .htaccess introduces a syntax error. Apache returns 500 on every request until the file is fixed. This is one of the most common self-inflicted 500 causes — always test .htaccess changes in staging.
500 vs 503 — which to use during maintenance
Both are server-side statuses, but they signal completely different things to search engines.
Use 503 Service Unavailable when
- You are performing planned maintenance
- The server is temporarily overloaded
- You want Google to come back later
- Include a
Retry-Afterheader - Downtime is expected to be short (minutes to hours)
500 Internal Server Error means
- Something is genuinely broken and unexpected
- The server needs human intervention
- You should be alerted and paged
- Persistent 500s reduce crawl rate
- Never use 500 for planned downtime
7 best practices for 500 errors
- Alert on 500 rate. Set an uptime monitor and alert if 500 rate exceeds baseline. Don't wait for a customer to tell you the site is broken.
- Read the server logs first. The visible 500 page rarely tells you the cause. The application log, Nginx log, or reverse-proxy log has the stack trace.
- Return 503 for planned downtime. With a
Retry-Afterheader. Google respects it and comes back. - Ship graceful error pages. The user-facing 500 page should still return HTTP 500 in the header but present a helpful branded page.
- Roll back fast. If a deploy triggers 500s, roll back first and diagnose second. Every minute is lost traffic and revenue.
- Cache-bust after fixes. If the CDN cached a 500 response, purge the cache after fixing the underlying issue.
- Track 500s in Search Console. The Pages report surfaces server-error URLs. Investigate before Google drops them from the index.
Some frameworks catch every exception, log it, and return a "friendly" error page with HTTP 200. That looks fine to a browser but makes Google think a broken page is a valid page. Always return HTTP 500 in the header on genuine server errors — the user-friendly HTML body is fine, the status code must be correct.
Common 500 mistakes to avoid
- Returning 200 on a broken page — masks the problem from Google and creates soft errors.
- Using 500 for planned maintenance — use 503 with
Retry-After. - Not monitoring 500 rate — you find out from customers or ranking drops instead of alerts.
- Ignoring intermittent 500s — a 2% error rate is enough to slow Google's crawl.
- Editing production config without testing — the classic broken
.htaccessor Nginx conf that takes the site down. - Not purging CDN cache after a fix — cached 500s continue to serve after the origin is fixed.
Frequently asked questions
Yes, if they persist. Googlebot expects to see valid responses. Repeated 500s on a URL cause Google to slow crawling and eventually drop the URL from the index. Widespread 500s across the site can trigger a full crawl-rate reduction.
The most common causes are application code exceptions, database connection failures, misconfigured .htaccess or Nginx config, exhausted memory or CPU, expired SSL certificates, and permission errors on files or directories. Server logs are the fastest way to identify the root cause.
Check server error logs first — they contain the actual stack trace. Then look for recent deploys, config changes, or resource exhaustion. Common fixes: fix the code exception, restore the config, increase memory limits, renew the SSL certificate, or fix file permissions.
500 is a generic server error. 502 Bad Gateway means an upstream server (behind a proxy or load balancer) returned an invalid response. 503 Service Unavailable means the server is temporarily overloaded or down for maintenance and Google respects it as a temporary state.
Yes. Return 503 with a Retry-After header for maintenance windows. Google treats 503 as a temporary state and will re-crawl. A 500 is treated as an unexpected server fault and repeated 500s harm crawlability.
Related glossary terms
Sources
