Migração de site sem perder SEO: como planejar URLs, redirects, staging, QA e monitoramento

Migração é gestão de risco, não apenas deploy

Sites perdem sinais durante migrações quando várias relações mudam ao mesmo tempo e ninguém preserva uma linha de base. URL, conteúdo, links internos, status HTTP, canonical, rastreamento, infraestrutura e analytics podem mudar juntos. Se o tráfego cai depois, fica difícil separar causa de coincidência.

Por isso o plano começa antes do código final. A equipe precisa saber quais páginas sustentam descoberta, quais URLs recebem links, quais consultas geram demanda, quais conversões importam e o que exatamente será diferente depois do corte.

1. Classifique o tipo de migração antes de montar o checklist

• mudança de domínio ou subdomínio
• mudança de protocolo ou host
• troca de CMS, framework ou arquitetura de renderização
• mudança de hosting/CDN sem alterar URLs
• reestruturação de categorias, diretórios ou slugs
• redesign com alteração relevante de conteúdo e navegação
• consolidação ou divisão de páginas

Uma mudança de hosting sem alteração de URLs exige controles diferentes de uma mudança de domínio com centenas de redirects. Misturar todos os cenários em um checklist genérico aumenta o risco de esquecer justamente o que é específico do projeto.

2. Congele o inventário e o baseline antes do corte

Antes de publicar, exporte o estado atual. O inventário deve permitir comparar o antes e o depois sem depender da memória da equipe.

• URLs canônicas e respectivos status HTTP
• titles, descriptions, H1 e canonicals das páginas prioritárias
• páginas com maior volume de cliques, impressões, conversões e links externos
• sitemap atual e regras de robots.txt
• links internos relevantes e profundidade das páginas críticas
• structured data e entidades importantes
• eventos de analytics, formulários e origem dos leads
• consultas e páginas prioritárias no Search Console

3. Crie um mapa de equivalência URL por URL

O Google recomenda mapear URLs antigas para novos destinos equivalentes em mudanças de site. O princípio é simples: cada URL importante deve apontar para a melhor continuação possível da mesma intenção, não para o endereço mais conveniente para a equipe.

• URL antiga
• URL nova equivalente
• motivo da mudança
• status esperado antes e depois
• redirect permanente quando a URL mudou
• canonical final
• responsável pela validação

4. Preserve intenção e conteúdo, não apenas endereço

Uma migração pode manter o mesmo slug e ainda perder desempenho se a nova página remove a resposta que sustentava determinadas consultas. Compare conteúdo, headings, FAQs, elementos de prova, autoria, links e chamadas comerciais das URLs prioritárias.

Quando houver mudança editorial deliberada, registre-a separadamente da migração técnica. Isso reduz a dificuldade de atribuir uma queda a redirects quando a causa real foi remoção de conteúdo, alteração de intenção ou navegação.

5. Trate staging como ambiente controlado

Staging pode precisar de autenticação, robots restritivo ou noindex. O risco aparece quando essas proteções são copiadas para produção ou quando o ambiente de teste fica publicamente indexável. O gate de release deve verificar explicitamente o estado final de robots.txt, meta robots, headers e autenticação.

• staging protegido de indexação e acesso indevido
• produção sem bloqueios temporários herdados
• WAF/CDN permitindo crawlers desejados conforme a política da empresa
• conteúdo principal disponível no HTML esperado
• assets e APIs críticos sem restrições específicas do ambiente antigo

6. Implemente redirects permanentes e teste a cadeia completa

301 e 308 são sinais de mudança permanente. Mais importante que escolher entre eles é garantir destino equivalente, ausência de loops, cadeias desnecessárias e regras que não capturam URLs erradas por padrão.

• antiga → nova em um salto quando possível
• nenhum loop ou redirect para erro
• parâmetros importantes preservados quando fazem parte da função da URL
• HTTP e HTTPS tratados de forma consistente
• host preferido resolvendo diretamente para a versão canônica
• links internos atualizados para o destino final em vez de depender do redirect

7. Valide canonical, sitemap, navegação e dados estruturados

Depois da mudança, o conjunto de sinais precisa apontar para a mesma arquitetura. Canonical antigo, sitemap com URLs removidas ou breadcrumb desatualizado podem criar mensagens contraditórias.

• canonical absoluto e coerente com a URL final
• sitemap contendo somente páginas canônicas válidas
• menus, breadcrumbs e links contextuais atualizados
• Organization, Person, Service e outros schemas compatíveis com a página visível
• hreflang revisado quando existir estratégia internacional

8. Faça o release com um gate de QA, não com uma lista informal

Cada item crítico precisa de responsável, evidência e critério de aceite. Para páginas prioritárias, teste status, redirect, canonical, H1, metadata, conteúdo, links, formulário e analytics no ambiente público. O próprio domínio precisa ser validado; preview não substitui produção.

• amostra de URLs antigas e novas por tipo de template
• páginas de maior tráfego e receita
• 404 real para URLs inexistentes
• robots.txt e sitemap servidos pelo host correto
• eventos e conversões chegando ao destino esperado
• logs e alertas de 4xx/5xx ativos quando disponíveis

9. Atualize Search Console e monitore o processamento

Sitemap, propriedades e ferramentas de mudança aplicáveis devem ser tratados conforme o tipo de migração. Depois do release, monitore páginas, consultas, cobertura e erros. A ausência de recuperação no dia seguinte não prova falha: crawling, reprocessamento e reavaliação podem levar tempo.

Registre a data de cada correção para não comparar um sinal anterior ao deploy com uma hipótese posterior. Em projetos grandes, segmentar por diretório e template ajuda a descobrir se o problema é sistêmico ou localizado.

10. Defina o que não deve mudar no mesmo dia

Quanto mais variáveis são alteradas simultaneamente, menor a capacidade de diagnosticar uma regressão. Quando possível, separe mudança estrutural de grandes reescritas editoriais, troca de tracking, experimento de conversão e novas regras de infraestrutura. Nem sempre é possível fazer tudo em fases, mas a decisão precisa ser explícita.

11. Tenha plano de rollback — mas não reverta por ansiedade

Rollback é necessário para falhas graves de produção, não para qualquer oscilação de posição. Se redirects, conteúdo e tracking estão corretos, reverter cedo demais pode criar uma segunda migração antes que a primeira tenha sido processada. O plano deve definir quais falhas justificam retorno imediato e quais exigem observação.

Documentos que aprofundam ou sustentam este tema