Creare un sito WordPress con Claude o ChatGPT (in locale)

In questi giorni mi sono passati davanti alcuni video tutorial che promettono di creare un sito WordPress con Claude o ChatGPT e una manciata di prompt, e visto che non so stare zitto ti dico cosa ne penso. La ricetta è quasi sempre la stessa: crei un’application password per il tuo utente amministratore, la incolli nella chat dell’agente e lo lasci lavorare sul sito online, mentre costruisce pagine, cambia i colori, carica immagini e pubblica.
Ok, funziona, e a volte il risultato è anche bello, ma per progetti anche solo un pochino più complessi rischia di diventare un ciclo infinito di «sistema questo, sistema quello», e nel frattempo si sono rotte altre tre cose.

In questo articolo ti racconto come lavoro io: lo stesso agente e lo stesso tipo di prompt, ma su un sito che gira sul tuo computer, con GitHub che tiene la storia di ogni modifica, controlli automatici che verificano al posto tuo e un piccolo gruppo di subagenti, cioè assistenti dell’agente, in cui chi scrive il codice non è chi lo approva. Se sei un designer o un freelance che il terminale lo apre il meno possibile sei nel posto giusto: quasi tutto lo prepara l’agente da solo, partendo da un buon prompt, perché oggi per lavorare in modo ordinato conta più sapere cosa chiedere che saper programmare.

Creare un sito WordPress dal vivo

Collegare Claude o ChatGPT a un sito online con la password di un amministratore è il modo più rapido per creare un sito WordPress, e anche quello con meno reti di sicurezza: niente storia delle modifiche, niente test, nessuna revisione.

Il metodo, ripulito dai dettagli, funziona così. Installi WordPress su uno spazio online, crei dal tuo profilo un’application password, cioè una password pensata per i programmi e separata da quella con cui entri in bacheca, e la passi all’agente insieme all’indirizzo del sito. Da lì in poi l’agente usa la REST API, il canale con cui un programma parla con WordPress, per creare pagine con i blocchi di Gutenberg e caricare immagini, e quando non basta apre la bacheca e cambia le impostazioni del tema dal vivo. Tu guardi, chiedi correzioni in chat e alla fine controlli il sito sul telefono, a occhio.

A parte questo, ci sono comunque delle idee giuste: le pagine sono fatte con blocchi nativi, quindi il cliente può modificarle da solo e non resta prigioniero di un builder, e l’application password si revoca con un clic senza toccare la password di accesso.

Il mio disappunto, quindi, non riguarda gli strumenti, che sono gli stessi che uso anch’io: quello che non mi convince è il posto in cui li usi.

Mi spiego meglio: WordPress tiene le revisioni dei contenuti, ma non quelle delle impostazioni, dei plugin o del Customizer (la schermata «Personalizza» del tema): se dopo un’ora di lavoro ti accorgi che qualcosa si è rotto, non c’è un «torna a stamattina». Nessun test verifica il risultato, nessuno rilegge quello che l’agente ha fatto prima che sia online, e il sito in costruzione, con le sue pagine di prova, resta visibile a chiunque passi di lì.

Il rischio più grande arriva dopo il lancio, perché chi ha imparato a creare un sito WordPress così continuerà a modificarlo nello stesso modo anche quando il sito sarà pubblico, con il cliente che vende, i moduli che raccolgono contatti e Google che passa ogni giorno. «Se l’AI sbaglia, correggo a mano» va bene per uno spazio fuori posto, molto meno per una pagina rotta.

In locale, con gli stessi strumenti

Tutto quello che l’agente fa sul sito online lo può fare su un WordPress che gira sul tuo computer: con wp-env lo accendi con un comando, e a prepararlo ci pensa l’agente stesso.

Lo dice anche il manuale ufficiale dei temi: quando sviluppi «è una buona idea farlo in un ambiente separato dal sito live». Il manuale dell’editor a blocchi indica anche lo strumento, wp-env, open source e mantenuto dal progetto WordPress, con alternative grafiche come Studio e Local per chi preferisce cliccare.

wp-env usa Docker, un programma che fa girare il sito in una specie di scatola chiusa sul tuo computer, e legge da un file del progetto la versione di WordPress e di PHP e i plugin da attivare. Se ti sembra già troppo tecnico, non preoccuparti: l’ambiente lo prepara l’agente, e se sul computer manca qualcosa, come Docker o Node.js, te lo dice e ti guida nell’installazione, o, se gli dai i permessi, fa tutto lui.

Il metodo dei tutorial funziona identico anche qui: wp-env dichiara il sito come ambiente «locale», e in quel caso WordPress abilita le application password anche senza il lucchetto HTTPS dei siti online. Stesse pagine create dall’agente, ma su un sito che esiste solo sul tuo computer: se l’agente combina un disastro, cancelli la copia e la ricrei in un minuto, e nessun cliente se ne accorge.

Io aggiungo una regola: l’ambiente deve essere riproducibile, cioè descritto da file che stanno nel progetto, così che un collega o un altro agente possano ricrearlo identico. Quando devo creare un sito WordPress questo vuol dire mettere nel progetto anche lo script che costruisce pagine, menu e impostazioni di partenza: lo scrive l’agente, e la prossima volta che serve un sito simile parti da lì invece che da una bacheca vuota.

GitHub, la memoria del sito

Ogni modifica che l’agente fa al tema, ai plugin o agli script del sito viene salvata su GitHub con una nota: puoi sempre vedere chi ha cambiato cosa, e tornare indietro.

GitHub è il servizio online che conserva il codice di un progetto e tutta la sua storia: una specie di Dropbox in cui ogni salvataggio ha una data, un autore e una nota che spiega cosa è cambiato.

Quando devi creare un sito WordPress per un cliente, lì va solo quello che hai scritto tu: il tema, o il tema child, i plugin su misura, gli script che preparano pagine e impostazioni, la configurazione di wp-env. Mai l’intera installazione di WordPress con i plugin di terzi e la cartella delle immagini caricate. Per i clienti il progetto è privato; quando posso lo rendo pubblico, come quello di Book a Call, che ha già ambiente, controlli, test e procedure automatiche configurati.

L’agente non lavora mai direttamente sulla versione ufficiale. Apre una copia di lavoro parallela, ci fa le sue modifiche e, quando ha finito, ti manda una richiesta di approvazione: una pagina di GitHub che mostra cosa è cambiato, con l’esito dei controlli e un pulsante verde per accettare. Solo quando lo premi le modifiche entrano nella versione ufficiale. Anche colori e font stanno nei file del tema, non nella schermata «Personalizza»: così un cambio di palette si rilegge e si annulla come qualunque altra modifica.

Non devi conoscere i comandi di Git, il programma che sta dietro a GitHub: li usa l’agente. Nel progetto metto anche un CLAUDE.md (per Codex si chiama AGENTS.md), il file di istruzioni che l’agente rilegge ogni volta che parte: come si accende il sito, come si lanciano i controlli, cosa non toccare. Ne parlo più a fondo nella guida a Claude Code.

L’agente però in chat userà le parole di Git, ed è utile sapere cosa vogliono dire quando te le scrive:

Test e controlli al posto tuo

Quando usi un agente per creare un sito WordPress, procedure automatiche controllano ogni modifica prima che arrivi online, e GitHub le ripete su un computer pulito a ogni richiesta di approvazione.

Un test è un piccolo programma che prova il sito al posto tuo: apre una pagina, compila un modulo, controlla che il risultato sia quello atteso. Gli strumenti sono quasi tutti ufficiali, li trovi nella tabella qui sotto, e non devi impararli: li installa e li usa l’agente. Uno controlla che il codice rispetti le regole di scrittura di WordPress, compresa la sicurezza, un altro fa ai plugin dei clienti gli stessi controlli di Plugin Check, e Playwright apre il sito in un browser vero e guarda quello che vede il visitatore.

Il controllo mobile a occhio lo sostituisco con gli screenshot automatici: a ogni modifica Playwright fotografa le pagine principali a 390, 820 e 1280 pixel di larghezza, cioè telefono, tablet e desktop, e il revisore li guarda prima di dire che va bene. Così controlli anche i tablet, che a occhio non guarda quasi nessuno.

Il passo in più sono le procedure automatiche di GitHub, che si chiamano GitHub Actions: ogni volta che l’agente ti manda una richiesta di approvazione, GitHub prepara un computer pulito, installa tutto da zero e rilancia gli stessi controlli. Se qualcosa non va, la pagina della richiesta lo mostra in rosso, e tu sai che non è il momento di approvare. È un collega pignolo che ricontrolla tutto, ogni volta, senza stancarsi e senza dimenticare niente.

Le chiavi del sito di prova

Sul tuo computer l’agente comanda WordPress con WP-CLI e con un’application password: ha tutta la libertà che gli serve, su un sito che il mondo non vede.

WP-CLI è il modo ufficiale di dare ordini a WordPress scrivendo comandi invece di cliccare in bacheca, e dentro wp-env è già installato. Per un agente è l’interfaccia ideale, perché legge e scrive testo e ogni azione resta scritta nella conversazione: è ripetibile e verificabile. Quando le chiedo di riprodurre un bug, Claud.ia crea da sola i contenuti, l’utente o la configurazione che servono, verifica il comportamento e mi riporta il risultato, senza che io apra il browser.

L’application password serve quando l’agente deve usare il sito come farebbe un’applicazione vera: creare pagine a blocchi, caricare immagini, provare un modulo come lo proverebbe un visitatore. In locale gliela crei per un utente dedicato, mai per il tuo, e sulla copia di prova online, lo staging che mostri al cliente prima del lancio, vale lo stesso schema, con i permessi minimi. Nota che in tutto questo non c’è nessun plugin MCP installato dentro WordPress: WP-CLI e la REST API il sito le ha già, e un plugin in più sarebbe solo altro codice da aggiornare e un’altra porta aperta, come spiego nell’articolo su WordPress MCP senza plugin.

Sul sito del cliente la regola cambia: l’agente può al massimo toccare i contenuti, con un utente suo e il ruolo da redattore, mentre il codice arriva solo con una versione controllata, preparata e verificata dalle procedure automatiche di GitHub. Nello stesso articolo trovi le regole che seguo quando un agente lavora su un sito vero, dagli utenti dedicati ai plugin da evitare.

Subagenti: chi pianifica e chi controlla

Un agente principale divide il lavoro in fasi, un subagente sviluppa, un altro verifica: se è tutto verde ti chiede l’approvazione, altrimenti rimanda la lista dei problemi a chi ha scritto il codice.

Un solo agente che pianifica, scrive e poi si approva da solo è come uno studente che si corregge il compito: tende a darsi ragione. Per questo, quando il lavoro è più di una modifica veloce, come creare un sito WordPress da zero, divido i ruoli. L’agente principale non scrive codice: legge la richiesta, la divide in fasi piccole e verificabili, per esempio prima la struttura delle pagine, poi lo stile e infine i moduli, e per ogni fase prepara le istruzioni.

Il subagente sviluppatore prende una fase alla volta e la realizza nella sua copia di lavoro parallela, salvando ogni passo. Il subagente revisore parte da zero, senza aver visto come è stato scritto il codice: confronta il risultato con il piano, lancia controlli e test, guarda gli screenshot alle tre larghezze. Se è tutto a posto ti manda la richiesta di approvazione con un riassunto in parole semplici; altrimenti scrive una lista precisa dei problemi e la rimanda allo sviluppatore, che corregge e ripassa dal revisore.

Conta anche quale modello fa cosa. Con Claude uso Opus, il più potente, per l’agente principale e per il revisore, cioè per l’inizio e la fine, dove si decide il piano e si cerca l’errore; Sonnet, più veloce ed economico, per lo sviluppatore, che riceve istruzioni precise e deve soprattutto scrivere tanto e bene. L’agente principale è la sessione che apri tu, quindi la avvii già con Opus.

Così, quando devi creare un sito WordPress, il grosso del lavoro lo fa il modello che costa meno. Con ChatGPT e Codex la logica è la stessa: Sol al posto di Opus per pianificare e verificare, Terra al posto di Sonnet per sviluppare.

Due regole rendono il giro affidabile. La prima è un tetto ai tentativi: dopo tre giri senza successo i subagenti si fermano e chiedono a te, invece di girare in tondo consumando il credito dell’abbonamento. La seconda è che l’ultima parola resta tua: la richiesta arriva già controllata, ma decidere cosa entra nella versione ufficiale, e quindi cosa andrà online, è il lavoro che non si delega.

Ogni subagente è un piccolo file di testo nel progetto, con le istruzioni, gli strumenti a disposizione e il modello da usare, e lavora senza la memoria della conversazione degli altri. In Claude Code al revisore puoi anche togliere il permesso di modificare i file, così non «sistema» da solo quello che dovrebbe solo segnalare; in Codex lo stesso divieto è un’istruzione scritta. Non serve scrivere niente a mano: i file li chiedi all’agente, come tutto il resto.

Il prompt che prepara tutto

Per creare un sito WordPress con questo workflow non servono competenze tecniche: serve un prompt che dica all’agente cosa costruire, cosa non toccare e come dimostrare che ha finito.

Questo è il prompt che uso come base quando devo creare un sito WordPress nuovo. Funziona con Claude Code e con Codex, gli agenti che lavorano sul tuo computer e possono lanciare comandi, non con la normale chat nel browser; il progetto WordPress pubblica anche delle skill ufficiali per gli agenti che li aiutano a seguire le convenzioni giuste. È scritto per l’agente, quindi le parole tecniche lì dentro vanno bene: le capisce lui, e tu non devi toccarle. Il brief del cliente, i riferimenti grafici e la palette li aggiungi sotto, come faresti con un collega.

Dobbiamo creare il sito WordPress di «Cliente». Lavora solo sul mio
computer: non collegarti a nessun sito online.
Non sono uno sviluppatore: prima di installare qualcosa spiegami in
parole semplici cosa serve e aspetta il mio ok.

Ambiente
- Un repository Git privato su GitHub (se serve, guidami nel login)
  con wp-env: ultima versione stabile di WordPress, PHP 8.3, debug
  acceso. Un tema child del tema scelto e, se servono, plugin su
  misura. Colori e font nel theme.json, non nel Customizer.
- Uno script con WP-CLI che crea pagine, menu e impostazioni di
  partenza, con i blocchi nativi di Gutenberg.
- PHPCS con i WordPress Coding Standards, Playwright con gli
  screenshot delle pagine a 390, 820 e 1280 px, GitHub Actions che
  rilancia tutto a ogni pull request.
- Un CLAUDE.md (AGENTS.md se sei Codex) con i comandi per avviare,
  controllare e fermare tutto.

Metodo
- Tu pianifichi e dividi il lavoro in fasi piccole; non scrivi codice.
  Mostrami il piano e aspetta il mio ok prima di partire.
- Per ogni fase un subagente sviluppatore (modello Sonnet) lavora su
  un branch nuovo.
- Un subagente revisore (modello Opus), che non ha scritto il codice e
  non può modificare i file, lancia controlli, test e screenshot e
  confronta il risultato con il piano. Se è tutto verde apre la pull
  request, altrimenti rimanda la lista dei problemi allo sviluppatore.
  Dopo tre giri senza successo fermati e chiedimi.
- Ogni pull request ha un riassunto in parole semplici: cosa cambia
  sul sito e cosa devo guardare. Il merge lo faccio io.
- Nessuna password o chiave nei file: se ne servono, chiedimele.

Prima di dire «fatto» verifica che
1. il sito parta con npx wp-env start e risponda su localhost:8888;
2. lo script ricrei le pagine da zero su un ambiente pulito;
3. controlli, test e GitHub Actions siano verdi;
4. gli screenshot non mostrino testi tagliati o elementi sovrapposti.
Poi scrivimi cosa hai fatto e cosa resta aperto.

Le prime righe sono lì per te. «Non sono uno sviluppatore» cambia il modo in cui l’agente ti parla, e «aspetta il mio ok» ti lascia il controllo su cosa si installa sul tuo computer. Il resto del prompt ha tre parti, e ognuna ha il suo perché.

• Ambiente dice all’agente dove lavorare e cosa preparare: il sito sul tuo computer, il progetto su GitHub, i controlli automatici e il file di istruzioni per le volte successive. È la parte più tecnica, ed è proprio quella che non devi saper fare: la costruisce l’agente, e tu ne leggi solo il riassunto finale.
• Metodo decide chi fa cosa: il principale pianifica e ti mostra il piano, lo sviluppatore scrive, il revisore controlla senza poter correggere, e l’approvazione finale resta tua. La riga sui riassunti in parole semplici rende le richieste di approvazione leggibili anche se non hai mai visto una riga di codice.
• Le verifiche finali fanno la differenza più grande. Senza una lista l’agente dice «fatto» quando ha scritto i file; con la lista dice «fatto» quando il sito parte, si ricostruisce da zero e i controlli sono verdi, che è tutta un’altra cosa.

Se usi Codex, al posto di Sonnet scrivi Terra e al posto di Opus scrivi Sol, e apri la sessione con Sol. È lo stesso principio che racconto nell’articolo sugli harness per agenti AI: il modello è sempre quello, ma l’ambiente in cui lavora e i controlli che gli dai decidono la qualità del risultato.

Rispetto ai tutorial che promettono di creare un sito WordPress in pochi minuti, questo prompt cambia poco in lunghezza e moltissimo nelle conseguenze. Non hai installato niente a mano, non hai scritto una riga di codice e non hai imparato Git: hai solo detto all’agente dove lavorare e come controllarsi. E se a metà lavoro cambi idea sulla palette, lo chiedi in chat come prima, ma la modifica passa dal revisore e arriva a te come richiesta di approvazione.

Dal computer al sito del cliente

Finito di creare un sito WordPress in locale, al primo lancio si porta online tutto; da lì in poi i contenuti li gestisce il cliente sul sito, e il codice arriva solo con una versione controllata.

Quando hai finito di creare un sito WordPress e il cliente l’ha approvato, il primo lancio è una migrazione completa: database, immagini, tema e plugin vanno sullo spazio online del cliente, con gli indirizzi aggiornati da localhost, il nome con cui il computer chiama sé stesso, al dominio vero. Si fa con WP-CLI o con un plugin di migrazione; in tutti e due i casi l’agente può preparare la procedura e la lista dei controlli, ma il pulsante lo premi tu.

Dopo il lancio le strade si dividono. I contenuti diventano del cliente, che li modifica sul sito come in qualunque sito WordPress, con i blocchi nativi che conosce. Il codice, cioè tema, plugin su misura e stili del theme.json, continua a nascere in locale e arriva online solo come versione numerata e impacchettata: le procedure automatiche di GitHub rilanciano tutti i controlli, preparano il pacchetto e il sito lo installa. Il pacchetto lo prepara un computer pulito, non il tuo portatile con i suoi file dimenticati, e se un test fallisce la nuova versione semplicemente non esiste.

Per gli aggiornamenti c’è un meccanismo di WordPress che pochi usano: con una riga nell’intestazione un plugin o un tema su misura si aggiorna dalla bacheca come quelli di wordpress.org, prendendo le nuove versioni da GitHub. Su Book a Call lo faccio con la libreria Plugin Update Checker: al cliente, o a te, basta premere «Aggiorna ora». Le nuove sezioni del sito, quelle che toccano struttura e codice, si preparano di nuovo in locale e seguono la stessa strada.

Prima il cantiere, poi l’inaugurazione

Creare un sito WordPress con Claude o ChatGPT è una bella comodità; farlo in locale, con GitHub, test e subagenti, è quello che la trasforma in un metodo di lavoro.

Nessuno degli strumenti di cui ho parlato è nuovo: wp-env, Git, i test, WP-CLI e i controlli automatici esistono da anni, e i subagenti sono solo il modo più recente di dividersi il lavoro. La novità è che oggi, per creare un sito WordPress con questo metodo, non devi saperli usare per averli: li prepara l’agente, partendo da un prompt di una pagina, e tu tieni il ruolo che conta, cioè decidere cosa va online.

Non serve fare tutto subito: comincia dal sito sul tuo computer e da GitHub, aggiungi i controlli e il revisore al secondo sito, e gli aggiornamenti dalla bacheca quando hai un cliente da seguire nel tempo.

Per approfondire parti dalla documentazione di wp-env, dalle best practice del manuale dei plugin e dalla pagina sui subagenti di Claude Code; se vuoi un esempio completo, il progetto di Book a Call ha ambiente, controlli, test e procedure automatiche già configurati, e nella pagina dei miei plugin WordPress trovi gli altri. Se invece vuoi impostare questo workflow nel tuo studio o nella tua agenzia, possiamo parlarne in una call conoscitiva.

E tu dove fai lavorare il tuo agente: sul sito online o in locale? Raccontamelo nei commenti, e se hai un collega che ha appena incollato la password di amministratore del sito di un cliente in una chat, mandagli questo articolo prima del prossimo «ops».

FAQ: creare un sito WordPress con l’AI