Migração de site sem perder tráfego: redirecionamentos, testes e monitoramento

O que é uma migração de site e por que ela derruba tráfego

Migração de site é qualquer mudança que altera os endereços pelos quais o Google, as IAs e as pessoas chegam às suas páginas: troca de domínio, de protocolo, de estrutura de URLs ou de plataforma. Um redesenho que mantém todas as URLs é reforma. Um redesenho que muda as URLs é migração, mesmo que ninguém tenha chamado assim no orçamento.

O tráfego cai porque os sinais que o site acumulou estão presos aos endereços antigos. Links de outros sites, posições construídas ao longo de anos, favoritos de clientes, menções em matérias e as páginas que as IAs costumam citar apontam para URLs específicas. Se essas URLs passam a responder erro, ou levam a uma página que não tem relação com o conteúdo original, o buscador precisa reaprender o site e parte do que sustentava a presença orgânica se perde no caminho.

A boa notícia é que o Google documenta o processo com bastante detalhe. O guia de >mudança de site com alteração de URLs do Google Search Central descreve preparação, mapeamento, redirecionamentos e monitoramento. Ele também é honesto sobre o que esperar: haverá flutuação temporária de posições durante a mudança, e em sites de porte médio pode levar algumas semanas ou mais até as novas URLs aparecerem no lugar das antigas. Migração bem feita não elimina a oscilação. Ela evita que a oscilação vire perda permanente.

Tipos de migração e o que cada uma exige

Nem toda migração tem o mesmo risco. A tabela resume os cenários mais comuns e o que muda em cada um.

A coluna da ferramenta de mudança de endereço segue o guia do Google: ela serve para mudanças de domínio ou subdomínio e não é necessária para HTTP para HTTPS, para trocar www por sem www nem para mudar caminhos dentro do mesmo domínio. Em todos os casos, o trabalho de base é o mesmo: inventário, mapa e redirecionamentos permanentes bem feitos.

Antes da virada: inventário e mapa de redirecionamentos

O mapa de redirecionamentos é o documento mais importante da migração. É uma planilha com duas colunas principais: a URL antiga e a URL nova correspondente. Parece simples, e é onde a maioria dos projetos falha, porque a lista de URLs antigas quase sempre está incompleta.

De onde tirar as URLs antigas

O guia do Google sugere juntar as URLs a partir dos sitemaps, dos logs do servidor, da ferramenta de análise e do próprio CMS. Na prática, acrescento mais três fontes: o relatório de desempenho do Search Console (páginas com impressões), a lista de páginas com links externos e as URLs que as IAs costumam citar quando pergunto sobre o assunto da empresa. Uma página antiga que ninguém lembra, mas que recebe link de um portal regional, vale tanto quanto a home.

Como decidir o destino

• Equivalente direto: cada URL antiga aponta para a página nova que atende à mesma intenção. É o caso ideal.
• Conteúdo consolidado: três páginas antigas sobre o mesmo serviço viram uma página nova mais completa, e as três redirecionam para ela.
• Sem equivalente: a página deixa de existir e responde 404 ou 410. O Google recomenda isso para conteúdo removido. Redirecionar muitas URLs antigas para um único destino sem relação, como a home, pode ser tratado como soft 404.

Cada URL nova deve ter um rel="canonical" apontando para ela mesma, e os links internos, os sitemaps e as anotações hreflang devem ser atualizados para os endereços novos. Guarde também o sitemap com as URLs antigas: ele vai ser útil no monitoramento.

Redirecionamento 301 bem feito: cadeias, loops e regras

A >documentação do Google sobre redirecionamentos separa dois grupos. Os permanentes (301 e 308) são seguidos pelo Googlebot e tratados como sinal forte de que o destino deve ser a URL canônica. Os temporários (302, 303 e 307) também são seguidos, mas não funcionam como sinal de canonicalização, e a URL de origem costuma continuar aparecendo. Em migração, o padrão é redirecionamento permanente no servidor. Meta refresh instantâneo é alternativa quando o servidor não permite. Redirecionamento por JavaScript fica para último caso, porque a renderização pode falhar e o Google pode nunca ver o redirecionamento.

Cadeias

Cadeia é quando a URL A redireciona para B, que redireciona para C. Ela nasce de camadas: a regra de HTTPS, depois a de www, depois a da barra no final, depois a do redesenho anterior. Segundo a >página do Google sobre códigos de status HTTP, os rastreadores do Google seguem por padrão até 10 saltos. Mas o guia de migração recomenda redirecionar direto para o destino final e, quando não der, manter a cadeia idealmente em no máximo 3 saltos e abaixo de 5. Cada salto é uma requisição a mais para robôs e pessoas, e um ponto a mais para algo quebrar.

Loops

Loop é quando a cadeia volta ao começo: A leva a B, que leva de novo a A. O navegador mostra erro de redirecionamentos em excesso, e o robô desiste. Loops costumam surgir quando duas regras genéricas se contradizem, por exemplo, uma que remove a barra final e outra que a acrescenta, ou uma regra que tira o .html das URLs aplicada também ao destino que ela mesma gerou.

Como escrever regras que não criam problemas

• Combine as condições de protocolo e host numa única regra que leva direto ao endereço canônico final.
• Coloque as regras específicas (URL antiga para URL nova) antes das genéricas, e faça cada uma apontar já para o destino final, com protocolo, host e barra corretos.
• Quando uma URL antiga já redirecionava para outra que também mudou, atualize a regra antiga para o destino novo em vez de empilhar.
• Proteja regras genéricas com condições que impeçam que elas se apliquem ao próprio resultado.

Canonical, sitemap, robots.txt e o que mais precisa mudar

Redirecionamento resolve quem chega pela URL antiga. O resto do site precisa falar só a língua nova, para que o buscador não receba sinais contraditórios:

• Canonical: cada página nova aponta para si mesma. Canonical apontando para a URL antiga, herdado de um template, é um erro que vejo com frequência e anula o redirecionamento.
• Links internos: menus, rodapés, textos e botões devem apontar para o destino final. Depender do 301 nos links internos espalha saltos desnecessários pelo site inteiro.
• Sitemaps: o novo sitemap lista só URLs finais, com resposta 200. O antigo pode ser enviado por um tempo para acelerar a descoberta dos redirecionamentos.
• Robots.txt: o guia do Google lembra de remover bloqueios e noindex usados só durante a migração. O robots.txt do site antigo também não deve bloquear as URLs antigas: se o robô não puder acessá-las, não vê o redirecionamento. O guia de robots.txt e robôs de IA mostra como revisar o arquivo.
• Dados estruturados: propriedades como url, @id e sameAs precisam refletir os endereços novos. Um @id antigo quebra as ligações entre empresa, pessoa e serviços descritas em dados estruturados avançados.
• llms.txt: se o site tem um, todos os links precisam apontar para as URLs finais. Veja o guia de llms.txt.
• Fora do site: Perfil da Empresa no Google de cada unidade, redes sociais, diretórios e os links mais importantes de parceiros devem ser atualizados. Em redes com várias unidades, o link do site em cada perfil é um item crítico, como explico em SEO local para várias unidades.

Dia da virada: passo a passo

1. Congele o conteúdo. Evite publicar páginas novas no site antigo nos dias anteriores, para o mapa não ficar desatualizado.
2. Verifique as propriedades. Todas as variantes do site antigo e do novo devem estar verificadas no Search Console, incluindo HTTP, HTTPS, com e sem www.
3. Publique o site novo sem bloqueios. Confira robots.txt, noindex e senha de homologação antes de qualquer outra coisa.
4. Ative os redirecionamentos de uma vez. Migrar por partes, com metade do site redirecionando e metade não, complica a análise e os sinais.
5. Teste o mapa inteiro. Rode a lista de URLs antigas numa ferramenta que siga os redirecionamentos e registre código de status, número de saltos e destino final. Toda linha precisa terminar em 200 no endereço esperado, com um salto só.
6. Use a Inspeção de URL. Para as páginas mais importantes, confira no Search Console se o Google vê o redirecionamento e a página nova.
7. Envie os sitemaps. O novo, e, se fizer sentido, o antigo por algumas semanas.
8. Registre a mudança de endereço, se houve troca de domínio, na propriedade antiga do Search Console.
9. Prepare o servidor. O Google avisa que vai rastrear o site novo com mais intensidade que o normal logo após a migração.

Depois da virada: monitoramento e prazos

O guia do Google diz que o Googlebot precisa visitar cada URL do site antigo e do novo pelo menos uma vez, e que não há frequência fixa de rastreamento. Por isso, o monitoramento é diário nas primeiras semanas e semanal depois:

• Indexação: no relatório de páginas do Search Console, as URLs antigas devem cair e as novas subir. Erros inesperados aparecem aqui primeiro.
• Desempenho: acompanhe consultas e páginas. O esperado é ver as URLs novas assumindo as impressões das antigas. Compare por grupo de páginas, não pelo total do site.
• Logs do servidor: mostram se o Googlebot está passando pelas URLs antigas, recebendo 301 e chegando ao destino, e revelam 404 que o mapa esqueceu.
• Conversões: tráfego estável com contatos em queda indica problema de formulário, rastreamento ou página de destino, não de SEO. As métricas que importam estão em como medir resultados de SEO.
• Respostas das IAs: repita as perguntas que costumavam citar o site e confira se os links citados levam à página certa. Assistentes podem continuar citando a URL antiga por um tempo. Se o redirecionamento estiver correto, quem clica chega ao lugar certo. O artigo IA cita informação antiga trata do problema quando o conteúdo também está desatualizado.

Quanto tempo manter os redirecionamentos? O Google recomenda manter pelo maior tempo possível, em geral pelo menos 1 ano, e lembra que, do ponto de vista do usuário, vale considerar mantê-los indefinidamente. Na prática, eu não removo redirecionamento de URL que tenha recebido link externo.

Como eu aplico isso

No meu próprio site, passei por uma correção de cadeias e loops de 301, e ela ilustra bem como esses problemas nascem sem ninguém perceber. Ao longo dos anos, o site acumulou camadas de regras: a de HTTPS, a de www, a que remove o .html, os redirecionamentos de páginas antigas exportadas do Search Console e os de ferramentas que deixaram de existir. Cada regra fazia sentido sozinha. Juntas, algumas URLs passavam por mais de um salto até o destino, e uma regra genérica podia, em certas condições, se aplicar ao próprio resultado.

A correção seguiu quatro decisões:

• Protocolo e host foram resolvidos numa única regra, que leva qualquer variação (HTTP, com www) direto ao endereço canônico em um salto.
• Páginas antigas que apontavam para outra página antiga passaram a apontar direto para o destino final. Um exemplo: o endereço antigo da minha página de apresentação vai direto para /sobre/, sem passar pela URL intermediária que existia antes.
• A regra que remove o .html ganhou condições que a impedem de entrar em loop com as exceções e com o próprio resultado.
• Endereços de ferramentas sem equivalente passaram a responder 410, em vez de redirecionar tudo para a home.

Quando eu reviso uma migração de cliente, o erro que mais encontro não é técnico, é de escopo: o projeto de desenvolvimento termina no dia em que o site novo vai ao ar, e ninguém fica responsável pelas URLs antigas. O mapa é feito a partir do menu do site, não dos dados, e páginas com links externos e posições antigas ficam de fora. Foi exatamente esse o cuidado central do case como reconstruir um site sem jogar fora anos de SEO: tratar a migração como operação de SEO tanto quanto de desenvolvimento.

Se o site já foi migrado e o tráfego caiu, o caminho é o inverso: reconstruir o mapa a partir dos dados antigos e corrigir os redirecionamentos que faltam. Isso faz parte de uma auditoria de SEO, e os detalhes de servidor estão em SEO técnico avançado.

Migrações em empresas de São Paulo: situações comuns

Nas empresas paulistas, alguns cenários se repetem e cada um pede um cuidado específico:

• Rebranding depois de fusão ou entrada de sócio, comum em escritórios de advocacia e contabilidade na capital: domínio novo, nome novo e a marca antiga ainda buscada por clientes antigos. O site novo precisa explicar a mudança de nome com clareza, para que Google e IAs entendam que se trata da mesma empresa.
• Troca de plataforma de loja virtual, frequente em e-commerces da Grande São Paulo e do interior: as URLs de categoria e produto mudam de padrão, e filtros geram milhares de combinações. O guia de SEO para e-commerce detalha esse cenário.
• Indústrias com catálogo técnico na região de Campinas, em Sorocaba e no Vale do Paraíba: fichas técnicas em PDF e páginas de produto com links de distribuidores. Cada PDF com link externo precisa entrar no mapa.
• Redes que unificam domínios de unidades, como clínicas com um site por cidade entre Ribeirão Preto e Franca, ou imobiliárias com sites separados em Santos e no Guarujá: cada domínio absorvido precisa de redirecionamento para a página da unidade correspondente, não para a home do site principal.

Buscas como "clínica de fisioterapia em Franca" ou "contador em Santo André" dependem de páginas que continuam existindo depois da migração. Se a página da cidade ou do serviço some, a posição some junto. Para ver como esse trabalho se encaixa numa estratégia completa, a página do especialista em SEO, AEO e GEO em São Paulo resume a abordagem, e a biblioteca de SEO, AEO e GEO reúne os demais guias desta série.