Come configurare i redirect 301 in PrestaShop dopo una migrazione

Comprendere i redirect e perché il 301 è l'unica scelta corretta

Quando si migra un negozio PrestaShop, gli URL cambiano. I prodotti che si trovavano a un indirizzo ora si trovano a un altro. Le categorie che avevano un determinato slug ora ne hanno uno diverso. Senza redirect, ogni vecchio URL diventa un vicolo cieco, restituendo un errore 404 sia ai visitatori che ai motori di ricerca. L'effetto cumulativo è devastante: traffico perso, posizionamento perso e vendite perse.

Un redirect è un'istruzione dal tuo server che comunica ai browser e ai crawler dei motori di ricerca che una pagina si è spostata. Quando un visitatore o Googlebot richiede il vecchio URL, il server risponde con la nuova posizione e il client segue automaticamente il redirect. Ma non tutti i redirect sono uguali, e utilizzare il tipo sbagliato può compromettere l'intera migrazione.

301 vs 302: una distinzione fondamentale

Un redirect 301 segnala uno spostamento permanente. Comunica ai motori di ricerca di trasferire la link equity accumulata (il valore SEO costruito attraverso backlink, qualità dei contenuti e coinvolgimento degli utenti) dal vecchio URL al nuovo. Nel tempo, Google sostituisce il vecchio URL nel suo indice con quello nuovo. Questo è ciò che desideri dopo una migrazione.

Un redirect 302 segnala uno spostamento temporaneo. Comunica ai motori di ricerca che il vecchio URL tornerà eventualmente disponibile, quindi dovrebbero mantenere il vecchio URL nell'indice e non trasferire la link equity. Utilizzare redirect 302 dopo una migrazione permanente significa che Google continua a cercare di indicizzare i tuoi vecchi URL, i tuoi nuovi URL faticano ad acquisire autorità e perdi posizionamento inutilmente.

Esiste anche il redirect 307, che è l'equivalente HTTP/1.1 del 302, e il redirect 308, che è l'equivalente HTTP/1.1 del 301. Per gli scopi SEO di PrestaShop, il 301 è la scelta standard e universalmente supportata.

La regola è semplice: se la pagina si è spostata permanentemente, usa il 301. Dopo una migrazione, la pagina si è spostata permanentemente. Usa sempre il 301.

Configurazione dei redirect nel file .htaccess (Apache)

La maggior parte delle installazioni PrestaShop funziona su Apache, e il file .htaccess è dove si configurano i redirect. Questo file si trova nella directory root di PrestaShop, insieme a index.php.

La posizione è importante

Il file .htaccess di PrestaShop contiene regole di rewrite che gestiscono gli URL amichevoli, forzano l'HTTPS e instradano le richieste ai controller corretti. Le tue regole di redirect devono essere posizionate prima delle regole di rewrite di PrestaShop. Se le posizioni dopo, le regole di PrestaShop potrebbero intercettare la richiesta per prime e i tuoi redirect non verranno mai eseguiti.

Cerca la riga di commento che dice # Dispatcher o il blocco che inizia con RewriteRule ^api. I tuoi redirect personalizzati vanno sopra questa sezione ma dopo RewriteEngine On.

Redirect di singole pagine

La forma più semplice di redirect associa un vecchio URL specifico a un nuovo URL specifico:

Redirect 301 /vecchia-categoria/vecchio-prodotto.html https://www.esempio.com/nuova-categoria/nuovo-prodotto

La direttiva Redirect fa parte del modulo mod_alias di Apache. Il primo argomento è il codice di stato HTTP (301), il secondo è il vecchio percorso (relativo alla document root) e il terzo è il nuovo URL completo.

Dettagli importanti: il vecchio percorso deve iniziare con una barra e non deve includere il nome del dominio. Il nuovo URL deve essere un URL completo che includa il protocollo e il dominio. Il vecchio percorso viene confrontato in modo esatto, incluse le barre finali e le estensioni dei file.

Redirect basati su pattern con RewriteRule

Quando molti URL seguono un cambiamento di pattern prevedibile, i redirect individuali diventano poco pratici. Il modulo mod_rewrite di Apache permette di scrivere regole basate su pattern utilizzando espressioni regolari:

RewriteEngine On
RewriteRule ^vecchia-categoria/(.*)$ /nuova-categoria/$1 [R=301,L]

Questa regola cattura tutto ciò che segue vecchia-categoria/ e lo aggiunge a nuova-categoria/. Il $1 è un riferimento al primo gruppo catturato (la parte tra parentesi). I flag [R=301,L] specificano un redirect 301 e che questa è l'ultima regola da processare se corrisponde.

Scenari comuni di redirect basati su pattern per le migrazioni PrestaShop:

Rimozione delle estensioni .html:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Passaggio da URL di categoria basati su ID a URL basati sul nome:

RewriteRule ^3-vecchia-categoria(.*)$ /nuova-categoria$1 [R=301,L]

Redirect di un'intera sottodirectory:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Redirect condizionali

A volte è necessario applicare i redirect solo in determinate condizioni. RewriteCond fornisce questa funzionalità:

RewriteCond %{HTTP_HOST} ^vecchiodominio\.com$ [NC]
RewriteRule ^(.*)$ https://www.nuovodominio.com/$1 [R=301,L]

Questo reindirizza tutte le richieste da vecchiodominio.com a nuovodominio.com, preservando il percorso. Il flag [NC] rende la condizione case-insensitive.

Per reindirizzare solo se il file richiesto non esiste sul nuovo server (utile durante una migrazione graduale):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^vecchio-percorso/(.*)$ /nuovo-percorso/$1 [R=301,L]

Configurazione dei redirect in Nginx

Se il tuo PrestaShop funziona su Nginx, i redirect vengono configurati nel file di configurazione del server block, tipicamente situato in /etc/nginx/sites-available/tuodominio.conf o /etc/nginx/conf.d/tuodominio.conf.

Redirect individuali

location = /vecchia-categoria/vecchio-prodotto.html {
  return 301 https://www.esempio.com/nuova-categoria/nuovo-prodotto;
}

Il modificatore = specifica una corrispondenza esatta. Senza di esso, Nginx tratta la location come corrispondenza prefisso, che potrebbe reindirizzare più URL del previsto.

Redirect basati su pattern

location ~ ^/vecchia-categoria/(.*)$ {
  return 301 /nuova-categoria/$1;
}

Il modificatore ~ abilita la corrispondenza regex. Il gruppo catturato $1 funziona allo stesso modo che in Apache.

Redirect basati su map per liste estese

La direttiva map di Nginx è ideale per gestire centinaia o migliaia di redirect individuali senza sovraccaricare il server block:

map $request_uri $redirect_target {
  /vecchio-prodotto-1.html /nuovo-prodotto-1;
  /vecchio-prodotto-2.html /nuovo-prodotto-2;
  /vecchio-prodotto-3.html /nuovo-prodotto-3;
}

server {
  if ($redirect_target) {
    return 301 $redirect_target;
  }
}

Il blocco map viene valutato una sola volta per richiesta ed è altamente efficiente anche con migliaia di voci. È possibile caricare la map da un file esterno utilizzando la direttiva include.

Ricorda di testare la configurazione con nginx -t e di ricaricare con systemctl reload nginx dopo ogni modifica.

Redirect massivi con CSV

Per migrazioni che coinvolgono migliaia di prodotti, scrivere manualmente le regole di redirect non è fattibile. Un approccio basato su CSV semplifica il processo.

Creazione del CSV

Esporta i tuoi vecchi URL dai dati del crawl pre-migrazione o dal database. Esporta i nuovi URL dalla nuova installazione. Abbinali in un foglio di calcolo con due colonne: percorso del vecchio URL e percorso del nuovo URL. Salva come CSV.

Il tuo CSV potrebbe avere questo aspetto:

/3-vecchia-categoria,/nuova-categoria
/vecchia-categoria/vecchio-prodotto-1.html,/nuova-categoria/nuovo-prodotto-1
/vecchia-categoria/vecchio-prodotto-2.html,/nuova-categoria/nuovo-prodotto-2
/content/5-chi-siamo,/content/chi-siamo

Conversione del CSV in regole .htaccess

Un approccio semplice è convertire ogni riga del CSV in una direttiva Redirect. Utilizzando un editor di testo con trova e sostituisci o un semplice strumento da riga di comando:

awk -F',' '{print "Redirect 301 " $1 " https://www.esempio.com" $2}' redirects.csv >> .htaccess

Questo legge il file CSV, divide ogni riga per virgola e genera una direttiva Redirect per ogni riga.

Utilizzo di una tabella nel database

Per liste di redirect molto estese (oltre 10.000 voci), considera la possibilità di archiviare i redirect in una tabella del database e di gestirli a livello applicativo. Crea una tabella con colonne per il vecchio percorso e il nuovo percorso, e scrivi un piccolo modulo PrestaShop o un override che intercetti gli errori 404, controlli la tabella e restituisca un redirect 301 se viene trovata una corrispondenza. Questo approccio è più facile da gestire tramite un'interfaccia di amministrazione, ma aggiunge una piccola query al database per ogni risposta 404.

Soluzioni di redirect basate su moduli

Diversi moduli PrestaShop forniscono la gestione dei redirect attraverso il back office, eliminando la necessità di modificare direttamente i file di configurazione del server.

Vantaggi dei redirect basati su moduli

Un modulo di redirect offre un'interfaccia intuitiva per aggiungere, modificare e eliminare redirect. Include tipicamente funzionalità di importazione/esportazione per operazioni massive, logging per monitorare quali redirect vengono utilizzati, e la possibilità per i membri non tecnici del team di gestire i redirect senza accesso al server.

Come funzionano i redirect basati su moduli

La maggior parte dei moduli di redirect funziona agganciandosi al processo di gestione delle richieste di PrestaShop. Quando arriva una richiesta che normalmente genererebbe un errore 404, il modulo la intercetta, controlla il suo database di redirect per un vecchio URL corrispondente e, se trovato, invia una risposta di redirect 301 al nuovo URL.

Alcuni moduli vanno oltre creando automaticamente redirect quando si modifica l'URL amichevole di un prodotto nel back office. Questo previene il problema comune di rompere i vecchi link quando si ottimizzano gli slug degli URL.

Considerazioni sulle prestazioni

I redirect basati su moduli aggiungono un piccolo overhead a ogni richiesta 404 perché devono interrogare il database. Per la maggior parte dei negozi questo è trascurabile, ma se hai migliaia di redirect e un traffico significativo di bot che colpiscono i vecchi URL, le query al database possono accumularsi. Considera l'utilizzo di un livello di caching o lo spostamento dei redirect più utilizzati nel file .htaccess per prestazioni ottimali.

Redirect regex: potenza e pericolo

I redirect con espressioni regolari sono strumenti potenti che possono gestire trasformazioni URL complesse con una singola regola. Sono anche la fonte più comune di errori di redirect e loop infiniti.

Quando utilizzare i redirect regex

Utilizza i redirect regex quando il cambiamento dell'URL segue un pattern coerente e prevedibile. Buoni candidati includono: rimuovere o aggiungere estensioni file a tutti gli URL, cambiare un prefisso URL per un'intera sezione del sito, rimuovere o aggiungere prefissi di lingua, e eliminare parametri di query.

Pattern regex comuni per PrestaShop

Rimozione del prefisso ID delle categorie che PrestaShop 1.6 aggiunge agli URL delle categorie:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Questa regola corrisponde a URL come /3-scarpe e reindirizza a /scarpe.

Aggiunta di un prefisso di lingua:

RewriteCond %{REQUEST_URI} !^/(en|de|fr|it)/
RewriteRule ^(.+)$ /it/$1 [R=301,L]

Rimozione delle doppie barre:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Testare le regole regex in sicurezza

Prima di distribuire i redirect regex in produzione, testali accuratamente. Utilizza un tester regex online (come regex101.com) per verificare che il tuo pattern corrisponda agli URL desiderati e non corrisponda a URL che non dovrebbe intercettare.

Inizia con un redirect 302 durante i test. Questo impedisce ai motori di ricerca di memorizzare nella cache redirect errati. Una volta verificato che la regola funziona correttamente, cambiala in 301.

Testa i casi limite: URL con parametri di query, URL con caratteri speciali, URL con più pattern corrispondenti. Ciascuno di questi può rivelare problemi che non sono evidenti con URL di test semplici.

Test dei redirect

Distribuire redirect senza test accurati è una ricetta per il disastro. Ecco i metodi che dovresti utilizzare per verificare i tuoi redirect prima e dopo il go-live.

Test da riga di comando con curl

Il comando curl è il modo più affidabile per testare i redirect perché mostra esattamente ciò che il server restituisce:

curl -I https://www.esempio.com/vecchio-prodotto.html

Il flag -I richiede solo gli header. Nella risposta, cerca:

HTTP/1.1 301 Moved Permanently
Location: https://www.esempio.com/nuovo-prodotto

Verifica che il codice di stato sia 301 (non 302) e che l'header Location punti al corretto nuovo URL.

Per seguire la catena di redirect e vedere ogni passaggio:

curl -IL https://www.esempio.com/vecchio-prodotto.html

Il flag -L dice a curl di seguire i redirect, mostrando gli header a ogni passaggio.

Test massivi

Per liste di redirect estese, automatizza i test con un ciclo:

while IFS=, read -r old new; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.esempio.com$old")
  echo "$old -> $status"
done < redirects.csv

Questo legge il tuo file CSV, testa ogni vecchio URL e stampa il codice di stato HTTP. Qualsiasi URL che non restituisce 301 richiede attenzione.

Test nel browser

Apri gli strumenti per sviluppatori del browser (F12), vai alla scheda Network e naviga verso un vecchio URL. La scheda Network mostra la catena di richieste, inclusi tutti i redirect. Verifica il codice di stato, la destinazione del redirect e la pagina finale che viene caricata.

Ispezione in Google Search Console

Dopo la distribuzione, utilizza lo strumento Controllo URL in Google Search Console per verificare come Google vede i tuoi URL reindirizzati. Inserisci un vecchio URL e controlla se Google riconosce il redirect e ha scoperto il nuovo URL.

Catene di redirect e come evitarle

Una catena di redirect si verifica quando un redirect porta a un altro redirect, che può portare a un ulteriore redirect. Ad esempio: l'URL A reindirizza all'URL B, che reindirizza all'URL C, che infine serve il contenuto. Ogni passaggio aggiunge latenza e diluisce la link equity.

Perché le catene di redirect sono dannose

Google ha dichiarato che seguirà le catene di redirect, ma con dei limiti. Dopo un certo numero di passaggi (tipicamente 5-10), Googlebot rinuncia e tratta l'URL come un errore. Anche per catene più corte, ogni passaggio ritarda la consegna della pagina e perde una piccola quantità di link equity.

Per i visitatori, ogni redirect aggiunge 50-200 millisecondi di latenza, a seconda delle condizioni di rete e del tempo di risposta del server. Una catena di 3 redirect può aggiungere mezzo secondo o più al tempo di caricamento percepito.

Cause comuni delle catene di redirect in PrestaShop

La catena più comune si verifica quando una migrazione aggiunge redirect sopra redirect esistenti. Ad esempio, potresti avere vecchi redirect da un precedente cambio di struttura URL, e la nuova migrazione aggiunge un ulteriore livello. L'URL A reindirizza all'URL B (dalla prima migrazione), e l'URL B reindirizza all'URL C (dalla seconda migrazione).

Un'altra causa comune è l'interazione tra il redirect canonico integrato di PrestaShop e i tuoi redirect personalizzati. PrestaShop potrebbe reindirizzare da un URL non canonico alla versione canonica, e se anche il tuo redirect personalizzato corrisponde, ottieni una catena.

L'imposizione dell'HTTPS aggiunge un altro potenziale passaggio. Se il tuo redirect punta a un URL HTTP, e il server poi reindirizza a HTTPS, quella è una catena a due passaggi.

Correzione delle catene di redirect

Esegui un audit dei tuoi redirect regolarmente utilizzando uno strumento di crawling che rileva le catene. Quando trovi una catena, aggiorna il primo redirect in modo che punti direttamente alla destinazione finale. L'URL A dovrebbe reindirizzare direttamente all'URL C, bypassando completamente l'URL B.

Quando aggiungi nuovi redirect durante una migrazione, controlla sempre se l'URL di destinazione è esso stesso un redirect. Se lo è, imposta il nuovo redirect in modo che punti alla destinazione finale.

Errori comuni e come evitarli

Loop di redirect infiniti

Un loop infinito si verifica quando l'URL A reindirizza all'URL B e l'URL B reindirizza nuovamente all'URL A. Il browser rileva questa situazione e mostra un errore ERR_TOO_MANY_REDIRECTS. Le cause comuni includono regole in conflitto nel file .htaccess (una regola reindirizza www verso non-www mentre un'altra reindirizza non-www verso www), redirect in conflitto tra .htaccess e un modulo di redirect, e regole regex troppo ampie che corrispondono ai propri URL di destinazione.

Per risolvere un loop, inizia disabilitando tutti i redirect personalizzati e riabilitandoli uno alla volta fino a quando il loop ricompare. Questo identifica la regola in conflitto.

Dimenticare i parametri di query

Per impostazione predefinita, la direttiva Redirect di Apache passa i parametri di query al nuovo URL. Tuttavia, RewriteRule non passa i parametri di query a meno che non si aggiunga il flag [QSA] (Query String Append). Se i tuoi vecchi URL includono parametri di query importanti (come ?id_product=123), assicurati che vengano gestiti correttamente.

Sensibilità alle maiuscole

Sui server Linux, gli URL sono case-sensitive. /Prodotto.html e /prodotto.html sono URL diversi. Se il tuo vecchio sito aveva URL con maiuscole e minuscole miste e il tuo nuovo sito normalizza tutto in minuscolo, hai bisogno di redirect che gestiscano entrambi i casi. Utilizza il flag [NC] nella RewriteRule per la corrispondenza case-insensitive.

Non reindirizzare tutte le varianti degli URL

Una singola pagina prodotto potrebbe essere accessibile tramite più URL: con e senza barra finale, con e senza estensione .html, con e senza il prefisso del percorso della categoria, con e senza www. Ogni variante che è stata indicizzata necessita del proprio redirect al nuovo URL canonico.

Lasciare i redirect attivi per sempre

Sebbene i redirect debbano rimanere attivi per almeno 12 mesi dopo una migrazione (Google raccomanda almeno un anno), non dovrebbero rimanere indefinitamente. Dopo un anno o più, i vecchi URL non dovrebbero più apparire nei risultati di ricerca né ricevere traffico significativo. Esamina i log dei redirect, rimuovi le regole che non vengono più attivate e mantieni la configurazione pulita.

Riepilogo

Configurare correttamente i redirect 301 è il compito tecnico più importante in una migrazione PrestaShop. Ogni vecchio URL che aveva traffico, backlink o visibilità nei motori di ricerca deve reindirizzare alla sua controparte con un codice di stato 301. Il metodo di implementazione dipende dal tuo server (Apache .htaccess o configurazione Nginx), dal numero di URL (regole individuali, pattern regex o moduli basati su database) e dalle capacità tecniche del tuo team. Testa ogni redirect prima del go-live utilizzando curl o gli strumenti per sviluppatori del browser. Fai attenzione alle catene di redirect, ai loop infiniti e ai problemi di sensibilità alle maiuscole. Monitora Google Search Console dopo la distribuzione per verificare che Google stia elaborando correttamente i tuoi redirect. E ricorda che un 302 dove dovrebbe esserci un 301 non è mai innocuo. È sempre la scelta sbagliata per una migrazione permanente.