Redirecionamento 302 vs. 307

TL;DR — Um 302 e um 307 são redirecionamentos “temporary” (tradução) temporários — eles enviam visitantes para outro lugar por enquanto, mantendo a URL original como a que conta. O Google os processa da mesma forma, então não há diferença relevante de SEO. A única diferença técnica real é que um 307 precisa manter o mesmo tipo de solicitação (assim, o envio de um formulário continua sendo um envio, em vez de virar uma simples busca de página), enquanto um 302 historicamente permitia essa troca. Use um 302 comum para redirecionamentos normais; use 307 quando estiver redirecionando algo como um formulário ou uma API que envia dados — e não presuma que usar 307 em tudo seja automaticamente gratuito.

O que um 302 e um 307 realmente significam

Tanto 302 quanto 307 são redirecionamentos: você solicita uma URL e chega a outra. O número é o código de status HTTP que o servidor envia e carrega uma mensagem para navegadores e mecanismos de busca.

• 302 — “Found” (temporário). É o redirecionamento temporário original. Ele diz: “go here for now, but the old address is still the real one — I’ll be back” (tradução) “vá para cá por enquanto, mas o endereço antigo ainda é o real — eu voltarei”.
• 307 — “Temporary Redirect” (redirecionamento temporário). A mensagem é a mesma — temporário, a URL antiga ainda conta —, mas com uma promessa adicional: o navegador precisa repetir exatamente a sua solicitação, inclusive se ela foi um GET (apenas buscar uma página) ou um POST (enviar dados, como em um formulário).

Eles são irmãos. Uma forma útil de dizer isso é: um 307 é um 302 que também garante que o navegador não vai trocar silenciosamente o envio do seu formulário por uma simples solicitação de página.

Isso importa para SEO?

Não da forma que preocupa a maioria dos proprietários de sites. A documentação do Google lista 307 como “equivalent to 302” (tradução) “equivalente a 302” na maneira como seus rastreadores processam e seguem o redirecionamento. Ambos são sinais de “temporário”, então, por padrão, o Google não trata o destino como a página canônica apenas porque você redirecionou para ele. A documentação não explica se 302 e 307 passam quantidades idênticas ou diferentes de valor de link — o que ela afirma com clareza é que nenhum dos dois códigos entrega ao destino os sinais da origem da forma como um redirecionamento permanente faz. Se alguém disser que 307 “passa menos valor” que 302, peça a fonte: o Google não publicou uma afirmação assim.

Então, quando uso cada um?

• Use um 302 comum para redirecionamentos temporários do dia a dia — uma página de promoção sazonal, um teste A/B, uma página de manutenção ou o envio de alguém para a home específica de um país.
• Use um 307 quando aquilo que está sendo redirecionado envia dados — um envio de formulário, uma chamada de API ou um POST de login ou checkout. A promessa do 307 (manter o método e os dados exatamente como estavam) realmente importa, porque um 302 comum pode permitir que um navegador antigo transforme POST em GET e descarte os dados.

Uma coisa que costuma confundir

Às vezes você abre as ferramentas de desenvolvimento do navegador e vê um 307 que nunca configurou. Normalmente, isso não é um redirecionamento real do servidor — é o navegador atualizando sozinho um link http:// para https:// (um recurso de segurança chamado HSTS) e mostrando-o para você como 307. Falamos mais sobre isso na aba Avançado.

Quer a visão completa — a história da especificação, exatamente o que o Google e Mueller dizem, o “phantom 307” (tradução) “307 fantasma” do HSTS e os padrões de frameworks que surpreendem desenvolvedores? Mude para a aba Avançado.

TL;DR — 302 e 307 são redirecionamentos temporários, e o Google os processa da mesma forma — a documentação diz que 307 é “equivalent to 302” (tradução) “equivalente a 302”, e Mueller disse “for SEO, it doesn’t really matter” (tradução) “para SEO, não importa muito” entre os pares temporário e permanente; nenhum dos dois códigos é um sinal de que o destino deve se tornar canônico, e o Google não publicou uma divisão declarada de PageRank/valor de link entre eles. A diferença real é a preservação do método: um 307 seguido automaticamente precisa manter o mesmo método (um POST continua sendo POST), enquanto um 302 permite que um cliente converta POST em GET — os bytes exatos do corpo, as credenciais e o comportamento entre origens ainda dependem do cliente, então verifique em vez de presumir. Prefira 307 quando perder o método quebrar algo — APIs, formulários e fluxos de POST/webhook/checkout/autenticação —, mas fique atento à repetição não idempotente (uma chamada redirecionada de pagamento ou pedido pode ser reenviada). Um 302 comum é adequado para redirecionamentos GET normais, inclusive a recomendação explícita do Google para testes A/B. Observe o “HSTS phantom 307” (tradução) “307 fantasma do HSTS” (um rótulo da interface do Chrome, não uma garantia do protocolo), as especificidades de frameworks (o Next.js documenta 303 para Server Actions e 307 em outros contextos — confira sua versão em vez de generalizar para outras plataformas) e o fato de que o Bing não tem orientação específica para 302 vs. 307. Minha ordem preferida para redirecionamentos temporários é 307 / 302 / 303 acima de meta/HTTP refresh — mas usar 307 por padrão não é gratuito, então verifique primeiro cabeçalhos de cache, suporte de clientes legados e salvaguardas de idempotência.

Ambos são temporários — esse é o ponto de partida

Antes de qualquer coisa: 302 e 307 estão na mesma categoria. O Google agrupa 302 (Found), 303 (See Other) e 307 (Temporary Redirect) como “temporary redirects” (tradução) “redirecionamentos temporários”, e seu comportamento para todos eles é o mesmo — “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (tradução) “O Googlebot segue o redirecionamento, mas o pipeline de indexação não usa o redirecionamento como um sinal de que o destino deve ser considerado principal.” Em termos simples, um redirecionamento temporário mantém a URL de origem como principal por padrão; ele não entrega ao destino os sinais da origem como faz um redirecionamento permanente (301/308).

Essa é exatamente a comparação com a camada permanente um nível acima: 301/308 formam o par permanente, 302/307 formam o par temporário, e a lógica de que “o código de número maior preserva o método” é idêntica nos dois pares.

A única diferença real: preservação do método e do corpo

Aqui está, em uma frase, a distinção que realmente importa: quando um cliente segue automaticamente um 307, a especificação HTTP atual (RFC 9110) exige que ele mantenha o mesmo método de solicitação; um 302 deixa o cliente livre para converter POST em GET. Essa é uma garantia da especificação sobre o método — não uma garantia geral sobre cada byte do corpo, credenciais ou comportamento entre origens, que ainda dependem do cliente específico que implementa o redirecionamento. Verifique esses pontos com uma solicitação real em vez de presumir que um 307 repete tudo de forma idêntica em todos os casos.

A razão dessa ambiguidade existir é uma história da especificação que vale contar, porque a maioria dos textos afirma o fato sem explicar por quê. Na era do HTTP/1.0, o texto da especificação do 302 dizia tecnicamente que os clientes não deveriam alterar o método da solicitação ao seguir o redirecionamento — mas os primeiros navegadores (Netscape e, depois, todos os demais) ignoraram isso e converteram silenciosamente métodos que não eram GET, sobretudo POST, em GET ao seguir um 302. Esse comportamento inconsistente, mas universal, virou o padrão de fato. O HTTP/1.1 (RFC 2616, 1999, depois incorporado à RFC 7231 e à atual RFC 9110) formalizou a divisão em dois códigos explícitos para acabar com a confusão:

• 303 (See Other) — busca o destino do redirecionamento com GET ou HEAD (não é simplesmente “always GET” (tradução) “sempre GET” — a RFC 9110 permite qualquer um dos dois métodos seguros), o comportamento pretendido para “POST, then redirect to a result page you can safely reload” (tradução) “POST e depois redirecionar para uma página de resultado que você pode recarregar com segurança”.
• 307 (Temporary Redirect) — o método é estritamente preservado em um seguimento automático, pela especificação; a RFC 9110 não obriga todo cliente a seguir o redirecionamento.

A MDN resume bem a consequência prática: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (tradução) “A diferença entre 307 e 302 é que 307 garante que o cliente não alterará o método e o corpo da solicitação quando a solicitação redirecionada for feita. Com 302, clientes antigos alteravam incorretamente o método para GET.” Portanto, o 307 não acrescentou tanto uma capacidade nova quanto removeu uma ambiguidade — é a versão garantida pela especificação do que um 302 bem comportado deveria fazer desde o começo. Os navegadores modernos são muito mais consistentes que o caos da era Netscape, mas o 307 remove a ambiguidade por especificação, não por convenção.

Comparação lado a lado:

Vale manter duas notas de precisão: a permissão da RFC para converter em um 302 menciona POST, não todo método — não generalize isso para “302 always breaks PUT/DELETE” (tradução) “302 sempre quebra PUT/DELETE” sem verificar seu cliente específico. E nenhum dos dois códigos é armazenável heuristicamente por padrão apenas por causa do status: a RFC 9111 não lista 302 ou 307 entre os códigos que podem ser armazenados heuristicamente pelo status sozinho — o cache ainda depende de cabeçalhos explícitos Cache-Control/Expires, não do código de redirecionamento escolhido.

A definição da Ahrefs também coincide com a parte da preservação do método: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (tradução) “Um redirecionamento 307 é igual a um redirecionamento 302, exceto por manter o método HTTP (POST, GET) da solicitação original ao executar o redirecionamento.”

O Google trata 302 e 307 de forma diferente para SEO?

Não — e o Google é especialmente explícito sobre isso. Este é um assunto consolidado e de baixa controvérsia, assim como 301 vs. 308.

Na documentação do Google sobre códigos de status HTTP, a linha do 302 diz que os rastreadores do Google seguem o redirecionamento e usam o redirecionamento como um sinal fraco de que o destino deve ser processado, e a linha do 307 diz, literalmente, “Equivalent to 302.” (tradução) “Equivalente a 302.” O Google acrescenta então a ressalva que vale igualmente para os pares 302/307 e 301/308: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (tradução) “Embora o Google trate esses códigos de status da mesma forma, lembre-se de que eles são semanticamente diferentes. Use o código de status apropriado para o redirecionamento para que outros clientes (por exemplo, leitores eletrônicos e outros mecanismos de busca) possam se beneficiar dele.”

Essa é a resposta sobre o processamento do rastreador. O Google trata os dois da mesma forma na maneira como o Googlebot busca e segue o redirecionamento, e apenas pede que você escolha o código semanticamente correto para que clientes que não sejam do Google se comportem bem. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Há uma nuance importante, porque ela é uma lacuna real em muita cobertura: a equivalência no processamento do rastreador é uma afirmação separada do resultado de indexação. A documentação do Google sobre redirecionamentos e Busca agrupa 302, 303 e 307 como “temporary redirects” (tradução) “redirecionamentos temporários” e afirma que “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (tradução) “o pipeline de indexação não usa o redirecionamento como um sinal de que o destino deve ser canônico.” Essa é uma garantia real e útil — mas não promete que sua URL de origem continuará ranqueando, nem que o destino jamais poderá ser indexado por outros sinais. Trate “302 e 307 são processados da mesma forma” e “nenhum dos dois é um sinal de canonicalização para o destino” como duas afirmações separadas, ambas verdadeiras — não como uma alegação de que os dois códigos passam PageRank ou valor de link idênticos, algo que a documentação do Google não afirma de nenhuma das duas formas.

John Mueller diz o mesmo com suas próprias palavras. No episódio Search Off the Record “Let’s talk redirects” (tradução) “Vamos falar sobre redirecionamentos”, Martin Splitt perguntou diretamente por que 307 e 308 existem ao lado de 301 e 302. Mueller respondeu: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (tradução) “Tive de pesquisar isso recentemente. E, normalmente, com 301 e 302, o que é encaminhado são solicitações GET.” … “And with 307, 308, it also forwards POST requests.” (tradução) “E, com 307 e 308, ele também encaminha solicitações POST.” Então veio a frase que resolve a questão de SEO: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (tradução) “Acho que, para SEO, não importa muito. É mais algo como: não sei… funciona para APIs ou não? E, normalmente, APIs não são algo que você precisa indexar diretamente na Busca.”

Observe o enquadramento: a razão inteira para escolher 307 em vez de 302 é uma questão de funcionalidade (“does it work for APIs?” (tradução) “funciona para APIs?”), não de ranking. Não existe uma fonte primária confiável que alegue uma vantagem de SEO em qualquer direção.

O Bing trata 302 e 307 de forma diferente?

Honestamente: o Bing não disse. A orientação pública de redirecionamentos dele (a publicação de 2011 “Managing redirects – 301s, 302s and canonicals” (tradução) “Gerenciando redirecionamentos — 301, 302 e canônicas” e a publicação de 2020 “Website Migration with Bing” (tradução) “Migração de site com o Bing”) trata apenas da divisão entre permanente e temporário de 301 vs. 302 e nunca menciona 307 ou 308 pelo nome. Ao contrário do tema 301 vs. 308 — em que Fabrice Canel deu uma declaração direta —, não encontrei uma declaração de representante do Bing especificamente sobre 302 vs. 307.

Então vou dizer de forma simples, em vez de presumir paridade: não existe uma declaração do Bing que diferencie especificamente 302 e 307. Existe um comportamento documentado do Bing que vale conhecer para a discussão de redirecionamentos temporários em geral — se o Bingbot vê o mesmo 302 vezes suficientes seguidas, começa a tratá-lo como 301 e consolida o destino —, mas o Bing não confirmou publicamente que esse comportamento se estenda a 307 repetido. Trate isso como uma lacuna genuína de documentação, não como um fato sobre 307.

Quando 307 é a escolha tecnicamente correta

Qualquer redirecionamento em que perder o método ou o corpo original quebraria alguma coisa:

• APIs e endpoints de webhook — um POST/PUT/DELETE que precisa chegar à nova URL com o método e o payload intactos.
• Envios de formulário (fluxos POST) — como disse Mueller: “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (tradução) “se você tem algum tipo de API que usa solicitações POST, ou eu quase diria, como uma configuração quebrada, um formulário em um domínio cujos resultados são encaminhados para outro, então você usaria 307, 308.”
• Handoffs de checkout, pagamento e login/autenticação por POST — qualquer lugar em que descartar o corpo faça a transação falhar silenciosamente.

Vale destacar uma questão de segurança: a garantia de preservação do método do 307 funciona nos dois sentidos. Se a solicitação original não era idempotente — uma cobrança, um pedido, qualquer coisa com efeito colateral —, um seguimento automático de 307 repete essa solicitação exata na nova URL. Normalmente é isso que você quer, mas também significa que uma nova tentativa do cliente ou uma cadeia de redirecionamentos pode reenviar uma chamada não idempotente mais de uma vez. Coloque controles de idempotência (uma chave de idempotência, uma verificação de envio duplicado) no endpoint que recebe a solicitação, em vez de presumir que o redirecionamento torna a repetição segura.

Uma das principais razões para desenvolvedores encontrarem 307 sem escolhê-lo: alguns frameworks e plataformas de edge adotam por padrão um código que preserva o método em solicitações que não são GET. O Next.js é o exemplo documentado mais claro — a função redirect() retorna 303 quando é chamada a partir de uma Server Action e 307 em outros contextos compatíveis, segundo a referência atual da API; portanto, confira a documentação da sua versão do Next.js em vez de presumir que um código se aplica a toda a plataforma. Outros frameworks, CDNs e balanceadores variam conforme o produto e a versão — verifique o status real que sua plataforma retorna, em vez de presumir que ele seja igual ao de uma plataforma parecida. Ver um 307 ou 303 inesperado muitas vezes é a plataforma fazendo algo sensível ao método de propósito, não uma configuração incorreta — mas confirme no seu ambiente específico.

Quando 302 é o padrão pragmático

Redirecionamentos temporários padrão em solicitações GET simples — não há método a preservar, então a garantia do 307 não traz benefício:

• Redirecionamentos geográficos/de idioma (com a ressalva habitual contra bloquear totalmente o conteúdo por região).
• Testes A/B e testes divididos — a própria orientação do Google para testes de sites diz explicitamente para usar 302, não 301, em variações de teste redirecionadas, precisamente porque o redirecionamento é temporário.
• Redirecionamentos de modo de manutenção / “volto em breve” — mas apenas quando existe um recurso real para enviar aos visitantes; se o site inteiro estiver indisponível, a própria orientação do Google aponta para 503 (serviço indisponível), não para qualquer redirecionamento. E, se o que está sendo redirecionado for uma solicitação não-GET — um checkout ou chamada de API que chega à página de manutenção —, um 307 repetirá essa solicitação na nova URL, o que não é automaticamente seguro quando a chamada tem efeitos colaterais; portanto, não use 307 por hábito sem verificar.
• Redirecionamentos mobile↔desktop (m-dot) — o exemplo do próprio Mueller em que 302 é especificamente o código correto: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (tradução) “um redirecionamento 302 seria o correto porque, na próxima vez que alguém acessar, você não sabe se essa pessoa quer a versão mobile ou a versão desktop.” O destino correto depende do visitante, então não é uma mudança permanente.

O “307 fantasma” do HSTS — um 307 que seu servidor nunca enviou

Esta seção merece existir porque trata de um assunto completamente diferente da escolha do código de redirecionamento, e confundir os dois causa problemas reais ao depurar cadeias de redirecionamento.

Se um site envia o cabeçalho HSTS (Strict-Transport-Security) por HTTPS, o navegador se lembra dele e, em qualquer tentativa posterior de acessar a versão http://, atualiza a solicitação para https:// por conta própria — o URI é reescrito antes de a solicitação sequer tocar na rede. As versões atuais do Chrome mostram essa atualização interna nas ferramentas de desenvolvimento como um 307, mas nada no servidor a emitiu, e o rótulo exato, a contagem de bytes ou a forma de exibição do cabeçalho dependem da versão do Chrome; isso não é uma exigência da especificação HTTP ou HSTS — não trate “307” como um rótulo garantido em todo navegador ou em toda versão futura. John Mueller explicou isso no site pessoal dele: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (tradução) “Depois de ver a URL HTTPS com o cabeçalho HSTS (por exemplo, com qualquer redirecionamento da versão HTTP), o Chrome agirá como se estivesse vendo um redirecionamento 307 na próxima vez que você tentar acessar a página HTTP.” E a explicação principal: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (tradução) “Seu servidor não está retornando um 307; o Chrome está apenas mostrando isso para explicar que está fazendo o redirecionamento por você.”

Já sinalizei a mesma coisa nos meus textos sobre códigos de status — há até um significado distinto de “307 HSTS Policy” (tradução) “política HSTS 307” (que força o cliente a usar HTTPS), separado de “307 Temporary Redirect” (tradução) “redirecionamento temporário 307”. A nuance de SEO é: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (tradução) “Quando servidores web exigem que os clientes usem apenas conexões HTTPS (política HSTS), o Google não verá o 307 porque ele fica armazenado no cache do navegador.” Portanto, se você encontrar um 307 na aba Network que nunca configurou, antes de procurar uma regra de redirecionamento incorreta, verifique se é apenas o HSTS fazendo uma atualização de HTTP para HTTPS.

Mitos comuns

• “307 não passa o mesmo valor de SEO que 302.” Não há suporte para isso — a própria documentação do Google diz que 307 é “Equivalent to 302” (tradução) “equivalente a 302” na forma como o redirecionamento é processado, e nenhum dos dois códigos é tratado como um sinal de que o destino deve ser canônico. Mas o Google não publicou uma fórmula exata de PageRank/valor de link para nenhum dos dois códigos; portanto, não afirme uma transferência precisa de valor igual (ou diferente) em nenhuma direção — a afirmação correta é que o Google os processa da mesma forma, não que tenha quantificado o valor transferido.
• “302 é a escolha mais segura/recomendada porque é mais claro como os mecanismos de busca o tratam.” Exagero. O tratamento do 307 pelo Google é igualmente documentado (“Equivalent to 302” (tradução) “equivalente a 302”) — não é um caso em que um código seja mais bem compreendido pelos mecanismos de busca. Se alguma coisa, o 307 oferece uma garantia funcional (preservação do método/corpo) que o 302 não oferece. (Alguns guias de terceiros dizem o contrário; veja a nota na aba de recursos.)
• “Um 307 na aba Network do meu navegador significa que o servidor configurou um redirecionamento errado.” Muitas vezes é falso — se o HSTS estiver ativo e você tiver carregado a versão HTTPS anteriormente, esse 307 é a própria atualização de HTTP para HTTPS do Chrome, não uma resposta do servidor.
• “302 sempre converte POST em GET, então nunca use 302 em um formulário.” Exagero para navegadores modernos. A conversão POST→GET foi um problema real e bem documentado em clientes antigos — é a razão de o 307 existir como opção garantida, não uma prova de que todo 302 atual descarta dados POST. 302 é ambíguo, não universalmente quebrado.
• “Troque todos os seus redirecionamentos temporários por 307 para melhorar o ranking.” Falso e desnecessário — não há ganho de ranking. O único motivo válido para preferir 307 é uma necessidade genuína de preservar método/corpo (ou uma preparação geral para o futuro).
• “303 e 307 são basicamente iguais.” Não — 303 muda deliberadamente o seguimento para GET (foi criado para padrões de POST seguido de redirecionamento a uma página de resultado), o oposto funcional da garantia de preservação do 307. É fácil confundi-los porque aparecem juntos.

Minha recomendação

Para redirecionamentos temporários, minha ordem preferida de implementação é 307 / 302 / 303, acima de meta refresh (0) e HTTP refresh (0). Observe que eu realmente coloco 307 acima de 302 — não porque ele ajude o SEO (não ajuda), mas porque, se você sempre usa o código que preserva o método, raramente precisa lembrar de trocar depois: um redirecionamento GET simples funciona bem como 307 e, no dia em que você redirecionar um formulário ou uma API, já estará coberto. Isso é um argumento de completude, não uma política sem custo — uma política genuína de usar 307 por padrão ainda precisa da mesma disciplina de controle de cache que qualquer redirecionamento, precisa funcionar com os clientes legados que você realmente suporta e precisa de salvaguardas de idempotência em qualquer destino que não seja uma simples busca GET. Mueller fez a mesma observação sobre completude: “if you always use them, then you’re always safe.” (tradução) “se você sempre os usar, estará sempre seguro.” Dito isso, um 302 simples é perfeitamente adequado e, para o caso específico de m-dot, 302 é tecnicamente a escolha mais correta.

Onde isso se encaixa

302 e 307 são dois dos códigos de redirecionamento 3xx temporários, e cada um tem seu próprio aprofundamento neste cluster, ao lado do par permanente (301, 308), do irmão 303 que sempre usa GET e das comparações entre irmãos — 301 vs. 308 na camada permanente (a mesma lógica de preservação do método, um nível acima) e 301 vs. 302, permanente contra temporário — além dos riscos operacionais, cadeias de redirecionamento e loops de redirecionamento. Para a família completa de respostas do servidor, veja o hub de códigos de status HTTP; o tipo de redirecionamento também é um dos sinais de canonicalização abordados em canonicalização.

Resumo de IA

Uma versão condensada do Avançado:

• Ambos são redirecionamentos temporários. 302 e 307 mantêm a URL de origem como canônica por padrão — nenhum entrega ao destino os sinais da origem da forma como um 301/308 permanente faz.
• O Google os processa da mesma forma. A documentação diz que 307 é “equivalent to 302” (tradução) “equivalente a 302”, e Mueller: “for SEO, it doesn’t really matter.” (tradução) “para SEO, não importa muito.” Mas isso é uma afirmação sobre o processamento do rastreador, não uma fórmula declarada de PageRank/valor de link — o Google não publicou uma para nenhum dos códigos, então não afirme uma transferência exata igual (ou diferente) e não presuma que “processado da mesma forma” garanta que a origem continuará ranqueando ou que o destino nunca será indexado por outros sinais.
• A única diferença real é a preservação do método. Um seguimento automático de 307 precisa manter o mesmo método (um POST continua sendo POST); um 302 permite que o cliente converta POST em GET. O 307 foi acrescentado no HTTP/1.1 (RFC 2616 → 7231 → 9110) especificamente para fechar essa ambiguidade — mas os bytes exatos do corpo, as credenciais e o comportamento entre origens ainda dependem do cliente, e a permissão de conversão da RFC menciona especificamente POST, não todo método que não é GET.
• Use 307 para APIs, formulários e fluxos de POST/webhook/checkout/autenticação — mas observe a repetição não idempotente (uma cobrança ou pedido pode ser reenviado no redirecionamento; adicione salvaguardas de idempotência). Use 302 para redirecionamentos GET simples — geográficos/de idioma, a recomendação explícita do Google para testes A/B e, no exemplo de Mueller, mobile↔desktop. Redirecionamentos de manutenção dependem da existência de um recurso real para enviar aos visitantes; uma indisponibilidade total costuma ser melhor atendida por 503.
• Os padrões dos frameworks dependem da versão e do contexto, não são universais. O Next.js documenta 303 para Server Actions e 307 em outros contextos — confira sua versão em vez de presumir o comportamento de outros frameworks ou CDNs.
• “HSTS phantom 307” (tradução) “307 fantasma do HSTS”: um 307 na aba Network do navegador muitas vezes é o Chrome atualizando HTTP→HTTPS por conta própria (HSTS), não uma resposta do servidor — e o rótulo exato “307” é uma escolha de interface específica da versão do Chrome, não uma exigência da especificação HTTP/HSTS. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (tradução) “Seu servidor não está retornando um 307; o Chrome está apenas mostrando isso para você.”
• Bing: não existe orientação específica para 302 vs. 307 — não presuma paridade e não presuma que o comportamento de “302 repetido → tratado como 301” também se aplique a 307.
• Nenhum dos dois códigos é armazenável por padrão apenas pelo status (RFC 9111) — o cache ainda depende de cabeçalhos explícitos Cache-Control/Expires.
• A ordem preferida de Patrick para redirecionamentos temporários é 307 / 302 / 303 acima de meta/HTTP refresh — embora usar 307 em tudo não seja automaticamente gratuito; verifique primeiro cabeçalhos de cache, suporte de clientes legados e salvaguardas de idempotência.

Documentação oficial

Documentação e especificações de fontes primárias.

Google

• Códigos de status HTTP, erros de rede e DNS e o Google Search — a linha do 302 com “weak signal” (tradução) “sinal fraco”, a linha do 307 “Equivalent to 302” (tradução) “Equivalente a 302” e a ressalva de que são semanticamente diferentes — use o código apropriado.
• Redirecionamentos e o Google Search — agrupa 302, 303 e 307 como “temporary redirects” (tradução) “redirecionamentos temporários” e explica como cada um afeta a canonicalização.
• Search Off the Record, episódio 51 — “Let’s talk redirects” (John Mueller + Martin Splitt) — a discussão registrada sobre por que 307/308 existem e quando importam.
• John Mueller — Guia de mecanismo de busca para 301, 302, 307 e outros redirecionamentos — comportamento de indexação do 302 (a URL de origem “R” tende a ser indexada; o redirecionamento não fica em cache).
• John Mueller — 307s — a explicação do “307 fantasma” do HSTS.

Bing / Microsoft

• Gerenciando redirecionamentos — 301, 302 e canônicas (out. 2011) — a distinção do Bing entre 301 permanente e 302 temporário (sem menção a 307).
• Migração de site com o Bing (dez. 2020) — orientação geral de migração de site (novamente, sem declaração específica sobre 307).

Especificações

• MDN — Redirecionamento temporário 307 — a definição de preservação de método/corpo e a observação histórica sobre clientes antigos que alteravam o método para GET.
• RFC 9110 — Semântica HTTP — §15.4.8, “307 Temporary Redirect”, e §15.4.3, “302 Found”, o texto atual da especificação para os dois códigos.

Citações da fonte

Declarações registradas do Google, além da especificação. Quando a página de origem oferece suporte, cada link é um link profundo que salta para o trecho citado.

Documentação do Google — 307 é equivalente a 302

• A linha do 307 o classifica como equivalente ao 302 para o processamento do Googlebot — Google Search Central. Ir para a citação
• A mesma documentação ressalva que códigos tratados igualmente pelo Google continuam semanticamente diferentes e que a escolha correta beneficia outros clientes. Ir para a citação
• Para redirecionamentos temporários, incluindo 302/303/307, o Googlebot segue o destino, mas o pipeline de indexação não usa o redirecionamento como sinal de canonicalização do destino. Ir para a citação

John Mueller, Google (episódio 51 do podcast sobre redirecionamentos — “Let’s talk redirects”; PDF da transcrição oficial, citado por trecho — não há uma página HTML com texto correspondente para um link profundo #:~:text=)

• Mueller explicou que 301/302 normalmente encaminham solicitações GET, enquanto 307/308 também preservam POST.
• Para APIs ou formulários cujos resultados atravessam domínios, ele indicou 307/308 quando a preservação do método for necessária.
• Do ponto de vista de SEO, a escolha não importa muito; a pergunta prática é se funciona para APIs, que normalmente não precisam de indexação direta.
• Para redirecionamento entre versões mobile e desktop, ele apontou o 302 como a opção tecnicamente adequada porque a preferência da próxima visita é desconhecida. PDF da transcrição

John Mueller, Google (johnmu.com — o “307 fantasma” do HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (tradução) “Depois de ver a URL HTTPS com o cabeçalho HSTS (por exemplo, com qualquer redirecionamento da versão HTTP), o Chrome agirá como se estivesse vendo um redirecionamento 307 na próxima vez que você tentar acessar a página HTTP.”
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (tradução) “Seu servidor não está retornando um 307; o Chrome está apenas mostrando isso para explicar que está fazendo o redirecionamento por você.” Ler a publicação

MDN — a diferença de preservação do método

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (tradução) “A diferença entre 307 e 302 é que 307 garante que o cliente não alterará o método e o corpo da solicitação quando a solicitação redirecionada for feita. Com 302, clientes antigos alteravam incorretamente o método para GET.” Ir para a citação

Qual redirecionamento temporário: 302 ou 307?

Como ambos são temporários e equivalentes para SEO, toda a decisão se resume a uma pergunta — a solicitação carrega um método ou corpo que você precisa preservar?

Uma observação sobre o caminho “not sure” (tradução) “não tenho certeza”: o Google processa 307 da mesma forma que 302, e ele também funciona bem para redirecionamentos GET simples; portanto, usar 307 como padrão não é errado — mas também não é automaticamente gratuito. Confirme seus cabeçalhos de cache, verifique se os clientes antigos que você ainda suporta lidam previsivelmente com 307 e, se a solicitação redirecionada tiver efeitos colaterais (uma chamada não-GET para uma API), não permita que um 307 a repita automaticamente sem salvaguardas de idempotência.

Erros de redirecionamento temporário a evitar

Escolher 302 porque 307 supostamente passa menos valor

A documentação do Google diz que 307 é equivalente a 302 para a Busca. Escolha entre eles pelo comportamento da solicitação, não pelo ranking.

Presumir que 302 é sempre mais seguro por ser mais antigo

Clientes antigos tornavam o tratamento do método no 302 ambíguo. Se um corpo de POST, PUT, DELETE, webhook ou API precisa sobreviver, use 307 pela garantia explícita de preservação.

Tratar todo 307 do DevTools como regra do servidor

O Chrome pode mostrar uma atualização interna do HSTS como 307, mesmo quando o servidor nunca retornou um. Reproduza a solicitação com um verificador do lado do servidor ou curl antes de editar a configuração de redirecionamento.

Afirmar que todo 302 converte POST em GET

O comportamento histórico é permitido e ambíguo, não garantido em todo cliente moderno. Use 307 quando precisar de certeza; não descreva toda implementação de 302 como quebrada.

Substituir todo 302 por 307 em busca de ganho de SEO

Não há vantagem de ranking. Mude o código apenas quando preservar método/corpo melhorar a correção ou quando o padrão mais seguro de um framework for apropriado.

Confundir 303 com 307

Eles são opostos funcionais no tratamento do método: 303 muda deliberadamente o seguimento para GET; 307 preserva o método e o corpo originais.

Diagnosticar um 307 inesperado ou um fluxo 302 quebrado

O DevTools mostra um Internal Redirect / 307 inexplicável

Sintoma: uma navegação http:// aparece como 307 no Chrome, mas não existe uma regra de redirecionamento.

Causa provável: o HSTS atualizou a solicitação dentro do navegador antes de ela chegar ao servidor.

Correção: verifique o iniciador e os cabeçalhos da entrada e depois envie uma solicitação que não siga redirecionamentos automaticamente para a URL HTTP diretamente, usando uma ferramenta do lado do servidor — não o navegador, porque até uma janela anônima nova pode aplicar o estado HSTS pré-carregado. Também não trate curl como uma linha de base automaticamente neutra — ele pode ter seu próprio armazenamento HSTS configurado, então registre como foi invocado. Se a resposta bruta do servidor diferir do que o DevTools mostrou, não “corrija” o 307 fantasma; audite separadamente o redirecionamento HTTP→HTTPS real do servidor e repita qualquer solicitação não-GET como um teste controlado — uma solicitação HEAD que segue automaticamente não prova o comportamento de POST/corpo.

Um POST perde o corpo depois de um redirecionamento temporário

Sintoma: um formulário, webhook, login ou chamada de API chega ao destino como GET ou sem o payload.

Causa provável: a origem usou 302, permitindo que o cliente alterasse o método, ou um intermediário reescreveu a resposta.

Correção: use 307 para a mudança temporária, depois repita uma solicitação de teste segura e confirme nos logs do destino que método, tipo de conteúdo e corpo chegaram intactos.

A plataforma emite 307 embora você tenha escolhido um redirecionamento genérico

Sintoma: um framework ou uma plataforma de edge retorna 307 em vez do 302 esperado.

Causa provável: a plataforma escolheu o código temporário que preserva o método, geralmente para uma solicitação que não é GET.

Correção: confirme que a mudança é realmente temporária e que preservar a solicitação é correto. Se for, mantenha o código — o Google trata os dois da mesma forma. Só o altere quando a semântica da aplicação ou a compatibilidade com clientes exigir outra resposta.

302 vs. 307 de relance

Regra prática: página temporária GET simples → qualquer um funciona; solicitação temporária que não é GET e precisa chegar intacta → 307.

Ferramentas para identificar o redirecionamento que você realmente recebeu

Ferramenta gratuita de Patrick

• Bulk HTTP Status Code Checker — faz solicitações do lado do servidor para até 500 URLs e permite revisar os códigos reais e as cadeias. É especialmente útil para separar respostas do servidor da exibição interna de 307 causada apenas pelo HSTS do Chrome.

Inspecionar o comportamento da solicitação

• Redirect Checker — rastreia uma origem por cada salto e confirma se o servidor começa com 302 ou 307.
• Painel Network do DevTools do navegador — inspecione o iniciador e verifique se o Chrome rotula uma entrada como redirecionamento interno; não trate isso sozinho como prova de uma resposta do servidor.
• curl mais logs da aplicação — envie um POST seguro para staging e confirme que o destino recebe o mesmo método e corpo; se você configurou o curl com seu próprio armazenamento HSTS (--hsts), leve isso em conta ao interpretar o resultado. Ferramentas que mostram apenas o status não conseguem provar que o payload chegou.

Teste seus conhecimentos: 302 vs. 307

Cinco perguntas sobre os dois redirecionamentos temporários e o que realmente os diferencia. Escolha uma resposta para cada pergunta e confira depois.

Recursos que valem seu tempo

Minha produção relacionada

• 11 tipos de redirecionamentos e seu impacto no SEO (Ahrefs, com Joshua Hardwick) — meu panorama completo de todos os tipos de redirecionamento. É onde apresento minha ordem preferida de implementação para redirecionamentos temporários — 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 — e exponho o veredito de SEO: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (tradução) “Para SEO, é a mesma coisa, mas, se houver dados sendo enviados por formulários que redirecionam, você não vai querer alternar entre GET e POST.”
• Códigos de status HTTP e seu impacto no SEO (Ahrefs) — minha referência para cada código de status, incluindo os dois significados distintos de 307 (Temporary Redirect versus HSTS Policy 307) e a observação de que, com HSTS, “Google won’t see the 307 because it’s cached in the browser.” (tradução) “O Google não verá o 307 porque ele fica armazenado no cache do navegador.”
• Guia para iniciantes de SEO técnico — onde os redirecionamentos se encaixam no quadro maior.

Minhas palestras

• Patrick Stox no SlideShare e Speaker Deck — minhas palestras de SEO técnico; várias cobrem redirecionamentos e canonicalização. (Meu aviso permanente se aplica: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) “Esta é a minha compreensão dos sistemas… não será 100% completa ou precisa.”)

Oficial

• Google — Códigos de status HTTP, erros de rede e DNS — a linha “Equivalent to 302” (tradução) “Equivalente a 302” e a ressalva “semantically different, use the right code” (tradução) “semanticamente diferentes, use o código apropriado”.
• Google — Redirecionamentos e o Google Search — agrupa 302/303/307 como temporários.
• Search Off the Record — “Vamos falar sobre redirecionamentos” (Google Search Relations, ep. 51) — a discussão de Mueller/Splitt da qual as citações acima foram extraídas.

Ao redor da indústria

• John Mueller — 307s — a explicação mais clara do “307 fantasma” do HSTS: o 307 que seu navegador mostra, mas o servidor nunca enviou.
• MDN — Redirecionamento temporário 307 — a definição clara de preservação de método/corpo e a observação histórica sobre clientes antigos.
• Guia de SEO sobre redirecionamentos (Search Engine Land, Helen Pollitt) — uma boa visão geral da família de redirecionamentos.
• Redirecionamentos de URL para SEO: um guia técnico (Search Engine Journal) — outro panorama técnico sólido.
• Um mito a corrigir: a página da Conductor sobre “302 vs 307” recomenda usar 302 em vez de 307 porque “it’s clear how search engines treat the 302 redirect” (tradução) “é claro como os mecanismos de busca tratam o redirecionamento 302”. Essa orientação contradiz a documentação do próprio Google, que chama 307 explicitamente de “Equivalent to 302” (tradução) “Equivalente a 302” — o tratamento do 307 é igualmente documentado. Não trate “302 is the safer SEO choice” (tradução) “302 é a escolha de SEO mais segura” como autoridade; o único fator real de decisão é a necessidade de preservar método/corpo.
• r/TechSEO — a comunidade para depuração de redirecionamentos e canonicalização.

Registro de alterações