During a PrestaShop 1.7 to 8 migration, a theme change, a tree reorganisation, or simply a product slug change, hundreds — even thousands — of URLs silently change. Each of those URLs has accumulated SEO juice, inbound links, and may rank in Google with a strong position. Without a 301 redirect to the new URL, that capital disappears.
The worst part: the loss isn’t immediate. Traffic drops slowly over 3 to 6 weeks, without a clear incident. By the time you understand, you’ve lost 30 to 50% of SEO traffic and it will take 6 to 12 months to recover it — if you do at all.
This article unpacks the 301-redirect mechanics on PrestaShop: what the native does, what it misses, how to set up clean 404 monitoring, and how to automate the “slug change → 301 redirect” reflex.
Why 301 redirects are critical for SEO
A 301 (“Moved Permanently”) tells Google and users: this URL has moved permanently, here is the new address. Google then transmits PageRank, URL history, accumulated backlinks. The new URL inherits the SEO capital.
Without 301, the original URL returns a 404 (“Not Found”). Google queues the page for deindexing, backlinks point into the void, PageRank dissipates. After 3-6 months, the URL is removed from the index. Capital lost.
A few audit figures, on a post-migration store without clean 301 handling:
- 40 to 60% of indexed Google URLs return 404 within 6 months.
- SEO traffic drops 25 to 50% in the following quarter.
- Long-tail query positions (often the most profitable) collapse first.
- External backlinks (press, blogs, directories) become stale and lose their juice.
What PrestaShop handles natively (and what it misses)
The native SEO & URLs module
PrestaShop 8 and 9 offer a “Redirects” tab in Preferences > Traffic > SEO & URLs. It allows manual addition of 301 / 302 / 410 redirects by pair (source URL, target URL).
Limits:
- No regex or wildcard handling. To redirect an entire old category
/old-products/*to/sales/, every URL must be created manually. - No automatic redirect on slug change. If you modify a product slug, the old URL goes to 404 without redirection.
- No 404 monitoring on actually visited URLs.
- Limited performance. Beyond a few thousand redirects, the module slows the routing.
- No CSV import/export for bulk management.
The .htaccess file
Manual alternative: write RewriteRule rules in .htaccess. Performant (Apache processes rules upstream), but:
- Sensitive to syntax errors (a misplaced comma, and the whole site goes 500).
- Hard to maintain for non-technical teams.
- Doesn’t work on Nginx (which uses its own syntax).
- No BO interface or traceability.
The stack you should have
1. Automatic redirect on slug change
When a product, category or CMS page changes slug, the old URL must automatically register a 301 to the new one. No manual handling, no forget-risk. Safety net number one.
2. 404 monitoring
Every URL going to 404 must be logged with frequency and referrer. A URL called 200 times a month in 404 is a priority bug. A URL in 404 once a year can wait.
3. Mass redirects by regex and wildcard
For migrations, patterns are needed. /old-category/(.*) → /new-category/$1 must be configurable in one rule, not 200 entries.
4. CSV import/export
Before a migration, the mapping table is prepared in CSV from the old sitemap export and the new sitemap. Import once rather than typing by hand.
5. Redirect chain detection
A URL redirecting to a URL redirecting to a URL is an SEO anti-pattern. Google deprecates chains of more than 2 hops. A good tool detects and flags chains.
6. Traceability and audit
Who created which redirect, when, why? In case of a problem (post-migration traffic drop), auditing the 301 rules is crucial.
The special case of product slug changes
On an active store, slugs change constantly. A product whose name evolves (“Summer dress 2025” → “Linen summer dress 2025”), an SEO title optimisation, a typo correction — each modification of link_rewrite in ps_product_lang changes the canonical URL.
If the 301 isn’t created automatically, the old URL goes 404. Over 12 months, on a 5,000-product catalogue with 10% of slugs modified, that’s 500 “lost” URLs. If each drained 50 visits/month on average, that’s 25,000 lost SEO visits per year, without a visible incident.
The right reflex: a hook on actionObjectProductUpdateAfter that detects link_rewrite changes and automatically creates the 301, per language and per multi-shop store.
The trap of redirect chains
Classic scenario: a product A changes slug 3 times in 6 months. Without fine handling, you end up with:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
A request to the first URL hops 3 times before arriving. Google deprecates chains over 2 redirects. Crawl budget is uselessly consumed, and PageRank dissipates with each hop (5 to 10% loss per hop according to Moz studies).
The rule: flatten the chains. When a new redirect is created, the system must check if the source URL was already the target of another 301, and rewrite the old one to point directly at the new target. No more chain, no more hops.
Our dfredirects module: complete 301 manager
Implementing this stack by hand requires 7 to 12 days of PrestaShop dev, plus maintenance. Our dfredirects module for PrestaShop 8 and 9 industrialises the whole mechanic:
- 301, 302, 410 redirects configurable from the BO, with a filterable and paginated interface.
- Regex and wildcard patterns: one rule can cover hundreds of URLs (
/old-cat/(.*)$ → /new-cat/$1). - Automatic redirect on slug change for products, categories, manufacturers, suppliers, CMS — multilingual and multi-shop.
- 404 monitoring with frequency, last visit, referrer. Sort by volume to prioritise.
- Automatic chain flattening: no cascade redirects.
- CSV import/export for bulk pre-migration management.
- Traceability: author, date, optional reason per rule.
- PS 8 and 9 compatible, without Apache/.htaccess dependency (also works on Nginx).
- Performance: optimised indexed table, up to 100,000 rules without degradation.
For €49, you avoid post-migration traffic loss and install a lasting safety net against 404 drift.
SEO-safe migration procedure
Step by step, the procedure we apply on PrestaShop 1.7 → 8 migrations or major redesigns:
- Before migration: export of the old sitemap.xml. It contains every indexed URL.
- Full crawl of the old site with Screaming Frog or equivalent, to retrieve every URL (including off-sitemap pages: filters, paginations).
- Old → new mapping in CSV: each old URL gets its new URL. For disappeared URLs, choose a relevant alternative target (parent category, home page as last resort).
- CSV import into dfredirects before or during the cutover.
- Test: 50 random URLs verified as 301 directly, without chains, to the correct target.
- Submission of the new sitemap.xml to Google Search Console.
- Daily 404 monitoring during the first month: every recurring 404 is converted to 301.
- Audit at 30, 60, 90 days: Search Console coverage, lost queries, traffic stability check.
FAQ
What’s the difference between 301 and 302?
301 is permanent and transmits PageRank. 302 is temporary and does not. For a migration or a slug change, always use 301. 302 is reserved for explicitly temporary cases: maintenance, A/B testing, seasonal redirect.
And 410 (Gone)?
410 tells Google: this URL no longer exists and won’t return, deindex immediately. Faster than 404 for index cleanup. Useful for products definitively withdrawn without equivalent. But use sparingly: once 410 is returned, PageRank is lost.
How long does Google take to account for a 301?
The Google crawl of the old URL can take a few days to several weeks depending on crawl frequency. Full PageRank transmission to the new URL takes 1 to 3 months in practice. Submitting the new sitemap speeds up the process.
Can we redirect to HTTPS and change domain at the same time?
Yes, and it is even frequent. A 301 can combine protocol (HTTP → HTTPS), domain (old.com → new.com) and path. The rule: one 301 per URL, not a chain. Flatten as much as possible.
Do redirects impact performance?
A simple 301 adds about 100-200 ms to the response time for the first request. With browser caching (Cache-Control on the 301), subsequent visits go directly to the new URL without the hop. The cost is negligible outside of multiple chains. A 3-hop chain, however, can add 500 ms — hence the flattening.
To go further
Redirect management is one of the pillars of SEO-safe migration. Three complementary themes: prepare, execute, secure.
