Porque o Google reverte migrações de domínio após 4 meses e como proteger o WooCommerce

Mudar o nome de domínio de uma loja online WooCommerce em produção é uma das intervenções técnicas mais delicadas no comércio electrónico. Em Outubro de 2026, nos fóruns técnicos do Google Search Central e em artigos de análise no Search Engine Roundtable, foi relatado um caso de grande repercussão: quatro meses depois de terem sido configurados redireccionamentos HTTP 301 e de ter sido aprovada a alteração de endereço no Google Search Console, o motor de pesquisa começou subitamente a transferir o tráfego orgânico e a indexação do novo domínio de volta para o domínio original.

Muitos gestores de plataformas digitais e engenheiros de software assumem incorrectamente que o processo de transição termina no instante em que a consola do Google aceita a notificação de mudança de endereço e os primeiros URLs novos começam a figurar nas páginas de resultados. Na verdade, os algoritmos do Google analisam os sinais canónicos em contínuo. Se os alicerces técnicos do novo domínio se revelarem instáveis, a plataforma decide de forma autónoma anular a migração.

Neste artigo detalhamos a mecânica subjacente a este problema, expomos as principais falhas de gestão de dados no WooCommerce e apresentamos os procedimentos de engenharia recomendados para evitar quebras severas de visibilidade comercial.

#Porque é que o Google volta ao domínio antigo meses após a migração

O recuo de uma migração de domínio não é fruto de uma avaria aleatória dos sistemas de rastreio, mas sim o resultado directo da operação do algoritmo de determinação canónica do Google (Canonicalization System). O Google não encara um redireccionamento 301 nem a ferramenta de alteração de endereço como uma cessão perpétua de relevância orgânica. Trata-os como sugestões de elevado peso que necessitam de confirmação empírica diária através de dezenas de métricas independentes.

Quando o Googlebot visita o domínio antigo e recebe uma resposta de cabeçalho HTTP/1.1 301 Moved Permanently, dá início à transferência de PageRank para o destino designado. Em simultâneo, monitoriza a integridade técnica do novo domínio. Se durante os meses seguintes se verificarem irregularidades estruturais:

1. O novo domínio apresenta falhas de ligação intermitentes (códigos 500, 502, 504) perante picos de tráfego de agentes de IA e clientes.
2. Várias páginas de catálogo no novo alojamento respondem com o código 200 OK, mas exibem ecrãs em branco ou erros de PHP, gerando classificações automáticas de soft 404.
3. As etiquetas rel="canonical" no novo sítio continuam a apontar para o domínio antigo devido a lapsos em plugins de SEO ou a filtros manuais no ficheiro de funções do tema filho.
4. A estrutura de ligações internas (menus principais, rodapés, fichas de produto, breadcrumbs) mantém referências activas ao endereço antigo.
5. O perfil de menções e hiperligações externas do novo domínio não regista evolução, enquanto lapsos na cache do servidor antigo começam a omitir cabeçalhos 301.

Nestas condições, o índice de confiança algorítmica no novo domínio entra em declínio acentuado. Ultrapassado o limite de segurança, o Googlebot conclui que a migração foi mal executada ou revertida pela equipa técnica, procedendo ao restabelecimento dos URLs originais nos resultados de pesquisa.

#Como é que o Google avalia os sinais canónicos na mudança de domínio

O procedimento de canonização nos motores de busca modernos traduz-se num modelo de decisão multifactorial. Não se limita a interpretar uma etiqueta isolada no cabeçalho HTML, confrontando antes as orientações explícitas com a resposta prática da infraestrutura.

#Que sinais canónicos decidem a escolha do domínio pelo algoritmo

O quadro seguinte sintetiza a hierarquia e o peso dos sinais avaliados pelo Googlebot ao analisar páginas duplicadas ou redireccionadas:

Havendo contradições entre estes indicadores (por exemplo, se um redireccionamento 301 conduz ao novo domínio, mas a etiqueta canónica no HTML do novo domínio aponta de volta para o antigo), o motor entra num estado de indecisão. Ao longo do tempo, o algoritmo dá primazia ao domínio com maior antiguidade e melhor reputação de ligações externas.

#Porque é que tags rel canonical erradas revertem a migração no Google

Em projetos assentes em WooCommerce, ferramentas de SEO como o Yoast SEO, Rank Math ou The SEO Framework produzem etiquetas canónicas baseadas nas opções de configuração do WordPress. Se durante a transferência da base de dados os programadores mantiverem rotinas antigas no tema:

// Filtro prejudicial no ficheiro functions.php do tema filho
add_filter('wpseo_canonical', function($canonical) {
    return str_replace('nova-loja.pt', 'antiga-loja.pt', $canonical);
});

Cada página de artigo na nova loja passa a transmitir uma instrução clara ao Googlebot: este recurso é apenas uma réplica secundária, residindo a versão original e fidedigna no domínio antigo. Após verificar milhares de páginas com esta instrução incoerente, o Googlebot obedece à diretiva e despromove o novo domínio dos resultados orgânicos.

#Que erros em redireccionamentos 301 destroem uma loja WooCommerce

A definição de regras de encaminhamento exige muito mais rigor do que a adição de diretivas elementares num ficheiro .htaccess. Em catálogos com dezenas de milhares de referências, pequenos deslizes na lógica de ruting desencadeiam anomalias graves de indexação.

#Porque é que cadeias de redireccionamento e limites de CDN forçam o recuo

As plataformas modernas na edge impõem restrições técnicas que devem ser consideradas. O Cloudflare Pages, por exemplo, estabelece um limite estrito de 100 KB para o ficheiro de configuração _redirects (o equivalente a 2000 a 2500 linhas de regras estáticas). Quando se submete um ficheiro com 400 KB, o processo de compilação não falha com um alerta impeditivo, limitando-se a descartar silenciosamente todas as linhas que ultrapassem o limite de capacidade.

Assim, os primeiros 2000 artigos são reencaminhados com o código 301, enquanto os restantes 15 000 endereços de categorias e produtos geram páginas de erro 404 ou são forçados para a página inicial.

Outro problema crónico são as cadeias de redireccionamento sucessivas:

URL Antigo -> URL Novo (HTTP) -> URL Novo (HTTPS sem www) -> URL Novo (HTTPS com www e barra final)

Segundo a documentação do Google sobre erros HTTP, o Googlebot segue no máximo 10 saltos de redireccionamento ao rastrear conteúdo web, e a ferramenta de inspecção de URLs não segue redireccionamentos de todo. O guia de mudança de sítio desaconselha também as cadeias: cada URL antigo deve ser reencaminhado directamente para o destino final. Cada salto intermédio é um pedido HTTP adicional antes de chegar ao conteúdo, multiplicado por cada URL do catálogo.

#Como reencaminhar navegação facetada e parâmetros de filtragem correctamente

Lojas WooCommerce geram milhares de permutações de URLs através de parâmetros de consulta:

• ?filter_cor=preto
• ?filter_tamanho=xl&min_price=100
• ?marca=fabricante-a

Um erro recorrente de planeamento reside na tentativa de mapear cada parâmetro individual em ficheiros de reescrita estáticos. Esta abordagem sobrecarrega a memória dos servidores web. A resposta de engenharia adequada passa pela adopção de regras dinâmicas no Nginx:

# Configuração do Nginx no alojamento antigo: preservação de caminhos e parâmetros
server {
    listen 443 ssl http2;
    server_name antiga-loja.pt www.antiga-loja.pt;

    ssl_certificate /etc/ssl/certs/antiga-loja.crt;
    ssl_certificate_key /etc/ssl/private/antiga-loja.key;

    # Encaminhamento directo 1:1 com manutenção de caminhos e argumentos
    location / {
        return 301 https://nova-loja.pt$request_uri;
    }
}

Através da variável $request_uri, uma consulta dirigida a https://antiga-loja.pt/categoria/calcado/?filter_cor=preto é transferida instantaneamente para https://nova-loja.pt/categoria/calcado/?filter_cor=preto num único salto de rede, salvaguardando a relevância semântica.

#Como migrar a base de dados do WooCommerce sem corromper taxonomias

A base de dados do ecossistema WordPress adota formatos específicos para retenção de parâmetros. Preferências de sistema, configurações de blocos Gutenberg e metadados de catálogo são guardados sob a forma de objectos serializados em PHP.

#Porque é que comandos SQL directos destroem dados serializados em PHP

Uma cadeia serializada em PHP integra referências explícitas ao tamanho do texto. Observe-se um registo simplificado na tabela wp_options:

s:21:"https://antiga-loja.pt";

O prefixo s:21 informa que a cadeia seguinte contém precisamente 21 caracteres. Caso seja executada uma instrução genérica em phpMyAdmin ou MySQL:

-- CONSULTA PREJUDICIAL: CORROMPE DADOS SERIALIZADOS EM PHP
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'antiga-loja.pt', 'nova-loja-online.pt');

O novo endereço nova-loja-online.pt possui 19 caracteres, mas o indicador na base de dados permanece inalterado em s:21. Quando o WordPress tenta interpretar o valor através da função unserialize(), o motor de PHP acusa uma quebra de formato e devolve um valor nulo. Em consequência, perdem-se as chaves das plataformas de pagamento, as definições de portes de envio voltam ao estado padrão e o design das páginas criadas no editor de blocos é danificado.

#Script WP-CLI completo para alterar o domínio com segurança na base de dados

O procedimento padrão para actualização de domínios em WordPress é a utilização do utilitário de terminal WP-CLI. Esta ferramenta carrega as entradas serializadas para a memória, procede à substituição dos termos, recalcula os valores de comprimento e serializa novamente a informação antes de consolidar a escrita no MySQL.

O script em Bash que se segue automatiza toda a rotina, assegurando a realização de cópias de salvaguarda e a limpeza da cache do sistema:

#!/usr/bin/env bash
# Migração segura de domínio em WooCommerce com recurso a WP-CLI
set -euo pipefail

OLD_DOMAIN="antiga-loja.pt"
NEW_DOMAIN="nova-loja.pt"
WP_PATH="/var/www/nova-loja/public"

echo "=== A iniciar rotina de migração da base de dados ==="

# 1. Cópia de segurança preventiva da base de dados
wp db export "${WP_PATH}/backup-pre-migration-$(date +%F).sql" --path="${WP_PATH}"

# 2. Execução preliminar de validação (Dry Run)
echo "A verificar correspondências na base de dados (Dry Run)..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --dry-run \
    --path="${WP_PATH}"

# 3. Substituição efectiva de endereços sob protocolo HTTPS
echo "A aplicar a substituição para endereços HTTPS..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --recurse-objects \
    --path="${WP_PATH}"

# 4. Substituição do domínio simples ignorando a coluna GUID
wp search-replace "${OLD_DOMAIN}" "${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --skip-columns=guid \
    --path="${WP_PATH}"

# 5. Regeneração das regras de ligações permanentes
echo "A redefinir as regras de permalinks..."
wp rewrite flush --hard --path="${WP_PATH}"

# 6. Limpeza de caches em memória (Redis / Memcached)
wp cache flush --path="${WP_PATH}"

echo "=== Migração de dados concluída sem erros ==="

A instrução --skip-columns=guid é indispensável. Segundo os padrões de desenvolvimento do núcleo do WordPress, o campo guid na tabela wp_posts funciona como identificador único global para agregadores de conteúdos e nunca deve ser alterado em processos de mudança de domínio.

#Durante quanto tempo deve manter o sitemap XML e o servidor antigo activos

Uma das decisões operacionais mais desfavoráveis consiste em desactivar o servidor antigo ou não renovar o registo do domínio decorridos apenas seis meses sobre a migração.

A documentação do Google Search Central estipula expressamente que a infraestrutura de redireccionamentos tem de se manter funcional por um período mínimo de 12 meses. No sector do comércio electrónico, o procedimento mais prudente consiste em manter o domínio e as rotas activas indefinidamente. Um domínio expirado pode ser adquirido por redes de criação de ligações abusivas, contaminando a autoridade que a sua empresa demorou anos a edificar.

Além disso, o domínio anterior deve manter acessível um sitemap XML independente com a totalidade dos endereços históricos:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Mapa XML em antiga-loja.pt com relação de páginas redireccionadas -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://antiga-loja.pt/produto/computador-portatil/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
  <url>
    <loc>https://antiga-loja.pt/categoria/informatica/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Este mapa de páginas deve ser mantido activo na propriedade correspondente ao domínio antigo no Google Search Console. Esta medida fornece ao Googlebot um roteiro claro de caminhos a visitar com regularidade para validar a estabilidade das directivas 301 Moved Permanently.

#Como analisar os registos do servidor e identificar a reversão no Search Console

A detecção precoce de anomalias permite prevenir prejuízos de faturação na loja online. Quando uma operação de transição começa a desmoronar-se, os primeiros avisos manifestam-se nos ficheiros de registo do servidor semanas antes de qualquer alteração visível nos rankings.

#Que anomalias monitorizar no relatório de indexação do Search Console

No painel do Google Search Console, acompanhe de perto estes três indicadores:

1. Relatório de indexação de páginas no novo domínio: Crescimento repentino de estados como Rastreada: actualmente não indexada ou Duplicado: o utilizador não indicou um URL canónico. Este comportamento reflecte a hesitação do Googlebot em aceitar os novos recursos no índice activo.
2. Relatório de desempenho da propriedade antiga: Se a contagem de impressões no domínio anterior começar a subir após meses sem expressão estatística, significa que o Google está novamente a entregar URLs antigos aos utilizadores.
3. Ferramenta de inspecção de URLs: Verificação das principais fichas de catálogo. Se o campo URL canónico seleccionado pela Google mencionar o domínio antigo, enquanto o campo URL canónico indicado pelo utilizador contiver o novo, o sítio web encontra-se num impasse canónico.

#Como acompanhar códigos de estado HTTP no Cloudflare Logpush e Nginx

O escrutínio dos registos de pedidos proporciona uma leitura em tempo real das ações do crawler. Com este comando de consola pode filtrar as chamadas do Googlebot no servidor antigo:

# Filtrar registos Nginx por códigos de resposta atribuídos ao Googlebot
awk -F'"' '$6 ~ /Googlebot/ { print $1, $2, $3 }' /var/log/nginx/antiga-loja.access.log \
  | awk '{ print $1, $6, $7 }' \
  | sort | uniq -c | sort -nr | head -n 30

Num cenário adequado, todos os registos devem evidenciar o código de resposta 301. Qualquer presença de códigos 200, 302, 404 ou 502 para acessos ao domínio anterior sinaliza erros de ruting que exigem correcção imediata.

#O que fazer com ligações internas em blocos Gutenberg e campos ACF

Um factor preponderante na anulação de processos de migração em WordPress decorre de hiperligações internas esquecidas. Mesmo após uma intervenção cuidada com wp search-replace, vários URLs antigos podem subsistir em locais de armazenamento especializados, tais como campos em Base64, esquemas JSON na tabela wp_termmeta ou em modelos de apresentação estáticos.

Convirá passar em revista os seguintes pontos:

• Menus de navegação: Na secção Apresentação -> Menus, certifique-se de que nenhum item do tipo Hiperligação personalizada retém referências a antiga-loja.pt.
• Modelos de bloco (Full Site Editing): Ficheiros HTML integrados nas pastas /templates e /parts que possam incluir links estáticos para termos e condições ou páginas institucionais.
• Campos flexíveis do ACF: É frequente as páginas principais armazenarem relações sob a forma de identificadores, mas em caixas de texto com formatação (WYSIWYG) encontram-se com regularidade links inseridos de forma manual.
• Módulos de finalização de compra: Confirme que as opções de pagamento e de portes de envio não possuem URLs de retorno antigos gravados nas suas configurações.

Para auditar o código HTML processado na nova loja à procura de menções antigas, utilize um crawler de terminal:

# Varrer o novo catálogo online em busca de ligações para o domínio antigo
wget --spider --recursive --no-verbose --output-file=wget-scan.log https://nova-loja.pt || true
grep "antiga-loja.pt" wget-scan.log || echo "Nenhuma referência directa ao domínio antigo foi encontrada."

#Como recuperar o sítio web em 7 passos se o Google reverter a migração

Caso a sua loja online tenha sido vítima de um recuo de migração e os resultados de pesquisa estejam a devolver os URLs antigos, siga este plano de recuperação:

+-------------------------------------------------------------------+
|               PLANO DE RECUPERAÇÃO DE MIGRAÇÃO ANULADA            |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ PASSO 1: Auditar cabeçalhos HTTP e eliminar ciclos 301 ]
                 (Assegurar que cada URL antigo devolve 301 directo)
                                  |
                                  v
        [ PASSO 2: Validar etiquetas rel canonical no novo sítio ]
               (Nenhuma página pode referenciar o domínio antigo)
                                  |
                                  v
       [ PASSO 3: Solucionar erros soft 404 no catálogo online ]
               (Produtos sem stock devem responder com código 200)
                                  |
                                  v
      [ PASSO 4: Refazer a substituição de ligações na base ]
               (Verificar menus, campos ACF, widgets e rodapés)
                                  |
                                  v
         [ PASSO 5: Actualizar e reenviar sitemaps em XML ]
               (Submeter sitemaps em ambas as contas no Search Console)
                                  |
                                  v
       [ PASSO 6: Renovar o pedido de alteração de endereço no GSC ]
               (Reactivar o procedimento após a resolução técnica)
                                  |
                                  v
      [ PASSO 7: Dinamizar sinais externos para o novo domínio ]
               (Actualizar Google Perfil de Empresa e canais sociais)

1. Auditoria de cabeçalhos HTTP: Recorra ao utilitário cURL para confirmar que cada rota do domínio antigo responde de imediato com o código 301 para o endereço correspondente no novo sítio, eliminando nós intermediários.
2. Correcção de etiquetas rel canonical: Inspeccione o código fonte no novo domínio. A directiva canónica tem de coincidir rigorosamente com o URL actual, incluindo o protocolo seguro HTTPS e as normas de barra final.
3. Eliminação de estados soft 404: Avalie o relatório de páginas com falhas de conteúdo no Search Console. Em WooCommerce, artigos sem stock devem responder com o código 200 OK, aviso explícito de indisponibilidade e sugestões alternativas, evitando ecrãs vazios de erro.
4. Saneamento da base de dados: Realize uma verificação exaustiva com wp search-replace utilizando os parâmetros --precise e --all-tables, atestando a erradicação de qualquer menção residual ao endereço antigo.
5. Gestão de sitemaps combinados: Garanta que o sitemap do novo sítio reúne apenas URLs canónicos e funcionais com resposta 200 OK, mantendo no domínio antigo um sitemap exclusivo para os caminhos redireccionados.
6. Revalidação da mudança de endereço: Se já tiverem decorrido 180 dias sobre a submissão inicial, renove o pedido de alteração de endereço no Search Console logo após sanar todas as incorrecções de engenharia.
7. Reforço de sinais exteriores: Actualize os endereços oficiais no Google Perfil de Empresa, portais de pagamento, contas de redes sociais e registos empresariais, fornecendo sinais externos consistentes sobre a nova identidade digital.

#Conclusão técnica para arquitectos de software e gestores de lojas online

A reversão de uma migração de domínio pelo Google é um aviso técnico indiscutível: os motores de busca detectaram incongruências substantivas entre a intenção declarada da transição e o estado real da infraestrutura.

Em ambientes modernos de comércio electrónico, o êxito de uma mudança de domínio alicerça-se no rigor operacional:

• Os redireccionamentos devem operar num único salto e manter integralmente os parâmetros de navegação facetada.
• A base de dados do WordPress e WooCommerce deve ser actualizada com WP-CLI para preservar as estruturas serializadas em PHP.
• As etiquetas canónicas e a estrutura de ligações internas têm de apontar exclusivamente para o novo endereço desde o momento da activação do DNS.
• O domínio anterior, o respectivo certificado de segurança SSL e o mapa XML específico devem permanecer em funcionamento durante pelo menos 12 meses.

Antes de avançar para a viragem definitiva de servidores, consulte a nossa avaliação de migração WordPress para despistar anomalias de redireccionamento e divergências estruturais.

Com a aplicação consistente destas regras técnicas, elimina o risco de retrocesso na indexação e salvaguarda a continuidade de vendas da sua loja online.