Migrare una testata multilingue richiede di conservare il legame tra contenuti, lingue e indirizzi. Il nuovo sito deve permettere ai lettori di ritrovare gli articoli e alla redazione di continuare il lavoro. Per questo partirei da un inventario verificabile, prima di scegliere come importare i dati.
Nel lavoro su piattaforme editoriali, il passaggio a una nuova infrastruttura non coincide necessariamente con il cambio di CMS o dei permalink. Se le URL possono restare identiche, le conserverei. Cambiarle aggiunge una migrazione SEO da gestire e deve avere una motivazione concreta.
Inventariare anche ciò che non è nel corpo dell’articolo
Per ogni contenuto raccoglierei identificatore originale, URL, lingua, titolo, autore, stato, date, tassonomie e media. Aggiungerei metadati SEO e relazioni tra traduzioni, verificando come il plugin o il CMS le memorizza realmente.
Controllerei un campione con accenti, diacritici, embed e articoli aggiornati più volte. Un testo apparentemente leggibile può avere codifica errata o URL interni che puntano ancora all’ambiente precedente.
L’inventario delle URL deve includere anche archivi, paginazioni e media importanti. Userei sitemap e dati disponibili dal sito, senza assumere che una sola fonte descriva tutto ciò che utenti e motori possono raggiungere.
Lingua e pubblico geografico sono informazioni distinte
Una testata in rumeno rivolta a lettori in Italia non diventa italiana nella lingua. Per le versioni equivalenti, Google documenta l’uso di hreflang con codici di lingua e, quando appropriato, regione.
Proverei corrispondenze reciproche e URL assolute, comprese quelle della pagina stessa. Due articoli sullo stesso tema non sono automaticamente versioni linguistiche equivalenti. Le relazioni devono rappresentare il contenuto, non soltanto l’appartenenza a due edizioni.
Canonical, hreflang e link visibili devono essere coerenti. Il selettore della lingua dovrebbe portare alla versione pertinente quando esiste, senza nascondere le altre edizioni attraverso reindirizzamenti automatici difficili da controllare.
Rendere l’importazione ripetibile
Userei una chiave stabile che colleghi sorgente e destinazione, includendo sito e lingua se l’identificatore originale non è globalmente unico. Ripetere l’import deve aggiornare ciò che è cambiato senza creare copie aggiuntive.
Distinguerei una prima prova, il trasferimento principale e il recupero delle modifiche intervenute nel frattempo. Conteggi per stato e lingua, controlli sui media e confronto di campioni aiutano a trovare omissioni che il solo messaggio “import completato” non mostra.
Se il target è WordPress, le Application Passwords consentono autenticazione REST su HTTPS. I permessi devono essere quelli necessari all’operazione. Pubblicazioni, email e indicizzazioni attivate dall’import vanno previste prima di elaborare migliaia di record.
Mappare le URL che cambiano
Per gli indirizzi modificati preparerei una mappa verso il contenuto equivalente e redirect permanenti lato server. Eviterei catene e redirect indiscriminati alla home. Quando un contenuto è rimosso senza equivalente, la risposta deve rappresentare quella condizione.
La guida Google alle migrazioni con cambio di URL indica le verifiche per redirect, link interni e sitemap. Conservare una mappa permette anche di controllare automaticamente ciascun vecchio indirizzo dopo il passaggio.
In nginx una map con corrispondenze esatte può essere adatta a un elenco ampio. Non è la stessa cosa di migliaia di espressioni regolari valutate in sequenza. La scelta va provata con la configurazione reale, senza attribuire a tutte le regole un costo nullo.
Preparare il momento del passaggio
Concorderei quando interrompere o riconciliare le scritture, chi approva il controllo editoriale e quali condizioni fanno scattare il ritorno. Il rollback deve considerare anche articoli o commenti creati dopo il cambio: tornare al vecchio server può perdere quelle modifiche se non esiste una procedura.
Dopo il cutover verificherei pagine anonime, accesso redazionale, pubblicazione di prova, cache e attività programmate. Controllerei l’assenza del noindex usato in staging e la correttezza delle URL nella sitemap.
Le prestazioni richiedono una baseline confrontabile; i dati sul campo possono includere ancora il periodo precedente alla migrazione. Nel rapporto finale terrei separati trasferimento dei contenuti, verifiche SEO tecniche e risultati osservati nel tempo. Un crawl senza errori è una buona evidenza tecnica, non una garanzia sul posizionamento futuro.