TL;DR: se l’AI ti prepara un cambio di dominio per WordPress, non farle scrivere SQL da eseguire alla cieca. Chiedi un comando wp search-replace, aggiungi --dry-run e controlla il report prima di modificare il database.
Durante una migrazione basta una sostituzione troppo ampia per lasciare URL vecchie, rompere dati serializzati o cambiare campi che dovevano restare intatti. Il problema non è usare l’AI per preparare il comando. È trattare il suo output come se fosse già una procedura approvata.
La soluzione: separare proposta ed esecuzione
Fai produrre all’AI un comando WP-CLI con valori espliciti, scope dichiarato e modalità di prova. wp search-replace gestisce i dati PHP serializzati e l’opzione --dry-run esegue la ricerca mostrando il report, senza salvare modifiche nel database.
Per un passaggio da staging a produzione, la prima esecuzione può essere:
wp search-replace 'https://staging.example.com' 'https://example.com' --skip-columns=guid --dry-run
Gli URL sono esempi: sostituiscili solo dopo aver verificato protocollo, dominio e percorso. Il flag su guid rende esplicito un vincolo importante nelle migrazioni WordPress: quel campo non va riscritto come una normale URL.
I passaggi essenziali
- Fai un backup del database. Salvalo fuori dal server che stai modificando. Il dry run riduce il rischio, ma non sostituisce un rollback disponibile.
- Dai all’AI uno scope stretto. Indica vecchia URL, nuova URL, installazione singola o multisite, tabelle escluse e richiesta esplicita di non produrre SQL diretto.
- Esegui solo la prova. Leggi il numero di sostituzioni per tabella. Se compaiono tabelle inattese o conteggi poco credibili, fermati e correggi il comando.
- Rimuovi
--dry-runsolo dopo la revisione. Esegui in una finestra controllata, poi verifica frontend, login, media, moduli e redirect.
È la stessa disciplina usata per il codice generato: output piccolo, leggibile e verificabile. Per le modifiche a temi e plugin ho raccolto il flusso gemello nell’articolo su come chiedere all’AI una patch WordPress circoscritta.
L’errore da evitare
Non limitarti a chiedere: “dammi il comando per cambiare dominio”. Senza contesto, il modello può scegliere uno scope troppo largo o ignorare multisite, prefissi e colonne da escludere. Il prompt deve produrre una proposta da revisionare, non un’autorizzazione implicita a toccare la produzione.
Take finale
L’AI è utile quando riduce il tempo necessario a preparare una migrazione. La sicurezza arriva da un’altra parte: backup, scope esplicito, dry run e verifica. Se il comando non può essere provato e spiegato prima dell’esecuzione, non è pronto per il database di un cliente.

