Saltar para o conteúdo

Redesign ou migração de website sem perder SEO

Como fazer o redesign ou a migração de um website sem perder tráfego: redirecionamentos 301, hreflang, sitemaps, Core Web Vitals e alteração de endereço.

Publicado a
min de leitura
9 min de leitura
Equipa editorial Hanoon Labs

Um redesign de website devia trazer mais clientes, e muitas vezes traz menos durante meses: URLs que mudam sem redirecionamento, páginas que desaparecem, títulos reescritos, conteúdo apagado, um site novo mais bonito e mais lento. Quase nada disto é inevitável. A migração de um website sem perder SEO é, em grande parte, um trabalho de preparação: saber o que existe, decidir o que muda, mapear cada URL antigo para o novo e acompanhar o resultado depois do lançamento.

Este guia segue as recomendações oficiais da Google e organiza-as num plano de trabalho com checklists. Não prometemos "zero oscilação": a própria Google avisa que é normal haver flutuações durante uma mudança. O objetivo é reduzi-las e recuperar depressa.

Que tipo de mudança está a fazer?

O risco depende do tipo de mudança, e as ações também:

Tipo de mudançaExemploRisco para o SEOAlteração de endereço no Search Console
Só visualNovo tema, mesmos URLs e conteúdoBaixo (atenção ao desempenho)Não
Estrutura de URLs/servicos/x passa a /pt/services/xMédio a altoNão (mesmo domínio)
HTTP para HTTPS, www para sem wwwMudar a versão canónicaMédioNão
Mudança de plataformaWordPress para outro CMS, Shopware para WooCommerceMédio a altoNão, se o domínio e os URLs se mantiverem
Mudança de domínioempresa.pt passa a marca.comAltoSim

A documentação da Google sobre mudanças de site com alteração de URLs explica que a ferramenta de alteração de endereço só se usa quando muda de domínio ou subdomínio; não serve para HTTP→HTTPS, www/sem www ou mudanças de caminho.

Antes de começar: auditar o que tem

Não consegue proteger o que não conhece. Antes de desenhar o novo site:

  1. Liste todos os URLs que existem hoje: exporte do CMS, do sitemap, de um rastreador (crawler) e do Search Console.
  2. Identifique as páginas que geram tráfego e conversões (Search Console e analítica). Estas são as que não pode perder.
  3. Registe os ficheiros externos: PDF, imagens, ficheiros descarregáveis com ligações externas.
  4. Guarde uma cópia de referência: títulos, descrições, cabeçalhos, dados estruturados e ligações internas das páginas principais.
  5. Meça o desempenho atual: posições, cliques, páginas indexadas e Core Web Vitals, para comparar depois.
  6. Verifique ligações de entrada (backlinks) para as páginas mais importantes, porque são as que mais importa redirecionar bem.

Um bom critério: se uma página tem tráfego, ligações externas ou conversões, ela tem de ter um destino equivalente no site novo.

Redirecionamentos 301: o coração da migração

Sempre que um URL muda, o antigo deve redirecionar para o novo equivalente com um redirecionamento permanente do lado do servidor. A Google indica 301 ou 308 do lado do servidor e considera os redirecionamentos do lado do cliente (por exemplo, em JavaScript) a última opção.

Regras práticas

  • Um mapa, URL a URL. Uma tabela com "URL antigo → URL novo". Em sites pequenos faz-se à mão; em grandes, por regras e exceções.
  • Redirecione diretamente para o destino final. Evite cadeias: a Google refere que idealmente não devem exceder 3 saltos e que devem ser sempre menos de 5.
  • Destino equivalente, não genérico. Não redirecione muitos URLs antigos para a página inicial; a Google desaconselha-o quando as páginas não são relacionadas.
  • Páginas apagadas sem equivalente devem devolver 404 ou 410 corretamente, não 200 com uma mensagem de "não encontrado".
  • Atualize as ligações internas para os URLs novos. Os redirecionamentos abrandam os utilizadores, e as ligações internas devem apontar para o destino final.
  • Mantenha os redirecionamentos pelo menos um ano. É a indicação da Google para permitir a transferência de sinais; pode mantê-los indefinidamente.
  • Teste antes de lançar, com o mapa completo num ambiente de testes, e depois de lançar, com um rastreio para detetar erros.

Um exemplo do nosso portefólio: na migração da Kachouri Getränke-Service de Shopware 5 para WooCommerce, com 812 produtos, a mudança de plataforma implicou tratar a estrutura de URLs de uma loja inteira; o resultado em desempenho foi um CLS móvel que passou de 0,44 para 0. Este tipo de projeto está descrito em criação de loja online; para decidir entre plataformas, veja Shopify, WooCommerce ou loja online à medida.

Conteúdo, títulos e estrutura

Um redesign muitas vezes "limpa" o conteúdo. Cuidado com o que tira:

  • Mantenha o conteúdo que posiciona. Se uma página tem texto longo que responde a uma pesquisa e a nova versão fica com três frases e uma imagem, perderá posição.
  • Preserve títulos (title), descrições e cabeçalhos relevantes, a menos que tenha uma razão para os melhorar. Mudar tudo ao mesmo tempo torna impossível perceber o que causou uma queda.
  • Mantenha a hierarquia de cabeçalhos (um H1 por página, H2 e H3 com lógica).
  • Conserve dados estruturados (por exemplo, de produtos, perguntas frequentes, organização).
  • Texto alternativo nas imagens e nomes de ficheiro com sentido.
  • Não bloqueie o rastreio por engano. É um erro clássico: o ambiente de testes tinha noindex ou um robots.txt restritivo e foi para produção assim. Verifique ambos antes do lançamento.

Sites em várias línguas: hreflang

Se o site existe em mais de uma língua, as anotações hreflang ajudam a Google a mostrar a versão certa a cada utilizador. A documentação da Google sobre versões localizadas estabelece regras que, num redesign, são fáceis de quebrar:

  • Pode usar um de três métodos: elementos <link> no <head>, cabeçalhos HTTP, ou o sitemap XML. Usar vários só acrescenta manutenção.
  • Cada versão deve listar-se a si própria e a todas as outras, com o mesmo conjunto de anotações em todas.
  • Ligações recíprocas: se a página A aponta para B, B tem de apontar para A, senão as anotações são ignoradas.
  • URLs completos (com https://), não relativos.
  • Códigos de língua ISO 639-1, com região opcional (ISO 3166-1 Alpha 2). Não pode haver região sozinha, e use GB, não UK.
  • x-default serve para a página de recurso, como um seletor de língua.

Se os URLs mudam, as anotações têm de ser atualizadas para os URLs novos em todas as línguas ao mesmo tempo. Um site multilíngue como o da PDF Nova, que existe em 6 línguas, é o tipo de projeto em que isto tem de ser sistematizado e testado, não feito à mão.

Sitemaps

Depois de lançar, envie um sitemap com os URLs novos. A Google recomenda ainda:

  • Submeter um sitemap com os URLs novos e remover o antigo quando o novo estiver em uso.
  • Não se preocupar com avisos de redirecionamento no sitemap antigo durante a mudança: são esperados.
  • Ter presente que um sitemap não garante que tudo seja rastreado e indexado, como a documentação sobre sitemaps refere.

Uma técnica útil: durante a transição, mantenha também um sitemap com os URLs antigos (que redirecionam), porque ajuda a Google a descobri-los e a processar os redirecionamentos mais depressa.

Core Web Vitals: o novo site não pode ser mais lento

Um site mais bonito e mais pesado é a regressão mais comum num redesign. A Google define as métricas Core Web Vitals e os respetivos valores "bons", medidos ao percentil 75 dos carregamentos:

MétricaO que medeValor "bom"
LCPCarregamento do conteúdo principalaté 2,5 segundos
INPCapacidade de resposta a interaçõesaté 200 milissegundos
CLSEstabilidade visualaté 0,1

A Google não indica o peso exato destas métricas no ranking, mas recomenda-as para ter sucesso na Pesquisa, e a experiência do utilizador é, em qualquer caso, um argumento comercial. Antes de lançar, meça as páginas principais no site novo (em móvel) e compare com o antigo. Pontos de atenção:

  • Imagens grandes sem dimensões definidas (causam saltos de layout).
  • Fontes e scripts de terceiros em excesso.
  • Carrossel e vídeo no topo da página inicial.
  • Alojamento mais fraco do que o anterior.

Exemplos: a PDF Nova obtém, em laboratório, Lighthouse móvel de 95 em Desempenho e 100 em Acessibilidade, Boas Práticas e SEO. São números de laboratório, que não substituem os dados reais de utilizadores, mas mostram que um site rico pode ser rápido se isso for um requisito desde o início. Ver também a nossa página de criação de sites, e o caso do Club Photo Tunis, um redesign de um website de um clube de fotografia.

Mudança de domínio: a alteração de endereço no Search Console

Se vai mudar de domínio, o processo tem passos adicionais. A ajuda do Search Console indica que a ferramenta se usa depois de ter movido e redirecionado o site, e que exige:

  • Um redirecionamento 301 da página inicial antiga para a nova (e recomenda-se redirecionar também as páginas canónicas principais).
  • Ser proprietário das propriedades antiga e nova, com a mesma conta Google.
  • Usar propriedades ao nível do domínio e verificar todas as variantes do domínio antigo (com e sem www, subdomínios).
  • Passar as verificações prévias da ferramenta.

A ferramenta pede à Google que dê prioridade ao rastreio e indexação do site novo e transfira sinais do antigo; os efeitos mantêm-se durante 180 dias. A mesma página recomenda manter os redirecionamentos pelo menos 180 dias (mais, se os URLs antigos ainda receberem tráfego) e manter o domínio antigo registado pelo menos um ano, para evitar utilização indevida. A documentação sobre mudança de site acrescenta que, para sites médios, a transição demora "algumas semanas ou mais" e que é normal haver flutuações na visibilidade.

Plano de lançamento em quatro fases

Fase 1: Preparação (semanas antes)

  • Auditoria de URLs, páginas de valor e métricas de referência.
  • Mapa de redirecionamentos completo.
  • Ambiente de testes com noindex e proteção de acesso.
  • Checklist de conteúdo, títulos, dados estruturados e hreflang.

Fase 2: Teste (antes do lançamento)

  • Rastreio do ambiente de testes e verificação do mapa de redirecionamentos.
  • Medição de Core Web Vitals em móvel.
  • Revisão de formulários, analítica, pixéis e faturação.
  • Plano de reversão, se algo correr mal.

Fase 3: Lançamento

  • Remover noindex e proteção, verificar robots.txt.
  • Ativar redirecionamentos e testar uma amostra.
  • Submeter o sitemap novo; se mudou de domínio, usar a ferramenta de alteração de endereço.
  • Evitar lançar em dias de pico de vendas ou sem equipa disponível.

Fase 4: Monitorização (semanas e meses depois)

  • Relatório de cobertura e de rastreio no Search Console.
  • Erros 404 e cadeias de redirecionamentos.
  • Comparação de cliques, impressões, posições e conversões com a referência.
  • Correção rápida do que falhou. A maior parte dos problemas resolve-se com ajustes pontuais se detetada cedo.

Erros que custam caro

  • Lançar sem mapa de redirecionamentos.
  • Redirecionar tudo para a página inicial.
  • Esquecer o noindex do ambiente de testes em produção.
  • Mudar URLs, plataforma, conteúdo e domínio ao mesmo tempo, sem poder isolar a causa de uma queda.
  • Ignorar o hreflang numa mudança multilíngue.
  • Desativar o domínio antigo cedo demais.
  • Não medir antes: sem referência, não sabe se perdeu ou ganhou.

Perguntas frequentes

Quanto tempo demora a recuperar o tráfego?

Depende do site. A Google indica, para sites médios, algumas semanas ou mais até substituir os URLs antigos pelos novos, e flutuações são normais. Um site grande demora mais.

Posso mudar o design sem mexer nos URLs?

Sim, e é a opção de menor risco. Mantenha URLs, conteúdo e estrutura, e preste atenção ao desempenho.

Quanto tempo devo manter os redirecionamentos?

Pelo menos um ano, segundo a Google, e idealmente enquanto os URLs antigos tiverem ligações externas ou tráfego.

Preciso da alteração de endereço se só passo para HTTPS?

Não. A ferramenta é só para mudanças de domínio ou subdomínio.

E se o novo site for mais lento?

Corrija antes de lançar. Medir os Core Web Vitals no ambiente de testes evita surpresas.

Conclusão

Um redesign bem-sucedido protege o que já funciona: URLs mapeados, conteúdo que posiciona, hreflang coerente, sitemap atualizado e um site tão rápido quanto o anterior ou mais. A flutuação inicial é normal, mas a perda duradoura é evitável. Se quiser planear uma migração ou um redesign com este rigor, fale connosco. Trabalhamos remotamente com clientes em vários países, sem escritório em Portugal.

Está a planear um projeto assim?

Diga-nos do que precisa — respondemos com uma abordagem concreta e um orçamento por escrito.