Migração do PrestaShop 1.6 para a 8: não perder o SEO

O principal risco não é o que se pensa

Numa migração a partir do PrestaShop 1.6, a preocupação recai naturalmente sobre os dados: vamos perder encomendas, clientes, produtos? Na prática, esses dados passam razoavelmente bem. O que se perde, e não volta sozinho, é o tráfego orgânico.

A estrutura dos URL muda entre a 1.6 e as versões modernas. Sem um plano de redirecionamentos, cada URL indexado passa a ser um 404. A Google desindexa, as posições conquistadas desaparecem e depois são precisos meses para recuperar. É por isso que uma migração bem-sucedida do ponto de vista técnico pode continuar a ser um fracasso comercial.

O caminho de versões é obrigatório

Primeira regra: não existe salto direto da 1.6 para a 8. Os scripts de migração aplicam-se de forma incremental e saltar patamares deixa a base de dados num estado incoerente.

O caminho é: 1.6.1.x → 1.7.8.x → 8.x (e depois 9.x, se for o caso).

Cada patamar tem de ser verificado antes de passar ao seguinte: o back-office carrega, é possível fazer uma encomenda, os produtos aparecem. Uma base migrada depressa demais produz erros que só surgem ao fim de várias semanas, em funcionalidades periféricas.

As seis perdas clássicas

1. O tema. Um tema 1.6 não funciona na 1.7 nem nas versões seguintes. O motor de templates mudou de versão e a estrutura dos ficheiros de produto foi totalmente refeita. Não há conversão automática: o tema é refeito ou substituído.

2. Todos os overrides. A pasta override/ tem de recomeçar do zero. As classes personalizadas mudaram de assinatura e um override da 1.6 mantido provoca um erro fatal. Também é uma oportunidade: metade dos overrides corresponde a necessidades abandonadas há muito tempo.

3. Os módulos 1.6. Os hooks foram renomeados (o hookHeader passou a hookDisplayHeader, por exemplo) e a arquitetura dos módulos evoluiu. Cada módulo tem de ser substituído pela versão moderna ou reescrito.

4. Os comentários de produto. O módulo productcomments muda de esquema. As avaliações dos clientes não são recuperadas automaticamente: têm de ser migradas por script, tabela a tabela. Este conteúdo tem valor real para o SEO, não o deixe de lado.

5. As imagens de produto. A regeneração das miniaturas a partir de Design > Definições de imagens ultrapassa o tempo de execução permitido acima de alguns milhares de imagens. Resultado: produtos sem imagem no front-office. É preciso passar pela linha de comandos ou processar por lotes.

6. Os blocos CMS e os conteúdos estáticos. Páginas CMS, blocos de confiança, conteúdos da página inicial: consoante os módulos usados na 1.6, esses conteúdos vivem em tabelas que já não existem. Devem ser exportados antes e reintroduzidos depois.

O plano de SEO, passo a passo

É a parte que merece mais atenção.

Antes da migração

1. Exportar todos os URL indexados. Cruze três fontes: um rastreio completo do site, a exportação das páginas da Search Console sobre 16 meses e o sitemap atual. A Search Console é indispensável: revela URL que o rastreio já não encontra mas que continuam a receber tráfego.
2. Registar as posições. Um retrato dos termos posicionados antes da mudança é o seu único ponto de comparação objetivo depois.
3. Construir a tabela de correspondência. Cada URL antigo tem de apontar para o equivalente novo. Os produtos eliminados vão para a respetiva categoria, nunca para a página inicial: um redirecionamento em massa para a página inicial é tratado pela Google como um erro suave.

Durante a migração

4. Implementar os redirecionamentos 301 ao nível do servidor, e não através de um módulo, quando os volumes são grandes. Um redirecionamento em PHP sobre 40 000 URL pesa no desempenho.
5. Verificar as etiquetas canónicas e o ficheiro robots.txt. Uma pré-produção em noindex colocada em produção sem retirar a diretiva é uma catástrofe clássica e perfeitamente evitável.

Depois da migração

6. Submeter o novo sitemap e vigiar diariamente o relatório de cobertura durante um mês.
7. Seguir os 404 reais nos registos do servidor, e não apenas na Search Console, que reporta com atraso. Cada 404 recorrente num URL que recebia tráfego é um redirecionamento esquecido.

Que prazos prever

Uma migração da 1.6 para a 8 com refazer do tema e substituição dos módulos conta-se em semanas, não em dias. A rubrica mais pesada é quase sempre o tema, seguida da recuperação dos desenvolvimentos específicos.

O melhor investimento continua a ser a auditoria prévia: inventário dos módulos, dos overrides, dos templates personalizados e dos URL indexados. Transforma um orçamento aproximado num plano de trabalho e revela muitas vezes que a obra é mais leve do que se anunciava.

Se já está na versão 8 e hesita sobre o passo seguinte, leia o nosso artigo sobre o fim de suporte do PrestaShop 8.

Migrar a sua loja

Encarregamo-nos da migração completa, incluindo o plano de redirecionamentos, com acompanhamento do tráfego orgânico depois da mudança. Veja a página de migração PrestaShop.