Restyling di un sito WordPress: cosa decidere prima e cosa sparisce con il tema vecchio

Il restyling di un sito WordPress passa quasi sempre da un cambio di tema, e il tema nuovo è l’ultima cosa da scegliere. Prima vengono le decisioni che costano care quando arrivano tardi. Che lavoro stai facendo, cosa del sito di oggi va tenuto, cosa sparisce insieme al tema vecchio, dove si costruisce il sito nuovo e come arriva online senza portarsi dietro il database di una copia. Questa guida le mette in fila, insieme a quello che WordPress fa nel momento del cambio, provato su due siti di prova. Le operazioni tecniche, come copiare il sito, spostarlo, scrivere i redirect o scegliere il tema, hanno ciascuna la sua guida, linkata nel punto in cui serve.

Una nota sulle fonti. Le prove le ho fatte il 12 ottobre 2026 su due installazioni di WordPress 7.1.3 (PHP 8.3, WP-CLI 2.12.0), una nel ruolo del sito vero e una in quello della copia di lavoro. Il tema di partenza è un tema classico costruito apposta con le abitudini di molti temi “tutto incluso”; quelli d’arrivo sono Twenty Twenty-One 2.9, classico, e Twenty Twenty-Five 1.5, a blocchi. Il resto viene dal codice di WordPress 7.1.3 e dalla documentazione ufficiale di WordPress, di WP-CLI e di Google, letta lo stesso giorno. Dove compare un numero di versione, accanto c’è la data.

Che lavoro stai facendo: restyling, rifacimento o cambio di piattaforma

Restyling è una parola che copre lavori diversi, e da quello che stai facendo dipendono gli indirizzi, il rischio e la guida da seguire.

I primi due possono arrivare insieme a uno degli altri due, ed è il caso da evitare.

La guida di Google ai trasferimenti di sito lo dice con una frase, “Effettua una modifica alla volta”, e con l’esempio di chi vuole passare a un dominio nuovo, cambiare il sistema di gestione dei contenuti e adottare un layout nuovo. Vanno fatti uno dopo l’altro. Se dopo un rilascio che ha cambiato tema, indirizzi e dominio il traffico scende, non c’è modo di sapere quale dei tre cambiamenti l’ha fatto scendere, e quindi su cosa intervenire.

Per un restyling questo vuol dire tenere fermo tutto il resto, dal dominio all’hosting, dalla struttura dei permalink al plugin SEO. In un rifacimento cambiano solo gli indirizzi che il rifacimento tocca, con le regole che valgono quando cambia la struttura di un sito già online. Il cambio di dominio, se è deciso, si fa in un altro momento, e ha una guida in calendario.

La fotografia del sito prima di toccarlo

Il dopo si giudica sul prima, e il prima va fotografato finché c’è. Le fotografie da fare sono tre, e riguardano gli indirizzi, i numeri e le funzioni.

Gli indirizzi

L’elenco degli indirizzi pubblici lo dà il sito stesso. Con WP-CLI, dalla cartella di WordPress, questi due cicli scrivono in un file l’indirizzo di ogni contenuto pubblicato, per tutti i tipi di contenuto pubblici, e quello di ogni categoria, tag o altra tassonomia pubblica. Ci sono anche i tipi di contenuto e le tassonomie registrati dal tema, che sono i primi a sparire.

# Tutti gli indirizzi pubblici del sito, uno per riga
for tipo in $(wp post-type list --public=1 --field=name); do
  wp post list --post_type="$tipo" --post_status=publish --field=url
done > "$HOME/indirizzi-prima.txt"
for tax in $(wp eval 'echo implode( " ", get_taxonomies( array( "public" => true ) ) );'); do
  wp term list "$tax" --field=url
done >> "$HOME/indirizzi-prima.txt"
wc -l "$HOME/indirizzi-prima.txt"

Il secondo ciclo prende le tassonomie da get_taxonomies() perché nella prova il filtro --public=1 di wp taxonomy list, nella versione 2.12.0, le ha elencate tutte, comprese quelle interne come i menu. Restano fuori la home e gli archivi degli autori e dei tipi di contenuto, che si aggiungono a mano. Sul sito di prova il file aveva dieci righe, fra cui i due progetti del tipo di contenuto registrato dal tema. Il file serve due volte. Prima del rilascio dice cosa deve continuare a esistere, dopo si passa riga per riga sul sito nuovo con il controllo con curl di ogni indirizzo, che stampa il codice di risposta e l’indirizzo d’arrivo.

Le pagine che contano di più si vedono da fuori. In Search Console il report sul rendimento, raggruppato per pagina, dice quali portano visite dalla ricerca, e il report Link, alla voce Pagine più collegate, quali ricevono link da altri siti. La tabella del report sul rendimento mostra al massimo 1.000 righe, e i dati si esportano.

I numeri da confrontare dopo

Un restyling cambia template, peso delle pagine e posizione dei pulsanti, e ognuna di queste cose si vede nei numeri. Prima di cominciare si annotano il traffico dalla ricerca, le prestazioni di una pagina per ogni modello e quello che il sito deve produrre, come richieste dai moduli, ordini o iscrizioni.

Per il traffico lo strumento c’è già. Per misurare l’effetto di una modifica, la guida di Search Console suggerisce di confrontare i dati con periodi simili del passato, con la funzione Confronta del report sul rendimento e una granularità settimanale o mensile, che toglie l’effetto del giorno della settimana. Il giorno del rilascio si segna sul grafico con un’annotazione personalizzata, che resta 500 giorni ed è visibile a tutti gli utenti della proprietà. Le annotazioni non compaiono in modalità di confronto, e si guardano sul grafico normale.

Per le prestazioni si misura un indirizzo per modello di pagina, la home, un articolo, un archivio e una scheda prodotto se c’è, come nel controllo 14 della checklist SEO on-page. Annotare anche quale elemento determina l’LCP aiuta a capire, dopo, cosa è cambiato.

Cosa fa il sito oltre ad apparire

La terza fotografia è quella che si dimentica.

Moduli con le loro notifiche, iscrizioni alla newsletter, codici di tracciamento, integrazioni con un gestionale o un CRM, ricerca interna. Ognuna di queste funzioni sta in un plugin, in un servizio esterno o nel tema, e quelle nel tema se ne vanno con lui. Si parte dall’inventario che precede una pulizia, con i plugin attivi e inattivi, i temi installati e il peso del database, e si arriva al rifacimento sapendo cosa il sito usa e cosa no.

Cosa sparisce quando cambi tema, e cosa resta

Su WordPress un restyling è quasi sempre un cambio di tema, e il cambio di tema fa cose precise. Le ho provate partendo da un tema classico costruito apposta, con una posizione di menu chiamata menu-1, come nei temi nati da Underscores, una seconda per il footer, due aree widget, un tipo di contenuto, uno shortcode, una dimensione delle immagini, un modello di pagina e un codice di tracciamento nel functions.php. Da lì sono passato a Twenty Twenty-One e a Twenty Twenty-Five, e sono tornato indietro.

Il caso che sorprende è il menu in un tema a blocchi. Twenty Twenty-Five non ha posizioni di menu, e il suo header contiene un blocco Navigazione che, se nessuno gli ha detto quale menu usare, se ne cerca uno da solo. Nel codice di WordPress 7.1, con la funzione che sceglie il menu di ripiego, prende l’ultimo menu a blocchi pubblicato. Se non ce n’è nessuno, ne crea uno copiando un menu classico, quello assegnato alla posizione primary del tema attivo, oppure quello con slug primary, oppure l’ultimo creato. Dopo il cambio la prima strada è chiusa, perché il tema a blocchi le posizioni non le ha.

Nella prova la home ha mostrato tre menu diversi a seconda di cosa c’era nel database. Con il menu a blocchi che WordPress si era creato all’installazione, l’header elencava tutte le pagine pubblicate, Sample Page compresa. Senza quel menu ha mostrato il menu del footer, che era il menu classico creato per ultimo, copiato in un menu a blocchi alla prima visita di un utente anonimo. Solo con lo slug primary sul menu principale l’header ha mostrato il menu giusto. Il menu creato all’installazione non è un incidente del banco di prova. Mentre si installa, WordPress visita una pagina del sito per capire se può usare i permalink, e con Twenty Twenty-Five attivo quella visita basta a crearlo, con l’elenco delle pagine dentro.

Il footer dello stesso tema ha otto link dimostrativi, da Blog a Temi, che portano tutti a #.

La prova sulla copia, prima di scegliere il tema

La tabella vale per i temi della prova, e per il tuo sito la risposta la dà la copia. Su una copia di lavoro protetta e spenta si fotografa cosa registra il tema vecchio, si attiva quello nuovo e si confronta. Con WP-CLI bastano poche righe.

# Sulla copia: cosa registra il tema vecchio, cosa registra il nuovo
fotografia() {
  wp post-type list --public=1 --field=name
  wp eval 'echo implode( "\n", array_keys( $GLOBALS["shortcode_tags"] ) ), "\n";'
  wp menu location list --format=csv
  wp sidebar list --fields=id,name --format=csv
}
fotografia > "$HOME/prima.txt"
wp theme activate tema-nuovo
fotografia > "$HOME/dopo.txt"
diff -u "$HOME/prima.txt" "$HOME/dopo.txt"

Le righe che cominciano con il segno meno sono quello che c’era e non c’è più, quelle con il più quello che arriva con il tema nuovo. Passando a Twenty Twenty-One il confronto ha segnalato il tipo di contenuto progetto, lo shortcode pulsante, le due posizioni di menu e l’area widget del footer. Per ogni shortcode che sparisce, wp post list --post_type=any --s='[nome' dice quali contenuti lo usano, e va lanciato prima di cambiare tema. Poi si apre la copia nel browser e si guardano una pagina per modello, il menu, il footer e un’immagine.

Se il sito è fatto con un page builder

Con un page builder il problema passa dal tema ai contenuti. Elementor (4.3.4, del 5 ottobre 2026) salva l’impaginazione nei metadati della pagina e, a ogni salvataggio, scrive nel contenuto una versione semplificata, senza struttura né stili. Nella prova, con il plugin spento, la pagina mostrava il titolo, il testo e il link del pulsante uno sotto l’altro, e nessuna classe di Elementor. Se Elementor resta anche nel sito nuovo, l’impaginazione è ancora nei suoi metadati; se lo si toglie, si riparte da quella versione, pagina per pagina.

I builder che salvano il contenuto come shortcode lasciano invece il testo pieno di parentesi quadre, perché WordPress esegue solo gli shortcode che qualcuno ha registrato e lascia gli altri così come sono. La prova è la stessa per tutti. Sulla copia si spegne il builder e si guardano le pagine. Tenerlo o lasciarlo è una decisione da prendere prima di scegliere il tema, perché decide quanta parte del lavoro riguarda i contenuti.

Gli indirizzi: restano uguali o diventano una mappa di redirect

In un restyling gli indirizzi non cambiano, perché il cambio di tema non tocca permalink, slug e categorie. Si provano lo stesso, per la ragione vista nella tabella. Un tipo di contenuto registrato dal tema vecchio porta con sé i suoi indirizzi, e senza quel tema rispondono 404. Nella prova, sul file degli indirizzi passato con curl, otto righe su dieci hanno risposto 200 e le due dei progetti 404, e la sitemap del core ha smesso di elencare i progetti.

Il rimedio è registrare quel tipo di contenuto in un plugin prima del cambio, con lo stesso nome e lo stesso slug.

Nella prova, con un plugin così e i permalink salvati una volta, i progetti e il loro archivio sono tornati a 200 e la sitemap li ha elencati di nuovo.

In un rifacimento una parte degli indirizzi cambia, e ognuno ha bisogno di una destinazione precisa. La mappa si costruisce sul file di prima, riga per riga, abbinando a ogni indirizzo vecchio quello nuovo che risponde alla stessa domanda. Le regole sono quelle di ogni redirect permanente. Un 301 in un salto solo, mai tutti verso la home, che Google può trattare come pagine inesistenti, e regole tenute almeno un anno. Con quale codice e con quale strumento si scrivono, e cosa WordPress fa già da solo, è spiegato nella guida su come scrivere un redirect in WordPress e cosa fa già il core.

La mappa conviene scriverla in un foglio prima di creare le regole, con tre colonne: indirizzo vecchio, indirizzo nuovo e codice di risposta.

Due casi da guardare per primi.

Le pagine accorpate, dove il redirect va alla pagina che ha preso il contenuto e non alla sezione che la contiene. Le categorie, se il permalink le contiene, perché rinominarne una cambia l’indirizzo di tutti i suoi articoli. I link interni, poi, si riscrivono verso gli indirizzi nuovi, senza lasciarli al redirect.

Una pagina che non serve più e non ha un equivalente può rispondere 404 o 410. La decisione si prende pagina per pagina, guardando nel file e in Search Console quali hanno visite o link da fuori, perché quelle meritano una destinazione.

Dove si costruisce il sito nuovo, e come arriva online

È la decisione più costosa da prendere tardi, perché stabilisce dove sta il lavoro il giorno del rilascio. Un restyling si fa su una copia, e da una copia, come spiega la guida su cosa riportare sul sito vero dopo il lavoro sulla copia, tornano il codice e le impostazioni, e il database solo nel caso che si vede più avanti, perché nel frattempo il sito vero ha ricevuto ordini, commenti e messaggi.

Le strade sono quattro.

Il tema scritto come codice

È la strada che uso io. Il tema nuovo è una cartella di file, un child theme di un tema esistente o un tema nato da una cartella vuota, che sviluppo in locale e porto in produzione come file. Sul sito vero, il giorno del rilascio, si attiva il tema e si rifanno a mano le impostazioni che stanno nel database, con la tabella di prima come lista. Menu e widget da riassegnare, impostazioni del Personalizza, CSS aggiuntivo da portare nei file. Il tipo di contenuto e gli shortcode del tema vecchio, se il sito li usa, passano in un plugin prima del cambio, e il giorno del rilascio non c’è nessun 404.

Il tema modificato nell’Editor del sito

Con un tema a blocchi il restyling si può fare senza codice, nell’Editor del sito. Il lavoro però finisce nel database. Template, parti del template e stili globali sono contenuti salvati e legati al tema, i menu a blocchi sono contenuti del sito, e fatti sulla copia restano tutti sulla copia.

Per portarli fuori c’è l’esportazione del core, nel menu Opzioni dell’editor alla voce Strumenti, Esporta, che scarica il tema con i template, le parti e un theme.json con i tuoi stili. Nella prova lo zip conteneva tutto questo, compreso il CSS aggiuntivo scritto nell’editor, più tre cose che sul sito vero non funzionano. Menu e pattern sincronizzati sono richiamati per numero, con il numero che hanno nel database della copia, e sul sito vero il menu è uscito vuoto e il pattern non c’era. Le immagini inserite nei template puntano all’indirizzo della copia, e si vedono finché la copia resta accesa e aperta. Lo zip, infine, si chiama come il tema di partenza e dentro dice di essere quel tema. Caricato al posto di Twenty Twenty-Five, è stato sovrascritto dal primo aggiornamento del tema ufficiale, che ho simulato abbassando il numero di versione, e header e stili sono tornati quelli di serie.

Il caso peggiore è venuto da un numero che sul sito vero esisteva ma era un’altra cosa. Quando il numero del menu della copia, sul sito vero, era quello di un articolo pubblicato, il blocco Navigazione ha stampato nell’header il testo dell’articolo e ha preso il suo titolo come nome del menu per i lettori di schermo. Il blocco del pattern sincronizzato controlla che il numero sia un pattern, il blocco Navigazione no (blocks/block.php e blocks/navigation.php in WordPress 7.1.3).

Create Block Theme (2.10.2, del 1° ottobre 2026), il plugin del progetto WordPress che trasforma in file il lavoro fatto nell’editor, nella sua esportazione toglie i riferimenti ai menu e copia le immagini dentro il tema. Il menu dell’header diventa così quello di ripiego del sito vero, che nella prova era l’elenco delle pagine, e il pattern sincronizzato resta richiamato per numero. Nel comando del plugin che salva le modifiche nel tema le stesse opzioni ci sono, spente finché non le spunti. Qualunque esportazione si usi, prima di caricarla servono un nome nuovo, nello style.css e nella cartella, e un controllo.

# Lo zip esportato, scompattato nella cartella tema-nuovo/
grep -rn --include='*.html' --include='*.php' '"ref":' tema-nuovo
grep -rln 'staging.tuosito.it' tema-nuovo

Ogni riga del primo comando è un menu o un pattern da rifare sul sito vero, ogni file del secondo un’immagine da caricare. Nella prova il primo ha trovato due riferimenti nello zip del core e uno in quello di Create Block Theme, il secondo un file solo, nello zip del core. A quel punto il tema è una cartella di file con un nome suo, e si torna alla prima strada.

Il sito fermo e l’installazione nuova

Resta l’eccezione già vista nella guida alla copia, il sito fermo, dove fra la copia e il rilascio non arriva niente, nessun ordine, commento, iscrizione o messaggio. Lì il database della copia può tornare indietro, a patto di fermare i contenuti per tutta la durata del lavoro e di ricontrollare la casella “Scoraggia i motori di ricerca” subito dopo.

L’ultima strada è un’installazione nuova, con il tema nuovo, in cui si importano i contenuti del sito vecchio. È un trasloco, con indirizzi da ricopiare, immagini da portare e redirect da provare, e ha senso quando il rifacimento è radicale. Valgono le regole di un cambio di piattaforma, a partire dagli indirizzi decisi prima di importare.

Quello che un restyling non deve rompere

Un tema nuovo cambia il markup di ogni pagina, e con il markup cambiano tre cose che nella demo del tema non si vedono.

L’accessibilità. La checklist di audit prevede un controllo rapido dopo ogni cambio di tema, i blocchi B, D ed E dell’audit di accessibilità in 24 controlli, e la parte che si rompe più spesso è la tastiera. Due dei sette problemi ricorrenti della guida alla navigazione da tastiera, il focus che non si vede e il menu che si apre solo passandoci sopra, dipendono dal CSS e dai menu del tema.

Le prestazioni. Si rimisura un indirizzo per modello e si confronta con la fotografia di prima. I dati raccolti da Chrome sugli utenti veri coprono gli ultimi 28 giorni, quindi il verdetto sul campo arriva qualche settimana dopo il rilascio. Se peggiorano, le cause sono quasi sempre fra le sei cause di un sito che rallenta.

La SEO della pagina. Il tema decide gli heading, e il blocco Titolo del sito lasciato al livello predefinito stampa un H1 in ogni pagina, accanto a quello del contenuto, come spiega la guida alle righe di testo e titoli nell’header di un tema a blocchi. Il controllo 9 della checklist, sul noindex rimasto acceso e sul canonical, si rifà il giorno stesso, e i dati strutturati si ricontrollano se li generava il tema vecchio.

Poi i moduli. Dopo il rilascio si inviano uno per uno, per vedere che le notifiche arrivano e che la protezione anti-spam c’è ancora.

Il giorno del rilascio e le settimane dopo

Il giorno del rilascio è corto se il lavoro prima è stato fatto. Google, per i trasferimenti, suggerisce il periodo di minore traffico, e vale anche qui. Si parte da un backup che si sa ripristinare, file e database. Poi si caricano il tema nuovo e i plugin che hanno preso le funzioni del vecchio, si attiva il tema, si rifanno le impostazioni della lista e si creano le dimensioni delle immagini che il tema nuovo chiede. Se il lavoro sul sito vero dura più di qualche minuto, i visitatori si tengono fuori con una pagina di manutenzione che risponde 503, come in un trasloco.

wp media regenerate --only-missing --yes

Con --only-missing, dice la documentazione del comando, si generano solo le dimensioni che mancano, senza rifare quelle che ci sono. Dopo si svuota la cache, quella del sito e quella del CDN se c’è, e si prova il file degli indirizzi con curl, una pagina per modello, il menu, il footer e i moduli. Se qualcosa non torna, il tema vecchio è ancora installato, e riattivandolo, nella prova, sono tornati widget, impostazioni e CSS aggiuntivo com’erano.

Nei giorni successivi si guardano due report di Search Console. Indicizzazione delle pagine, per gli indirizzi che escono e quelli che finiscono fra gli errori, e il report sul rendimento, con il confronto settimanale che parte dall’annotazione del giorno del rilascio. Un calo dei primi giorni si legge accanto ai 404 e ai redirect di quella settimana.

Domande frequenti

Da qui in avanti

Il tema nuovo arriva per ultimo. Prima ci sono il tipo di lavoro, la fotografia del sito di oggi, l’elenco di quello che se ne va con il tema vecchio e la scelta di dove costruire quello nuovo, che decide come arriverà online. Fatto in quest’ordine, il giorno del rilascio si lavora con una lista in mano, e il tema vecchio resta lì per tornare indietro. Dopo, il tema rientra nel controllo annuale del tema insieme al resto del sito.

Se preferisci che lo faccia io

Rifaccio siti WordPress per i clienti, e il tema nuovo lo scrivo come codice: lo sviluppo in locale e lo porto in produzione come file, con le impostazioni rifatte sul sito vero. È il lavoro del servizio di sviluppo di siti web personalizzati. Se vuoi che me ne occupi io, scrivimi che sito è, su quale tema è costruito e cosa non ti convince più.