307 Redirecionamento Temporário

TL;DR — Um 307 é um redirecionamento temporário, assim como um 302 — envia pessoas e mecanismos de busca para uma nova URL por enquanto, sem dizer ao Google para transferir o ranking da URL antiga para a nova. A única coisa que o diferencia de um 302: um 307 promete não mudar o tipo de solicitação. Se alguém enviou um formulário (um POST), ele continua sendo POST. Para links simples de página para página, isso é invisível; só importa para formulários e aplicativos. E o “307” que às vezes aparece no navegador ao atualizar para https nem sequer é um redirecionamento real.

O que é um redirecionamento 307

Quando uma URL mudou para outro lugar por enquanto — não permanentemente — o servidor pode responder com um redirecionamento temporário 307 e apontar o navegador para o novo local. Essa é a mesma ideia básica de um 302: é temporário, então o Google não o trata como um sinal para transferir o ranking da URL original para a nova, como faz com um redirecionamento permanente. É um sinal fraco que não define canonicalização, não uma garantia de que a URL original manterá seus rankings ou continuará indexada para sempre. Você usaria um redirecionamento temporário para uma página fora do ar por manutenção, uma campanha sazonal ou qualquer coisa que planeje reverter depois.

O que torna 307 diferente de 302

Na verdade, há apenas uma diferença, e a maioria das pessoas nunca se depara com ela. Uma solicitação web tem um método — normalmente GET (apenas buscar uma página), mas às vezes POST (enviar dados, como ao submeter um formulário). Um 307 garante que o navegador mantenha o mesmo método ao seguir o redirecionamento. Navegadores antigos às vezes transformavam POST em GET em um 302, o que podia quebrar o envio do formulário. Um 307 elimina esse risco pelas regras do protocolo. Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

Para a grande maioria dos redirecionamentos — alguém clicando em um link para uma página — isso não faz diferença alguma, porque são solicitações GET de qualquer maneira.

Um 307 prejudica o SEO?

Não. A própria documentação do Google diz que um 307 é “equivalent to” (tradução) «equivalente a» um 302. Ambos são temporários, portanto nenhum transfere o ranking da página antiga para a nova como um redirecionamento permanente (301) faz. Não há penalidade secreta nem benefício secreto — um 307 é tratado exatamente como um 302.

O “307” que não é um redirecionamento

Aqui está a parte que confunde as pessoas. Se seu site força https (um recurso de segurança chamado HSTS), seu navegador às vezes mostra um “307” nas ferramentas de desenvolvedor quando você visita a versão http de uma página. Seu servidor não enviou isso — o navegador inventou a indicação para explicar que saltou diretamente para a versão segura por conta própria. Ele inclusive mostra uma resposta de 0 bytes, o que denuncia o caso.

Portanto, se uma ferramenta de auditoria ou seu navegador sinalizar um 307 inesperado, não entre em pânico pensando que seu servidor está configurado incorretamente. Uma janela anônima nova normalmente limpa a memória HSTS aprendida pelo navegador e mostra o código de status real — mas nem sempre: alguns domínios estão na lista de preload HSTS incorporada aos navegadores, que a navegação anônima não limpa. Um verificador de redirecionamentos ou uma solicitação curl é a forma mais confiável de ver o que seu servidor realmente retorna.

Quer a linguagem da especificação, o que John Mueller disse, a mecânica completa do HSTS e como retornar um 307 de verdade? Mude para a aba Avançado.

TL;DR — Um 307 é um redirecionamento temporário que, pela RFC 9110, “MUST NOT change the request method” (tradução) «NÃO DEVE mudar o método da solicitação» — a única garantia rígida que um 302 não oferece. Para SEO, ele não muda nada: a documentação do Google o lista como “Equivalent to 302” (tradução) «Equivalente a 302» (um sinal fraco e temporário), e Mueller disse que a escolha entre 307 e 302 “doesn’t really matter” (tradução) «não importa muito» para a Busca — a questão é se o redirecionamento precisa funcionar para tráfego POST/API. O 307 que realmente confunde as pessoas é o artefato HSTS: um “redirecionamento” de 0 bytes, visível apenas no navegador, que o servidor nunca enviou e que surge quando o navegador atualiza http para https por conta própria. Há dois casos funcionalmente sem relação, e mantê-los separados é todo o trabalho.

Um 307 tem dois casos completamente diferentes

Esta é a ideia organizadora de tudo a seguir, e vem diretamente do meu guia de códigos de status, onde 307 aparece em duas entradas separadas: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (tradução) «Redirecionamento temporário 307 — tem a mesma funcionalidade que um redirecionamento 302, exceto que você não pode alternar entre POST e GET» e “307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP.” (tradução) «Política HSTS do 307 — força o cliente a usar HTTPS ao fazer solicitações em vez de HTTP.» Eles compartilham um número e quase nada mais:

1. 307 como redirecionamento temporário real, emitido pelo servidor — escolhido deliberadamente (ou definido por padrão por um framework) para preservar o método e o corpo HTTP em uma solicitação que não seja GET.
2. 307 como artefato do navegador HSTS — não é uma resposta do servidor. O navegador atualiza http para https internamente e rotula essa atualização como 307.

Confundir esses dois casos é a maior fonte isolada de confusão sobre 307. Vou tratá-los um de cada vez.

Caso 1: o 307 real — o que a especificação exige

A RFC 9110 (a especificação atual de semântica HTTP) é inequívoca na seção §15.4.8:

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (tradução) «O código de status 307 (Redirecionamento temporário) indica que o recurso de destino reside temporariamente sob um URI diferente e o agente de usuário NÃO DEVE alterar o método da solicitação se realizar um redirecionamento automático para esse URI.»

Esse “MUST NOT” (tradução) «NÃO DEVE» é uma exigência rígida, não uma sugestão. Compare-o com a seção sobre 302 (§15.4.3), que documenta abertamente a confusão histórica que o 307 foi criado para corrigir: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (tradução) «Por razões históricas, um agente de usuário PODE mudar o método da solicitação de POST para GET na solicitação seguinte. Se esse comportamento for indesejado, o código de status 307 (Redirecionamento temporário) pode ser usado.» Em outras palavras, 307 existe especificamente para remover a ambiguidade POST→GET que clientes antigos tinham com 302s.

A MDN apresenta a versão prática da mesma distinção:

“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. 307 and 302 responses are identical when the request method is GET.” (tradução) «A diferença entre 307 e 302 é que 307 garante que o cliente não mudará o método e o corpo da solicitação quando a solicitação redirecionada for feita. Com 302, clientes antigos mudavam incorretamente o método para GET. As respostas 307 e 302 são idênticas quando o método da solicitação é GET.»

Essa última frase é a que mais importa para SEO. Quase todo redirecionamento relevante para um profissional de SEO — uma página antiga para uma nova — é uma solicitação GET e, para solicitações GET, 307 e 302 são literalmente idênticos. A garantia de preservação do método só importa quando o método não é GET: reenvios de formulários, endpoints de API, destinos de webhooks e handoffs POST de checkout ou autenticação. A especificação garante o método e o corpo — ela não define por si só como cada cliente tratará cabeçalhos, credenciais ou solicitações entre origens ao repetir a solicitação; portanto, verifique isso com seu cliente real em vez de presumir comportamento byte a byte. Se você estiver comparando os dois códigos para uma mudança normal de página, o assunto é tratado em profundidade no artigo específico sobre 302 versus 307 — este artigo pressupõe que você já conhece o conceito básico de redirecionamento temporário do aprofundamento sobre 302 e se concentra no que é exclusivo do 307.

302 versus 303 versus 307, em uma tabela

Os três estão na categoria “temporário” da RFC, mas não se comportam da mesma forma nos dois eixos que realmente importam — preservação do método e cache:

Nenhum dos três é armazenável heuristicamente por padrão — um 307 (como 302 e 303) precisa de um sinal explícito de frescor (Cache-Control, Expires etc.) para que um cache o armazene sem perguntar novamente.

Caso 1, continuação: como o Google trata um 307 real para SEO

Versão curta: exatamente como um 302. A documentação de HTTP Status Codes do Google lista a linha 307 como “Equivalent to 302” (tradução) «Equivalente a 302», e a linha 302 que ele herda explica o que isso significa:

“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 deve ser processado.»

“Weak” (tradução) «Fraco» é a palavra operacional — um redirecionamento temporário não consolida a canonicalização no destino como um permanente faz. A documentação do Google sobre “Redirects and Google Search” (tradução) «Redirecionamentos e a Pesquisa Google» agrupa 302, 303 e 307 sob “temporary” (tradução) «temporário» e descreve o comportamento diretamente: “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 sinal de que o destino deve ser canônico.» A mesma página enquadra a intenção assim: “If you just want to send users to a different page temporarily, use a temporary redirect.” (tradução) «Se você apenas quer enviar usuários para uma página diferente temporariamente, use um redirecionamento temporário.»

Imediatamente depois das linhas 307 e 308, o Google acrescenta a ressalva que vale a pena tatuar na parede:

“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.»

Assim, o Google coloca 307 e 302 na mesma categoria para ranking, mas ainda orienta você a escolher o código semanticamente correto. Essa é toda a resposta de SEO. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John Mueller foi ainda mais direto no episódio 51 do programa Fora do registro da Busca (“Vamos falar de redirecionamentos”), explicando que “with 307, 308, it also forwards POST requests” (tradução) «com 307 e 308, ele também encaminha solicitações POST» — ao contrário de 301/302, que encaminham solicitações GET — e então resumindo o ponto:

Para SEO, a escolha entre esses códigos não importa muito; a questão prática é se o redirecionamento precisa funcionar para APIs, que normalmente não precisam ser indexadas diretamente na Busca.

Não há vantagem de ranking em trocar seus redirecionamentos temporários por 307. O único motivo válido para escolhê-lo é a preservação do método/corpo — ou, como preferência geral de preparação para o futuro, algo a que voltarei no final.

Caso 1, continuação: padrões de frameworks e CDNs

Uma parcela crescente das perguntas “por que isto é um 307?” não envolve escolhas deliberadas — são padrões de frameworks. A função redirect() do Next.js usa 307 por padrão, e a documentação explica explicitamente o motivo, sob o título “Why does redirect use 307 and 308?” (tradução) «Por que redirect usa 307 e 308?»: “The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.” (tradução) «O método redirect() usa 307 por padrão, em vez de um redirecionamento temporário 302, o que significa que suas solicitações sempre serão preservadas como solicitações POST.» (O Next.js usa 303 especificamente dentro de Server Actions e oferece permanentRedirect() separadamente para o caso 308.) Se você está vendo 307s que não escreveu manualmente, verifique se seu framework ou plataforma de edge os está definindo como padrão para redirecionamentos que não sejam GET — normalmente essa é a resposta, e normalmente está correta.

Caso 2: o “307 fantasma” do HSTS que seu servidor nunca enviou

Este é o território realmente pouco coberto e onde um artigo dedicado a 307 se justifica. Quando um site envia um cabeçalho Strict-Transport-Security (HSTS), ele diz ao navegador: a partir de agora, carregue-me apenas por https. Na próxima solicitação à versão http, o navegador atualiza para https por conta própria, sem falar com o servidor — e mostra essa atualização interna como um “307” nas ferramentas de desenvolvimento e nos rastreadores.

John Mueller explicou a mecânica em seu site pessoal:

“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. 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) «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. Seu servidor não está retornando um 307; o Chrome está apenas mostrando isso para explicar que está fazendo o redirecionamento por você.»

O corpo de 0 bytes é a pista — como Mueller acrescenta, “the 307 isn’t actually a redirect at all, it’s just a placeholder.” (tradução) «o 307 não é realmente um redirecionamento, é apenas um marcador.» Meu guia de redirecionamentos apresenta a consequência prática para auditorias: “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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.” (tradução) «Quando servidores web exigem que clientes usem apenas conexões HTTPS (política HSTS), o Google não verá o 307 porque ele fica armazenado no cache do navegador. O acesso inicial (sem cache) terá um código de resposta do servidor provavelmente 301 ou 302. Mas seu navegador mostrará um 307 nas solicitações seguintes, o que torna a solução de problemas mais difícil. Você precisará usar uma sessão anônima nova para ver o código de status retornado.»

O que o Googlebot realmente vê no HSTS (e como a história evoluiu)

Duas declarações do Google, separadas por cinco anos, merecem ser lidas juntas. Em dezembro de 2015, Zineb Ait Bahajji (então no Google) explicou, segundo o Search Engine Roundtable, que, com HSTS, o Googlebot via um redirecionamento 301, enquanto o 307 mostrado pelo navegador era apenas interno. Em outubro de 2020, Mueller formulou o ponto de modo um pouco diferente em um vídeo do Ask Google Webmasters (via Search Engine Journal): o Googlebot não interage com esses 307, que em geral não são redirecionamentos reais. De todo modo, o rastreador não está vendo o mesmo “307” que uma pessoa vê nas ferramentas de desenvolvimento — as ferramentas e a infraestrutura de rastreamento mudaram (Fetch as Google foi aposentado para a Inspeção de URL), mas o ponto principal se manteve por pelo menos uma década: não há um 307 real emitido pelo servidor no caso HSTS. Trate a declaração de 2020 como orientação atual; a de 2015 é história útil.

A conclusão operacional importante: HSTS é uma conveniência do navegador, não um mecanismo de descoberta de rastreamento. Os proprietários do site ainda precisam de um redirecionamento real no servidor (um 301 genuíno) para http→https se quiserem que esse caminho funcione para rastreadores.

Como o Bing trata um 307

Sinceramente? Há uma lacuna de documentação. Não encontrei nenhuma declaração pública do Bing que trate de 307 pelo nome, nem especificamente do 307 provocado por HSTS. A orientação de redirecionamentos do Bing (a publicação de 2011 Gerenciando redirecionamentos — 301s, 302s e URLs canônicas e a publicação de 2020 Migração de sites com o Bing) cobre apenas a divisão permanente versus temporária entre 301/302 — não menciona 307, 308 ou HSTS. Portanto, em vez de presumir paridade com o Google, trate o assunto com clareza: o Bing não disse nada publicamente específico sobre 307. O fenômeno ainda é real e relevante para rastreadores independentemente do mecanismo — o SEO Spider do Screaming Frog inclui uma opção “Respect HSTS Policy” (tradução) «Respeitar a política de HSTS» justamente porque HSTS afeta o rastreamento — mas isso é documentação de ferramenta, não uma declaração do Bing.

Quando escolher deliberadamente um 307

Escolha 307 (em vez de 302) sempre que perder o método ou o corpo original quebraria alguma coisa:

• Endpoints de API e destinos de webhook que recebem POST/PUT/PATCH.
• Fluxos de envio de formulário (POST) que redirecionam depois do processamento.
• Handoffs de POST de checkout/login entre hosts.
• Qualquer situação em que a solicitação carregue um corpo que você não possa perder.

Para uma mudança simples de página para página, 302 e 307 são indistinguíveis para o Google, então qualquer um serve no eixo de SEO. Se você está lidando com a versão permanente dessa mesma lógica de preservação do método, essa é a relação 301 versus 308 — 308 está para 301 assim como 307 está para 302.

Minha preferência declarada, no guia de redirecionamentos, é mais opinativa do que o usual “não importa”: “my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” (tradução) «minha ordem preferida seria: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.» Coloco 307 primeiro entre as opções temporárias — usá-lo de forma consistente significa que você está sempre seguro quanto à preservação do método, que é aproximadamente o argumento de “completude” que Mueller também apresentou. E qualquer que seja sua escolha, cuide para que um 307 real (ou o artefato HSTS) não se torne um salto em uma cadeia de redirecionamentos mais longa — cada salto extra acrescenta latência e reduz a eficiência.

Resumo de IA

Uma versão condensada da versão Advanced:

• Um 307 tem dois casos sem relação. (1) Um redirecionamento temporário real, emitido pelo servidor, que preserva o método e o corpo HTTP; (2) um artefato de navegador HSTS — um “307” de 0 bytes que o servidor nunca enviou, produzido quando o navegador atualiza http→https por conta própria. Mantê-los separados é todo o trabalho.
• Caso 1 — a garantia da especificação: a RFC 9110 diz que um 307 “MUST NOT change the request method.” (tradução) «NÃO DEVE mudar o método da solicitação.» A MDN acrescenta que “307 and 302 responses are identical when the request method is GET” (tradução) «as respostas 307 e 302 são idênticas quando o método da solicitação é GET» — portanto, isso só importa para POST/PUT/PATCH (formulários, APIs). A garantia cobre método e corpo; o tratamento de cabeçalhos, credenciais e origens cruzadas na repetição ainda depende do cliente.
• 302 versus 303 versus 307: 302 pode (historicamente) mudar POST para GET, 303 busca deliberadamente o destino com GET/HEAD, 307 não pode mudar o método — e nenhum dos três é armazenável heuristicamente por padrão.
• Resposta de SEO: a documentação do Google lista 307 como “Equivalent to 302” (tradução) «Equivalente a 302» — um sinal fraco e temporário que não consolida a canonicalização no destino. Mueller: para SEO, “it doesn’t really matter” (tradução) «não importa muito»; a pergunta real é “funciona para APIs?”.
• Padrões de frameworks: o redirect() do Next.js usa 307 por padrão (303 em Server Actions e permanentRedirect() para 308) para preservar POST — uma fonte comum de 307s “acidentais” que normalmente está correta.
• Caso 2 — HSTS: o navegador mostra um 307 com corpo de 0 bytes; o código real do servidor geralmente é 301/302. O Googlebot não vê esse 307 (Mueller em 2020: “doesn’t interact with them” (tradução) «não interage com eles»; Zineb em 2015: “sees a 301” (tradução) «vê um 301»). Você ainda precisa de um 301 real no servidor para http→https. Audite com um verificador de redirecionamentos ou curl simples — uma sessão anônima nova geralmente também funciona, mas não para domínios na lista de preload HSTS incorporada ao navegador.
• Bing: não há declaração pública específica sobre 307 — uma lacuna de documentação, não paridade.
• Preferência: não há motivo de ranking para mudar para 307; minha própria ordem coloca 307 em primeiro entre as opções temporárias para preparação futura.

Documentação oficial

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

Google

• Códigos de status HTTP, rede e erros de DNS e a Pesquisa Google — a linha “307 (temporary redirect) — Equivalent to 302” (tradução) «307 (redirecionamento temporário) — Equivalente a 302», a linguagem de “sinal fraco” do 302 e a ressalva de que são “semanticamente diferentes”.
• Redirecionamentos e a Pesquisa Google — agrupa 302/303/307 como “temporários”; “o pipeline de indexação não usa o redirecionamento como sinal de que o destino deve ser canônico”.

Bing / Microsoft

• Gerenciando redirecionamentos — 301s, 302s e URLs canônicas — orientação de redirecionamentos do Bing (somente 301/302; sem menção a 307/HSTS).
• Migração de sites com o Bing — orientação de migração, novamente apenas 301/302.

Especificação HTTP

• RFC 9110 §15.4.8 — Redirecionamento temporário 307 — “MUST NOT change the request method” (tradução) «NÃO DEVE mudar o método da solicitação.»
• RFC 9110 §15.4.3 — 302 Found — a observação histórica sobre POST→GET que faz referência cruzada ao 307.

Referência técnica

• MDN — Redirecionamento temporário 307 — preservação de método/corpo; “identical when the request method is GET” (tradução) «idêntico quando o método da solicitação é GET».

Framework

• Next.js — referência da função redirect() — a pergunta frequente “Why does redirect use 307 and 308?”; padrão 307 (303 em Server Actions).

Ferramenta de rastreamento

• Screaming Frog — An SEO’s Guide To Crawling HSTS & 307 Redirects — a configuração “Respect HSTS Policy” e a mecânica do HSTS.

Citações da fonte

Declarações registradas. Cada link aponta para (ou documenta) o trecho citado.

Documentação do Google — o tratamento de SEO

• “307 (temporary redirect) — Equivalent to 302.” (tradução) «307 (redirecionamento temporário) — Equivalente a 302.» — Google Search Central, “HTTP Status Codes, Network and DNS Errors, and Google Search” (tradução) «Códigos de status HTTP, rede e erros de DNS e a Pesquisa Google». Ir para a citação
• “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 deve ser processado.» (a linha 302 que o 307 herda) Ir para a citação
• “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 possam se beneficiar dele.» Ir para a citação
• “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 sinal de que o destino deve ser canônico.» — Google Search Central, “Redirects and Google Search” (tradução) «Redirecionamentos e a Pesquisa Google». Ir para a citação

Especificação HTTP / MDN — a garantia técnica

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (tradução) «O código de status 307 (Redirecionamento temporário) indica que o recurso de destino reside temporariamente sob um URI diferente e o agente de usuário NÃO DEVE alterar o método da solicitação se realizar um redirecionamento automático para esse URI.» — RFC 9110, §15.4.8. Leia a seção
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (tradução) «Por razões históricas, um agente de usuário PODE mudar o método da solicitação de POST para GET na solicitação seguinte. Se esse comportamento for indesejado, o código de status 307 (Redirecionamento temporário) pode ser usado.» — RFC 9110, §15.4.3 (a seção sobre 302). Leia a seção
• “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… 307 and 302 responses are identical when the request method is GET.” (tradução) «A diferença entre 307 e 302 é que 307 garante que o cliente não mudará o método e o corpo da solicitação quando o cliente realizar a solicitação redirecionada… as respostas 307 e 302 são idênticas quando o método da solicitação é GET.» — MDN, Redirecionamento temporário 307. Ir para a citação

John Mueller, Google — SEO e preservação do método

• “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.» — programa Fora do registro da Busca, episódio 51, “Vamos falar de redirecionamentos” (17 de novembro de 2022). PDF da transcrição
• “And with 307, 308, it also forwards POST requests” (tradução) «E com 307 e 308, ele também encaminha solicitações POST» (em comparação com 301/302, que encaminham solicitações GET). — Mesmo episódio.

John Mueller, Google — o “307 fantasma” do HSTS

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (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ê… o 307 não é realmente um redirecionamento, é apenas um marcador.» — John Mueller, HTTPS & HSTS: 301, 302, or 307? (johnmu.com, originalmente Google+, junho de 2016). Ir para a citação
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (tradução) «Em resumo, o [Googlebot] não interage com eles. Redirecionamentos 307 geralmente não são redirecionamentos reais.» — John Mueller, Ask Google Webmasters (outubro de 2020), via Search Engine Journal. Ir para a citação

Zineb Ait Bahajji, Google — HSTS, 2015 (relatado)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (tradução) «Com HSTS implementado, o Googlebot vê um redirecionamento 301 (tente com Fetch as Google). O 307 é apenas um “redirecionamento interno”.» — Zineb Ait Bahajji (Google), via Twitter, relatado pelo Search Engine Roundtable (dezembro de 2015). Ir para a citação

Qual 307 estou realmente vendo?

Quase toda pergunta sobre 307 se resolve em uma de duas coisas totalmente diferentes. Vamos percorrer o caso.

Mitos e erros a evitar

“A 307 doesn’t pass link equity the way a 302 does.” (tradução) «Um 307 não passa valor de link como um 302.» Isso é falso na formulação “307 é pior que 302” — e ela circula ativamente em grandes blogs de SEO. A documentação do Google processa 307 e 302 da mesma forma: ambos são redirecionamentos temporários de “weak signal” (tradução) «sinal fraco» que não definem canonicalização, e a documentação de HTTP Status Codes do Google chama 307 diretamente de “Equivalent to 302” (tradução) «Equivalente a 302». Não há base documentada para afirmar que 307 passa menos que 302. O enquadramento do próprio Google é que redirecionamentos temporários em geral não devem consolidar sinais de ranking no destino como um redirecionamento permanente — portanto, não deixe uma alegação de que “307 especificamente retém valor” levar você a mudanças desnecessárias.

“A 307 in my Network tab means my server misconfigured a redirect.” (tradução) «Um 307 na minha aba Network significa que meu servidor configurou um redirecionamento incorretamente.» Muitas vezes, falso. Se o HSTS estiver ativo e o navegador tiver visto antes o cabeçalho Strict-Transport-Security, ele mostra uma atualização http→https como 307 apenas para explicar seu próprio comportamento — o servidor nunca o retornou (o corpo de 0 bytes é a pista). Uma sessão anônima nova normalmente mostra o código real, mas não para domínios na lista de preload HSTS incorporada ao navegador — nesses casos, teste com um verificador de redirecionamentos ou curl (sem HSTS configurado) antes de procurar uma configuração incorreta que não existe.

“Googlebot sees the same 307 my browser shows me for an HSTS site.” (tradução) «O Googlebot vê o mesmo 307 que meu navegador mostra em um site HSTS.» Não exatamente. Representantes do Google disseram que o Googlebot vê um 301 (Zineb, 2015) ou não interage com o mecanismo 307/HSTS (Mueller, 2020). De qualquer forma, não é o “307” visível para a pessoa. Você ainda precisa de um 301 real no servidor para http→https se a descoberta de rastreamento desse caminho for importante.

“303 and 307 are basically interchangeable.” (tradução) «303 e 307 são basicamente intercambiáveis.» Eles são opostos no único eixo que importa. Um 303 sempre muda o método para GET (o padrão Post/Redirect/Get); um 307 garante que o método não seja alterado. Eles são fáceis de confundir apenas porque ambos estão na categoria “temporário” ao lado de 302.

“Switch all your temporary redirects to 307 for a rankings boost.” (tradução) «Mude todos os seus redirecionamentos temporários para 307 para aumentar os rankings.» Não há benefício. O único motivo válido para preferir 307 a 302 é a preservação genuína do método/corpo (ou a preparação geral para o futuro). Transformar todos os 302 em 307 não traz nada e pode introduzir erros.

“302s always convert POST to GET, so 302 is fundamentally broken for forms.” (tradução) «302s sempre convertem POST em GET, então 302 é fundamentalmente quebrado para formulários.» Exagero. A conversão POST→GET era um problema real para clientes antigos e inconsistentes — exatamente por isso 307 existe como opção garantida —, mas os navegadores modernos são muito mais consistentes. Um 307 remove a ambiguidade pela especificação, em vez de depender do comportamento atual do cliente; isso não significa que 302 esteja “quebrado”.

Veja o código de status real (não o artefato HSTS)

O navegador esconde um 301/302 real atrás de um 307 fantasma depois que o HSTS é armazenado. O curl não aplica HSTS por padrão, então uma chamada simples conversa diretamente com o servidor e mostra a verdade — apenas não a execute com um arquivo de cache --hsts configurado, ou você reintroduzirá a mesma reescrita no lado do cliente que está tentando excluir.

Rastreie a cadeia completa de redirecionamentos, somente cabeçalhos

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

Verifique o código de status de uma URL sem seguir o redirecionamento

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Console do Chrome DevTools — detectar um 307 fantasma

Cole na aba Console. Um redirecionamento real do servidor expõe uma flag redirected e uma URL resolvida; a atualização HSTS acontece antes mesmo de a solicitação sair do navegador.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Você também pode ler diretamente o registro HSTS do Chrome em chrome://net-internals/#hsts — consulte um domínio para ver se static_upgrade_mode/dynamic_upgrade_mode está forçando https (é isso que produz o 307 visto na aba Network).

Bookmarklet — consulta rápida de cabeçalhos da aba atual

Arraste um favorito com isto como URL e clique nele em qualquer página para registrar no Console o status e o estado de redirecionamento da URL atual:

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

Observação: o fetch() do navegador não consegue ler corpos opacos de redirecionamentos entre origens; portanto, para rastreamento autoritativo de vários saltos, curl -sIL acima é a fonte de verdade.

Retornar um 307 real

O objetivo de retornar um 307 (em vez de deixar um framework defini-lo como padrão) é garantir que o método e o corpo sobrevivam. Estas são algumas formas comuns de fazer isso explicitamente.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 é o padrão, então muitas vezes você nem escreve o código:

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

Como é uma resposta 307 bruta

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

Como é o “307 fantasma” do HSTS (somente no navegador)

A mesma linha de status nas ferramentas de desenvolvimento, mas observe as pistas — ela se origina no navegador, não no servidor, e carrega um corpo de 0 bytes:

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Se você vir Non-Authoritative-Reason: HSTS (Chrome) ou um “307” de 0 bytes que desaparece quando testado com um cliente que não aplica HSTS, esse é o artefato — não um redirecionamento enviado pelo servidor. O nome exato do cabeçalho e o rótulo do DevTools são detalhes de implementação específicos do Chrome, não uma garantia da especificação HTTP ou HSTS; trate-os como ilustrativos, não como algo para basear automação entre navegadores ou versões.

O método, a duração e o framework de origem

Avalio um 307 em três eixos antes de alterá-lo:

1. Método: o destino precisa receber o método e o corpo originais da solicitação? Se sim, 307 é o redirecionamento temporário que preserva os dois. Um GET simples de página para página normalmente não precisa dessa propriedade.
2. Duração: a mudança é genuinamente temporária? Mantenha 307 somente enquanto se espera que a URL original volte. Uma mudança permanente exige uma decisão por redirecionamento permanente, não um status temporário indefinido.
3. Origem: o servidor enviou o 307, um framework o escolheu ou o navegador sintetizou uma atualização HSTS interna? Um “Internal Redirect” do DevTools não é uma regra da origem para reescrever.

Ferramentas para separar 307s reais e fantasmas

• Redirect Checker: veja o status observável pelo servidor, o destino e cada salto sem depender do estado HSTS de um navegador.
• Redirect Chain Mapper: use a visão por salto quando um 307 fizer parte de um caminho de redirecionamento mais longo.
• HTTP Header Checker: inspecione Location e Strict-Transport-Security e compare pistas da edge com as da origem.
• curl: execute curl -I http://example.com/path fora da exibição HSTS interna do navegador. Teste a preservação de POST somente contra um endpoint seguro que você controle.
• DevTools do navegador: verifique se a entrada diz “Internal Redirect” e tem transferência de zero bytes, o que aponta para uma atualização HSTS gerada pelo navegador.

Validar um 307 depois da implantação

Teste de status e destino

Teste a executar: verifique a origem com o Redirect Checker ou curl -I. Resultado esperado: um 307 com o Location pretendido. Interpretação da falha: outra camada alterou a regra ou o destino. Janela de monitoramento: imediata. Gatilho de rollback: aparece um loop, um destino quebrado ou um hostname não intencional.

Teste de preservação do método

Teste a executar: envie um POST inofensivo para uma rota de teste controlada e inspecione o que o destino recebe. Resultado esperado: o destino recebe POST com o corpo original. Interpretação da falha: um intermediário converteu o método ou serviu outro código. Janela de monitoramento: imediata. Gatilho de rollback: uma solicitação de formulário, webhook ou checkout perde seu método ou corpo.

Teste de separação do HSTS

Teste a executar: compare o DevTools (ou uma sessão anônima nova) com uma solicitação curl -I sem cache HSTS configurado. Resultado esperado: um “Internal Redirect” do navegador é distinguível da resposta real do servidor, e HTTP ainda tem um redirecionamento no servidor. Interpretação da falha: o HSTS está mascarando uma regra ausente na origem — observe que apenas a navegação anônima não é suficiente para domínios na lista de preload HSTS incorporada ao navegador, pois esse estado persiste independentemente do histórico. Janela de monitoramento: imediata. Gatilho de rollback: a mudança na origem remove o redirecionamento funcional de HTTP para HTTPS.

Teste seus conhecimentos: redirecionamento temporário 307

Cinco perguntas rápidas sobre o que é 307, como o Google o trata e o artefato HSTS. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus textos relacionados

• 11 tipos de redirecionamento e seu impacto em SEO — de onde vêm a definição de 307, a ressalva sobre HSTS e minha classificação preferida (307 / 302 / 303 em primeiro).
• Códigos de status HTTP e seu impacto em SEO — meu texto com as duas entradas distintas de 307: o caso de redirecionamento temporário e o caso de política HSTS.
• Guia de SEO técnico para iniciantes — onde os redirecionamentos se encaixam no panorama maior.

Minhas apresentações

• How Search Works (SlideShare) — minha explicação sobre rastreamento, renderização, indexação e ranking, incluindo como os redirecionamentos são tratados. (Meu aviso permanente se aplica: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Este é meu entendimento dos sistemas… não será 100% completo ou preciso.»)

Da indústria

• John Mueller — HTTPS e HSTS: 301, 302 ou 307? — a explicação de primeira parte mais clara sobre o “307 fantasma” do HSTS (“your server’s not returning a 307” (tradução) «seu servidor não está retornando um 307»).
• Fora do registro da Busca, episódio 51 — “Vamos falar de redirecionamentos” (PDF da transcrição) — Mueller e Splitt sobre por que 307/308 existem e por que “for SEO, it doesn’t really matter” (tradução) «para SEO, não importa muito».
• Google sobre redirecionamentos 307/HSTS (Search Engine Journal) — resumo do vídeo de Mueller “307 redirects are generally not real redirects” (tradução) «redirecionamentos 307 geralmente não são redirecionamentos reais».
• O Googlebot trata redirecionamentos 307 como 301? (Search Engine Roundtable) — declaração de Zineb Ait Bahajji de 2015 sobre o que o Googlebot vê no HSTS.
• MDN — Redirecionamento temporário 307 — a referência técnica padrão-ouro para a garantia de preservação de método/corpo.
• Guia de SEO para rastrear HSTS e redirecionamentos 307 (Screaming Frog) — o melhor tratamento de configuração de rastreador para 307s provocados por HSTS.
• Next.js — redirect() reference — por que um framework importante define redirecionamentos que não são GET como 307.

Registro de alterações