Initpc: migrazione SEO di 16 anni di URL a WooCommerce

Un e-commerce che vende online da sedici anni non ha un solo insieme di indirizzi: ne ha cinque, uno per ogni piattaforma che lo ha fatto funzionare. Initpc è passato da osCommerce a Zen Cart, poi a Magento, a Magento 2 e infine a WooCommerce, e ogni generazione ha scritto i propri URL con una grammatica diversa. Quegli indirizzi vivono ancora nei risultati di Google, nei link di forum e blog, nei preferiti dei clienti.

La migrazione SEO è consistita nel far sì che tutta quella storia continuasse ad arrivare da qualche parte. Con oltre 280.000 prodotti e più di un milione di media, la differenza fra una migrazione che regge e una che disperde anni di posizionamento sta nel metodo: come si censiscono gli URL, come si decidono le destinazioni, cosa si controlla dopo.

Questa pagina è un approfondimento del case study Initpc, dove raccontiamo l'architettura completa del progetto. Qui ci concentriamo sull'unico strato che nessuna piattaforma può portarsi dietro da sola: gli indirizzi.

Cinque piattaforme, cinque grammatiche di URL

osCommerce e Zen Cart costruivano gli URL attorno a uno script PHP e a parametri di query: la scheda prodotto aveva la forma product_info.php?products_id=…, la categoria index.php?cPath=… con i livelli concatenati. Ordinamento, pagina e sessione erano altri parametri: un singolo articolo esisteva sotto molte varianti dello stesso indirizzo.

Magento ha introdotto i permalink parlanti con estensione .html: nome-del-prodotto.html per la scheda, categoria/sottocategoria.html per la categoria. Lo stesso prodotto era raggiungibile dal percorso diretto e da quello annidato sotto la categoria, mentre paginazione e filtri a livelli (?p=…, ?limit=…, attributi) moltiplicavano le varianti indicizzabili.

Magento 2 ha conservato lo schema, ma la rigenerazione delle riscritture durante l'aggiornamento ha prodotto slug leggermente diversi per una parte del catalogo.

WooCommerce, la piattaforma attuale, usa la struttura di WordPress: /prodotto/nome-del-prodotto/ e /categoria-prodotto/categoria/sottocategoria/, con slash finale, più le paginazioni /page/N/ e i filtri per attributo.

Generazione	Forma dell'URL	Regola di migrazione applicata
osCommerce	product_info.php?products_id=…, index.php?cPath=…	301 puntuale per id, dalla tabella id → prodotto attuale
Zen Cart	stessi script con parametri aggiuntivi (&page=, &sort=, session id)	Normalizzazione dei parametri, poi stessa regola puntuale per id
Magento	nome-prodotto.html, categoria/sotto.html, ?p=, filtri a livelli	301 a pattern sull'estensione .html, eccezioni puntuali per gli slug cambiati
Magento 2	come Magento, con slug rigenerati	Riconciliazione degli slug divergenti, poi regola a pattern
WooCommerce	/prodotto/slug/, /categoria-prodotto/…/, /page/N/	Canonical, sitemap XML e regole di crawl per paginazioni e filtri

Il censimento: sapere cosa esiste prima di decidere dove va

Nessun elenco degli URL storici esisteva in un solo posto: lo abbiamo ricostruito incrociando più fonti.

I log del server sono la fonte più onesta: registrano cosa chiedono davvero visitatori e crawler, comprese le forme che nessuno ricordava più. Search Console ci ha dato la vista di Google: pagine indicizzate ed escluse, errori di scansione, indirizzi ancora richiesti dopo anni. Le sitemap XML delle piattaforme precedenti hanno riempito i vuoti per gli indirizzi meno visitati. I backlink hanno indicato quali URL avessero un valore esterno da proteggere a prescindere dal traffico.

Ne è uscito un inventario unico, con ogni indirizzo classificato per generazione, tipo (prodotto, categoria, paginazione, filtro, immagine, pagina statica) e peso: senza, ogni regola sarebbe stata un'ipotesi.

Mappatura e redirect: pattern dove possibile, puntuali dove serve

Prima le regole a pattern: dove una forma intera di URL si trasforma con una legge semplice (l'estensione .html che cade, la categoria annidata che diventa un percorso di WooCommerce), una sola regola copre un'intera generazione e resta leggibile.

Poi i redirect puntuali: gli identificativi numerici di osCommerce e Zen Cart non hanno alcuna relazione con gli slug attuali, quindi servono tabelle di corrispondenza generate dal database del gestionale, che conserva il codice prodotto attraverso tutte le migrazioni. Lo stesso vale per gli slug di Magento 2 divergenti da Magento: una lista di eccezioni, non una regola.

Due vincoli valgono per entrambi. Niente catene: un URL di osCommerce che redirige a quello di Magento, poi a Magento 2 e infine a WooCommerce spreca budget di scansione e perde forza a ogni salto: ogni indirizzo storico punta direttamente alla destinazione finale, e a ogni cambio le regole si riscrivono, non si impilano. Ordine di valutazione: le regole puntuali vengono prima di quelle a pattern, altrimenti l'eccezione non viene mai raggiunta; i parametri di ordinamento e sessione sono rimossi a monte, così tutte le varianti convergono sulla stessa destinazione.

Canonical e sitemap XML sulla piattaforma attuale

I redirect risolvono il passato; per il presente anche WooCommerce va disciplinato, perché produce più indirizzi per la stessa risorsa.

Ogni scheda e ogni categoria dichiara un canonical verso la propria forma pulita, senza parametri. Le pagine di paginazione lo mantengono su se stesse, perché sono contenuti distinti; le combinazioni di filtri rimandano alla categoria e restano fuori dall'indice. Google può comunque ignorare un canonical se la pagina indicata è troppo diversa da quella che lo dichiara: va verificato in Search Console.

Le sitemap XML sono suddivise per tipo: prodotti, categorie, pagine statiche e una sitemap dedicata alle immagini, che associa a ogni prodotto le sue foto con l'indirizzo attuale. Su questo catalogo la sitemap è un indice di file, generato in base a ciò che è effettivamente pubblicato e aggiornato quando cambia la disponibilità: è il lavoro del gestionale che sincronizza i magazzini con il sito.

Prodotti fuori catalogo: 301, 410 o lasciare la pagina

La decisione più delicata riguarda ciò che non esiste più: in sedici anni molti prodotti sono usciti dal catalogo, e ognuno aveva un indirizzo, spesso più di uno.

Se esiste un sostituto diretto (codice aggiornato, versione successiva dello stesso modello), redirect 301 verso la nuova scheda.

Se il prodotto è sparito ma la categoria ha senso, redirect 301 verso la categoria più specifica: chi cercava una cartuccia di un modello dismesso trova le cartucce compatibili con la stessa stampante, non la home page. Il redirect verso la home lo abbiamo escluso a priori: Google lo tratta come un soft 404.

Se non c'è né sostituto né categoria pertinente, la pagina restituisce 410 Gone: dichiara la rimozione e l'indice si ripulisce più in fretta che con un 404 generico.

I prodotti temporaneamente non disponibili restano invece pubblicati, con lo stato corretto nei dati strutturati: togliere e rimettere una scheda costa più, in termini di indicizzazione, che lasciarla visibile con un onesto "non disponibile".

Immagini, media e backlink storici

Le immagini sono il patrimonio più voluminoso e quello che si perde con più facilità: ogni piattaforma le salvava in una cartella diversa, con nomi e tagli diversi, e i loro indirizzi compaiono in Google Immagini, nei marketplace e nelle pagine di terzi.

Per i media vale la stessa logica dei prodotti: regole a pattern dalle cartelle delle piattaforme precedenti verso lo storage attuale, e una tabella di corrispondenza per i file rinominati. Le schede prodotto generate con Hector AI hanno mantenuto l'indirizzo delle immagini dove il file era lo stesso.

I backlink storici hanno avuto la priorità: ogni URL con link esterni è stato verificato dopo la messa in produzione delle regole, controllando che la destinazione fosse pertinente e raggiunta in un solo salto. Dove il link puntava a un contenuto rimosso abbiamo preferito la categoria più vicina al 410: un link esterno merita di essere raccolto anche se il prodotto non c'è più.

Monitoraggio dopo la migrazione

La migrazione finisce quando il crawler ha smesso di trovare sorprese. Nelle settimane successive abbiamo controllato, prima ogni giorno e poi con cadenza più larga:

• gli errori 404 nei log e in Search Console, aggregati per forma di URL: ogni schema nuovo che compare è una regola mancante;
• i soft 404, pagine che rispondono 200 ma che Google giudica vuote: categorie svuotate, ricerche interne indicizzate, redirect verso destinazioni generiche;
• i canonical ignorati, segnalati da Search Console quando sceglie un indirizzo diverso da quello dichiarato: sintomo di pagine troppo diverse, redirect incoerenti o parametri non rimossi;
• la copertura dell'indice, confrontata con l'inventario del censimento: le pagine indicizzate devono convergere verso i prodotti a catalogo.

A questo si aggiungono il controllo delle sitemap (URL in mappa che rispondono redirect o 404) e la lettura delle query in Search Console.

È lo stesso metodo della migrazione di un CMS da Joomla a WordPress e di ogni sviluppo e progettazione di e-commerce che seguiamo: la piattaforma cambia, il patrimonio di indirizzi deve restare.