502 Bad Gateway

TL;DR — A 502 Bad GatewayA 502 Bad Gateway is an HTTP server error a gateway or reverse proxy (a CDN, load balancer, or proxy like Nginx) returns when it gets an invalid or no response from the upstream origin server it was trying to reach. It signals a communication failure *between* servers, not necessarily that the origin itself is down. For SEO, Google treats 502 exactly like 500 and 503: crawling slows, and persistent errors eventually get pages dropped from the index. means one server was asking another server for your page and got a bad answer back. Usually that “front” server is a CDN or a proxy, and the “back” server is your actual website (the origin). The error lives in your hosting/infrastructure — not in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — and a short-lived 502 typically carries limited SEO risk in practice, though Google doesn’t publish an exact “safe” duration. It’s a bigger problem the longer it drags on.

What a 502 Bad Gateway is

When you load a page, the request often doesn’t go straight to your website. It passes through a middleman — a CDN (like Cloudflare), a load balancer, or a reverse proxy (like Nginx). That middleman forwards the request to your actual server, waits for a response, and passes it back to the visitor.

A 502 Bad Gateway is what the middleman shows when it asked your server for the page and got back something invalid — or nothing at all. In plain terms: the front server couldn’t get a good answer from the back server. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

That’s the important nuance. A 502 doesn’t automatically mean your website is down. Your server might be perfectly healthy and answering fine to a direct request — but if the proxy in front of it can’t reach it (a timeout, a bad setting, or the CDN having its own bad day), visitors still see a 502.

How it’s different from its cousins

You’ll see a few 5xx errorsThe 4xx (client error) and 5xx (server error) HTTP status codes a server returns instead of a successful 2xx — and how Google treats each class very differently. that look similar:

• 500 — your website’s own code hit an error while building the page.
• 502 — a proxy in front of your site got a bad response from it.
• 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. — your site is deliberately unavailable (planned maintenance, overload).
• 504A 504 Gateway Timeout is an HTTP 5xx server error a gateway or proxy (a CDN, load balancer, or reverse proxy) returns when it doesn't get a timely response from the upstream server behind it. Unlike a 502 (a bad/garbled response) or a 503 (server explicitly unavailable), a 504 means no response arrived in time. For SEO, isolated 504s are retried and tolerated, but sustained 504s and timeouts make Googlebot slow its crawl and eventually drop pages from the index. — a proxy waited for your server but it timed out with no answer at all.

They’re related but they point you at different places to look.

Does a 502 hurt your SEO?

Usually not much — as long as it doesn’t last. Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. (GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.) treats a 502 the same way it treats other 5xx errors: it slows crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. in proportion to how many of your URLs are erroring, then ramps back up once your site starts responding with 2xx again. Google doesn’t publish an exact “safe” duration, but a brief 502 — minutes to a couple of hours — carries much less practical risk than one that keeps happening. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

The real risk shows up when a 502 keeps recurring or stays up for an extended stretch. Google’s own wording is that it removes URLs that “persistently” return a server error — it doesn’t define that as a specific number of days. (Google’s John Mueller has informally mentioned “multiple days” as roughly when pages start dropping out, and that they tend to come back once the site recovers — but treat that as one person’s rough read on a specific incident, not an official rule.)

What to do about it

• Don’t try to “fix” it in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.. Search Console only reports a 502 after the fact. The fix happens on your CDN, proxy, or server.
• Check whether it’s just you or everyone. If the whole internet is fine but your site is down, it’s your setup. If a big CDN is having an outage, it may not be your fault at all — and there’s nothing to fix on your end but wait.
• Look at your host or CDN’s status page and your server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened.. That’s where the real answer lives.

Want the layer-by-layer diagnosis (CDN vs. proxy vs. origin), exactly what Google’s docs say, and what John Mueller said during the November 2025 Cloudflare outage? Switch to the Advanced tab.

TL;DR — A 502 is a proxy/gateway-layer failure: RFC 9110 §15.6.3 defines it as a gateway or proxy receiving an invalid response from an inbound server. It’s distinct from a 500 (origin app errored) and a 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. (origin deliberately unavailable). Google’s documentation groups 500, 502, and 503 under one 5xx treatment — crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. drops proportionally to the number of erroring URLs, 5xx content is ignored, and persistent errors drop pages from the indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Recovery is gradual once 2xx resumes, though Google publishes no fixed timeline. Duration matters, but there’s no official threshold: brief spikes carry much less practical risk, while errors that keep recurring are what put pages at real risk — Mueller’s Nov 2025 remarks put that informally around multiple days, not as a documented SLA. Diagnose by layer — CDN, reverse proxy, or origin — and correlate evidence across hops rather than trusting a branded error page alone.

What a 502 actually signals

RFC 9110 §15.6.3 defines 502 specifically: a gateway or proxy receiving an invalid response from an inbound server it accessed while trying to fulfill the request. That spec boundary matters — it identifies where the gateway observed the failure, not necessarily which hop caused it. The 502 status is evidence of a boundary failure, not proof the origin application is broken. That single distinction is what most competitor “13 ways to fix it” posts blur over, and it’s why the diagnosis below is layered rather than flat. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Contrast the confusable 5xx codes:

• 500 Internal Server ErrorA 500 Internal Server Error is a generic HTTP status code — RFC 9110 defines it as an unexpected condition that stopped the server from fulfilling the request, and nothing more. The request may have been fine — something broke server-side while generating the response. For SEO, an isolated 500 is typically retried, but persistent, site-wide 500s get Google's documented response: slower crawling and, if the errors don't clear, eventual removal from the index. — the origin application itself errored (a code bug, an unhandled exception, resource exhaustion). The origin answered, and the answer was “I broke.”
• 502 Bad GatewayA 502 Bad Gateway is an HTTP server error a gateway or reverse proxy (a CDN, load balancer, or proxy like Nginx) returns when it gets an invalid or no response from the upstream origin server it was trying to reach. It signals a communication failure *between* servers, not necessarily that the origin itself is down. For SEO, Google treats 502 exactly like 500 and 503: crawling slows, and persistent errors eventually get pages dropped from the index. — the proxy got a malformed or invalid answer from upstream (RFC 9110 §15.6.3).
• 503 Service Unavailable503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. — the origin is deliberately unavailable; this is the intentional, Google-sanctioned “come back later” code you use for planned maintenance, ideally with a Retry-After header.
• 504 Gateway TimeoutA 504 Gateway Timeout is an HTTP 5xx server error a gateway or proxy (a CDN, load balancer, or reverse proxy) returns when it doesn't get a timely response from the upstream server behind it. Unlike a 502 (a bad/garbled response) or a 503 (server explicitly unavailable), a 504 means no response arrived in time. For SEO, isolated 504s are retried and tolerated, but sustained 504s and timeouts make Googlebot slow its crawl and eventually drop pages from the index. — the proxy waited for upstream and got nothing before its timeout expired (RFC 9110 §15.6.5). (502 = bad answer; 504 = no answer in time.)

The practical upshot: 503 is the code you choose on purpose; 502 is the code that happens to you when infrastructure fails.

How Googlebot handles a 502

Here’s the part worth groundingGrounding is anchoring an AI model's answer to source documents it retrieves at the moment you ask — not to the patterns frozen into its weights during training. Retrieval-Augmented Generation (RAG) is the most common way to do it. in Google’s actual documentation rather than the hand-wavy “it can hurt rankings” you’ll read elsewhere. Google’s HTTP and network errors doc lists 502 (bad gateway) as a 5xx code and gives all 5xx codes the same treatment:

• Crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. drops, proportionally. Google decreases the crawl rate for the site, and the decrease is proportionate to how many individual URLs are returning a server error. A handful of 502s is minor; a site-wide 502 is a firm “slow down.”
• 5xx content is ignored. Anything Google receives from a URL returning a 5xx is ignored — it won’t index a 502 error page as your content.
• Index preservation is temporary. Already-indexed URLs stay in the index at first, but Google’s indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline removes URLs that persistently return a server error.
• Recovery is automatic and gradual. Once the server starts responding with 2xx again, Google gradually increases the crawl rate back up. No resubmission, reconsideration request, or “validate fix” heroics are needed for ordinary recovery — that button just tells Google to recheck sooner.

The single most important takeaway: 502 is treated the same as 500 and 503. It is not “less serious” because it originates at the proxy/CDN layer instead of the origin app. There’s no documented leniency for 502. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Duration is the whole story

Whether a 502 actually hurts you comes down to how long it lasts — but Google doesn’t publish a fixed safe-duration or a fixed drop-out threshold, so treat the following as practical color, not an SLA:

• A brief spike (minutes to a few hours) → Google’s crawl-rate reduction scales with how many URLs are erroring, so a short, small-scale spike has limited practical impact and generally isn’t worth chasing in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. Nothing in Google’s documentation formally exempts short errors — it’s a matter of degree, not a hard cutoff.
• An error that keeps recurring or stays up → this is the window where Google’s “persistently return a server error” language applies, and pages can start dropping out of the index. Google doesn’t define “persistently” as a specific number of days. Mueller’s public comment (below) put it informally around multiple days, with recovery being fairly quick once the site is healthy — but that’s one practitioner’s read on a specific incident, not a documented rule you can rely on for every site or CDN.

This maps loosely onto the November 2025 Cloudflare outage, when a wave of sites threw 5xx errorsThe 4xx (client error) and 5xx (server error) HTTP status codes a server returns instead of a successful 2xx — and how Google treats each class very differently. through no fault of their own. Mueller’s public reply on Bluesky was that 5xx crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. slows down but “ramps back up” — see the Quotes tab for the exact wording and sourcing caveats, including a separate “multiple days” comment relayed through a third-party recap rather than verified against the original thread. A short, provider-confirmed outage is close to a best case: it’s visible, it typically resolves on its own, and once the provider confirms recovery and your own 2xx responses have resumed, the reasonable response is usually to hold off on infrastructure changes rather than make them reactively.

Diagnosing a 502 by layer

Because a 502 is a communication failure between servers, the fastest way to find it is to work down the stack — CDN, then reverse proxy, then origin — rather than running through a flat checklist. (The Decision Trees tab has this as a walk-through.)

One caution before you start: a branded error page, a provider’s name in a header, or the “look” of an outage is one evidence signal, not proof of which hop failed. Correlate it with response headers, request/trace IDs, and timestamped logs on both sides of the hop before concluding “it’s the CDN” or “it’s my origin.”

CDN / edge layer

• Upstream timeout: the edge node couldn’t get a response from origin in time.
• The edge can’t reach origin at all — DNS resolution failure, SSL/TLS handshake failure, or origin firewall/security blocking the CDN’s IP ranges.
• Documented causes vary by provider: Cloudflare’s own troubleshooting docs describe origin-connectivity and timeout scenarios specific to its edge network, while AWS CloudFront documents its own set of TLS, DNS, port, and origin-function causes — check your specific CDN’s docs rather than assuming one provider’s cause list applies to another.
• The CDN provider’s own outage (Cloudflare, Fastly, AWS, etc.) — a mass-502 event across unrelated sites that has nothing to do with your server’s health; confirm this against the provider’s status page, not just the branding on the error page.

Reverse proxy / load balancer layer (Nginx, Apache mod_proxy, HAProxy)

• Backend timeout or connection refused.
• A misconfigured proxy_pass / upstream block pointing at the wrong place.
• Backend pool exhaustion — every upstream worker is busy.
• SSL/TLS mismatch between the proxy and the backend.

Origin server layer

• Application/PHP-FPM crash or restart, or an OOM kill (memory limit exceeded).
• Database connection exhaustion.
• A deployment/restart causing brief unavailability.
• A WAF or security plugin blocking legitimate proxy or crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. IPs as if they were attackers — this is the sneaky one, because normal browsers work fine while the proxy (or GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.) gets 502s.

That last pattern is worth calling out: if only Googlebot or only requests via the CDN get 502s while normal browsers don’t, you’re looking at a bot-specific block or a varying-response issue, not a true outage. Test direct-to-origin vs. via-CDN, and verify what Googlebot actually sees with Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s URL Inspection live test rather than assuming ongoing impact from a Server error (5xx) report that may already be stale.

Fixing and preventing 502s

Fixes are layer-specific, and who should make them differs by role:

• Visitor — nothing to fix. Reload once, try a different network if you suspect a local issue, and otherwise wait; browser-side changes can’t repair a server-to-server failure.
• Site owner without infrastructure access — confirm scope and check status pages/logs first (see the checklist below), then escalate to your host, CDN support, or dev team rather than guessing at a fix.
• Host / CDN / application owner — correct the proxy/upstream config, raise timeouts and backend capacity where the origin is the actual bottleneck, and stagger deploys so restarts don’t blip the whole pool. Treat WAF allowlisting, firewall changes, and proxy/upstream config edits as changes that need sign-off — apply them only after logs and provider evidence actually show a firewall or access-control failure, not as a first-response guess; allowlisting a CDN or crawler isn’t a generic 502 fix.

For prevention, the boring stuff wins: uptime monitoring with alerting, server and proxy error-log monitoring, watching your Search Console crawl-stats Host statusThe at-a-glance availability indicator at the top of Google Search Console's Crawl Stats report. It shows whether Googlebot hit significant problems reaching your site in the last 90 days across three checks — robots.txt fetching, DNS resolution, and server connectivity. and Server error (5xx) trend, and correlating spikes against your CDN and DNS providers’ status pages so you can tell “my problem” from “their outage” in seconds.

Related codes worth keeping straight sit right next door in this cluster: the origin 500A 500 Internal Server Error is a generic HTTP status code — RFC 9110 defines it as an unexpected condition that stopped the server from fulfilling the request, and nothing more. The request may have been fine — something broke server-side while generating the response. For SEO, an isolated 500 is typically retried, but persistent, site-wide 500s get Google's documented response: slower crawling and, if the errors don't clear, eventual removal from the index., the intentional 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime., and the timeout 504A 504 Gateway Timeout is an HTTP 5xx server error a gateway or proxy (a CDN, load balancer, or reverse proxy) returns when it doesn't get a timely response from the upstream server behind it. Unlike a 502 (a bad/garbled response) or a 503 (server explicitly unavailable), a 504 means no response arrived in time. For SEO, isolated 504s are retried and tolerated, but sustained 504s and timeouts make Googlebot slow its crawl and eventually drop pages from the index..

AI summary

A condensed take on the Advanced version:

• 502 = proxy/gateway-layer failure. RFC 9110 §15.6.3 defines it as a gateway or proxy receiving an invalid response from an inbound server — that’s evidence of a boundary failure, not proof of which hop (CDN, proxy, or origin) caused it. The origin can be healthy while visitors still see a 502.
• Distinct causes, same documented family. 500 (origin app errored), 502 (proxy got a bad answer, RFC §15.6.3), 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. (origin deliberately unavailable), 504A 504 Gateway Timeout is an HTTP 5xx server error a gateway or proxy (a CDN, load balancer, or reverse proxy) returns when it doesn't get a timely response from the upstream server behind it. Unlike a 502 (a bad/garbled response) or a 503 (server explicitly unavailable), a 504 means no response arrived in time. For SEO, isolated 504s are retried and tolerated, but sustained 504s and timeouts make Googlebot slow its crawl and eventually drop pages from the index. (proxy got no timely answer, RFC §15.6.5). Google’s documentation groups 500, 502, and 503 under one 5xx treatment — it doesn’t document status-specific parity beyond that family rule.
• GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s response: crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. drops proportionally to the number of erroring URLs, 5xx content is ignored, indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs are preserved short-term but removed if errors persist, and crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. ramps back up gradually once 2xx resumes — Google publishes no exact safe duration or guaranteed recovery timeline.
• Duration matters, but there’s no official threshold. Brief spikes carry much less practical risk; errors that keep recurring are the real risk. Mueller’s informal Nov 2025 comment put index drop-outs around “multiple days,” with fairly quick recovery — treat that as a practitioner’s read on one incident, not a documented SLA.
• Diagnose by correlating evidence across layers, not by trusting branding alone: CDN (timeout, DNS/SSL failure, provider outage — Cloudflare and AWS CloudFront each document different platform-specific causes) → reverse proxy (bad proxy_pass, pool exhaustion, connection refused) → origin (app/PHP-FPM crash, OOM, DB exhaustion, WAF blocking proxy/crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. IPs). Match headers, trace IDs, and timestamped logs on both sides of a hop before concluding which layer failed.
• It’s not a one-size-fits-all fix. GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. only reports 502 after the fact and can’t fix it. Visitors can’t fix it either; site owners without infra access should escalate rather than edit config; and destructive changes — WAF allowlisting, firewall or proxy edits — should follow log/provider evidence, not be a first-response guess. If only GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. or only via-CDN requests get 502, suspect a bot-specific block, not a global outage.

Official documentation

Primary-source documentation on how search engines handle 5xx errorsThe 4xx (client error) and 5xx (server error) HTTP status codes a server returns instead of a successful 2xx — and how Google treats each class very differently., including 502.

Google

• How HTTP status codes affect Google’s crawlers — the canonical doc; lists 502 (bad gateway) alongside 500 and 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. and describes the shared crawl-rate/indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. treatment.
• How to deal with planned site downtime — why 503 (not 502, 404, or 200) is the right code for intentional downtime, with a Retry-After header. Useful for the 502-vs-503 distinction.
• robots.txt spec — handling server errors — how Google treats a 5xx on the robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. file itself.

Specification

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — the spec-level definition: a gateway or proxy receiving an invalid response from an inbound server it accessed while trying to fulfill the request. It identifies the boundary where the failure was observed, not which hop caused it.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing surfaces server-side (5xx-class) crawl issuesCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index., including connectivity failures, in its crawl-error reporting.

Quotes from the source

On-the-record statements from Google. Each link deep-links to the quoted passage.

Google — how 5xx (including 502) is handled

• “5xx and 429429 Too Many Requests is an HTTP client-error status code that means a client sent too many requests in a given time window — a mechanism called rate limiting. Unlike other 4xx codes, Google treats 429 as a server-overload signal and slows crawling instead of removing content. server errors prompt Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. to temporarily slow down with crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. For Google Search, already indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs are preserved in the index, but eventually dropped.” — Google Search Central, How HTTP status codesAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. affect Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.. Jump to quote
• “Google decreases the crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. for the site. The decrease in crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline removes from the index URLs that persistently return a server error.” — same doc, the table row covering 500, 502, and 503. Jump to quote
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” — same doc. Jump to quote

John Mueller, Google (Bluesky, Nov 18, 2025 — replying in a thread about the Cloudflare-outage 5xx spike)

• “Yeah. 5xx = Google crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. slows down, but it’ll ramp back up.” View the post
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” Relayed via Matt G. Southern’s Search Engine Journal write-up of the same exchange; confirm against the original thread before treating as final. Read the coverage

502 Bad Gateway response checklist

When a 502 shows up — in a browser, in monitoring, or in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Server error (5xx) report — work this list. Role tags: [Any] works whether or not you have infrastructure access; [Host/CDN/App owner] needs it.

• [Any] Confirm it’s real and current — reproduce the URL now; a Server error (5xx) report can lag behind a blip that’s already resolved.
• [Any] Check scope — is it one URL, a section, or site-wide? (Crawl impact scales with how many URLs error.)
• [Any] Check your CDN/DNS provider’s status page for a provider-wide outage before touching your own config.
• [Host/CDN/App owner] Test direct-to-origin vs. via-CDN — if origin answers 2xx directly but the CDN returns 502, the problem is at the edge or in between.
• [Host/CDN/App owner] Check whether only botsA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index./CDN IPs get 502 while browsers are fine — points to a possible WAF/firewall block, not an outage. Confirm it in firewall/WAF logs before allowlisting anything; allowlisting isn’t a generic fix and should follow evidence, not precede it.
• [Host/CDN/App owner] Read the proxy error logs (Nginx/Apache/HAProxy) for upstream timeouts or connection-refused entries.
• [Host/CDN/App owner] Read the origin logs for app crashes, OOM kills, or DB connection exhaustion around the timestamps.
• [Any] Verify what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. sees with GSC URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. live test.
• [Host/CDN/App owner] Apply the layer-specific fix only once logs/provider evidence point to it — WAF, firewall, timeout, and proxy-config changes are infrastructure changes, not first-response guesses.
• [Any] Once fixed, let recovery happen — 2xx responses gradually ramp crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. back up; Google doesn’t publish an exact recovery timeline. Use “Validate Fix” only to prompt a faster recheck, not as a “fix.”
• [Host/CDN/App owner] Confirm you’re using 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. (not 502) for any planned downtime going forward.

Is my 502 a CDN, proxy, or origin problem?

A 502 is a failure between servers, so diagnose it by walking down the stack instead of guessing. Start at the edge and move inward.

Q1. Is your CDN or DNS provider reporting an outage right now?

• Yes → it’s most likely a provider-wide outage (the Nov 2025 Cloudflare event is the textbook case). There’s usually nothing to fix on your end. Confirm your origin is healthy, then wait for recovery — Google’s crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. ramps back up gradually once 2xx responses resume, though no exact timeline is published. Stop here.
• No → continue.

Q2. Does the origin answer 2xx on a direct request (bypassing the CDN/proxy)?

• No — origin also fails → the problem is at the origin layer. Check app / PHP-FPM crashes, OOM kills, database connection exhaustion, or a bad deploy in the logs. Note this often reads as a 500 or 504A 504 Gateway Timeout is an HTTP 5xx server error a gateway or proxy (a CDN, load balancer, or reverse proxy) returns when it doesn't get a timely response from the upstream server behind it. Unlike a 502 (a bad/garbled response) or a 503 (server explicitly unavailable), a 504 means no response arrived in time. For SEO, isolated 504s are retried and tolerated, but sustained 504s and timeouts make Googlebot slow its crawl and eventually drop pages from the index. too, depending on how the proxy sees it. Stop here.
• Yes — origin is healthy directly, but the CDN/proxy returns 502 → continue. The origin is fine; something in front of it can’t get a clean response.

Q3. Do normal browsers work while only GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. / CDN IPs get 502s?

• Yes → suspect a WAF or firewall block treating the proxy or crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. IP ranges as attackers. Confirm it in firewall/WAF logs first, then allowlist the legitimate CDN and verified crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. IP ranges — don’t allowlist without that confirmation. Stop here.
• No — everyone via the proxy gets 502 → continue.

Q4. What do the reverse-proxy logs show for the upstream?

• Timeout / connection refused → the proxy can reach the backend but isn’t getting a timely, valid response → backend capacity or timeout issue (pool exhausted, timeouts too tight). Raise capacity/timeouts or fix the slow backend.
• Wrong host / DNS / SSL handshake failure to upstream → proxy misconfiguration → fix the proxy_pass / upstream block or the proxy↔backend TLS setup.

Whatever the layer: the SEO cleanup is the same and mostly hands-off. Once the URLs return 2xx, Google resumes crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. automatically — no resubmission needed.

502 myths and mistakes to avoid

• Myth: “502 is a Google/SEO problem I fix in Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results..” No. A 502 is a hosting/infrastructure failure; Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. only reports it after the fact. The fix is at the CDN, proxy, or origin. “Validate Fix” just asks Google to recheck — it doesn’t repair anything.
• Myth: “A 502 always means my server is down.” No. The origin can return 2xx to a direct request while visitors see a 502 through the CDN — a timeout, a bad upstream config, or the CDN’s own outage. Test direct-to-origin before assuming your server crashed.
• Myth: “502 is less serious than 500 for SEO.” No. Google’s docs give 500, 502, and 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. the same crawl-rate reduction and the same eventual indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.-removal for persistent errors. There’s no documented leniency for 502.
• Myth: “A one-time 502 will deindexDeindexing means getting a URL to stop appearing in Google's search results. There's no single delete button — the right method depends on whether you own the page, whether removal is temporary or permanent, and whether the content should still exist. my page.” No. CrawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. slows, then ramps back up. Index drops require the error to persist — Google’s docs use that word without defining an exact day count. Mueller’s informal Nov 2025 comment put it around multiple days, adding that dropped pages “pop back in fairly quickly” — treat that as a practitioner’s read on one incident, not an official threshold.
• Myth: “502 and 503 mean the same thing.” No. 503 is the intentional “service unavailable” code you should use for planned maintenance (with a Retry-After); 502 is an unintentional proxy failure. Conflating them in monitoring hides real incidents behind expected maintenance windows.
• Myth: “Clearing my browser cache fixes a site-wide 502.” That’s advice for a visitor troubleshooting their own view. If the CDN/proxy/origin is actually failing, no browser-side action changes anything for anyone else.
• Anti-pattern: reflexively hitting “Validate Fix” and refreshing GSC. During a transient spike (or a CDN outage), the fastest, correct move is often to do nothing but confirm recovery. Google handles the ramp-back automatically.

Incident playbook: the site is returning 502

1. Confirm the scope. Check one affected URL with the Website Down Checker and then test multiple URLs with the Bulk HTTP Status Code Checker. If only your browser fails, clear the local network or DNS issue before escalating a site-wide incident. If many public URLs return 502, continue.
2. Record the failing response. Save the time, URL, status, response headers, and any CDN request ID. If the error is intermittent, repeat the request rather than treating one successful retry as recovery.
3. Identify the gateway — treat branding as one signal, not proof. Read headers and the branded error page for a CDN, reverse proxy, or load-balancer fingerprint, but confirm it against the provider’s own status page and your logs before concluding which hop failed; branded pages and headers are provider-specific and don’t universally prove cause. If the provider reports an outage, follow its incident path; otherwise continue toward the origin.
4. Compare edge and origin. Request the public hostname normally, then send the same hostname directly to the known origin IP with curl --resolve. If origin succeeds while the edge returns 502, inspect CDN-to-origin connectivity, TLS, and proxy configuration. If both fail, move to the application and origin logs.
5. Correlate logs by timestamp. A connection refusal or TLS failure points to the gateway/origin boundary; a malformed or abruptly closed upstream response points to the origin service. Fix the failing layer, not Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results..
6. Verify recovery. Re-run both public and direct-origin checks across representative URLs. If 2xx responses are stable, monitor logs and Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. while GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. resumes crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. automatically. If 502s recur, return to step 4 with the new timestamps instead of increasing retries blindly.

Prompt: classify a batch of 502 failures by layer

Paste a CSV containing the URL, timestamp, status, response headers, public-edge result, direct-origin result, and any matching log excerpt. Remove secrets, cookies, authorization headers, and private origin addresses first.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Expect a triage queue, not a definitive root-cause report. Validate every suggested check against live headers and logs.

Reproduce the public 502

Run this in a macOS/Linux shell. It prints response headers without downloading the body and follows no redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., so you see the first response.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

PowerShell equivalent:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

If the application handles HEAD differently, use a normal GET and discard the body:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Compare the CDN route with the known origin

Replace 203.0.113.10 with an origin IP you control. --resolve keeps the public hostname for the HTTP Host header and TLS name while connecting to that IP.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

Do not expose a protected origin or weaken its firewall just to run this test. Run it from an already authorized network. Public 502 plus direct-origin success narrows the failure to the CDN/proxy path; failure on both paths points you toward the origin or application.

Tools for narrowing a 502

• Website Down Checker — confirm whether the URL is reachable from an external Cloudflare vantage point and capture timing, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and bounded DNS evidence. It answers “is this only happening to me?” before you start changing infrastructure.
• Bulk HTTP Status Code Checker — test a representative URL set, see full redirect paths and latency, and export results. Use it to separate a single-route failure from a broader 502 incident.
• Your CDN or load-balancer dashboard — match request IDs and timestamps from the failing response to edge logs and provider status.
• Origin application and server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. — confirm whether the upstream accepted the request and whether it returned, reset, or malformed the response. This is what turns a layer hypothesis into a root cause.

No tool can identify the failing layer from 502 alone. Compare public-edge evidence with an authorized direct-origin request and timestamped logs.

Test yourself: 502 Bad Gateway

Five quick questions on what a 502 is and how it affects SEO. Pick an answer for each, then check.

Resources worth your time

My related writing

• A Comprehensive Guide to HTTP Status Codes for SEO — where 502 and the rest of the 5xx family fit, and what each code signals to search engines.
• The Beginner’s Guide to Technical SEO — how server health and crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. connect to the bigger picture.
• Robots.txt and SEO: Everything You Need to Know — relevant because a 5xx on your robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. file is handled specially.

From around the industry

• How HTTP status codes affect Google’s crawlers (Google Search Central) — the primary source: 502 (bad gateway) grouped with 500/503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime., and the exact crawl-rate/indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. language.
• How to deal with planned site downtime (Google Search Central) — the 503-vs-502 distinction and why 503 is the code for intentional downtime.
• Cloudflare Outage Triggers 5xx Spikes: What It Means For SEO (Matt G. Southern, Search Engine Journal) — the Nov 2025 outage as a real-world case study, with Mueller’s comments.
• 502 Bad Gateway: MDN reference (MDN Web Docs) — the neutral spec-level definition of the status code.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — the underlying HTTP semantics spec.
• How To Fix a 502 Bad Gateway Error (Kinsta) — a thorough host’s-eye troubleshooting walkthrough for the browser/site-owner fixes.
• 502 bad gateway: what it means & how web developers can fix these errors (Webflow) — a developer-oriented causes-and-fixes overview.

502 Bad Gateway

A 502 Bad Gateway is an HTTP server error a gateway or reverse proxy (a CDN, load balancer, or proxy like Nginx) returns when it gets an invalid or no response from the upstream origin server it was trying to reach. It signals a communication failure *between* servers, not necessarily that the origin itself is down. For SEO, Google treats 502 exactly like 500 and 503: crawling slows, and persistent errors eventually get pages dropped from the index.

Related: HTTP Status Code, Crawling, Crawl Budget

502 Bad Gateway

A 502 Bad Gateway is an HTTP server error status code returned when a server that’s acting as a gateway or reverse proxy — a CDN, a load balancer, or a proxy like Nginx or Apache — receives an invalid or malformed response from the upstream (“inbound”) origin server it was trying to reach to fulfill the request. The plain-English version: the machine in front got a bad answer from the machine behind it. RFC 9110 §15.6.3 defines this boundary precisely: it identifies where the gateway observed the failure, not necessarily which hop caused it.

The key distinction is where the failure lives. A 502 is a communication failure between servers, which makes it different from a 500 Internal Server ErrorA 500 Internal Server Error is a generic HTTP status code — RFC 9110 defines it as an unexpected condition that stopped the server from fulfilling the request, and nothing more. The request may have been fine — something broke server-side while generating the response. For SEO, an isolated 500 is typically retried, but persistent, site-wide 500s get Google's documented response: slower crawling and, if the errors don't clear, eventual removal from the index. (the origin application itself errored) and a 503 Service Unavailable503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. (the origin is deliberately unavailable, e.g. maintenance or overload). The origin can be perfectly healthy and still throw a 502 at visitors if the proxy in front of it can’t get a valid response — a timeout, a bad upstream config, or the CDN provider’s own outage. A branded error page or provider name in a header is one evidence signal for isolating the failure, not proof by itself; correlate it with response headers, trace IDs, and logs on both sides of the hop.

For SEO, the treatment is the part people get wrong. Google’s documentation groups 502 (bad gateway) with 500 and 503 under one 5xx response: crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. slows in proportion to how many URLs are erroring, content from 5xx responses is ignored, and already-indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. URLs are preserved short-term but dropped if the errors persist. It is not treated as less serious just because it originates at the proxy layer. Recovery is gradual once 2xx responses resume — Google doesn’t publish an exact recovery timeline. Duration matters for real harm, but Google doesn’t define a fixed safe-duration or drop-out threshold: a brief spike carries much less practical risk than an error that keeps recurring or stays up.

Related: HTTP Status Code, Crawling, Crawl Budget

Changelog