308 Redirecionamento Permanente

TL;DR — Um 308 Permanent Redirect diz “isto mudou de vez” — exatamente como um 301 — mas com uma promessa adicional: o método da solicitação não pode ser alterado no novo endereço e, como o navegador repete a mesma solicitação em vez de fazer uma nova, o restante (incluindo os dados de um formulário) normalmente também segue. Assim, o envio de um formulário continua sendo um envio de formulário, em vez de virar silenciosamente uma visita de página comum. Para mecanismos de busca, os dois códigos são idênticos; portanto, para um redirecionamento normal de “esta página mudou”, 301 é suficiente. Escolha 308 quando estiver redirecionando algo que não seja apenas uma página clicada por alguém — como uma API ou formulário — e a solicitação original precisar chegar intacta.

O que é um 308, de fato

Quando um servidor envia seu navegador de uma URL para outra, ele carimba a resposta com um número — um código de status. Alguns desses números significam “esta página mudou permanentemente”:

• 301 — “Moved Permanently.” O código original e mais antigo de redirecionamento permanente. Ele existe desde os primórdios da web.
• 308 — “Permanent Redirect.” Um código mais novo (adicionado à especificação em 2015) que faz o mesmo trabalho mais uma garantia que o 301 nunca ofereceu.

Essa garantia é a razão inteira de o 308 existir. Na maior parte do tempo, quando você visita uma página, seu navegador envia uma solicitação simples chamada GET — “por favor, entregue esta página”. Mas, quando você envia um formulário ou faz login, o navegador envia um POST — uma solicitação que carrega dados (aquilo que você digitou). Com um 301 antigo, o navegador tecnicamente pode transformar seu POST em um GET simples no caminho para a nova URL — o que normalmente faz esses dados serem descartados. Um 308 não pode alterar o método dessa forma. Como o navegador repete a mesma solicitação em vez de criar uma nova, os dados normalmente vêm junto — mas, se isso importar para algo que você esteja construindo (uma chamada de API, um fluxo de checkout), não aceite apenas a palavra da especificação: teste a solicitação real e confirme que o corpo chega à nova URL.

Um 308 prejudica o SEO?

Não. A própria documentação do Google diz literalmente que um 308 é “Equivalent to 301.” (tradução) «Equivalente a 301.» Ambos são redirecionamentos permanentes e ambos passam os sinais de ranking de uma página para a nova URL da mesma forma. O Bing também os trata da mesma maneira. Não há bônus de ranking por usar 308 nem penalidade — a escolha entre eles diz respeito ao comportamento técnico acima, não aos rankings de busca. Evidence for this claim Google treats 308 as equivalent to 301 for Search and groups both as permanent redirects. Scope: Google Search processing; the two status codes remain semantically different for HTTP clients. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search Google: Redirects and Google Search

Então, quando você deve usar um?

Para uma página normal que mudou — uma nova URL, uma mudança de http para https, uma alteração de domínio — um 301 simples é a escolha fácil e universal. Todo navegador, plugin e ferramenta de hospedagem o entende.

Use um 308 especificamente quando aquilo que você está redirecionando não for uma página comum:

• Uma API chamada por outro software.
• Um formulário ou login que envia dados.
• Um webhook — uma URL automatizada para a qual outro serviço envia POST.

Nesses casos, você não pode permitir que a solicitação seja silenciosamente rebaixada e os dados descartados, e um 308 garante que isso não aconteça.

Quer a história da especificação, as citações exatas do Google e do Bing e trechos de servidor para copiar e colar? Mude para a aba Avançado.

TL;DR — 308 é o redirecionamento permanente que preserva estritamente o método: o mesmo sinal de canonicalização do 301 (a documentação do Google diz “Equivalent to 301”), mas com a garantia de que o cliente não alterará o método na nova URL — e, como um cliente compatível repete a mesma solicitação em vez de criar uma nova, o corpo segue junto. Ele existe porque o HTTP teve um código temporário que preservava o método (307) anos antes de ter um permanente — a RFC 7538 (2015) preencheu essa lacuna, e a RFC 9110 agora aponta diretamente para 308 na própria definição de 301. Para SEO, os dois são intercambiáveis (Illyes: o Google “merges” (tradução) «mescla» 308 com 301; Canel, do Bing, confirma a paridade). Escolha 308 quando uma solicitação não-GET precisar sobreviver: migrações de API/versão, URLs de webhook e fluxos POST de autenticação/formulário — mas verifique a preservação de método e corpo no seu próprio cliente, em vez de presumir isso apenas pela especificação. Fora disso, 301 continua sendo o padrão — o suporte dos navegadores ao 308 é forte em 2026 (o caniuse registra atualmente cerca de 96,5%+), mas a própria RFC 9110 ainda sinaliza que 308 é mais novo e não é reconhecido universalmente, e alguns plugins de CMS, UIs de regras de edge e proxies antigos ainda só expõem 301/302/307.

O que 308 significa, mecanicamente

Um Permanent Redirect 308 carrega a mesma mensagem de um 301 — este recurso agora fica permanentemente em uma nova URL — com uma adição que o 301 nunca garantiu: o cliente não deve alterar o método da solicitação no destino. Como o cliente repete a mesma solicitação em vez de emitir uma nova, o corpo segue junto em um cliente compatível com a especificação — isso é uma consequência da garantia do método, não uma promessa certificada separadamente; portanto, verifique de ponta a ponta para seu próprio cliente e servidor em vez de assumir sem ressalvas. A MDN descreve 308 como o código que mantém inalterados o método (e, na prática, o corpo) da solicitação durante o redirecionamento, enquanto um 301 pode não fazer isso.

A versão em linguagem simples que uso no guia de redirecionamentos da Ahrefs: “A 308 redirect is the same as a 301 redirect, except it retains the HTTP method of the original request, GET or POST, when performing the redirect.” (tradução) «Um redirecionamento 308 é igual a um redirecionamento 301, exceto por manter o método HTTP da solicitação original, GET ou POST, ao realizar o redirecionamento.» Ou, ainda mais curto, no guia de códigos de status HTTP: “308 Permanent Redirect – Has the same functionality as a 301 redirect, except you can’t switch between POST and GET.” (tradução) «308 Permanent Redirect — tem a mesma funcionalidade de um redirecionamento 301, exceto que não permite alternar entre POST e GET.» Evidence for this claim RFC 7538 defines 308 Permanent Redirect as a permanent move whose redirect follow-up must not change the request method. Scope: HTTP semantics for 308 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 7538 §3 — 308 Permanent Redirect

Veja a diferença na prática. Imagine que um cliente envie POST de um pedido para /api/orders com um corpo JSON:

POST /api/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{ "sku": "A-100", "qty": 2 }

Se esse endpoint responder com 301 e o cliente respeitar a permissão histórica “você pode mudar para GET”, a solicitação pode chegar à nova URL como um GET vazio — o corpo desaparece e o pedido se perde. Responda com 308 e o cliente deve repetir o POST na nova URL; um cliente compatível carrega o corpo junto, então o pedido é processado — confirme isso nos logs do seu próprio cliente e servidor (veja a aba Scripts) em vez de presumir que funcione universalmente. Essa é toda a distinção prática: ela só aparece quando a solicitação original não era um GET simples.

Por que 308 existe — a história da especificação

Esta é a parte que a maioria das explicações deixa de fora e a forma mais clara de entender o código.

307 veio primeiro. O HTTP já tinha um redirecionamento temporário que preservava o método — o 307 — muito antes de ter um equivalente permanente. A especificação central original (RFC 7231) nunca definiu um equivalente permanente do 307. Assim, havia um código temporário “mantenha o método” e um código permanente “você pode mudar o método” (301), mas nenhum código permanente “mantenha o método”.

A RFC 7538 preencheu a lacuna. 308 foi adicionado especificamente para ser o 307 permanente que faltava — primeiro como a RFC 7238 experimental (junho de 2014), depois padronizado como a RFC 7538 (abril de 2015). É um encaixe para uma lacuna real, não um substituto do 301.

A especificação atual aponta diretamente para ele. A RFC 9110, especificação atual de semântica HTTP, ainda documenta a ambiguidade incorporada ao 301 — e então nomeia 308 como a correção dentro da própria definição de 301: um agente de usuário “MAY change the request method from POST to GET for the subsequent request… If this behavior is undesired, the 308 (Permanent Redirect) status code can be used instead.” (tradução) «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 308 (Permanent Redirect) pode ser usado.» Essa única frase é a razão inteira de 308 existir, diretamente da especificação oficial. E, em sua própria seção sobre 308, a RFC 9110 acrescenta a ressalva honesta: esse código “is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.” (tradução) «é muito mais novo (junho de 2014) que seus códigos irmãos e, portanto, pode não ser reconhecido em todos os lugares.»

O comportamento POST-para-GET do 301 não é um bug — é uma permissão documentada “por razões históricas” incorporada à especificação, e 308 é a forma oficialmente aprovada de não aceitá-la.

301 versus 308 — a diferença prática em uma tabela

A conclusão: para a grande maioria dos redirecionamentos — que são GETs simples — 301 e 308 fazem exatamente a mesma coisa. A garantia só se justifica quando um método não-GET com corpo está envolvido. (Para a comparação completa, veja o artigo dedicado a 301 versus 308.)

O Google trata 308 da mesma forma que 301 para SEO?

Sim, sem ambiguidade, e isso está documentado. A documentação de códigos de status HTTP do Google lista 301 como um redirecionamento que o Google “use[s]… as a strong signal that the redirect target should be processed,” (tradução) «usa como um sinal forte de que o destino deve ser processado» e lista 308 simplesmente como “Equivalent to 301.” (tradução) «Equivalente a 301.» Ela acrescenta uma ressalva sensata: “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 são semanticamente diferentes. Use o código apropriado para o redirecionamento para que outros clientes possam se beneficiar dele.» Em termos simples: o Google não vai penalizar você por usar o código “errado”, mas você ainda deve usar o que é correto para a solicitação, pois outros softwares dependem da distinção.

A documentação de redirecionamentos do Google coloca os dois códigos na mesma categoria recomendada: “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (tradução) «Os códigos de status 301 e 308 significam que uma página mudou permanentemente para um novo local.» E a orientação de mudança de site cita 308 explicitamente, em vez de tratá-lo como uma nota secundária do 301 — a recomendação é usar redirecionamentos HTTP permanentes “such as 301 and 308” (tradução) «como 301 e 308» ao fazer uma mudança permanente.

Vale saber: essa paridade nem sempre foi documentada. Gary Illyes disse que o Google mescla 308 com 301 internamente, e a cobertura do Search Engine Roundtable apresenta o momento em que isso entrou na documentação oficial como o ponto em que uma observação informal finalmente se tornou algo em que você podia confiar — os proprietários que perguntavam “isso está realmente documentado?” alguns anos atrás tinham razão em ser cautelosos, embora o comportamento subjacente nunca tenha mudado. Se quiser a formulação exata do Google e de seus representantes, a aba Citações contém as citações verificadas e os links profundos.

O Bing trata 308 da mesma forma que 301?

Sim. O Bing não tem uma página de documentação dedicada explicando 308 como o Google tem, mas Fabrice Canel, da Microsoft, confirmou isso diretamente no X em setembro de 2024, conforme relatado pelo Search Engine Roundtable: o Bing trata redirecionamentos 308 da mesma forma que redirecionamentos 301. Essa é a declaração autoritativa do Bing — veja a aba Citações para a frase literal.

Quando realmente usar um 308

É aqui que está o caso independente para 308 — e quase sempre é uma solicitação não-GET.

Endpoint de API e migrações de versão. Mover /v1/ para /v2/, ou realocar um host de API, é o caso clássico. Clientes acessam esses endpoints com POST/PUT/PATCH/DELETE e corpos reais. Um 308 garante que o método e a carga útil sobrevivam ao salto; um 301 arrisca um rebaixamento silencioso que deixa a solicitação perdida.

Migrações de site com muitos POSTs. Fluxos de checkout, endpoints de login/autenticação e destinos de ações de formulário enviam dados POST. Se qualquer uma dessas URLs mudar durante uma migração, 308 mantém o envio intacto onde 301 talvez não consiga.

Mudanças de URL de webhook. Quando outro serviço envia POST para uma URL de webhook que você está realocando, 308 diz ao cliente HTTP para reenviar o POST ao novo endereço com o corpo intacto — exatamente o que um consumidor de webhook precisa.

O ponto em comum: use 308 sempre que perder o corpo ou deixar o método cair silenciosamente para GET quebrar a funcionalidade, não apenas alterar um pouco de valor de SEO.

Antes de mudar qualquer um desses caminhos, teste como uma integração, não apenas como um código de status:

• Repita o método e a carga útil reais contra uma cópia de staging do novo endpoint.
• Confirme se cabeçalhos de autorização ou cookies devem ser transportados e verifique se realmente são.
• Se a solicitação original não for idempotente (um POST que cria um pedido, por exemplo), observe possíveis efeitos duplicados durante o salto do redirecionamento.
• Confirme que a query string e o cabeçalho Content-Type sobrevivem, não apenas o corpo.
• Verifique se o cliente real — o remetente do webhook, o SDK da API ou o navegador — segue automaticamente um 308 antes de aposentar o endpoint antigo. Nem todo cliente HTTP faz isso por padrão.

Quando 301 ainda é o padrão pragmático

Para tudo que seja um GET simples, 301 continua sendo o padrão sensato:

• Mudanças comuns de conteúdo/URL de página.
• Migrações de HTTP → HTTPS.
• Mudanças de domínio e migrações comuns de site.
• Normalização de barra final e de www/sem www.

Aqui a solicitação é um GET simples, então a garantia do 308 não oferece nada — e 301 vence pela universalidade. Não há custo de SEO em nenhum dos dois. Não migre em massa 301s existentes para 308s em busca de aumento de rankings; esse benefício não existe. Observe que, na hierarquia de preferência de redirecionamentos do guia da Ahrefs, 308 e 301 ficam juntos no nível mais alto (à frente de meta refresh, JavaScript e outras soluções alternativas) — são pares, não degraus.

Ressalvas de adoção e suporte — qual é o risco real em 2026

O suporte dos navegadores não é o risco prático de antes. Segundo o acompanhamento atual do caniuse, 308 tem cerca de 96,5%+ de suporte global — consulte a tabela ativa para o número de hoje, pois ele muda — e as lacunas visíveis se concentram em navegadores mortos há anos: anteriores ao IE11, Chrome/Firefox/Safari antigos e Android Browser antigo. Se você ainda vê circulando o alerta antigo “IE11 falha com 308”, ele está desatualizado para tráfego mainstream.

As ferramentas são a ressalva mais atual. A lacuna honesta de 2026 é que nem toda camada expõe uma opção 308. Alguns plugins de redirecionamento de CMS, algumas UIs de regras de redirecionamento de CDN/edge e alguns proxies reversos ou balanceadores antigos ainda só deixam escolher 301/302/307. Antes de se comprometer com 308, verifique se a camada que realmente serve o redirecionamento pode emiti-lo, em vez de rebaixá-lo silenciosamente — a aba Scripts tem uma linha única para confirmar o código real na rede. A observação da RFC 9110 sobre ser “much younger… might not be recognized everywhere” (tradução) «muito mais novo… pode não ser reconhecido em todos os lugares» não se limita a navegadores — é a cautela geral da especificação para implantação de 308. Em 2026, o impacto prático dessa cautela aparece sobretudo nas ferramentas, não nos navegadores mainstream, mas vale lê-la como a ressalva de base da especificação, não como algo completamente aposentado.

Uma nota de rodapé não padrão: “308 Resume Incomplete”

Uma peculiaridade que reforça como esse código ainda é novo: 308 não é somente um código de redirecionamento no mundo real. A API de upload do Google Drive reutiliza 308 com um significado completamente diferente — “Resume Incomplete”, sinalizando que um upload em partes parou e que o cliente deve retomá-lo. John Mueller destacou isso (veja a aba Citações) e a MDN documenta o mesmo uso não padrão. Isso não muda nada sobre 308 como redirecionamento, mas é uma ilustração interessante de que 308 é um código de status mais novo e menos “assentado” culturalmente que o venerável 301.

Cadeias e saltos de redirecionamento funcionam da mesma forma

Nada acima muda o funcionamento das cadeias de redirecionamento. Por padrão, os rastreadores do Google seguem até 10 saltos — mas isso é um padrão, não uma constante universal; a documentação do próprio Google observa que produtos específicos podem ser diferentes (a ferramenta de Inspeção de URL, por exemplo, não segue redirecionamentos), portanto verifique o número atual na documentação do Google em vez de tratar 10 como fixo para sempre. Esse limite padrão é idêntico quando os saltos são 301 ou 308. Se você estiver empilhando redirecionamentos (por exemplo, um caminho de API antigo que salta duas vezes antes de chegar ao destino), aplique a mesma higiene de cadeias e loops — reduza a cadeia a um único salto quando puder. Veja o artigo dedicado a cadeias de redirecionamento para a mecânica.

Resumo de IA

Uma versão condensada da versão Advanced:

• 308 = permanente + preservação estrita do método. A mesma mensagem “movido permanentemente” de um 301, mais uma garantia que o 301 nunca ofereceu: o cliente não deve alterar o método na nova URL. Um cliente compatível repete a mesma solicitação, então o corpo segue junto — verifique isso de ponta a ponta no seu cliente, em vez de presumir apenas pela especificação.
• Equivalente a 301 para SEO. A documentação do Google diz que 308 é “Equivalent to 301”; Gary Illyes diz que o Google mescla 308 com 301; Fabrice Canel confirma que o Bing os trata da mesma maneira. Não há benefício nem penalidade de ranking. (Atribuição: as declarações de Illyes/Mueller/Canel são relatadas pelo Search Engine Roundtable — confirme as fontes originais antes de tratá-las como finais.)
• Por que existe: o HTTP tinha um redirecionamento temporário que preservava o método (307) anos antes de ter um permanente. A RFC 7538 (2015) preencheu a lacuna. A RFC 9110 aponta para 308 em sua própria definição de 301: um 301 “MAY change the request method from POST to GET… for historical reasons” (tradução) «PODE mudar o método da solicitação de POST para GET… por razões históricas» e “if this behavior is undesired, the 308… can be used instead” (tradução) «se esse comportamento for indesejado, 308 pode ser usado».
• Use 308 para: migrações de API/versão, mudanças de URL de webhook e fluxos POST de formulário/autenticação — qualquer lugar em que perder método/corpo quebraria a funcionalidade. Antes de mudar, repita o método e a carga útil reais em staging e confirme cabeçalhos de autenticação, idempotência e o comportamento do cliente real ao seguir redirecionamentos.
• Use 301 para: mudanças comuns de página, HTTP→HTTPS, alterações de domínio e normalização — todos GETs simples, em que a garantia do 308 não traz benefício e 301 vence pelo suporte universal.
• Adoção: o suporte dos navegadores é forte (o caniuse registra atualmente cerca de 96,5%+, com lacunas sobretudo em navegadores mortos há muito tempo), mas a RFC 9110 ainda traz a ressalva geral de que 308 é “younger, might not be recognized everywhere” (tradução) «mais novo, pode não ser reconhecido em todos os lugares» — em 2026, isso aparece principalmente como lacuna de ferramentas (alguns plugins de CMS, UIs de CDN/edge e proxies antigos expõem apenas 301/302/307). Verifique se a camada de redirecionamento pode realmente emitir 308 e observe que 308 pode ser armazenado heuristicamente, portanto um 308 errado ou revertido pode permanecer nos caches.
• Nota: o Google Drive reutiliza “308 Resume Incomplete” para uploads interrompidos — um uso que não é redirecionamento e mostra como o código ainda é novo.

Documentação oficial

Documentação de fontes primárias sobre 308 pelos mecanismos de busca e pela especificação HTTP.

Google

• Códigos de status HTTP, erros de rede e DNS e a Pesquisa Google — lista 308 como “Equivalent to 301”, a ressalva de que são semanticamente diferentes mas tratados da mesma forma e o limite de 10 saltos.
• Redirecionamentos e a Pesquisa Google — “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (tradução) «Os códigos de status 301 e 308 significam que uma página mudou permanentemente para um novo local.»
• Mudanças de site com alterações de URL — recomenda redirecionamentos HTTP permanentes “such as 301 and 308” (tradução) «como 301 e 308» para uma mudança permanente.

Especificação HTTP

• RFC 9110 — Semântica HTTP — a especificação atual. A seção §15.4.9 define 308 (e a ressalva de ser “much younger… might not be recognized everywhere” (tradução) «muito mais novo… pode não ser reconhecido em todos os lugares»); a §15.4.2 define 301 e aponta para 308 como correção da conversão indesejada de POST para GET.
• RFC 7538 — Código de status HTTP 308 (Redirecionamento permanente) — o padrão que introduziu 308 (abril de 2015), substituindo a RFC 7238 experimental (junho de 2014).

Referência

• MDN — 308 Permanent Redirect — semântica de preservação de método/corpo e o uso não padrão do Google Drive “Resume Incomplete”.
• caniuse — HTTP status code 308 — a tabela de suporte dos navegadores (cerca de 96,5%+ global).

Citações da fonte

Declarações registradas do Google, do Bing e da especificação HTTP. Cada link aponta diretamente para o trecho citado na página de origem.

Google — a equivalência central

• “301 (moved permanently): Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (tradução) «301 (movido permanentemente): o Google segue o redirecionamento, e os sistemas do Google usam o redirecionamento como um sinal forte de que o destino deve ser processado.» — Documentação do Google Search Central. Ir para a citação
• “308 (moved permanently): Equivalent to 301.” (tradução) «308 (movido permanentemente): Equivalente a 301.» 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 são semanticamente diferentes. Use o código apropriado para o redirecionamento para que outros clientes possam se beneficiar dele.» Ir para a citação
• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (tradução) «Os códigos de status 301 e 308 significam que uma página mudou permanentemente para um novo local.» Ir para a citação

Gary Illyes, Google

• Sobre como o Google trata 308: “we just merge that with 301 so we really don’t care iirc.” (tradução) «nós simplesmente mesclamos isso com 301, então realmente não nos importamos, se me lembro corretamente.» Relatado pela cobertura literal do Search Engine Roundtable, O Google trata oficialmente redirecionamentos 308 como 301 (julho de 2021) — confirme com a fonte original antes de tratar isso como final.

John Mueller, Google

• Sobre o uso não padrão: “Google Drive uses a 308 redirect as a Resume Incomplete response to indicate to the client when an incomplete upload stalled. So that is a bit different. But you can use it as a normal redirect.” (tradução) «O Google Drive usa um redirecionamento 308 como resposta Resume Incomplete para indicar ao cliente quando um upload incompleto parou. Portanto, isso é um pouco diferente. Mas você pode usá-lo como um redirecionamento normal.» Relatado pelo Search Engine Roundtable, O Google pode tratar redirecionamentos 308 como 301 (maio de 2018) — confirme com a fonte original antes de tratar isso como final.

Fabrice Canel, Microsoft Bing

• “I accidentally deleted my reply, so confirming again: Bing treats 308 redirects the same as 301 redirects.” (tradução) «Apaguei acidentalmente minha resposta, então confirmo novamente: o Bing trata os redirecionamentos 308 da mesma forma que os redirecionamentos 301.» Fabrice Canel no X (setembro de 2024), relatado pelo Search Engine Roundtable, O Bing trata redirecionamentos 308 da mesma forma que 301 — confirme com a fonte original antes de tratar isso como final.

RFC 9110 — a especificação de semântica HTTP

• Sobre por que 308 existe, na própria definição de 301 da especificaçã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 308 (Permanent 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 308 (Permanent Redirect) pode ser usado.» Leia a RFC 9110
• Sobre adoção: 308 “is much younger (June 2014) than its sibling codes and thus might not be recognized everywhere.” (tradução) «é muito mais novo (junho de 2014) que seus códigos irmãos e, portanto, pode não ser reconhecido em todos os lugares.» Leia a RFC 9110

Este redirecionamento deve ser um 308?

Como 301 e 308 são equivalentes para SEO, esta não é uma decisão de rankings — tudo se resume a uma pergunta: há uma solicitação não-GET com corpo envolvida e sua camada de redirecionamento realmente consegue emitir 308? Vamos percorrer o caso.

A versão curta: GET simples → 301; solicitação não-GET que você precisa preservar (e sua stack consegue emitir) → 308. Para SEO, os dois são intercambiáveis; portanto, a pergunta sobre o método — mais uma verificação rápida de “minha ferramenta realmente consegue fazer isso?” — é a única coisa que decide.

Mitos e erros sobre 308

Extraídos diretamente dos modos de falha que vejo com mais frequência.

“308 is better for SEO than 301.” (tradução) «308 é melhor para SEO que 301.» Falso. A documentação do Google diz “Equivalent to 301”, e Illyes, Mueller e Canel, do Bing, confirmam a paridade. Nenhum mecanismo trata 308 como superior para SEO. Escolhê-lo diz respeito à correção de método/corpo, nunca a uma vantagem de ranking.

“You should migrate all your existing 301s to 308s.” (tradução) «Você deve migrar todos os seus 301s existentes para 308s.» Pura mudança sem benefício de ranking. Se as solicitações redirecionadas forem GETs simples — a grande maioria dos redirecionamentos de página para página —, um 301 já se comporta de forma idêntica na prática. Reserve a troca para redirecionamentos que realmente carreguem métodos não-GET.

“308 isn’t safe because it’s newer.” (tradução) «308 não é seguro porque é mais novo.» Exagero especificamente para navegadores: a RFC 7538 tem mais de uma década, Google e Bing confirmam suporte no nível do mecanismo, e o caniuse mostra atualmente cerca de 96,5%+ de suporte de navegador, com lacunas sobretudo em versões mortas há muito tempo. A RFC 9110 ainda traz uma ressalva geral de “mais novo, pode não ser reconhecido em todos os lugares” para 308 — em 2026, isso aparece principalmente como lacuna de ferramentas (nem todo plugin de CMS, UI de regras de CDN ou proxy antigo expõe uma opção 308), não como lacuna de cliente ou mecanismo de busca, mas não é uma ressalva completamente aposentada.

“A 301 will always mangle my POST/API request.” (tradução) «Um 301 sempre deformará minha solicitação POST/API.» Exagero. Muitos clientes modernos preservam o comportamento razoavelmente bem; o risco real documentado na especificação é a conversão específica de POST para GET que a RFC 9110 permite “for historical reasons” (tradução) «por razões históricas», quando um cliente respeita essa permissão legada. 308 elimina esse risco — ele não corrige uma falha universal e garantida.

“308 is only ever a redirect code.” (tradução) «308 é sempre apenas um código de redirecionamento.» Não exatamente. O uso não padrão do Google Drive, “308 Resume Incomplete”, reutiliza o código para um upload interrompido — um significado completamente diferente. É um bom lembrete de que o uso real de 308 é mais novo e menos consolidado que o de 301.

Contraste adicional — “permanent redirects lose PageRank.” (tradução) «Redirecionamentos permanentes perdem PageRank.» Não é o tema central deste artigo, mas vale uma frase: a orientação do próprio Google agrupa 301 e 308 como redirecionamentos permanentes usados como sinal para processar a nova URL como destino de referência — isso indica continuidade, não uma perda de valor. Trate isso como comportamento de processamento documentado pelo Google, não como uma garantia ampla de que “nenhum PageRank jamais é perdido”; a formulação mais estreita sobre o sinal de referência é a que a fonte atual realmente sustenta.

Confirmar e implementar um 308

A coisa mais útil que você pode fazer com 308 é verificar o código de status real na rede — porque a falha mais comum não é um problema de navegador, mas uma camada de ferramentas rebaixando silenciosamente seu 308 pretendido para 301 (ou não emitindo redirecionamento algum).

Verifique o código de status com curl

# Show only the response headers; -I sends a HEAD request.
curl -sI https://example.com/old-path | head -n 1
# → HTTP/1.1 308 Permanent Redirect     (what you want)
# → HTTP/1.1 301 Moved Permanently      (your layer downgraded it)

Para confirmar que o método é realmente preservado em um POST (o objetivo de um 308), siga o redirecionamento com -L e observe o que chega — -X POST junto com --data só continuará sendo POST durante o salto se o servidor tiver retornado 308/307:

curl -sIL -X POST --data '{"sku":"A-100"}' \
  -H 'Content-Type: application/json' \
  https://api.example.com/v1/orders
# Inspect each hop's request line; a 308 keeps it "POST", a 301 may show "GET".

Rastreie uma cadeia inteira

Se o caminho saltar mais de uma vez, imprima cada código de status da cadeia para detectar um rebaixamento ou um salto extra não intencional:

curl -sIL https://example.com/old-path \
  | grep -iE '^HTTP/'
# Each line is one hop. Collapse chains to a single hop where you can.

Verifique se um 308 está em cache antes de revertê-lo

A RFC 9110 torna 308 armazenável heuristicamente — um cliente ou intermediário pode decidir armazená-lo mesmo sem um cabeçalho Cache-Control explícito. Isso significa que um 308 errado (ou um que você precise reverter) pode continuar sendo servido pelo cache muito depois de você corrigir a regra na origem. Antes de concluir que um redirecionamento está “preso”:

• Teste com um cliente novo (privado/anônimo, sem visita anterior) e com um que já acessou a URL antiga — clientes com e sem cache podem se comportar de forma diferente.
• Verifique na resposta os cabeçalhos Cache-Control, Expires e Age com curl -sI.
• Teste separadamente um GET simples e uma solicitação não-GET representativa; o comportamento de cache pode variar conforme o método.
• Se precisar reverter um 308, elimine explicitamente o cache da edge/CDN — não presuma que remover a regra da origem basta e espere que alguns clientes que já armazenaram o redirecionamento antigo não façam nova solicitação por conta própria.

Console do Chrome DevTools — verificar um redirecionamento no navegador

Cole no Console do DevTools (F12 → Console) para ver a URL final e o status sem sair da página. Um fetch com redirecionamento manual informa diretamente o status da primeira resposta:

// Reports the status of the first response (the redirect itself), not the target.
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'manual' })
  .then(r => console.log('type:', r.type, 'status:', r.status || '(opaqueredirect)'));

// Follow the chain and log where it lands:
fetch('https://example.com/old-path', { method: 'HEAD', redirect: 'follow' })
  .then(r => console.log('final URL:', r.url, 'final status:', r.status));

Bookmarklet — “o que esta URL retorna?” com um clique

Arraste um favorito com isto como URL e clique nele em qualquer página para pedir uma URL e alertar o status final e a URL de destino:

javascript:(function(){var u=prompt('URL to check:',location.href);if(!u)return;fetch(u,{method:'HEAD',redirect:'follow'}).then(function(r){alert('Final status: '+r.status+'\nLanded on: '+r.url);}).catch(function(e){alert('Error: '+e);});})();

Implementar um 308 no servidor

Apache (.htaccess) — mod_rewrite com um R=308 explícito:

RewriteEngine On
RewriteRule ^old-path/?$ /new-path [R=308,L]

nginx — return 308 é exato e inequívoco:

location = /old-path {
    return 308 https://example.com/new-path;
}

Express.js (Node) — passe o código de status para redirect():

app.all('/api/v1/orders', (req, res) => {
  // 308 keeps the POST body intact on the way to /api/v2/orders
  res.redirect(308, '/api/v2/orders');
});

Next.js — defina permanent: true e ele emitirá 308 (os redirecionamentos permanentes do Next são 308):

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/api/v1/:path*', destination: '/api/v2/:path*', permanent: true },
    ];
  },
};

O comportamento de frameworks e camadas de hospedagem não é fixo entre versões. O próprio tratamento de redirecionamento do Next.js, por exemplo, pode variar conforme a versão e o local em que o redirecionamento é acionado — uma entrada redirects() em next.config.js, uma chamada permanentRedirect() em uma Server Action ou uma resposta de streaming não necessariamente resulta no mesmo código de status. A mesma cautela vale para versões de módulos Apache/nginx e qualquer camada de CDN ou proxy diante da origem. Trate cada trecho acima como ponto de partida, não como garantia, e confirme a documentação atual da sua própria versão.

Depois de implantar qualquer uma dessas opções, execute novamente a verificação curl -sI acima para confirmar que a rede realmente carrega um 308 — essa é a etapa de verificação que as pessoas pulam e acabam lamentando.

Ferramentas para confirmar um 308 na rede

Minhas ferramentas gratuitas

• Redirect Checker — rastreie uma URL ou um lote rápido e confirme que a primeira resposta é 308, que o destino está correto e que a cadeia termina em uma resposta final saudável.
• Bulk HTTP Status Code Checker — verifique até 500 URLs migradas, filtre respostas 301/302/307 inesperadas e exporte cadeias ou loops para remediação.

Prove o comportamento estrito quando isso importar

• curl com uma carga de teste segura — repita o método real contra um endpoint de staging ou não destrutivo e siga o redirecionamento. Confirme que a origem emite 308.
• Logs do aplicativo/gateway de API — verifique se o destino recebeu o mesmo método, tipo de conteúdo e corpo. Um verificador de redirecionamentos prova status e destino; os logs de recebimento provam que a preservação do método funcionou de ponta a ponta.
• Painel Network do DevTools do navegador — útil para fluxos de formulário e autenticação, mas teste separadamente clientes de webhook e API, pois a interoperabilidade é a razão para escolher 308 em vez de 301.
• Inspeção de URL do Google Search Console — para URLs de página indexáveis, confirme que a mudança permanente é processada como 301 e que o destino é o canônico selecionado.

Teste seus conhecimentos: 308 Permanent Redirect

Cinco perguntas rápidas sobre o que é 308, por que ele existe e como os mecanismos de busca o tratam. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Minha produção

• 11 tipos de redirecionamento e seu impacto em SEO (com Joshua Hardwick) — minha definição de 308, a formulação “para fins de SEO eles são iguais, mas formulários” e a hierarquia de preferência em que 308 e 301 compartilham o nível mais alto.
• Códigos de status HTTP e seu impacto em SEO — onde digo de forma direta que 308 “has the same functionality as a 301… except you can’t switch between POST and GET” (tradução) «tem a mesma funcionalidade que um 301… exceto que não permite alternar entre POST e GET» e que 308s “are treated the same as 301s and consolidate forward” (tradução) «são tratados da mesma forma que 301s e consolidam para frente».
• Uma migração de site exige mais do que um checklist para ter sucesso — por que escolho 301 ou 308 (não 302/307) em uma mudança permanente.
• Guia de SEO técnico para iniciantes — onde os redirecionamentos se encaixam no panorama maior.

Da indústria

• Redirecionamentos e a Pesquisa Google — o guia oficial de redirecionamentos do Google, que cita 301 e 308 juntos como opções permanentes.
• Códigos de status HTTP, erros de rede e DNS e a Pesquisa Google — a documentação que chama 308 de “Equivalent to 301” (tradução) «Equivalente a 301», com a ressalva de serem semanticamente diferentes.
• RFC 9110 — Semântica HTTP — a especificação atual; sua definição de 301 aponta para 308 como correção da conversão indesejada de POST para GET.
• RFC 7538 — Código de status HTTP 308 (Redirecionamento permanente) — o padrão que introduziu 308.
• MDN — Redirecionamento permanente 308 — semântica de método/corpo e a observação sobre “Resume Incomplete” do Google Drive.
• caniuse — código de status HTTP 308 — a tabela de suporte de navegadores que desmente o mito de que 308 é frágil.
• O Bing trata redirecionamentos 308 da mesma forma que 301 (Search Engine Roundtable) — a confirmação de 2024 de Fabrice Canel para o Bing.
• O Google trata oficialmente redirecionamentos 308 como 301 (Search Engine Roundtable) — o contexto da frase de Gary Illyes “we just merge that with 301” (tradução) «nós simplesmente mesclamos isso com 301» e o momento em que a documentação se tornou oficial.

Registro de alterações