Durante una migrazione PrestaShop 1.7 verso 8, un cambio di tema, una riorganizzazione dell’alberatura, o semplicemente una modifica di slug prodotto, centinaia o migliaia di URL cambiano silenziosamente. Ognuna di queste URL accumula succo SEO, link in ingresso, e magari figura nei risultati Google con un buon posizionamento. Senza redirect 301 verso il nuovo URL, questo capitale sparisce.
Il peggio: la perdita non è immediata. Vedi il traffico calare lentamente in 3-6 settimane, senza incidenti chiari. Il tempo di capire e hai perso il 30-50% del traffico SEO, e ci vorranno 6-12 mesi per recuperarlo — se ci riesci.
Questo articolo seziona la meccanica dei redirect 301 su PrestaShop: cosa fa il nativo, cosa gli sfugge, come mettere in piedi un monitoring 404 pulito e come automatizzare il riflesso “cambio di slug → redirect 301”.
Perché i redirect 301 sono critici per la SEO
Un redirect 301 (“Moved Permanently”) dice a Google e agli utenti: questo URL è stato trasferito definitivamente, ecco il nuovo indirizzo. Google trasmette allora il PageRank, lo storico dell’URL, i backlink accumulati. Il nuovo URL eredita il capitale SEO.
Senza 301, l’URL iniziale restituisce una 404 (“Not Found”). Google mette la pagina in coda di deindicizzazione, i backlink puntano nel vuoto, il PageRank si dissipa. Dopo 3-6 mesi, l’URL viene rimosso dall’indice. Il capitale è perso.
Qualche numero di audit, su un negozio post-migrazione senza gestione 301 pulita:
- 40-60% degli URL indicizzati Google rispondono 404 entro 6 mesi.
- Il traffico SEO cala del 25-50% nel trimestre successivo.
- Le posizioni sulle query long-tail (spesso le più redditizie) crollano per prime.
- I backlink esterni (stampa, blog, directory) diventano obsoleti e perdono il loro succo.
Cosa gestisce nativamente PrestaShop (e cosa gli sfugge)
Il modulo SEO & URL nativo
PrestaShop 8 e 9 propongono una scheda “Redirect” in Preferenze > Traffico > SEO & URL. Permette di aggiungere manualmente redirect 301 / 302 / 410 per coppia (URL sorgente, URL destinazione).
Limiti:
- Nessuna gestione per regex o wildcard. Per reindirizzare un’intera vecchia categoria
/prodotti-vecchi/*verso/promozioni/, bisogna creare manualmente ogni URL. - Nessun redirect automatico al cambio di slug. Se modifichi lo slug di un prodotto, il vecchio URL finisce in 404 senza redirect.
- Nessun monitoring 404 sugli URL effettivamente visitati.
- Performance limitata. Oltre qualche migliaio di redirect, il modulo rallenta il routing.
- Nessun import/export in CSV per gestione di massa.
Il file .htaccess
Alternativa manuale: scrivere regole RewriteRule in .htaccess. Performante (Apache elabora le regole a monte), ma:
- Sensibile agli errori di sintassi (una virgola fuori posto e tutto il sito va in 500).
- Difficile da mantenere per i non tecnici.
- Non funziona su Nginx (che usa la propria sintassi).
- Nessuna interfaccia BO né tracciabilità.
Lo stack che dovresti avere
1. Redirect automatico al cambio di slug
Quando un prodotto, una categoria o un CMS cambia slug, il vecchio URL deve automaticamente registrare un 301 verso il nuovo. Nessuna operazione manuale, nessun rischio di dimenticanza. È la rete di sicurezza numero 1.
2. Monitoring dei 404
Tutti gli URL che finiscono in 404 devono essere loggati con la loro frequenza e il referrer. Un URL chiamato 200 volte al mese in 404 è un bug da trattare in priorità. Un URL in 404 una volta all’anno può aspettare.
3. Redirect di massa per regex e wildcard
Per le migrazioni, servono pattern. /categoria-vecchia/(.*) → /categoria-nuova/$1 deve poter essere configurato in una regola, non in 200 voci.
4. Import/export CSV
Prima di una migrazione, prepari la tabella di corrispondenza in CSV partendo dall’export del vecchio sitemap e del nuovo. Importi in una volta sola invece di inserire a mano.
5. Rilevamento delle catene di redirect
Un URL che redirige verso un URL che redirige verso un URL è un anti-pattern SEO. Google penalizza le catene di più di 2 hop. Un buon strumento rileva e segnala le catene.
6. Tracciabilità e audit
Chi ha creato quale redirect, quando, per quale motivo? In caso di problema (calo di traffico post-migrazione), poter auditare le regole 301 è cruciale.
Il caso particolare del cambio di slug prodotto
Su un negozio attivo, gli slug cambiano costantemente. Un prodotto il cui nome evolve (“Vestito estate 2025” → “Vestito lino estate 2025”), un’ottimizzazione SEO del titolo, una correzione di typo — ogni modifica del link_rewrite in ps_product_lang cambia l’URL canonico.
Se il 301 non viene creato automaticamente, il vecchio URL finisce in 404. Su 12 mesi, su un catalogo di 5.000 prodotti con il 10% di slug modificati, sono 500 URL “persi”. Se ciascuno catturava in media 50 visite/mese, parliamo di 25.000 visite SEO perse all’anno, senza incidenti visibili.
Il riflesso corretto: un hook su actionObjectProductUpdateAfter che rileva il cambio di link_rewrite e crea il 301 automaticamente, per lingua e per negozio multi-shop.
La trappola delle catene di redirect
Scenario classico: un prodotto A cambia slug 3 volte in 6 mesi. Senza gestione fine, ci si ritrova con:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
Una richiesta sul primo URL fa 3 hop prima di arrivare. Google penalizza le catene di più di 2 redirect. Il crawl budget viene consumato inutilmente, e il PageRank si dissipa a ogni hop (perdita del 5-10% per hop secondo gli studi Moz).
La regola: appiattire le catene. Quando viene creato un nuovo redirect, il sistema deve cercare se l’URL sorgente era già la destinazione di un altro 301, e riscrivere il vecchio per puntare direttamente alla nuova destinazione. Niente più catena, niente più hop.
Il nostro modulo dfredirects: gestore 301 completo
Implementare questo stack a mano richiede 7-12 giorni di sviluppo su PrestaShop, più la manutenzione. Il nostro modulo dfredirects per PrestaShop 8 e 9 industrializza tutta la meccanica:
- Redirect 301, 302, 410 configurabili dal BO, con interfaccia filtrabile e paginata.
- Pattern regex e wildcard: una regola può coprire centinaia di URL (
/old-cat/(.*)$ → /new-cat/$1). - Redirect automatico al cambio di slug prodotto, categoria, produttore, fornitore, CMS — multilingue e multi-shop.
- Monitoring 404 con frequenza, ultima visita, referrer. Ordinamento per volume per prioritizzare.
- Appiattimento automatico delle catene: niente redirect a cascata.
- Import/export CSV per gestione di massa prima della migrazione.
- Tracciabilità: autore, data, motivo opzionale per regola.
- Compatibile PS 8 e 9, senza dipendenza da Apache/.htaccess (funziona anche su Nginx).
- Performance: tabella ottimizzata con indice, fino a 100.000 regole senza degrado.
A 49 €, eviti la perdita di traffico post-migrazione e installi una rete di sicurezza duratura contro la deriva 404.
Procedura di migrazione SEO-safe
Passo per passo, la procedura che applichiamo sulle migrazioni PrestaShop 1.7 → 8 o sui rifacimenti maggiori:
- Prima della migrazione: export del vecchio sitemap.xml. Contiene tutti gli URL indicizzati.
- Crawl completo del sito vecchio con Screaming Frog o equivalente, per recuperare tutti gli URL (incluse pagine fuori sitemap: filtri, paginazioni).
- Mapping vecchio → nuovo in CSV: ogni URL vecchio riceve il suo nuovo URL. Per gli URL spariti, scegliere una destinazione alternativa pertinente (categoria padre, home page in ultima istanza).
- Import del CSV in dfredirects prima o durante lo switch.
- Test: 50 URL random verificati in 301 direttamente, senza catena, verso la destinazione corretta.
- Sottomissione del nuovo sitemap.xml a Google Search Console.
- Monitoring 404 giornaliero durante il primo mese: ogni 404 ricorrente viene convertito in 301.
- Audit a 30, 60, 90 giorni: copertura Search Console, query perse, verifica della stabilità del traffico.
FAQ
Che differenza c’è tra 301 e 302?
Il 301 è definitivo e trasmette il PageRank. Il 302 è temporaneo e non trasmette. Per una migrazione o un cambio di slug, usare sempre 301. Il 302 è riservato ai casi esplicitamente temporanei: manutenzione, A/B test, redirect stagionale.
E il 410 (Gone)?
Il 410 dice a Google: questo URL non esiste più e non tornerà, deindicizza immediatamente. Più veloce del 404 per la pulizia dell’indice. Utile per i prodotti definitivamente ritirati senza equivalente. Ma da usare con parsimonia: una volta restituito il 410, il PageRank è perso.
Quanto tempo impiega Google a prendere in carico un 301?
Il crawl Google del vecchio URL può richiedere da qualche giorno a diverse settimane secondo la frequenza di crawl. La trasmissione completa del PageRank verso il nuovo URL richiede in pratica 1-3 mesi. Sottomettere il nuovo sitemap accelera il processo.
Si può reindirizzare in HTTPS e cambiare dominio nello stesso tempo?
Sì, ed è anche frequente. Un 301 può combinare protocollo (HTTP → HTTPS), dominio (vecchio.com → nuovo.com) e percorso. La regola: un solo 301 per URL, non una catena. Appiattire al massimo.
I redirect impattano sulle performance?
Un 301 semplice aggiunge circa 100-200 ms al tempo di risposta per la prima richiesta. Con il caching del browser (Cache-Control sul 301), le visite successive vanno direttamente al nuovo URL senza l’hop. Il costo è trascurabile fuori dalle catene multiple. Una catena di 3 hop, invece, può aggiungere 500 ms — da qui l’appiattimento.
Per approfondire
La gestione dei redirect è uno dei pilastri della migrazione SEO-safe. Vedi anche la nostra checklist completa di migrazione PrestaShop 1.7 → 8 (pianificata il 10 giugno) dove i 301 sono il passo 8 della procedura, e la nostra guida SEO e-commerce 2026 per il quadro completo della SEO PrestaShop. Tre articoli complementari sulla stessa tematica: preparare, eseguire, mettere in sicurezza.
