Come ho collegato un agente AI al mio blog WordPress (esperimento reale)

Esperimento reale, fatto oggi: un agente AI in esecuzione su un VPS che crea bozze e pubblica articoli direttamente su WordPress tramite API.

1) Introduzione

L’idea è semplice: se un agente AI può scrivere contenuti utili (o aiutarti a scriverli), perché non permettergli anche di inserirli automaticamente nel CMS?

Il mio obiettivo in questo setup era pratico: collegare un agente OpenClaw (in esecuzione su un VPS) al mio blog WordPress, in modo che possa:

• creare articoli in bozza (modalità sicura);
• quando richiesto, pubblicare un post;
• caricare immagini nella libreria media e, volendo, impostarle come immagine in evidenza (featured image).

Risultato: funziona. E soprattutto è replicabile senza magie, usando strumenti standard di WordPress.

Come ho fatto (senza essere uno sviluppatore)

Una cosa importante da chiarire: io non sono uno sviluppatore e non scrivo codice professionalmente.

Tutto il processo che ha portato a questo risultato è stato fatto con l’aiuto dell’intelligenza artificiale.

In pratica ho utilizzato:

• ChatGPT Plus
• Atlas, il browser AI integrato
• il mio VPS con OpenClaw

ChatGPT mi ha guidato passo dopo passo nelle operazioni tecniche: dalla configurazione delle API di WordPress alla creazione delle skill necessarie per permettere all’agente di pubblicare contenuti.

Io mi sono limitato a:

• spiegare cosa volevo ottenere
• seguire le indicazioni tecniche
• testare i risultati

Il codice, le richieste HTTP e la struttura delle integrazioni sono stati generati e adattati con l’aiuto dell’AI.

Questo esperimento dimostra che oggi anche chi non è uno sviluppatore può costruire sistemi di automazione avanzati collaborando con modelli di intelligenza artificiale.

2) Setup tecnico

Il contesto in cui ho fatto girare l’esperimento:

• VPS Hostinger
• Ubuntu
• Docker per tenere l’ambiente pulito e riproducibile
• OpenClaw agent come “cervello operativo” (scrive, decide, esegue script)
• Sito WordPress come destinazione di pubblicazione

La parte importante qui non è la marca del VPS: è il fatto che l’agente vive su una macchina sempre accesa, con accesso alla rete, e può eseguire azioni quando glielo chiedi (o quando un’automazione lo attiva).

3) Collegamento tramite WordPress REST API

WordPress espone una REST API ufficiale. Per i post, l’endpoint principale è:

POST https://www.alessandrofranzoni.com/wp-json/wp/v2/posts

Con una chiamata POST puoi creare un post passando un body JSON come questo:

{
  "title": "Titolo",
  "content": "Contenuto (HTML)",
  "status": "draft"
}

Il punto critico è l’autenticazione. In questo setup ho usato una soluzione nativa e molto pratica: Application Password.

• Crei (o usi) un utente WordPress.
• Generi una Application Password dal profilo utente.
• Autentichi con Basic Authentication, cioè un header del tipo:

Authorization: Basic BASE64(username:application_password)

Questo approccio ha due vantaggi enormi rispetto a “soluzioni creative”:

• è ufficiale lato WordPress (non serve un plugin strano);
• l’Application Password è revocabile in qualsiasi momento, senza toccare la password principale.

4) Creazione della skill wordpress-publish

Per rendere il flusso riutilizzabile ho creato una skill (chiamata wordpress-publish) che incapsula la logica di pubblicazione.

In pratica la skill fornisce uno script che:

• accetta input title e content (e opzionalmente media_id);
• costruisce la request HTTP verso /wp-json/wp/v2/posts;
• invia il JSON con status (di default bozza, ma può pubblicare);
• se c’è media_id, aggiunge featured_media per impostare l’immagine in evidenza.

Nota pratica: per articoli lunghi è comodo passare il contenuto da file (ad esempio --content-file), così eviti problemi di quoting nel terminale.

5) Test di pubblicazione (draft + publish)

Il test reale si è svolto in due step (esattamente come farei in produzione):

• Step 1: bozza — l’agente crea un post in stato draft. Questo è il “paracadute”: puoi verificare contenuti e formattazione prima che qualcosa vada online.
• Step 2: pubblicazione — l’agente crea (o aggiorna) un post con stato publish, rendendolo visibile pubblicamente.

In termini di controllo, questa distinzione è fondamentale: il default dovrebbe essere sempre bozza, e la pubblicazione dovrebbe richiedere un’azione esplicita (o una regola molto chiara).

6) Upload immagini con /wp-json/wp/v2/media

Per caricare immagini nella libreria media l’endpoint è:

POST https://www.alessandrofranzoni.com/wp-json/wp/v2/media

Qui non mandi JSON: mandi il binario dell’immagine con header tipici come:

• Content-Type: image/jpeg (o png/webp…)
• Content-Disposition: attachment; filename="nomefile.jpg"
• Authorization: Basic ...

La skill wordpress-upload-image che ho preparato fa proprio questo:

1. scarica l’immagine da un image_url pubblico;
2. la carica su WordPress;
3. ritorna media_id e source_url.

A quel punto puoi usare media_id dentro wordpress-publish per impostare featured_media e avere un post completo (testo + immagine in evidenza).

7) Possibili applicazioni

Collegare un agente AI al CMS non è “solo un trick”. È un mattoncino che abilita automazioni interessanti, soprattutto se lo fai in modo controllato (bozze, revisione, log).

• SEO blogging: generazione di bozze strutturate (titolo, H2, FAQ), poi revisione umana e pubblicazione.
• Content pipeline: da idea → outline → articolo → immagini → upload media → post in bozza, tutto tracciato.
• Workflow di publishing con AI: programmazione editoriale (anche con trigger), ripubblicazioni, aggiornamenti di pagine “evergreen”.

La parte più importante, però, è la governance: permessi minimi, credenziali revocabili, e una regola semplice: l’automazione accelera, ma non deve togliere controllo.

Conclusione

In questo esperimento ho collegato un agente OpenClaw su VPS a WordPress con la REST API, usando Application Password e Basic Auth. Il risultato è un flusso concreto: l’agente può creare bozze, pubblicare quando richiesto e caricare immagini nella media library.

Il prossimo passo “serio” è rendere tutto ancora più robusto: separare l’utente WordPress dedicato, limitare le capability, e costruire una pipeline che pubblichi solo dopo una tua approvazione (o dopo test automatici di qualità). Ma già così, la base è solida.