Migrar a Loja Online Sem Perder SEO: Guia Técnico Para Empresas Portuguesas (2026)

No guia completo de migração explicámos porque é que a perda de tráfego orgânico é o erro mais caro de uma mudança de plataforma. Este artigo é o nível seguinte: o plano técnico, pela ordem certa, para que o Google não trate a loja nova como uma loja desconhecida — e para sair da migração com mais tráfego do que entrou.

---

Há um momento, três a quatro semanas depois do lançamento de uma loja nova, em que alguém abre o Google Analytics e percebe que as visitas orgânicas caíram para metade. O site está mais bonito, mais rápido e mais fácil de gerir. E está a vender menos.

Não é um fenómeno raro. Uma migração sem estratégia de preservação de SEO perde tipicamente até 40% do tráfego orgânico, e a recuperação demora entre seis e doze meses — quando acontece. Numa loja em que o orgânico representa metade das visitas, isto significa perder um quinto das vendas durante um ano, o que vale frequentemente mais do que o projeto inteiro.

O contrário também acontece. Num cliente de retalho de moda com 15.000 páginas de produto, mapeámos todos os URLs, configurámos os redirecionamentos um a um e mantivemos a estrutura de categorias. A loja manteve 98% do tráfego orgânico e os rankings começaram a subir três semanas depois do lançamento, por causa da velocidade da nova plataforma.

A diferença entre os dois cenários não é sorte nem orçamento. É uma lista de tarefas executada pela ordem certa, com uma pessoa responsável por cada uma. Este artigo é essa lista.

Porque É Que o Google "Perde" a Loja Numa Migração

O erro conceptual começa aqui: pensar que o Google indexa a loja. Não indexa. O Google indexa URLs — e cada URL acumulou, ao longo de anos, um conjunto de sinais que não se transferem sozinhos: links de outros sites, links internos, histórico de cliques, conteúdo já avaliado e posicionado.

Quando um produto passa de /12-sapatilhas-running.html para /products/sapatilhas-running sem um redirecionamento permanente, o Google vê duas coisas: um URL antigo que desapareceu (e levou consigo os sinais) e um URL novo que começa do zero. Multiplique por 15.000 páginas e está explicada a queda de 40%.

Mas os URLs são só a parte visível. Numa migração muda quase tudo ao mesmo tempo:

A recomendação do próprio Google para mudanças de site é não fazer demasiadas alterações ao mesmo tempo, precisamente para conseguir isolar o efeito de cada uma. Uma migração de plataforma não permite esse luxo. É por isso que o trabalho tem de ser feito antes, e não depois, de o Google reparar.

Primeiro: O Que a Plataforma Nova Permite Fazer aos URLs

Antes de falar de redirecionamentos, há uma decisão que depende da plataforma de destino e que condiciona todo o resto: é possível manter os URLs atuais?

Shopify e Shopify Plus. Não. Os produtos vivem obrigatoriamente em /products/nome e as coleções em /collections/nome. Quem migra de WooCommerce, PrestaShop ou Magento para Shopify vai mudar 100% dos URLs de catálogo. Não é um problema — é uma certeza que tem de estar no plano desde o primeiro dia, com um mapa completo e sem exceções.

Saleor, Payload CMS e qualquer plataforma com frontend próprio em Next.js. Sim. A estrutura de URLs é definida por quem constrói o storefront, o que abre duas opções: manter exatamente a estrutura antiga (zero redirecionamentos de catálogo) ou desenhar uma estrutura nova, melhor, e redirecionar uma única vez. É uma vantagem real de uma arquitetura headless que raramente entra nas comparações de plataformas.

Do lado de origem, cada plataforma traz os seus vícios. O PrestaShop gera URLs com identificadores numéricos e sufixo .html, muitas vezes com prefixo de idioma. O WooCommerce usa bases como /produto/ e /categoria-produto/, com o mesmo produto a aparecer, por vezes, em vários caminhos. O Magento 1 permite que o mesmo produto seja acessível através de vários caminhos de categoria, o que costuma deixar anos de conteúdo duplicado no índice.

A regra de decisão é simples: mantenha os URLs se forem bons; mude-os se forem maus; nunca os mude "porque a plataforma nova tem outro formato" sem um mapa completo. E, se mudar, mude uma vez. Cada mudança adicional de estrutura nos anos seguintes é uma nova migração aos olhos do Google.

O Mapa de URLs: O Documento Mais Importante do Projeto

Se só puder fazer uma coisa bem, faça esta. O mapa de URLs é uma tabela com duas colunas — URL antigo, URL novo — que cobre todas as páginas que o Google conhece. Não as que estão no catálogo. Todas.

A diferença é enorme. A exportação de produtos e categorias da plataforma antiga cobre normalmente 60 a 80% dos URLs que o Google tem indexados. O resto são páginas de campanhas de há três anos, URLs de filtros que ganharam links, páginas paginadas, imagens, PDFs de fichas técnicas, artigos de blog e variantes de URL que ninguém sabia que existiam.

Como construir o inventário

O inventário é a união de cinco fontes, e nenhuma delas chega sozinha:

1. Um rastreio completo do site atual com uma ferramenta como o Screaming Frog, incluindo imagens e PDFs.
2. A exportação da Search Console — relatório de desempenho, últimos 16 meses, todas as páginas com impressões. Esta lista contém páginas que o rastreio não encontra porque já não têm links internos.
3. As páginas de entrada do Google Analytics dos últimos 12 meses, para identificar o que realmente traz visitas.
4. Os URLs com links externos, exportados de uma ferramenta de backlinks. São os mais valiosos e os que mais custam a perder.
5. O sitemap atual e os registos do servidor, para apanhar o que o Googlebot continua a pedir mesmo que já não exista.

Com o inventário feito, priorize. Os URLs com links externos, os que geraram cliques nos últimos 12 meses e as 200 páginas de entrada com mais receita têm de ser mapeados e verificados manualmente, um a um. O resto pode ser mapeado por regra.

As regras de mapeamento

Duas regras que não têm exceção. Nunca redirecione em massa para a homepage: o Google trata isso como um erro 404 disfarçado e os sinais perdem-se na mesma. Nunca crie cadeias: se o URL A já redirecionava para B, e agora B redireciona para C, corrija A para apontar diretamente para C. Cada salto adicional dilui o sinal e atrasa o rastreio, e o Googlebot desiste ao fim de alguns saltos.

Como implementar os redirecionamentos

Os redirecionamentos têm de ser permanentes e têm de acontecer no servidor. Um redirecionamento em JavaScript ou por meta refresh não transfere sinais de forma fiável. Os códigos aceitáveis são o 301 e o 308 — o Google trata ambos como permanentes; o Next.js, por exemplo, emite 308 quando um redirecionamento é marcado como permanente, e está correto.

Com milhares de entradas, o mapa não pode viver num ficheiro de configuração. Precisa de uma tabela consultada em tempo real — num middleware com um armazenamento de chave-valor, ou ao nível do CDN, com funcionalidades como os Bulk Redirects do Cloudflare. Isto permite corrigir um redirecionamento errado sem fazer um novo deploy.

E têm de ser testados por script, não à mão. Um programa que percorre todos os URLs antigos, segue os redirecionamentos e regista o código final e o destino demora minutos a escrever e apanha os erros que ninguém veria numa amostra de 50 páginas: destinos que devolvem 404, cadeias esquecidas, redirecionamentos para o staging.

Por fim, mantenha-os. O Google recomenda um mínimo de um ano; na prática, enquanto houver links externos a apontar para URLs antigos, os redirecionamentos devem ficar. Desligá-los "para limpar" ao fim de seis meses é uma forma silenciosa de perder o que se preservou.

O Que Tem de Estar Certo na Loja Nova Antes do Lançamento

O mapa de URLs preserva o que existia. Esta secção garante que o que existe do outro lado do redirecionamento merece o tráfego.

Metadados e conteúdo

Títulos, meta descriptions, H1, descrições de produto, textos de categoria e textos alternativos das imagens têm de ser migrados, não regenerados a partir dos templates da plataforma nova. O padrão que vemos mais vezes: a loja nova gera automaticamente títulos como "Sapatilhas – Nome da Loja" para 15.000 produtos, substituindo títulos que tinham sido otimizados durante anos.

Atenção especial às páginas de categoria. São as que posicionam para os termos comerciais genéricos com mais volume ("sapatilhas de running", "torneiras de cozinha") e são as primeiras a perder o texto na migração, porque muitos templates novos não têm onde o mostrar, ou porque ninguém o copiou. Se a categoria tinha 300 palavras de conteúdo por baixo da grelha de produtos, tem de continuar a tê-las.

Canónicas, filtros e paginação

A navegação por filtros — tamanho, cor, marca, preço — é a maior armadilha de rastreio numa loja online, e cada plataforma trata-a de forma diferente. A plataforma antiga pode ter gerado dezenas de milhares de combinações indexadas; a nova pode fazer o mesmo, ou nada, consoante a configuração.

A regra: cada combinação de filtros aponta, por canónica, para a categoria base, e as combinações que não têm valor de pesquisa ficam bloqueadas ao rastreio no robots.txt. As combinações que têm procura real — "sapatilhas de running para homem" — merecem ser páginas de categoria de pleno direito, com URL próprio, título próprio e texto próprio.

A paginação deve continuar rastreável, com cada página a apontar a canónica para si própria. O Google deixou de usar rel="next" e rel="prev" em 2019; o que importa é que a página 2 seja acessível por um link normal, e não apenas por um botão "carregar mais" que só funciona com JavaScript.

Variantes de produto: uma página canónica por produto. Só faz sentido indexar uma variante separadamente quando há procura específica por ela, e nesse caso a variante precisa de conteúdo próprio.

Dados estruturados

As páginas de produto devem ter dados estruturados Product com Offer completo — preço, moeda, disponibilidade — e, quando existem, avaliações, marca, SKU ou GTIN, condições de envio e política de devoluções. É isto que permite os resultados enriquecidos de produto na pesquisa e no separador de compras do Google. Junte BreadcrumbList em todas as páginas e Organization na homepage.

Os templates das plataformas incluem quase sempre algum markup, mas raramente completo ou válido. Valide uma amostra de cada tipo de página no teste de resultados enriquecidos do Google antes do lançamento, não depois.

Renderização e Core Web Vitals

Aqui a migração deixa de ser um risco e passa a ser uma oportunidade. O Google usa os Core Web Vitals como sinal de posicionamento, medidos com dados reais de utilizadores, e os limiares são conhecidos: LCP até 2,5 segundos, INP até 200 milissegundos, CLS até 0,1. O INP substituiu o FID em 2024 e mede a capacidade de resposta da página a interações — o que, numa loja, significa filtros, seletores de variante e o botão de adicionar ao carrinho.

Há uma decisão de arquitetura que decide isto: o HTML tem de chegar ao Google já renderizado. Um storefront que só entrega o conteúdo depois de o JavaScript correr no browser obriga o Google a colocar a página numa fila de renderização, e num catálogo de milhares de páginas isso traduz-se em conteúdo indexado com atraso, ou não indexado de todo. A renderização no servidor (SSR) ou a geração estática incremental (ISR) do Next.js resolvem o problema na origem, e são a razão pela qual a velocidade de uma loja bem construída passa de 5 segundos para 1,5 sem truques.

O outro inimigo do INP é o gestor de tags cheio de píxeis esquecidos. A migração é o momento certo para auditar cada script de terceiros e perguntar quem ainda usa os dados que ele recolhe.

robots.txt, sitemap e hreflang

A plataforma nova traz um robots.txt novo, e é frequente ele bloquear coisas por defeito — diretórios de imagens, CSS, JavaScript, ou os próprios produtos, herdado de uma configuração de staging. Leia-o linha a linha antes do lançamento.

Aproveite para tomar uma decisão explícita sobre os rastreadores de IA (GPTBot, ClaudeBot, PerplexityBot e semelhantes). Bloqueá-los ou permiti-los é uma escolha de negócio, mas tem de ser uma escolha, e não o que o template trouxe de origem — cada vez mais decisões de compra começam numa resposta de IA e não numa página de resultados.

O sitemap XML deve conter apenas URLs canónicos que devolvem 200, dividido em ficheiros de 50.000 URLs no máximo, com datas de modificação reais. Nada de URLs redirecionados, bloqueados ou com noindex.

Se a loja serve vários idiomas ou mercados — Portugal, Espanha, Brasil — as anotações hreflang têm de ser reconstruídas na plataforma nova, incluindo o x-default, e verificadas em ambos os sentidos.

Staging protegido

O ambiente de staging tem de estar atrás de autenticação HTTP, e não apenas protegido por noindex ou pelo robots.txt. Um staging que o Google descobre — e descobre, basta um link num ticket público — é uma loja duplicada no índice a competir com a verdadeira.

O inverso é igualmente comum e mais grave: lançar a loja com o noindex do staging ainda ativo. Faz parte da lista do dia do lançamento, e é a primeira coisa a verificar.

O Dia do Lançamento

A sequência importa. Esta é a que usamos:

1. 48 horas antes, congelar alterações de conteúdo na loja antiga e fazer um rastreio final: é a fotografia de referência.
2. Exportar a baseline da Search Console (páginas, consultas, impressões, cliques) e do Analytics. Sem baseline, não há forma de saber se se perdeu alguma coisa.
3. Cutover de DNS ou de infraestrutura, com a loja antiga a continuar viva em paralelo para rollback, como descrevemos no guia de migração.
4. Nos primeiros 30 minutos: correr o script de verificação de redirecionamentos sobre o inventário completo; confirmar que o robots.txt em produção é o certo; confirmar que nenhuma página tem noindex; confirmar que as canónicas apontam para o domínio de produção e não para o staging.
5. Uma única versão do domínio: https e www (ou sem www) resolvidos com um só redirecionamento, sem cadeias.
6. Submeter o sitemap na Search Console e pedir indexação das 20 páginas mais importantes.
7. Verificar a medição: GA4, conversões de anúncios e restantes tags a disparar. Não é SEO, mas é o dia em que mais dados se perdem sem ninguém reparar.
8. A ferramenta de mudança de endereço da Search Console só se aplica se o domínio mudar. Numa mudança de plataforma no mesmo domínio, não é necessária.

Uma nota sobre lançamentos faseados por percentagem de tráfego: só são seguros para SEO se ambas as versões responderem aos mesmos URLs com o mesmo conteúdo. Se não for o caso, faseie por secção do site — blog primeiro, categorias depois, checkout no fim — e não por percentagem.

As Primeiras Oito Semanas: O Que Vigiar

Alguma flutuação é normal. O Google tem de rastrear todos os URLs antigos, seguir os redirecionamentos, rastrear os novos e reavaliar. Em lojas médias, o processo demora semanas; em catálogos grandes, meses. O que distingue uma flutuação de um problema é a tendência ao fim de três semanas.

Semanalmente, alguém tem de olhar para isto:

• Search Console, relatório de páginas: crescimento de erros 404, "erro de redirecionamento" ou "rastreada, mas não indexada". Cada um tem uma causa concreta e corrigível.
• Search Console, desempenho: impressões e cliques por página, comparados com a baseline. Uma descida temporária até 10% nas primeiras duas semanas é habitual; mais de 15% na terceira semana é um alarme.
• Estatísticas de rastreio: um pico de pedidos é esperado e desejável. Uma queda para valores residuais indica um bloqueio.
• Registos do servidor: pedidos do Googlebot a devolver 404 são URLs que ficaram fora do mapa. Acrescente-os.
• Core Web Vitals: os dados de campo demoram 28 dias a estabilizar. Até lá, use o PageSpeed Insights para confirmar que a loja nova está dentro dos limiares.
• Posições das 100 palavras-chave principais, com atenção às páginas de categoria.
• Os URLs com mais links externos a devolver 200 no destino final.

Quando há uma queda, as causas são quase sempre uma destas: noindex esquecido, robots.txt a bloquear, redirecionamentos para a homepage, canónicas a apontar para o staging, textos de categoria em falta, ou dados estruturados inválidos a fazer desaparecer resultados enriquecidos. Todas se diagnosticam em menos de uma hora com a lista acima.

Onde Estas Migrações Perdem Tráfego: Seis Causas Recorrentes

1. Redirecionar tudo para a homepage. Resolve os 404 no relatório e perde os sinais na mesma. É o equivalente a arrumar a casa atirando tudo para o armário.
2. Lançar com o noindex do staging. Acontece a lojas grandes com equipas experientes. A única defesa é a verificação estar na lista, e alguém ser responsável por ela.
3. Deixar o conteúdo de categoria para trás. O template novo não tinha onde mostrar o texto, ninguém reparou, e as páginas que mais posicionavam ficaram só com uma grelha de produtos.
4. Mudar tudo ao mesmo tempo. Domínio, plataforma, design, estrutura de categorias e conteúdo, num único dia. Quando o tráfego cai, é impossível saber porquê. Se o domínio tiver de mudar, mude-o meses antes ou meses depois da plataforma.
5. Esquecer imagens e PDFs. O tráfego do Google Imagens e as fichas técnicas em PDF — que num negócio B2B são frequentemente as páginas com mais links — raramente entram no mapa.
6. Não guardar a baseline. Sem os dados de antes, "perdemos tráfego" e "o tráfego é sazonal" são indistinguíveis, e a discussão com a agência ou com a administração não tem por onde se resolver.

Migrar É a Melhor Altura Para Ganhar SEO

Tudo o que ficou para trás é sobre não perder. Mas a razão pela qual o cliente de moda subiu nos rankings três semanas depois do lançamento é a outra metade da história: uma migração é o único momento em que se pode mudar a fundação técnica de uma loja sem um projeto adicional.

É a altura de corrigir URLs com identificadores numéricos e sufixos .html. De consolidar os produtos que existiam em três caminhos diferentes num só. De eliminar dezenas de milhares de combinações de filtros que inflavam o índice sem trazer uma visita. De dar às categorias o conteúdo que nunca tiveram. De passar de dados estruturados incompletos para markup completo e válido. De construir breadcrumbs e ligações entre produtos relacionados que distribuem autoridade de forma deliberada. E de passar de um tempo de carregamento de 5 segundos para 1,5, o que por si só muda a conversão e o posicionamento ao mesmo tempo.

Nada disto se faz bem numa loja em produção, com o risco de partir o que funciona. Numa migração, é trabalho que já está a ser feito — só precisa de ser feito com intenção.

Checklist

Antes do lançamento

• Inventário completo de URLs a partir de cinco fontes, não só do catálogo
• Mapa de redirecionamentos 1:1, com os URLs com links e tráfego verificados manualmente
• Redirecionamentos permanentes, no servidor ou CDN, sem cadeias, testados por script
• Títulos, descrições, H1, textos de categoria e alt de imagens migrados, não regenerados
• Canónicas, filtros e paginação configurados; combinações sem valor bloqueadas
• Dados estruturados de produto, breadcrumbs e organização validados
• HTML renderizado no servidor; Core Web Vitals dentro dos limiares em staging
• robots.txt lido linha a linha; decisão explícita sobre rastreadores de IA
• Sitemap só com URLs canónicos a devolver 200; hreflang reconstruído se aplicável
• Staging atrás de autenticação HTTP
• Baseline exportada da Search Console e do Analytics

No dia do lançamento

• Script de redirecionamentos corrido sobre o inventário completo
• noindex removido; robots.txt de produção confirmado; canónicas a apontar para produção
• Uma versão do domínio, um só redirecionamento
• Sitemap submetido; indexação pedida para as páginas principais
• Medição a funcionar: GA4, conversões, tags

Nas primeiras oito semanas

• Revisão semanal de páginas, desempenho e estatísticas de rastreio na Search Console
• Registos do servidor: 404 do Googlebot acrescentados ao mapa
• Core Web Vitals de campo a estabilizar dentro dos limiares
• Redirecionamentos mantidos — no mínimo um ano, idealmente enquanto houver links

Perguntas Frequentes

Quanto tempo demora o Google a processar uma migração? Em lojas de dimensão média, algumas semanas. Em catálogos com dezenas de milhares de páginas, pode demorar meses até todos os URLs antigos serem rastreados e substituídos. A tendência ao fim de três semanas é o indicador mais fiável.

Durante quanto tempo devo manter os redirecionamentos? No mínimo um ano, segundo a recomendação do Google. Na prática, enquanto existirem links externos a apontar para os URLs antigos — o que, numa loja com anos de história, significa indefinidamente.

301 ou 308? Ambos são permanentes e o Google trata-os da mesma forma. O 308 é o que o Next.js emite por defeito para redirecionamentos permanentes. O que não serve são os temporários (302, 307), os redirecionamentos em JavaScript e o meta refresh.

Perco SEO se mudar de WooCommerce ou PrestaShop para Shopify? Não necessariamente. O que é certo é que todos os URLs de catálogo vão mudar, porque o Shopify impõe a sua estrutura. Isso torna o mapa de redirecionamentos obrigatório e completo, mas não implica perda se for bem feito.

Preciso de usar a ferramenta de mudança de endereço da Search Console? Só se o domínio mudar. Uma mudança de plataforma no mesmo domínio não a exige, e usá-la sem mudança de domínio não tem efeito.

Um lançamento faseado é seguro para SEO? Faseado por secção do site, sim. Faseado por percentagem de tráfego, só se as duas versões responderem aos mesmos URLs com o mesmo conteúdo; caso contrário, o Google recebe respostas inconsistentes para a mesma página.

Em Resumo

O Google não indexa lojas; indexa URLs, e cada um deles carrega anos de sinais que só se transferem com um redirecionamento permanente para o destino certo. O mapa de URLs, construído a partir de todas as fontes e testado por script, é o documento que decide se a migração preserva o tráfego. Tudo o resto — conteúdo migrado, canónicas, dados estruturados, renderização no servidor, robots.txt e sitemap corretos — garante que a loja nova merece esse tráfego e, quase sempre, ganha mais.

Na Sparkwave, a preservação de SEO faz parte de todas as migrações que executamos: o mapa de URLs, os redirecionamentos, a validação técnica e as oito semanas de acompanhamento estão no âmbito do projeto, não são um extra. Se está a planear mudar de plataforma, conheça o nosso serviço de migração de plataforma ou fale connosco. E se a loja atual já está na plataforma certa mas os Core Web Vitals continuam fora dos limiares, o problema é outro — e o nosso serviço de otimização de performance trata dele.