Redirect 301 e 404 dopo una migrazione: cosa controllare

Cosa perde un negozio quando gli indirizzi cambiano

Motori di ricerca, link esterni, segnalibri e campagne puntano a indirizzi precisi. Se dopo una migrazione o un cambio di URL quegli indirizzi rispondono 404, Google non li indicizza: nella sua documentazione, gli URL che restituiscono un codice 4xx non vengono indicizzati e quelli già indicizzati vengono rimossi dall’indice. Un redirect permanente dice invece che la pagina esiste ed è stata spostata: Google lo usa come segnale che la destinazione sia l’URL canonico e afferma che i 301 e gli altri redirect permanenti non causano perdita di PageRank. Quanto traffico si perda in concreto dipende dal sito, e per questo si misura con Search Console invece di fidarsi di cifre generiche.

I codici HTTP che contano

La stessa RFC precisa che il 410 è preferibile al 404 quando il server sa che la condizione è probabilmente permanente.

Cosa fa PrestaShop 9.1 da solo

Quanto segue è stato verificato nel codice di PrestaShop 9.1.5, con i file citati nelle fonti.

Redirect all’URL canonico

In Parametri Negozio, Traffico & SEO, Impostazione URL, l’opzione «Redirect all’URL canonico» (PS_CANONICAL_REDIRECT) vale 0 (nessun redirect), 1 (302) o 2 (301). Nel FrontController, per le richieste GET, se l’URL richiesto non coincide con quello canonico PrestaShop risponde con un 301 quando l’opzione vale 2, con un 302 altrimenti, e non fa nulla con 0. La documentazione ufficiale consiglia il 301 a modifiche concluse e avverte che senza redirect si possono avere URL duplicati. In modalità sviluppo, invece del redirect compare una pagina di debug: tienilo presente quando provi.

Cambia lo slug di un prodotto o di una categoria

Le regole predefinite mettono l’id nell’URL ({id}{-:id_product_attribute}-{rewrite}.html per i prodotti, {id}-{rewrite} per le categorie). Il vecchio URL, con lo slug precedente, trova quindi ancora l’oggetto, e il controller lo confronta con quello attuale: con l’opzione su 301 reindirizza, con 0 entrambi gli indirizzi rispondono e i duplicati restano.

Cambia lo schema degli URL

Il Dispatcher parte dal controller pagenotfound e lo sostituisce solo se l’URI corrisponde a una delle rotte attuali, quelle predefinite o quelle personalizzate (PS_ROUTE_*). Il codice non conserva gli schemi precedenti: i vecchi indirizzi che non corrispondono più a nessuna rotta finiscono su una pagina che risponde con un vero stato 404. I redirect dagli schemi vecchi vanno creati a parte.

Prodotto disattivato o non più disponibile

Il campo «Reindirizzamento quando offline» della scheda prodotto (redirect_type) ha dieci valori: default, 404 e 410 (pagina di errore), 200-displayed, 404-displayed e 410-displayed (prodotto mostrato come fuori catalogo con quel codice), 301-category e 302-category (redirect a una categoria), 301-product e 302-product (redirect a un altro prodotto). Con default vale «Comportamento predefinito per i prodotti disabilitati» (PS_PRODUCT_REDIRECTION_DEFAULT). Un prodotto cancellato non esiste più e la pagina risponde 404.

Categoria disattivata o cancellata

Una categoria disattivata segue il campo «Reindirizza quando non visualizzato»: 301 per impostazione predefinita, verso la categoria genitore attiva più vicina se non ne scegli un’altra, oppure 302, 410, 404. Una categoria cancellata risponde 404, e Category::deleteRedirections() riporta al comportamento predefinito i prodotti e le categorie che reindirizzavano verso di lei.

Migrazione da un’altra piattaforma

Cambiando piattaforma quasi tutti gli URL cambiano forma: prodotti, categorie, pagine, immagini e file. PrestaShop non può indovinare i vecchi indirizzi, vanno raccolti e mappati.

1. Raccogli i vecchi URL. Google suggerisce di partire dalle sitemap, dai log del server o dall’analytics per gli URL più visitati, dal rapporto «Link» di Search Console e dall’elenco del CMS. Il rapporto «Prestazioni» ha la dimensione «Pagine» e un pulsante di esportazione. Includi immagini, video, JavaScript e CSS.
2. Mappa ogni URL. Google scrive che è importante mappare gli URL del vecchio sito su quelli del nuovo e decidere dove deve puntare ciascuno: la pagina più pertinente, uno a uno.
3. Gestisci ciò che non ha un equivalente. Google chiede che i contenuti eliminati rispondano 404 o 410. Evita di mandare molti vecchi URL a una sola destinazione non pertinente, come la home: secondo Google può confondere gli utenti e può essere trattato come soft 404. Se più pagine sono confluite in una sola, quella è una destinazione legittima.
4. Evita gli errori comuni: catene di redirect (Googlebot ne segue fino a 10, ma Google consiglia di puntare alla destinazione finale e, se non si può, di restare idealmente entro 3 passaggi e comunque sotto i 5); loop; 302 al posto di 301; link interni, canonical, hreflang e sitemap rimasti sui vecchi URL; redirect verso URL che non esistono; noindex o blocchi robots.txt della fase di sviluppo rimasti attivi; redirect tolti troppo presto.

Cosa controllare in Search Console

• Rapporto «Indicizzazione delle pagine»: «Non trovata (404)», «Soft 404», «Pagina con reindirizzamento» ed «Errore di reindirizzamento» (catena troppo lunga, loop, URL troppo lungo o non valido). Il rapporto stesso dice che un 404 non è per forza un problema se la pagina è stata rimossa senza sostituto, e di usare un 301 se è stata spostata.
• «Controllo URL»: il test sull’URL pubblicato segue i redirect ma non indica di averne seguito uno né mostra l’URL finale. Per vedere codici e catena servono uno strumento da riga di comando o uno script.
• Sitemap: invia quella con i nuovi URL. Quella con i vecchi può mostrare avvisi sui redirect, ed è normale.
• «Cambio di indirizzo»: serve solo passando da un dominio o sottodominio a un altro, non per HTTP verso HTTPS, www o non www, né per percorsi dello stesso dominio.
• Tempi: per un sito medio-piccolo Google indica alcune settimane per la maggior parte delle pagine, con oscillazioni temporanee della visibilità.

Checklist

1. Elenco dei vecchi URL con visite e link, da sitemap, log e Search Console.
2. Mappatura uno a uno; 404 o 410 per ciò che non ha un equivalente.
3. 301 lato server per i contenuti spostati, 302 solo se temporaneo.
4. Nessuna catena: ogni vecchio URL punta alla destinazione finale, verificato con uno script su tutta la lista.
5. Link interni, canonical, hreflang e sitemap sui nuovi URL.
6. «Redirect all’URL canonico» su 301 quando il negozio è online.
7. Monitoraggio di 404 e «Indicizzazione delle pagine» nelle settimane dopo la migrazione; redirect mantenuti il più a lungo possibile, in generale almeno un anno.

Come lo fa il modulo Redirect SEO - Gestione 301/302/404 (SEO Redirects)

• Regole 301, 302 e 410 con percorso semplice, wildcard (* e ?) o regex validata, e opzioni sulla query string (ignorarla, confrontare l’URL completo o richiedere un parametro). Il 410 risponde con uno stato 410 vero e X-Robots-Tag: noindex, prima che il tema venga caricato.
• Il redirect scatta nell’hook actionDispatcher, prima della costruzione della pagina: le regole semplici si trovano con una ricerca indicizzata sull’hash del percorso, wildcard e regex si valutano in ordine.
• Il monitor 404 registra gli URL mancanti con numero di richieste, ultimo accesso, referer e user agent (fino a 5.000 URL distinti, modificabile); «Crea 301» precompila la regola.
• Crea un 301 quando cambia lo slug di un prodotto, di una categoria o di una pagina CMS, per ogni lingua, se nessuna regola copre già quell’URL.
• Importa ed esporta CSV (colonne source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), con il conto delle righe importate e saltate: comodo per caricare la mappatura di una migrazione.
• Rifiuta destinazioni esterne che non siano sul negozio o in un elenco di host autorizzati (protezione open redirect).

Vedi la scheda del modulo oppure leggi la guida all’installazione e alla configurazione.

Fonti

• RFC 9110, HTTP Semantics: sezioni 15.4.2, 15.4.3, 15.4.9, 15.5.5 e 15.5.11
• Google Search Central: redirect e Google Search, spostamento di un sito con cambio di URL, codici di stato HTTP
• Guida di Search Console: Indicizzazione delle pagine, Controllo URL, Cambio di indirizzo, Prestazioni
• Codice di PrestaShop 9.1.5 su GitHub: FrontController, ProductController, CategoryController, Dispatcher
• Documentazione PrestaShop: SEO e URL, gestione dei prodotti

Domande frequenti

301 o 302 per una migrazione?

301 (o 308) per i contenuti spostati in modo definitivo: Google lo usa come segnale forte, mentre il 302 è un segnale debole. La sua documentazione consiglia i redirect permanenti quando si è sicuri che non verranno annullati.

Conviene reindirizzare tutti i vecchi URL alla home?

No. Google sconsiglia di mandare molti vecchi URL a un’unica destinazione non pertinente: può confondere gli utenti e può essere trattato come soft 404. Meglio la pagina più pertinente, oppure un 404 o 410 se non c’è un equivalente.

Per quanto tempo vanno tenuti i redirect?

Google indica di tenerli il più a lungo possibile, in generale almeno un anno, perché i segnali passino ai nuovi URL e i link esterni vengano riassegnati.

PrestaShop reindirizza da solo il vecchio URL quando cambia lo slug?

Sì, se l’id è nell’URL e «Redirect all’URL canonico» è su 301 (con 302 il redirect è temporaneo, con 0 non c’è redirect). Non succede se cambia lo schema degli URL: i vecchi indirizzi che non corrispondono più a nessuna rotta danno 404.

404 o 410 per le pagine eliminate?

Lo standard preferisce il 410 quando la rimozione è probabilmente permanente. Per Google i due codici sono trattati allo stesso modo, come tutti i 4xx escluso il 429.

Il modulo basta da solo?

No. Il modulo gestisce regole, monitor 404, CSV e 301 automatici, ma la mappatura va preparata da te. Non controlla catene e loop tra le regole e non corregge link interni, canonical, hreflang e sitemap: restano da verificare con uno script e con Search Console.