Struttura URL di PrestaShop: URL Puliti, Canonical e Come Evitare i Contenuti Duplicati

Modificare la struttura degli URL del vostro negozio PrestaShop una delle attivit SEO pi impattanti e pi rischiose che possiate intraprendere. Fatta correttamente, elimina anni di debito tecnico accumulato, cancella i contenuti duplicati e vi offre un'architettura URL scalabile con il vostro catalogo. Fatta male, pu cancellare mesi o anni di traffico organico da un giorno all'altro.

Ho gestito migrazioni URL per negozi PrestaShop che vanno da piccole boutique a cataloghi con oltre 30.000 prodotti. Questa guida non riguarda cosa rende un "buon URL" in teoria ci sono molti articoli che lo trattano. Questa la guida pratica, passo dopo passo, per i proprietari di negozi che stanno effettivamente cambiando i loro URL: come pianificare la migrazione, implementare correttamente i redirect 301, monitorare la transizione in Google Search Console e recuperare se qualcosa va storto.

Quando Dovreste Cambiare la Vostra Struttura URL?

I cambiamenti URL comportano rischi reali, quindi assicuratevi di averne effettivamente bisogno. Ecco motivi legittimi per ristrutturare gli URL in PrestaShop:

• Percorsi categoria negli URL prodotto che causano duplicati: La configurazione predefinita di PrestaShop include il percorso della categoria negli URL prodotto (/bags/leather/blue-wallet). Quando un prodotto appartiene a pi categorie, diventa accessibile da URL multipli un classico problema di contenuto duplicato.
• ID non necessari negli URL: URL come /42-wallets o /123-blue-leather-wallet.html non aggiungono alcun valore SEO o per l'utente. Rimuovere gli ID crea URL pi puliti e condivisibili.
• Prefissi lingua su negozi monolingua: Un negozio che serve solo clienti italiani non ha bisogno di /it/ in ogni URL.
• Estensioni .html legacy: Alcune configurazioni PrestaShop aggiungono .html a ogni URL. Sebbene innocuo, rimuoverlo crea URL pi corti e puliti.
• Migrazione di piattaforma: Passare da un altro CMS a PrestaShop o da PrestaShop 1.6 a 1.7/8.x spesso cambia automaticamente i pattern URL.
• Ristrutturazione delle categorie: Riorganizzare la gerarchia del catalogo cambia gli URL delle categorie e qualsiasi URL prodotto che includa percorsi di categoria.

Quando NON Cambiare gli URL

Se i vostri URL sono funzionali, indicizzati e si posizionano bene lasciateli stare. Un URL con un numero ID che si posiziona in prima pagina di Google ha infinitamente pi valore di un URL "pi pulito" che riparte da zero. I cambiamenti URL cosmetici non valgono quasi mai il rischio della migrazione.

Il Vero Costo di Cambiare URL Senza un Piano

Devo essere diretto su cosa succede quando i cambiamenti URL vanno male, perch l'ho visto accadere troppe volte:

• Calo di traffico immediato del 20-60% Google deve ri-scansionare e ri-valutare ogni URL modificato. Durante questo periodo, le pagine possono temporaneamente scomparire dall'indice.
• Backlink persi: Ogni sito esterno che linka ai vostri vecchi URL raggiunger un 404 a meno che non reindirizziate. Quei backlink spesso costruiti nel corso di anni trasferiscono zero valore senza un redirect 301.
• Link interni rotti: Menu, footer, cross-sell di prodotti, link nelle pagine CMS, template email tutti contengono URL hardcoded che si romperanno.
• Tempo di recupero di 4-16 settimane Anche con redirect perfetti, Google impiega tempo per elaborare i cambiamenti. I dati di Semrush suggeriscono che la maggior parte delle migrazioni eseguite correttamente recupera il 90-95% del traffico entro 8-12 settimane (fonte: Semrush).

Detto questo, quando una migrazione necessaria specialmente per correggere contenuti duplicati dai percorsi di categoria il beneficio SEO a lungo termine supera il costo a breve termine. La chiave eseguirla correttamente.

Passaggio 1: Analizzare il Vostro Panorama URL Attuale

Prima di cambiare qualsiasi cosa, avete bisogno di un quadro completo dei vostri URL attuali. Questo significa:

Scansionare l'Intero Sito

Usate Screaming Frog, Sitebulb o qualsiasi crawler per estrarre ogni URL del vostro sito. Esportate l'elenco completo. Per un negozio PrestaShop, prestate particolare attenzione a:

• URL prodotto con percorsi di categoria: Lo stesso prodotto che appare su /category-a/product e /category-b/product
• URL con numeri ID: /42-category-name vs. /category-name
• URL basati su parametri: ?id_product=123&controller=product sono le versioni non-friendly che potrebbero essere ancora scansionabili
• URL paginati: /category?page=2 fino a /category?page=50

Esportare i Dati di Google Search Console

Andate su Search Console → Rendimento → Pagine. Esportate tutti gli URL che hanno ricevuto impressioni o clic negli ultimi 16 mesi. Questi sono i vostri URL "di valore" quelli che Google sta attivamente posizionando. Qualsiasi piano di migrazione deve tenere conto di ognuno di essi.

Esportare i Dati dei Backlink

Usate Ahrefs, Semrush o il rapporto Link di Google Search Console per identificare quali dei vostri URL hanno backlink esterni. Questi sono i vostri target di redirect a pi alta priorit perdere il valore dei backlink da domini referenti ad alta autorit pu richiedere anni per essere ricostruito.

Documentare lo Stato Attuale

Create un foglio di calcolo con colonne per: URL attuale, stato HTTP, valore del tag canonical, numero di backlink, clic organici mensili e URL di destinazione nuovo. Questo diventa la vostra mappa di migrazione il documento singolo pi importante dell'intero processo.

Passaggio 2: Progettare la Nuova Struttura URL

Per i negozi PrestaShop, raccomando questi principi di struttura URL:

Rimuovere i Percorsi di Categoria dagli URL Prodotto

Questo il cambiamento URL singolo pi comune e pi importante per i negozi PrestaShop. Invece di:

/bags/leather-bags/blue-leather-wallet

Usate:

/blue-leather-wallet

Perch? Perch quando un prodotto appartiene a pi categorie, l'approccio con percorso di categoria crea URL multipli per lo stesso prodotto. PrestaShop tenta di gestire questo con tag canonical, ma nella pratica ho visto Google indicizzare entrambe le versioni comunque, diluendo i segnali di posizionamento tra i duplicati.

Una struttura URL prodotto piatta dove i prodotti si trovano al livello root elimina questo problema alla radice. Ogni prodotto ha esattamente un URL indipendentemente da quante categorie gli appartengano. Strumenti come lo Smart SEO Friendly URL Manager rendono questo cambiamento semplice in PrestaShop.

Mantenere gli URL Categoria con Gerarchia (Ma Superficiale)

Le categorie beneficiano della gerarchia negli URL perch comunica struttura sia agli utenti che ai motori di ricerca:

/bags/leather-bags    ✓ Buono  relazione padre/figlio chiara
/bags/leather-bags/casual/everyday    ✗ Troppo profondo  limitare a 2 livelli

Rimuovere ID, Estensioni e Prefissi Non Necessari

/42-wallets            → /wallets
/blue-wallet.html      → /blue-wallet
/en/wallets            → /wallets  (negozi monolingua)
/home/1-home.html      → /         (homepage)

Usare Trattini, Sempre Minuscolo

Google tratta i trattini come separatori di parole (blue-wallet = "blue" + "wallet") ma gli underscore come connettori (blue_wallet = "bluewallet"). Usate sempre i trattini. Usate sempre il minuscolo gli URL sono case-sensitive, e /Blue-Wallet un URL diverso da /blue-wallet.

Passaggio 3: Costruire la Mappa dei Redirect

Questo il passaggio pi laborioso e quello in cui gli errori sono pi costosi. Ogni vecchio URL che sia mai stato indicizzato, linkato o abbia ricevuto traffico deve essere mappato al suo nuovo equivalente.

Mappatura Uno-a-Uno

La regola d'oro: ogni vecchio URL reindirizza al suo equivalente diretto. Non alla homepage. Non a una pagina di categoria. Allo stesso identico contenuto al suo nuovo URL.

/42-wallets                      → /wallets
/bags/leather-bags/blue-wallet   → /blue-wallet
/123-blue-wallet.html            → /blue-wallet
/en/bags/wallets                 → /bags/wallets

Gestire Correttamente le Pagine Eliminate

Per i prodotti che non esistono pi, avete tre opzioni in ordine di preferenza:

1. Redirect al prodotto equivalente pi vicino se avete discontinuato il "Portafoglio Blu v1" e lo avete sostituito con il "Portafoglio Blu v2," reindirizzate al nuovo prodotto.
2. Redirect alla categoria madre se non esiste un equivalente diretto, inviate gli utenti alla pagina categoria dove possono trovare alternative.
3. Restituire un 410 Gone se il prodotto non ha equivalenti e anche la categoria sparita, un 410 dice a Google di rimuovere l'URL dal suo indice pi velocemente di un 404.

Non reindirizzate mai tutto alla homepage. Google lo chiama "soft 404" e non fornisce alcun valore SEO i segnali di posizionamento del vecchio URL vengono semplicemente persi.

Evitare Catene di Redirect

Una catena di redirect si verifica quando l'URL A reindirizza all'URL B, che reindirizza all'URL C. Ogni passaggio aggiunge latenza (tipicamente 50-200ms per redirect), e sebbene Google dica che seguir fino a 5 passaggi, il valore dei link pu diminuire attraverso le catene. Pi importante ancora, le catene sono un incubo di manutenzione che si moltiplica con le migrazioni successive.

Reindirizzate sempre direttamente dall'URL originale alla destinazione finale:

✗ Male:  /old-url → /intermediate-url → /final-url
✓ Bene: /old-url → /final-url

Se avete redirect esistenti da una migrazione precedente, aggiornateli per puntare direttamente ai nuovi URL piuttosto che concatenarli attraverso il passaggio intermedio.

Passaggio 4: Implementare i Redirect 301 in PrestaShop

Ci sono diversi modi per implementare i redirect in PrestaShop, ciascuno con compromessi diversi:

Metodo 1: Regole .htaccess (Apache)

Il metodo pi veloce e pi efficiente lato server. I redirect avvengono a livello web server prima ancora che PrestaShop si carichi:

# Redirect prodotti individuali
RewriteRule ^42-wallets$ /wallets [R=301,L]
RewriteRule ^bags/leather-bags/blue-wallet$ /blue-wallet [R=301,L]

# Redirect basati su pattern (rimuovi estensione .html)
RewriteRule ^(.+)\.html$ /$1 [R=301,L]

# Redirect basati su pattern (rimuovi prefisso ID)
RewriteRule ^[0-9]+-(.+)$ /$1 [R=301,L]

# Rimuovi prefisso lingua per negozi monolingua
RewriteRule ^en/(.*)$ /$1 [R=301,L]

Inserite le regole di redirect prima delle regole di rewrite proprie di PrestaShop nel file .htaccess. I flag [R=301,L] significano: restituire uno stato 301 (redirect permanente) e interrompere l'elaborazione di ulteriori regole.

Pro: Esecuzione pi veloce, nessun overhead PHP, funziona anche se PrestaShop offline.
Contro: Richiede manutenzione manuale, errori nelle regex possono rompere l'intero sito, solo Apache.

Metodo 2: Modulo PrestaShop

Un modulo di gestione redirect fornisce un'interfaccia guidata dal database per creare e gestire i redirect. Questo l'approccio che raccomando per la maggior parte dei negozi perch:

• Il personale non tecnico pu gestire i redirect tramite il pannello di amministrazione
• Importazione massiva da CSV fondamentale per grandi migrazioni con migliaia di redirect
• Rilevamento automatico dei 404 con suggerimenti di redirect
• Nessun rischio di rompere la sintassi del .htaccess

Metodo 3: Configurazione Nginx

Per i negozi su Nginx (incluse molte installazioni basate su Docker), i redirect vanno nella configurazione del server:

location = /42-wallets {
    return 301 /wallets;
}

# Redirect basato su pattern
location ~ ^/(\d+)-(.+)$ {
    return 301 /$2;
}

Nginx richiede un reload dopo le modifiche alla configurazione (nginx -s reload), ma i redirect si eseguono pi velocemente dell'approccio .htaccess di Apache perch la configurazione caricata in memoria piuttosto che letta dal disco per ogni richiesta.

Passaggio 5: Aggiornare Tutto Ci Che Referenzia i Vecchi URL

I redirect sono una rete di sicurezza, non una soluzione. Ogni riferimento interno ai vecchi URL dovrebbe essere aggiornato per puntare direttamente ai nuovi URL. Affidarsi ai redirect per la navigazione interna spreca budget di scansione e aggiunge latenza non necessaria.

Link Interni da Aggiornare

• Menu di navigazione menu superiore, link nel footer, navigazione laterale
• Contenuto pagine CMS qualsiasi link hardcoded in "Chi Siamo", "Politica di Spedizione", ecc.
• Descrizioni prodotto riferimenti incrociati ad altri prodotti o categorie
• Template email conferma d'ordine, notifica di spedizione, email carrello abbandonato
• Sitemap XML rigenerate immediatamente con i soli nuovi URL (consultate la nostra guida alle sitemap)
• Profili social media qualsiasi link nella vostra bio, post fissati o annunci
• Feed Google Merchant Center gli URL prodotto nel vostro feed shopping devono corrispondere alla nuova struttura
• Dati strutturati il markup JSON-LD nelle pagine prodotto include URL che devono essere aggiornati

Pulizia URL a Livello Database

PrestaShop memorizza gli URL in diverse tabelle del database. Dopo aver cambiato il vostro schema URL, verificate che queste tabelle riflettano la nuova struttura:

• ps_product_lang la colonna link_rewrite
• ps_category_lang la colonna link_rewrite
• ps_cms_lang la colonna link_rewrite

Se avete cambiato le impostazioni degli URL amichevoli (rimosso il percorso di categoria, rimosso gli ID), PrestaShop rigenera gli URL da questi valori link_rewrite. Assicuratevi che siano puliti nessun carattere speciale, nessuna maiuscola, nessun underscore.

Passaggio 6: La Strategia dei Tag Canonical

Anche con URL puliti e redirect corretti, i tag canonical rimangono essenziali. Sono la vostra dichiarazione esplicita ai motori di ricerca: "Questa la versione ufficiale di questa pagina."

Canonical Auto-referenzianti

Ogni pagina del vostro negozio dovrebbe avere un tag canonical che punta a se stessa. Questo protegge da contenuti duplicati accidentali dovuti a parametri di tracciamento, ID di sessione o altre variazioni URL:

<link rel="canonical" href="https://yourstore.com/blue-leather-wallet" />

In PrestaShop, i tag canonical vengono generati automaticamente per le pagine prodotto e categoria, ma verificate che stiano usando la nuova struttura URL non quella vecchia. Il modulo Product Canonical Manager vi d un controllo fine sulla generazione dei tag canonical.

Canonical per Contenuti Paginati

Le pagine categoria con paginazione meritano attenzione speciale. Google ha rimosso il supporto per rel="prev"/rel="next" anni fa, quindi la best practice attuale :

• Ogni pagina paginata (/wallets?page=1, /wallets?page=2) ottiene un canonical auto-referenziante
• Se preferite, canonicalizzate tutte le pagine paginate alla pagina 1 ma questo significa che i prodotti dalla pagina 2 in poi sono scopribili solo tramite link interni, non tramite la sitemap
• In alternativa, usate pagine "mostra tutto" se la dimensione del catalogo lo permette una singola pagina con tutti i prodotti della categoria

Canonical Cross-Domain

Se gestite un setup PrestaShop multi-negozio con prodotti condivisi tra domini, i tag canonical cross-domain prevengono contenuti duplicati tra i negozi. Il canonical su store-b.com/blue-wallet pu puntare a store-a.com/blue-wallet per consolidare i segnali di posizionamento.

Passaggio 7: Budget di Scansione e Perch Conta

Il budget di scansione il numero di pagine che Googlebot scansioner sul vostro sito in un determinato arco di tempo. Per negozi piccoli (sotto le 1.000 pagine), il budget di scansione raramente un problema. Per cataloghi pi grandi, influisce direttamente sulla velocit con cui le nuove pagine vengono scoperte e con quale frequenza le pagine esistenti vengono ri-scansionate.

Le migrazioni URL impattano il budget di scansione in diversi modi:

• L'elaborazione dei redirect consuma budget di scansione: Ogni redirect 301 che Googlebot incontra conta come un URL scansionato. Se avete 10.000 redirect e Google li visita tutti, sono 10.000 scansioni spese per redirect invece che per pagine di contenuto reale.
• Gli URL duplicati raddoppiano i requisiti di scansione: Se i vecchi URL rimangono accessibili (restituendo 200 invece di 301), Google potrebbe scansionare sia le vecchie che le nuove versioni raddoppiando la domanda di scansione senza fornire alcun valore aggiuntivo.
• Le catene di redirect moltiplicano il costo: Una catena A → B → C conta come tre URL scansionati per un singolo contenuto.

La soluzione: implementate i redirect correttamente (diretti, senza catene), aggiornate i link interni per puntare ai nuovi URL (riducendo gli hit sui redirect) e rigenerate la vostra sitemap XML con i soli nuovi URL.

Passaggio 8: Monitorare la Migrazione in Google Search Console

Dopo aver implementato i cambiamenti URL e i redirect, il monitoraggio fondamentale. Ecco una guida settimana per settimana:

Giorno 1-3: Verificare che i Redirect Funzionino

• Testate 50-100 vecchi URL manualmente (o con un crawler). Ciascuno dovrebbe restituire uno stato 301 con la destinazione corretta.
• Controllate i log del server per errori 404 qualsiasi picco indica redirect mancanti.
• Reinviate la vostra sitemap aggiornata in Google Search Console.

Settimana 1-2: Valutazione dell'Impatto Iniziale

• Aspettatevi un calo di traffico del 10-30%. Questo normale e non motivo di allarme.
• Monitorate il rapporto "Pagine" in Search Console per nuovi errori di scansione.
• Cercate le voci "Redirect" queste confermano che Google sta scoprendo e seguendo i vostri 301.
• Verificate che i vecchi URL vengano gradualmente sostituiti dai nuovi nel rapporto "Rendimento".

Settimana 3-6: Fase di Recupero

• Il traffico dovrebbe iniziare a recuperare man mano che Google rielabora i redirect e ricalcola i posizionamenti.
• Monitorate le pagine che sono uscite dall'indice verificate se il loro redirect funziona correttamente.
• Cercate lo stato "Scansionata - attualmente non indicizzata" sui nuovi URL. Questo potrebbe indicare contenuti thin o problemi di qualit non correlati alla migrazione.

Settimana 8-12: Stabilizzazione

• Entro la settimana 8-12, il traffico dovrebbe essere al 90-100% dei livelli pre-migrazione.
• Se il traffico ancora in calo del 20%+ alla settimana 12, investigate le pagine specifiche il problema probabilmente con redirect individuali, non con la migrazione nel suo complesso.
• Iniziate ad analizzare le catene di redirect nel tempo, i siti di terze parti aggiorneranno i loro link, riducendo la necessit di alcuni redirect.

In Corso: Quando Rimuovere i Redirect

Google raccomanda di mantenere i redirect attivi per almeno un anno. Dopo, i redirect ad alto valore (pagine con backlink) dovrebbero rimanere permanentemente. I redirect a basso valore (pagine senza backlink e senza traffico di ricerca) possono essere rimossi dopo 12-18 mesi e lasciati restituire 404/410.

Gestire i Negozi Multilingua

I negozi PrestaShop multilingua affrontano una complessit URL aggiuntiva. Ogni prodotto esiste su /en/blue-wallet, /de/blaue-brieftasche, /fr/portefeuille-bleu, ecc. Quando ristrutturate gli URL, dovete:

• Mantenere i prefissi lingua per i negozi multilingua (servono a uno scopo reale dire a Google quale versione linguistica servire)
• Assicurarvi che i tag hreflang puntino ai nuovi URL in tutte le versioni linguistiche
• Creare redirect per ogni variante linguistica se cambiate l'URL italiano, vi servono redirect corrispondenti per tedesco, francese e ogni altra lingua
• Aggiornare i valori link_rewrite nel database per tutte le lingue, non solo quella predefinita

Il conteggio dei redirect si moltiplica per il numero di lingue. Un negozio con 5.000 prodotti in 4 lingue potrebbe necessitare di 20.000 redirect per una ristrutturazione URL completa.

Il Problema dei Contenuti Duplicati in PrestaShop: Cause Principali

Prima di concludere, lasciate che affronti i problemi specifici di contenuto duplicato che vedo pi spesso in PrestaShop perch comprenderli vi aiuta a progettare una struttura URL che prevenga i problemi piuttosto che limitarsi a correggerli:

Prodotti in Pi Categorie

Un prodotto assegnato sia a "Saldi" che a "Portafogli" crea due URL. PrestaShop aggiunge tag canonical, ma la correzione pi sicura rimuovere del tutto i percorsi di categoria dagli URL prodotto.

www vs. non-www

Se sia www.yourstore.com che yourstore.com risolvono al vostro negozio senza un redirect, ogni pagina duplicata. Correggete con un redirect 301 nel .htaccess o nella configurazione server scegliete una versione e reindirizzate l'altra.

HTTP vs. HTTPS

Stesso problema di www/non-www. Se http://yourstore.com ancora risolve, reindirizzatelo a https:// con un 301.

Slash Finale

/wallets e /wallets/ sono tecnicamente URL diversi. Scegliete una convenzione e reindirizzate l'altra. Il default di PrestaShop senza slash finale mantenetelo a meno che non abbiate un motivo specifico per non farlo.

ID di Sessione e Parametri di Tracciamento

/blue-wallet?utm_source=newsletter&utm_medium=email se i vostri tag canonical sono corretti, questo gestito. Ma verificate che PrestaShop non stia generando tag canonical che includono parametri di tracciamento.

Conclusione: La Migrazione un Progetto, Non una Correzione Rapida

Una migrazione URL di PrestaShop non qualcosa che si fa un venerd pomeriggio. un progetto che richiede un audit, un piano, una mappa di redirect, implementazione, aggiornamento dei link interni, rigenerazione della sitemap e settimane di monitoraggio. Ma quando avete contenuti duplicati che dissipano i segnali di posizionamento su URL multipli, o una struttura URL che spreca budget di scansione su variazioni di parametri la migrazione vale la pena.

Pianificate meticolosamente, reindirizzate tutto, aggiornate tutti i riferimenti interni, monitorate settimanalmente in Search Console e date a Google 8-12 settimane per elaborare i cambiamenti. Non ho mai visto una migrazione ben eseguita che non sia riuscita a recuperare. Ho visto molte migrazioni mal pianificate causare danni duraturi.

Prendetevi il tempo per farla bene.