502 Gateway inválido

TL;DR — Um 502 Bad Gateway significa que um servidor pediu sua página a outro servidor e recebeu uma resposta inválida. Normalmente, o servidor “da frente” é uma CDN ou um proxy, e o servidor “de trás” é seu site de fato (a origem). O erro está na hospedagem/infraestrutura — não no Google Search Console — e um 502 de curta duração costuma trazer risco limitado para SEO na prática, embora o Google não publique uma duração exata “segura”. Quanto mais tempo ele persistir, maior o problema.

O que é um 502 Bad Gateway

Quando você carrega uma página, a solicitação muitas vezes não vai diretamente para seu site. Ela passa por um intermediário — uma CDN (como Cloudflare), um balanceador de carga ou um proxy reverso (como Nginx). Esse intermediário encaminha a solicitação ao seu servidor real, espera uma resposta e a repassa ao visitante.

Um 502 Bad Gateway é o que o intermediário mostra quando pediu a página ao seu servidor e recebeu algo inválido — ou nada. Em termos simples: o servidor da frente não conseguiu obter uma boa resposta do servidor de trás. 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

Essa é a nuance importante. Um 502 não significa automaticamente que seu site está fora do ar. Seu servidor pode estar perfeitamente saudável e respondendo bem a uma solicitação direta — mas, se o proxy à frente dele não consegue alcançá-lo (um timeout, uma configuração incorreta ou um dia ruim da própria CDN), os visitantes ainda veem um 502.

Como ele difere dos códigos parecidos

Você verá alguns erros 5xx que parecem semelhantes:

• 500 — o próprio código do seu site encontrou um erro ao construir a página.
• 502 — um proxy à frente do seu site recebeu uma resposta inválida dele.
• 503 — seu site está deliberadamente indisponível (manutenção planejada, sobrecarga).
• 504 — um proxy esperou pelo seu servidor, mas o tempo expirou sem resposta.

Eles são relacionados, mas apontam para lugares diferentes que você deve investigar.

Um 502 prejudica seu SEO?

Geralmente não muito — desde que não dure. O rastreador do Google (Googlebot) trata um 502 da mesma forma que outros erros 5xx: reduz o rastreamento proporcionalmente à quantidade de URLs com erro e depois aumenta o ritmo quando seu site volta a responder com 2xx. O Google não publica uma duração exata “segura”, mas um 502 breve — de minutos a algumas horas — traz muito menos risco prático do que um que continua ocorrendo. 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

O risco real aparece quando um 502 continua se repetindo ou permanece ativo por um período prolongado. A formulação do próprio Google é que ele remove URLs que retornam um erro de servidor “persistentemente” — sem definir isso como um número específico de dias. (John Mueller, do Google, mencionou informalmente “vários dias” como uma aproximação de quando as páginas começam a desaparecer, e que elas tendem a voltar quando o site se recupera — mas trate isso como a leitura aproximada de uma pessoa sobre um incidente específico, não como uma regra oficial.)

O que fazer a respeito

• Não tente “corrigir” isso no Search Console. O Search Console apenas relata um 502 depois que ele acontece. A correção ocorre na sua CDN, no proxy ou no servidor.
• Verifique se o problema é só seu ou de todos. Se a internet inteira está normal, mas seu site está fora do ar, o problema é sua configuração. Se uma CDN grande está passando por uma interrupção, talvez a culpa não seja sua — e não há nada para corrigir do seu lado além de esperar.
• Veja a página de status da sua hospedagem ou CDN e os logs do servidor. É ali que está a resposta real.

Quer o diagnóstico camada por camada (CDN versus proxy versus origem), exatamente o que a documentação do Google diz e o que John Mueller disse durante a interrupção da Cloudflare em novembro de 2025? Mude para a aba Avançado.

TL;DR — Um 502 é uma falha na camada de proxy/gateway: a RFC 9110 §15.6.3 o define como um gateway ou proxy recebendo uma resposta inválida de um servidor de entrada. Ele é diferente de um 500 (a aplicação na origem apresentou erro) e de um 503 (a origem está deliberadamente indisponível). A documentação do Google agrupa 500, 502 e 503 sob o mesmo tratamento de 5xx — a taxa de rastreamento cai proporcionalmente à quantidade de URLs com erro, o conteúdo 5xx é ignorado e erros persistentes removem páginas do índice. A recuperação é gradual quando o 2xx volta, embora o Google não publique um cronograma fixo. A duração importa, mas não existe um limiar oficial: picos breves trazem muito menos risco prático, enquanto erros que continuam se repetindo colocam as páginas em risco — as observações de Mueller de novembro de 2025 os situam informalmente em torno de vários dias, não como um SLA documentado. Diagnostique por camada — CDN, proxy reverso ou origem — e correlacione as evidências entre os saltos em vez de confiar apenas em uma página de erro com marca.

O que um 502 realmente sinaliza

A RFC 9110 §15.6.3 define especificamente o 502 como um gateway ou proxy recebendo uma resposta inválida de um servidor de entrada que acessou ao tentar atender à solicitação. Esse limite da especificação é importante — ele identifica onde o gateway observou a falha, não necessariamente qual salto a causou. O status 502 é evidência de uma falha no limite entre camadas, não prova de que a aplicação na origem está quebrada. É justamente essa distinção que a maioria dos artigos concorrentes de “13 maneiras de corrigir” deixa indistinta, e por isso o diagnóstico abaixo é por camadas, não uma lista plana. 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

Compare os códigos 5xx que podem ser confundidos:

• 500 Internal Server Error — a própria aplicação na origem apresentou erro (bug no código, exceção não tratada, esgotamento de recursos). A origem respondeu, e a resposta foi “eu quebrei”.
• 502 Bad Gateway — o proxy recebeu uma resposta malformada ou inválida do upstream (RFC 9110 §15.6.3).
• 503 Service Unavailable — a origem está deliberadamente indisponível; este é o código intencional, sancionado pelo Google, de “volte mais tarde”, usado para manutenção planejada, idealmente com um cabeçalho Retry-After.
• 504 Gateway Timeout — o proxy esperou pelo upstream e não recebeu nada antes de o timeout expirar (RFC 9110 §15.6.5). (502 = resposta inválida; 504 = nenhuma resposta a tempo.)

A consequência prática: 503 é o código que você escolhe de propósito; 502 é o código que acontece com você quando a infraestrutura falha.

Como o Googlebot trata um 502

Esta é a parte que vale fundamentar na documentação real do Google, em vez do “isso pode prejudicar os rankings” vago que você encontrará em outros lugares. O documento do Google sobre erros HTTP e de rede lista 502 (bad gateway) como um código 5xx e dá a todos os códigos 5xx o mesmo tratamento:

• A taxa de rastreamento cai proporcionalmente. O Google reduz a taxa de rastreamento do site, e a redução é proporcional à quantidade de URLs individuais que retornam um erro de servidor. Alguns 502 são algo pequeno; um 502 no site inteiro é um “diminua o ritmo” inequívoco.
• O conteúdo 5xx é ignorado. Tudo o que o Google recebe de uma URL que retorna 5xx é ignorado — ele não indexará uma página de erro 502 como seu conteúdo.
• A preservação no índice é temporária. URLs já indexadas permanecem no índice no início, mas o pipeline de indexação do Google remove URLs que retornam um erro de servidor persistentemente.
• A recuperação é automática e gradual. Quando o servidor volta a responder com 2xx, o Google aumenta gradualmente a taxa de rastreamento. Não é necessário reenviar, pedir reconsideração ou fazer heroísmos com “validar correção” para a recuperação normal — esse botão apenas pede ao Google que verifique novamente mais cedo.

A conclusão mais importante: 502 recebe o mesmo tratamento que 500 e 503. Ele não é “menos grave” por ter origem na camada de proxy/CDN em vez da aplicação na origem. Não existe tolerância documentada para 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

A duração é toda a história

O fato de um 502 realmente prejudicar você depende de quanto tempo ele dura — mas o Google não publica uma duração segura fixa nem um limiar fixo para remoção, então trate o que segue como contexto prático, não como um SLA:

• Um pico breve (minutos a algumas horas) → a redução da taxa de rastreamento do Google acompanha a quantidade de URLs com erro, então um pico curto e de pequena escala tem impacto prático limitado e geralmente não vale ser perseguido no Search Console. Nada na documentação do Google isenta formalmente erros curtos — é uma questão de grau, não um corte rígido.
• Um erro que continua se repetindo ou permanece ativo → esta é a janela em que se aplica a formulação do Google “retornam um erro de servidor persistentemente”, e as páginas podem começar a sair do índice. O Google não define “persistentemente” como um número específico de dias. O comentário público de Mueller (abaixo) o situou informalmente em torno de vários dias, com recuperação relativamente rápida quando o site está saudável — mas essa é a leitura de um profissional sobre um incidente específico, não uma regra documentada na qual você possa confiar para todo site ou CDN.

Isso se relaciona de forma aproximada à interrupção da Cloudflare em novembro de 2025, quando uma onda de sites lançou erros 5xx sem culpa própria. A resposta pública de Mueller no Bluesky foi que o rastreamento com 5xx desacelera, mas “volta a aumentar” — veja a aba Citações para a formulação exata e as ressalvas de origem, incluindo um comentário separado sobre “vários dias” retransmitido por um resumo de terceiros, sem verificação no tópico original. Uma interrupção breve confirmada pelo provedor é quase o melhor caso: é visível, normalmente se resolve sozinha e, quando o provedor confirma a recuperação e suas próprias respostas 2xx voltam, a reação razoável costuma ser evitar mudanças de infraestrutura reativas.

Diagnosticando um 502 por camada

Como um 502 é uma falha de comunicação entre servidores, a maneira mais rápida de encontrá-la é descer pela pilha — CDN, depois proxy reverso, depois origem — em vez de percorrer uma lista plana. (A aba Árvores de decisão apresenta isso passo a passo.)

Um cuidado antes de começar: uma página de erro com marca, o nome de um provedor em um cabeçalho ou a “aparência” de uma interrupção são sinais de evidência, não prova de qual salto falhou. Correlacione isso com cabeçalhos de resposta, IDs de solicitação/rastreamento e logs com registro de horário nos dois lados do salto antes de concluir “é a CDN” ou “é minha origem”.

Camada da CDN/borda

• Timeout do upstream: o nó de borda não conseguiu obter uma resposta da origem a tempo.
• A borda não consegue alcançar a origem — falha de resolução DNS, falha no handshake SSL/TLS ou firewall/segurança da origem bloqueando os intervalos de IP da CDN.
• As causas documentadas variam por provedor: a documentação de solução de problemas da Cloudflare descreve cenários de conectividade com a origem e timeout específicos de sua rede de borda, enquanto a AWS CloudFront documenta seu próprio conjunto de causas relacionadas a TLS, DNS, porta e funções na origem — consulte a documentação da sua CDN específica em vez de presumir que a lista de um provedor se aplica a outro.
• A própria interrupção do provedor de CDN (Cloudflare, Fastly, AWS etc.) — um evento de 502 em massa entre sites não relacionados, sem relação com a saúde do seu servidor; confirme isso na página de status do provedor, não apenas pela marca na página de erro.

Camada do proxy reverso/balanceador de carga (Nginx, Apache mod_proxy, HAProxy)

• Timeout do backend ou conexão recusada.
• Um bloco proxy_pass/upstream mal configurado apontando para o lugar errado.
• Esgotamento do pool do backend — todos os workers upstream estão ocupados.
• Incompatibilidade de SSL/TLS entre o proxy e o backend.

Camada do servidor de origem

• Falha ou reinicialização da aplicação/PHP-FPM, ou encerramento por OOM (limite de memória excedido).
• Esgotamento das conexões do banco de dados.
• Um deploy/reinicialização causando uma indisponibilidade breve.
• Um WAF ou plugin de segurança bloqueando IPs legítimos do proxy ou do rastreador como se fossem invasores — este é o caso sorrateiro, porque navegadores normais funcionam enquanto o proxy (ou o Googlebot) recebe 502s.

Vale destacar esse último padrão: se apenas o Googlebot ou apenas as solicitações via CDN recebem 502 enquanto navegadores normais não, você está diante de um bloqueio específico para bots ou de uma resposta variável, não de uma verdadeira interrupção. Teste diretamente na origem e via CDN, e verifique o que o Googlebot realmente vê com o teste ao vivo de inspeção de URL do Search Console, em vez de presumir um impacto contínuo com base em um relatório de Erro de servidor (5xx) que talvez já esteja desatualizado.

Corrigindo e prevenindo 502s

As correções são específicas da camada, e quem deve executá-las varia conforme o papel:

• Visitante — nada para corrigir. Recarregue uma vez, tente outra rede se suspeitar de um problema local e, caso contrário, espere; mudanças no navegador não podem reparar uma falha entre servidores.
• Proprietário do site sem acesso à infraestrutura — confirme o escopo e verifique primeiro as páginas de status/logs (consulte a lista abaixo), depois encaminhe o caso ao host, ao suporte da CDN ou à equipe de desenvolvimento em vez de adivinhar uma correção.
• Proprietário do host/CDN/aplicação — corrija a configuração do proxy/upstream, aumente timeouts e a capacidade do backend quando a origem for o gargalo real e distribua os deploys para que reinicializações não interrompam todo o pool. Trate allowlisting de WAF, alterações de firewall e edições de configuração de proxy/upstream como mudanças que precisam de aprovação — aplique-as somente depois que logs e evidências do provedor mostrarem de fato uma falha de firewall ou controle de acesso, não como um palpite de primeira resposta; colocar uma CDN ou rastreador em allowlist não é uma correção genérica para 502.

Para prevenção, o básico funciona: monitoramento de disponibilidade com alertas, monitoramento dos logs de erro do servidor e do proxy, acompanhamento do Host status e da tendência de Erro de servidor (5xx) nas estatísticas de rastreamento do Search Console e correlação dos picos com as páginas de status dos seus provedores de CDN e DNS, para distinguir “meu problema” da “interrupção deles” em segundos.

Os códigos relacionados que vale manter em ordem ficam logo ao lado neste grupo: a origem 500, o 503 intencional e o 504 de timeout.

Resumo de IA

Uma versão condensada do conteúdo avançado:

• 502 = falha na camada de proxy/gateway. A RFC 9110 §15.6.3 o define como um gateway ou proxy recebendo uma resposta inválida de um servidor de entrada — isso é evidência de uma falha de limite, não prova de qual salto (CDN, proxy ou origem) a causou. A origem pode estar saudável enquanto os visitantes continuam vendo 502.
• Causas distintas, mesma família documentada. 500 (a aplicação na origem apresentou erro), 502 (o proxy recebeu uma resposta inválida, RFC §15.6.3), 503 (a origem está deliberadamente indisponível), 504 (o proxy não recebeu uma resposta a tempo, RFC §15.6.5). A documentação do Google agrupa 500, 502 e 503 sob o mesmo tratamento de 5xx — não documenta paridade específica por status além dessa regra de família.
• Resposta do Googlebot: a taxa de rastreamento cai proporcionalmente à quantidade de URLs com erro, o conteúdo 5xx é ignorado, URLs indexadas são preservadas no curto prazo mas removidas se os erros persistirem, e o rastreamento volta a aumentar gradualmente quando o 2xx retorna — o Google não publica uma duração segura exata nem um cronograma de recuperação garantido.
• A duração importa, mas não há limiar oficial. Picos breves trazem muito menos risco prático; erros que continuam se repetindo são o risco real. O comentário informal de Mueller em novembro de 2025 situou as remoções do índice em torno de “vários dias”, com recuperação relativamente rápida — trate isso como a leitura de um profissional sobre um incidente, não como um SLA documentado.
• Diagnostique correlacionando evidências entre camadas, não confiando apenas na marca: CDN (timeout, falha de DNS/SSL, interrupção do provedor — Cloudflare e AWS CloudFront documentam causas específicas de cada plataforma) → proxy reverso (proxy_pass incorreto, pool esgotado, conexão recusada) → origem (falha da aplicação/PHP-FPM, OOM, esgotamento do banco, WAF bloqueando IPs do proxy/rastreador). Compare cabeçalhos, IDs de rastreamento e logs com registro de horário nos dois lados do salto antes de concluir qual camada falhou.
• Não há uma correção universal. O GSC apenas relata o 502 depois do fato e não pode corrigi-lo. Visitantes também não podem; proprietários sem acesso à infraestrutura devem escalar o problema em vez de editar a configuração; e mudanças destrutivas — allowlisting de WAF, alterações de firewall ou proxy — devem seguir evidências de logs/provedor, não ser um palpite de primeira resposta. Se apenas o Googlebot ou solicitações via CDN recebem 502, suspeite de um bloqueio específico para bots, não de uma interrupção global.

Documentação oficial

Documentação de fonte primária sobre como mecanismos de busca lidam com erros 5xx, incluindo 502.

Google

• Como os códigos de status HTTP afetam os rastreadores do Google — o documento canônico; lista 502 (bad gateway) junto com 500 e 503 e descreve o tratamento compartilhado de rastreamento/indexação.
• Como lidar com a indisponibilidade planejada de um site — por que 503 (não 502, 404 ou 200) é o código correto para indisponibilidade intencional, com um cabeçalho Retry-After. Útil para a distinção entre 502 e 503.
• Especificação do robots.txt — tratamento de erros do servidor — como o Google trata um 5xx no próprio arquivo robots.txt.

Especificação

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — a definição no nível da especificação: um gateway ou proxy recebe uma resposta inválida de um servidor de entrada que acessou ao tentar atender à solicitação. Ela identifica o limite onde a falha foi observada, não qual salto a causou.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — o Bing apresenta problemas de rastreamento do lado do servidor (classe 5xx), incluindo falhas de conectividade, em seus relatórios de erros de rastreamento.

Citações da fonte

Declarações registradas de fontes do Google. Cada link leva diretamente ao trecho citado.

Google — como 5xx (incluindo 502) é tratado

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (tradução) «Erros de servidor 5xx e 429 fazem os rastreadores do Google desacelerarem temporariamente o rastreamento. Na Pesquisa Google, as URLs já indexadas são preservadas no índice, mas acabam removidas.» — Google Search Central, Como os códigos de status HTTP afetam os rastreadores do Google. Ir para a citação
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (tradução) «O Google reduz a taxa de rastreamento do site. A redução é proporcional ao número de URLs individuais que retornam um erro de servidor. Na Pesquisa Google, o pipeline de indexação remove do índice as URLs que retornam um erro de servidor persistentemente.» — o mesmo documento, a linha da tabela que cobre 500, 502 e 503. Ir para a citação
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (tradução) «Quando o servidor começa a responder com um código de status 2xx, o Google aumenta gradualmente a taxa de rastreamento do site.» — same doc. Ir para a citação (tradução) «As citações acima documentam que erros de servidor 5xx e 429 desaceleram temporariamente o rastreamento, preservam inicialmente URLs já indexadas e podem removê-las do índice; a segunda citação acrescenta que a redução da taxa é proporcional à quantidade de URLs com erro e que URLs que retornam erros de servidor persistentemente são removidas.»

John Mueller, Google (Bluesky, 18 de novembro de 2025 — respondendo em uma conversa sobre o pico de 5xx da interrupção da Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (tradução) «Sim. 5xx = o rastreamento do Google desacelera, mas volta a aumentar.» Ver a publicação
• “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.” (tradução) «Se continuar em 5xx por vários dias, algumas páginas podem começar a desaparecer; mesmo assim, elas voltarão rapidamente.» Reproduzido por Matt G. Southern em uma matéria do Search Engine Journal sobre a mesma troca; confirme no tópico original antes de tratá-lo como definitivo. Leia a cobertura (tradução) «As duas citações de Mueller descrevem uma desaceleração seguida de recuperação do rastreamento e uma possibilidade de remoção após vários dias de 5xx persistentes. A segunda é retransmitida por uma cobertura de terceiros, portanto a própria formulação deve ser confirmada no tópico original antes de ser tratada como final.»

Checklist de resposta a 502 Bad Gateway

Quando um 502 aparece — no navegador, no monitoramento ou no relatório de Erro de servidor (5xx) do Search Console — siga esta lista. As etiquetas de papel indicam: [Qualquer pessoa] funciona com ou sem acesso à infraestrutura; [Proprietário do host/CDN/app] exige esse acesso.

• [Qualquer pessoa] Confirme que o erro é real e atual — reproduza a URL agora; um relatório de Erro de servidor (5xx) pode estar atrasado em relação a uma falha já resolvida.
• [Qualquer pessoa] Verifique o escopo — é uma URL, uma seção ou o site inteiro? (O impacto no rastreamento aumenta com a quantidade de URLs com erro.)
• [Qualquer pessoa] Consulte a página de status do seu provedor de CDN/DNS para verificar uma interrupção geral antes de tocar na sua configuração.
• [Proprietário do host/CDN/app] Teste diretamente na origem versus via CDN — se a origem responde 2xx diretamente, mas a CDN retorna 502, o problema está na borda ou entre as duas camadas.
• [Proprietário do host/CDN/app] Verifique se apenas bots/IPs da CDN recebem 502 enquanto os navegadores funcionam — isso aponta para um possível bloqueio de WAF/firewall, não para uma interrupção. Confirme nos logs do firewall/WAF antes de colocar qualquer coisa em allowlist; allowlisting não é uma correção genérica e deve seguir evidências, não precedê-las.
• [Proprietário do host/CDN/app] Leia os logs de erro do proxy (Nginx/Apache/HAProxy) em busca de timeouts do upstream ou entradas de conexão recusada.
• [Proprietário do host/CDN/app] Leia os logs da origem em busca de falhas da aplicação, encerramentos por OOM ou esgotamento de conexões do banco nos horários relevantes.
• [Qualquer pessoa] Verifique o que o Googlebot vê com o teste ao vivo de inspeção de URL do GSC.
• [Proprietário do host/CDN/app] Aplique a correção específica da camada somente quando os logs/evidências do provedor apontarem para ela — mudanças de WAF, firewall, timeout e configuração de proxy são alterações de infraestrutura, não palpites de primeira resposta.
• [Qualquer pessoa] Depois de corrigir, deixe a recuperação acontecer — respostas 2xx fazem o rastreamento voltar a aumentar gradualmente; o Google não publica um cronograma exato de recuperação. Use “Validar correção” apenas para pedir uma nova verificação mais rápida, não como uma “correção”.
• [Proprietário do host/CDN/app] Confirme que você está usando 503 (não 502) para qualquer indisponibilidade planejada.

Meu 502 é um problema de CDN, proxy ou origem?

Um 502 é uma falha entre servidores, então diagnostique percorrendo a pilha em vez de adivinhar. Comece na borda e avance para dentro.

P1. Seu provedor de CDN ou DNS está relatando uma interrupção agora?

• Sim → provavelmente é uma interrupção geral do provedor (o evento da Cloudflare em novembro de 2025 é o exemplo clássico). Normalmente não há nada para corrigir do seu lado. Confirme que sua origem está saudável e espere a recuperação — a taxa de rastreamento do Google volta a aumentar gradualmente quando as respostas 2xx retornam, embora nenhum cronograma exato seja publicado. Pare aqui.
• Não → continue.

**P2. A origem responde 2xx a uma solicitação direta (ignorando a CDN/proxy)?

• Não — a origem também falha → o problema está na camada da origem. Verifique nos logs falhas da aplicação/PHP-FPM, encerramentos por OOM, esgotamento de conexões do banco ou um deploy incorreto. Observe que isso também costuma aparecer como 500 ou 504, dependendo de como o proxy o enxerga. Pare aqui.
• Sim — a origem está saudável diretamente, mas a CDN/proxy retorna 502 → continue. A origem está bem; algo à frente dela não consegue obter uma resposta limpa.

**P3. Navegadores normais funcionam enquanto apenas Googlebot/IPs da CDN recebem 502?

• Sim → suspeite de um bloqueio de WAF ou firewall que trata os intervalos de IP do proxy ou rastreador como invasores. Confirme primeiro nos logs do firewall/WAF e só então coloque em allowlist os intervalos legítimos da CDN e de rastreadores verificados — não faça allowlisting sem essa confirmação. Pare aqui.
• Não — todos recebem 502 via proxy → continue.

**P4. O que os logs do proxy reverso mostram sobre o upstream?

• Timeout / conexão recusada → o proxy alcança o backend, mas não recebe uma resposta válida a tempo → problema de capacidade do backend ou timeout (pool esgotado, timeouts muito curtos). Aumente a capacidade/timeouts ou corrija o backend lento.
• Host incorreto / DNS / falha de handshake SSL para o upstream → configuração incorreta do proxy → corrija o bloco proxy_pass/upstream ou a configuração de TLS entre proxy e backend.

Qualquer que seja a camada: a limpeza de SEO é a mesma e, em grande parte, automática. Quando as URLs retornam 2xx, o Google retoma o rastreamento sozinho — não é necessário reenviar nada.

Mitos e erros a evitar sobre 502

• Mito: “502 é um problema do Google/SEO que corrijo no Search Console.” Não. Um 502 é uma falha de hospedagem/infraestrutura; o Search Console apenas relata isso depois do fato. A correção está na CDN, no proxy ou na origem. “Validar correção” apenas pede ao Google uma nova verificação — não repara nada.
• Mito: “A 502 always means my server is down.” (tradução) «Um 502 sempre significa que meu servidor está fora do ar.» Não. A origem pode retornar 2xx a uma solicitação direta enquanto os visitantes veem 502 pela CDN — por causa de um timeout, uma configuração incorreta do upstream ou uma interrupção da própria CDN. Teste diretamente na origem antes de presumir que o servidor caiu.
• Mito: “502 é menos grave que 500 para SEO.” Não. A documentação do Google dá a 500, 502 e 503 a mesma redução de taxa de rastreamento e a mesma remoção eventual do índice para erros persistentes. Não há tolerância documentada para 502.
• Mito: “Um 502 isolado vai desindexar minha página.” Não. O rastreamento desacelera e depois volta a aumentar. Remoções do índice exigem que o erro persista — a documentação do Google usa essa palavra sem definir um número exato de dias. O comentário informal de Mueller em novembro de 2025 o situou em torno de vários dias, acrescentando que as páginas removidas “voltam rapidamente” — trate isso como a leitura de um profissional sobre um incidente, não como um limiar oficial.
• Mito: “502 e 503 significam a mesma coisa.” Não. 503 é o código intencional de “serviço indisponível” que você deve usar para manutenção planejada (com Retry-After); 502 é uma falha não intencional do proxy. Confundi-los no monitoramento esconde incidentes reais atrás de janelas de manutenção esperadas.
• Mito: “Limpar o cache do navegador corrige um 502 no site inteiro.” Esse é um conselho para um visitante investigar a própria visualização. Se a CDN/proxy/origem está realmente falhando, nenhuma ação no navegador muda algo para as outras pessoas.
• Antipadrão: clicar reflexivamente em “Validar correção” e atualizar o GSC. Durante um pico transitório (ou uma interrupção da CDN), a ação mais rápida e correta muitas vezes é não fazer nada, apenas confirmar a recuperação. O Google administra o retorno gradual automaticamente.

Playbook de incidente: o site está retornando 502

1. Confirme o escopo. Verifique uma URL afetada com o Website Down Checker e depois teste várias URLs com o Bulk HTTP Status Code Checker. Se apenas seu navegador falha, corrija o problema local de rede ou DNS antes de escalar um incidente no site inteiro. Se muitas URLs públicas retornam 502, continue.
2. Registre a resposta com falha. Salve horário, URL, status, cabeçalhos de resposta e qualquer ID de solicitação da CDN. Se o erro for intermitente, repita a solicitação em vez de tratar uma tentativa bem-sucedida como recuperação.
3. Identifique o gateway — trate a marca como um sinal, não como prova. Leia os cabeçalhos e a página de erro com marca em busca da assinatura de uma CDN, proxy reverso ou balanceador de carga, mas confirme isso na página de status do próprio provedor e nos seus logs antes de concluir qual salto falhou; páginas e cabeçalhos com marca são específicos de cada provedor e não provam universalmente a causa. Se o provedor relatar uma interrupção, siga o caminho do incidente; caso contrário, continue em direção à origem.
4. Compare borda e origem. Solicite o hostname público normalmente e depois envie o mesmo hostname diretamente ao IP de origem conhecido com curl --resolve. Se a origem funcionar enquanto a borda retorna 502, investigue conectividade CDN-origem, TLS e configuração do proxy. Se ambos falharem, avance para os logs da aplicação e da origem.
5. Correlacione os logs por horário. Uma conexão recusada ou falha de TLS aponta para o limite gateway/origem; uma resposta upstream malformada ou fechada abruptamente aponta para o serviço de origem. Corrija a camada com falha, não o Search Console.
6. Verifique a recuperação. Repita as verificações pública e direta na origem em URLs representativas. Se as respostas 2xx estiverem estáveis, monitore logs e Search Console enquanto o Googlebot retoma o rastreamento automaticamente. Se os 502s voltarem, retorne à etapa 4 com os novos horários em vez de aumentar as tentativas às cegas.

Prompt: classifique um lote de falhas 502 por camada

Cole um CSV contendo a URL, o horário, o status, os cabeçalhos de resposta, o resultado na borda pública, o resultado direto na origem e qualquer trecho de log correspondente. Remova segredos, cookies, cabeçalhos de autorização e endereços de origem privados primeiro.

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]

Espere uma fila de triagem, não um relatório definitivo de causa-raiz. Valide cada verificação sugerida com cabeçalhos e logs ao vivo.

Reproduza o 502 público

Execute isto em um shell macOS/Linux. Ele imprime os cabeçalhos de resposta sem baixar o corpo e não segue redirecionamentos, para que você veja a primeira resposta.

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

Equivalente no PowerShell:

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

Se a aplicação tratar HEAD de forma diferente, use um GET normal e descarte o corpo:

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

Compare a rota da CDN com a origem conhecida

Substitua 203.0.113.10 por um IP de origem que você controla. --resolve mantém o hostname público no cabeçalho Host e no nome TLS enquanto conecta a esse IP.

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

Não exponha uma origem protegida nem enfraqueça seu firewall apenas para executar este teste. Execute-o de uma rede já autorizada. Um 502 público junto com sucesso na origem direta restringe a falha ao caminho CDN/proxy; falha nos dois caminhos aponta para a origem ou a aplicação.

Ferramentas para delimitar um 502

• Website Down Checker — confirme se a URL está acessível a partir de um ponto de presença externo da Cloudflare e capture tempo, redirecionamentos e evidências DNS delimitadas. Ele responde “isso acontece só comigo?” antes que você comece a alterar a infraestrutura.
• Bulk HTTP Status Code Checker — teste um conjunto representativo de URLs, veja caminhos completos de redirecionamento e latência e exporte os resultados. Use-o para separar uma falha de uma única rota de um incidente 502 mais amplo.
• Painel da sua CDN ou balanceador de carga — compare IDs de solicitação e horários da resposta com falha com os logs da borda e o status do provedor.
• Logs da aplicação e do servidor de origem — confirme se o upstream aceitou a solicitação e se respondeu, resetou ou produziu uma resposta malformada. É isso que transforma uma hipótese de camada em causa-raiz.

Nenhuma ferramenta consegue identificar a camada com falha apenas pelo 502. Compare as evidências da borda pública com uma solicitação direta autorizada à origem e com logs que tenham horário.

Teste seus conhecimentos: 502 Bad Gateway

Cinco perguntas rápidas sobre o que é um 502 e como ele afeta o SEO. Escolha uma resposta para cada pergunta e depois confira.

Recursos que valem seu tempo

Meus textos relacionados

• Guia completo de códigos de status HTTP para SEO — onde 502 e o restante da família 5xx se encaixam e o que cada código sinaliza aos mecanismos de busca.
• Guia para iniciantes em SEO técnico — como a saúde do servidor e o rastreamento se conectam ao quadro maior.
• Robots.txt e SEO: tudo o que você precisa saber — relevante porque um 5xx no arquivo robots.txt é tratado de forma especial.

Da indústria

• Como os códigos de status HTTP afetam os rastreadores do Google (Google Search Central) — a fonte primária: 502 (bad gateway) agrupado com 500/503 e a formulação exata sobre rastreamento/indexação.
• Como lidar com a indisponibilidade planejada de um site (Google Search Central) — a distinção entre 503 e 502 e por que 503 é o código para indisponibilidade intencional.
• Interrupção da Cloudflare provoca picos de 5xx: o que isso significa para SEO (Matt G. Southern, Search Engine Journal) — a interrupção de 2025 como estudo de caso real, com os comentários de Mueller.
• 502 Bad Gateway: referência da MDN (MDN Web Docs) — a definição neutra do status no nível da especificação.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — a especificação de semântica HTTP subjacente.
• Como corrigir um erro 502 Bad Gateway (Kinsta) — um guia detalhado de solução de problemas do ponto de vista do host, para navegador/proprietário do site.
• 502 Bad Gateway: o que significa e como desenvolvedores web podem corrigir esses erros (Webflow) — uma visão orientada a desenvolvedores sobre causas e correções desses erros.

Registro de alterações