Idiomas

Redirecionamento 302

O que é um redirecionamento temporário 302, por que o Google o chama de sinal “fraco” para processamento do destino (não o beco sem saída de equity zero do folclore de SEO), os casos legítimos que o Google realmente recomenda e o único erro que custa rankings.

Publicado pela primeira vez: 2 de jul. de 2026 · Última atualização: 6 de ago. de 2026 · Avançado
Idiomas
AIEscrito porAI v2
1 sinal de evidência nesta página

Um redirecionamento 302 (status HTTP 302, “Found” _(tradução)_ «Encontrado») é temporário: encaminha usuários para uma nova URL enquanto sinaliza que a URL original deve continuar nos resultados de busca. A nuance que a maioria dos guias erra: a infraestrutura de rastreamento do Google chama 302 de sinal fraco de que o destino deve ser processado, em contraste com o sinal forte enviado por 301 — mas isso é separado do pipeline de indexação da Busca, que diz não tratar um redirecionamento temporário como sinal de que o destino deve ser principal (fraco não é zero e processado não é principal). O Google (Mueller, Illyes) disse que 302 ainda transfere sinais de links e, se permanecer ativo por tempo suficiente, pode começar a ser tratado como 301 — um padrão observado por profissionais sem prazo publicado. É a escolha correta para situações genuinamente temporárias — o Google recomenda explicitamente 302 em vez de 301 para testes A/B, além de roteamento geográfico/de dispositivo e páginas de manutenção. O único erro real é usar 302 em uma mudança permanente, o que pode deixar a URL antiga ranqueando em vez da nova por um período imprevisível.

TL;DR — Um 302 (“Found”) é um redirecionamento temporário. A formulação precisa do Google tem duas etapas, não uma: a infraestrutura de rastreamento chama-o de sinal fraco de que o destino do redirecionamento deve ser processado, em contraste com o sinal forte de um 301 — e, separadamente, o pipeline de indexação da Busca diz que não trata um redirecionamento temporário como sinal de que o destino deve ser principal (o destino ainda pode ser indexado por meio de outros sinais). Dois mecanismos são constantemente confundidos: a transferência de sinais de links/PageRank (Mueller e Illyes disseram que ela não é zero em um 302, embora isso seja uma declaração pública deles, não uma regra universal formalmente publicada) e a preferência de canonicalização/indexação (que é o que realmente difere — um 302 diz ao Google para manter a URL de origem indexada). Deixado no lugar por tempo suficiente, um 302 pode virar — um padrão observado por profissionais, não um mecanismo documentado, sem prazo publicado. O Google recomenda 302 em vez de 301 para testes A/B. O único erro real é usar 302 para uma mudança permanente; nunca construa o destino do redirecionamento a partir de entrada de usuário não verificada.

”Moved Temporarily” → “Found” — uma história rápida

O 302 nasceu ambíguo. No HTTP/1.0, ele se chamava “Moved Temporarily”, e a especificação dizia que os clientes deveriam reutilizar o método da solicitação original ao segui-lo. Na prática, os navegadores não faziam isso — muitos mudavam silenciosamente um POST para GET no redirecionamento, contrariando a especificação. O HTTP/1.1 reconheceu a realidade ao renomear o 302 para “Found” e adicionar duas alternativas inequívocas: 303 (See Other), que sempre muda para GET, e 307 (Temporary Redirect), que nunca muda o método. A especificação atual, RFC 9110 (2022), ainda observa que os clientes podem mudar POST para GET em um 302 — exatamente por isso existe 307 para os casos em que não podem mudar. Para redirecionamentos de páginas baseados em GET (o caso de uso de SEO), 302 e 307 se comportam do mesmo modo para os mecanismos de busca; a distinção de preservação do método só importa em envios de formulário e chamadas de API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: IETF: RFC 9110 §15.4.3 — 302 Found

Para fins de busca, o Google agrupa 302 (found), 303 (see other) e 307 (temporary redirect) como “Temporary”, em oposição a 301 e 308, que são “Permanent”.

A decisão compacta, se você estiver escolhendo entre eles:

  • 302 — o cliente que o segue pode mudar POST para GET (RFC 9110). Tudo bem para um redirecionamento de página simples baseado em GET; evite-o se não puder tolerar a mudança de método.
  • 307 — nunca muda o método nem reenvia uma solicitação diferente. Use-o quando um envio de formulário ou uma chamada de API precisar ser reproduzido exatamente como foi enviado.
  • 303 — aponta deliberadamente para um recurso diferente e não equivalente, normalmente buscado com GET/HEAD — o padrão clássico de “redirecionar depois de um POST para uma página de confirmação”, não um substituto equivalente da solicitação original.
  • Cache — um 302 não é armazenável heuristicamente apenas por causa do código de status (RFC 9111); ele só é armazenado/reutilizado se você definir diretivas explícitas de frescor ou cache. Não presuma que uma CDN ou um navegador tratará um 302 sem cabeçalhos como armazenável por padrão.

Sinal fraco versus sinal forte — as palavras exatas do Google

Ignore o folclore e leia a linguagem real do Google. Na documentação da infraestrutura de rastreamento, o Google diz que um 302 é um sinal fraco:

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (tradução) «Por padrão, os rastreadores do Google seguem o redirecionamento, e os sistemas do Google usam o redirecionamento como um sinal fraco de que o destino do redirecionamento deve ser processado.»

Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

A linha do 301 na mesma tabela é idêntica, exceto por uma palavra — strong:

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (tradução) «O Google segue o redirecionamento, e os sistemas do Google usam o redirecionamento como um sinal forte de que o destino do redirecionamento deve ser processado.»

Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

“Fraco” não significa “zero” — mas também vale ser preciso sobre o que é fraco. São dois sistemas diferentes do Google falando sobre duas etapas diferentes, não um único contínuo:

  • Infraestrutura de rastreamento (a citação do “sinal fraco” acima) trata de o destino do redirecionamento ser processado — em essência, se o rastreador do Google se dá ao trabalho de buscar e examinar o destino.
  • Pipeline de indexação da Busca é uma etapa posterior e separada e declara sua própria regra diretamente: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (tradução) «O Googlebot segue o redirecionamento, mas o pipeline de indexação não usa o redirecionamento como sinal de que o destino deve ser principal. A página de destino ainda pode ser indexada se outros sinais de canonicalização estiverem presentes.» Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: Google: Redirects and Google Search Google: Website testing

Leia as duas coisas juntas: um 302 dá ao Google um pequeno empurrão para olhar o destino (rastreamento), mas o pipeline de indexação da Busca não trata esse mesmo redirecionamento como um voto para tornar o destino principal (indexação). O destino ainda pode acabar indexado e principal — apenas porque outros sinais fizeram esse trabalho, não pelo 302 em si. Não reduza isso a “um 302 é um voto fraco para o destino ser principal” — não é isso que nenhuma das duas documentações diz; elas descrevem escopos diferentes.

Dois mecanismos, não um

É aqui que a maior parte do conteúdo concorrente mistura as coisas; portanto, mantenha-as separadas:

  1. A transferência de sinais de links/PageRank não é zero em um 302. Gary Illyes disse em 2016 que o Google não aplica mais diluição de PageRank entre redirecionamentos 301, 302 ou outros 30x (aposentando o velho folclore de “perda de ~15% por salto”), e Mueller destacou o mesmo ponto especificamente sobre 302: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (tradução) «funcionam da mesma forma que redirecionamentos normais… Não é que eles não passem nenhum PageRank ou algo assim.» Trate isso como a declaração pública do Google sobre a questão, não como uma garantia universal formalmente publicada — a documentação primária atual não especifica uma regra exata de transferência de sinais de links para todo tipo de redirecionamento em toda situação.
  2. A preferência de canonicalização/indexação é o mecanismo que realmente difere. Um 301 é um sinal forte para indexar o destino; um 302 é fraco, então o padrão do Google é continuar indexando a origem.

“Um 302 passa PageRank?” e “um 302 muda qual URL ranqueia?” são duas perguntas diferentes. A resposta à primeira é sim; à segunda é “não por padrão”. Confundi-las é como nasceu o mito de “302 = zero equity”.

Relacionado a isso: quando você redireciona uma URL, o Google acompanha as duas pontas. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (tradução) «O Google acompanha tanto a origem do redirecionamento (a URL antiga) quanto o destino (a nova URL). Uma das URLs será a preferida; qual delas depende de sinais como o fato de o redirecionamento ser temporário ou permanente. A outra URL se torna um nome alternativo da URL preferida.» Em um 302, a origem permanece preferida — por enquanto. Evidence for this claim A 302 expresses temporary intent, but it does not guarantee that the source URL will always remain Google's selected canonical or that the target cannot index through other signals. Scope: redirect crawling, indexing, and canonicalization Confidence: high · Verified: Redirects and Google Search

O que acontece se um 302 permanecer ativo por tempo demais — a “virada”

Esta é a parte que surpreende as pessoas: um redirecionamento temporário que nunca é removido pode deixar de ser tratado como temporário. Mueller: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (tradução) «se você mantém redirecionamentos 302 por muito tempo, nós os tratamos exatamente como redirecionamentos 301.»

Por que isso acontece? Esta é minha própria explicação de trabalho, baseada no meu guia de canonicalização da Ahrefs — um modelo mental de profissional construído a partir de comportamento observado, não um mecanismo publicado formalmente pelo Google — pense nisso como uma balança inclinando. Redirecionamentos permanentes enviam sinais para frente, para a nova URL; redirecionamentos temporários enviam sinais para trás, para a URL original. Mas:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (tradução) «Se um redirecionamento temporário for deixado no lugar por tempo suficiente ou a URL para a qual ele aponta já existir, ele pode ser tratado como um redirecionamento permanente e enviar os sinais para frente. É preciso haver sinais suficientes para virar a balança que vimos antes com os sinais de canonicalização. À medida que os links se acumulam, os links internos mudam, as URLs do sitemap são atualizadas etc., mais sinais apontam para a nova URL do que para a antiga, e a virada acontece.»

A ressalva: ninguém sabe quanto tempo isso leva. Como escrevi no meu guia de redirecionamentos, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (tradução) «Ninguém sabe por quanto tempo um redirecionamento 302 precisa existir antes de o Google começar a tratá-lo como um redirecionamento 301. Normalmente, são algumas semanas a alguns meses, mas pode levar dias, semanas ou meses.» E o Google pode agir antes se achar que você cometeu um erro: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (tradução) «Isso só não acontece se o Google achar que você usou um redirecionamento 302 por engano em uma mudança permanente. Nesse caso, ele trata o redirecionamento como um 301… Em algumas circunstâncias, o Google parece até tratar 302 como 301 desde o começo.» Não cite uma quantidade específica de dias para isso — não existe uma publicada, e qualquer número que você veja (incluindo os “2 days” que circulam no folclore do Bing) não foi confirmado pelo Google.

Como o Bing trata um 302 — ele observa o comportamento, não apenas o cabeçalho

O Bing chega ao mesmo resultado por um caminho um pouco diferente e o afirma explicitamente. Em seu explicador tradicional sobre redirecionamentos, o Bing descreve observar o padrão observado de um redirecionamento em rastreamentos repetidos, em vez de confiar apenas no código de status: redirecionamentos que continuam mudando de destino são tratados mais como 302 mesmo quando estão identificados como 301, e redirecionamentos que sempre apontam para o mesmo lugar são tratados mais como 301 mesmo quando estão identificados como 302 — o sistema do Bing começa a “think about them more like 301s as we continue to crawl them again and again.” (tradução) «pensar neles mais como 301 à medida que continuamos a rastreá-los repetidamente.» É a mesma convergência descrita pelo Google, alcançada de forma independente: com comportamento consistente suficiente ao longo do tempo, os dois mecanismos confiam no que um redirecionamento faz mais do que no que seu cabeçalho afirma.

A orientação mais antiga do Bing também enfatizava mais “usar 302 com moderação” do que o Google faz hoje, alertando que um 302 usado incorretamente pode deixar valor preso nas URLs originais. A conclusão prática é idêntica à do Google: combine o tipo de redirecionamento com sua intenção real.

Quando um 302 é a escolha certa

O Google não apenas tolera 302 — para um caso de uso ele os recomenda. Da orientação sobre testes A/B:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (tradução) «Se você está executando um teste que redireciona usuários da URL original para uma URL de variação, use um redirecionamento 302 (temporário), não um redirecionamento 301 (permanente). Isso informa aos mecanismos de busca que o redirecionamento é temporário — ele só ficará no lugar enquanto você executar o experimento — e que eles devem manter a URL original no índice em vez de substituí-la pelo destino do redirecionamento (a página de teste). Redirecionamentos baseados em JavaScript também são aceitáveis.»

Os casos de uso legítimos (todos genuinamente temporários):

  • Teste A/B — recomendação explícita do Google, acima. Mas não o prolongue: o Google alerta que “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (tradução) «se descobrirmos um site executando um experimento por tempo desnecessariamente longo, poderemos interpretar isso como uma tentativa de enganar os mecanismos de busca e agir de acordo». Execute-o pelo tempo necessário para obter significância e depois remova-o.
  • Roteamento geográfico, por dispositivo e por idioma — quando o destino “certo” depende do visitante e nenhuma URL deve substituir permanentemente a origem. Isso exige mais do que escolher um código de status: confirme para onde o próprio Googlebot é roteado (normalmente ele não carrega os sinais reais de localização/dispositivo de um visitante; verifique o que sua regra serve a ele), se o roteamento depende de cookies ou cabeçalhos que um rastreador não enviará, se as chaves de cache e o cabeçalho Vary separam corretamente as variantes (para que o cache não sirva a página de um país para outro), se um visitante com leitor de tela ou sem JavaScript ainda consegue acessar o conteúdo e se o visitante pode substituir o roteamento automático em vez de ficar preso em um loop de redirecionamento. Combine-o com hreflang correto nas versões localizadas — o redirecionamento e o hreflang devem concordar, não brigar.
  • Páginas temporárias de manutenção / serviço indisponível — o próprio exemplo do Google: “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (tradução) «se um serviço oferecido pelo seu site estiver temporariamente indisponível, você pode configurar um redirecionamento temporário para enviar usuários a uma página que explique o que está acontecendo, sem comprometer a URL original nos resultados de busca.» Pense em qual das duas situações você realmente tem. Se a própria URL simplesmente não pode ser servida agora (o backend caiu, você está no meio de um deploy), um 503 Service Unavailable com cabeçalho Retry-After na mesma URL geralmente é uma resposta mais precisa — ela diz “temporariamente não é possível atender a esta solicitação, tente novamente mais tarde” sem redirecionar para outro lugar. Use 302 quando estiver roteando deliberadamente visitantes para uma URL explicativa diferente e realmente útil (uma página de status ou uma página “voltaremos em breve” com mais detalhes), em vez de apenas marcar a original como indisponível.
  • Promoções com prazo — envie visitantes para uma página de campanha durante sua vigência e depois reverta.
  • Balanceamento de carga / failover — roteie o tráfego para outro lugar quando uma origem ou data center estiver temporariamente indisponível.

Veja a aba Exemplos para estes casos anotados lado a lado e a aba Listas de verificação para uma verificação prévia.

O único erro real

Usar um 302 quando você quer dizer uma mudança permanente. Você está dizendo ao Google para manter a URL antiga indexada, então a nova página que você quer que ranqueie pode não assumir o lugar por um período indefinido e imprevisível — um custo real de visibilidade perdida, não um risco teórico. Se uma página acabou de vez, use um 301 (ou 308). Erros relacionados: misturar 301 e 302 de forma inconsistente dentro de uma cadeia de redirecionamentos e — o modo de falha de qualquer redirecionamento — apontar acidentalmente duas URLs uma para a outra, criando um loop.

Implementando um 302

O cabeçalho é o que importa — linha de status 302 Found mais um Location. Exemplo do próprio Google em PHP:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess) — a flag R=302 é o que o torna temporário (um R=301 ou um R sem valor usaria o padrão permanente):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx — redirect emite um 302 (permanent emitiria um 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Qualquer que seja a stack (plugins de redirecionamento do WordPress, uma regra de CDN/edge ou um handler no nível da aplicação), a regra é a mesma: redirecionamentos no servidor são preferíveis, e você precisa escolher deliberadamente o código temporário — a maioria das ferramentas usa 301 por padrão, então 302 geralmente é uma configuração explícita.

Uma observação de segurança que vale para qualquer redirecionamento, não apenas 302: se o destino no seu cabeçalho Location for construído a partir de entrada controlada pelo usuário (por exemplo, um parâmetro de consulta ?next= ou ?returnUrl=), você tem os ingredientes para um open redirect — um invasor cria um link no seu domínio que na verdade envia visitantes para algum lugar malicioso. Não envie visitantes para qualquer URL que apareça em um parâmetro da solicitação; crie uma lista permitida dos destinos para os quais você realmente redirecionará (um conjunto fixo de caminhos ou origens conhecidos e seguros) e teste como sua lógica trata entradas codificadas e relativas ao esquema (//evil.example, %2F%2Fevil.example e truques semelhantes) antes de confiar nela em produção. Confira a sintaxe exata do snippet de cada plataforma em relação à versão atual antes de publicar — os exemplos acima são ilustrativos, não substituem testes no seu próprio servidor/CDN.

Para o equivalente de mudança permanente e a comparação completa, consulte os artigos irmãos sobre redirecionamento 301, 301 vs. 302 e 302 vs. 307 neste cluster.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.