Checklist de migração de site SEO segundo o Google

A ordem que a documentação do Google propõe

O guia do Google sobre mudança de site com alteração de URL divide a migração em cinco etapas: ler as práticas recomendadas, preparar e testar o novo site, montar o mapa de URLs, iniciar a mudança com redirecionamentos no servidor e monitorar o tráfego nos dois endereços. O mesmo guia pede uma mudança de cada vez. Trocar domínio, CMS e layout no mesmo dia soma três fontes de oscilação e tira do analista a chance de saber qual delas derrubou o tráfego.

Dois pontos do guia costumam faltar nos checklists que circulam em português. Sites pequenos e médios devem mover todos os URLs de uma vez, e sites grandes podem ir por partes. E o servidor novo precisa aguentar rastreamento acima do normal logo depois da virada, porque o Googlebot passa a buscar os endereços antigos e os novos ao mesmo tempo.

Mapa de redirecionamentos 301 e o teste em lote

O mapa de redirecionamentos é a planilha que liga cada URL antigo ao seu equivalente novo. O Google indica três fontes para montá-lo: os sitemaps já enviados, os logs do servidor ou a ferramenta de análise e o relatório de links do Search Console. Imagens, PDFs, CSS e JavaScript também entram, porque recebem tráfego e links.

Na implementação, o Google recomenda redirecionamento 301 ou 308 do lado do servidor e afirma que esses códigos não causam perda de PageRank. Isso tira o fundamento das tabelas de "porcentagem de valor transferida" que ainda aparecem em guias de migração. O limite que importa é outro: o Googlebot segue até 10 saltos, mas o guia pede redirecionamento direto ao destino final, com no máximo três saltos e cinco no limite. Mandar muitos URLs antigos para a home tende a virar soft 404.

O limite que importa é outro: o Googlebot segue até 10 saltos, mas o guia pede redirecionamento direto ao destino final, com no máximo três saltos e cinco no limite.

Lucas Ferraz, especialista em SEO

O teste que recomendo antes da virada é rodar o mapa inteiro contra o servidor novo. O script abaixo lê um CSV sem cabeçalho e aponta quatro falhas: primeiro salto que não é permanente, cadeia, destino diferente do mapa e página final sem status 200.

# mapa.csv: url_antiga,url_nova
while IFS=, read -r antiga nova; do
  primeiro=$(curl -s -o /dev/null -w '%{http_code}' "$antiga")
  read -r final saltos destino < <(curl -sL -o /dev/null \
    -w '%{http_code} %{num_redirects} %{url_effective}' "$antiga")
  case "$primeiro" in 301|308) ;; *) echo "NAO_PERMANENTE $primeiro $antiga";; esac
  [ "$saltos" -le 1 ] || echo "CADEIA $saltos $antiga"
  [ "$destino" = "$nova" ] || echo "DESTINO_ERRADO $antiga -> $destino"
  [ "$final" = "200" ] || echo "FINAL_$final $antiga"
done < mapa.csv

Canonical robots e sitemap no dia da virada

O canonical de cada URL novo precisa apontar para ele mesmo no dia em que os redirecionamentos entram, e as anotações hreflang precisam trocar para os endereços novos. Os links internos também mudam para o destino final. Deixar menu e rodapé apontando para URLs que redirecionam cria um salto extra em cada clique e em cada rastreamento. Rodar o crawler depois da virada e comparar a profundidade de clique com a do site antigo mostra se alguma seção ficou mais longe da home.

A primeira linha da tabela de erros comuns do guia é o bloqueio esquecido: noindex ou regra de robots.txt que protegia a homologação e subiu junto para produção. Na mesma tabela aparecem redirecionamentos que levam a URLs inexistentes e sitemaps desatualizados. O sitemap novo leva só URLs finais. No monitoramento, o guia sugere enviar os dois sitemaps salvos no mapeamento: o de endereços antigos perde páginas indexadas até zero, o de endereços novos ganha, e os avisos de redirecionamento no arquivo antigo são esperados.

Quando usar a Alteração de endereço do Search Console?

A ferramenta Alteração de endereço do Search Console serve apenas para troca de domínio ou de subdomínio, como example.com para example.net. A ajuda do Google exclui três casos que se resolvem com redirecionamento e canonical: HTTP para HTTPS, mudança de caminho dentro do mesmo domínio e remoção do www. Para usar, a mesma Conta do Google precisa ser proprietária das duas propriedades, e só propriedades no nível do domínio são aceitas.

Dois detalhes pegam quem nunca usou. A ferramenta não move subdomínios abaixo do domínio informado, então www, sem www e cada subdomínio pedem solicitação própria, mesmo os que não estão em uso. E a ferramenta confere redirecionamentos 301 em algumas páginas antes de aceitar o pedido, por isso ela entra depois que os redirecionamentos estão ativos.

O conflito entre 180 dias e um ano

As duas páginas do Google sobre migração dão prazos diferentes para manter os redirecionamentos. A ajuda da Alteração de endereço pede pelo menos 180 dias e explica que, depois desse período, o Google trata o site antigo como não relacionado ao novo. O guia de mudança com alteração de URL fala em manter pelo maior tempo possível, geralmente pelo menos um ano, e sugere pensar em manter indefinidamente do ponto de vista do usuário.

Leio os dois textos como camadas. Os 180 dias são o período em que a ferramenta repassa sinais e prioriza o site novo na escolha de canônicos. O ano é o tempo que o guia estima para o Google rastrear tudo de novo e reatribuir os links externos. Na dúvida, prefiro manter o 301 sem data de remoção e tratar o prazo menor como piso.

Monitoramento pós-migração nas duas propriedades

O monitoramento pós-migração acompanha a propriedade antiga e a nova ao mesmo tempo no Search Console, porque a curva esperada é cruzada: indexação e cliques caem no endereço antigo e sobem no novo. O guia cita os relatórios de sitemaps, de cobertura do índice e de consultas. Para um site médio, a documentação fala em algumas semanas até a maior parte das páginas ser movida, com oscilação temporária de posição no caminho.

O log do servidor mostra antes o que os relatórios atrasam: Googlebot pedindo URL antigo e recebendo 404, pico de erro 5xx no servidor novo e redirecionamento que ficou fora do mapa. O filtro por user agent descrito no post sobre crawlers de IA no log do servidor serve aqui, trocando a lista de robôs pelo Googlebot verificado. Quem precisa explicar o risco para o dono do site encontra a versão comercial no verbete de migração de site da agência.