Numa migração do PrestaShop 1.7 para 8, numa mudança de tema, numa reorganização da árvore de categorias ou simplesmente numa alteração do slug de um produto, centenas ou milhares de URL mudam em silêncio. Cada um desses URL acumula autoridade SEO e ligações externas, e talvez figure nos resultados da Google com boa classificação. Sem redirecionamento 301 para o novo URL, esse capital desaparece.
O pior: a perda não é imediata. Vê o tráfego cair devagar durante 3 a 6 semanas, sem incidente claro. Quando percebe, perdeu 30 % a 50 % do tráfego SEO e vai precisar de 6 a 12 meses para o recuperar, se conseguir.
Este artigo disseca a mecânica dos redirecionamentos 301 no PrestaShop: o que o nativo faz, o que falha, como montar uma monitorização de 404 limpa, e como automatizar o reflexo «mudança de slug, redirecionamento 301».
Porque é que os redirecionamentos 301 são críticos para o SEO
Um redirecionamento 301 («Moved Permanently») diz à Google e aos utilizadores: este URL mudou definitivamente, este é o novo endereço. A Google transmite então o PageRank, o histórico do URL e os backlinks acumulados. O novo URL herda o capital SEO.
Sem 301, o URL inicial devolve um 404 («Not Found»). A Google põe a página na fila de desindexação, os backlinks apontam para o vazio, o PageRank dissipa-se. Ao fim de 3 a 6 meses, o URL é retirado do índice. O capital está perdido.
Alguns números de auditoria, numa loja pós-migração sem gestão de 301 limpa:
- 40 % a 60 % dos URL indexados na Google respondem 404 em 6 meses.
- O tráfego SEO cai 25 % a 50 % no trimestre seguinte.
- As posições nas pesquisas de cauda longa (muitas vezes as mais rentáveis) desabam primeiro.
- Os backlinks externos (imprensa, blogues, diretórios) ficam obsoletos e perdem o seu valor.
O que o PrestaShop gere de origem (e o que falha)
O módulo SEO e URL nativo
O PrestaShop 8 e 9 propõe um separador «Redirecionamentos» em Preferências > Tráfego > SEO e URL. Permite acrescentar à mão redirecionamentos 301, 302 ou 410 por par (URL de origem, URL de destino).
Limites:
- Sem gestão por regex ou wildcard. Para redirecionar toda uma categoria antiga
/produtos-antigos/*para/promocoes/, é preciso criar à mão cada URL. - Sem redirecionamento automático na mudança de slug. Se alterar o slug de um produto, o URL antigo passa a 404 sem redirecionamento.
- Sem monitorização dos 404 nos URL efetivamente visitados.
- Desempenho limitado. Acima de alguns milhares de redirecionamentos, o módulo atrasa o roteamento.
- Sem importação nem exportação em CSV para gerir em massa.
O ficheiro .htaccess
Alternativa manual: escrever regras RewriteRule no .htaccess. Rápido (o Apache trata as regras a montante), mas:
- Sensível aos erros de sintaxe (uma vírgula mal colocada e todo o site cai em 500).
- Difícil de manter para os não técnicos.
- Não funciona em Nginx (que usa a sua própria sintaxe).
- Sem interface no back-office nem rastreabilidade.
A stack que devia ter
1. Redirecionamento automático na mudança de slug
Quando um produto, uma categoria ou uma página CMS muda de slug, o URL antigo deve registar automaticamente um 301 para o novo. Sem manipulação manual, sem risco de esquecimento. É a rede de segurança número um.
2. Monitorização dos 404
Todos os URL que caem em 404 devem ser registados com a sua frequência e o seu referenciador. Um URL chamado 200 vezes por mês em 404 é um bug a tratar em prioridade. Um URL em 404 uma vez por ano pode esperar.
3. Redirecionamentos em massa por regex e wildcard
Nas migrações, precisamos de padrões. /categoria-antiga/(.*) → /categoria-nova/$1 tem de poder ser configurado numa regra, não em 200 entradas.
4. Importação e exportação CSV
Antes de uma migração, prepara-se a tabela de correspondência em CSV a partir da exportação do sitemap antigo e do sitemap novo. Importa-se de uma vez em vez de introduzir à mão.
5. Deteção das cadeias de redirecionamento
Um URL que redireciona para um URL que redireciona para um URL é um antipadrão de SEO. A Google desvaloriza as cadeias com mais de 2 saltos. Uma boa ferramenta deteta e sinaliza as cadeias.
6. Rastreabilidade e auditoria
Quem criou este redirecionamento, quando, com que motivo? Em caso de problema (queda de tráfego pós-migração), poder auditar as regras 301 é crucial.
O caso particular da mudança de slug de produto
Numa loja ativa, os slugs mudam constantemente. Um produto cujo nome evolui («Vestido verão 2025» para «Vestido de linho verão 2025»), uma otimização SEO do título, uma correção de gralha: cada alteração do link_rewrite em ps_product_lang muda o URL canónico.
Se o 301 não for criado automaticamente, o URL antigo cai em 404. Em 12 meses, num catálogo de 5000 produtos com 10 % de slugs alterados, são 500 URL «perdidos». Se cada um drenava em média 50 visitas por mês, falamos de 25 000 visitas SEO perdidas por ano, sem incidente visível.
O reflexo correto: um hook em actionObjectProductUpdateAfter que deteta a alteração de link_rewrite e cria o 301 automaticamente, por língua e por loja em multiloja.
A armadilha das cadeias de redirecionamento
Cenário clássico: um produto A muda de slug 3 vezes em 6 meses. Sem gestão fina, fica-se com:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
Um pedido ao primeiro URL faz 3 saltos antes de chegar. A Google desvaloriza as cadeias com mais de 2 redirecionamentos. O crawl budget é consumido inutilmente, e o PageRank dissipa-se a cada salto (perda de 5 % a 10 % por salto segundo os estudos da Moz).
A regra: achatar as cadeias. Quando é criado um redirecionamento novo, o sistema deve verificar se o URL de origem já era destino de outro 301, e reescrever o antigo para apontar diretamente ao novo destino. Sem cadeia, sem salto.
O nosso módulo dfredirects: gestor de 301 completo
Implementar esta stack à mão exige 7 a 12 dias de desenvolvimento no PrestaShop, mais a manutenção. O nosso módulo dfredirects para PrestaShop 8 e 9 industrializa toda a mecânica:
- Redirecionamentos 301, 302 e 410 configuráveis no back-office, com interface filtrável e paginada.
- Padrões regex e wildcard: uma regra pode cobrir centenas de URL (
/cat-antiga/(.*)$ → /cat-nova/$1). - Redirecionamento automático na mudança de slug de produto, categoria, fabricante, fornecedor e CMS, multilingue e multiloja.
- Monitorização dos 404 com frequência, última visita e referenciador. Ordenação por volume para priorizar.
- Achatamento automático das cadeias: sem redirecionamentos em cascata.
- Importação e exportação CSV para gerir em massa antes de uma migração.
- Rastreabilidade: autor, data e motivo opcional por regra.
- Compatível com PS 8 e 9, sem dependência do Apache ou do .htaccess (funciona também em Nginx).
- Desempenho: tabela otimizada com índices, até 100 000 regras sem degradação.
Por 49 €, evita a perda de tráfego pós-migração e instala uma rede de segurança duradoura contra a deriva dos 404.
Procedimento de migração seguro para o SEO
Passo a passo, o procedimento que aplicamos nas migrações PrestaShop 1.7 para 8 ou nas refundições importantes:
- Antes da migração: exportação do sitemap.xml antigo. Contém todos os URL indexados.
- Rastreio completo do site antigo com o Screaming Frog ou equivalente, para recuperar todos os URL (incluindo páginas fora do sitemap: filtros, paginações).
- Mapeamento antigo para novo em CSV: cada URL antigo recebe o seu URL novo. Nos URL desaparecidos, escolher um destino alternativo relevante (categoria-mãe, página inicial em último recurso).
- Importação do CSV no dfredirects antes ou durante a mudança.
- Teste: 50 URL aleatórios verificados em 301 diretos, sem cadeia, para o destino certo.
- Submissão do novo sitemap.xml na Google Search Console.
- Monitorização diária dos 404 durante o primeiro mês: qualquer 404 recorrente é convertido em 301.
- Auditoria aos 30, 60 e 90 dias: cobertura na Search Console, pesquisas perdidas, verificação da estabilidade do tráfego.
FAQ
Qual é a diferença entre 301 e 302?
O 301 é definitivo e transmite o PageRank. O 302 é temporário e não transmite. Numa migração ou numa mudança de slug, usar sempre 301. O 302 fica reservado aos casos explicitamente temporários: manutenção, teste A/B, redirecionamento sazonal.
E o 410 (Gone)?
O 410 diz à Google: este URL já não existe e não voltará, desindexa de imediato. Mais rápido do que o 404 para limpar o índice. Útil para os produtos definitivamente retirados sem equivalente. Mas a usar com parcimónia: uma vez devolvido o 410, o PageRank perde-se.
Quanto tempo demora a Google a ter em conta um 301?
O rastreio do URL antigo pela Google pode demorar de alguns dias a várias semanas, consoante a frequência de rastreio. A transmissão completa do PageRank para o novo URL leva na prática 1 a 3 meses. Submeter o novo sitemap acelera o processo.
Pode-se redirecionar para HTTPS e mudar de domínio ao mesmo tempo?
Sim, e é até frequente. Um 301 pode combinar protocolo (HTTP para HTTPS), domínio (antigo.pt para novo.pt) e caminho. A regra: um único 301 por URL, não uma cadeia. Achatar ao máximo.
Os redirecionamentos afetam o desempenho?
Um 301 simples acrescenta cerca de 100 a 200 ms ao tempo de resposta no primeiro pedido. Com cache no navegador (Cache-Control no 301), as visitas seguintes vão diretamente ao novo URL sem o salto. O custo é negligenciável fora das cadeias múltiplas. Uma cadeia de 3 saltos, pelo contrário, pode acrescentar 500 ms, daí o achatamento.
Para ir mais longe
A gestão dos redirecionamentos é um dos pilares da migração segura para o SEO. Veja também a nossa checklist completa de migração PrestaShop 1.7 para 8, em que os 301 são a etapa 8 do procedimento, e o nosso guia SEO para e-commerce 2026 para o quadro completo do SEO no PrestaShop. Três artigos complementares sobre o mesmo tema: preparar, executar, proteger.
Leia também: Indexing API, IndexNow e bots de IA.
Para passar à ação: a nossa seleção de módulos de SEO técnico para PrestaShop.
