429 Muitas solicitações

TL;DR — Um 429 Too Many Requests significa que seu servidor disse a um visitante ou bot: “você está solicitando páginas demais rápido demais — diminua o ritmo”. Isso se chama rate limiting. A boa notícia para SEO: 429 é o único erro da família que o Google trata com cuidado. Em vez de remover suas páginas, o Googlebot simplesmente reduz o ritmo e rastreia você mais devagar por algum tempo. Só vira um problema se seu servidor continuar enviando 429s por vários dias.

O que um 429 realmente diz

Sempre que um navegador, script ou rastreador de mecanismo de busca pede uma página ao seu servidor, o servidor responde com um código de status. 200 significa “aqui está a página”. Um 429 significa “você fez solicitações demais em uma janela curta, então não vou responder esta — volte mais tarde”.

Os servidores usam 429 de propósito para se proteger. Se um visitante (ou bot) estiver sobrecarregando o site rápido o bastante para deixá-lo lento para todos, retornar 429 é a forma de o servidor dizer pare por um momento. Uma resposta 429 bem-comportada também inclui o cabeçalho Retry-After — uma observação que diz ao cliente quantos segundos esperar antes de tentar novamente. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

Por que 429 é o erro “gentil” para SEO

Aqui está a parte que surpreende as pessoas. 429 fica no grupo de “erro de cliente 4xx”, ao lado de códigos como 403 (acesso proibido) e 404 (não encontrado). Esses dois são más notícias se o Google continuar vendo-os — o Google acaba removendo essas páginas da busca.

429 é a exceção. O Google interpreta um 429 como o servidor está ocupado, diminua o ritmo — da mesma forma que interpreta um erro de servidor 503 ou 500. Assim, em vez de remover suas páginas, o Googlebot apenas rastreia seu site mais lentamente por algum tempo. O Google recomenda de fato o 429 como a forma correta de desacelerar um rastreador e alerta especificamente contra usar 403 ou 404 para isso. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

Quando 429 vira um problema

Um 429 ocasional é completamente normal e se corrige sozinho — quando seu servidor para de enviá-los, o Google acelera o rastreamento novamente por conta própria. Você não precisa pedir isso.

O perigo aparece quando os 429s persistem. Se o Googlebot continuar encontrando 429 nas mesmas páginas por mais de um ou dois dias, o Google pode começar a remover essas páginas do índice — porque, do lado do Google, parece que seu site ficou quebrado e indisponível por dias. Portanto, 429 é uma ferramenta de curto prazo, não uma configuração permanente.

O que fazer

• Se você não pretendia enviar 429s (eles aparecem de surpresa no Google Search Console ou na sua ferramenta de rastreamento), algo está aplicando rate limiting de forma agressiva demais — muitas vezes um plugin de segurança, firewall (WAF) ou seu provedor/CDN. Encontre-o e afrouxe o limite para que ele pare de bloquear mecanismos de busca reais.
• Se você pretendia enviá-los — por exemplo, porque seu servidor está sob carga intensa — tudo bem; apenas limite o período e adicione um cabeçalho Retry-After. Desative-o dentro de um ou dois dias.

Quer o passo a passo da configuração do servidor, a formulação exata do Google e os mitos que as pessoas entendem errado? Mude para a aba Avançado.

TL;DR — 429 é o único código 4xx que o Google trata como 5xx: quando encontra um número significativo de respostas 500/503/429, interpreta isso como sinal de sobrecarga do servidor e reduz a taxa de rastreamento do Googlebot em todo o hostname, em vez de remover conteúdo. É o único código que o Google recomenda para desacelerar um rastreador — nunca 403 ou 404. A documentação do Google dá a orientação de uso emergencial “algumas horas ou 1–2 dias” — não uma janela segura garantida; 429s persistentes nas mesmas URLs trazem o risco de elas serem removidas do índice, e a taxa volta a aumentar (não necessariamente de imediato ou por completo) quando o volume de erros cai. A RFC 6585 diz que uma resposta 429 SHOULD explicar a condição e MAY incluir Retry-After — enviá-lo é uma prática recomendada, não uma exigência de conformidade. Limite o tráfego correto e verifique a identidade dos rastreadores antes de criar exceções.

O que é 429 no nível do protocolo

Diretamente da especificação, nas palavras da MDN: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (tradução) «A resposta de erro do cliente HTTP 429 Too Many Requests indica que o cliente enviou solicitações demais em determinado período; esse mecanismo de pedir que o cliente reduza a taxa de solicitações é normalmente chamado de rate limiting.» Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

A seção 4 da RFC 6585 é mais precisa do que a maioria dos resumos. Uma representação 429 SHOULD explicar a condição e MAY incluir um cabeçalho Retry-After dando ao cliente um número concreto de segundos (a RFC 9110 também permite uma data HTTP) para esperar antes de tentar novamente — Retry-After é prática recomendada, não requisito de conformidade. A especificação também não define como identificar o cliente ou como contar solicitações; isso fica inteiramente a cargo de quem emitiu a resposta (por IP, sessão, chave de API, recurso — política de implementação, não de protocolo). Outra regra fácil de perder: a RFC 6585 diz que uma resposta 429 não deve ser armazenada por um cache. Se você encontrar um 429 que parece armazenado em cache ou reproduzido em uma origem saudável, o problema é de um intermediário (CDN, proxy), não de a origem ter decidido limitar você novamente.

Sempre expliquei isso de forma direta no meu guia Códigos de status HTTP e seu impacto em SEO: 429 é “uma forma de rate limiting para proteger o servidor porque o cliente enviou solicitações demais ao servidor rápido demais”. Formalmente, é um erro de cliente — o cliente fez algo errado ao pedir demais. Mas é exatamente nesse ponto que a história de SEO diverge da especificação.

A única exceção entre os códigos 4xx

O fato mais importante desta página: o Google não trata 429 como o restante da família 4xx. Gary Illyes escreveu uma publicação inteira no Google Search Central sobre isso em fevereiro de 2023, porque sites e CDNs suficientes estavam usando 404s de forma indevida para limitar o Googlebot e o Google precisou dizer para que parassem.

Sua regra é: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (tradução) «A única exceção é 429, que significa “solicitações demais”. Esse erro sinaliza a qualquer robô bem-comportado, inclusive o Googlebot, que precisa desacelerar porque está sobrecarregando o servidor.» A referência de códigos de status do Google acrescenta: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tradução) «Não use os códigos 401 e 403 para limitar a taxa de rastreamento; os códigos 4xx, exceto 429, não têm efeito sobre essa taxa.»

Assim, enquanto 403 e 404 fazem seu conteúdo ser removido da Busca, 429 produz uma desaceleração temporária. O Google o agrupa literalmente com os erros de servidor: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tradução) «Os rastreadores do Google tratam o status 429 como sinal de que o servidor está sobrecarregado, e ele é considerado um erro de servidor.» Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

É isso que torna 429 o irmão útil de 503 Service Unavailable (o sinal tradicional de manutenção ou indisponibilidade temporária) — e o oposto exato de 403 Forbidden, que é a ferramenta errada para rate limiting, apesar de muitos firewalls usarem esse padrão.

O impacto na taxa de rastreamento é em todo o hostname — com um limiar

É comum confundir duas escalas diferentes, então vale separá-las. A forma como você conta e identifica um limite — por IP, sessão, chave de API, recurso ou servidor — é sua política; a especificação HTTP não a define. O que o Google faz com os erros que observa é um comportamento documentado separado e depende do volume, não de uma única resposta: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (tradução) «A infraestrutura de rastreamento do Google reduz a taxa de rastreamento do site quando encontra um número significativo de URLs com status HTTP 500, 503 ou 429.» Depois que o limiar é atingido, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (tradução) «A taxa reduzida afeta todo o hostname, tanto o rastreamento das URLs que retornam erros quanto o das URLs que retornam conteúdo.»

Em outras palavras, se você aplicar 429 a um subconjunto de páginas (por exemplo, um caminho de API pesado) em volume real, o Googlebot reduzirá o rastreamento do hostname inteiro — inclusive das páginas que continuam retornando 200. Esse costuma ser o efeito pretendido quando o objetivo é reduzir a carga total. Mas um único 429 isolado em um caminho, por si só, não estabelece esse efeito em todo o hostname — a formulação do Google se refere a “um número significativo” de respostas de erro, não a uma única resposta.

A orientação de 1–2 dias — quando 429 fica arriscado

429 é um sinal de curto prazo, e o Google dá uma orientação concreta para uso emergencial — não uma janela segura garantida nem um limite rígido. A documentação para reduzir a taxa de rastreamento diz: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1–2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (tradução) «Se você precisar reduzir urgentemente a taxa de rastreamento por pouco tempo, como algumas horas ou 1–2 dias, retorne o status 500, 503 ou 429 em vez de 200 às solicitações de rastreamento.»

Depois disso, o risco aumenta, embora o Google o apresente como possibilidade, não como promessa: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (tradução) «O Google não recomenda manter esses códigos por um período longo, pois a URL pode ser removida do índice se o Googlebot os observar na mesma URL por vários dias.» A referência de status diz o mesmo para 5xx e 429: “already indexed URLs are preserved in the index, but eventually dropped.” (tradução) «URLs já indexadas são preservadas no índice, mas acabam sendo removidas.»

O modelo de risco, dito com honestidade: um 429 de curto prazo cabe na janela que o Google recomenda para uso emergencial; um 429 sustentado nas mesmas URLs por vários dias é quando a linguagem do próprio Google passa a ser “pode” e “acaba sendo removida” — um risco documentado, não um resultado garantido em nenhuma direção. É a mesma dinâmica de um 503 prolongado.

A taxa de rastreamento se recupera automaticamente

O lado tranquilizador é que não existe uma penalidade que acompanhe o site. Quando os erros diminuem, o Google diz que “the crawl rate will automatically start increasing again.” (tradução) «a taxa de rastreamento começará a aumentar automaticamente». Você não precisa protocolar nada nem solicitar novamente. Observe a formulação exata: o Google diz “começa a aumentar”, não “instantly returns to your prior rate.” (tradução) «volta instantaneamente à taxa anterior». Trate a recuperação como uma direção documentada, sem prazo fixo ou ponto final garantido, não como um SLA.

(Compare isso com o problema oposto: querer que o Google rastreie você permanentemente menos. Se não for viável servir erros, o Google diz para “file a special request to report a problem with unusually high crawl rate” (tradução) «enviar uma solicitação especial para relatar um problema de taxa de rastreamento excepcionalmente alta» — um caminho manual que pode levar dias e não é garantido. Não há esse atrito na recuperação.)

Como o Bing lida com 429

Há muitos relatos de que o Bingbot se comporta de forma semelhante — 429/500/503 sinalizam sobrecarga e o Bingbot recua — embora eu não tenha conseguido confirmar de forma independente a formulação atual nas páginas de ajuda do próprio Bing nesta pesquisa (são SPAs renderizadas por JavaScript que não forneceram texto estático buscável). Trate a afirmação de paridade como um relato do setor, não como algo verificado na documentação atual do Bing. O que o Bing confirma, em sua orientação histórica, são dois controles proativos que o Google não oferece da mesma forma:

• Crawl Control no Bing Webmaster Tools, uma grade de solicitações por segundo em que você define a velocidade do Bingbot por hora do dia.
• A diretiva crawl-delay do robots.txt. A orientação atual do Bing Webmaster documenta valores de 1–20 segundos. Isso é específico do Bing; não limita o Googlebot.

No Bing, portanto, você pode limitar proativamente com crawl-delay ou Crawl Control, em vez de reativamente com códigos de status. (O Google aposentou seu próprio controle manual de taxa de rastreamento em 2024 e agora depende inteiramente das respostas do seu servidor.)

Quando você enviaria 429 deliberadamente

Motivos legítimos para retornar 429 de propósito:

• Carga emergencial no servidor — um pico de tráfego, uma migração malfeita ou uma interrupção em que você precisa que o Googlebot diminua o ritmo agora por algumas horas.
• Proteção de APIs e endpoints que não são HTML contra abuso de rastreadores/bots — rastreadores de mecanismos de busca, rastreadores de SEO de terceiros (Ahrefs, Screaming Frog) e scrapers todos encontram limites destinados a impedir abuso.

Para que 429 não serve: bloquear permanentemente bots que você nunca quer. Se você não quer que algo seja rastreado, use uma regra de desautorização em robots.txt, não 429. Se quer manter uma página fora do índice, use noindex. 429 significa apenas “mais tarde”, não “nunca”.

429s não intencionais — os culpados habituais

Quando 429s aparecem no relatório Page indexing ou Crawl Stats do GSC sem que você os tenha configurado, a origem costuma ser uma destas — não tenho evidência sólida para uma classificação universal do que é mais comum; trate-a como uma lista de candidatos a confirmar ou excluir, não como diagnóstico:

• Regras de WAF/firewall disparando por engano em intervalos legítimos de IP de rastreadores.
• Limites padrão de hospedagem compartilhada ou CDN apertados demais para um rastreamento real.
• Ferramentas de gerenciamento de bots classificando Googlebot ou Bingbot como tráfego abusivo.
• Middleware agressivo de rate limiting destinado a abuso de API capturando seus próprios rastreadores.

Antes de alterar um limiar ou criar uma regra que isente bots de busca reais, estabeleça a proveniência — não adivinhe qual camada é dona da resposta. Colete os cabeçalhos brutos, as linhas exatas do log de solicitações (não um resumo do painel), o identificador da regra ou zona de limite que disparou, a chave do cliente contabilizada (IP, sessão, chave de API), a rota, o POP ou local da borda da CDN e a janela de tempo. Esse conjunto mostra qual camada emitiu o 429 e o que ela estava contando — só então faz sentido afrouxar o limite ou adicionar uma exceção. Verifique a identidade do rastreador com DNS reverso mais direto (o método oficial do Google), não apenas com a string de user-agent — user-agents falsificados de “Googlebot” são comuns. A aba Scripts contém os comandos exatos.

A versão curta do playbook

1. Use 429 ou 503 com Retry-After para desacelerar um rastreador — nunca 403 ou 404.
2. Mantenha por horas ou 1–2 dias — depois disso, URLs podem ser removidas.
3. Lembre que a limitação é em todo o hostname e se recupera automaticamente quando os erros param.
4. Limite o tráfego correto e verifique a identidade do rastreador antes de isentar bots.

Resumo de IA

Uma versão condensada da parte Advanced:

• 429 Too Many Requests = o servidor dizendo a um cliente (navegador, script ou rastreador) que ele enviou solicitações demais rápido demais — “rate limiting”. Formalmente, é um erro 4xx de cliente.
• Nível de protocolo: a RFC 6585 diz que uma resposta 429 SHOULD explicar a condição e MAY incluir Retry-After — recomendado, não obrigatório. Ela também determina que o 429 NÃO DEVE ser armazenado por cache; um 429 armazenado ou reproduzido é um bug do intermediário, não da origem. A forma de contar ou identificar o limite (IP, sessão, chave de API, recurso) é sua política — a especificação não a define.
• A única exceção 4xx: o Google trata 429 como erro de servidor 5xx, não como 403/404. Interpreta “server overloaded, slow down” (tradução) «servidor sobrecarregado, diminua o ritmo» e reduz o rastreamento em vez de remover conteúdo.
• O Google recomenda 429 (e 500/503) para desacelerar rastreadores — nunca 403 ou 404. Gary Illyes publicou uma orientação em 2023 especificamente para dizer que sites e CDNs parassem de usar 404 para limitar o Googlebot.
• A limitação é em todo o hostname, acima de um limiar — a formulação do Google condiciona o efeito ao encontrar “um número significativo” de respostas 500/503/429, não a um único 429. Acima do limiar, páginas que continuam servindo 200 também são rastreadas menos.
• Orientação de 1–2 dias, não uma linha rígida: a documentação do Google fala em “algumas horas ou 1–2 dias” para emergências. 429s sustentados nas mesmas URLs por vários dias podem fazer com que sejam removidas do índice — “pode” e “acaba”, não garantia — de modo semelhante a um 503 prolongado.
• A recuperação é direcional, não instantânea: pare de enviar 429 e o Google diz que a taxa “começa a aumentar novamente” — sem nova solicitação e sem penalidade persistente, mas também sem promessa de restauração imediata ou completa em prazo fixo.
• Novas tentativas no cliente: respeite um Retry-After válido; quando ausente, a RFC não prescreve fórmula — use backoff limitado com jitter, limite tentativas e verifique idempotência antes de repetir solicitações não idempotentes.
• Limite o tráfego correto e verifique a identidade do rastreador (DNS reverso mais direto) antes de isentar bots.
• Bing é amplamente relatado como recuando de forma semelhante diante de 429, embora essa paridade não tenha sido confirmada de forma independente na documentação atual do Bing nesta pesquisa; a orientação histórica do Bing confirma crawl-delay e a grade Crawl Control como alternativas proativas.
• 429 não é bloqueio: significa “mais tarde”, não “nunca”. Use robots.txt para manter bots fora e noindex para remover uma página do índice.

Documentação oficial

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

Google

• Evite 403s ou 404s para limitação de taxa — publicação de Gary Illyes de fevereiro de 2023; a declaração principal de que 429 é a exceção e 403/404 são ferramentas erradas.
• Reduza a taxa de rastreamento do Google — orientação sobre retornar 500, 503 ou 429, a janela de 1–2 dias, a limitação em todo o hostname e a recuperação automática.
• Códigos de status HTTP, erros de rede e DNS — como o Google trata cada código; 429 agrupado com erros de servidor (também disponível no caminho antigo search/docs/crawling-indexing/http-network-errors).
• Reduza a taxa de rastreamento do Google — caminho de solicitação especial — o caminho manual para relatar uma taxa de rastreamento excepcionalmente alta quando não der para servir erros.

Bing / Microsoft

• Crawl Control — agendador de solicitações por segundo do Bingbot no Bing Webmaster Tools.
• Orientação do Bingbot — orientação atual do Bing Webmaster sobre crawl-delay (1–20 segundos).

Especificação HTTP

• MDN — 429 Muitas solicitações — definição do protocolo, Retry-After e fundamentos de limitação de taxa.

Citações da fonte

Declarações registradas do Google, do Bing e da especificação HTTP. Cada link é profundo e salta para a passagem citada na página de origem.

Google — Gary Illyes, “Não use 403s ou 404s para rate limiting” (fev. 2023)

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (tradução) «Nos últimos meses, observamos um aumento de proprietários de sites e algumas redes de distribuição de conteúdo tentando usar erros 404 e outros erros 4xx de cliente (mas não 429) para reduzir a taxa de rastreamento do Googlebot.» Ir para a citação
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (tradução) «A única exceção é 429; esse erro sinaliza a qualquer robô bem-comportado, inclusive o Googlebot, que precisa desacelerar porque está sobrecarregando o servidor.» Ir para a citação
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (tradução) «Todos os códigos de status HTTP 4xx (novamente, exceto 429) farão com que seu conteúdo seja removido da Busca do Google.» Ir para a citação
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (tradução) «Use o Search Console para reduzir temporariamente a taxa de rastreamento. Retorne um status HTTP 500, 503 ou 429 ao Googlebot quando ele estiver rastreando rápido demais.» Ir para a citação

Google — Reduza a taxa de rastreamento / referência de códigos de status

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (tradução) «Se você precisar reduzir urgentemente a taxa de rastreamento por pouco tempo, como algumas horas ou 1–2 dias, retorne 500, 503 ou 429 em vez de 200 às solicitações de rastreamento.» Ir para a citação
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (tradução) «A taxa reduzida afeta todo o hostname do site; quando o número desses erros diminui, a taxa de rastreamento começa a aumentar automaticamente.» Ir para a citação
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (tradução) «Não recomendamos fazer isso por um período longo; a URL pode ser removida do índice do Google.» Ir para a citação
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (tradução) «Os rastreadores do Google tratam o status 429 como sinal de sobrecarga do servidor, e ele é considerado um erro de servidor.» Ir para a citação
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tradução) «Não use os códigos 401 e 403 para limitar a taxa de rastreamento; os códigos 4xx, exceto 429, não têm efeito sobre essa taxa.» Ir para a citação

MDN — definição do protocolo

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (tradução) «A definição da MDN descreve o 429 como a resposta para solicitações demais em determinado período e chama de rate limiting o mecanismo de pedir ao cliente que reduza a taxa.» Ir para a citação

Bing — orientação atual do Webmaster

• Orientação do Bingbot documenta valores de crawl-delay de 1–20 segundos. Trate isso como orientação específica do Bing, não como um limite genérico para rastreadores.

Corroboração do setor sobre a declaração do Google

• A publicação de Illyes de fevereiro de 2023 foi reproduzida por Search Engine Land, Search Engine Roundtable e Search Engine Journal — as três apresentam 429 como “a única exceção”. São textos da imprensa especializada sobre a mesma publicação do Google; a fonte primária é a publicação de Illyes citada acima.

Envie um 429 correto — com Retry-After

A parte mais importante de um 429 bem-comportado é o cabeçalho Retry-After. Ele diz a qualquer cliente compatível — inclusive o Googlebot — quanto tempo esperar. Pode conter um número de segundos ou uma data HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

Omitir Retry-After não quebra a conformidade, mas incluí-lo é uma prática recomendada e fornece aos rastreadores um sinal concreto de recuo.

nginx — rate limiting que retorna 429

Por padrão, o limit_req do nginx retorna 503. Para semântica amigável a rastreadores, substitua por 429 e adicione um cabeçalho Retry-After. Este exemplo permite 10 solicitações por segundo por IP com um pequeno burst:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — rate limiting com mod_ratelimit / mod_evasive

O mod_ratelimit central do Apache limita largura de banda, não quantidade de solicitações; para limitar a taxa de solicitações, normalmente você usa mod_evasive (ou um WAF). Para fazer uma resposta limitada retornar 429 com Retry-After, defina-o explicitamente:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

Observe a ressalva: versões antigas do mod_evasive usam 403 como resposta padrão de bloqueio — exatamente o código que o Google diz não usar para rate limiting. Confirme que sua versão retorna 429 (ou coloque na frente uma CDN/WAF que faça isso).

Cloudflare / CDN — rate limiting para 429

Na camada da CDN, configure a ação da regra de rate limiting para responder 429 (muitas usam 403 ou um desafio por padrão). Nas regras de Rate Limiting da Cloudflare, o status da resposta para limites excedidos é configurável — escolha 429 e, quando houver suporte, anexe um Retry-After. O mesmo princípio vale para Fastly, Akamai ou um gateway de API: a ação quando o limite é excedido deve ser 429 Too Many Requests, não 403 Forbidden.

No cliente: tentar novamente após um 429 sem uma fórmula

Se você está escrevendo o cliente, a RFC dá uma única regra rígida e nenhum algoritmo alternativo: respeite um Retry-After válido quando ele estiver presente. Quando estiver ausente, a RFC 6585 não prescreve intervalo de nova tentativa, fórmula de backoff, distribuição de jitter, número de tentativas ou condição de sucesso — essas são políticas suas, não requisitos da especificação. Não apresente uma fórmula específica (inclusive a abaixo) como lei do HTTP; ela é um padrão limitado razoável, não a única opção correta.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

As partes importantes, independentemente dos números exatos, são: limitar o tempo total de espera e a quantidade de tentativas (não tente para sempre), usar jitter (para que uma frota de clientes não tente novamente em sincronia e dispare o limite de novo) e verificar idempotência antes de repetir algo que não seja seguro repetir (um POST não idempotente precisa de uma chave de deduplicação, não de uma nova tentativa cega).

Verifique se um bot é realmente o Googlebot antes de isentá-lo

Se você está criando exceções de rate limiting para mecanismos de busca, confirme a identidade com uma verificação de DNS reverso mais direto — user-agents falsificados de “Googlebot” são comuns, e a string de UA, sozinha, não prova nada.

macOS / Linux (tradução) «No macOS/Linux, faça uma consulta DNS reversa ao IP dos logs e depois resolva o hostname de volta; o nome deve terminar em googlebot.com ou google.com e retornar ao mesmo IP.»

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows (tradução) «No Windows, use nslookup para consultar o IP e depois o hostname do Googlebot.»

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Se a consulta reversa não terminar em um domínio do Google, ou se a consulta direta não corresponder ao IP original, não é Googlebot. Você também pode comparar com os intervalos de IP publicados pelo Google (googlebot.json).

Mitos comuns sobre 429 e SEO

Mito: “Qualquer 429 prejudica meu SEO ou causa desindexação.” Não. O Google projetou 429 como um sinal seguro e esperado de limitação. 429s de curto prazo ou intermitentes são normais e se corrigem sozinhos. O risco de desindexação só aparece com 429s sustentados nas mesmas URLs por vários dias — a orientação do próprio Google de 1–2 dias é a linha relevante.

Mito: “429 e 503 são basicamente intercambiáveis para SEO.” Para limitar a taxa de rastreamento, o Google os trata de forma semelhante. Mas eles significam coisas diferentes: 503 Service Unavailable é o sinal tradicional de “temporariamente indisponível/manutenção”, enquanto 429 comunica especificamente sobrecarga de taxa ou volume. Usar o código semanticamente correto importa para seu monitoramento, suas ferramentas e qualquer sistema posterior que leia códigos de status — mesmo que o Googlebot recue nos dois casos.

Mito: “Você pode usar 403 ou 404 para desacelerar o Googlebot, assim como 429.” A publicação de Illyes de fevereiro de 2023 refuta isso diretamente — era tão comum que o Google escreveu um artigo dedicado para pedir que parassem. 403/404 não têm efeito sobre a taxa de rastreamento e removem ativamente conteúdo do índice. 429 é o único código 4xx que a limita.

Mito: “Limitar bots de busca causa um corte permanente no crawl budget.” A redução é temporária e se recupera automaticamente quando o volume de erros diminui. Não há uma marca persistente no site depois que os erros param — a documentação do Google diz que a taxa “will automatically start increasing again.” (tradução) «começará a aumentar automaticamente».

Mito: “Se o Googlebot receber 429, ele desiste daquela URL para sempre.” O Google tenta novamente mais tarde. A preocupação são 429s sustentados por vários dias em cada URL — não um limite ocasional, que o Googlebot simplesmente respeita e supera.

Perguntas frequentes

Um erro 429 prejudica meu SEO? Não por si só. 429s de curto prazo ou intermitentes apenas desaceleram temporariamente o Googlebot e se corrigem sozinhos. O risco só aparece quando as mesmas URLs retornam 429 por vários dias.

Por quanto tempo posso retornar 429 antes de o Google desindexar minhas páginas? A documentação do Google diz para limitar a resposta a “a couple of hours, or 1–2 days.” (tradução) «algumas horas ou 1–2 dias». Depois disso, “the URL may be dropped from Google’s index.” (tradução) «a URL pode ser removida do índice do Google». Trate 1–2 dias como teto rígido, não como meta.

Qual é a diferença entre 429 e 503 para SEO? O Google reduz o rastreamento de forma semelhante nos dois. Mas 503 significa “temporariamente indisponível/manutenção”, enquanto 429 significa especificamente “você está enviando solicitações demais”. Use o código semanticamente correto para que seu monitoramento e suas ferramentas o interpretem corretamente.

Devo bloquear o Googlebot com 429 se quiser que ele rastreie menos permanentemente? Não — 429 é um sinal de curto prazo, não uma configuração permanente. Para uma redução duradoura, o Google diz para enviar uma solicitação especial sobre a taxa de rastreamento alta. Para manter bots fora de uma área, use robots.txt; para remover uma página do índice, use noindex.

O Bingbot respeita 429 da mesma forma que o Googlebot? O Bingbot também recua diante de sinais de sobrecarga como 429/500/503. Além disso, o Bing oferece controles proativos que o Google não oferece — a diretiva crawl-delay do robots.txt e a grade de solicitações por segundo do Crawl Control no Bing Webmaster Tools.

O que é o cabeçalho Retry-After e preciso dele? Retry-After informa ao cliente quanto tempo esperar antes de tentar novamente (um número de segundos ou uma data HTTP). Ele não é estritamente obrigatório, mas é uma prática recomendada e dá aos rastreadores um sinal concreto de recuo.

O Google retomará o rastreamento normal depois que eu parar de retornar 429s? Sim, automaticamente. Quando o volume de erros cai, “the crawl rate will automatically start increasing again.” (tradução) «a taxa de rastreamento começa a aumentar novamente». Não é necessário solicitar de novo e não fica uma penalidade persistente.

Ferramentas de WAF ou CDN podem aplicar 429 ao Googlebot por engano? Com muita frequência. Regras agressivas de firewall, limites padrão de CDN/hospedagem e ferramentas de gerenciamento de bots podem classificar Googlebot ou Bingbot como tráfego abusivo. Verifique a identidade do rastreador (DNS reverso mais direto) antes de criar exceções e afrouxe limites que capturem mecanismos de busca reais.

429 é um erro de cliente ou de servidor? Tecnicamente, é um erro de cliente 4xx na especificação HTTP. Mas o Google o trata como erro de servidor para fins de rastreamento — é o único 4xx agrupado com os 5xx.

O que meu cliente deve fazer se receber 429 sem cabeçalho Retry-After? Não existe fórmula imposta pelo HTTP — a especificação deixa isso para a política. Um padrão limitado razoável: backoff exponencial com jitter, limite rígido do tempo total de espera e da quantidade de tentativas para não tentar indefinidamente, e verificação de idempotência antes de repetir uma solicitação que não seja segura para enviar duas vezes. Veja a aba Scripts para uma versão em pseudocódigo.

O que devo fazer com um 429?

Problemas comuns de 429

O Googlebot recebe 429, mas visitantes normais não

Sintoma: relatórios de rastreamento mostram 429, enquanto verificações no navegador retornam 200. Causa provável: gerenciamento de bots, regra de UA ou rate limiting baseado em IP. Correção: correlacione eventos do WAF com IPs de rastreadores verificados e restrinja ou corrija a regra responsável; não coloque um user-agent em allowlist sozinho.

A taxa de rastreamento de todo o hostname cai

Sintoma: o rastreamento fica mais lento além das URLs que retornaram 429. Causa provável: o Google aplica o sinal de sobrecarga em todo o hostname. Correção: interrompa 429s não intencionais, restaure respostas de sucesso estáveis e deixe a taxa de rastreamento se recuperar automaticamente.

As respostas 429 continuam depois do incidente

Sintoma: o servidor está saudável, mas as URLs continuam retornando 429. Causa provável: um cache de CDN, regra de borda ou estado do limitador sobreviveu ao evento. Correção: desative ou expire a regra temporária, elimine uma resposta armazenada incorretamente e verifique caminhos e regiões representativos.

Retry-After está ausente ou inutilizável

Sintoma: os clientes sabem que foram limitados, mas não quando tentar novamente. Causa provável: a resposta foi gerada por uma regra de segurança genérica. Correção: faça a camada emissora enviar um atraso válido ou uma data HTTP e teste o cabeçalho bruto.

Prompt: audite uma regra de rate limit

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

Prompt: diagnostique 429s inexplicados

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

Ferramentas para investigar 429s

• Bulk HTTP Status Code Checker: teste um conjunto representativo de URLs e exporte quais caminhos retornam 429 no momento.
• HTTP Header Checker: inspecione Retry-After, fingerprints de CDN e saltos de redirecionamento na resposta limitada.
• Googlebot Verifier: valide evidências de IP antes de criar uma exceção para rastreador.
• Log File Analyzer: segmente o desperdício de códigos de status por bot e seção mantendo os logs enviados no navegador.
• Search Console Crawl Stats: compare o momento dos 429s com mudanças nas solicitações de rastreamento e no comportamento de resposta do host.

Valide uma configuração de 429

Teste do contrato de resposta

Teste a executar: acione o limite com segurança em um ambiente controlado e inspecione a resposta bruta. Resultado esperado: 429 com Retry-After válido e sem redirecionamento ou status de sucesso acidental. Interpretação da falha: a camada errada ou o template de erro é dono da resposta. Janela de monitoramento: imediata. Gatilho de rollback: solicitações normais são limitadas ou o teste desestabiliza o serviço.

Teste de escopo

Teste a executar: exercite um cliente intencionalmente limitado junto com usuários normais e tráfego de rastreador verificado em classes representativas de URL. Resultado esperado: somente o tráfego definido ultrapassa o limite. Interpretação da falha: a chave ou o escopo da regra de rate limiting são amplos demais. Janela de monitoramento: durante o teste controlado e a propagação na borda. Gatilho de rollback: rotas, usuários ou hosts não relacionados recebem 429.

Teste de recuperação

Teste a executar: pare o gatilho, espere o intervalo configurado para nova tentativa e repita as solicitações. Resultado esperado: respostas normais estáveis voltam sem solução manual por URL. Interpretação da falha: 429s armazenados em cache ou estado do limitador persistem. Janela de monitoramento: o intervalo configurado mais a propagação da implantação. Gatilho de rollback: o hostname continua limitado depois que a carga subjacente desaparece.

Teste de armazenamento em cache

Teste a executar: coloque um cache ou borda de CDN diante da rota limitada, acione um 429 e solicite a mesma URL novamente depois que a condição subjacente desaparecer. Resultado esperado: a segunda solicitação é avaliada novamente — nenhum 429 armazenado ou reproduzido é servido pela borda. Interpretação da falha: um intermediário está armazenando uma resposta que a RFC 6585 diz não poder ser armazenada; verifique cabeçalhos de controle de cache e configuração da regra da borda, não a origem. Janela de monitoramento: imediata, em um conjunto representativo de nós/POPs. Gatilho de rollback: qualquer 429 em cache é servido depois que a origem se recupera.

Teste da política de novas tentativas do cliente

Teste a executar: envie um cliente contra um 429 com e sem um cabeçalho Retry-After válido. Resultado esperado: com o cabeçalho, o cliente espera o intervalo especificado; sem ele, aplica uma política limitada de backoff com jitter, respeita uma quantidade máxima de tentativas e verifica idempotência antes de repetir uma solicitação não idempotente. Interpretação da falha: um cliente que tenta imediatamente, tenta sem limite ou repete cegamente uma solicitação não idempotente tem uma política de retry quebrada, não um problema de conformidade HTTP. Janela de monitoramento: durante toda a sequência limitada de tentativas. Gatilho de rollback: o cliente dispara novamente o mesmo limite por novas tentativas imediatas ou ilimitadas.

Recursos que valem seu tempo

Meus textos relacionados

• Códigos de status HTTP e seu impacto em SEO — meu guia completo de como cada código de status afeta SEO, incluindo onde 429 se encaixa.
• Guia para iniciantes de SEO técnico — onde controles de rastreamento e códigos de status entram no quadro maior.
• A história do bloqueio de 2 páginas bem posicionadas com Robots.txt — meu experimento de primeira parte sobre o que acontece quando você corta o acesso dos rastreadores.

Minhas apresentações

• How Search Works (SlideShare) — minha explicação de rastreamento, renderização, indexação e ranqueamento, incluindo como os servidores sinalizam aos rastreadores que devem diminuir o ritmo. (Vale minha ressalva habitual: “Este é meu entendimento dos sistemas… não será 100% completo ou preciso”.)

Da indústria

• Não use 403s ou 404s para limitação de taxa (Google Search Central, Gary Illyes) — a declaração canônica de que 429 é a exceção.
• Reduza a taxa de rastreamento do Google (Google) — a janela de 1–2 dias, a limitação em todo o hostname e a recuperação automática.
• Google alerta contra usar códigos 403 ou 404 para limitar a taxa do Googlebot (Search Engine Land) — cobertura da publicação de Illyes pela imprensa especializada.
• Google diz para parar de usar 403s ou 404s para reduzir a taxa do Googlebot (Search Engine Roundtable) — resumo de Barry Schwartz apresentando 429 como “a única exceção”.
• Google: não use respostas de erro 403/404 para limitar o Googlebot (Search Engine Journal) — uma terceira análise independente da mesma orientação.
• MDN — 429 Muitas solicitações — definição do HTTP e referência de Retry-After.
• Orientação do Bingbot — orientação atual do Bing para a diretiva crawl-delay.

Teste seus conhecimentos: 429 Too Many Requests

Cinco perguntas rápidas sobre como 429 funciona e como o Google o trata. Escolha uma resposta para cada uma e depois confira.

Registro de alterações