Migrar o site sem perder a posição no Google

Quem migra o seu site tem, em regra, medo de uma coisa: que as páginas que atualmente trazem visitantes deixem de se encontrar. Esse medo é legítimo, mas a causa raramente está onde a espera. Um novo alojamento ou um novo design não lhe custa posição. Endereços que desaparecem sem uma indicação custam. Este texto explica como criar essas indicações, por que ordem, e o que verificar depois de o novo site estar no ar.

Primeiro: que tipo de migração é

O Google distingue dois tipos de migração, e cada um pede uma abordagem diferente. Se só mudar de alojamento ou de CDN e todos os endereços se mantiverem, há no fundo uma única ação: as definições de DNS do seu domínio passam a apontar para o novo local. O Google descreve esse caminho no guia para uma migração sem alterações de endereços (consultado em 20 de setembro de 2026).

Se os endereços mudarem, por exemplo por causa de um novo domínio, de uma nova estrutura de pastas ou da passagem de HTTP para HTTPS, aplicam-se as regras do guia para uma migração com alterações de endereços (consultado em 20 de setembro de 2026). Tudo o que se segue diz respeito a este segundo tipo, porque é aí que as coisas correm mal. Também não trate o primeiro tipo de ânimo leve, mas então não precisa de um mapa de endereços, apenas de um bom teste e de uma passagem limpa.

Migre uma coisa de cada vez

A tentação de fazer tudo de uma vez é grande: novo domínio, novo sistema, novo design, novos textos. Não o faça. O Google recomenda planear as suas alterações uma a uma (consultado em 20 de setembro de 2026). Se a sua posição cair depois da migração, quer saber porquê. Se mudar quatro coisas ao mesmo tempo, nunca o saberá, e também não poderá reverter nada de forma dirigida.

Planeie ainda a migração para um período tranquilo. Se o seu negócio tem uma época ou um dia da semana mais calmo, menos visitantes são atingidos por um eventual erro. Conte também com oscilações. O Google escreve que, num site de dimensão média, pode demorar algumas semanas ou mais até os novos endereços substituírem os antigos nos resultados de pesquisa (consultado em 20 de setembro de 2026). Uma quebra nos primeiros dias é, portanto, normal e não é motivo para reverter em pânico.

Faça primeiro o mapa, só depois a migração

O trabalho mais importante acontece antes de algo se mudar. Faça uma lista de cada endereço que existe agora e ponha ao lado o endereço onde essa página vai ficar. O Google chama a isto um mapa de endereços, em inglês URL mapping (consultado em 20 de setembro de 2026). Sem esse mapa migra por intuição, e a intuição esquece a página que uma vez teve bons resultados e desde então ninguém notou.

Assim se constrói a lista:

• Recolha os endereços de várias fontes: o seu sitemap, um rastreio do seu próprio site e o relatório de desempenho do Search Console. Só o sitemap deixa de fora endereços que já existiram.
• Junte a cada endereço o que ele rende atualmente: impressões e cliques do Search Console, e se outros sites apontam para ele. Isso determina a ordem em que verifica as coisas.
• Dê a cada endereço um destino: a página que responde à mesma pergunta. Se essa página já não existir, um erro é mais honesto do que um redirecionamento para outra coisa. O Google pede então um código de erro 404 ou 410 (consultado em 20 de setembro de 2026).

Não mande tudo para a página inicial

Este é um erro frequente, e nós próprios o cometemos. Quando não sabe para onde deve ir um endereço antigo, a página inicial é a saída fácil. O Google avisa expressamente contra isso: enviar muitos endereços antigos para um único destino irrelevante, como a página inicial, pode ser tratado como soft 404 (consultado em 20 de setembro de 2026). Num soft 404, o redirecionamento não conta como prova de que o conteúdo mudou de sítio.

Em 22 de julho de 2026 percorremos a nossa própria tabela de redirecionamentos com os dados do Search Console dos três meses até 19 de julho de 2026. Verificou-se que 40 dos nossos 49 redirecionamentos apontavam para a página inicial, quando o Google pode tratar esses redirecionamentos como soft 404 (consultado em 20 de setembro de 2026). Alguns desses endereços antigos ainda recebiam impressões. Isso diz muito: as pessoas continuavam a procurar esse conteúdo e o Google continuava a mostrar-lhes o endereço antigo, só que aterravam numa página que não respondia à sua pergunta. Redirecionámos 30 deles para a página que responde de facto à pergunta original. O método de medição é simples e repetível: exporte os redirecionamentos, exporte as impressões por endereço e veja que destinos nada têm a ver com a pesquisa.

Faça o redirecionamento permanente e num só passo

Numa migração, o redirecionamento permanente é a escolha certa. O Google explica que um 301 ou 308 dá o sinal de que o novo destino é o canónico, e que um redirecionamento temporário como 302 ou 307 mantém o endereço antigo nos resultados de pesquisa (consultado em 20 de setembro de 2026). Usar um redirecionamento temporário numa migração definitiva é, portanto, uma forma subtil de bloquear a sua própria migração.

Escolha ainda um redirecionamento feito no servidor, não em JavaScript. O Google descreve os redirecionamentos em JavaScript como utilizáveis apenas se não puder fazer de outra forma (consultado em 20 de setembro de 2026). E limite-se a um só passo: um endereço antigo que passa por um endereço intermédio até ao novo é mais lento para os visitantes e aumenta a probabilidade de algo se quebrar pelo caminho.

O Google aconselha manter os redirecionamentos durante pelo menos 1 ano (consultado em 20 de setembro de 2026), para que possa transferir todos os sinais, incluindo as ligações de outros sites para os seus endereços antigos. Para os visitantes, na prática nunca precisa de os retirar. Atualize, contudo, as suas próprias ligações, porque um redirecionamento é mais lento do que um endereço direto.

Como o fizemos no nosso próprio blogue

Uma migração em pequena escala é um bom exercício, por isso tomemos o nosso próprio blogue como exemplo. Até 14 de setembro de 2026, o blogue neerlandês da FWRD estava em /blog/. Em 15 de setembro de 2026 passou para /nl/blog/. Quatro dias depois, em 19 de setembro de 2026, /blog/ tornou-se o blogue em inglês, com versões em alemão, francês, espanhol e português numa pasta própria de cada língua.

Nisto havia três escolhas que se encontram em qualquer migração:

• Uma lista fixa em vez de uma regra genérica. A solução prática era uma regra que enviasse tudo o que está em /blog/ para /nl/blog/. Mas, desde que /blog/ contém artigos em inglês, essa regra apanharia cada artigo inglês e enviá-lo-ia para uma página neerlandesa. No endereço antigo só existiram três artigos neerlandeses, por isso fixámos esses três como lista. Tudo o que não consta da lista não é redirecionado.
• Levar todas as variantes de um endereço. Uma página tem mais endereços do que se pensa. Além do próprio artigo, migraram também a versão sem barra final, a versão de texto para máquinas com a extensão .md e as páginas dos autores. Quem só redireciona o artigo deixa o resto para trás.
• Não redirecionar de propósito. O feed do blogue, /blog/rss.xml, pertence desde essa troca ao blogue em inglês. Se o tivéssemos redirecionado para o feed neerlandês, cada página inglesa anunciaria um feed noutra língua. Só o descobrimos na primeira ronda de traduções. Um redirecionamento deve, portanto, seguir a intenção do endereço antigo, e não apenas o caminho.

Este último ponto é o cerne de todo este texto: um redirecionamento é uma afirmação sobre o que um endereço significa. Essa afirmação tem de estar certa, mesmo quando a pergunta que lhe deu origem muda. O resultado verifica-se com um comando simples na linha de comandos ou no navegador: o endereço antigo deve chegar à nova página num só passo, com um redirecionamento permanente. Foi assim que o verificámos em 15 de setembro de 2026, e é assim que deve percorrer cada endereço do seu próprio mapa.

O que verificar logo após a migração

Assim que os redirecionamentos estiverem no ar, há uma lista curta a cumprir. O Google refere os pontos principais no guia para iniciar a migração (consultado em 20 de setembro de 2026):

• Teste os redirecionamentos. Faça-o para os seus endereços mais importantes com a inspeção de URL no Search Console e, para os restantes, com um script que percorra o mapa inteiro.
• Verifique se a referência canonical nas novas páginas aponta para os novos endereços e não ainda para os antigos.
• Retire a regra noindex que pôs durante a construção para evitar que o novo site fosse indexado cedo demais. Este erro fica invisível até a sua posição desaparecer, porque o novo site parece perfeitamente bom.
• Verifique o seu robots.txt. Muitos construtores bloqueiam aí todo o rastreio durante o desenvolvimento e esquecem-se de o levantar.
• Submeta o novo sitemap no Search Console.
• Se migrar para outro domínio, existe ainda a ferramenta de alteração de endereço no Search Console. Para uma migração dentro do mesmo domínio, como de HTTP para HTTPS ou de uma pasta para outra, não precisa dela.

Depois, nas semanas seguintes, consulte diariamente o relatório de páginas indexadas e o relatório de desempenho, endereço a endereço e não apenas no total. Uma migração faz-se endereço a endereço, e por isso também endereço a endereço vê se resultou.

O que costuma correr mal

Quatro erros são evidentes. O primeiro é fazer o mapa com o que vê no site em vez do que o Google já conhece. O segundo é deixar uma definição de construção como noindex. O terceiro é migrar e reescrever o conteúdo ao mesmo tempo, o que torna uma quebra impossível de explicar. O quarto é limpar os redirecionamentos passadas poucas semanas porque o site antigo já foi desligado.

Se não quiser descobrir isto sozinho, pode pedir-nos para migrar o seu site, em que os seus textos e a sua estrutura existentes são o ponto de partida do novo site. Se primeiro quiser saber o que está agora no seu site e o que o Google vê, comece por uma análise do seu site, e veja como a visibilidade no Google pode ser tratada como parte fixa de um site.