SEO PrestaShop

Como o SEO funciona no PrestaShop — URLs amigáveis com tokens de ID obrigatórios, redirecionamentos canônicos configuráveis, um gerador nativo limitado de sitemap e robots.txt, sem hreflang ou schema nativos, e o ecossistema de módulos que preenche as lacunas.

Publicado pela primeira vez: 26 de jun. de 2026 · Última atualização: 23 de ago. de 2026 · Avançado
Idiomas

O PrestaShop é um ecommerce de código aberto (PHP/MySQL) que você mesmo hospeda, então oferece controle profundo, mas exige mais configuração do que concorrentes hospedados. Ele faz muita coisa certa nativamente: meta tags por objeto, URLs amigáveis (mod_rewrite obrigatório), um redirecionamento 301 configurável para o canônico, um H1 por página, opções de redirecionamento para produtos desativados e um gerador de robots.txt. O problema são seus padrões: tokens numéricos {id} são obrigatórios nas rotas de URL (removíveis apenas via módulo/sobrescrita de rota), o sitemap nativo não atualiza automaticamente e é fraco em cobertura multilíngue/imagens, e não há hreflang ou schema abrangente nativo. URLs de navegação facetada, ordenação e filtros não são canonicalizadas para você. A maioria das lacunas é preenchida por módulos de terceiros, e o Core Web Vitals nos temas padrão mais pesados é ajudado pelo recurso integrado CCC (Concatenar, Comprimir, Cache).

TL;DR — PrestaShop é um ecommerce de código aberto auto-hospedado, então você troca trabalho de hospedagem por controle profundo. Pontos fortes nativos: meta tags por objeto, URLs amigáveis (mod_rewrite obrigatório), redirecionamento configurável 301/302 para canônico, canonicalização de URL pai para combinações de produto, um H1 por página, redirecionamentos configuráveis para produtos desativados e um gerador de robots.txt. Os padrões que incomodam: o token {id} é obrigatório nas rotas de URL (removível apenas via módulo/substituição de rota), o sitemap nativo não atualiza automaticamente e é fraco em cobertura multilíngue e de imagens via CDN, e o comportamento multilíngue, de dados estruturados e de URLs filtradas deve ser verificado em relação à versão instalada, ao tema e aos módulos. O desempenho nos temas padrão mais pesados é ajudado pelo CCC integrado (Concatenate, Compress, Cache).

Evidence for this claim PrestaShop provides configurable friendly URLs, canonical redirects, and route patterns in its traffic and SEO settings. Scope: PrestaShop 8 administration; modules and version differences can change behavior. Confidence: high · Verified: PrestaShop 8: SEO and URLs Evidence for this claim Google treats canonical declarations as signals and recommends consistent canonicalization for duplicate URLs. Scope: Google canonicalization behavior applied to ecommerce URL variants. Confidence: high · Verified: Google Search Central: Canonicalization

O contexto: controle profundo, mais configuração

A maior parte do conteúdo de SEO para PrestaShop é ou uma lista de verificação genérica ou um discurso de venda de um módulo pago. O enquadramento útil é este: o PrestaShop oferece mais controle bruto do que qualquer plataforma SaaS hospedada — código aberto, acesso ao servidor, modelos de rota editáveis — mas ele entrega menos coisas prontas, então as lacunas são específicas e previsíveis. Divida tudo em duas categorias e a plataforma deixa de ser misteriosa.

Uma nota de versão antes de tudo: em meados de 2026, o PrestaShop mantém dois ramos principais ativos ao mesmo tempo9.x (9.1.4 em junho de 2026) e um ramo 8,2.x LTS que ainda está lançando suas próprias atualizações em paralelo (8.2.7, também em junho de 2026). As configurações de SEO descritas abaixo não mudam entre v8 e v9 — verificadas diretamente na documentação de SEO & URLs do PrestaShop v9 — mas um módulo criado e testado para um ramo não tem garantia de funcionar no outro. Verifique a versão compatível listada do módulo antes de instalar e confirme primeiro a versão do núcleo da sua própria loja — é o número no qual a listagem de “compatível com” de cada fornecedor de módulo se baseia.

Correto por padrão: meta títulos/descrições por objeto, URLs amigáveis, tags canônicas com redirecionamento configurável, canonização da URL pai de combinações de produto, um H1 por página, breadcrumbs, opções de redirecionamento de produto desativado, um gerador de robots.txt e um módulo nativo de sitemap.

Você precisa fazer (principalmente via módulos): URLs sem ID, hreflang para vários idiomas / várias lojas, schema abrangente de Produto/Breadcrumb/Organização/FAQ, canônico/noindex de navegação facetada, um sitemap de imagens multilíngue com atualização automática e Core Web Vitals no tema padrão.

Estrutura de URL

As configurações de URL ficam em Parâmetros da Loja → Tráfego e SEO. Ativar URLs amigáveis converte product.php?id_product=27 em um slug descritivo como /2-music-players/27-ipod-nano-green. Isso requer o Apache mod_rewrite (ou um equivalente Nginx), e você pode preservar caracteres acentuados nas URLs se quiser.

O que você precisa entender é o esquema de rota padrão. A rota de produto do PrestaShop é {category:/}{id}{-:id_product_attribute}-{rewrite}{-:ean13}.html, e os outros tipos seguem o mesmo padrão:

Tipo de páginaRota padrão
Produtos{category:/}{id}{-:id_product_attribute}-{rewrite}{-:ean13}.html
Categorias{id}-{rewrite}
Páginas CMScontent/{id}-{rewrite}
Fornecedoressupplier/{id}-{rewrite}
Marcasbrand/{id}-{rewrite}

O token {id} é obrigatório. Ele está em todas as rotas padrão porque o PrestaShop procura o objeto no banco de dados por esse ID — o slug ({rewrite}) é decorativo. Esta é a coisa mais mal compreendida sobre as URLs do PrestaShop: você não pode remover o número pelas configurações. Fazer isso de forma limpa exige um módulo de terceiros (FME Pretty URL, SunnyToo, MyPresta) que remove o ID e mantém redirecionamentos 301, ou uma substituição cuidadosa do modelo de rota que pode quebrar a funcionalidade principal se for feita errado. A reclamação da Empirical Edge de que o PrestaShop “gera URLs que contêm números e caracteres especiais indesejados” é precisa, mas os IDs servem a um propósito real — eles não são um bug, são uma chave de consulta.

Mais dois detalhes de rota que valem a pena saber: o token {category:/} injeta a categoria do produto na URL do produto por padrão (uma consideração de conteúdo duplicado se um produto estiver em várias categorias), e {-:ean13} pode anexar o EAN à URL. Desde a v1.7.5.1, você também pode ativar “Exibir atributos no meta título do produto” para criar automaticamente títulos como “Nome do Produto Cor Tamanho.”

Tags canônicas

O PrestaShop gera tags canonical automaticamente e oferece, em Tráfego e SEO, uma configuração de redirecionamento para a URL preferencial com três opções: sem redirecionamento, 301 (permanente) ou 302 (temporário). Use 301 em qualquer configuração estável de produção — esse redirecionamento consolida as variantes de URL duplicadas que o PrestaShop tende a gerar.

O comportamento nativo é realmente bom em um caso específico: combinações de produtos. Para URLs de variantes (cor, tamanho — a parte {-:id_product_attribute} da rota), a tag canonical aponta para a URL do produto principal; quando uma URL contém um ID de atributo inválido, o PrestaShop a redireciona para esse produto. Assim, as combinações de tamanho e cor não se fragmentam, por padrão, em centenas de duplicatas indexáveis.

A implementação nativa da tag canonical não cobre parâmetros de filtro, parâmetros de ordenação nem páginas de categoria paginadas. O PrestaShop não direciona ?order=price_asc nem uma URL facetada ?color=red&size=M para a categoria limpa por meio de uma tag canonical. Como explica a PrestaHero, “implementing canonical tags is one of the most important practices… as these HTML tags inform search engines of the ‘master’ version of a page when duplicate or similar content exists” (tradução) «implementar tags canonical é uma das práticas mais importantes, pois elas informam aos mecanismos de busca qual é a versão principal de uma página quando existe conteúdo duplicado ou semelhante» — nas páginas filtradas, essa implementação depende de um módulo de canonicalização ou de alterações no tema ou no código.

Conteúdo duplicado — o trabalho real

As fontes de conteúdo duplicado do PrestaShop são previsíveis. A FME Modules resume o que está em jogo: “duplicate URL issues confuse search engine crawlers, waste crawl budget, and split link equity, which collectively damage SEO performance.” (tradução) «problemas de URL duplicada confundem os rastreadores dos mecanismos de busca, desperdiçam o orçamento de rastreamento e dividem a autoridade de links, o que coletivamente prejudica o desempenho de SEO.» Os culpados usuais:

  • Navegação facetada — URLs de filtro como ?color=red&size=M, com conteúdo idêntico ou quase idêntico, sem uma tag canonical nativa.
  • Ordenação?order=price_asc acrescentado às URLs de categoria.
  • Paginação/page-2, /page-3 em categorias e na busca.
  • URLs apenas com ID ou com slug — ambas podem responder se o redirecionamento não tiver sido imposto.
  • www ou sem www / HTTP ou HTTPS — exigem uma configuração correta de redirecionamento.
  • Impressão e, em versões antigas, URLs com ID de sessão.

A correção é em camadas, não um único interruptor:

  1. Defina o redirecionamento para a URL canonical como 301 em Tráfego e SEO.
  2. Personalize o robots.txt para desautorizar parâmetros de filtro e ordenação (detalhes abaixo).
  3. Na navegação facetada, adicione um módulo de canonicalização — o recurso nativo atende produtos e combinações, mas não páginas filtradas.
  4. Trate a paginação deliberadamente. O PrestaShop já remove o bloco de título da categoria depois da página 1 para reduzir duplicação. O Google abandonou o suporte a rel=next/prev em 2019; hoje, cada página paginada deve manter sua própria URL canonical e continuar indexável — não direcione a página 2 ou posterior para a página 1, a menos que o conteúdo seja realmente duplicado. Também não aplique noindex automaticamente à paginação; reserve essa regra para variações de filtro e ordenação.

Uma nota de H1 do PrestaShop para auditores: um bug que produzia H1s duplicados em páginas de categoria foi corrigido na v1.7,5. Em instalações mais antigas, verifique isso.

Sitemap

O PrestaShop vem com um módulo nativo de Google Sitemap (do catálogo de módulos) que cobre produtos, categorias, fabricantes, páginas CMS e páginas geradas por módulos. Após gerá-lo, adicione a URL do sitemap ao robots.txt e envie-o no Google Search Console.

Os limites do módulo nativo são bem documentados e importam em escala: ele não se atualiza automaticamente quando você adiciona produtos (você regenera manualmente ou via cron), o suporte multilíngue é fraco (sitemaps por idioma precisam de um módulo de terceiros) e a indexação de imagens hospedadas em CDN é inconsistente. A FME Modules descreve a restrição diretamente: o sitemap embutido do PrestaShop “may not auto-refresh when adding products, multilingual support is weak, and CDN-hosted image indexing is inconsistent.” (tradução) «pode não se atualizar automaticamente ao adicionar produtos, o suporte multilíngue é fraco e a indexação de imagens hospedadas em CDN é inconsistente.» Para uma loja multilíngue ou um catálogo grande e em rápida mudança, um módulo de sitemap de terceiros (FME, Sweet Sitemap) oferece atualização automática, sitemaps por idioma, sitemaps de imagens e controle de prioridade/frequência.

Robots.txt

Gere-o em Parâmetros da Loja → Tráfego e SEO → “Gerar arquivo robots.txt.” O PrestaShop escreve uma linha de base na instalação, mas você deve personalizá-la. Desautorizações recomendadas:

  • /cart, /checkout, /search
  • parâmetros de filtro/ordenação: ?order=, ?sort=, ?q= e seus parâmetros de faceta
  • caminhos utilitários de admin/módulo (por exemplo, /module/)

Mantenha /img/ rastreável para que as imagens dos seus produtos possam ser indexadas e adicione a referência do seu sitemap (Sitemap: https://example.com/sitemap.xml).

O único aviso que importa mais do que todos os outros: um robots.txt mal configurado pode remover toda a sua loja. A PrestaHero é direta sobre isso — “a misconfigured robots.txt can destroy SEO, as you don’t want to accidentally block /category or /product pages, which could remove your whole store from Google’s index.” (tradução) «um robots.txt mal configurado pode destruir o SEO, pois você não quer bloquear acidentalmente as páginas /category ou /product, o que poderia remover toda a sua loja do índice do Google.» Desautorizar o caminho errado aqui é uma desindexação autoinfligida.

Schema / dados estruturados

Esta é uma lacuna real. O PrestaShop inclui apenas dados estruturados mínimos de fábrica; um schema abrangente é trabalho de um módulo. O que você normalmente vai querer — Product completo (nome, imagem, preço, disponibilidade, avaliações, envio/devoluções), BreadcrumbList, Organization, WebSite e FAQPage — vem de um módulo de rich snippets. O Schema Pro da PrestaPremium, por exemplo, anuncia que ele “automatically generates 9 Schema.org types across your entire store: Product, ProductGroup (variants with size, color, material), Organization, WebSite, BreadcrumbList, FAQPage, CollectionPage, shipping details and return policy.” (tradução) «gera automaticamente 9 tipos de Schema.org em toda a sua loja: Product, ProductGroup (variantes com tamanho, cor, material), Organization, WebSite, BreadcrumbList, FAQPage, CollectionPage, detalhes de envio e política de devolução.» Os dados estruturados de Product do Google suportam exatamente esses campos, então vale a pena adicionar a marcação; só não espere isso do núcleo.

Performance e Core Web Vitals

Os temas padrão do PrestaShop — especialmente o tema legado Classic — muitas vezes têm dificuldades com Core Web Vitals: CSS/JS que bloqueiam a renderização, imagens não otimizadas (sem WebP por padrão em versões mais antigas), sem lazy loading de fábrica em temas mais antigos e JS de módulos pesados carregando de forma síncrona. Os alvos são os padrão: LCP < 2,5 s, INP < 200ms (o INP substituiu o FID em março de 2024), CLS < 0,1.

A alavanca integrada do PrestaShop é o CCC (Concatenate, Compress, Cache) em Advanced Parameters → Performance — ele mescla e compacta CSS/JS para reduzir requisições e peso. Teste antes de ativar em produção, porque pode quebrar alguns módulos. Além do CCC: converta imagens para WebP, ative o lazy loading, use uma CDN, escolha um tema focado em desempenho (Hummingbird), adie JS não crítico e adicione cache em nível de servidor (Redis/Memcached). A forma como a Knowband enquadra por que isso importa é justa — Core Web Vitals “affects crawl efficiency, paid traffic quality, mobile conversion, checkout trust, and the first impression of every product page.” (tradução) «afeta a eficiência do rastreamento, a qualidade do tráfego pago, a conversão mobile, a confiança no checkout e a primeira impressão de cada página de produto.» Meça com PageSpeed Insights e os dados do CrUX no Search Console.

Hreflang para lojas multilíngues

O PrestaShop suporta vários idiomas (mesmo domínio, prefixo de idioma na URL como /fr/ /en/ ou domínios separados) e várias lojas compartilhando um catálogo — mas ele não gera tags hreflang nativamente. Isso é um módulo: SunnyToo, DataFireFly, MyPresta, Canonical & Hreflang da FME. A MyPresta declara o modo de falha claramente: “without hreflang tags, Google does not know which version of a page to display based on the visitor’s language or region. It may index the wrong version, create duplicate content across your language stores, or show an English page to a French-speaking visitor.” (tradução) «sem tags hreflang, o Google não sabe qual versão de uma página exibir com base no idioma ou região do visitante. Ele pode indexar a versão errada, criar conteúdo duplicado entre suas lojas de idiomas ou mostrar uma página em inglês para um visitante que fala francês.»

Ao implementar, cubra todos os tipos de página (produto, categoria, CMS, fabricante, fornecedor), inclua sempre x-default, lide com o pareamento multi-loja entre domínios e mantenha a canonicalização consistente junto com isso. E lembre-se da regra geral de hreflang: uma implantação parcial e sem pareamento não traz nada — o Google precisa das tags de retorno para reconhecer o conjunto.

Comparação de plataformas

O PrestaShop fica entre as plataformas SaaS hospedadas e o Magento de controle total. Onde cada plataforma se posiciona nas alavancas de SEO:

RecursoPrestaShopShopifyWooCommerceMagentoBigCommerce
URLs amigáveisSim (alternância)Sim (prefixo obrigatório)Via móduloSimSim
ID nas URLsSim por padrãoNãoVia YoastConfigurávelNão
Tags canonicalSim (parcial)SimVia YoastSimSim
Schema nativoMódulo necessárioParcialVia Yoast/RankMathParcialParcial
HreflangMódulo necessárioAplicativo necessárioVia WPML/YoastSimLimitado
Sitemap nativoMódulo (limitado)AutomáticoVia YoastSimAutomático
Editor de robots.txtPainel administrativo (gerar)Não nativoVia móduloEditávelEditável
Tratamento de navegação facetadaMódulo necessárioLimitadoVia móduloOpção de configuraçãoOpção de configuração
Código aberto / acesso ao servidorSimNãoSimSimNão

O resumo honesto, muito dele da comparação da Kinsta: contra Shopify, o PrestaShop dá mais controle bruto (código aberto, acesso ao servidor, rotas personalizáveis) enquanto o Shopify cuida do desempenho e da segurança para você e força um prefixo estilo /products/ que você não pode remover. Contra WooCommerce, a leitura da Kinsta é que “WooCommerce would beat PrestaShop, as it inherits all of WordPress’s SEO capabilities, especially when it comes to blogging” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» — embora eles também observem que “out of the box, PrestaShop offers more options than WooCommerce for ecommerce SEO, with the product editor enabling you to add custom meta titles and descriptions for each product.” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» «WooCommerce venceria o PrestaShop, pois herda todos os recursos de SEO do WordPress, especialmente quando se trata de blogs» — embora também observem que «pronto para uso, o PrestaShop oferece mais opções que o WooCommerce para SEO de ecommerce, com o editor de produto permitindo adicionar títulos e descrições de meta personalizados para cada produto.» Contra Magento, o Magento “offers the most control for complex stores with full URL customization, native structured data, advanced sitemap configuration, and deep meta tag management” (tradução) «em português, a citação confirma a explicação apresentada neste bloco» (LueurExterne) — a um custo e complexidade muito maiores. «oferece o maior controle para lojas complexas com personalização completa de URL, dados estruturados nativos, configuração avançada de sitemap e gerenciamento profundo de meta tags» (LueurExterne) — a um custo e complexidade muito maiores. Contra BigCommerce, o BigCommerce oferece melhores padrões (sitemap automático, schema integrado, sem ID nas URLs), mas muito menos personalização aberta. Todos eles ranqueiam bem; o trade-off do PrestaShop é controle por trabalho de configuração.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.