Aggiungi come fonte preferita su Google
I siti WordPress sono sempre stati progettati pensando alle persone. Quando qualcuno visita una pagina, gira per il sito, compila un modulo, clicca su un pulsante o crea un account. Il browser è il cuore di questa esperienza, ed è per questo che gli sviluppatori costruiscono il sito attorno alle azioni che le persone compiono sullo schermo.
Gli agenti di intelligenza artificiale non funzionano sempre in questo modo; possono ottenere informazioni, richiamare funzioni e svolgere attività senza dover visitare una pagina o aprire wp-admin. WordPress si sta adeguando utilizzando strumenti come l’API Abilities e l’MCP Adapter, che forniscono al software mezzi più diretti per individuare e utilizzare le funzionalità del sito.
Man mano che queste interazioni diventano più comuni, gli sviluppatori devono tenere conto di un altro tipo di utente. Sviluppare WordPress sia per le persone che per gli agenti AI cambia il modo in cui pensi alle API, alle autorizzazioni, all’autenticazione, alle prestazioni e a cosa succede quando qualcosa va storto.
Gli agenti AI non usano WordPress come fanno le persone
Le persone sono piuttosto brave a capire le cose man mano che procedono. Possono dare un’occhiata a un menu, cogliere gli indizi visivi, rileggere una richiesta o provare un altro pulsante quando qualcosa non funziona al primo tentativo.
Gli agenti non hanno la stessa flessibilità. Hanno bisogno di un percorso più chiaro, con azioni definite, input strutturati, un modo per autenticarsi e risposte che possano interpretare in modo affidabile.
Questo cambia alcuni dei presupposti alla base dell’architettura di WordPress:
| Interazione incentrata sull’utente | Interazione a misura di agente |
| Menu di navigazione e pulsanti | Funzionalità individuabili |
| Moduli | Input strutturati e API |
| Schermate di accesso | Autenticazione programmatica |
| Feedback visivo | Risposte e errori strutturati |
| Visualizzazioni di pagina e sessioni | Chiamate API ed esecuzioni di strumenti |
È importante anche distinguere gli agenti dai crawler. I crawler si occupano principalmente di recuperare o indicizzare informazioni. Gli agenti possono invece andare oltre e agire per conto di un utente. Questo può significare controllare le disponibilità, recuperare informazioni sull’account, creare una bozza, inviare dati o attivare un flusso di lavoro.
Quando un software va oltre la semplice lettura dei contenuti, l’architettura deve tenere conto di autorizzazioni, autenticazione, stati di errore e delle conseguenze di ogni azione. Un sito che funziona bene per gli agenti AI, quindi, non ha bisogno solo di contenuti facili da trovare per le macchine. Ha bisogno di modalità chiaramente definite che permettano alle macchine di interagire con WordPress in modo sicuro e affidabile.
Progetta funzionalità, non solo pagine
Il web design tradizionale parte dal percorso dell’utente. Qualcuno arriva su una pagina, clicca qua e là, compila un modulo e arriva a una schermata di conferma.
Un agente AI potrebbe saltare completamente quel percorso. Non ha bisogno di vedere l’interfaccia se può accedere direttamente alla funzione sottostante.
Quella funzione potrebbe consistere nel cercare nella documentazione, controllare le giacenze, inviare una richiesta di preventivo o creare una bozza. Invece di chiedere a un agente di riprodurre gli stessi passaggi che una persona compie sullo schermo, gli sviluppatori possono rendere accessibili quelle azioni in un formato che il software possa comprendere e utilizzare.
L’API Abilities di WordPress offre agli sviluppatori un modo più pulito per rendere accessibili queste funzionalità. Invece di far funzionare uno strumento esterno attraverso una pagina o estrarre informazioni dall’HTML, puoi definire direttamente un’azione, insieme ai dati di cui ha bisogno, a cosa restituisce e a chi può usarla.
Questo non significa che ogni pulsante debba avere un equivalente accessibile alle macchine. La domanda più utile è: quali funzioni vale la pena rendere accessibili, chi dovrebbe poterle usare e quali limiti dovrebbero essere applicati.
Per gli sviluppatori, questo aggiunge una nuova domanda al processo di pianificazione: cosa può permettere in sicurezza questo sito alle persone e alle macchine di fare?
L’autenticazione e le autorizzazioni diventano più importanti
Una volta che un agente AI può agire all’interno di WordPress, la domanda non è più “Può connettersi?” ma “Cosa dovrebbe effettivamente essere autorizzato a fare?”
Questa distinzione è importante, dato che sempre più software opera con le proprie credenziali e autorizzazioni. Il rapporto “2025 Identity Security Landscape” di CyberArk ha rilevato che il 68% delle organizzazioni non dispone di controlli di sicurezza delle identità per l’AI. Dare accesso a un agente è facile. Limitare quell’accesso al compito specifico richiede invece una pianificazione più accurata.
Per ogni funzionalità rivolta alle macchine, gli sviluppatori devono rispondere ad alcune domande fondamentali:
- Chi sta effettuando la richiesta?
- Per conto di chi sta agendo?
- Quali informazioni può leggere?
- Cosa può modificare?
- Quali azioni richiedono un’approvazione aggiuntiva?
Limita l’accesso dell’agente al compito che sta svolgendo. Uno strumento che cerca nella documentazione non ha motivo di modificare i post, e uno che scrive bozze non deve per forza pubblicarle. Quando si tratta di cose come cambiare account, cancellare contenuti o gestire pagamenti, la soglia deve essere molto più alta.
L’API Abilities di WordPress aiuta gli sviluppatori a definire questi limiti. Ogni abilità può includere i propri controlli di autorizzazione, insieme a input e output definiti. Questo ti dà più controllo rispetto al fornire le credenziali di amministratore a un servizio esterno e fidarti che ne usi solo ciò di cui ha bisogno.
Gran parte di questo si riduce a normali pratiche di sicurezza. Qualsiasi cosa invii un agente deve comunque essere verificata prima che WordPress agisca di conseguenza. Le credenziali non dovrebbero circolare in finestre di dialogo, codice front-end o log. Se l’agente sta per fare qualcosa di costoso o difficile da annullare, è il momento giusto per fermarsi e chiedere l’approvazione di una persona in carne e ossa.
Il fatto di dover svolgere un compito non dovrebbe dare a un agente un accesso illimitato a WordPress. Concedigli solo i permessi necessari per gestire l’attività in questione, e nient’altro.
Gli utenti automatici cambiano i requisiti di prestazione
I visitatori umani navigano a un ritmo naturale. Caricano una pagina, la leggono, cliccano su qualcosa e aspettano la risposta successiva. Gli agenti AI possono muoversi molto più velocemente. Possono inviare diverse richieste in pochi secondi mentre raccolgono informazioni sul contesto, richiamano strumenti, confrontano risultati e portano a termine un’attività in più fasi.
Le normali regole di sicurezza non spariscono solo perché c’è di mezzo un agente. WordPress deve comunque controllare ciò che entra, e le credenziali devono rimanere fuori dalle finestre di dialogo, dal codice front-end e dai log. Se il flusso di lavoro arriva a un punto in cui può apportare una modifica costosa o difficile da annullare, è lì che un essere umano dovrebbe intervenire prima che prosegua.
I flussi di lavoro automatizzati possono mettere a dura prova WordPress molto più di una persona che clicca qua e là sul sito, quindi conviene ridurre il lavoro superfluo. Questo potrebbe significare combinare le chiamate API, memorizzare nella cache le risposte in sola lettura, limitare il numero di richieste eseguite contemporaneamente o spostare i processi più lenti in background. Anche i limiti di frequenza e i timeout ragionevoli possono impedire che un flusso di lavoro automatizzato blocchi le risorse per tutti gli altri.
L’obiettivo è evitare che WordPress debba fare più lavoro di quanto l’attività richieda effettivamente. Se un agente ha bisogno di tre informazioni, per esempio, un endpoint ben progettato potrebbe essere meglio di diverse richieste separate, ognuna delle quali fa scattare un’operazione sul database.
I timeout sono complicati perché la richiesta potrebbe essere andata a buon fine anche se l’agente non riceve mai la risposta. Se invia di nuovo la stessa richiesta, questo potrebbe non avere importanza per una semplice ricerca. È molto più importante se la prima richiesta ha creato o modificato qualcosa. Prima di riprovare, l’agente deve avere un modo per verificare se l’operazione è già stata eseguita.
Le esigenze dell’infrastruttura AI più generali sono già ben documentate. Il punto chiave è più specifico: la pianificazione delle prestazioni non può più dare per scontato che ogni interazione avvenga alla velocità umana.
Man mano che gli agenti diventano un altro tipo di utente di WordPress, l’infrastruttura deve gestire picchi di attività guidata dalle macchine senza che quei flussi di lavoro rallentino le persone che usano il sito nello stesso momento.
Gli agenti hanno bisogno di risposte prevedibili e flussi di lavoro osservabili
Gli agenti devono avere un’idea chiara di cosa sia successo dopo ogni richiesta. Se la risposta è vaga, si ritrovano a chiedersi se l’operazione sia ancora in corso, sia fallita del tutto o sia terminata senza inviare una risposta.
I flussi di lavoro più lunghi rendono più difficile riprendersi da questa situazione. Se una fase restituisce un risultato poco chiaro, l’agente potrebbe ripeterla, saltare avanti o continuare prima che l’attività precedente sia effettivamente completata.
Non è sempre un problema. Recuperare la stessa documentazione due volte è per lo più innocuo. Creare lo stesso ordine due volte non lo è. Lo stesso vale per la pubblicazione o l’eliminazione di contenuti. L’operatore ha bisogno di un modo per vedere cosa è già successo prima di inviare nuovamente la richiesta.
L’API di Kinsta lo fa per alcune azioni che richiedono più tempo tramite un ID operazione. Invece di tenere aperta la richiesta, restituisce un ID che il software può controllare in seguito per vedere se il processo è ancora in esecuzione o è terminato.
Hai anche bisogno di visibilità sufficiente per capire cosa è andato storto quando un flusso di lavoro si interrompe. Un messaggio di errore finale potrebbe non dirti molto. Potresti dover capire quale richiesta si è bloccata, se WordPress ha chiamato un altro servizio, cosa è successo nel database o se l’agente ha inviato la stessa richiesta più di una volta.
L’APM di Kinsta e i log del server possono aiutarti a tracciare quell’attività, mentre l’ambiente di staging offre ai team un luogo più sicuro per testare i flussi di lavoro guidati dagli agenti prima che possano influire sui dati di produzione.
Con un visitatore in carne e ossa, un flusso di lavoro interrotto spesso diventa subito evidente. Qualcuno vede l’errore e lo segnala. Con un agente, il malfunzionamento può rimanere nascosto all’interno di diverse fasi automatizzate. Risposte prevedibili e una forte osservabilità rendono questi problemi molto più facili da individuare e risolvere.
Anche il livello di hosting può avere un’interfaccia per le macchine
L’architettura pronta per gli agenti non si ferma a WordPress stesso. Considera due livelli rivolti alle macchine: il sito e l’infrastruttura che lo supporta.
A livello di WordPress, l’API Abilities e l’adattatore MCP possono rendere accessibili contenuti e funzionalità a strumenti esterni. Un agente potrebbe recuperare dati, creare contenuti o attivare il flusso di lavoro di un plugin. A livello di hosting, le API possono rendere accessibili attività operative che altrimenti richiederebbero l’intervento di qualcuno tramite una dashboard.
L’API di Kinsta offre agli sviluppatori l’accesso programmatico ad attività come il recupero di informazioni sul sito e sull’ambiente, la gestione dei domini, la gestione della cache e la gestione di altre operazioni di hosting. Questo apre la strada a flussi di lavoro che vanno oltre l’applicazione WordPress stessa. Uno strumento può controllare un ambiente prima di eseguire un’azione, attivare un’attività di infrastruttura o integrare informazioni in un processo automatizzato più ampio.
Kinsta ha anche realizzato un server MCP basato sulla propria API, che permette a un client AI artificiale di utilizzare alcune funzioni di hosting come strumenti. Ciò può includere l’ispezione degli ambienti, lo svuotamento della cache, la clonazione di un sito o il controllo delle informazioni sui plugin senza che qualcuno debba cliccare su MyKinsta per ogni singolo passaggio.
Un agente può fare molto senza avere accesso all’intero account di hosting. Se deve solo svuotare la cache, controllare un ambiente o estrarre i dati dei plugin, questo è tutto ciò a cui dovrebbe poter accedere. Non c’è alcun vantaggio nel concedergli permessi più ampi solo perché esiste la connessione.
MyKinsta continua a occuparsi della parte “umana” delle cose, come controllare le impostazioni, risolvere i problemi e gestire i siti giorno per giorno. Le API sono utili quando quelle stesse attività di hosting devono collegarsi a qualcos’altro, che si tratti di un processo di distribuzione, uno strumento interno, un flusso di lavoro dell’agenzia o un sistema di IA.
Le agenzie dovrebbero includere la predisposizione per gli agenti nelle revisioni dell’architettura
Non devi per forza inserire agenti AI o MCP in ogni progetto WordPress in questo momento. La mossa più intelligente è evitare scelte che rendano difficile aggiungere quei flussi di lavoro in un secondo momento, soprattutto se un cliente torna a richiederli dopo che il sito è già stato realizzato.
Per una nuova realizzazione o una revisione importante, vale la pena chiedersi:
- Quali attività i clienti o i dipendenti potrebbero eventualmente affidare a un agente?
- A quali dati o funzioni del sito dovrebbe poter accedere il software?
- Quali azioni dovrebbero sempre richiedere l’approvazione di una persona?
- Come farà l’agente a dimostrare chi è e cosa è autorizzato a fare?
- Cosa succede se il traffico automatizzato aumenta?
- Come farà il team a individuare e risolvere i problemi quando un flusso di lavoro si interrompe?
Le risposte a queste domande possono influenzare ogni aspetto, dalla scelta dei plugin e la progettazione delle API fino alle autorizzazioni e all’hosting. Influiscono anche sulle decisioni più piccole. Un flusso di lavoro nascosto in una schermata di amministrazione a cui si accede solo una volta è più difficile da riutilizzare in seguito rispetto a una funzione che un altro sistema può richiamare direttamente.
Il caso di studio di Sod mostra come questo tipo di flessibilità possa tradursi nella pratica. L’agenzia gestisce più di 400 siti WordPress e usa l’API di Kinsta per automatizzare attività che altrimenti richiederebbero un controllo manuale.
Non si tratta di un flusso di lavoro basato su un agente AI, ma dimostra il valore di un’infrastruttura che offre al software un modo supportato per interagire con le operazioni di hosting, invece di costringere ogni attività a passare attraverso una dashboard.
Questo tipo di flessibilità diventa sempre più utile man mano che cambiano le aspettative dei clienti. Un flusso di lavoro che oggi parte come automazione interna potrebbe in seguito collegarsi a un assistente AI, a un client MCP o a un altro sistema aziendale. Se la funzione sottostante ha già un’interfaccia pulita e permessi ben definiti, aggiungere quel nuovo livello diventa molto più facile.
Lo stesso principio vale quando si pianificano gli agenti. Le agenzie non devono automatizzare ogni flusso di lavoro fin da subito. Devono evitare di costruire siti partendo dal presupposto che sarà sempre una persona a recuperare le informazioni, attivare le azioni o gestire il sistema sottostante.
Inserire la predisposizione per gli agenti nelle revisioni dell’architettura offre ai clienti più spazio per adottare nuovi flussi di lavoro in futuro senza dover ripensare il sito da zero.
Crea per le persone e per il software che agisce per loro
WordPress deve comunque funzionare innanzitutto per le persone. Pagine, moduli, navigazione e una solida esperienza utente non spariranno. Ciò che cambia è che non sono più l’unico modo in cui qualcuno, o qualcosa, potrebbe usare il sito.
Gran parte di questo lavoro sta iniziando a svolgersi senza che nessuno clicchi all’interno di WordPress. Un agente può estrarre informazioni, innescare un’azione e passare alla fase successiva in pochi secondi. Questo rende l’infrastruttura molto più importante. Gli sviluppatori devono sapere esattamente a cosa può accedere l’agente, di quanto accesso dispone, se il sito riesce a stare al passo e dove cercare quando qualcosa va storto.
Non è necessario ricostruire oggi ogni sito WordPress pensando agli agenti di AI. Ma devi smettere di dare per scontato che ogni interazione futura inizierà con una persona che apre un browser. L’hosting WordPress gestito di Kinsta offre agli sviluppatori le prestazioni, la visibilità e gli strumenti necessari per supportare sia i visitatori umani che i flussi di lavoro sempre più automatizzati.
Il tuo prossimo cliente potrebbe essere ancora un essere umano. La differenza è che un software potrebbe interagire con il tuo sito per suo conto.
Carlo è cultore appassionato di webdesign e front-end development. Gioca con WordPress da oltre 20 anni, anche in collaborazione con università ed enti educativi italiani ed europei. Su WordPress ha scritto centinaia di articoli e guide, pubblicati sia in siti web italiani e internazionali, che su riviste a stampa. Lo trovate su LinkedIn.
