Migrare a WordPress da un’altra piattaforma: cosa si porta via, cosa va rifatto e come tenere gli indirizzi

Migrare a WordPress da un’altra piattaforma vuol dire spostare tre cose che si comportano in modo diverso. I contenuti (testi, immagini, date, categorie) si esportano, ogni piattaforma a modo suo e quasi mai per intero. L’aspetto e le funzioni del sito vecchio, dal modello grafico ai moduli di contatto, non si esportano e vanno rifatti. Gli indirizzi delle pagine si possono tenere identici o reindirizzare uno per uno, e da loro dipende se il sito nuovo eredita le visite di quello vecchio.

Questa guida parte da quello che le piattaforme lasciano portare via (Webflow, Wix, Squarespace, Blogger, WordPress.com e gli altri CMS), poi passa a quello che WordPress sa leggere, alle immagini, agli indirizzi e a quello che va ricostruito. Vale per chi arriva su un WordPress installato sul proprio hosting. Se il sito è già WordPress e cambia soltanto server o dominio, il lavoro è diverso, e la tabella qui sotto rimanda alla guida giusta.

Una nota sulle fonti. Quello che segue l’ho verificato il 29 settembre 2026 sulla documentazione ufficiale di Webflow, Wix, Squarespace, Blogger, WordPress.com e Google, e sul codice di WordPress 7.1. Lo script d’importazione, le importazioni e i redirect li ho eseguiti in un WordPress 7.1.2 vero (WordPress Playground, PHP 8.5), con immagini prese dal CDN di Webflow. Le piattaforme cambiano spesso quello che lasciano esportare, e per questo accanto ai limiti trovi la data della pagina che li descrive.

Una versione precedente di questo articolo conteneva due indicazioni sbagliate, corrette il 2 ottobre 2026. Diceva che l’importatore di Blogger porta articoli, commenti, categorie e immagini: con il backup che Blogger fornisce oggi da Google Takeout non importa niente, e con il vecchio file .xml scarica le immagini dei soli 20 articoli più recenti. Lo script d’importazione del CSV, inoltre, passava il testo a WordPress senza wp_slash(), e le barre rovesciate, come quelle di un percorso di Windows o di una formula, andavano perse.

Quale migrazione stai facendo

La parola migrazione copre lavori molto diversi fra loro. Prima di aprire qualsiasi pannello conviene capire quale stai facendo, perché da questo dipendono cosa si sposta, cosa si ricostruisce e quale procedura seguire.

Il caso di questa pagina è il primo, ed è il meno automatico.

Fra due installazioni WordPress si copia tutto, database compreso. Fra un’altra piattaforma e WordPress passa solo quello che la piattaforma lascia uscire, nel formato che sceglie lei.

Cosa si sposta e cosa no: contenuti, aspetto, funzioni

I contenuti sono dati. Titolo, testo, data, autore, categorie e immagini sono l’unica parte che un’esportazione può contenere, e quasi tutte le piattaforme la consegnano incompleta. La schermata di importazione di WordPress, in Strumenti, Importa, lo dice con precisione: “Se hai articoli o commenti su un’altra piattaforma, WordPress può importarli in questo sito”. Parla di articoli e commenti, e di nient’altro.

L’aspetto è il modello grafico con i suoi stili e le sue animazioni. Ogni piattaforma lo costruisce con un sistema proprio, e nessuna lo esporta in una forma che WordPress sappia usare. Anche l’esportazione del codice di Webflow, che consegna l’HTML, il CSS e il JavaScript delle pagine, produce un sito statico da tenere come riferimento, e il tema WordPress va scritto o scelto comunque.

Le funzioni sono i servizi che la piattaforma fa girare sui propri server, come i moduli con le loro notifiche, il carrello, le aree riservate e la ricerca interna. Su WordPress si rifanno con un plugin o con del codice. La documentazione di Webflow lo mette per iscritto per il codice esportato, dove moduli, ricerca e pagine protette da password smettono di funzionare. Per le aree riservate la questione non si pone più, perché Webflow ha spento gli User Accounts su tutti i siti il 29 gennaio 2026.

C’è poi un’indicazione di Google che cambia l’ordine dei lavori. Nella guida ai trasferimenti di sito, aggiornata il 20 agosto 2026, Google consiglia di cambiare una cosa alla volta, con il dominio, il sistema di gestione dei contenuti e il layout in tre momenti diversi. In un cambio di piattaforma il sistema cambia per definizione e il layout quasi sempre. Le due cose che si possono tenere ferme, il dominio e gli indirizzi delle pagine, vanno tenute ferme, con lo stesso principio con cui si cambia la struttura di un sito WordPress già online.

Cosa esporta la piattaforma da cui parti

Il lavoro lo decide l’esportazione.

Una piattaforma che consegna un file nel formato di WordPress porta via quasi tutto il testo in un passaggio. Una che consegna un foglio di calcolo chiede di abbinare le colonne ai campi di WordPress. Una che non esporta niente lascia il copia e incolla. La tabella riassume i casi più comuni, secondo le documentazioni ufficiali al 29 settembre 2026.

Da Webflow a WordPress

Webflow esporta il CMS una Collection alla volta, in CSV. Si apre il pannello CMS, si sceglie la Collection e si usa Export; il file comprende anche le voci archiviate, ma solo nella lingua che stai visualizzando. Dentro, il testo ricco arriva come HTML, i campi di riferimento come testo, le immagini e i file come indirizzi ospitati da Webflow (documentazione sull’importazione e l’esportazione del CMS, aggiornata il 18 agosto 2026). Se le categorie del blog sono una Collection a parte, collegata agli articoli con un campo di riferimento, nel file diventano testo, con più voci separate da virgole, e lo script più avanti ne fa categorie di WordPress.

Quelle immagini restano sul dominio della piattaforma, cdn.prod.website-files.com, e la stessa pagina avverte che se il sito Webflow viene cancellato i loro indirizzi smettono di funzionare, comprese le immagini dentro il testo. Sul CDN di Webflow si trovano anche file AVIF e SVG, che WordPress tratta diversamente dalle JPEG, come si vede più avanti.

Le pagine statiche, come la home o la pagina dei servizi, nel CSV non ci sono. Il loro testo esce solo con l’esportazione del codice, che Webflow concede sui piani Workspace e non sui piani Site, e che lascia fuori CMS, negozio, contenuti nelle lingue secondarie, protezione con password, ricerca e invio dei moduli (pagina aggiornata il 31 ottobre 2025). È un archivio e un riferimento per il tema; in WordPress non si importa.

Tre esportazioni sono facili da dimenticare. Gli invii dei moduli si scaricano in CSV dalle impostazioni del sito, alla voce Forms, con gli eventuali allegati come indirizzi da salvare a parte. I redirect 301 impostati negli anni si esportano in CSV dalla voce Publishing, e vanno riportati in WordPress. Il terzo non è un file. Quando il piano Site viene disdetto, Webflow scollega da solo i domini personalizzati, quindi la disdetta si fa per ultima, a trasloco finito.

Gli indirizzi di Webflow hanno una forma fissa. Le pagine di una Collection stanno in una cartella che porta l’indirizzo della Collection, per esempio /post/titolo, e le pagine statiche stanno alla radice o nelle cartelle in cui le hai raccolte. Nessuna ha la barra finale, e sul sito di Webflow gli indirizzi con la barra rispondono con un 301 verso la versione senza. È il dato da cui partire per scegliere i permalink.

Esiste anche un plugin ufficiale di Webflow per WordPress, Webflow Pages, ma non migra niente. Mostra dentro WordPress pagine che restano disegnate su Webflow, e richiede un progetto Webflow attivo. Al 29 settembre 2026 ha oltre 2.000 installazioni, l’ultimo aggiornamento risale al 13 novembre 2024 e la sua scheda avverte che non è stato provato con le ultime tre versioni maggiori di WordPress.

Da Wix a WordPress

Wix è la piattaforma da cui si porta via meno.

Il sito non si può esportare né ospitare altrove, perché funziona solo sui server di Wix, e nemmeno gli articoli del blog, che per Wix sono ancora una richiesta aperta degli utenti. Resta il feed RSS del blog, che però mostra al massimo gli ultimi 20 articoli.

L’unico importatore ufficiale per Wix sta su WordPress.com, e non nel WordPress che si installa sul proprio hosting. La guida di WordPress.com all’importazione da Wix, rivista l’11 agosto 2026, elenca pagine statiche, immagini, titolo del sito e menu. Gli articoli del blog restano fuori, e per quelli la guida suggerisce l’importatore RSS, con il limite dei venti articoli più recenti. Il design resta fuori, e il tema si sceglie su WordPress.com.

Per arrivare su un WordPress tuo la strada passa quindi da un sito WordPress.com. Si importa lì, si esporta il contenuto dal suo Strumenti, Esporta, e lo si importa sul sito definitivo con il WordPress Importer, tenendo pubblico il sito WordPress.com finché le immagini non sono state copiate. Non l’ho provata dall’inizio alla fine; ogni passaggio però è documentato da WordPress.com. Gli articoli più vecchi dei venti del feed, in ogni caso, si portano a mano.

Da Squarespace a WordPress

Squarespace esporta un file XML nel formato di WordPress, dal pannello di importazione ed esportazione con l’icona di WordPress, e solo da un sito attivo e pubblicato (da un sito in prova non si può). Secondo la sua guida all’esportazione, aggiornata il 12 febbraio 2026, il file porta le pagine di layout, un solo blog con i suoi articoli e fino a mille commenti per articolo, i blocchi di testo e di immagine e le gallerie. Lascia fuori le pagine negozio e gli altri tipi di pagina, i blog oltre il primo, i blocchi video, audio e prodotto, le bozze, gli stili e il CSS personalizzato.

Sulle immagini la stessa guida è esplicita. Importando il file con il WordPress Importer su un WordPress installato in proprio, le immagini possono restare collegamenti al sito vecchio, e sparire quando lo si disattiva. Le prove fatte per questa guida spiegano il perché, e le trovi nella sezione sulle immagini.

Per gli indirizzi, la guida di WordPress.com all’importazione da Squarespace suggerisce una struttura dei permalink personalizzata con /blog/ davanti al nome dell’articolo, che è la forma degli articoli su Squarespace. È il metodo della sezione sugli indirizzi, applicato a un caso concreto.

Da Blogger, da WordPress.com e dalle piattaforme di blogging

Blogger fa scaricare il backup del blog da Google Takeout (guida di Blogger), in un archivio con un file feed.atom che contiene articoli, pagine e commenti. WordPress ha un importatore dedicato fra quelli di Strumenti, Importa, ma legge solo il vecchio formato .xml di Blogger: con il feed.atom di oggi non importa niente, e sulla sua scheda compare l’avviso che non è stato provato con le ultime tre versioni maggiori. Come importare il backup di oggi e tenere gli indirizzi lo spiego nella guida per passare da Blogger a WordPress.

WordPress.com esporta dal suo Strumenti, Esporta un file XML con articoli, pagine, commenti, categorie e tag. Le immagini non ci sono, ci sono i loro indirizzi, e il sito nuovo le va a prendere da quello vecchio durante l’importazione. Per questo la guida di WordPress.com all’esportazione chiede di tenere pubblico il sito vecchio finché il numero di elementi nella Libreria media non coincide sui due siti. Tema e plugin restano fuori, salvo il backup completo dei piani Business e Commerce, e ne ho scritto parlando di cosa si porta via da WordPress.com.

Tumblr, Movable Type e TypePad e LiveJournal hanno un importatore nell’elenco di WordPress; quello di LiveJournal non riceve aggiornamenti dal 16 ottobre 2014. Per Medium e Substack gli importatori ufficiali stanno su WordPress.com, e vale la stessa strada descritta per Wix.

Da Joomla, Drupal e dagli altri CMS

Da un CMS installato su un server, come Joomla o Drupal, i contenuti stanno in un database, e l’esportazione si fa leggendolo. La documentazione ufficiale di WordPress sull’importazione elenca 25 fra sistemi e formati di partenza, e per Joomla e Drupal rimanda a plugin di terze parti come FG Joomla to WordPress e FG Drupal to WordPress, aggiornati fra agosto e settembre 2026 e dichiarati compatibili con WordPress 7.1. Prima di sceglierne uno conviene leggere nella scheda quali contenuti importa e da quali versioni del CMS di partenza. Wix, Squarespace e Webflow, in quell’elenco, non compaiono.

Cosa sa leggere WordPress

WordPress va installato prima, sul server che ospiterà il sito, e i passi sono quelli per installare e configurare WordPress sul nuovo hosting. L’importazione viene dopo, da Strumenti, Importa, che elenca sette importatori: Blogger, Convertitore di categorie e tag, LiveJournal, Movable Type e TypePad, RSS, Tumblr e WordPress. Ciascuno è un plugin, si installa con Installa ora e si lancia con Avvia l’importazione.

Il formato che WordPress legge meglio è il suo, l’XML di esportazione chiamato WXR, lo stesso che producono WordPress.com e Squarespace. Il WordPress Importer (versione 0.9.6, aggiornata il 27 agosto 2026) ne porta dentro articoli, pagine, commenti, campi personalizzati, categorie, tag e autori. Le immagini dichiarate nel file le scarica solo se spunti Scarica e importa gli allegati, una casella che parte spenta. La casella sotto, già spuntata, cambia i link rivolti al sito precedente con l’indirizzo del sito nuovo, funziona da WordPress 6.7 in poi e serve quando cambia anche il dominio. Sulla scheda del WordPress Importer compare lo stesso avviso delle ultime tre versioni maggiori. Viene dal campo del readme che dichiara la compatibilità, fermo alla 6.8, e non dall’attività del progetto, aggiornato a fine agosto. Per giudicare un importatore, come qualsiasi plugin, contano la data dell’ultimo aggiornamento e il changelog più di quell’avviso.

Un importatore per i file CSV, invece, WordPress non ce l’ha.

Fra i plugin gratuiti, WP All Import legge CSV e XML, ma scarica le immagini nella Libreria media solo nella versione Pro, insieme ai campi personalizzati. Really Simple CSV Importer prende da un indirizzo l’immagine in evidenza, e per le immagini dentro il testo non ha un’opzione. Per un CSV di Webflow, dove le immagini stanno nel testo come HTML, fa prima uno script con WP-CLI.

Lo script qui sotto crea un articolo per ogni riga, con lo stesso slug e la stessa data, e mette in bozza le voci archiviate. Poi scarica nella Libreria media l’immagine principale e quelle nel testo, e ne riscrive gli indirizzi. Si lancia con wp eval-file e si può rilanciare senza creare doppioni, perché salta gli slug già presenti. In cima ci sono i nomi delle colonne. Nel file di Webflow ogni colonna porta il nome del campo della Collection, quindi vanno copiati dalla prima riga del tuo; le categorie che non esistono ancora vengono create.

<?php
/**
 * Importa in WordPress gli articoli di una Collection esportata in CSV (Webflow o altro).
 * Uso: wp eval-file importa-csv.php esportazione.csv --user=admin
 *
 * Un articolo per riga, con lo stesso slug e la stessa data. Scarica nella Libreria media
 * l'immagine principale e le immagini dentro il testo, e ne riscrive gli indirizzi.
 * Si può rilanciare: le righe con uno slug già presente vengono saltate.
 */

// A destra le intestazioni della prima riga del tuo file (qui quelle della mia prova).
$colonne = array(
	'titolo'     => 'Name',
	'slug'       => 'Slug',
	'data'       => 'Published On',
	'testo'      => 'Post Body',
	'riassunto'  => 'Post Summary',
	'immagine'   => 'Main Image',
	'categorie'  => 'Category', // riferimenti come testo, più voci separate da virgole
	'archiviato' => 'Archived', // le voci archiviate finiscono nel file: qui diventano bozze
);

require_once ABSPATH . 'wp-admin/includes/media.php';
require_once ABSPATH . 'wp-admin/includes/file.php';
require_once ABSPATH . 'wp-admin/includes/image.php';
require_once ABSPATH . 'wp-admin/includes/taxonomy.php';

// Le AVIF WordPress le accetta dalla 6.5, ma il download da URL non le prevede.
add_filter( 'image_sideload_extensions', fn( $estensioni ) => array_merge( $estensioni, array( 'avif' ) ) );

// Scarica un'immagine una volta sola: se l'URL è già nella Libreria media, riusa quella.
$scarica = function ( $url, $post_id ) {
	$gia = get_posts( array( 'post_type' => 'attachment', 'post_status' => 'inherit', 'meta_key' => '_source_url', 'meta_value' => $url, 'fields' => 'ids', 'numberposts' => 1 ) );
	return $gia ? $gia[0] : media_sideload_image( $url, $post_id, null, 'id' );
};

if ( empty( $args[0] ) || ! is_readable( $args[0] ) ) {
	WP_CLI::error( 'Indica il file CSV da importare.' );
}
$csv             = fopen( $args[0], 'r' );
$intestazioni    = fgetcsv( $csv, null, ',', '"', '' );
$intestazioni[0] = preg_replace( '/^\xEF\xBB\xBF/', '', $intestazioni[0] ); // BOM di Excel
$creati = $saltati = $immagini = 0;

while ( ( $riga = fgetcsv( $csv, null, ',', '"', '' ) ) !== false ) {
	if ( count( $riga ) !== count( $intestazioni ) ) {
		WP_CLI::warning( 'Riga con un numero di colonne diverso, saltata.' );
		continue;
	}
	$r    = array_combine( $intestazioni, $riga );
	$v    = fn( $campo ) => trim( $r[ $colonne[ $campo ] ] ?? '' );
	$slug = $v( 'slug' ) ?: sanitize_title( $v( 'titolo' ) );

	if ( get_posts( array( 'name' => $slug, 'post_type' => 'post', 'post_status' => 'any', 'fields' => 'ids' ) ) ) {
		WP_CLI::log( 'Già presente: ' . $slug );
		$saltati++;
		continue;
	}
	$data = strtotime( preg_replace( '/\s*\(.*\)$/', '', $v( 'data' ) ) ); // toglie il nome del fuso fra parentesi, se c'è
	if ( ! $data ) {
		WP_CLI::warning( 'Data non leggibile per ' . $slug . ': uso quella di oggi.' );
	}
	$id = wp_insert_post( wp_slash( array(
		'post_type'     => 'post',
		'post_status'   => 'true' === strtolower( $v( 'archiviato' ) ) ? 'draft' : 'publish',
		'post_title'    => $v( 'titolo' ),
		'post_name'     => $slug,
		'post_excerpt'  => $v( 'riassunto' ),
		'post_content'  => $v( 'testo' ),
		'post_date_gmt' => $data ? gmdate( 'Y-m-d H:i:s', $data ) : '',
		'post_category' => array_filter( array_map( fn( $nome ) => wp_create_category( trim( $nome ) ), explode( ',', $v( 'categorie' ) ) ) ),
	) ), true );
	if ( is_wp_error( $id ) ) {
		WP_CLI::warning( $slug . ': ' . $id->get_error_message() );
		continue;
	}

	// Le immagini nel testo: si scaricano e si punta alla copia locale.
	$html = new WP_HTML_Tag_Processor( get_post_field( 'post_content', $id ) );
	while ( $html->next_tag( 'img' ) ) {
		$src = (string) $html->get_attribute( 'src' );
		if ( ! str_starts_with( $src, 'http' ) ) {
			continue;
		}
		$allegato = $scarica( $src, $id );
		if ( is_wp_error( $allegato ) ) {
			WP_CLI::warning( $slug . ': ' . $allegato->get_error_message() . ' ' . $src );
			continue;
		}
		$html->set_attribute( 'src', wp_get_attachment_url( $allegato ) );
		$html->remove_attribute( 'srcset' ); // le varianti le rigenera WordPress
		$html->remove_attribute( 'sizes' );
		$html->add_class( 'wp-image-' . $allegato );
		$immagini++;
	}
	wp_update_post( wp_slash( array( 'ID' => $id, 'post_content' => $html->get_updated_html() ) ) );

	if ( $v( 'immagine' ) ) {
		$allegato = $scarica( $v( 'immagine' ), $id );
		is_wp_error( $allegato ) ? WP_CLI::warning( $allegato->get_error_message() ) : set_post_thumbnail( $id, $allegato );
	}
	WP_CLI::log( 'Creato: ' . $slug . ' (ID ' . $id . ')' );
	$creati++;
}
WP_CLI::success( "Creati $creati, saltati $saltati, immagini nel testo sistemate $immagini." );

L’ho provato su un CSV costruito con le regole di esportazione di Webflow, con il testo ricco in HTML, le immagini come indirizzi del suo CDN e tre voci, una delle quali archiviata. Sono nati tre articoli con slug e data originali, anche dove la data era scritta nel formato di JavaScript, con il nome del fuso orario fra parentesi. La voce archiviata è diventata una bozza. Le quattro immagini del testo sono state scaricate e riscritte, e quella usata in due articoli è stata scaricata una volta sola. Le categorie, anche due nella stessa cella, sono state create e assegnate. Alla seconda esecuzione lo script ha saltato tutte e tre le righe.

Tre dettagli sono venuti fuori dalle prove. media_sideload_image(), la funzione che scarica le immagini, accetta soltanto jpg, jpeg, jpe, png, gif e webp. Le AVIF, che WordPress gestisce dalla versione 6.5 se il server le supporta, vanno aggiunte con il filtro in cima allo script. Gli SVG restano fuori, e lo script li segnala senza toccarli, perché WordPress non li accetta come caricamento. L’opzione --user serve per l’autore, perché senza WP-CLI non imposta nessun utente e gli articoli nascono con autore 0.

Le immagini: nella Libreria media prima di spegnere il vecchio sito

Nessuna delle esportazioni viste finora contiene le immagini.

Contengono i loro indirizzi, e l’istruzione di andarle a prendere. Lo scrivono tre documentazioni diverse. WordPress.com chiede di tenere pubblico il sito vecchio finché quello nuovo non ha copiato le immagini; Webflow avverte che gli indirizzi del CSV smettono di funzionare quando si cancella il sito; Squarespace, che le immagini possono restare collegamenti al sito disattivato.

Una prova con il WordPress Importer mostra dove sta la trappola. Ho importato un file con due immagini, una dichiarata come allegato e una presente solo nel testo. La prima è finita nella Libreria media, con l’indirizzo riscritto nel testo. La seconda è rimasta sul dominio di partenza. Finché il sito vecchio è online il sito nuovo le mostra entrambe, e il giorno in cui lo si chiude ne perde una. Un’importazione che sembra riuscita va quindi controllata prima di disdire la piattaforma.

Il controllo è una ricerca del dominio vecchio dentro i contenuti. Con WP-CLI:

wp post list --post_type=any --post_status=any --s=website-files.com --fields=ID,post_status,post_title

Il dominio da cercare è quello da cui arrivano le immagini del tuo sito; per Webflow è quello dell’esempio. Ogni riga del risultato è un contenuto che dipende ancora dalla piattaforma, e va sistemato prima della disdetta. Nella prova dello script la ricerca ha trovato l’unico articolo rimasto con un’immagine esterna, l’SVG. Le immagini rimaste fuori si caricano a mano nella Libreria media e si sostituiscono nei blocchi che le usano. Quando l’esportazione è un file WXR, WordPress.com suggerisce anche un controllo più rapido, il numero di elementi nella Libreria media, che deve essere uguale sui due siti.

Resta una perdita che nessun controllo evita.

Nella guida di Google ai trasferimenti immagini, video e file fanno parte del trasloco, e vanno reindirizzati come le pagine. Se però stavano sul dominio della piattaforma, i loro indirizzi non sono tuoi e non si possono reindirizzare. Le copie nella Libreria media hanno indirizzi nuovi, e Google le deve trovare da capo. Aiuta tenere i nomi dei file e i testi alternativi, che lo script conserva, e conviene mettere in conto un periodo in cui le immagini vanno riscoperte.

Gli indirizzi: i permalink si decidono prima di importare

Un sito che cambia piattaforma e tiene gli stessi indirizzi non ha bisogno di redirect.

Per arrivarci l’ordine conta. Prima l’elenco degli indirizzi vecchi, poi la struttura dei permalink, poi l’importazione, e solo alla fine i redirect per quello che non torna.

Per l’elenco Google suggerisce di partire dalle sitemap del sito vecchio, dai collegamenti che Search Console registra verso il sito e dalle statistiche di traffico, includendo immagini e file. La sitemap, da salvare prima del passaggio finché risponde, è il punto di partenza più rapido.

Poi si guarda la forma degli indirizzi. Su Webflow gli articoli di una Collection stanno in una cartella e le pagine statiche alla radice o nelle loro cartelle, senza barra finale; su Squarespace gli articoli stanno sotto /blog/. In WordPress la stessa forma si ottiene da Impostazioni, Permalink, scegliendo Struttura personalizzata: /post/%postname% ricopia gli articoli di una Collection con indirizzo post, /blog/%postname% quelli di Squarespace. Si imposta prima di importare, perché i link interni e le verifiche partono da lì.

Ho provato tre strutture su WordPress 7.1.2, con un articolo e una pagina, chiedendo al sito un indirizzo nella forma di Webflow, /post/articolo-di-prova:

La prima riga è quella da preferire quando si può, perché gli indirizzi restano gli stessi e non serve nessun redirect; le varianti con la barra rispondono con un 301 verso quelle senza. La scelta della barra finale vale per tutto il sito, perché WordPress la deduce dall’ultimo carattere della struttura e la applica anche alle pagine e agli archivi. Anche il prefisso vale per gli archivi, e con /post/%postname% la categoria Notizie risponde su /post/category/notizie.

La terza riga sembra comoda, e lo è meno di quanto sembri. Quel 301 non nasce da una regola ma dalla funzione con cui WordPress, davanti a un indirizzo che non esiste, cerca un contenuto con uno slug che comincia allo stesso modo. Nella stessa prova anche /post/articolo, un indirizzo mai esistito, è finito su quell’articolo, mentre uno slug cambiato durante la migrazione ha risposto 404. È un ripiego, e il core permette di spegnerlo con il filtro do_redirect_guess_404_permalink.

Quello che non si può ricopiare diventa una mappa di redirect, una riga per ogni indirizzo vecchio con la destinazione esatta, raggiunta in un salto solo. Le regole si scrivono con Rank Math o direttamente sul server, e quale codice usare e con quale strumento è spiegato in una guida a parte. Due indicazioni di Google valgono qui più che altrove. Niente redirect in massa verso la home, che possono essere trattati come pagine inesistenti, e redirect tenuti per almeno un anno. Lo strumento Cambio di indirizzo di Search Console invece non serve se il dominio resta lo stesso: Google lo prevede solo per il passaggio da un dominio o da un sottodominio a un altro.

Nella mappa vanno anche i redirect che la piattaforma aveva già, altrimenti gli indirizzi che portavano verso quelli vecchi si interrompono. Webflow li esporta in un CSV con indirizzo vecchio e indirizzo nuovo. Il plugin gratuito Redirection importa un CSV con origine e destinazione nelle prime due colonne, mentre il modulo dei redirect di Rank Math accetta un CSV solo nella versione Pro. Le regole con i caratteri jolly di Webflow, scritte con (.*) e %1, vanno riscritte nella sintassi del plugin che le riceve.

Quello che va rifatto: tema, moduli, negozio

Il tema si decide prima di importare, perché i contenuti vanno controllati dentro il tema definitivo. Le strade sono tre. Si può scegliere un tema professionale e adattarlo con un child theme, oppure scriverlo da zero, che ha senso quando il sito vecchio aveva un disegno su misura da ricostruire fedelmente. In quel caso l’esportazione del codice di Webflow torna utile come riferimento per misure, colori e struttura delle pagine.

I moduli si ricostruiscono con un plugin di WordPress. Prima di spegnere la piattaforma si scaricano gli invii ricevuti, che su Webflow sono un CSV per ogni modulo, e si salvano subito gli allegati, perché nel file ci sono solo i loro indirizzi. Un modulo nuovo ha bisogno anche di una protezione anti-spam, che la piattaforma di partenza forniva senza chiedere niente.

Anche i menu si rifanno. L’importatore di WordPress.com per Wix li porta, mentre da Webflow e da Squarespace non escono, perché fanno parte del design. In un tema a blocchi si ricostruiscono con il blocco Navigazione, in un tema classico da Aspetto, Menu.

Il negozio è un progetto a sé. WooCommerce ha un importatore CSV per i prodotti, che la documentazione di WordPress elenca fra gli importatori disponibili, e Webflow esporta i prodotti in CSV come il resto del CMS. Le colonne dei due file non coincidono e vanno abbinate una per una; ordini, clienti e pagamenti sono un lavoro separato.

Poi c’è quello che la piattaforma aggiungeva da sola, come il codice delle statistiche, il banner dei cookie, i pixel delle campagne e la ricerca interna, e va rimesso pezzo per pezzo. Le statistiche conviene tenerle attive su tutti e due i siti nei giorni del passaggio, come suggerisce Google, per vedere il traffico spostarsi dal vecchio al nuovo.

Titoli, descrizioni e il resto della SEO

Su Webflow il titolo e la descrizione per i motori di ricerca delle pagine di una Collection sono un modello costruito con i campi della Collection, come spiega la guida alle pagine delle Collection. Le pagine statiche hanno i loro valori nelle impostazioni di pagina. Nel CSV si trovano quindi i campi e non il risultato, e delle pagine statiche niente. In WordPress si ricostruiscono con il plugin SEO. Con Rank Math si imposta un modello per tutti gli articoli in Titoli e Meta, e i valori pagina per pagina dove servono, copiandoli dall’HTML del sito vecchio finché risponde. Lo stesso vale per titolo e descrizione delle anteprime sui social (Open Graph), che su Webflow sono un secondo modello.

Il resto è una lista corta, presa dalla guida di Google. Ogni pagina nuova ha un canonical verso sé stessa. La sitemap nuova va inviata a Search Console, e per un po’ quella vecchia mostrerà indirizzi che reindirizzano, cosa che Google considera normale. La verifica della proprietà in Search Console deve sopravvivere al cambio, quindi un file HTML o un meta tag di verifica vanno rimessi nel sito nuovo. Infine il sito nuovo, mentre si costruisce, va tenuto fuori dai motori di ricerca, e per questo la soluzione più sicura è quella che si usa per gli ambienti di staging, un sito protetto da una password chiesta dal server, che nessun motore può indicizzare per sbaglio. Il rischio opposto è lasciare acceso un noindex messo durante lo sviluppo, che è uno dei controlli della checklist SEO on-page da rifare il giorno del passaggio.

Il giorno del passaggio e la settimana dopo

Il passaggio in sé somiglia a un trasloco fra due server, con il TTL del DNS abbassato qualche giorno prima, il sito nuovo collaudato al dominio definitivo attraverso il file hosts, i contenuti congelati mentre cambia il puntamento. La procedura completa è quella di un cambio di server senza interruzioni. Qui mi fermo su quello che cambia quando si lascia una piattaforma.

Il dominio, per cominciare, può essere registrato presso la piattaforma stessa. Si può trasferire la registrazione oppure cambiare solo il puntamento, e la seconda strada è più rapida e rimanda il trasferimento a quando il sito nuovo è stabile. Se poi cambi i nameserver, cambi chi risponde per tutto il dominio, posta compresa. Squarespace lo scrive nella sua guida ai nameserver, aggiornata il 21 settembre 2026. Con nameserver esterni i record impostati sulla piattaforma smettono di valere, e quelli della posta, come MX e DKIM, vanno ricreati dal nuovo fornitore. Prima del cambio si fa l’elenco completo dei record, oppure si cambiano soltanto quelli del sito e i nameserver restano dove sono. In ogni caso la piattaforma resta attiva finché non hai verificato tre cose: le immagini nella Libreria media, i redirect provati uno per uno, il DNS stabile. Su Webflow l’ordine conta anche per la disdetta, che scollega i domini personalizzati. I file esportati (CSV, XML, codice, invii dei moduli) si conservano come archivio.

Il giorno dopo si prova la lista degli indirizzi vecchi, tutti e non a campione. Questo ciclo stampa per ognuno il codice finale, il numero di redirect e l’indirizzo d’arrivo:

#!/bin/sh
# Prova ogni indirizzo del sito vecchio sul sito nuovo e stampa: codice finale,
# numero di redirect, indirizzo d'arrivo. vecchi-url.txt: un indirizzo per riga.
while read -r url; do
  curl -s -o /dev/null -L --max-redirs 10 \
    -w "%{http_code} %{num_redirects} %{url_effective} <- $url\n" "$url"
done < vecchi-url.txt

Ogni riga deve finire con 200 e al massimo un redirect, e va letto anche l’indirizzo d’arrivo. Nella prova un indirizzo mai esistito, /post/articolo, ha risposto 200 dopo un redirect, perché WordPress l’aveva abbinato a un articolo con uno slug simile. Nelle settimane successive il rapporto sull’indicizzazione delle pagine e quello delle sitemap, in Search Console, mostrano gli indirizzi vecchi che escono e i nuovi che entrano. Google avverte che per un sito di medie dimensioni servono alcune settimane, e che nel frattempo le posizioni oscillano.

Domande frequenti

Da qui in avanti

Un cambio di piattaforma riuscito si riconosce da quello che non succede.

Nessun indirizzo vecchio che finisce su un 404, nessuna immagine che sparisce il giorno della disdetta, nessun modulo che smette di arrivare. Ci si arriva lavorando in ordine, con l’elenco degli indirizzi prima dei permalink e i permalink prima dell’importazione. Il passaggio da Blogger, con il suo importatore e i suoi indirizzi, ha una guida a parte; le decisioni da prendere prima di rifare un sito da capo ne hanno un’altra.

Se preferisci che lo faccia io

Portare un sito su WordPress da un’altra piattaforma, con gli indirizzi mappati, le immagini nella Libreria media e i redirect provati uno per uno, è il lavoro del servizio di migrazione e trasferimento del sito. Se vuoi che me ne occupi io, scrivimi da quale piattaforma parti e quante pagine ha il sito.