PrestaShop SEO Guide: Settings, Duplicates, Filters, Schema
I run the whole tech side of 23 PrestaShop storefronts across 22 markets, and I am migrating them to PrestaShop 9 and Hummingbird as I write this. This guide is the order I work through SEO in PrestaShop on a live store: the settings first, then the duplicate-content sources one by one, then the templates that carry revenue, then the things that only matter once those are right. It is the same order I follow when a store hires me for PrestaShop SEO or for PrestaShop development more broadly.
It is not a module shopping list. Most of what the paid "SEO modules" sell has been in the core since 1.7, and a store with the right settings and a clean theme needs almost none of them. Where a module is genuinely the answer, it is named.
Start with what Google actually sees
Before touching a setting, get two things: your Search Console data and your raw server access log.
Search Console tells you which URLs earn impressions and which are excluded and why. The access log tells you what Googlebot actually requests, which on PrestaShop is usually a surprise: filter combinations, sort orders, paginated pages, print views and combination URLs that never appear in your sitemap but eat most of the crawl. Pull a week of Apache or Nginx logs and run them through my free access log viewer; it groups requests by user agent and URL pattern, so the waste is visible in a minute.
Everything below is aimed at making those two views agree: the URLs you want indexed are the ones Google spends its time on, and nothing else.
The SEO & URLs settings, in order
All of these live under Shop Parameters > Traffic & SEO (called SEO & URLs in older versions). The order matters, because several of them change URLs and each URL change needs a redirect.
Friendly URLs
Turn them on. Without them every page is index.php?id_product=847&controller=product, and nothing else in this guide applies. On a store that has been live without friendly URLs, the switch changes every address, so it goes through the redirect process described under URL changes below.
Redirect to the canonical URL
Set this to 301 (permanent). It is the single most valuable setting on the page and it is frequently left on "no redirection". With it on, a product reached through a non-default category, a category reached with a stray parameter, or a URL with the wrong language prefix all redirect to the one address you want indexed. Without it, PrestaShop happily serves the same page at several addresses and leaves Google to pick one.
Accented URLs
Off, unless you have a specific reason. Accented characters in URLs are legal, but they encode differently across browsers, tools and copy-paste, and the same product ends up with two spellings in the wild.
Schema of URLs, and the question of IDs
The route patterns decide what your product and category URLs look like. The defaults produce addresses like /clothes/3-printed-t-shirt.html, and the number is the product ID. The most common question I get is how to remove it.
My answer, after running this at scale: do not, on an established store. The ID does nothing to your rankings. Removing it requires a module that overrides the dispatcher to resolve products by rewrite alone, it changes every product and category URL on the site, and it creates a permanent dependency on that module. For a new store that has not launched, a clean route is fine. For a store with rankings, it is a URL migration with no upside.
What is worth doing in the routes: keep the category path out of product URLs if your products live in several categories, so the canonical does not depend on the path the visitor came in through.
Meta titles and descriptions
Every product, category, CMS page, manufacturer and supplier has its own title and description fields. Categories are where these matter most, because category pages are the ones that should rank for the terms with volume, and they are the ones most stores leave on the default "Category name - Shop name" pattern. Write them for the top twenty categories by hand; template the rest.
Leave meta keywords empty. Google has ignored the field for over a decade and the empty field costs nothing.
robots.txt
The Generate robots.txt button writes a sensible file that blocks the admin, cart, account, order and search controllers in every language. Regenerate it after adding a language or a shop, then add your sitemap line. Do not block filter parameters here; filtered URLs are handled at the source below, and a robots block on a URL that is already indexed keeps it indexed forever.
Set shop URL and SSL
One canonical host, HTTPS everywhere, SSL forced on all pages. If the store still answers on http:// or on both www and bare domain without redirecting, fix that at the server before anything else.
Duplicate content, source by source
PrestaShop generates duplicates in six places. Each has its own fix, and the canonical redirect setting above closes most of them only when the theme emits a correct canonical. Check the raw HTML of a product, a category and a paginated category after each change.
Products in more than one category
A product assigned to three categories can be reached through three paths. The canonical must point at the URL built from the product's default category, and with the 301 canonical redirect on, the other two paths redirect there. Check that your theme's canonical really uses the default category and not the current one.
Combinations
Depending on version and theme, product URLs either carry the combination ID in the path or switch combinations with a URL fragment. Fragments are invisible to Google and fine. Combination IDs in the path are not, unless the canonical strips them consistently. Pick one behaviour and verify it in the HTML; both exist in the wild.
Pagination
?page=2 and onward must be crawlable, must canonicalise to themselves, and must not carry noindex. The old advice to point every page at page one hides everything past the first page from the index, and the rel="next" and rel="prev" links that guides still recommend have not been used by Google as an indexing signal since 2019. Self-canonical, indexable, done.
Sorting
?order=product.price.asc and friends are the same list in a different order. They must canonicalise to the unsorted category URL. Most themes get this right; check it once.
Filtered category URLs
Layered filters are the largest source of crawl waste on PrestaShop, and also the most controllable. Every filter combination a visitor can click is a URL with parameters, and the store has to decide, per filter, whether that URL exists for Google or only for the visitor.
The rule: no filtered URL is indexable by default. A filtered page canonicalises back to its category, and the links that produce it are not followed. Then open a filter up only where the combination is itself a search term with volume - brand within a category is the usual case, occasionally a material or a size class - and give that page a self-referencing canonical and its own copy. Every other combination is a duplicate of the category with fewer products on it.
Two checks in the raw HTML settle it: the canonical on a filtered page, and the rel attribute on the filter links. If either is wrong, the fix is in the theme's category template, not in a robots rule.
Related: a parent category with no products of its own should not render an empty grid. Show its subcategories' products there or fill it; empty categories are thin pages.
Languages, stores and hreflang
Within one shop, the Classic theme emits hreflang alternates for each active language, which is correct as long as every language actually has translated content. A language enabled with untranslated products produces a set of English pages under a German URL, and Google treats that as what it is.
Across a multistore estate on separate domains, the core does not know the sibling shops exist, so the hreflang set stops at the shop's own languages. If you run country stores on country domains, the cross-domain hreflang has to be added in the theme from a shared map of equivalent URLs. This is the one place on a 22-market estate where I had to write code rather than configure.
Category pages: where the revenue terms rank
Category pages rank for the terms people actually buy from, and PrestaShop ships them as a heading over a grid. Three changes turn them into pages:
- Write the category description, per language, and make sure the theme shows it. Classic shows a truncated version with a "more" toggle; whether that is above or below the grid depends on the theme. Copy above the grid, sized like an introduction, works better for both users and crawlers than an essay pushed below page three of products.
- Link between categories inside the copy: the parent, the siblings that share buyers, the guide article that answers the pre-purchase question. PrestaShop's category tree gives Google structure; the copy gives it context.
- One H1, which is the category name, and no second H1 from a banner module. Check in the HTML.
Categories that exist for navigation but carry two products are not worth a ranking; merge them or noindex them rather than leaving thin pages in the index.
Product pages
The product fields do most of the work, if they are filled:
- The summary appears in listings and is the fallback for the meta description. The description is the page. Neither should be the manufacturer's text that fifty other shops also pasted in; rewriting the top sellers by hand is the highest-return content work on a PrestaShop store.
- EAN, UPC, MPN and ISBN fields flow into the structured data. Fill them; Google uses identifiers to match products across the web, and Shopping surfaces depend on them.
- Manufacturer assigned, so brand appears in the markup.
- Image alt text is the image caption field; fill it for the primary image at least.
When a product goes offline, set its redirection when offline to a 301 to the category or to the replacement product. A deleted product that returns a 404 with rankings attached is lost traffic; the field exists so you do not have to run a redirect module.
Structured data
Classic and Hummingbird ship Product structured data, and the questions are whether it validates and whether it is complete. Test a live product URL in the Rich Results tool. What is usually missing: brand, sku, gtin, priceValidUntil, and correct availability for out-of-stock combinations.
Breadcrumb markup comes from the theme's breadcrumb and matches the category path, which is another reason the canonical category matters.
Reviews need a module, and the review markup must describe reviews that are visible on the page. Markup that claims ratings the page does not show is exactly what gets a store's rich results removed.
Sitemaps
Use the official free Google Sitemap module (gsitemap). It generates a sitemap index with one file per language and per content type, excludes inactive products, and can be regenerated from a cron URL. Two checks after generating:
- Every sitemap URL must be the canonical form, including language prefix and host. If the sitemap and the canonical disagree, Google trusts the canonical and ignores the sitemap.
- On multistore, generate and submit per shop, in each shop's own Search Console property.
Speed and Core Web Vitals
PrestaShop is not slow; PrestaShop stores are slow because of what is installed on them. In order of effect:
- Modules. Every module that hooks the header adds its CSS and JavaScript to every page. Uninstall what is not used, not just disable it. A module audit is usually worth more than every setting below combined.
- Images. Since PrestaShop 8 the image settings can generate WebP (and AVIF in later releases). Turn it on, regenerate thumbnails, and check the theme serves them. Product images are the LCP element on almost every page.
- Caching. Under Performance: Smarty cache on and template compilation set to never recompile in production. On 1.7 with Classic, the CCC options combine and compress assets. On 8 and 9 with Hummingbird, assets are built ahead of time and CCC is less relevant.
- Server. PHP opcache, a current PHP version, enough memory for MySQL, and a full-page cache in front of the shop if you have the traffic to justify it. This is where I spend the AWS budget on the estate I run, and it is where the last third of the LCP score comes from.
- Third-party tags. Analytics, chat, consent and marketing tags loaded through a tag manager on every page. Audit them like modules.
Measure on real product and category URLs in Search Console's Core Web Vitals report, not on the homepage.
Multistore and international stores
If you sell into several countries, decide the structure once: one shop with many languages, one shop per country on subfolders or subdomains, or separate domains. The SEO consequences are different.
Languages in one shop share authority and are the simplest to keep consistent. Country shops on separate domains split authority and each needs its own Search Console property, sitemap and, as above, hand-built cross-domain hreflang - but they let each market have its own catalog, prices and content. On the estate I run, the country-domain model was inherited and it works, but it costs real engineering to keep 22 markets on one codebase; do not choose it casually.
Whatever the structure, the rule is that each market's pages are fully translated, priced in the local currency and linked to their equivalents. Half-translated markets are the most common international SEO problem I see on PrestaShop, and no setting fixes them.
URL changes and redirects
Any change that moves URLs - enabling friendly URLs, changing routes, renaming categories, restructuring the tree - needs the same procedure:
- Export every URL with impressions from Search Console before the change.
- Map each one to its new address.
- Load the redirects at the server level (Apache or Nginx) or with a redirect module, and test a sample.
- Keep the redirects for at least a year, longer if the old URLs still get crawled.
PrestaShop's core handles per-product redirects when a product goes offline, and nothing else. For a structural change, the server is the right place for the rules.
PrestaShop SEO modules: which are worth installing
- Google Sitemap (official, free): yes.
- A redirect manager module: only if your team needs to manage redirects from the back office rather than the server config. The server is better for bulk rules; a module is better for a marketing team adding one a week.
- The paid SEO suites: their legitimate uses are bulk meta-title templates across thousands of products and per-page redirect management. The rest of what they list - canonicals, friendly URLs, sitemaps, "duplicate content protection" - is core functionality dressed up. If you need the bulk editing, buy for that; do not expect ranking changes from the module itself.
- Structured data modules: only if your theme's built-in markup fails validation and you cannot fix the theme. Check first.
What PrestaShop 9 changes for SEO
The settings described above are essentially the same in 9 as in 8. What changes is underneath: PHP 8.1 or newer, a current Symfony core, a new Admin API, and Hummingbird as the supported modern theme. Hummingbird is built on Bootstrap 5 with no jQuery dependency, and on the stores I have moved, the Core Web Vitals improvement comes from the theme, not from any SEO setting.
The other change is indirect. 1.7 is out of support, which means unpatched security exposure, and a compromised store is an SEO problem before it is anything else - injected spam URLs get indexed fast and take months to clear. If you are still on 1.7, the upgrade is the SEO project. I have written up how I run it on the PrestaShop upgrade and migration page.
The PrestaShop SEO checklist
Technical:
- Friendly URLs on, canonical redirect 301, accented URLs off, HTTPS forced on one host
- Canonical correct on products in several categories, on combinations, on paginated and sorted lists
- Filtered URLs kept out of the index except the few that are search terms
- hreflang complete within the shop and, on multistore domains, across shops
- Sitemap generated per language, submitted per property, URLs matching canonicals
- robots.txt regenerated after every language or shop change
- Product structured data validating on live URLs, with identifiers and brand
Content:
- Top categories with hand-written titles, descriptions and above-grid copy
- Top products with rewritten descriptions and filled identifiers
- Thin categories merged or noindexed
- Offline products redirected, not 404ing
Speed:
- Module audit done, unused modules uninstalled
- WebP generation on, thumbnails regenerated
- Cache and template compilation set for production
- Core Web Vitals checked on product and category templates in Search Console
PrestaShop SEO tips, and the questions people ask
How do you do SEO in PrestaShop?
In this order: friendly URLs on with a 301 canonical redirect and one HTTPS host; each duplicate-content source closed (multi-category products, combinations, pagination, sorting, filtered URLs); real titles, descriptions and above-grid copy on the categories that carry revenue; product structured data validated on live URLs; hreflang correct per language and store; then speed. All of it lives in the core settings and the theme. No SEO module is required.
What are the most useful PrestaShop SEO tips?
Read your access log before you touch a setting, so you fix what Googlebot actually crawls. Set the canonical redirect to 301. Keep filtered URLs out of the index except the few that are real search terms. Give your top categories hand-written copy. Redirect offline products instead of letting them 404. Uninstall the modules you do not use. Check Core Web Vitals on product and category templates, not on the home page.
Is PrestaShop good for SEO?
Yes, once configured. The core has had friendly URLs, canonical redirects, per-page meta fields, hreflang and product structured data since 1.7. What holds stores back is the defaults, and those are configuration and template work, not a platform limit.
How do I enable SEO-friendly URLs in PrestaShop?
Under Shop Parameters > Traffic & SEO, switch Friendly URL on, set the canonical redirect to 301 and leave accented URLs off. On a live store, export the old URLs from Search Console first and load redirects at the server, because every address changes.
Should I remove the ID numbers from PrestaShop URLs?
On an established store, no. The ID has no effect on rankings, removing it needs a module that overrides routing, and it changes every URL on the site. For a store that has not launched, a clean route is fine.
How do I fix duplicate content in PrestaShop?
Canonical redirect to 301, theme canonical on the default category, paginated pages self-canonical, sorted lists canonicalised to the category, filtered URLs out of the index except real search terms. Then verify each case in the raw HTML.
What is the best PrestaShop SEO module?
The official free Google Sitemap module; the rest is core settings and the theme. Paid suites are worth it only for bulk meta templating on large catalogs or back-office redirect management.
Does PrestaShop 9 improve SEO?
The settings are essentially the same as 8. The gains come from Hummingbird's Core Web Vitals and from being on a supported, patched version.
Where to go from here
Everything above is doable by a store owner or an in-house developer with a staging copy and an afternoon per section. If you would rather have it done by the person who runs it on 23 stores, that is what the PrestaShop SEO page is for, and the PrestaShop development and maintenance pages cover the rest of what a store needs from a specialist.