Come Migrare un Sito Multilingua Senza Perdere Posizionamento SEO

Il traffico di solito non scompare perché Google si è confuso. Scompare perché una migrazione multilingua è stata gestita come un semplice redesign, e qualcuno si è dimenticato che ogni versione linguistica ha i propri URL, segnali, canonical e percorsi di link interni. Se vuoi migrare un sito multilingua senza perdere il posizionamento SEO, hai bisogno di un piano che tratti la localizzazione come architettura, non come decorazione.

In WordPress la situazione si complica rapidamente. Un plugin archivia gli URL tradotti in un modo, un altro riscrive gli slug in modo diverso, e un terzo inietta i tag hreflang con una logica tutta sua. Poi qualcuno cambia la struttura del dominio, manda online il nuovo sito il venerdì, e passa il mese successivo a chiedersi perché le pagine prodotto in francese siano sparite dai risultati. Non c'è niente di misterioso in tutto questo. Nella maggior parte dei casi è semplicemente evitabile.

Perché le migrazioni multilingua rompono così facilmente il SEO

Una migrazione in una singola lingua è già delicata. Aggiungi più lingue e ti ritrovi a migrare gruppi di pagine equivalenti, URL alternativi, targeting regionale, metadati tradotti, link interni e spesso una grande quantità di contenuto dall'aspetto duplicato che i motori di ricerca comprendono solo grazie ai segnali che lo circondano.

L'errore più grande è credere che i posizionamenti dipendano esclusivamente dal contenuto della pagina. Non è così. Dipendono dall'insieme di tutto il sistema: struttura degli URL, indicizzabilità, canonical, hreflang, redirect, coerenza della sitemap e dalla capacità di Google di capire ancora quale pagina in inglese corrisponde a quale versione in spagnolo o tedesco.

Se anche uno solo di questi elementi si rompe su larga scala, il danno si propaga. Un canonical sbagliato può azzerare un'intera cartella linguistica. I redirect mancanti possono bruciare vecchi link con autorità. Un hreflang errato può indirizzare la pagina sbagliata al mercato sbagliato. E se gli slug tradotti cambiano senza una mappa di redirect pulita, stai praticamente chiedendo a Google di ricominciare da zero.

Prima di migrare un sito multilingua senza perdere il SEO

Non iniziare dal design. Inizia dall'inventario.

Esegui una scansione del sito attuale ed esporta ogni URL indicizzabile per ogni lingua. Includi titoli, meta description, canonical, codici di stato, riferimenti hreflang, voci della sitemap XML e link interni se il tuo crawler lo supporta. Se stai effettuando la migrazione da un livello di traduzione in hosting o da una piattaforma di traduzione SaaS, documenta il formato esatto degli URL attualmente in uso. Questo significa sottodirectory, sottodomini, parametri, slug tradotti e URL dei media, se anche questi sono localizzati.

Poi mappa ogni vecchio URL verso una nuova destinazione. Non solo i template. Ogni URL. Pagine di categoria, archivi paginati, pagine prodotto, articoli del blog, homepage nelle varie lingue, pagine account e qualsiasi landing page di alto valore costruita per la ricerca a pagamento o organica. Se una pagina viene rimossa, decidi se deve reindirizzare a un equivalente simile, restituire un 410 o semplicemente non esistere più. Improvvisare in seguito è il modo in cui si creano catene di redirect e traffico orfano.

Questo è anche il momento in cui decidi cosa non cambiare. Se gli URL multilingua attuali si posizionano già bene, tienili. Una migrazione non è il momento di essere creativi con slug più puliti o una nuova architettura linguistica, a meno che non ci sia un reale vantaggio. La stabilità vince.

Scegli la giusta strategia URL e mantienila

Per il SEO multilingua esistono solo poche opzioni sensate: sottodirectory, sottodomini o domini per paese. In WordPress le sottodirectory sono spesso le più facili da gestire e preservano bene l'autorità, ma questo non le rende automaticamente giuste per ogni configurazione.

Ciò che conta di più durante una migrazione è la coerenza. Se il vecchio sito usa /es/ e /de/, non passare alla leggera a es.example.com solo perché a qualcuno sembra più enterprise. Questo crea un secondo problema di migrazione sopra il primo. Stesso contenuto, nuova struttura, nuovi segnali, più possibilità di sbagliare.

Ci sono casi in cui un cambio di URL è giustificato. Forse la vecchia piattaforma usava brutte query string, o forse le pagine tradotte venivano proxate in un modo che non ti ha mai dato vera ownership. Va bene. Sii però onesto riguardo al costo. Più grande è il cambiamento strutturale, più precisi devono essere la mappatura dei redirect e il controllo qualità post-lancio.

I redirect non sono un'attività di pulizia

I redirect sono la migrazione.

Se cambi anche un solo schema di URL multilingua, costruisci un foglio di redirect che abbini ogni vecchio URL a una destinazione finale. Usa redirect 301. Evita le catene di redirect. Evita i disallineamenti linguistici, a meno che non ci siano alternative. Una vecchia pagina prodotto in spagnolo non dovrebbe scaricare gli utenti sulla homepage in inglese perché il team di migrazione ha finito il tempo.

Questo è importante per gli utenti e per i crawler, ma anche per i ricavi. Gli store WooCommerce con pagine prodotto multilingua spesso hanno backlink che puntano a SKU localizzati, pagine di categoria e contenuti del blog. Perdere quei percorsi non significa solo perdere posizionamenti. Significa sprecare link equity già acquisita attraverso contenuti, PR e tempo.

Se stai abbandonando una piattaforma di traduzione in abbonamento, assicurati di poter preservare gli URL esatti che gli utenti già visitano lato SEO. È qui che conta la proprietà. Alcuni strumenti di migrazione, incluse le configurazioni basate su TrueLang, sono progettati specificamente per trasferire gli URL multilingua e mantenere intatta la struttura SEO invece di costringerti a ripartire da zero.

Hreflang, canonical e indicizzabilità richiedono un audit rigoroso

È qui che molte migrazioni falliscono silenziosamente.

L'hreflang deve puntare a equivalenti reali e indicizzabili in tutte le lingue. Ogni pagina del gruppo deve riferirsi correttamente alle altre, inclusa se stessa. I codici di lingua e regione devono essere validi. Se usi x-default, usalo consapevolmente, non perché un plugin lo ha aggiunto di default.

I canonical richiedono ancora più attenzione. Il canonical su una pagina tradotta dovrebbe di norma puntare a se stesso, non alla versione nella lingua originale. Se la tua pagina in spagnolo punta come canonical alla versione inglese, stai dicendo a Google che la pagina spagnola è la copia da ignorare. Questo errore è comune, devastante e completamente evitabile.

Poi controlla l'indicizzabilità a livello di template. Tag noindex, cartelle bloccate, residui di staging, richieste di password accidentali e problemi di rendering JavaScript possono colpire una sezione linguistica senza toccare le altre. Non puoi dare per scontato che se la versione inglese è scansionabile anche quella italiana stia bene.

La parità dei contenuti conta più di quanto si pensi

Una migrazione multilingua non è solo idraulica tecnica. I motori di ricerca confrontano gli equivalenti. Se la vecchia pagina in tedesco aveva tag title ottimizzati, contenuto del corpo, FAQ e link interni, ma quella nuova è tradotta automaticamente con formattazione ridotta e metadati mancanti, il posizionamento può calare anche se i redirect sono perfetti.

Questo non significa che ogni parola debba corrispondere alla versione precedente. A volte un aggiornamento aiuta. Ma l'intento, la struttura e il targeting on-page devono essere mantenuti. Conserva i campi SEO tradotti dove performano bene. Conserva il testo alternativo delle immagini dove rilevante. Conserva i dati strutturati se esistono in ogni lingua. Conserva i link interni all'interno dei contenuti tradotti, soprattutto se puntano a pagine di destinazione localizzate.

Questo è uno dei motivi per cui molti proprietari di siti abbandonano piattaforme gonfie. Si rendono conto di non possedere davvero una configurazione multilingua pulita e modificabile. L'hanno affittata. E poi la migrazione si trasforma in un lavoro di archeologia.

Il giorno del lancio è per la verifica, non per la speranza

Quando il nuovo sito va online, controlla subito gli URL live. Non domani. Non dopo il weekend.

Testa la lista dei redirect confrontandola con le risposte reali. Esegui la scansione del nuovo sito per lingua. Ispeziona l'output hreflang. Controlla i canonical. Valida le sitemap XML. Assicurati che i vecchi URL vengano risolti correttamente e che le nuove pagine restituiscano codici di stato 200. Esegui controlli a campione sui link interni in menu, selettori di lingua, breadcrumb, prodotti, blog e flussi transazionali come carrello e checkout.

Poi apri Search Console e monitora i cambiamenti di copertura, le anomalie di scansione e gli errori hreflang. Confronta il numero di URL indicizzati nelle varie sezioni linguistiche. Se un mercato inizia a scendere in modo sproporzionato, indaga rapidamente. Nel SEO multilingua, i piccoli bug di implementazione raramente restano piccoli.

Aspettati anche qualche fluttuazione. Non ogni calo significa un fallimento. Se hai cambiato architettura, contenuto, hosting e strumenti di traduzione tutti insieme, Google ha bisogno di tempo per rielaborare i segnali. L'obiettivo non è zero movimento. L'obiettivo è un movimento controllato con una spiegazione chiara.

Cosa evitare se vuoi che i posizionamenti sopravvivano

Non migrare, riprogettare e riscrivere ogni pagina allo stesso tempo, a meno che tu non voglia fare debug su tre variabili contemporaneamente.

Non lasciare che un plugin generi automaticamente slug tradotti in modo diverso dagli URL già indicizzati, a meno che tu non abbia un piano di redirect per ognuno di essi.

Non puntare tutte le pagine localizzate rimosse verso un'unica homepage generica nella lingua. È una soluzione pigra, e i motori di ricerca lo sanno.

Non fidarti del fatto che l'hreflang sia corretto solo perché un plugin dichiara di supportare il SEO multilingua. Il supporto non è la stessa cosa dell'output corretto sul tuo sito.

E non trattare la proprietà come una questione secondaria. Se le tue pagine tradotte, i metadati e gli URL vivono all'interno del sistema in affitto di qualcun altro, il rischio di migrazione aumenta. Sempre.

La mossa intelligente è noiosa: tieni ciò che già funziona, documenta ogni URL, mappa ogni redirect, verifica ogni segnale e rifiutati di improvvisare dopo il lancio. È così che si migra senza drammi. Ed è anche il modo per smettere di pagare per il lock-in altrui e tenere i posizionamenti che ti sei guadagnato.