Como migrar um domínio sem afundar as suas classificações de pesquisa

Mudar de domínio é um dos poucos projetos de SEO em que um erro tecnicamente pequeno pode tornar-se muito visível muito depressa. Um redirecionamento em falta, um caminho de rastreio bloqueado ou um canonical esquecido podem transformar um rebranding simples em semanas de volatilidade nas classificações.

Alguma oscilação é normal. Os motores de pesquisa precisam de tempo para rastrear os URLs antigos, descobrir os redirecionamentos, processar sinais e acomodar o novo domínio no índice. O objetivo não é evitar qualquer queda. O objetivo é tornar a migração aborrecida: um URL antigo aponta para um URL novo equivalente, o servidor responde de forma clara e nada importante desaparece.

Comece com um inventário, não com uma regra de redirecionamento

A falha mais comum numa migração é tratá-la como uma tarefa de configuração do servidor. Não é. É uma tarefa de arquitetura de informação que, por acaso, acaba em configuração do servidor.

Antes de tocar no DNS, crie uma lista dos URLs que importam:

• URLs que recebem tráfego orgânico
• URLs com backlinks externos
• URLs que convertem, geram leads ou apoiam campanhas
• URLs canónicos atualmente no seu sitemap XML
• PDFs, imagens e ficheiros descarregáveis que têm links externos
• URLs legados de alto valor que podem não aparecer na navegação atual

Para cada URL antigo, atribua um destino no novo domínio. Na maioria dos casos, esse destino deve ser a mesma página com a mesma intenção. Se /pricing passar a ser https://newdomain.com/pricing, isso é simples. Se três páginas antigas de produto forem fundidas num novo guia, documente essa decisão deliberadamente.

Evite o padrão preguiçoso: redirecionar tudo para a nova homepage. É conveniente, mas desperdiça relevância. Tanto os motores de pesquisa como os utilizadores esperam que o destino responda à mesma necessidade que o URL original.

Preserve a estrutura de URLs sempre que puder

Uma migração de domínio é mais fácil quando os caminhos se mantêm estáveis. Passar de oldsite.com/blog/example para newsite.com/blog/example é muito mais limpo do que mudar domínio, CMS, slugs, estrutura de pastas e conteúdo ao mesmo tempo.

Por vezes, um redesign ou uma migração de CMS torna inevitáveis as alterações de URL. Se for esse o caso, separe as decisões:

1. O que muda porque o domínio está a mudar?
2. O que muda porque a estrutura do site está a mudar?
3. O que está a ser eliminado, fundido ou reescrito?

Quanto mais variáveis introduzir, mais difícil será diagnosticar problemas mais tarde. Se a migração for importante e o site atual estiver a ter bom desempenho, considere mudar primeiro o domínio e redesenhar depois.

Use redirecionamentos permanentes de um só salto

Para uma verdadeira migração de domínio, use redirecionamentos 301 ou 308 do lado do servidor, dos URLs antigos para os seus novos equivalentes. Redirecionamentos temporários são para situações temporárias. Redirecionamentos JavaScript, meta refreshes e redirecionamentos soft são sinais mais fracos e mais fáceis de quebrar.

Os seus objetivos de redirecionamento são simples:

• Todos os URLs antigos importantes devolvem um redirecionamento permanente.
• Cada redirecionamento vai diretamente para o destino final.
• HTTP redireciona para HTTPS de forma limpa.
• Variantes www e sem www são tratadas de forma consistente.
• Os redirecionamentos não dependem de comportamento frágil de query strings, salvo se necessário.

Uma má cadeia tem este aspeto:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Isto pode acabar por chegar à página certa, mas é lento, mais difícil de rastrear e mais propenso a esconder erros. Aponte para um só salto de cada variante antiga para o novo URL final.

Ao validar o comportamento, inspecione as respostas HTTP reais em vez de confiar no que o navegador mostra. O nosso guia sobre debugging redirects and HTTP headers in production é útil aqui porque os navegadores são demasiado educados: seguem a cadeia e escondem as partes confusas.

Prepare DNS e certificados antes do lançamento

O DNS não transfere classificações diretamente, mas um mau DNS pode fazer uma migração parecer quebrada. Reduza os valores de TTL antes da janela de lançamento para que as alterações se propaguem de forma mais previsível. Confirme que o novo domínio tem os registos corretos para tráfego web, email e quaisquer subdomínios necessários.

Também precisa de certificados TLS válidos para ambos os domínios. Isto é fácil de esquecer. O domínio antigo continua a precisar de servir redirecionamentos HTTPS depois da migração. Se o certificado expirar, utilizadores e crawlers podem encontrar avisos do navegador antes de chegarem ao novo site.

Se a mudança afetar o email, não trate isso como um detalhe secundário. Mudanças de domínio quebram frequentemente SPF, DKIM, DMARC, registos MX, links de tracking e email transacional. Para uma revisão dos registos que importam, consulte o nosso guia orientado para programadores sobre MX, SPF, DKIM, and DMARC.

Verifique canonicals, links internos e sitemaps

Depois do lançamento, o novo domínio deve comportar-se como se tivesse sido sempre a casa canónica do conteúdo.

Isto significa:

• As tags canonical apontam para os novos URLs, não para o domínio antigo.
• Os links internos usam o novo domínio ou caminhos relativos à raiz.
• Os sitemaps XML contêm apenas novos URLs finais e indexáveis.
• As anotações hreflang, se usadas, referenciam os novos URLs.
• Open Graph, dados estruturados e links alternativos são atualizados.
• Robots.txt não bloqueia secções importantes.

Não publique um sitemap cheio de URLs antigos esperando que os redirecionamentos resolvam tudo. Um sitemap deve ser uma lista de URLs que quer ver indexados. Depois de uma migração, isso significa URLs finais no novo domínio.

Esteja também atento a contradições de canonical. Uma página que redireciona do antigo para o novo, mas tem um canonical a apontar de volta para o domínio antigo, envia sinais mistos. Os motores de pesquisa costumam conseguir lidar com alguma inconsistência, mas não deve pedir-lhes que o façam.

Não mude tudo no dia do lançamento

Uma migração já é um evento suficientemente grande. Se possível, evite combiná-la com grandes cortes de conteúdo, reescritas de templates, alterações de navegação, mudanças na renderização JavaScript ou um novo perfil de desempenho.

Isto não é superstição. É disciplina de debugging. Se as classificações caírem depois do lançamento, precisa de saber se a causa é o mapeamento de redirecionamentos, o acesso de rastreio, conteúdo alterado, renderização mais lenta, dados estruturados em falta ou outra coisa.

Mantenha o lançamento inicial tão próximo do site antigo quanto for prático. Quando o novo domínio estiver estável, faça alterações editoriais e de design maiores em lotes mais pequenos.

Diga aos motores de pesquisa o que mudou

No Google Search Console, verifique tanto o domínio antigo como o novo. Depois use a ferramenta Change of Address quando a mudança for ao nível do domínio e o conteúdo estiver a mudar para um novo domínio. Submeta o novo sitemap depois do lançamento.

Isto não substitui os redirecionamentos. Apoia-os. Os motores de pesquisa continuam a precisar de redirecionamentos persistentes e rastreáveis para compreender o mapeamento ao nível do URL.

Para Bing e outros motores de pesquisa, use as respetivas ferramentas para webmasters quando disponíveis. Atualize também os locais que controla: perfis sociais, listagens de negócio, destinos de anúncios, rodapés de email, documentação, links de parceiros e referências canónicas em conteúdo sindicado.

Nem todos os links externos serão atualizados, e não há problema. Mas os mais importantes devem ser. Se um grande parceiro, marketplace de apps, portal de documentação ou página de imprensa aponta para o domínio antigo, peça uma atualização.

Monitorize as coisas certas depois do lançamento

Os primeiros dias após a migração devem ser de monitorização ativa, não de celebração.

Verifique:

• Logs do servidor para atividade de rastreio nos domínios antigo e novo
• 404s e erros 5xx inesperados
• Cadeias e loops de redirecionamento
• Estado de indexação no Search Console
• Descoberta e processamento do sitemap
• Páginas de entrada orgânicas e padrões de consultas
• Caminhos de conversão que dependem de URLs antigos
• Filtros de analytics e exclusões de referência

Espere ruído nos relatórios. Algumas ferramentas de analytics tratam o novo domínio como uma nova propriedade, a menos que sejam configuradas corretamente. Alguns dashboards comparam o tráfego do domínio antigo com o do novo domínio e fazem a migração parecer pior do que é.

A visibilidade de pesquisa pode flutuar durante algumas semanas. O que não quer é um padrão em que URLs antigos de alto valor são rastreados repetidamente mas não redirecionados corretamente, ou em que novas páginas são descobertas mas marcadas como duplicados do domínio antigo.

O desempenho também não deve ser ignorado. Se o novo domínio for lançado com templates mais pesados, cache quebrada ou assets não otimizados, os utilizadores podem sentir a migração como uma lentidão. Se está a usar Lighthouse como parte das suas verificações, leia-o com prioridades em mente; o nosso artigo sobre how to read a Lighthouse report without panicking explica como separar problemas significativos de ruído.

Mantenha o domínio antigo durante muito tempo

Não deixe o domínio antigo expirar depois de a migração “funcionar”. Mantenha-o registado, mantenha os certificados válidos e mantenha os redirecionamentos ativos pelo maior tempo possível. Na prática, isso costuma significar anos.

Links antigos continuam a existir em posts de blog, favoritos, documentação, PDFs, emails e publicações sociais. Os redirecionamentos são a ponte entre esse histórico e o novo domínio. Desativá-los demasiado cedo quebra os caminhos dos utilizadores e desperdiça sinais acumulados.

Mantenha também uma cópia do seu mapa de redirecionamentos e das notas de lançamento. Seis meses depois, quando alguém perguntar por que motivo um URL legado se comporta de determinada forma, ficará satisfeito por o ter documentado.

<!-- tool-cta:start -->

💡 Experimente isto: Após a migração, rastreie seus URLs antigos com Redirect Checker para confirmar que cada um resolve em um único salto 301 para a nova página correta.

<!-- tool-cta:end -->

Uma checklist sensata de migração

Antes do lançamento:

• Verifique ambos os domínios no Search Console.
• Rastreie o site atual e exporte URLs importantes.
• Crie um mapa de redirecionamentos um-para-um.
• Reduza os TTLs do DNS.
• Prepare certificados TLS para os domínios antigo e novo.
• Atualize canonicals, links internos, hreflang, dados estruturados e sitemaps.
• Teste redirecionamentos em staging ou num ambiente controlado.

No dia do lançamento:

• Implemente os redirecionamentos.
• Confirme o comportamento de HTTP para HTTPS.
• Teste amostras de URLs importantes de todos os tipos de template.
• Submeta o novo sitemap.
• Use a ferramenta Change of Address quando apropriado.
• Vigie erros de servidor, loops de redirecionamento e recursos bloqueados.

Depois do lançamento:

• Monitorize erros de rastreio e relatórios de indexação.
• Atualize links externos importantes sempre que puder.
• Compare o tráfego pela intenção da página de entrada, não apenas pelos totais do domínio.
• Mantenha os redirecionamentos ativos indefinidamente.
• Adie redesigns ou experiências de conteúdo não relacionados até a mudança estabilizar.

Migrações de domínio não são isentas de risco, mas são geríveis. As classificações costumam sofrer quando a migração envia sinais pouco claros: redirecionamentos em falta, conteúdo alterado, canonicals contraditórios, crawlers bloqueados ou um domínio antigo esquecido. Dê aos motores de pesquisa e aos utilizadores um mapa limpo, e a mudança torna-se muito menos dramática.