Redirecionamento 301

TL;DR — Um redirecionamento 301 envia permanentemente qualquer pessoa (ou bot) que visita uma URL antiga para uma nova. É a ferramenta certa quando uma página muda de vez — novo domínio, nova URL, HTTP para HTTPS ou união de duas páginas. Configure-o no servidor, aponte cada URL antiga para seu substituto real (não apenas para a página inicial) e mantenha-o ativo. O Google diz que um 301 não custa valor de ranking, então não há motivo para medo.

O que é um redirecionamento 301

Quando um navegador ou mecanismo de busca solicita uma página, seu servidor responde com um código de status HTTP de três dígitos. 200 significa “aqui está a página”. 404 significa “não encontrado”. Um 301 significa “Moved Permanently” — esta URL tem uma nova casa; vá para lá.

Assim, um redirecionamento 301 é seu servidor dizendo a todos: o recurso que você pediu agora está em outro endereço, e isso é permanente. Os visitantes são enviados automaticamente para a nova página e os mecanismos de busca atualizam seus registros para apontar para a nova URL.

Quando usar um

Use um 301 sempre que o endereço de uma página estiver mudando de forma permanente:

• Você mudou uma URL — renomeou uma página, reestruturou o site ou limpou uma URL confusa.
• Mudou para um novo domínio — em um rebranding ou migração de site.
• Trocou para HTTPS — toda URL http:// deve redirecionar por 301 para sua equivalente https://.
• Uniu páginas — dois artigos semelhantes viraram um; redirecione os antigos para o sobrevivente.
• Aposentou uma página com substituto claro — envie-a para o equivalente mais próximo, não para um beco sem saída.

A recomendação do próprio Google é: “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (tradução) «Se você precisa mudar a URL de uma página como ela aparece nos resultados do mecanismo de busca, recomendamos usar um redirecionamento permanente no servidor sempre que possível.»

O único número que você deve ignorar

Você ouvirá que um 301 “perde 10–15% do link juice”. Esse é um mito antigo. O Google é direto: “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank.» Portanto, não evite redirecionar uma página por medo de “vazar” valor — um 301 correto entrega ao destino os sinais que a URL antiga conquistou.

Você também verá afirmações confiantes de que um 301 “passa 90–99% do link equity”. Ignore-as: o Google não publica nenhuma porcentagem desse tipo, e o número é inventado.

Três coisas para acertar

1. Aponte cada URL antiga para seu substituto real — não para a página inicial. Se você despejar todas as páginas aposentadas na home, o Google pode tratá-las como erros (um “soft 404”) e não passar o valor. Faça o mapeamento antigo → novo um a um.
2. Use um 301 real, não um falso. Um redirecionamento feito apenas em JavaScript ou um link “clique aqui se não for redirecionado” não é a mesma coisa — o Google pode nem vê-lo. Faça-o no servidor.
3. Mantenha-o ativo. O Google recomenda manter os redirecionamentos geralmente por pelo menos um ano para que todos os sinais tenham tempo de ser transferidos. Honestamente, se puder, mantenha-os para sempre.

E um 302?

Um 302 é a versão temporária — “esta página mudou por enquanto, mas a original continua sendo a verdadeira”. Se você usar 302 quando queria 301, o Google pode manter a URL antiga nos resultados em vez da nova. Quando a mudança for permanente, use 301. (Há uma comparação completa entre 301 e 302 para ler separadamente.)

Quer as configurações de servidor, os detalhes de tempo, as regras de cadeias de redirecionamento e como detectar um 301 “falso” que falha silenciosamente? Mude para a aba Avançado.

TL;DR — Um 301 (HTTP “301 Moved Permanently”) é uma resposta do servidor que move uma URL permanentemente e é o sinal mais forte para consolidar ranking no destino. O Google é explícito: redirecionamentos permanentes não causam perda de PageRank — a regra de “perda de ~15% por salto” morreu e não há porcentagem publicada de equity transferido, então não invente uma. Implemente-o no servidor (Apache, nginx, código da aplicação) ou na borda (Cloudflare), não com JavaScript nem com uma meta refresh atrasada. Redirecione URLs antigas para seu equivalente relevante 1:1 — não tudo para a home, que o Google pode reclassificar como soft 404. Mantenha as cadeias curtas (o Google segue até 10 saltos, mas recomenda ficar abaixo de ~5; Mueller mencionou ~5 por rastreamento). No servidor é instantâneo; a consolidação completa de índice/sinais leva semanas a geralmente pelo menos um ano.

O que um 301 realmente é

Um 301 é um código de status HTTP — “301 Moved Permanently” — retornado pelo servidor (ou pela borda da CDN) nos cabeçalhos da resposta, antes de qualquer corpo de página. Essa é a parte importante: um 301 real acontece no nível do protocolo, na resposta à solicitação. Não é uma função de plugin, uma tag <meta> ou um trecho de JavaScript — essas são alternativas quando você não consegue fazer isso no servidor e se comportam de outra forma (mais sobre isso abaixo).

O Google resume a definição assim: “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.» (308 é o código de redirecionamento permanente mais novo que também preserva o método da solicitação; para SEO, o Google trata 301 e 308 da mesma forma — “use HTTP permanent redirects if possible, such as 301 and 308.” (tradução) «use redirecionamentos permanentes HTTP se possível, como 301 e 308».)

Alguns detalhes de protocolo merecem atenção antes da implementação: uma resposta 301 é armazenável heuristicamente em cache por padrão, então um navegador ou cache intermediário pode guardá-la — por isso um redirecionamento “corrigido” ainda pode enviar testadores ao destino antigo até o cache ser limpo. E como 301 existe desde HTTP/1.0, um user-agent pode trocar uma requisição POST por GET ao segui-lo — não presuma que 301 preserva o método original de um formulário; use 308 se isso importar. O cabeçalho Location só precisa ser uma referência URI (tecnicamente pode ser relativa), embora apontar para uma URL absoluta evite ambiguidades na prática.

Como o Google processa um 301 (canonicalização + indexação)

Um redirecionamento permanente é um dos sinais de canonicalização mais fortes que o Google possui. Quando o Googlebot segue um 301, o pipeline de indexação usa o redirecionamento como sinal de que o destino deve ser a URL canonical. O Google mantém um registro das duas pontas: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (tradução) «Ao redirecionar uma URL, o Google acompanha tanto a origem do redirecionamento (a URL antiga) quanto o destino (a nova URL). Uma das URLs será a canonical… A outra vira um nome alternativo da URL canonical.»

É por isso que às vezes você ainda vê a URL antiga nos resultados por algum tempo após uma mudança — o Google a mantém como um “nome alternativo”. O Google diz para não entrar em pânico: em uma mudança de domínio, “it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.” (tradução) «é muito provável que o Google continue ocasionalmente mostrando as URLs antigas nos resultados, mesmo que as novas já estejam indexadas. Isso é normal… os nomes alternativos desaparecerão sem que você precise fazer nada.»

Um redirecionamento supera sinais de canonicalização mais fracos. Gary Illyes resumiu a hierarquia: um redirecionamento “should be much higher weight… than whether the page is on an http URL or https.” (tradução) «deveria ter um peso muito maior… do que o fato de a página estar em uma URL http ou https». Assim, um 301 perdido pode substituir silenciosamente uma tag canonical ou uma preferência HTTPS que apontem para o outro lado. (Veja o tratamento completo em canonicalização.)

Vale ser preciso sobre o que esse sinal promete e o que não promete: um 301 é um sinal forte de destino canonical, não uma garantia. Ele diz ao Google qual URL deve ser canonical — não garante que essa URL será indexada, ranqueará, receberá tráfego ou que todos os outros sinais (links, qualidade do conteúdo, autoridade do site) serão transferidos automaticamente. Trate “escolha de canonical” e “resultados de indexação, ranking e tráfego” como perguntas separadas; um 301 responde diretamente apenas à primeira.

O mito do PageRank — acerte isto exatamente

Este é o fato mais distorcido sobre 301s, então esta é a versão precisa.

Declaração exata do Google: “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank.» É isso. Não “você mantém 85%”, não “perde 10–15% por salto”. Nenhuma perda.

A regra de “perda de ~15% por salto” vem de declarações antigas, anteriores a 2016, sobre amortecimento do PageRank em redirecionamentos (comumente atribuídas a Matt Cutts). O Google a reverteu publicamente por volta de 2016 — segundo os relatos da época, deixou de aplicar diluição de PageRank em redirecionamentos 30x, e o destino recebe a autoridade.

O corolário que confunde as pessoas na direção oposta é: não diga que um 301 “passa 90–99% do link equity”. O Google não publica esse número. “Não causa perda de PageRank” é uma afirmação direcional, não uma porcentagem — qualquer porcentagem específica que você veja é folclore, não algo confirmado pelo Google. Cite a redação “sem perda”; nunca invente uma cifra.

Acrescento minha própria ressalva. Testei a afirmação de que os “sinais permanecem após um ano” removendo 301s de quatro posts da Ahrefs com muitos links e observando o resultado (Is It OK to Remove 301 Redirects After a Year? We Tested It). Os domínios de referência caíram visivelmente quando os redirecionamentos saíram, e o tráfego orgânico foi misto — um post subiu, um caiu, dois ficaram quase estáveis, com uma aparente “queda” que na verdade precedeu a remoção. Minha conclusão honesta: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” (tradução) «Não estou disposto a dizer conclusivamente que redirecionamentos permanentes passam valor mesmo depois de um ano, mas o que Gary disse parece se manter em grande parte.» Amostra pequena, então faço uma ressalva — mas a conclusão prática é sem graça: não remova seus redirecionamentos.

Tempo — três relógios diferentes

“Quanto tempo leva para um 301 funcionar?” depende de qual relógio você quer dizer:

• O servidor: instantâneo. No momento em que a regra entra no ar, toda solicitação recebe 301 e os usuários chegam à nova URL. Sem espera.
• O índice: dias a semanas. O Google precisa rastrear novamente a URL antiga, ver o redirecionamento e processar o destino. O enquadramento do próprio Google: “a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer” (tradução) «um site pequeno ou médio pode levar algumas semanas para mover a maioria das páginas, e sites maiores levam mais tempo», e “visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (tradução) «a visibilidade do seu conteúdo na Busca pode oscilar temporariamente durante a mudança. Isso é normal.»
• Consolidação completa dos sinais: geralmente pelo menos um ano. O Google diz: “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (tradução) «Mantenha os redirecionamentos o máximo possível, geralmente por pelo menos 1 ano. Esse prazo permite ao Google transferir todos os sinais para as novas URLs… Do ponto de vista dos usuários, considere manter os redirecionamentos indefinidamente.» É o mesmo prazo de um ano citado por Illyes para a passagem completa dos sinais da origem ao destino.

Regra prática: mantenha os 301 no lugar por pelo menos um ano e, na verdade, para sempre se as URLs não custarem nada para você.

Implementando um 301

Faça isso o mais perto do servidor possível. Aqui estão os quatro caminhos que cobrem quase todo mundo. (São exemplos; adapte caminhos/hosts ao seu ambiente, e a aba Scripts tem versões para copiar e colar, além de como testá-las.)

Faça backup da configuração existente de .htaccess ou nginx antes de editá-la — uma regra malformada pode derrubar o site inteiro, não apenas a URL que você está redirecionando.

Apache (.htaccess)

Para uma única URL com mod_alias:

Redirect permanent "/old-page" "https://example.com/new-page"

Para regras baseadas em padrões com mod_rewrite:

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

O WordPress não tem um gerenciador de redirecionamentos integrado, então você adiciona um:

• Plugin Redirection (gratuito) — a escolha mais comum; adicione origem → destino em uma interface, sem código.
• Yoast SEO Premium — seu Redirect Manager pode criar automaticamente um redirecionamento quando você exclui ou muda o slug de uma URL. Atenção: a versão gratuita do Yoast não tem gerenciador de redirecionamentos (muitos tutoriais omitem isso).
• Nível do servidor — se você pode editar .htaccess/nginx diretamente, uma regra do servidor é mais rápida que um plugin em PHP, que roda a cada solicitação.

Cloudflare

No Cloudflare, você pode redirecionar na borda, antes que a solicitação chegue à origem:

• Single Redirects — regras individuais no painel.
• Bulk Redirects — uma lista de redirecionamentos (milhares de pares origem → destino) aplicada à conta inteira. É realmente útil em uma migração completa, pois não exige tocar na configuração da origem — especialmente prático quando o servidor antigo será desativado.

Código da aplicação (exemplo em PHP)

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

301s “falsos” — o modo de falha que ninguém verifica

Vale internalizar este ponto contraintuitivo: uma URL pode retornar 200 OK e ainda estar redirecionando. Como escrevi em 11 tipos de redirecionamentos e seu impacto em SEO, “A redirect can still be happening with any status code. You may have a page that shows as a 200 OK status code, but still actually be redirecting” (tradução) «Um redirecionamento ainda pode estar acontecendo com qualquer código de status. Uma página pode aparecer com status 200 OK, mas ainda estar redirecionando» — via JavaScript, depois do carregamento. Esse “redirecionamento” fica invisível para uma verificação rápida de status e não tem nenhuma das garantias de um 301.

A orientação do Google hierarquiza os métodos:

• No servidor (301/308): melhor. Use sempre que for tecnicamente possível.
• Meta refresh: depende do tempo. O Google interpreta um meta refresh instantâneo como redirecionamento permanente e um meta refresh atrasado (disparado depois de N segundos) como temporário. Portanto, um refresh content="5;url=…" não substitui um 301.
• JavaScript: último recurso. O Google diz: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (tradução) «Use redirecionamentos JavaScript somente se não puder fazer redirecionamentos no servidor ou meta refresh… se você configurar um redirecionamento JavaScript, o Google talvez nunca o veja se a renderização do conteúdo falhar.» Se a renderização não termina, o redirecionamento efetivamente não existe para o Google.
• Pseudo-redirecionamentos “crypto” / apenas por link: não. Uma página que apenas aponta para a nova URL sem código de status nem refresh é, nas palavras do Google, algo que “not all search engines may recognize… as an official redirect.” (tradução) «nem todos os mecanismos de busca podem reconhecer… como um redirecionamento oficial». Não dependa disso.

A lição: se você se importa com SEO, confirme que seu redirecionamento é um 301 real no servidor, não um 200 que redireciona no navegador. A aba Scripts mostra como verificar com curl.

Erros comuns de 301

• Redirecionar tudo para a página inicial. O clássico. O Google diz: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page… This can confuse users and might be treated as a soft 404 error.” (tradução) «Não redirecione muitas URLs antigas para um único destino irrelevante, como a página inicial… Isso pode confundir usuários e ser tratado como um erro soft 404.» Um soft 404 não consolidará sinais de forma confiável. Redirecione para o substituto relevante — e, se você realmente consolidou várias páginas em uma, enviar todas para essa nova página combinada está certo.
• Cadeias longas. O Google seguirá “up to 10 hops” (tradução) «até 10 saltos», mas aconselha ir direto ao destino final, “ideally no more than 3 and fewer than 5.” (tradução) «idealmente não mais que 3 e menos que 5». Mueller disse que o Google segue cerca de 5 saltos por tentativa em URLs rastreadas com frequência. Meu limite prático é o mesmo: não me preocupo com cadeias abaixo de ~5 saltos, mas já vi problemas acima de 5. Cadeias também acrescentam latência para usuários reais. Ao adicionar um redirecionamento, atualize regras antigas para apontar ao URL final, não ao salto anterior.
• Usar 302 quando você quer 301. Um 302 diz ao Google que a URL original deve continuar canonical, então uma mudança permanente feita com 302 pode deixar a URL errada indexada. O Google pode reinterpretar um 302 de longa duração como permanente, mas o prazo é indefinido — como digo, ninguém sabe realmente quanto tempo, “normalmente algumas semanas a alguns meses”. Use o código que corresponde à intenção.
• Remover redirecionamentos cedo demais. Menos de um ano arrisca deixar valor preso na URL morta. Mantenha-os por pelo menos um ano; idealmente, indefinidamente.
• Regras wildcard amplas demais. Um catch-all de pasta frequentemente envia URLs para o lugar errado. Mapeie antigo → novo 1:1 tanto quanto possível.
• Esquecer recursos que não são HTML. Em uma migração, redirecione também imagens e PDFs; não é necessário redirecionar arquivos JS/CSS/fontes.
• Deixar o host antigo sair do ar cedo demais. Uma regra de redirecionamento não consegue resgatar uma solicitação que nunca chega a ela — se você desativar o DNS do domínio antigo, deixar o certificado TLS expirar ou derrubar o servidor antes de os redirecionamentos terminarem o trabalho, visitantes e bots receberão um erro de conexão em vez de um 301. Mantenha DNS, certificado e regras do host antigo ativos enquanto mantiver os redirecionamentos.

Bing

O Bing trata um 301 como um sinal forte para consolidar o ranking na URL de destino e retirar a antiga do índice — o mesmo modelo básico do Google. A orientação histórica do Bing recomenda manter um redirecionamento permanente por um mínimo menor (da ordem de alguns meses) que o ~1 ano do Google, e sua orientação de migração diz que 301s normalmente são suficientes — a ferramenta Site Move não os substitui. Se você atende aos dois mecanismos, a decisão segura é seguir a orientação mais rigorosa: 301s reais no servidor, mantidos por pelo menos um ano.

Onde isso se encaixa

Um 301 é um código de status em uma família. Seu par mais direto é o redirecionamento 302 (seu equivalente temporário) — a decisão 301 vs. 302 é realmente “esta mudança é permanente ou não?”. É primo próximo da canonicalização (301 é um sinal canonical forte, mas para mover uma página, não para consolidar duplicatas que continuam ativas — para isso se usa rel="canonical"). E é a espinha dorsal de qualquer migração de site. Para o conjunto mais amplo — 302/307 temporários, 308 permanente, 404/410 desaparecidos e erros 5xx — veja o cluster de códigos de status HTTP em que esta página vive.

Resumo de IA

Uma versão condensada da versão Avançada:

• 301 = HTTP “301 Moved Permanently” — uma resposta no servidor que move uma URL permanentemente e é um dos sinais de destino canonical mais fortes que o Google tem. É um sinal, não uma garantia — não promete por si só indexação, ranking ou tráfego. O Google trata 301 e 308 da mesma forma para SEO, mas um 301 pode trocar POST por GET e é armazenável heuristicamente em cache por padrão; use 308 se precisar preservar o método.
• Nenhuma perda de PageRank. Redação exata do Google: “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank.» A velha regra de “perda de ~15% por salto” morreu — e o Google não publica nenhuma porcentagem de equity transferido, então nunca diga “90–99%”.
• Três relógios de tempo: servidor = instantâneo; migração do índice = dias a semanas (mais em sites grandes); consolidação completa de sinais = geralmente pelo menos um ano. Mantenha os redirecionamentos pelo menos um ano, idealmente para sempre.
• Implemente no servidor/borda: Apache .htaccess (Redirect permanent / mod_rewrite [R=301]), nginx (return 301), WordPress (plugin Redirection ou Yoast Premium — o Yoast gratuito não tem gerenciador), Single/Bulk Redirects do Cloudflare (na borda, sem configuração da origem) ou código da aplicação.
• 301s “falsos”: uma página pode retornar 200 e ainda redirecionar por JavaScript (invisível em uma verificação de status). Meta refresh instantâneo ≈ permanente; meta refresh atrasado ≈ temporário; JS é último recurso (o Google pode não vê-lo se a renderização falhar); redirecionamentos “crypto” apenas por link são pouco confiáveis.
• Principais erros: redirecionar tudo para a página inicial (risco de soft 404); cadeias longas (mantenha abaixo de ~5 saltos); usar 302 em uma mudança permanente; remover redirecionamentos cedo demais; wildcards amplos em vez de mapeamento 1:1.
• Ressalva de Patrick: seu próprio teste removendo 301s após um ano mostrou resultados reais mais confusos e mistos que a história limpa de “um ano e você está seguro” — portanto, mantenha os redirecionamentos.

Documentação oficial

Documentação de fontes primárias dos mecanismos de busca.

Google

• Redirecionamentos e a Pesquisa Google — o que é um 301, redirecionamentos no servidor vs. meta refresh vs. JavaScript, regras de tempo de meta refresh e exemplos de implementação (PHP, Apache, nginx).
• Mudanças de site com alterações de URL — a afirmação de “sem perda de PageRank”, a orientação de manter redirecionamentos geralmente por pelo menos 1 ano, limites de cadeias, alerta de soft 404 e migração de sites pequenos vs. grandes.
• How to specify a canonical URL — onde os redirecionamentos se posicionam como sinal de canonicalização.
• Crawling and Indexing — hub principal de redirecionamentos, canonicalização e controles de rastreamento.

Bing / Microsoft

• Bing Webmaster Guidelines — a posição do Bing sobre redirecionamentos e mudanças permanentes.
• Website Migration with Bing (dez. de 2020) — a ferramenta Site Move do Bing e a observação de que 301s normalmente são suficientes e a ferramenta não os substitui.

Implementação em plataformas

• Cloudflare — Bulk Redirects — listas de redirecionamento aplicadas à conta na borda.
• Cloudflare — URL forwarding (Redirects) overview — Single vs. Bulk Redirects.
• Yoast — How to create a 301 redirect in WordPress — os caminhos específicos do WordPress (incluindo que a gestão de redirecionamentos é um recurso Premium).

Citações da fonte

Declarações registradas do Google. Cada link é um deep link que salta para a passagem citada na página de origem.

Google — o que é um 301 e quando usá-lo

• “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.» — Central da Pesquisa Google, Redirecionamentos e a Pesquisa Google. Ir para a citação
• “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (tradução) «Se você precisa mudar a URL de uma página como ela aparece nos resultados do mecanismo de busca, recomendamos um redirecionamento permanente no servidor sempre que possível.» Ir para a citação
• “Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.” (tradução) «Use redirecionamentos permanentes no servidor se for tecnicamente possível… recomendamos usar redirecionamentos permanentes HTTP se possível, como 301 e 308.» — Central da Pesquisa Google, Mudanças de site com alterações de URL. Ir para a citação

Google — PageRank / consolidação (a espinha dorsal de precisão)

• “301 and other permanent redirects don’t cause a loss in PageRank.” (tradução) «301 e outros redirecionamentos permanentes não causam perda de PageRank.» — Central da Pesquisa Google, Mudanças de site com alterações de URL. Ir para a citação
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (tradução) «Ao redirecionar uma URL, o Google acompanha tanto a origem (a URL antiga) quanto o destino (a nova URL). Uma delas será a canonical… A outra se torna um nome alternativo da URL canonical.» — Central da Pesquisa Google, Redirecionamentos e a Pesquisa Google. Ir para a citação

Google — tempo

• “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (tradução) «Deixe os redirecionamentos ativos pelo maior tempo possível, normalmente por pelo menos um ano. Esse intervalo permite ao Google transferir todos os sinais para os novos endereços… Do ponto de vista do usuário, considere mantê-los indefinidamente.» — Central da Pesquisa Google, Mudanças de site com alterações de URL. Ir para a citação
• “A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (tradução) «Um site pequeno ou médio pode levar algumas semanas para mover a maioria das páginas, e sites maiores levam mais tempo… a visibilidade do seu conteúdo na Busca pode oscilar temporariamente durante a mudança. Isso é normal.» Ir para a citação

Google — cadeias, soft 404s e redirecionamentos falsos

• “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (tradução) «Embora o Googlebot possa seguir até 10 saltos em uma cadeia de vários redirecionamentos… recomendamos redirecionar diretamente para o destino final. Se isso não for possível, mantenha o número baixo, idealmente não mais que 3 e menos que 5.» Ir para a citação
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” (tradução) «Não redirecione muitas URLs antigas para um único destino irrelevante, como a página inicial do novo site. Isso pode confundir usuários e ser tratado como soft 404.» Ir para a citação
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (tradução) «Use redirecionamentos JavaScript somente se não puder fazer redirecionamentos no servidor ou meta refresh… se configurar um redirecionamento JavaScript, o Google talvez nunca o veja se a renderização falhar.» — Central da Pesquisa Google, Redirecionamentos e a Pesquisa Google. Ir para a citação
• “Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.” (tradução) «O Google Search interpreta meta refresh instantâneo como redirecionamento permanente… e meta refresh atrasado como redirecionamento temporário.» — A âncora da documentação usa a frase “Google differentiates between two kinds of meta refresh redirects” (tradução) «O Google diferencia entre dois tipos de redirecionamento por meta refresh». Ir para a citação

Checklist de implementação de redirecionamento 301

Uma verificação para executar antes, durante e depois de colocar um redirecionamento permanente (ou um lote deles) no ar:

Antes

• Confirme que a mudança é realmente permanente — se for temporária, você quer um 302, não um 301.
• Construa um mapa 1:1 da URL antiga → URL nova mais relevante (não URL antiga → home).
• Para consolidações, decida qual é a única URL sobrevivente para cada grupo.
• Planeje redirecionar imagens e PDFs também (ignore arquivos JS/CSS/fontes).

Implementação

• Faça no servidor (Apache/nginx/app) ou na borda (Cloudflare) — não via JavaScript ou meta refresh atrasado.
• Prefira regras 1:1 a wildcards amplos de pastas que podem encaminhar URLs para o lugar errado.
• Aponte cada regra para o destino final, para não criar cadeias.
• No WordPress, use o plugin Redirection ou Yoast Premium (o Yoast gratuito não tem gerenciador), ou uma regra do servidor.

Verificação

• Teste se cada URL antiga retorna um 301 real (não 200, não 302, não redirecionamento JS) — veja a aba Scripts para testes com curl.
• Confirme que não existem cadeias acima de ~5 saltos; compacte-as em um único salto.
• Verifique se o destino retorna 200, não outro redirecionamento nem 404.
• Teste uma URL com query string, fragmento, barra final ou maiúsculas/minúsculas — regras podem descartar ou alterar isso silenciosamente.
• Faça amostras de URLs redirecionadas na Inspeção de URL do GSC para ver como o Google as resolve.
• Em uma migração, faça um rastreamento do site (Ahrefs Site Audit / Screaming Frog) para encontrar loops, cadeias e URLs antigas que escaparam do mapa.

Depois

• Deixe os redirecionamentos no lugar geralmente por pelo menos um ano — idealmente indefinidamente.
• Espere que a URL antiga permaneça nos resultados por algum tempo (“nome alternativo”) — isso é normal; não remova o redirecionamento para forçar seu desaparecimento.

Detectando e testando 301s

Verifique com o Redirect Checker:

1. Cole a URL no campo de URL única (ou mude para o modo em lote, para até 20 de uma vez).
2. Clique em Check redirects para rastrear a cadeia completa.
3. Leia o código de status do primeiro salto e o ponto de veredito — um redirecionamento permanente real mostra 301 (ou 308) de ponta a ponta; um 302/307 misturado ou uma severidade de “chain” acima do verde significa que não é um 301 limpo de um salto.

O objetivo é responder a uma pergunta: esta URL realmente retorna um 301 no servidor ou algo está mentindo para mim? (Lembre-se: uma página pode retornar 200 OK e ainda redirecionar no navegador via JavaScript.)

Não teste apenas a URL básica — repita com uma versão que tenha query string, um #fragment, barra final ou capitalização diferente. A especificação HTTP não garante que uma regra de reescrita carregue esses elementos; isso é detalhe da implementação e é comum uma RewriteRule ou correspondência de padrão descartar silenciosamente uma query string ou fragmento original.

Veja o código de status bruto e a cadeia de redirecionamento (curl)

macOS / Linux / WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

Um redirecionamento permanente limpo parece HTTP/1.1 301 Moved Permanently (ou HTTP/2 301) com um único cabeçalho location: apontando para a URL final. Se você vir 302, é temporário. Se vir 200, mas o navegador terminar em outro lugar, é um redirecionamento “falso” de JavaScript/meta refresh.

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

Capture um redirecionamento JavaScript “falso”

curl vê apenas a resposta do servidor, não o JavaScript. Se curl diz 200, mas a página ainda muda de lugar em um navegador real, o redirecionamento é do lado do cliente. Confirme no Chrome DevTools:

1. Abra DevTools → Network e marque Preserve log.
2. Carregue a URL antiga.
3. Se a solicitação superior mostrar Status 301 (ou 308), é um redirecionamento real do servidor. Se a primeira solicitação for 200 e uma entrada de navegação aparecer depois, é um redirecionamento JS/meta refresh — não um 301 verdadeiro.

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress (sem plugin — functions.php, use com moderação)

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

Para a maioria dos sites WordPress, o plugin Redirection ou o Redirect Manager do Yoast Premium é a opção prática — sem código, e o Yoast Premium pode criar automaticamente um 301 quando você altera ou exclui uma URL.

Cloudflare (borda, sem configuração da origem)

Os Single Redirects do Cloudflare já vêm no painel (Rules → Redirect Rules). Para uma migração, uma lista de Bulk Redirects usa um CSV de duas colunas origem → destino e o aplica à conta inteira na borda — a maneira mais rápida de mover milhares de URLs sem tocar na configuração do servidor de origem.

Erros de 301 que transformam uma mudança limpa em bagunça

Redirecionar toda URL antiga para a página inicial

Um catch-all irrelevante confunde usuários e pode ser tratado como soft 404. Mapeie cada URL antiga para seu substituto real mais próximo; retorne 404 ou 410 quando não houver substituto.

Adicionar o novo destino ao final de uma cadeia antiga

Encadear antiga → anterior → atual acrescenta latência e pontos de falha. Atualize a regra mais antiga para apontar diretamente ao destino 200 final.

Deixar um 302 em uma mudança permanente

Um código temporário pede aos mecanismos de busca que prefiram a URL de origem. Use um 301 ou 308 real no servidor quando a mudança for permanente e verifique o status na rede.

Remover o redirecionamento assim que a nova URL aparecer

A mudança no índice não é a consolidação completa de sinais. O Google recomenda manter os redirecionamentos o máximo possível, geralmente por pelo menos um ano; retenção indefinida é melhor para usuários e links antigos quando o custo operacional é baixo.

Confiar em um wildcard amplo sem testar seus destinos

Uma regra de pasta pode enviar URLs não relacionadas para a página errada. Comece com um mapa 1:1, teste casos extremos e reserve padrões para estruturas de URL cuja transformação origem → destino seja realmente consistente.

Esquecer recursos que não são HTML

Imagens e PDFs também podem ter links e tráfego. Inclua recursos movidos no mapa quando tiverem substitutos relevantes; não redirecione cegamente todas as solicitações JS, CSS ou de fontes.

Audite um mapa de redirecionamentos antes da publicação

Cole um CSV contendo pelo menos source_url e target_url. Adicione status atual da origem/destino, tipo de conteúdo, título da página e categoria temática quando disponíveis.

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

A estrutura dos três relógios para um 301

“Quanto tempo leva um 301?” não tem uma única resposta, porque três sistemas avançam em ritmos diferentes. Dê nome ao relógio antes de interpretar o resultado.

A estrutura evita dois erros de categoria comuns: tratar uma regra de servidor funcionando como prova de que a indexação terminou e tratar uma mudança no resultado de busca como permissão para excluir a regra. Valide cada relógio com sua própria evidência.

Ferramentas para implantar e verificar 301s

Ferramentas gratuitas de Patrick

• Redirect Checker — inspecione uma URL ou um lote rápido e veja o primeiro status, cada salto e o destino final. Use-o para a verificação rápida “este é um 301 real de um salto?”.
• Redirect Chain Mapper — diagnostique o que muda em cada salto e exporte regras de limpeza para Cloudflare, Apache ou nginx. Use-o quando a própria cadeia precisar ser compactada.
• Bulk HTTP Status Code Checker — teste até 500 URLs mapeadas, filtre origens que não são 301 e destinos que não são 200 e exporte o conjunto de QA do lançamento.

Verificações de busca e infraestrutura

• Inspeção de URL do Google Search Console — confirme que o Google buscou a URL antiga como um redirecionamento e revise a seleção de canonical no destino.
• Logs do servidor/CDN — verifique se solicitações reais do Googlebot recebem a mesma regra que os usuários.
• Um rastreador completo do site — encontre links internos esquecidos, entradas antigas no sitemap, loops, cadeias e recursos redirecionados depois da migração.

Teste seus conhecimentos: redirecionamentos 301

Cinco perguntas rápidas sobre redirecionamentos permanentes. Escolha uma resposta para cada pergunta e depois confira.

Prove que o redirecionamento realmente funcionou

Você colocou o 301 no ar. Estas verificações separam “a regra está no arquivo de configuração” de “o Google está consolidando a URL antiga na nova”. Execute-as em ordem — a primeira é instantânea, a última leva semanas.

Teste 1 — A URL antiga retorna um 301 real no servidor

• Teste — Cole a URL antiga no Redirect Checker (ou execute curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url).
• Resultado esperado — O primeiro salto é 301 (ou 308) com cabeçalho location:, e a URL final retorna 200. Um salto, limpo.
• Interpretação de falha — Um 200 na URL antiga significa um redirecionamento “falso” JavaScript/meta refresh, não um 301 do servidor; 302/307 significa que você publicou o código temporário por engano.
• Janela de monitoramento — Imediata — o servidor responde no momento em que a regra entra no ar.
• Gatilho de rollback — O verificador mostra uma cadeia com mais de ~5 saltos ou um loop — retire a regra e aponte antigo → destino final 1:1 antes de republicar.

Teste 2 — O Google viu o redirecionamento e escolheu a nova URL

• Teste — Execute a Inspeção de URL no Google Search Console para a URL antiga.
• Resultado esperado — O status diz “Page with redirect” (tradução) «Página com redirecionamento», e a inspeção da nova URL mostra que ela está indexada com ela própria como canonical escolhida pelo Google.
• Interpretação de falha — Se a URL antiga ainda aparece como “Submitted and indexed” (tradução) «Enviada e indexada» com ela própria como canonical semanas depois, o Google não consegue buscar o redirecionamento ou há um sinal conflitante (tag canonical, sitemap, links internos) apontando de volta para ela.
• Janela de monitoramento — Dias a algumas semanas em um site pequeno/médio; mais em sites grandes. O Google diz que a visibilidade pode oscilar durante a mudança — isso é normal.
• Gatilho de rollback — Não remova o redirecionamento para “corrigir” uma URL antiga persistente — o Google a mantém como nome alternativo e ela desaparece sozinha. Reavalie apenas se a nova URL nunca for indexada.

Teste 3 — A migração não deixou o tráfego sem destino

• Teste — Envie em lote as URLs antigas mapeadas pelo Redirect Checker (até 20 por vez) ou faça um rastreamento completo, e acompanhe as páginas migradas no relatório de desempenho do GSC.
• Resultado esperado — Toda URL mapeada chega em um único salto a um 200, e cliques/impressões no destino se recuperam em direção aos níveis anteriores da URL antiga em algumas semanas.
• Interpretação de falha — Uma queda sustentada normalmente indica um mapa quebrado (URL antiga → página errada ou irrelevante, que o Google pode tratar como soft 404), não que o redirecionamento esteja “vazando” PageRank — um 301 correto não causa perda de PageRank.
• Janela de monitoramento — 2–4 semanas de dados do GSC antes de confiar na tendência; compare uma janela equivalente antes/depois, não o ruído diário.
• Gatilho de rollback — Uma queda clara e sustentada de impressões no conjunto migrado alinhada à data do lançamento — audite novamente o mapa 1:1 antes de concluir que o redirecionamento é o problema.

Registro de alterações