Migração de Site sem Perder SEO: Guia Técnico

Aprenda a migrar ou redesenhar um site sem perder SEO com inventário de URLs, redirects, canonicals, testes, sitemap e monitoramento pós-lançamento.

Migração de site sem perder SEO: por onde começar?

Uma migração de site sem perder SEO exige preservar a relação entre cada conteúdo antigo e seu destino novo. Na prática, isso significa inventariar URLs, manter o que não precisa mudar, mapear alterações página a página, aplicar redirecionamentos permanentes no servidor e verificar se canonicals, links internos, sitemap e regras de indexação apontam para a mesma versão.

Não existe garantia de posições idênticas durante a transição. O próprio Google informa que oscilações temporárias podem ocorrer enquanto rastreia e reindexa os endereços. O objetivo técnico é reduzir incerteza, impedir perdas evitáveis e distinguir uma variação normal de um defeito real.

O processo vale para troca de domínio, CMS, framework, hospedagem, protocolo, estrutura de URLs ou redesign. Quanto mais dimensões mudam ao mesmo tempo, maior a superfície de risco. Quando possível, separe domínio, plataforma e reformulação de conteúdo em etapas.

Defina exatamente o que será migrado

“Migrar o site” pode representar projetos muito diferentes:

trocar somente o provedor de hospedagem, sem alterar URLs;
mudar de HTTP para HTTPS;
mudar domínio ou subdomínio;
substituir CMS, framework ou mecanismo de renderização;
reorganizar categorias, diretórios e slugs;
unir vários sites ou separar uma área;
redesenhar páginas e reescrever conteúdo;
transferir imagens, PDFs, vídeos e outros arquivos.

Registre o estado inicial e o estado desejado para cada dimensão. Se as URLs permanecerem iguais, o foco recai sobre disponibilidade, DNS, capacidade do servidor, renderização e continuidade dos controles. Se os endereços mudarem, redirects e sinais canônicos passam a ser centrais.

O guia oficial do Google para mudanças de URL recomenda alterar uma coisa por vez quando isso for viável. Essa abordagem facilita atribuir uma queda ao fator correto e simplifica o rollback. Em um projeto de criação de sites profissionais, a decisão de preservar URLs deve acontecer antes do desenvolvimento, não na véspera do lançamento.

Crie uma linha de base antes de alterar o site

Sem uma referência anterior, a equipe pode confundir sazonalidade, mudança de demanda e problemas de migração. Guarde uma linha de base com data e fonte:

URLs conhecidas no CMS, sitemap e rastreamento interno;
páginas com impressões e cliques no Search Console;
sessões, conversões e receita por landing page, quando aplicável;
links externos relevantes apontando para páginas internas;
status HTTP, title, description, H1 e canonical;
regras de robots, noindex e hreflang;
dados estruturados e imagens principais;
links internos e profundidade de navegação;
Core Web Vitals e tempos do servidor;
principais erros 404 e registros de acesso.

Exporte dados suficientes para incluir períodos sazonais relevantes. Não use apenas a lista do sitemap: páginas antigas podem receber tráfego ou backlinks mesmo sem aparecer nele. Logs, analytics, banco de dados e Search Console revelam URLs que um rastreamento comum pode não encontrar.

Faça também um backup verificável de conteúdo, banco, arquivos, configurações, redirects e DNS. “Há um backup” não basta; registre quem restaura, em quanto tempo e qual é o ponto de retorno seguro.

Mantenha URLs estáveis sempre que possível

Uma nova tecnologia não obriga a trocar todos os endereços. Se uma página continua com a mesma finalidade, preservar seu URL reduz trabalho, latência e risco. Alterar slug apenas para deixá-lo mais curto raramente compensa durante uma migração ampla.

Quando a mudança for necessária, construa uma tabela com, no mínimo:

URL antiga	URL nova	ação	motivo	prioridade	teste
/servico-antigo	/novo-servico	301	conteúdo equivalente	alta	pendente
/guia-a	/guia-unificado	301	consolidação real	média	pendente
/campanha-expirada	—	410	sem substituto	baixa	pendente

Cada URL antiga valiosa deve apontar diretamente para o equivalente mais próximo. Não envie centenas de páginas sem relação para a home: isso frustra a pessoa e pode ser interpretado como erro leve, ou soft 404. Conteúdo realmente removido e sem substituto adequado deve responder com 404 ou 410.

Inclua imagens, PDFs e outros arquivos que recebem links ou tráfego. A migração do HTML pode funcionar enquanto documentos importantes permanecem quebrados.

Use redirects permanentes e evite cadeias

Para uma mudança definitiva, prefira redirect HTTP permanente no servidor. A documentação de redirects do Google trata 301 e 308 como sinais de que o destino deve se tornar canônico. Redirects temporários, como 302 e 307, são adequados quando a mudança realmente será revertida.

O teste precisa confirmar três propriedades:

o endereço antigo retorna o status planejado;
o cabeçalho Location aponta para o destino correto;
o destino final responde 200 e contém o conteúdo esperado.

Evite sequências como antiga → intermediária → nova. Redirecione em um salto para o endereço final. Cadeias aumentam latência, consomem recursos de rastreamento e ficam frágeis quando uma regra intermediária é removida. Loops e destinos 404 devem bloquear o lançamento.

O Google recomenda manter redirects de uma migração por pelo menos um ano e, do ponto de vista do usuário, por mais tempo quando ainda houver acessos aos endereços antigos. Atualize também links internos, campanhas, perfis e backlinks de alto impacto; não faça o site depender indefinidamente do redirect para sua própria navegação.

Prepare a homologação sem criar outro site indexável

O ambiente de homologação precisa permitir testes completos sem competir com o site público. Proteção por autenticação ou restrição de rede costuma ser mais segura que confiar apenas em robots.txt. Bloquear rastreamento não é o mesmo que impedir indexação, e ainda pode ocultar do teste aquilo que o robô precisaria acessar.

Se a homologação usar noindex, mantenha uma lista explícita das regras temporárias. Antes do lançamento, verifique HTML, cabeçalhos HTTP, robots.txt, firewall e CDN. Um noindex esquecido ou um bloqueio de produção copiado do staging pode tirar a nova versão da busca.

Rastreie a homologação usando a tabela de URLs como conjunto de teste. Compare página antiga e nova para confirmar:

conteúdo principal, title e H1 preservados ou alterados intencionalmente;
canonical absoluto e autorreferente no destino;
hreflang atualizado, se houver versões regionais;
dados estruturados coerentes com o conteúdo visível;
links internos apontando diretamente para URLs novas;
imagens, scripts, CSS e fontes acessíveis;
formulários, eventos e conversões funcionando;
páginas removidas com o status correto.

O artigo sobre dados estruturados para SEO aprofunda a validação de entidades, artigos, imagens e datas após uma mudança de template.

Faça canonical, sitemap e links contarem a mesma história

O redirect transfere pessoas e rastreadores. O canonical declara a versão preferida entre páginas iguais ou muito parecidas. O sitemap apresenta as URLs que o site deseja disponibilizar. Links internos mostram a arquitetura usada de fato. Esses sinais devem convergir.

Segundo a orientação de canonicalização do Google, redirects e rel=canonical são sinais fortes, enquanto a presença no sitemap é um sinal mais fraco. Não declare a URL nova como canonical e mantenha links e sitemap apontando para a antiga.

O sitemap novo deve conter apenas URLs canônicas, indexáveis e com resposta 200. Gere-o a partir da fonte real de publicação, não de uma planilha desatualizada. A documentação oficial de sitemaps reforça que os endereços enviados representam as versões preferidas.

Preserve a verificação do Search Console e as propriedades necessárias. A ferramenta de mudança de endereço só se aplica a troca de domínio ou subdomínio; não é necessária para HTTP → HTTPS, mudança entre www e sem www no mesmo domínio, nem alteração de caminhos internos.

Trate hospedagem, DNS e desempenho como parte do SEO

Uma migração tecnicamente correta ainda pode falhar se o novo servidor não suportar usuários e rastreadores. Antes do corte, teste capacidade, cache, CDN, TLS, timeouts, erros 5xx e comportamento sob carga. O Google pode rastrear o novo ambiente mais intensamente logo após a mudança.

Na troca de hospedagem sem alteração de URL, o guia do Google para mudança de infraestrutura recomenda reduzir o TTL do DNS com antecedência, confirmar que firewall e proteção contra ataques não bloqueiam Googlebot e acompanhar logs nos servidores antigo e novo. Desative o ambiente anterior somente quando o tráfego tiver migrado de fato.

Compare desempenho com dados de laboratório e de campo. Um redesign pode preservar URLs e conteúdo, mas introduzir JavaScript excessivo, imagens maiores, instabilidade visual ou resposta lenta. Use o diagnóstico de Core Web Vitals e performance para separar gargalos de LCP, INP e CLS.

Checklist para o dia do lançamento

Congele mudanças não essenciais e defina responsáveis por aplicação, infraestrutura, SEO, conteúdo e decisão de rollback. Escolha uma janela de tráfego menor, mas mantenha pessoas disponíveis para corrigir problemas.

Execute este roteiro imediatamente após o corte:

testar amostras de URLs prioritárias e uma seleção aleatória;
validar em massa todos os redirects previstos;
rastrear o site novo e procurar 3xx internos, 4xx, 5xx e loops;
confirmar que home, páginas comerciais e artigos respondem 200;
revisar robots.txt, noindex, canonicals e hreflang;
verificar sitemap, imagens e dados estruturados;
conferir analytics, consentimento, formulários e conversões;
testar versões móvel e desktop;
conferir DNS, certificado, cabeçalhos e cache;
inspecionar algumas URLs no Search Console;
registrar horário, versão, testes e problemas encontrados.

O critério de rollback deve ser definido antes. Indisponibilidade ampla, bloqueio de indexação, redirects quebrados em massa, perda de transações ou corrupção de conteúdo justificam uma decisão rápida. Uma pequena oscilação de ranking, isoladamente, não é um indicador operacional para rollback.

Monitore por URL, não apenas pelo total do site

Nas primeiras horas, observe disponibilidade, erros, redirects e conversões. Nos dias seguintes, acompanhe rastreamento e indexação. Nas semanas posteriores, compare consultas, landing pages e resultados comerciais com a linha de base.

Crie alertas para:

aumento de 404, 410 inesperado e 5xx;
páginas importantes fora do sitemap ou sem links internos;
Google escolhendo canonical diferente da declarada;
queda concentrada em um diretório ou tipo de página;
redirects recebendo tráfego sem chegar ao destino;
redução de conversão em páginas que mantiveram tráfego;
regressão de Core Web Vitals;
rastreamento persistente de URLs antigas sem resposta correta.

Uma queda agregada não explica a causa. Segmente por dispositivo, país, tipo de página, template e data de publicação. Compare antigas e novas URLs como pares. Oscilações temporárias são esperadas, mas erros técnicos objetivos devem ser corrigidos imediatamente.

Se a indexação se comportar de forma inesperada, o guia de indexação de sites no Google ajuda a separar descoberta, rastreamento, renderização, canonicalização e inclusão no índice.

Erros que mais comprometem uma migração

Os problemas mais recorrentes não são sofisticados:

lançar sem inventário completo;
trocar domínio, CMS, design e conteúdo ao mesmo tempo sem necessidade;
redirecionar tudo para a home;
criar cadeias ou loops;
esquecer imagens, PDFs e páginas de campanha;
deixar noindex ou bloqueios de homologação em produção;
manter links internos e canonicals antigos;
publicar sitemap com redirects ou URLs não canônicas;
perder verificação, eventos ou metas de analytics;
desligar hospedagem ou domínio antigo cedo demais;
medir apenas posição de poucas palavras-chave;
declarar sucesso no primeiro dia ou esperar uma garantia de tráfego.

Uma migração de site sem perder SEO é um processo de engenharia, conteúdo e operação. Ela termina quando as rotas antigas chegam aos destinos corretos, o novo site pode ser rastreado e usado, os sinais técnicos concordam e as métricas se estabilizam — não apenas quando o layout entra no ar.

Se sua empresa planeja trocar plataforma, domínio, hospedagem ou arquitetura, a Mattos Tech Solutions pode apoiar a migração para cloud, o desenvolvimento e a validação técnica. Converse com a equipe para estruturar escopo, testes e monitoramento antes do corte.