Codice generato con l’AI dentro WordPress: come lo ospitiamo senza rompere il sito

In sintesi: capita sempre più spesso che un cliente con una buona dimestichezza nell’uso dell’AI voglia pubblicare da solo pagine costruite con HTML, CSS e JavaScript generati dall’intelligenza artificiale, non semplice testo. La tentazione è dargli una casella dove incollare il codice e chiudere la questione. Ma il lavoro serio non è generare quel codice: lo fa l’AI in pochi secondi. Il lavoro serio è costruire il contenitore che lo ospita senza mettere a rischio il sito. In questo pezzo raccontiamo come lo facciamo: un template dedicato, le regole di generazione scritte dentro il campo stesso, un disclaimer per chi naviga e una scadenza automatica che si porta dietro conseguenze che quasi nessuno prevede.

Qualche tempo fa ci siamo trovati davanti a una richiesta che oggi torna con una certa regolarità. Un cliente con una buona dimestichezza nell’uso dell’AI voleva pubblicare in autonomia delle pagine a tempo: promozioni, annunci, contenuti legati a una data che dopo quella data non servono più. Fin qui niente di strano. La novità era il come: quelle pagine le voleva generare con l’AI, chiedendo a un modello di produrre l’intero blocco di markup, gli stili e l’eventuale interattività, per poi caricarlo sul sito senza passare da noi ogni volta.

È una richiesta legittima, e in molti casi anche sensata. Ma tra “ho il codice pronto” e “il codice è online e non fa danni” c’è una distanza che l’entusiasmo per l’AI tende a nascondere. Quella distanza è esattamente il nostro mestiere.

Il problema vero non è generare, è ospitare

Quasi tutto il discorso pubblico sull’AI applicata ai siti web guarda al momento della generazione: quale strumento usare, quanto è bravo, quanto codice riesce a produrre. È la parte visibile e spettacolare. Ma è anche la parte che, ormai, costa meno fatica di tutte.

WordPress è nato per gestire contenuti testuali: articoli, pagine, campi strutturati. Non è pensato per prendere un blocco di HTML, CSS e JavaScript arbitrario e iniettarlo in produzione così com’è. Nel momento in cui accetti codice completo da una fonte esterna, le domande giuste diventano altre. Dove lo stampo, dentro la struttura della pagina? Come faccio in modo che gli stili e gli script non entrino in conflitto con il resto del sito? E soprattutto: cosa succede a quella pagina quando non serve più? Sono domande di architettura, non di generazione. L’AI non le pone e non le risolve. Le poniamo noi, prima che il codice tocchi il server.

Un template dedicato, non una textarea nel contenuto

La prima decisione è la più importante: isolare. Invece di lasciare che il codice generato finisca nel corpo di una pagina qualsiasi, mescolato agli altri contenuti, gli diamo un template di pagina tutto suo. Una pagina che usa quel template si comporta in modo diverso da tutte le altre, e questo ci permette di controllarne ogni aspetto.

Su quel template predisponiamo tre campi separati, uno per ciascuna delle tre cose che l’AI produce: il markup, gli stili, il codice JavaScript. Non è una scelta estetica. I tre pezzi vanno stampati in tre punti diversi del documento per funzionare correttamente. Il CSS va nell’intestazione della pagina, prima che il browser inizi a disegnare, così gli stili sono già pronti quando compare il contenuto. Il markup va nel corpo. Il JavaScript va in fondo, subito prima della chiusura della pagina, quando il contenuto a cui deve agganciarsi esiste già nel documento. Tenere i tre campi separati significa poterli collocare ognuno al posto giusto, invece di ricevere un unico blocco confuso in cui stili e script sono annegati nell’HTML.

Sullo stesso template gestiamo anche un dettaglio apparentemente minore ma utile: per queste pagine, spesso pensate come landing autonome, diamo la possibilità di mostrare l’intestazione completa del sito oppure una versione ridotta con il solo logo, a seconda che la pagina debba vivere dentro la navigazione del sito o funzionare come atterraggio isolato di una campagna. Il piè di pagina resta invariato, perché lì vivono informazioni che servono sempre. Tutto questo lavoro poggia su WordPress e sulla nostra infrastruttura Flying, il tema custom con cui costruiamo i siti dei nostri clienti.

Il contratto di generazione: le regole vivono dentro il campo

Ecco il punto che raramente si trova scritto da qualche parte. Se dai a qualcuno tre caselle vuote in cui incollare codice generato dall’AI, otterrai codice che non combacia: classi CSS che non trovano nessun elemento, script che cercano selettori inesistenti, tag di apertura e chiusura di troppo. Non perché l’AI sia scarsa, ma perché nessuno le ha detto in che contesto quel codice andrà a vivere.

Per questo le istruzioni di generazione le abbiamo scritte dentro l’help di ciascun campo. Chi deve produrre il codice trova, proprio lì dove serve, il promemoria di cosa chiedere al modello: genera solo il markup che va dentro il corpo della pagina, senza tag di intestazione o di apertura del documento; tieni gli stili e gli script fuori dall’HTML, nei loro campi dedicati; usa gli stessi nomi di classi e identificatori in tutti e tre i campi, perché devono combaciare uno a uno; scrivi il JavaScript sapendo che girerà quando il contenuto è già presente, quindi senza bisogno di avvolgerlo in attese di caricamento del documento. E, trasversalmente, la regola che conta più di tutte: i tre campi vanno generati come un pacchetto unico e coerente nella stessa richiesta, non in tre conversazioni separate, altrimenti i selettori non si parlano tra loro.

Il campo, insomma, non è una scatola vuota. È un’interfaccia che insegna come va usata. È lo stesso principio con cui progettiamo i pannelli di gestione per i nostri clienti: dare autonomia senza rinunciare al controllo, un equilibrio su cui ragioniamo spesso, per esempio quando scegliamo gli strumenti che permettono al cliente di gestire i propri form senza rompere nulla.

Cosa vuol dire davvero “stampato senza sanitizzazione”

Arriviamo alla parte che ribalta l’intuizione comune. Quel codice viene stampato in pagina tale e quale, senza filtri automatici che lo ripuliscano. In gergo si dice “senza sanitizzazione”, e la reazione istintiva è pensare che sia una leggerezza. È il contrario: è una scelta consapevole, possibile solo perché il codice arriva da un cliente di cui ci fidiamo, ed è il codice suo. Ma proprio perché non c’è nessun filtro, l’unica barriera reale diventa il controllo umano prima di salvare. E qui c’è un punto delicato: saper usare bene l’AI e saper verificare il codice che l’AI produce non sono la stessa competenza. La dimestichezza con il prompt non garantisce l’occhio critico sull’output, ed è proprio per questo che la revisione non può restare un gesto implicito. Non un controllo implicito, dato per scontato. Un controllo scritto, esplicito, con una lista di cose da verificare a colpo d’occhio: nessuna chiamata a script o domini esterni non richiesti, nessun codice offuscato o illeggibile, nessuna funzione che esegue stringhe come fossero comandi, nessuna credenziale o chiave lasciata nel codice, nessuna raccolta di dati degli utenti che non sia stata dichiarata. “Senza sanitizzazione” non significa “senza regole”. Significa spostare la regola dal codice alla persona, e metterla nero su bianco perché nessuno se la dimentichi. Chi vuole capire perché questo tema è delicato può partire dalla documentazione MDN sul cross-site scripting, che spiega bene cosa può fare del codice arbitrario nelle mani sbagliate.

C’è poi una seconda direzione della trasparenza, che non guarda a chi scrive ma a chi legge. Su queste pagine mostriamo un disclaimer che avverte chi naviga che il contenuto è stato generato con l’AI. Lo gestiamo con un meccanismo a due livelli: un testo unico, definito una volta sola a livello di sito e disponibile in tutte le lingue, e un interruttore per singola pagina, attivo di default. Il disclaimer compare solo se entrambe le condizioni sono vere, il che ci dà un comportamento prudente di base (tende a mostrarsi) ma la libertà di spegnerlo dove non ha senso. Non è solo cortesia verso chi legge: in alcuni casi è anche un obbligo di legge, ed è il tema della prossima sezione.

L’AI Act europeo e l’obbligo di dichiarare il contenuto generato

Dal 2 agosto 2026 si applica l’articolo dell’AI Act europeo dedicato alla trasparenza, che in alcuni casi impone di dichiarare quando un contenuto è stato generato dall’AI. Vale la pena capire i confini di questo obbligo, perché è più stretto di quanto il titolo lasci pensare, ma tocca da vicino chi pubblica pagine come quelle di cui stiamo parlando.

L’obbligo non è universale. Secondo le indicazioni della Commissione europea, l’etichettatura del testo generato dall’AI riguarda i contenuti pubblicati allo scopo di informare il pubblico su questioni di interesse pubblico: temi come politica, sanità, ambiente, sicurezza dei consumatori, sviluppi economici o scientifici rilevanti per il dibattito pubblico. Una landing promozionale a tempo, di norma, non ricade in questa categoria; una pagina che informa il pubblico su un tema di interesse collettivo, invece, sì. È una distinzione che dipende dalla finalità del contenuto, non dal fatto che sia stato generato con l’AI, ed è la prima cosa da valutare caso per caso.

C’è poi un’eccezione che ci riguarda da vicino. L’obbligo non si applica quando il contenuto è passato attraverso una revisione umana o un controllo editoriale sostanziale, con una persona che ne detiene la responsabilità. E la norma è esplicita su cosa conti come revisione: non bastano controlli superficiali o puramente formali, come una correzione ortografica. Serve un esame vero della sostanza del contenuto, da parte di chi ha le competenze per valutarlo. È esattamente il recinto che abbiamo descritto finora: la checklist di sicurezza e il controllo umano prima della pubblicazione sono la revisione sostanziale di cui parla il legislatore. In altre parole, l’impalcatura che avevamo costruito per non rompere il sito è anche ciò che determina da che parte dell’obbligo cade la pagina.

Due precisazioni utili, prima di chiudere il tema. I contenuti generati prima del 2 agosto 2026 non vanno etichettati a posteriori. E c’è una differenza tra gli obblighi di chi fornisce il modello (la marcatura tecnica, leggibile dalle macchine, dell’output) e quelli di chi pubblica il contenuto (l’etichetta visibile a chi legge): in questo scenario voi e il vostro cliente siete nella seconda categoria. Detto questo, noi teniamo il disclaimer attivo di default a prescindere, perché la trasparenza verso chi naviga è una scelta prima ancora che un adempimento. Un’ultima nota di onestà, che vale come sempre: non siamo avvocati, e il caso specifico va verificato con chi di dovere. Qui ci interessa il principio, non la consulenza legale.

Dietro le quinte: la scadenza e il suo effetto domino

La funzione che a prima vista sembra più banale è quella che racconta meglio come ragioniamo. Molte di queste pagine hanno una vita a termine: una promozione che finisce, un evento che passa. Serviva quindi poter dire a una pagina “da questa data non esisti più”, e mandare chi ci arriva altrove.

La soluzione è un reindirizzamento gestito lato server, agganciato al momento in cui WordPress decide quale template usare, cioè prima che venga prodotta qualsiasi porzione di pagina. Se la pagina è scaduta, chi la richiede viene rimandato a una destinazione scelta in fase di configurazione, con un redirect temporaneo (il codice 302, quello che dice ai browser e ai motori di ricerca “questa risorsa per ora è altrove”, senza cancellarla in modo permanente). Il confine della scadenza è preciso: scatta dalla mezzanotte del giorno indicato.

E qui arriva l’effetto domino che nessuno prevede al primo colpo. Una pagina che cambia comportamento in base alla data mal si concilia con la cache full-page, cioè il sistema che, per andare più veloce, congela una versione statica della pagina e la serve a tutti. Se quella copia congelata viene salvata prima della mezzanotte di scadenza, il sito continuerebbe a mostrare la pagina anche quando dovrebbe reindirizzare. Quindi la scadenza, da sola, ci obbliga a due decisioni in più: escludere queste pagine dalla cache full-page, e programmare l’eventuale pulizia della cache in modo coerente con il confine della mezzanotte, qualche minuto dopo lo scoccare della data. Una funzione apparentemente semplice ne trascina altre due. È il genere di ragionamento a catena che distingue una pagina che funziona per caso da una che funziona sempre, e che sta al centro del modo in cui trattiamo la vita di un sito dopo la messa online.

Un limite reale: la fiducia non è una funzione

Va detto con chiarezza, perché essere onesti sui limiti è parte del nostro modo di lavorare. Tutta questa impalcatura non elimina il rischio. Lo sposta e lo rende gestibile, ma non lo azzera. Se il cliente incolla del codice sbagliato o dannoso e salta la lista di controlli, il sito lo eseguirà comunque, perché è costruito apposta per non filtrare nulla.

Questo approccio ha senso solo con clienti di cui ci fidiamo, e va detto con onestà quanto la faccenda sia delicata: come abbiamo visto, saper usare l’AI non coincide con il saper leggere e giudicare il codice che produce. La fiducia, in questo schema, non è una funzione che possiamo programmare: è un presupposto, e va calibrata sul singolo cliente e sulla sua reale capacità di validare quello che pubblica. Preferiamo dirlo, invece di far finta che il template sia a prova di tutto. Per progetti dove quella fiducia non c’è, o dove il rischio non è accettabile, la risposta giusta è diversa: un presidio più stretto, dove il codice passa da noi, dentro un servizio di manutenzione e sicurezza che se ne assume la responsabilità.

Da dove iniziare

Isola il codice generato dall’AI in un template dedicato, con campi separati per markup, stili e script. Non lasciarlo finire nel contenuto di una pagina qualsiasi: la separazione è ciò che ti permette di controllare dove e come ogni pezzo viene eseguito.

Scrivi le regole di generazione dentro l’interfaccia stessa, non in un documento a parte che nessuno aprirà. Il campo deve dire a chi lo usa cosa chiedere all’AI, così il codice che arriva è già compatibile con il contesto in cui vivrà.

Decidi chi valida prima della pubblicazione, e con quale lista di controlli. Se il codice entra senza filtri automatici, l’occhio umano è l’unica barriera: rendila esplicita, non lasciarla al buonsenso del momento.

Dichiara a chi naviga che il contenuto è generato con l’AI, sia per trasparenza sia perché in certi casi la normativa europea lo richiede. Un interruttore attivo di default è il modo più semplice per non dimenticartene.

Pensa al ciclo di vita della pagina prima di metterla online: quando scade, dove reindirizza, come si comporta la cache. Sono le domande che l’AI non ti pone e che fanno la differenza tra una pagina che regge e una che si rompe in silenzio.

Se ti serve una mano

Se stai ragionando su come dare ai tuoi clienti, o a te stesso, la libertà di pubblicare contenuti generati con l’AI dentro WordPress senza trasformare il sito in un campo minato, possiamo parlarne. In PaperPlane offriamo una consulenza gratuita di trenta minuti in cui guardiamo insieme il tuo caso: che tipo di pagine ti servono, chi le produrrà, quali controlli ha senso mettere in mezzo. Senza vendere una soluzione preconfezionata: ci interessa capire se questo approccio è quello giusto per te, o se te ne serve un altro.