Como Migrar um Site Multilingue Sem Perder SEO

O tráfego normalmente não desaparece porque o Google ficou confuso. Desaparece porque uma migração multilingue foi tratada como um simples redesign, e alguém se esqueceu de que cada versão de idioma tem os seus próprios URLs, sinais, canonicals e caminhos de ligações internas. Se quer migrar um site multilingue sem perder SEO, precisa de um plano que trate a localização como arquitectura, e não como decoração.

Isto complica-se rapidamente no WordPress. Um plugin armazena os URLs traduzidos de uma forma, outro reescreve os slugs de maneira diferente, e um terceiro injeta tags hreflang com a sua própria lógica. Depois alguém muda a estrutura do domínio, coloca o novo site em produção numa sexta-feira, e passa o mês seguinte a perguntar-se porque é que as páginas de produto em francês caíram a pique. Nada disto é misterioso. Normalmente é apenas evitável.

Por que razão as migrações multilingues quebram o SEO com tanta facilidade

Uma migração de idioma único já é frágil. Acrescente múltiplos idiomas e estará a migrar grupos de páginas equivalentes, URLs alternativas, segmentação regional, metadados traduzidos, ligações internas e, frequentemente, muito conteúdo de aparência duplicada que os motores de busca só compreendem graças aos sinais que o rodeiam.

O maior erro é assumir que as classificações residem apenas no conteúdo da página. Não residem. Residem na configuração completa — estrutura de URL, indexabilidade, canonicals, hreflang, redireccionamentos, consistência do sitemap, e se o Google ainda consegue perceber qual a página em inglês que corresponde a qual versão em espanhol ou alemão.

Se um único destes elementos falhar em escala, o dano propaga-se. Um canonical incorreto pode eliminar uma pasta de idioma inteira. Redireccionamentos em falta podem destruir ligações antigas com autoridade. Um hreflang incorreto pode enviar a página errada para o mercado errado. E se os slugs traduzidos mudarem sem um mapa de redireccionamento limpo, está essencialmente a pedir ao Google que comece do zero.

Antes de migrar um site multilingue sem perder SEO

Não comece pelo design. Comece pelo inventário.

Faça um crawl ao site actual e exporte todos os URLs indexáveis de cada idioma. Inclua títulos, meta descriptions, canonicals, códigos de estado, referências hreflang, entradas no sitemap XML e ligações internas, se o seu crawler as suportar. Se estiver a migrar de uma camada de tradução alojada ou de uma plataforma de tradução SaaS, documente o formato exacto de URL que está a ser utilizado actualmente. Isso inclui subpastas, subdomínios, parâmetros, slugs traduzidos e URLs de media, caso estes também estejam localizados.

De seguida, mapeie cada URL antigo para um novo destino. Não apenas templates. Cada URL. Páginas de categoria, arquivos paginados, páginas de produto, artigos de blog, páginas iniciais por idioma, páginas de conta e quaisquer landing pages de alto valor criadas para pesquisa paga ou orgânica. Se uma página vai ser removida, decida se deve redirecionar para um equivalente próximo, devolver 410 ou simplesmente desaparecer. Decidir mais tarde é a forma como se criam cadeias de redireccionamento e tráfego órfão.

É também neste ponto que decide o que não vai alterar. Se os URLs multilingues actuais já têm boas classificações, mantenha-os. Uma migração não é o momento de ser criativo com slugs mais limpos ou uma nova arquitectura de idiomas, a menos que haja um benefício real. A estabilidade vence.

Escolha a estratégia de URL correcta e mantenha-a

Existem apenas algumas opções sensatas para SEO multilingue: subpastas, subdomínios ou domínios por país. No WordPress, as subpastas são frequentemente as mais fáceis de gerir e preservam bem a autoridade, mas isso não as torna automaticamente correctas para todas as configurações.

O que mais importa durante uma migração é a consistência. Se o seu site antigo usa /es/ e /de/, não mude casualmente para es.example.com só porque alguém acha que parece mais empresarial. Isso cria um segundo problema de migração por cima do primeiro. O mesmo conteúdo, nova estrutura, novos sinais, mais pontos de falha.

Há casos em que uma mudança de URL vale a pena. Talvez a plataforma antiga usasse query strings feias, ou talvez as páginas traduzidas fossem servidas por proxy de uma forma que nunca lhe deu verdadeira propriedade. Está bem. Seja apenas honesto quanto ao custo. Quanto maior for a mudança estrutural, mais rigoroso tem de ser o mapeamento de redireccionamentos e o QA pós-lançamento.

Os redireccionamentos não são uma tarefa de limpeza

Os redireccionamentos são a migração.

Se alterar sequer um padrão de URL multilingue, crie uma folha de redireccionamentos que emparelhe cada URL antigo com um destino final. Use redireccionamentos 301. Evite saltos de redireccionamento. Evite discrepâncias de idioma, a menos que não haja alternativa. Uma página de produto em espanhol antiga não deve enviar os utilizadores para a página inicial em inglês só porque a equipa de migração ficou sem tempo.

Isto é importante para utilizadores e crawlers, mas também para a receita. As lojas WooCommerce com páginas de produto multilingues têm frequentemente backlinks a apontar para SKUs localizados, páginas de categoria e conteúdo de blog. Perca essas rotas e não está apenas a perder classificações. Está a desperdiçar link equity que já pagou através de conteúdo, relações públicas e tempo.

Se está a abandonar uma plataforma de tradução por subscrição, certifique-se de que consegue preservar os URLs exactos voltados para SEO que as pessoas já visitam. É aqui que a propriedade importa. Algumas ferramentas de migração, incluindo configurações construídas à volta do TrueLang, foram concebidas especificamente para transferir URLs multilingues e manter a estrutura SEO intacta, em vez de o forçar a um recomeço.

Hreflang, canonicals e indexabilidade precisam de uma auditoria rigorosa

É aqui que muitas migrações falham silenciosamente.

O hreflang precisa de apontar para equivalentes reais e indexáveis entre idiomas. Cada página do grupo deve referenciar correctamente as outras, incluindo a si própria. Os códigos de idioma e região têm de ser válidos. Se usar x-default, use-o intencionalmente, não porque um plugin o adicionou por predefinição.

Os canonicals precisam de ainda mais atenção. O canonical numa página traduzida deve normalmente apontar para si própria, e não para a versão no idioma de origem. Se a sua página em espanhol aponta canonicamente para o original em inglês, está a dizer ao Google que a página em espanhol é a cópia que deve ignorar. Este erro é comum, devastador e completamente evitável.

De seguida, verifique a indexabilidade ao nível do template. Tags noindex, pastas bloqueadas, resquícios de staging, pedidos de palavra-passe acidentais e problemas de renderização JavaScript podem afectar uma secção de idioma sem tocar nas outras. Não pode assumir que o facto de a versão em inglês ser crawlável significa que a versão em italiano está bem.

A paridade de conteúdo importa mais do que as pessoas admitem

Uma migração multilingue não é apenas plumbing técnico. Os motores de busca comparam equivalentes. Se a página antiga em alemão tinha title tags optimizadas, conteúdo no corpo, FAQs e ligações internas, mas a nova está traduzida por máquina com formatação removida e metadados em falta, as classificações podem cair mesmo que os redireccionamentos sejam perfeitos.

Isto não significa que cada palavra tem de corresponder à versão antiga. Por vezes uma actualização ajuda. Mas a intenção, a estrutura e a optimização on-page devem ser preservadas. Preserve os campos de SEO traduzidos onde têm bom desempenho. Preserve o texto alternativo das imagens onde for relevante. Preserve os dados estruturados, se existirem em cada idioma. Preserve as ligações internas dentro do conteúdo traduzido, especialmente se apontarem para páginas de destino localizadas.

Esta é uma das razões pelas quais muitos proprietários de sites abandonam plataformas inchadas. Percebem que na verdade não possuem uma configuração multilingue limpa e editável. Alugaram-na. E então a migração transforma-se em arqueologia.

O dia do lançamento é para verificação, não para esperança

Quando o novo site entrar em produção, verifique os URLs em directo de imediato. Não amanhã. Não depois do fim-de-semana.

Teste a sua lista de redireccionamentos com respostas reais. Faça um crawl ao novo site por idioma. Inspeccione o output do hreflang. Verifique os canonicals. Valide os sitemaps XML. Certifique-se de que os URLs antigos resolvem correctamente e que as novas páginas devolvem códigos de estado 200. Faça verificações pontuais nas ligações internas em menus, selectores de idioma, breadcrumbs, produtos, blogs e fluxos transaccionais como o carrinho e o checkout.

De seguida, abra a Search Console e observe as alterações de cobertura, anomalias de crawl e erros de hreflang. Compare o número de URLs indexados por secção de idioma. Se um mercado começar a cair de forma desproporcionada, investigue rapidamente. No SEO multilingue, pequenos bugs de implementação raramente se mantêm pequenos.

Espere também alguma flutuação. Nem toda a queda significa falha. Se mudou a arquitectura, o conteúdo, o alojamento e as ferramentas de tradução todos de uma vez, o Google precisa de tempo para reprocessar os sinais. O objectivo não é movimento zero. O objectivo é movimento controlado com uma explicação clara.

O que evitar se quer que as classificações sobrevivam

Não migre, redesenhe e reescreva todas as páginas ao mesmo tempo, a menos que goste de depurar três variáveis em simultâneo.

Não deixe um plugin gerar automaticamente slugs traduzidos de forma diferente dos seus URLs indexados existentes, a menos que tenha um plano de redireccionamento para cada um deles.

Não aponte todas as páginas localizadas removidas para uma página inicial de idioma genérica. É preguiçoso, e os motores de busca sabem-no.

Não confie que o hreflang está correcto porque um plugin diz que suporta SEO multilingue. Suporte não é o mesmo que output correcto no seu site.

E não trate a propriedade como uma questão secundária. Se as suas páginas traduzidas, metadados e URLs residem dentro do sistema alugado de outra pessoa, o risco de migração aumenta. Sempre.

A jogada inteligente é aborrecida: mantenha o que já funciona, documente cada URL, mapeie cada redireccionamento, verifique cada sinal e recuse improvisar após o lançamento. É assim que se migra sem drama. É também assim que se deixa de pagar pelo lock-in de outros e se mantêm as classificações que conquistou.