20 ott 2026 · 10 min di lettura

Come lasciare Magento 2 senza perdere posizioni su Google

La maggior parte dei negozi Magento che perde traffico organico dopo un trasloco non lo perde perché la nuova piattaforma è peggiore. Lo perde perché migliaia di vecchi indirizzi hanno smesso di rispondere, o hanno iniziato a rispondere con la pagina sbagliata. Questa è una guida pratica ai punti in cui una migrazione da Magento 2 lascia scappare posizioni, al perché di ognuno, e una checklist che funziona qualunque sia la piattaforma di arrivo.

In questo articolo

Una migrazione che sembrava andata bene il giorno del lancio

Lo schema è noto nei forum dei commercianti. Un negozio con qualche migliaio di prodotti lascia Magento in un fine settimana. Il nuovo sito sembra giusto, gli ordini arrivano il lunedì, tutti tirano un sospiro di sollievo. Tre settimane dopo il traffico organico è calato di un terzo. Search Console è pieno di 404 su indirizzi che finiscono in .html, le visite dalla ricerca immagini sono quasi sparite, un intero ramo di vecchi link alle categorie finisce sulla home page, e nessuno sa dire quale di questi problemi pesi di più.

Non è sempre così netto. In una discussione un commerciante ha perso circa metà del traffico dopo aver lasciato Magento pur avendo redirect per prodotti, categorie e articoli; le risposte indicavano categorie rinominate, contenuti e struttura cambiati, e le settimane che servono ai segnali per passare attraverso i redirect. In un'altra è calato solo il Regno Unito, tre mesi dopo il trasloco, e i sospetti erano vecchi URL che nessuno aveva mappato e tag hreflang mancanti. La lezione è la stessa: un trasloco è una lista di URL e di segnali, e ciò che non è nella lista va perso.

Perché gli URL di Magento sono più difficili da spostare

Magento costruisce gli indirizzi da più impostazioni insieme. La chiave URL di un prodotto può avere un suffisso come .html, può essere servita con o senza il percorso della categoria e può stare dietro un codice negozio. La stessa documentazione Adobe sulle riscritture URL mostra lo stesso prodotto raggiungibile come gear/bags/impulse-duffle.html e come impulse-duffle.html, a seconda della configurazione.

Dietro tutto questo c'è la tabella url_rewrite. Contiene ogni indirizzo a cui Magento risponde: quelli attuali, le varianti con il percorso di categoria e i 301 creati in automatico ogni volta che qualcuno ha cambiato una chiave URL negli anni. Quella tabella, non la sitemap, è l'elenco reale di ciò che Google può conoscere. Esportatela prima di ogni altra cosa.

Dove finiscono le posizioni: URL che cambiano

  • Il suffisso .html. Come si vede: tutti i prodotti e le categorie danno 404 dopo il lancio, o finiscono nella ricerca. Perché: quasi nessun'altra piattaforma usa un suffisso, quindi /cappotto-lana.html diventa /cappotto-lana o /products/cappotto-lana. La soluzione: una regola che toglie il suffisso va bene per iniziare, ma verificate ogni regola sull'esportazione reale, perché chiavi di categorie e prodotti possono coincidere.
  • Percorsi di categoria negli URL dei prodotti. Come si vede: l'URL breve del prodotto fa redirect, ma /donna/cappotti/cappotto-lana.html no. Perché: con le categorie nel percorso, un prodotto ha tanti indirizzi quante categorie, e ci sono link esterni verso tutti. La soluzione: mappare ogni request_path di ogni prodotto all'unico nuovo indirizzo, non solo quello canonico.
  • Codici negozio. Come si vede: una seconda lingua o un secondo paese perde tutto. Perché: con Add Store Code to URLs attivo, Adobe mette il codice in ogni percorso, /en/ o /it/, e i link del selettore negozio possono portare anche un parametro ___store. La soluzione: mappare gli URL di ogni store view sulla versione nella stessa lingua del nuovo sito, mai sulla lingua predefinita.
  • Vecchie chiavi URL che Magento continuava a reindirizzare. Come si vede: link da blog e vecchie newsletter si rompono mesi dopo. Perché: le righe di url_rewrite con redirect_type 301 tenevano in vita anni di prodotti rinominati, e spariscono con il vecchio server. La soluzione: puntare ognuna direttamente al nuovo indirizzo finale, così resta un solo salto.
  • Navigazione a livelli. Come si vede: Search Console mostra migliaia di URL strani come ?color=49&size=166 che danno 404 o portano alla home page. Perché: i filtri di Magento sono parametri sulle pagine di categoria, e Google li scansiona. La soluzione: non mappateli uno per uno. Mandate gli URL filtrati alla loro categoria e trasformate in pagine vere solo le poche combinazioni che portavano visite. La guida di Google sulla navigazione a faccette spiega perché gli URL dei filtri sprecano scansione.
  • Indirizzi delle immagini. Come si vede: il traffico da Google Immagini cala e non torna. Perché: le foto passano da /media/catalog/product/ allo spazio della nuova piattaforma, con altri nomi. La soluzione: la guida di Google ai traslochi di siti dice di includere le immagini nella mappa degli URL; fate redirect almeno delle immagini dei prodotti più venduti e mantenete testo alternativo e nomi file descrittivi.

Dove finiscono le posizioni: segnali che si perdono

  • Redirect mancanti, o tutto verso la home page. Come si vede: una fila continua di 404, o la home page che all'improvviso riceve traffico per ricerche di prodotti. Perché: una regola generica ha mandato gli URL senza corrispondenza alla home page. Google dice di non puntare molti vecchi URL verso una pagina non correlata, e dice che questi redirect possono essere trattati come soft 404. La soluzione: una destinazione pertinente per ogni URL, e un vero 404 o 410 quando niente va bene.
  • Catene di redirect. Come si vede: i vecchi link funzionano ma posizionano peggio e vengono scansionati lentamente. Perché: una vecchia chiave puntava a una più recente, che ora punta alla nuova piattaforma. La soluzione: appiattire la catena, ogni vecchio indirizzo direttamente a quello finale. Google consiglia di andare dritti all'indirizzo finale e, se non si può, di non superare tre salti; puntate a uno.
  • Temporaneo invece di permanente. Perché: alcuni strumenti e impostazioni usano 302 di default. Un redirect temporaneo tiene il vecchio URL nei risultati; quelli permanenti (301 o 308) passano la posizione al nuovo. Usate redirect lato server; quelli in JavaScript sono l'ultima risorsa.
  • Meta title e meta description. Come si vede: le pagine sono indicizzate ma il tasso di clic scende. Perché: molti importatori portano nome e descrizione ma non meta_title e meta_description di Magento, quindi il nuovo titolo è solo il nome del prodotto. La soluzione: esportare entrambi i campi e copiarli, soprattutto per le pagine che ricevono clic.
  • Canonical e hreflang tra store view. Come si vede: una lingua supera un'altra nel paese sbagliato, o le pagine risultano duplicate. Perché: canonical e tag hreflang spesso arrivano da un'estensione o dal tema Magento, e sul nuovo sito semplicemente non esistono. La soluzione: dare a ogni nuova pagina un canonical verso sé stessa e ricostruire le alternative di lingua tra le versioni.
  • robots.txt e noindex rimasti dall'ambiente di prova. Come si vede: le pagine escono dall'indice pochi giorni dopo il lancio. Perché: il sito di prova era nascosto, e l'impostazione è andata in produzione con lui. La soluzione: controllare robots.txt e il meta tag robots sul dominio reale nella prima ora.
  • La sitemap. Perché: l'URL della vecchia sitemap dà 404, e la nuova non è mai stata inviata. La soluzione: inviare la nuova sitemap in Search Console e, come suggerisce Google, tenere per un po' una sitemap con i vecchi URL, così i redirect vengono scoperti prima.

La checklist, passo per passo

  1. 1

    Scansionare il sito Magento in produzione ed esportarne gli URL

    Fate passare un crawler su tutto il negozio e salvate ogni URL con stato, titolo, meta description, canonical e H1. Poi esportate la tabella url_rewrite (request_path, target_path, redirect_type, store_id, entity_type, entity_id). Insieme sono il vostro inventario.

  2. 2

    Aggiungere ciò che Google e altri siti conoscono

    Esportate le pagine principali dal rapporto Prestazioni di Search Console degli ultimi 16 mesi, le pagine con più link e le pagine di ingresso degli analytics. Vecchie sitemap, log del server e la Wayback Machine trovano indirizzi che nessuno ricorda più.

  3. 3

    Mappare ogni vecchio URL su un nuovo URL

    Un foglio di calcolo con due colonne: vecchio e nuovo. Prodotti per SKU o ID, categorie per ID, pagine CMS a mano. I prodotti ritirati vanno alla categoria o al sostituto più vicino, non alla home page. Segnate gli URL con traffico o link, per testarli per primi.

  4. 4

    Portare i segnali di ogni pagina

    Meta title, meta description, intestazioni, descrizioni delle categorie, testo alternativo delle immagini e dati strutturati. Tenete nomi e descrizioni delle categorie vicini a quelli vecchi nei primi mesi; un trasloco non è il momento di riscrivere tutto.

  5. 5

    Impostare i 301, un salto ciascuno

    Redirect permanenti lato server, caricati dalla mappa, ognuno diretto all'indirizzo finale. Decidete dove vivranno (lo strumento di redirect della nuova piattaforma, la CDN o un web server davanti) prima del lancio, non dopo.

  6. 6

    Testare in prova, e di nuovo in produzione

    Date la lista dei vecchi URL a un crawler in modalità elenco e verificate che ognuno restituisca un solo 301 verso una pagina 200. Ripetete sul dominio reale nell'ora del passaggio.

  7. 7

    Aprire le porte

    Togliete ogni noindex e le regole robots.txt dell'ambiente di prova, inviate la nuova sitemap, tenete i vecchi URL in una seconda sitemap e controllate qualche pagina chiave con il Controllo URL di Search Console.

  8. 8

    Osservare, correggere e tenere i redirect

    Controllate i 404 in Search Console ogni giorno per le prime due settimane e aggiungete redirect man mano che compaiono. Teneteli il più a lungo possibile: Google dice in genere almeno un anno, e per sempre è meglio per chi segue vecchi link.

Dopo il lancio: cosa è normale e cosa no

La guida di Google ai traslochi di siti avverte che le posizioni possono oscillare mentre il sito viene riscansionato, e che per un sito di medie dimensioni possono servire alcune settimane o più perché la maggior parte delle pagine passi; i siti più grandi richiedono più tempo. Un calo nelle prime settimane non è un verdetto.

Cosa vedeteNormale quandoPreoccupante quando
Impressioni e clic in caloIl calo è lieve e rientra in poche settimaneÈ ancora forte dopo due o tre mesi
Vecchi URL ancora nei risultatiFanno redirect e spariscono nel giro di settimaneDanno 404 o portano alla home page
Molti avvisi di redirect sulla vecchia sitemapSempre: quella sitemap elenca apposta URL reindirizzatiLa nuova sitemap mostra errori o poche pagine indicizzate
Nuovi 404 in Search ConsoleQualche vecchio URL dimenticatoCentinaia di URL di prodotti o categorie
Traffico in calo in un paese o una linguaIn pratica maiDal primo giorno, il che di solito indica URL delle store view o hreflang

Un calo ancora presente dopo due o tre mesi ha quasi sempre una causa tecnica che vale la pena cercare: confrontate la lista dei vecchi URL con ciò che restituisce il nuovo sito, pagina per pagina.

Se passate a WhizzyCommerce

L'importatore Magento 2 tiene la chiave URL di ogni prodotto e categoria come handle, e le pagine stanno alla radice, quindi /cappotto-lana.html diventa /cappotto-lana. Così la mappa è quasi meccanica: togliere il suffisso e il percorso di categoria. Le immagini vengono copiate nello spazio del vostro negozio, quindi i loro indirizzi cambiano. L'importatore legge la store view predefinita, e una seconda store view diventa un secondo negozio.

I redirect passano: ogni vecchio indirizzo .html di un prodotto o di una categoria, a qualsiasi profondità, porta da solo al nuovo con un 301, e l'importatore porta i redirect di Magento, compresi quelli personalizzati, ognuno dritto alla pagina finale. Cosa non fa, senza giri di parole: i meta title di prodotti e categorie non vengono importati (ogni prodotto e collezione ha il proprio titolo e descrizione SEO da compilare), e i codici del negozio negli URL (/en/...) e gli indirizzi dei filtri della navigazione a livelli non vengono mappati da soli; aggiungeteli in Impostazioni, Motori di ricerca, Reindirizzamenti, a mano o da un CSV. La sitemap del negozio elenca tutti i prodotti, le categorie e le pagine, con le versioni in ogni lingua. Per i primi 100 negozi che lasciano Magento, una persona del nostro team fa il trasloco e mantiene funzionanti i vostri URL: chiedetelo su passare da Magento. Se cambiate perché la vostra versione sta perdendo il supporto, partite dalla fine del supporto di Magento 2.

Domande

Perderò posizioni su Google lasciando Magento?

Un po' di movimento nelle prime settimane è normale mentre Google riscansiona. Le perdite durature vengono da URL che danno 404, che fanno redirect verso la home page o a catena, e da titoli e descrizioni persi. Una mappa completa degli URL con 301 a un solo salto evita quasi tutto.

Quanto ci mette il traffico a riprendersi dopo una migrazione?

Google dice che un sito di medie dimensioni può impiegare alcune settimane o più per il passaggio, e i siti grandi di più. Se il traffico è ancora nettamente più basso dopo due o tre mesi, cercate una causa tecnica invece di aspettare.

Devo tenere il .html alla fine degli URL?

Solo se la nuova piattaforma vi permette di tenere URL identici senza espedienti. Altrimenti toglietelo e reindirizzate ogni vecchio indirizzo .html al nuovo con un 301. I redirect puliti non fanno danni; sono quelli rotti a costare posizioni.

Devo reindirizzare gli URL dei filtri della navigazione a livelli?

Non uno per uno. Mandate gli URL filtrati alla pagina della categoria e trasformate in pagine vere solo le poche combinazioni di filtri che portavano visite dalla ricerca.

Per quanto tempo devo tenere i redirect?

Google dice il più a lungo possibile, in genere almeno un anno. I link da altri siti e da vecchie email continuano ad arrivare per anni, quindi tenerli per sempre è la scelta più sicura.

Da leggere dopo