500 Erro interno do servidor

TL;DR — Um erro 500 Internal Server Error significa que o servidor falhou enquanto tentava construir a página — não é um problema da sua URL, do navegador ou do rastreador. Um 500 isolado normalmente é tentado novamente pelo Google, e não existe regra dizendo que ele gera um custo. O perigo documentado aparece quando muitas páginas retornam 500 por algum tempo — então o Google reduz o rastreamento e, por fim, pode remover páginas da busca. Comece a correção olhando os logs de erro do servidor, não o navegador.

O que é um erro 500

Um 500 Internal Server Error é a versão web de “algo deu errado e não consigo dizer exatamente o quê”. O servidor recebeu a solicitação, começou a construir a página, encontrou um problema e desistiu — retornando um erro genérico em vez da página. No guia de códigos de status HTTP da Ahrefs, escrevi assim: o servidor “encounters some kind of issue and doesn’t have a better or more specific error code.” (tradução) «encontra algum tipo de problema e não tem um código de erro melhor ou mais específico». Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

Essa é a ideia principal: 500 é um código genérico. Ele diz que algo falhou no lado do servidor, mas não diz o quê. Descobrir o “o quê” é todo o trabalho.

É um problema do servidor, não seu (geralmente)

Erros 500 fazem parte da família 5xx — erros de servidor. Isso é diferente de erros 4xx, como 404 (página não encontrada), que dizem respeito à solicitação (uma URL incorreta ou ausente). Com 500, a URL pode estar perfeitamente correta; o servidor apenas não conseguiu terminar o trabalho. Você também verá parentes do 500 — 502, 503 e 504 — que continuam sendo erros do servidor, mas apontam para situações mais específicas (gateway incorreto, servidor temporariamente indisponível ou timeout).

Um erro 500 prejudica o SEO?

Um 500 isolado e ocasional em uma página? O Google normalmente volta e tenta novamente; se a página carregar na nova tentativa, geralmente o assunto termina aí. O Google não publica uma promessa geral de que uma falha isolada é inofensiva — apenas não documenta um mecanismo que penalize uma falha pontual.

O risco real e documentado são 500s persistentes em muitas páginas. Quando isso acontece:

1. O Google continua tentando, vê os erros persistirem e reduz a velocidade com que rastreia seu site.
2. Se os erros ainda não desaparecerem, o Google acaba removendo essas páginas do índice — elas deixam de aparecer na busca. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

A boa notícia: a própria documentação do Google descreve uma recuperação gradual quando o problema subjacente é corrigido e os rastreamentos voltam a funcionar — mas não garante prazo nem resultado. “Recovery is usually quick” (tradução) «A recuperação geralmente é rápida» é o caso comum, não uma promessa.

Como começar a corrigir

• Confira primeiro os logs de erro do servidor. É ali que mora o motivo real — não no navegador. O navegador mostra apenas “500”; os logs mostram por quê.
• Veja o que mudou recentemente. Plugin, tema ou módulo novo? Um deploy recente? Uma edição em arquivo de configuração como .htaccess? Mudanças recentes são os suspeitos habituais.
• Confira o Google Search Console. O relatório Page Indexing tem uma seção “Server error (5xx)” que mostra em quais URLs o Google está vendo 500s.
• Pergunte ao seu host. Especialmente em hospedagem compartilhada, muitos 500s vêm de limites de memória ou recursos — o host geralmente consegue confirmar isso do lado dele.

Quer a versão aprofundada — exatamente como o Google escala a reação, a regra aproximada de ~1%, a diferença entre 500 e 503 e uma ordem completa de diagnóstico? Mude para a aba Avançado.

TL;DR — A RFC 9110 define 500 como uma condição inesperada que impediu o servidor de atender à solicitação — esse é todo o limite do código; causa, duração e possibilidade de nova tentativa são diagnóstico, não semântica. A reação documentada do Google é gradual: 500s isolados normalmente são tentados novamente; 500s persistentes em todo o site reduzem o rastreamento e, se não forem resolvidos, acabam removendo URLs do índice. Mueller ofereceu uma regra pessoal aproximada — taxas de erro acima de cerca de 1% provavelmente indicam que algo está quebrado — mas isso não é um limiar documentado do Google, e a sequência tentar novamente → rastrear mais devagar → remover descreve comportamentos documentados, não um cronômetro fixo. Diagnostique primeiro pelos logs, depois pelo relatório Server error (5xx) do GSC e pelo Crawl Stats “by response”. A diferença 500/503 importa: 503 é o código sancionado de “volte depois”, com uma janela de tolerância de cerca de 2 dias; um 500 descontrolado não recebe essa tolerância. Evidence for this claim RFC 9110 defines 500 as an unexpected condition encountered by the server that prevented it from fulfilling the request. Scope: web requests Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

O que um 500 realmente é

Comece pela especificação, não pelo resumo de praticante. A RFC 9110 — o padrão de semântica HTTP — define 500 Internal Server Error como uma condição inesperada que impediu o servidor de atender à solicitação. Esse é o limite inteiro do que o código de status informa. Ele não identifica a causa-raiz, o componente que falhou, por quanto tempo o problema durará, se a mesma solicitação funcionaria em uma nova tentativa ou se a recuperação é provável. Tudo depois de “o servidor encontrou algo que não conseguiu tratar” é diagnóstico — e o diagnóstico vive nos seus logs de erro do servidor, não na especificação nem no navegador. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

No guia de códigos de status HTTP da Ahrefs, mantenho a definição voltada para praticantes deliberadamente direta: o servidor “encounters some kind of issue and doesn’t have a better or more specific error code.” (tradução) «encontra algum tipo de problema e não tem um código de erro melhor ou mais específico». É uma explicação em linguagem simples do mesmo limite da RFC — ainda genérica, ainda um sintoma, não um diagnóstico.

Ele fica na família 5xx ao lado de 502 (bad gateway), 503 (service unavailable) e 504 (gateway timeout) — todos do lado do servidor, mas 500 é o que significa “nenhum código melhor se aplica”. Como o próprio status não traz detalhes de diagnóstico, recarregar o navegador não diz por que aconteceu; seus logs de erro do servidor são a fonte de verdade.

Como o Googlebot trata um 500

O rastreador do Google é educado por projeto — ajusta o ritmo à saúde do seu servidor, e respostas 5xx são um dos sinais que ele lê como “diminua o ritmo”. A documentação atual do Google confirma o formato dessa reação: respostas 5xx e 429 provocam uma redução temporária da taxa de rastreamento (proporcional a quantas URLs são afetadas), e URLs que continuam falhando podem acabar removidas do índice, enquanto conteúdo já indexado é preservado nesse intervalo até uma atualização bem-sucedida. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller descreveu essa mesma progressão com suas próprias palavras, em uma sessão do Google SEO Office Hours reproduzida pelo Search Engine Journal:

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (tradução) «A declaração de Mueller descreve tentar novamente os erros 500, reduzir o rastreamento se eles persistirem e remover as URLs do índice se a persistência continuar. Isso é uma descrição de comportamentos documentados, não um cronômetro fixo com transições ou prazos garantidos.»

Leia isso como uma descrição de comportamentos documentados — tentar novamente, rastrear mais devagar, possível remoção — e não como um cronômetro fixo de três etapas com transições ou prazos garantidos; o Google não publica limiares exatos para quando uma etapa vira a seguinte. Um 500 isolado em uma URL normalmente é tentado novamente, e a próxima busca bem-sucedida costuma encerrar o problema — mas isso descreve o caso comum, não garante que uma falha pontual tenha custo zero. O risco real e documentado está nos erros que não desaparecem.

Por que 500s em todo o site são piores que os isolados

Há uma dinâmica pior quando uma grande parte do site retorna 500 ao mesmo tempo. A documentação atual do Google confirma que a redução da taxa de rastreamento cresce conforme o número de URLs afetadas — quanto maior a parte do site que falha, mais o rastreamento diminui. Mueller explicou o raciocínio em termos mais específicos, sugerindo que o Google pode suspeitar que o próprio rastreamento faça parte da sobrecarga:

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (tradução) «Mueller descreve a hipótese de que, quando uma grande parte do site apresenta 500s de forma consistente, o rastreamento pode estar contribuindo para o problema; nesse cenário o Google reduz o rastreamento do site inteiro e, se as páginas parecem realmente desaparecidas, pode removê-las do índice.»

Trate essa formulação causal específica como caracterização do próprio Mueller, e não como texto retirado literalmente da documentação oficial atual do Google — o mecanismo subjacente é documentado (mais URLs falhando, maior redução da taxa), embora o raciocínio causal exato seja mais fácil de verificar na declaração dele. Vale internalizar o ciclo prático: rastreamento agressivo sob exaustão de recursos pode provocar mais 500s → o Google recua do rastreamento do site inteiro → e, se os erros persistirem, as páginas são removidas. Um problema 500 nem sempre é bug de código — às vezes o servidor cede sob carga concorrente que só aparece com picos de rastreamento ou tráfego.

Quanto é “demais”?

Não existe uma linha rígida — a documentação de solução de problemas do Google não publica um limiar de taxa de erros. Mueller ofereceu uma regra pessoal aproximada no SEO Office Hours (novamente reproduzida pelo Search Engine Journal, não uma publicação oficial do Google):

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (tradução) «Mueller apresenta mais de um por cento como um possível sinal de que algo está quebrado, uma regra prática pessoal e não um limite oficial.»

Trate ~1% como um teste informal de cheiro atribuído a Mueller, não como limite documentado ou aplicado pelo Google. Abaixo disso, provavelmente está tudo bem; acima, vale investigar — mas não trate a passagem de 1% como gatilho automático nem ficar abaixo dela como garantia. O único número que o Google assume publicamente é a ausência de um: “we don’t have any strong thresholds”. (tradução) «não temos limiares rígidos».

500 vs. 503: a diferença que importa

É aqui que muita gente erra. Um 503 Service Unavailable é a forma sancionada de dizer a um rastreador “estou temporariamente fora do ar, volte mais tarde”. O Google o trata como intencional e concede uma janela de tolerância. A documentação de rastreamento do próprio Google é explícita:

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (tradução) «A orientação do Google é retornar 503 ou 429 temporariamente quando o servidor estiver sobrecarregado; o Googlebot tentará novamente essas URLs por cerca de 2 dias. Códigos de indisponibilidade mantidos por mais de alguns dias podem fazer o Google reduzir permanentemente ou parar o rastreamento das URLs.»

O contraste: 503 é intencional e recebe uma tolerância de novas tentativas de cerca de 2 dias; um 500 descontrolado é não intencional e não recebe essa tolerância — ele simplesmente é tentado novamente até o Google desistir. Na prática, para manutenção planejada ou defesa deliberada contra sobrecarga, retorne 503 (idealmente com um cabeçalho Retry-After), não 500 e não uma página de erro com 200. Nunca vista uma interrupção real como 200.

Como diagnosticar um 500

Trabalhe em camadas — aplicação/código, plataforma/CMS, infraestrutura e recursos, depois configuração — começando pelo que é mais barato e provavelmente útil. Os passos marcados como (específico de WordPress) são práticas comuns do WordPress, não correções universais; adapte-os à sua stack real.

1. Logs de erro do servidor. error.log / access.log (ou o visualizador de logs da plataforma). Relacione horários às solicitações que falharam. É aqui que aparecem o stack trace, o erro fatal do PHP ou a falha de conexão com o banco. Tudo depois disso é palpite até você ler esses logs.
2. GSC — relatório Server error (5xx). O relatório Page Indexing do Google Search Console sinaliza as URLs nas quais o próprio Google está vendo 500s. Depois abra Crawl Stats e leia a divisão “by response” ao longo do tempo — assim você diferencia uma falha transitória de um problema real e persistente de disponibilidade.
3. Bing Webmaster Tools. Os alertas de erro de rastreamento agrupam Server Errors (5xx) e apontam URLs específicas e a ferramenta Crawl Information.
4. Reproduza como bot, não apenas no navegador. Uma página pode retornar 500 para o Googlebot e carregar normalmente para você — sob carga disparada por rastreamento, configuração incorreta de detecção de bots/firewall ou limites de capacidade que só aparecem com tráfego de bots concorrente. Use URL Inspection (GSC), Fetch as Bingbot ou curl com user-agent de bot para encontrar falhas exclusivas de bot. “Funciona no meu navegador” não é liberação.
5. Conflitos de plugin/tema/módulo (padrão específico do WordPress; adapte em outros lugares). Faça um backup primeiro — sempre tenha um caminho de volta antes de desativar coisas. Depois desative extensões e reative uma por vez para isolar a causadora, verificando permissões/propriedade de arquivos que você tocar. Guias próprios de hospedagem para WordPress relatam esse padrão com frequência, mas isso é uma observação específica de stack, não evidência de que seja a principal causa em todo lugar — em outro CMS ou aplicação personalizada, o equivalente é conflito de módulo, pacote ou middleware de terceiros.
6. Exaustão de recursos. Limites de memória do PHP, conexões de banco, capacidade de hospedagem, picos de tráfego ou rastreamento. Seu host geralmente consegue confirmar isso do lado dele.
7. Configuração e mudanças recentes. Um .htaccess quebrado, edição incorreta de configuração do servidor, deploy recente ou credenciais erradas do banco. Mudanças recentes são o lugar de maior retorno para começar.

Como corrigir (combine a correção com a causa)

Combine a correção com a camada indicada pelo diagnóstico. Estes são padrões comuns relatados em textos de praticantes, não uma lista universal ou ranqueada do que é mais provável na sua stack específica:

• Configuração/deploy causou o erro → reverta a mudança; corrija o .htaccess, a configuração ou as credenciais.
• Exaustão de recursos → aumente limites (memória do PHP, conexões do banco) ou suba o nível de hospedagem; se o rastreamento estiver disparando a sobrecarga, isso também é uma conversa sobre taxa de rastreamento.
• Conflito de plugin/módulo → remova ou substitua a extensão causadora.
• Bug de código → corrija o código e adicione o tratamento de erro ausente.
• Você não consegue descobrir → escale para o host com os horários exatos e as linhas dos logs. Não adivinhe em produção.

Evitando recorrência

Monitore e alerte sobre taxas de 5xx, faça staging das mudanças antes de chegarem à produção, teste carga antes de picos conhecidos de tráfego e — se o próprio rastreamento do Googlebot for o gatilho — gerencie a carga de rastreamento (e retorne 503/429 deliberadamente durante uma sobrecarga real, em vez de deixar o servidor emitir 500s descontrolados).

FAQ

Um erro 500 prejudica o SEO? O risco documentado diz respeito principalmente à persistência em escala. 500s isolados normalmente são tentados novamente, sem penalidade documentada por uma falha pontual; 500s persistentes em todo o site reduzem o rastreamento e podem levar à desindexação.

Quanto tempo leva para o Google desindexar uma página com 500? Não existe prazo fixo. O Google tenta novamente primeiro e reduz o rastreamento; a remoção do índice só ocorre se os erros continuarem. Corrija o problema e as páginas geralmente voltam quando os rastreamentos são bem-sucedidos.

Por que meu site retorna 500 para o Googlebot, mas carrega bem no meu navegador? 500s exclusivos de bot geralmente significam problemas de capacidade ou tratamento de bots — carga disparada pelo rastreamento, regras de firewall/bots ou limites que só aparecem com tráfego concorrente de bots. Confie nos logs, não em uma verificação manual no navegador.

500s podem desacelerar o rastreamento do site inteiro, não apenas das páginas afetadas? Sim — a documentação do Google confirma que a redução da taxa cresce conforme o número de URLs que falham, então uma grande parte do site retornando 500 reduz o rastreamento em todo o site. Mueller também descreveu a possibilidade de o Google suspeitar que o próprio rastreamento esteja contribuindo para a sobrecarga — caracterização dele, não formulação retirada literalmente da documentação oficial atual.

O que causa um 500 no WordPress? No WordPress especificamente, provedores de hospedagem e a comunidade costumam relatar conflitos de plugin/tema, .htaccess corrompido ou limite de memória do PHP — isso é o que se relata para essa plataforma, não uma afirmação de que sejam as principais causas universais de todo 500. A ordem de diagnóstico acima (logs primeiro, depois o que mudou) é a mesma em qualquer CMS.

É seguro tentar automaticamente uma solicitação novamente depois de um 500? Somente depois de verificar primeiro o método e a idempotência da solicitação — o status 500, por si só, não autoriza uma política de retry. GET, HEAD, PUT e DELETE geralmente podem ser repetidos com segurança por serem idempotentes; um POST simples geralmente não é, a menos que sua API garanta idempotência explicitamente (por exemplo, com uma chave de idempotência) — repeti-lo cegamente pode duplicar um pedido, um e-mail ou uma cobrança. Ao tentar novamente, use backoff exponencial com jitter, limite o número de tentativas e defina um orçamento de retry para que um servidor em dificuldade não sofra uma tempestade de novas tentativas além do que já está falhando.

Resumo de IA

Uma versão condensada da parte Advanced:

• 500 = o limite de condição inesperada da RFC 9110. Esse é o escopo inteiro do próprio código — sem causa-raiz, duração ou indicação de que vale tentar novamente. É um sintoma, não um diagnóstico; encontre a causa nos logs do servidor, não no navegador. Diferencia-se de erros 4xx (cliente/solicitação) e dos irmãos 5xx 502/503/504.
• A reação documentada do Google é gradual: redução temporária da taxa de rastreamento (proporcional ao número de URLs afetadas) e possível remoção posterior do índice para URLs que continuam falhando, com recuperação quando as buscas voltam a funcionar. Mueller descreve isso como tentar novamente → rastrear mais devagar → remover do índice — uma descrição de comportamentos documentados, não um cronômetro rígido. Um 500 isolado normalmente é tentado novamente; não há promessa de custo zero, mas o risco documentado real é a persistência em escala.
• 500s em todo o site são piores: a redução cresce conforme o número de URLs que falham. Mueller sugere que o Google pode suspeitar que seu próprio rastreamento faça parte da sobrecarga — caracterização dele, não texto literal da documentação — e forma-se um ciclo em que a carga de rastreamento provoca mais 500s.
• Regra prática, não limiar: Mueller disse que taxas acima de ~1% estão “provavelmente quebradas”, mas é sua formulação pessoal no SEO Office Hours, não um limite documentado do Google — o Google afirma que não possui limiares rígidos.
• 500 vs. 503: 503 (ou 429) é o sinal sancionado de “volte depois”, com tolerância de retry de cerca de 2 dias na documentação do Google; um 500 descontrolado não recebe tolerância. Use 503 (com Retry-After) para indisponibilidade planejada.
• Ordem do diagnóstico: logs do servidor → GSC Server error (5xx) + Crawl Stats “by response” → Bing Webmaster Tools → reproduzir como bot (URL Inspection / curl) → conflitos de plugin/módulo → exaustão de recursos → mudanças de configuração/deploy.
• A segurança do retry depende da solicitação, não do status. Métodos idempotentes (GET/HEAD/PUT/DELETE) geralmente podem ser repetidos; um POST simples normalmente não deve ser repetido sem chave de idempotência. Use backoff, limite de tentativas e orçamento de retry.
• A recuperação geralmente é rápida depois da correção — páginas removidas tendem a voltar quando os rastreamentos são bem-sucedidos, embora o Google não garanta prazo ou resultado.

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca e da especificação HTTP.

Google

• Solucionar erros de rastreamento do Google Search — tratamento de erros de servidor e uso sancionado de 503/429 para sobrecarga temporária.
• Guia aprofundado de como funciona o Google Search — o agendador de rastreamento e o fato de que respostas 5xx são lidas como “diminua o ritmo”.
• Relatório Crawl Stats — divisão “by response” (incluindo Server error (5xx)) para distinguir uma falha pontual de um problema persistente.
• Reduzir a taxa de rastreamento do Googlebot — o caminho correto e deliberado para desacelerar o rastreamento, em vez de deixar o servidor emitir 500s descontrolados.

Bing / Microsoft

• Bing Webmaster Tools — lista de alertas de erro de rastreamento — como o Bing agrupa Server Errors (5xx) e onde inspecionar as URLs afetadas.

Especificação/referência HTTP

• MDN — 500 Internal Server Error — definição do próprio código de status.
• RFC 9110 §15.6.1 — 500 Internal Server Error — semântica HTTP autoritativa.

Citações da fonte

Declarações registradas. Quando uma página é renderizada por JavaScript ou uma fonte foi reproduzida por cobertura secundária, isso é sinalizado com uma ressalva <small>.

Google — o caminho de escalada

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (tradução) «Não temos limiares rígidos para isso. Em essência, tentamos novamente os erros 500; se continuarmos vendo-os, reduzimos o rastreamento e, se persistirem, removemos essas URLs do índice.» — John Mueller, Google. Leia a cobertura Reproduzido pela transcrição do Search Engine Journal de um vídeo do Google SEO Office Hours; confirme a redação exata no vídeo-fonte antes de tratá-la como definitiva.
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (tradução) «Se uma grande parte do site tiver erros 500 de forma consistente, o Google pode reduzir o rastreamento do site inteiro e, se as páginas parecerem realmente desaparecidas, removê-las.» — John Mueller, Google. Leia a cobertura Reproduzido pelo Search Engine Journal; confirme a formulação literal no vídeo original.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (tradução) «Minha impressão é que, se você estiver vendo algo acima de um por cento, isso parece indicar que há algum problema.» — John Mueller, Google, sobre uma regra prática aproximada para a taxa de erros. Leia a cobertura Reproduzido pelo Search Engine Journal; confirme a formulação literal no vídeo original. (tradução) «As citações registram a sequência de tentar novamente, reduzir o rastreamento e remover URLs quando 500s persistem, além da caracterização de Mueller sobre 500s em grande parte do site e sua regra pessoal aproximada de 1%.»

Google — o sinal sancionado de “diminua o ritmo” (documentação verificada)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (tradução) «Retorne códigos HTTP 503 ou 429 temporariamente ao Googlebot quando o servidor estiver sobrecarregado; ele tentará novamente por cerca de 2 dias, e códigos de indisponibilidade mantidos por mais tempo podem reduzir ou interromper permanentemente o rastreamento.» — Google Search Central docs. Jump to quote

Patrick Stox — a definição (Ahrefs, verificada)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (tradução) «500 Internal Server Error — o servidor encontra algum tipo de problema e não tem um código de erro melhor ou mais específico». — my HTTP status codes guide on the Ahrefs blog. Jump to quote

Checklist de triagem de erros 500

Siga de cima para baixo assim que os 500s aparecerem:

• Extraí os logs de erro do servidor e encontrei o erro real (stack trace / fatal do PHP / falha de banco) — não apenas o “500” do navegador.
• Verifiquei o que mudou recentemente — plugin/tema/módulo novo, deploy, edição em .htaccess ou configuração do servidor, credenciais do banco alteradas.
• Abri GSC → Page Indexing → Server error (5xx) para ver quais URLs o Google está encontrando com 500.
• Li o GSC Crawl Stats “by response” ao longo do tempo para distinguir transitório de persistente.
• Verifiquei os alertas de erro de rastreamento do Bing Webmaster Tools para as mesmas URLs.
• Reproduzi como bot (URL Inspection / Fetch as Bingbot / curl com user-agent de bot), não apenas no navegador.
• Descartei exaustão de recursos (memória do PHP, conexões de banco, capacidade de hospedagem) com o host.
• Isolei qualquer conflito de plugin/módulo desativando e reativando um por vez.
• Confirmei que não estou emitindo 500s descontrolados durante manutenção planejada — use 503 (com Retry-After).
• Depois da correção, verifiquei que a taxa de erro voltou abaixo do teste informal de ~1% (regra prática de Mueller, não limiar documentado do Google) e que o GSC mostra rastreamentos bem-sucedidos.

Runbook: “O site está retornando 500s — o que verifico primeiro?”

Uma ordem de operações sem pânico. Faça nesta sequência e pare quando encontrar e corrigir a causa.

0. Determine o escopo (2 minutos). É uma URL, um template/seção ou o site inteiro? Uma URL é baixa urgência (o Google tenta novamente). O site inteiro é a emergência — esse é o padrão que faz o Google reduzir o rastreamento do site.

1. Leia os logs de erro do servidor. Comece por error.log. Relacione horários às falhas. Procure a causa real: erro fatal do PHP, falha de conexão com banco, segfault ou encerramento por falta de memória. Tudo abaixo é palpite até você fazer isso.

2. Relacione com “o que mudou”. Ordene por mudanças recentes: último deploy, plugin/tema/módulo adicionado ou atualizado, edição de .htaccess, credenciais do banco rotacionadas ou alteração de configuração. A maioria dos 500s remonta a uma mudança das últimas horas ou dias. Se puder, reverta primeiro e diagnostique depois — restaurar o serviço compra tempo.

3. Confirme a visão do mecanismo de busca. GSC → Page Indexing → Server error (5xx) para as URLs afetadas, depois Crawl Stats → by response para ver se é uma falha pontual ou persistente. Confira também os alertas de erro de rastreamento do Bing Webmaster Tools. Isso mostra a urgência do relógio de SEO.

4. Reproduza como o bot vê. Se humanos carregam a página mas o Googlebot recebe 500, teste como bot: URL Inspection, Fetch as Bingbot ou curl -A "Googlebot" <url>. 500s exclusivos de bot apontam para capacidade, regras de firewall/bot ou carga disparada por rastreamento — uma correção diferente de um bug de código.

5. Faça uma busca binária nos suspeitos habituais.

• Plugins/módulos: desative todos e reative um por vez até quebrar novamente.
• Recursos: verifique o limite de memória do PHP, o teto de conexões do banco e a capacidade de hospedagem com o host — especialmente se os 500s se agruparem em torno de picos de tráfego ou rastreamento.
• Configuração: reverta o .htaccess ou a configuração do servidor para uma versão conhecida como boa.

6. Se o rastreamento for o gatilho, não apenas absorva-o. Quando o volume de rastreamento do Googlebot sobrecarrega você, a alavanca temporária correta é retornar 503/429 (com Retry-After) — não deixar o servidor emitir 500s descontrolados. O Google respeita 503 como “volte depois” por cerca de 2 dias; 500 não recebe essa tolerância.

7. Verifique a recuperação. Taxa de erros abaixo do teste informal de ~1%, logs limpos e GSC Crawl Stats mostrando buscas bem-sucedidas novamente. Páginas removidas geralmente voltam quando os rastreamentos funcionam — sem prazo garantido, mas normalmente rápido.

Padrão de escalada para lembrar: 500 ocasional → normalmente tentado novamente, baixo risco documentado → 500 persistente → rastreamento diminui → ainda persistente → URLs saem do índice. O Google não publica o tempo exato dessas transições; seu trabalho é quebrar a cadeia antes que chegue lá.

Qual código de servidor devo retornar?

Use isto ao decidir o que servir ou interpretar o que está vendo.

A falha é intencional (manutenção/defesa deliberada contra sobrecarga)?

• Sim → Retorne 503 Service Unavailable com um cabeçalho Retry-After. O Google o trata como temporário e tenta novamente por cerca de 2 dias. Não sirva uma página de erro 200 e não deixe cair em 500.
• Não (é uma falha real e inesperada) → continue.

Todos recebem o erro, ou apenas o rastreador?

• Todos → É um problema de código/configuração/banco. Vá aos logs de erro do servidor e à lista “o que mudou”. Reverta mudanças recentes.
• Somente Googlebot/Bingbot → Suspeite de capacidade, regras de detecção de bots/firewall ou carga disparada por rastreamento. Reproduza como bot, verifique recursos e regras de bot.

É uma URL ou uma grande parte do site?

• Uma URL/ocasional → Baixa urgência. O Google tenta novamente; corrija quando puder, mas confirme que é realmente isolado.
• Site inteiro/persistente → Emergência. Esse é o padrão que faz o Google reduzir o rastreamento e eventualmente desindexar. Restaure o serviço primeiro (reverta), descubra a causa depois.

A taxa de erros está acima de ~1%?

• Sim → Vale investigar como provável problema real — é a regra prática não oficial de Mueller, não um limiar documentado do Google.
• Não → Provavelmente está tudo bem — mas monitore a tendência, não apenas o retrato atual.

Prompt: correlacione um 500 com logs e um deploy

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt: transforme um stack trace em um plano de teste seguro

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: amostre uma lista de URLs em busca de respostas 5xx

Execute isto com uma URL absoluta por linha em urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

A saída separa rotas isoladas de uma falha ampla e registra latência sem baixar corpos de resposta.

PowerShell: exporte a mesma amostra de status

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: conte status 5xx em um access log

Ajuste a posição do campo de status para corresponder ao formato documentado do seu log antes de confiar no resultado.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Ferramentas para encontrar e diagnosticar 500s

• Logs de erro do servidor — error.log/access.log ou o visualizador de logs do host/plataforma. A ferramenta mais importante; a causa real vive aqui.
• Google Search Console — Page Indexing — a seção “Server error (5xx)” lista as URLs nas quais o Google está vendo 500s.
• GSC — relatório Crawl Stats — a divisão “by response” ao longo do tempo separa uma falha pontual de um problema persistente.
• GSC — URL Inspection — busque uma URL específica como o Google para reproduzir um 500 exclusivo de bot.
• Bing Webmaster Tools — alertas de erro de rastreamento agrupam Server Errors (5xx) e apontam para Crawl Information.
• curl — reproduza com qualquer user-agent: curl -I -A "Googlebot" <url> para ver o status como um bot o vê.
• Rastreadores/auditorias de site — Ahrefs Site Audit e Screaming Frog SEO Spider encontram respostas 5xx e mostram padrões (um template ou seção inteira falhando).
• Monitoramento de uptime/status — alertas sobre taxas de 5xx para você descobrir o pico antes do Google.

Recursos que valem seu tempo

Meus textos relacionados

• HTTP Status Codes: A Guide to How They Impact SEO & UX — minha referência completa de códigos de status, incluindo a definição de 500 e a visão mais ampla do rastreamento de 5xx.
• The Beginner’s Guide to Technical SEO — onde os erros de servidor entram no quadro técnico maior.

Minhas apresentações

• How Search Works (SlideShare) — minha explicação de rastreamento e de como a saúde do servidor retroalimenta o processo. (Vale minha ressalva habitual: “Este é meu entendimento dos sistemas… não será 100% completo ou preciso”.)

Da indústria

• Como os códigos de erro 500 podem afetar negativamente a indexação (Search Engine Journal) — texto de Matt G. Southern com as citações de John Mueller sobre tentar novamente → rastrear mais devagar → remover do índice e a regra de ~1%.
• Como corrigir o erro “Erro do servidor (5xx)” no Google Search Console (Search Engine Land) — passo a passo do relatório do GSC.
• Como corrigir “Erro do servidor (5xx)” no Google Search Console (Onely) — o que são erros 5xx, onde encontrá-los no GSC e um caminho de correção.
• How to Fix a 500 Internal Server Error on Your Site (Kinsta) — lista detalhada centrada em hospedagem WordPress (logs, plugins/temas, memória do PHP, .htaccess, permissões).
• 5xx Server Errors: A Guide to Finding & Fixing 5xx Issues (Lumar) — visão empresarial/técnica forte em logs e crawl budget.
• How to Fix 5xx Server Error in Google Search Console (Sitechecker) — outro guia do relatório do GSC.

Vídeos

• Google Search Central (YouTube) — o arquivo de SEO Office Hours, de onde vem a orientação de John Mueller sobre erros de servidor e rastreamento (a sequência tentar novamente → rastrear mais devagar → remover citada acima). Canal

Teste seus conhecimentos: 500 Internal Server Error

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

Registro de alterações