O site novo fica pronto, o layout aprovado, o conteúdo revisado. Na semana da estreia, alguém pergunta o que acontece com os endereços antigos, e a resposta mais comum é "a gente redireciona tudo para a home". É nessa frase que muita empresa perde, de uma vez, as páginas que o Google levou anos para confiar.
Este guia é para quem vai refazer o site e mudar as URLs, o caso mais comum de migração. Ele explica o que é o redirecionamento 301, como o Google lê cada tipo de redirecionamento, como montar a planilha que liga cada endereço antigo ao novo, o que fazer no Search Console e, principalmente, por quanto tempo manter tudo isso no ar, com a documentação atual do Google, e não com uma frase antiga repetida de blog em blog.
O que é redirecionamento 301?
É a resposta que o servidor dá quando alguém pede um endereço que mudou de lugar para sempre. Em vez de entregar a página, ele devolve o código HTTP 301 ("moved permanently") e o endereço novo. O navegador vai para lá sozinho, e o visitante quase nunca percebe.
Para o buscador, esse código é um recado: a página antiga não existe mais naquele endereço, e o novo endereço deve ocupar o lugar dela nos resultados. É por isso que o 301 é a peça central de qualquer mudança de URL, seja troca de domínio, passagem de http para https ou reorganização das páginas de um site refeito.
Qual a diferença entre 301, 302, 307 e 308?
A diferença que importa para o negócio é uma só: qual endereço o Google vai mostrar nos resultados. No permanente, ele passa a mostrar o novo. No temporário, continua mostrando o antigo, porque entende que a página vai voltar.
| Código | Leitura do Google | O que aparece na busca | Quando usar |
|---|---|---|---|
| 301 | permanente | o endereço novo | página que mudou de vez: migração, troca de domínio, URL reescrita |
| 308 | permanente | o endereço novo | o mesmo caso do 301; o Google trata os dois como permanentes |
| 302 | temporário | o endereço antigo | desvio que vai ser desfeito |
| 303 e 307 | temporário | o endereço antigo | situações de curto prazo, nunca migração |
| meta refresh de 0 segundo | permanente | o endereço novo | plataforma que não deixa configurar o servidor |
| meta refresh atrasado | temporário | o endereço antigo | evite em mudança de site |
Organizado pela Alliance a partir de "Redirecionamentos e a Pesquisa Google" (Google Search Central)
O exemplo que o próprio Google dá para o temporário é um serviço fora do ar por um tempo: você manda o visitante para uma página de aviso sem comprometer a URL original nos resultados. Numa migração, o 302 faz o contrário do que se quer. Ele mantém o endereço velho como o "oficial" e deixa o novo esperando.
Por isso, antes de ativar qualquer regra num painel ou plugin, confira qual código ela devolve. "Redirecionar" sem número não diz se a mudança é permanente ou temporária, e é esse número que o Google lê.
E o meta refresh e o JavaScript, contam como redirecionamento?
Funcionam, com graus diferentes de confiança. O Google ordena os métodos pela probabilidade de interpretá-los corretamente, e o redirecionamento do lado do servidor (o 301 configurado no Apache, no NGINX, no PHP ou no painel da hospedagem) vem primeiro.
O meta refresh é uma etiqueta no cabeçalho da página que manda o navegador para outro endereço. Se for instantâneo, com zero segundo de espera, o Google o trata como permanente. Se tiver atraso, aquele "você será redirecionado em alguns segundos", vira temporário.
O redirecionamento em JavaScript é o último recurso. O Google renderiza o JavaScript depois de rastrear a página, e a documentação avisa que essa renderização pode falhar por vários motivos. Se falhar, o redirecionamento simplesmente não é visto. Para uma página que concentra tráfego, apostar nisso é apostar no acaso.
Por que refazer o site é o momento de maior risco?
Porque o redesenho quase sempre muda os endereços sem que ninguém decida isso de propósito. O CMS novo tem outro padrão de URL, as páginas de serviço são reagrupadas, o blog ganha outra pasta, os PDFs vão para outro diretório. Cada mudança dessas cria um endereço antigo sem destino.
E o endereço antigo é onde está o histórico: os links que outros sites fizeram, os favoritos dos clientes, as posições conquistadas. Sem um 301 que leve cada um para o equivalente novo, quem chega por ali encontra uma página de erro, e o Google, depois de algumas visitas, entende que o conteúdo sumiu.
A documentação de migração do Google tem uma recomendação que vai contra o instinto de quem está refazendo tudo: mude uma coisa por vez. Se a empresa quer trocar de domínio, de CMS e de layout, o Google sugere mover para o domínio novo primeiro e alterar o layout depois. A ajuda da ferramenta de Alteração de endereço é ainda mais direta: combinar a mudança de domínio com uma reformulação do conteúdo e da estrutura de URLs provavelmente vai causar perda de tráfego, porque o Google talvez precise detectar e avaliar as páginas de novo.
Nem sempre dá para separar as etapas, e tudo bem. O que não dá é tratar o 301 como detalhe do último dia. Ele é parte do projeto do site, como tratamos ao falar de criação de site com foco em velocidade e conversão: o site novo herda o tráfego do antigo ou começa do zero, e quem decide isso é o mapeamento.
Por quanto tempo manter os redirecionamentos 301?
Esta é a pergunta que a maioria dos guias responde com uma frase solta, atribuída a uma sessão antiga de perguntas e respostas do Google. A resposta atual está escrita na documentação, revisada em setembro de 2026.
Repare na estrutura da frase: um ano é o piso, não o prazo. O motivo não é burocrático. O Google precisa revisitar cada endereço antigo, perceber o redirecionamento e reatribuir a ele os links que outros sites fizeram. Links em sites de terceiros não mudam sozinhos, e uma matéria antiga vai continuar apontando para o endereço velho enquanto existir.
Há um segundo número na documentação que costuma confundir. A ajuda da ferramenta de Alteração de endereço do Search Console pede para manter os redirecionamentos por pelo menos 180 dias, ou mais se o site antigo ainda receber tráfego da Pesquisa Google. Os dois prazos não se contradizem: os 180 dias são a janela em que a ferramenta encaminha sinais do domínio antigo para o novo; o ano é a recomendação geral para qualquer mudança de URL. Na dúvida, vale o mais longo.
Na prática, a decisão mais segura é tratar o arquivo de redirecionamentos como parte permanente do site. Ele custa pouco para manter, e removê-lo cedo é desfazer o trabalho exatamente quando o Google terminou de entendê-lo.
Quanto tempo o Google leva para trocar as URLs antigas pelas novas?
Menos do que um ano, mas mais do que a ansiedade da semana de estreia aguenta. E, durante a troca, as posições podem se mexer.
Duas consequências para quem gerencia o projeto. A primeira: combine a expectativa antes da virada. Se a diretoria espera tráfego igual na segunda-feira seguinte, qualquer oscilação vira crise, mesmo quando é o comportamento previsto. A segunda: a documentação diz que um URL é movido de cada vez e que não há frequência fixa de rastreamento. Não existe botão que acelere tudo.
A mesma página traz uma garantia que derruba um mito antigo do mercado: o 301 e outros redirecionamentos permanentes não causam perda de PageRank. Os percentuais de "autoridade perdida no redirecionamento" que circulam em glossários não aparecem na documentação atual. O que faz um site perder tráfego na migração é o redirecionamento errado, ausente ou em cadeia.
Como mapear as URLs antigas para as novas?
O mapeamento é uma planilha com duas colunas: endereço antigo e endereço novo. Parece trabalho menor e é o documento mais importante da migração. A documentação do Google descreve o processo em etapas, que adaptamos para o caso do redesenho:
1. Liste todos os endereços antigos, não só os do menu
Comece pelo sitemap atual, que costuma reunir as páginas mais importantes. Some os endereços que trazem tráfego no Analytics ou nos registros do servidor, as páginas com links internos e externos (o relatório de Links do Search Console mostra quais são) e a lista de conteúdo do CMS. Não esqueça imagens, vídeos e PDFs: eles também recebem tráfego e links, e precisam mudar junto.
2. Dê a cada endereço antigo um destino equivalente
Cada linha aponta para a página nova que responde à mesma necessidade. Se várias páginas antigas viraram uma só, todas podem apontar para a consolidada. O que o Google pede para evitar é mandar muitos endereços para um destino irrelevante, como a página inicial: isso confunde o visitante e pode ser tratado como erro soft 404.
3. Decida o que sai de vez
Conteúdo que não vai para o site novo não precisa de redirecionamento forçado. A documentação orienta que esses endereços devolvam 404 ou 410. É mais honesto com o visitante e mais claro para o buscador do que um desvio para uma página que não tem nada a ver.
4. Atualize o site novo antes da virada
Com a planilha pronta, os links internos do site novo devem apontar direto para os endereços novos, e cada página precisa de uma tag canonical apontando para si mesma. Guarde também o sitemap com os endereços novos e a lista de sites que linkam para os antigos: os dois serão usados depois.
5. Redirecione direto para o destino final
O Googlebot segue até 10 saltos numa cadeia de redirecionamentos, mas o Google recomenda apontar sempre para o destino final e, se não for possível, manter a cadeia de preferência em até três saltos, cinco no máximo. Cadeia aparece quando o site já passou por migrações anteriores: o endereço da primeira versão aponta para o da segunda, que agora aponta para o da terceira. Na planilha, o mais antigo deve ir direto para o novo.
Como fazer o redirecionamento 301 no servidor, no WordPress e na Cloudflare?
A regra geral do Google é usar redirecionamento permanente do lado do servidor sempre que for tecnicamente possível, e consultar o administrador do servidor ou a hospedagem para saber o que está disponível. Os caminhos mais comuns:
- Servidor Apache (.htaccess): a documentação do Google mostra o formato com mod_alias, na linha
Redirect permanent "/old" "https://example.com/new", e com mod_rewrite, usando a marca[R=301]. Uma linha por endereço da planilha, ou uma regra de padrão quando a mudança é sistemática. - NGINX: a instrução
return 301dentro de um blocolocation, também com exemplo na documentação do Google. - PHP: a função
header()com o status 301 e o cabeçalho Location, enviados antes de qualquer conteúdo da página. - WordPress: o caminho usual é um plugin gerenciador. O Redirection, no repositório oficial do WordPress, cria e gerencia redirecionamentos 301 sem mexer no Apache ou no NGINX, registra os erros 404 e pode criar o redirecionamento sozinho quando o link permanente de um post muda.
- Cloudflare: segundo a documentação da Cloudflare sobre redirecionamentos, há Single Redirects (regras por domínio, com curingas que cobrem milhares de URLs numa regra) e Bulk Redirects (listas grandes de redirecionamentos estáticos no nível da conta). Os dois exigem que o DNS do domínio passe pelo proxy da Cloudflare e estão disponíveis em todos os planos, com cotas que variam por plano.
- Plataformas fechadas (lojas virtuais e construtores de site): você não acessa o servidor, então depende do que o painel oferece. O próprio Google lembra que plataformas desse tipo podem já ter uma solução de redirecionamento integrada e sugere procurar na ajuda da plataforma. Confira se o código devolvido é 301 e se há limite de quantidade.
Qualquer que seja o caminho, o teste é o mesmo. A Ferramenta de inspeção de URL do Search Console mostra como o Google vê um endereço. Para dezenas ou centenas de endereços, o Google recomenda scripts ou ferramentas de linha de comando que leiam a planilha e confiram, linha por linha, se o código é 301 e se o destino é o certo.
O que muda no Search Console quando o site troca de endereço?
Depende do tipo de mudança, e é aqui que muita equipe gasta energia no lugar errado. A ferramenta de Alteração de endereço, a mais lembrada, serve para um caso só: a troca de domínio ou subdomínio.
| Tipo de mudança | Precisa de 301? | Usar Alteração de endereço? | Cuidado principal |
|---|---|---|---|
| Site refeito no mesmo domínio, com URLs novas | sim, endereço a endereço | não | a planilha de mapeamento |
| Troca de domínio (exemplo.com para exemplo.net) | sim | sim, para todas as variantes do domínio antigo | as duas propriedades verificadas na mesma Conta do Google |
| De http para https | sim | não; o Google detecta a mudança | certificado e redirecionamento de todas as páginas |
| Com www para sem www (ou o contrário) | sim | não | canonical e redirecionamento consistentes |
| Troca de hospedagem sem mudar URLs | não | não | capacidade do servidor e configuração do DNS |
Organizado pela Alliance a partir de "Como mover um site" (Google Search Central) e da Ajuda do Search Console sobre a ferramenta Alteração de endereço
No redesenho dentro do mesmo domínio, o trabalho no Search Console é de acompanhamento. Envie o sitemap novo, e o Google sugere enviar também o antigo, salvo no mapeamento: com o tempo, o número de páginas indexadas do sitemap antigo cai para zero enquanto o do novo sobe. Os avisos sobre URLs com redirecionamento no sitemap antigo são esperados e podem ser ignorados. Para ler esses relatórios sem tirar conclusões apressadas, vale o nosso guia do que os relatórios do Search Console não mostram.
Outro detalhe que some na pressa: a verificação de propriedade. Se o site antigo foi verificado por arquivo HTML, por meta tag ou pelo Google Analytics, o site novo precisa levar esse item junto, ou a conta perde a verificação justamente no período em que os dados mais importam.
Quais os erros mais comuns na migração de URLs?
A documentação do Google lista os problemas que mais impedem o site novo de ser indexado. Na prática de projeto, eles aparecem quase sempre nesta forma:
- Esquecer o bloqueio do ambiente de testes. O site novo foi desenvolvido com noindex ou com o robots.txt fechando tudo, e ninguém tirou na estreia.
- Redirecionar tudo para a home. É o atalho que transforma páginas com histórico em erro soft 404.
- Usar 302 por engano. O painel ofereceu "redirecionamento", ninguém conferiu o código, e o Google continua mostrando o endereço antigo.
- Criar cadeias. Redirecionamentos de migrações anteriores que não foram atualizados para o destino final.
- Redirecionar para endereço que não existe. A documentação aponta isso como frequente: o 301 está lá, mas leva a uma página de erro no site novo.
- Deixar sitemaps e links internos com endereços velhos. Cada link interno que passa por redirecionamento deixa a navegação mais lenta e manda um sinal confuso.
- Subestimar o servidor. Depois de uma migração, o Google rastreia o site novo com mais intensidade que o normal, porque os rastreamentos do antigo são levados para ele.
- Apagar os redirecionamentos cedo. Na limpeza do servidor, alguns meses depois, alguém remove o arquivo "que não serve mais".
Quem paga o domínio antigo depois da mudança?
Na troca de domínio, essa pergunta costuma ficar sem dono, e é ela que decide quanto tempo o 301 consegue existir. O redirecionamento só funciona enquanto o domínio antigo estiver ativo e apontando para um servidor que responda com o código certo. Domínio vencido não redireciona nada.
A Ajuda do Search Console é explícita: recomenda continuar pagando pelo domínio antigo por pelo menos um ano, para impedir que outras pessoas o comprem e o usem para fins maliciosos. Um domínio com histórico e links interessa a quem quer se aproveitar dele, e quem comprar herda os links que ainda apontam para lá.
Por isso a recomendação prática é colocar o domínio antigo no contrato e no orçamento: quem renova, em nome de quem fica o registro, por quanto tempo. Esse cuidado conversa com outro que já tratamos, o de registrar o domínio em nome da empresa, e não do fornecedor. Em migração, o problema dobra: são dois domínios para não perder.
O que muda conforme o tamanho e o tipo de site?
O processo é o mesmo, mas a escala muda a estratégia. Para sites pequenos e médios, o Google recomenda mover todos os endereços de uma vez, o que facilita a experiência do usuário e ajuda os algoritmos a detectar a mudança. Para sites grandes, é possível mover por partes, começando por uma seção que mude pouco, para testar o efeito no tráfego e na indexação antes do resto.
Em loja virtual, a atenção vai para os produtos fora de linha e as páginas de categoria. Em site institucional, as páginas de serviço e os artigos com links externos são as que carregam o histórico. E, em empresa que faz campanhas, vale lembrar dos endereços impressos em material gráfico, QR codes e anúncios: o Google sugere atualizar também os links de perfis em redes sociais e as campanhas que levam às páginas de destino.
Por onde começar se o site novo já está a caminho?
Se o projeto já está em desenvolvimento, ainda dá tempo, desde que o mapeamento comece antes da data de estreia. Uma sequência possível:
- Exporte a lista de endereços do site atual (sitemap, Analytics, Search Console e CMS) e salve uma cópia: depois da virada, ela fica difícil de reconstruir.
- Monte a planilha antigo para novo e marque o que sai de vez.
- Combine com quem desenvolve onde os redirecionamentos vão morar (servidor, plugin, CDN ou painel da plataforma) e confira que o código é 301.
- Na virada, teste por amostragem com a inspeção de URL e, para o resto, com uma varredura automatizada da planilha.
- Acompanhe indexação e tráfego nas semanas seguintes, com a expectativa de oscilação combinada com a diretoria.
- Registre no contrato a manutenção dos redirecionamentos e, se houve troca de domínio, a renovação do antigo por pelo menos um ano.
Se a migração faz parte de um projeto maior de presença digital, o trabalho de SEO e GEO da Alliance entra justamente nesse ponto, junto com o desenvolvimento do site. E, para saber onde o site atual está mais frágil antes de mexer nele, o diagnóstico de marketing gratuito aponta as lacunas de presença digital e o que priorizar.

