WordPress 7.0 e l'AI: una forzatura? Come cambia il lavoro delle web agency

Chi si aspettava un redattore automatico nel backend è rimasto deluso, e per fortuna. Core non ha imposto nessun fornitore di AI: ha posato tre mattoni sotto il pavimento, e sono mattoni da sistemisti, non da marketing.

WP AI Client: un solo canale verso i modelli

È un'interfaccia PHP provider-agnostica: i plugin parlano con i modelli generativi senza riscrivere l'integrazione ogni volta, e il routing delle richieste lo gestisce Core. Chi sviluppa può dichiarare una preferenza di modello con using_model_preference() e costruire i prompt con WP_AI_Client_Prompt_Builder. Tradotto: il modello diventa un dettaglio di configurazione, non una scelta incisa nel codice del tema.

Abilities: il sito diventa invocabile

Le Abilities, introdotte con WordPress 6.9 e diventate anche client-side in 7.0, sono azioni registrate con schema di input e output, permessi e annotazioni: sola lettura, idempotente, distruttiva. È così che un assistente — o un workflow interno — scopre cosa il sito sa fare e lo esegue, senza un endpoint REST artigianale per ogni plugin. Sopra c'è l'adattatore MCP: strumenti come Claude, ChatGPT o Gemini possono vedere quelle azioni e richiamarle. Non è magia, è un contratto.

Connectors: dove finiscono le chiavi API

In Impostazioni → Connectors si gestiscono le connessioni ai provider: Anthropic, Google e OpenAI di default, più eventuali connettori propri. Attenzione a un dettaglio che in produzione fa la differenza: le chiavi inserite da quella schermata sono mascherate a video ma non cifrate nel database. Su un sito di produzione vanno passate da variabili d'ambiente o costanti PHP.

Il ciclo dopo un major dice sempre più cose del major stesso. Qui ha detto due cose: il core si è stabilizzato in fretta, e la sicurezza non ha aspettato i vostri piani di rilascio.

9 luglio 2026 — 7.0.1, manutenzione

Release minore con 31 bugfix distribuiti tra core, block editor e media. Niente da raccontare al cliente, tutto da mettere in pianificazione.

17 luglio 2026 — 7.0.2, la release che si è installata da sola

Release di sicurezza con una vulnerabilità critica e una alta (CVE-2026-60137 e CVE-2026-63030). WordPress.org ha forzato gli aggiornamenti automatici sulle versioni interessate, con backport su 6.9.5 e 6.8.6. Per chi gestisce un parco di cinquanta o duecento siti è il punto che fa male: un core update può partire di notte su un catalogo che nessuno ha provato in staging. Se avete ancora installazioni sotto la 6.8, quel backport non vi copre.

19 agosto 2026 — 7.1 «Mary Lou»

Meno AI da manifesto, più lavoro quotidiano: admin bar coerente in tutto il backend, visibilità responsive dei blocchi senza CSS custom, nuovo editor media con crop libero, flip e rotazione, Notes con rich text e @menzioni in qualsiasi punto del contenuto, blocchi Playlist e Tabs, API per registrare set di icone SVG. La 7.1 non contraddice la 7.0: la rende usabile da un team.

Dipende da cosa intendete per forzatura. Vale la pena separare le due cose, perché la risposta non è la stessa.

Cosa non è obbligatorio

• Nessun provider incluso. Core non spedisce un fornitore di AI: senza connettori configurati, non parte nulla.
• Funzioni opt-in. Riassunti, excerpt e testi alternativi generati vivono in gran parte tra gli esperimenti AI, da attivare a mano.
• Nessun costo nascosto. I token li paga chi collega la propria chiave. Un sito 7.x può restare muto verso i modelli e funzionare come prima.

Cosa invece subite

• La piattaforma è agent-ready. I plugin seri registreranno ability: il sito diventa comandabile dall'esterno, che vi piaccia o no.
• Il mercato si muove prima di voi. I clienti chiederanno «lo fa anche l'AI?» e i concorrenti venderanno pacchetti di contenuti automatici.
• Gli aggiornamenti forzati. La 7.0.2 è entrata in produzione senza chiedere il permesso a nessuna agenzia.

Quindi no, l'AI non è imposta. Ma il modello di responsabilità è cambiato comunque: la superficie da governare si è allargata, e l'auto-update di sicurezza ha ricordato a tutti che il tempo, su WordPress, ce l'ha chi ha staging, backup e una finestra di verifica. Gli altri lo scoprono dal ticket del cliente.

In fase di build: dal sito al sistema

Il valore si sposta dalla pagina singola all'impianto: theme.json, pattern curati, blocchi registrati in PHP, ability documentate. È così che si consegnano dieci siti coerenti senza clonare a mano il page builder. L'AI non sostituisce il design system: lo consuma. Se i pattern sono deboli, l'output generato è debole; se i permessi delle ability sono larghi, l'output diventa un danno.

In manutenzione: serve l'inventario delle ability

Il canone di manutenzione non copre più solo versioni e backup. Adesso servono risposte a domande nuove: quali plugin espongono ability, quali sono distruttive, dove stanno le chiavi API, chi può abilitare un provider. E serve un protocollo di aggiornamento scritto, perché 7.0.1 e 7.0.2 hanno mostrato che «aggiorniamo quando c'è tempo» non è una strategia.

In fase commerciale: si vende governance, non impaginazione

Generare una bozza di pagina o un alt text costa pochissimo, e il cliente lo scoprirà. Quello che non sa fare da solo è tenere insieme voce del brand, qualità, accessibilità, SEO e responsabilità. L'agenzia che vende ore di impaginazione compete con un modello linguistico. Quella che vende contenuti revisionati, workflow con approvazione, monitoraggio e hosting isolato alza il canone invece di abbassare il preventivo.

• Setup AI e permessi — configurazione connettori, chiavi fuori dal database, ruoli abilitati, elenco delle ability attive con annotazioni. Una volta, a progetto.
• QA editoriale dell'AI — revisione umana dei contenuti generati: tono, fonti, accessibilità, SEO. A volume o a canone.
• Aggiornamenti core con staging — finestra di verifica, rollback, report al cliente. È il servizio che la 7.0.2 ha reso vendibile senza dover spiegare perché serve.

Sono tre voci che il cliente capisce e che difendono il margine: nessuna delle tre è replicabile da un prompt.

• Portate il parco a 7.1 (o almeno a 7.0.2 / 6.9.5 / 6.8.6 secondo il ramo) dopo un passaggio in staging.
• Fate l'elenco dei plugin e dei temi che registrano ability, segnando quelle distruttive.
• Decidete se l'AI è accesa, per quali ruoli e su quali ambienti. Mettetelo per iscritto.
• Spostate le chiavi API fuori dal database, in variabili d'ambiente o costanti PHP.
• Verificate che backup e staging reggano un aggiornamento forzato nel fine settimana.
• Spiegate al cliente chi paga i token, chi vede i dati inviati al modello e chi risponde se online finisce una sciocchezza.

WordPress non vi sta costringendo a far scrivere i siti a un modello. Vi sta costringendo a trattare il sito come una piattaforma con azioni invocabili. È la stessa curva vista con Gutenberg, con i block theme, con WooCommerce: chi si adatta vende servizi migliori, chi aspetta che passi la moda finisce a sistemare siti che i clienti hanno già iniziato a far toccare all'AI per conto loro.

Su Host.it i siti WordPress girano su infrastruttura italiana, con backup, SSL e Application Manager per pubblicare e aggiornare senza teatro. Se gestite molti clienti, quello che fa la differenza resta banale e decisivo: staging, osservabilità e qualcuno da chiamare quando un aggiornamento di sicurezza parte di sabato notte. L'AI nel core non elimina questo bisogno: lo rende più urgente.