Il cambio di mentalità necessario è piccolo ma potente. Oggi la maggior parte dei plugin SEO fa il proprio audit chiamando Yoast o Rank Math via reflection o hook, con risultati fragili e duplicazione di logica. Con Abilities API, ogni plugin espone le proprie capacità come abilities registrate, e chiunque può chiederle via wp_get_ability() con capability check, audit log e kill switch integrati. Questo non è teorico: il Plugin Team stesso lo usa già per i triage AI del Plugin Directory 2026.

Per capire il contesto AI dell'API rimando al pattern ufficiale Plugin Team MCP + Abilities e alla preparazione alla AI-use disclosure; qui il focus è su come chiunque può adottare Abilities API anche senza una sola riga di codice AI, ottenendo vantaggi concreti in robustezza, auditabilità e interoperabilità tra plugin.

Cos'è Abilities API WordPress 6.9 in 90 secondi

Abilities API è una nuova API core di WordPress 6.9 che permette a un plugin (o al core) di registrare "abilità" (abilities) come unità discrete di funzionalità. Ogni ability ha:

• Slug univoco: seo-audit/canonical-check, security-scan/file-integrity, performance-check/db-query-time
• Capability requirements: chi può chiamarla (administrator, editor, custom role)
• Input schema: parametri accettati (post_id, capability array, scope)
• Output schema: struttura del risultato atteso
• Callback registrato: la funzione che esegue l'abilità
• Audit metadata: chi l'ha chiamata, quando, con quali parametri

A differenza degli hook tradizionali, un'ability è una funzione chiamabile esplicitamente da altro codice con un'API uniforme, non un side effect agganciato a un evento. Questo la rende perfetta per audit e check operativi, dove serve un "contratto" chiaro tra chi chiede e chi esegue.

Differenza tra Ability e Hook WordPress

Un hook tradizionale (do_action, apply_filters) è publish-subscribe: il publisher non sa chi ascolta. Un'ability è request-response: il chiamante sa esattamente cosa sta chiedendo e cosa riceverà. Questa differenza sembra sottile ma in termini di testabilità, documentazione e debug è enorme.

Differenza tra Ability e REST endpoint

Un'ability è simile a un REST endpoint ma vive nello stesso processo PHP, senza HTTP overhead. È ideale per uso server-side (WP-CLI, cron, plugin-to-plugin). Per uso client-side (JavaScript in admin) si consiglia di esporre l'ability anche via REST controller aggiuntivo.

Caso d'uso 1: audit SEO come abilities componibili

Vediamo il primo caso d'uso pratico: trasformare i 12 check SEO che ogni agenzia fa a mano (canonical, meta description, alt text, structured data, robots, sitemap, ecc.) in abilities dichiarate. Il vantaggio immediato è che qualunque plugin (Rank Math, Yoast, SEOPress) può esporre le proprie check come abilities, e i tool di audit (WooCommerce, page builder, plugin custom) possono chiamarle senza dover conoscere il plugin specifico.

Registrazione di un'ability SEO canonical-check

// registra un'ability SEO audit
add_action( 'wp_abilities_api_init', function() {
    wp_register_ability( 'seo-audit/canonical-check', array(
        'label'       => __( 'Canonical URL check', 'seo-abilities' ),
        'description' => __( 'Verifica che il post abbia un canonical URL valido', 'seo-abilities' ),
        'callback'    => 'seo_abilities_check_canonical',
        'capability'  => 'edit_posts',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'post_id' => array( 'type' => 'integer' )
            ),
            'required'   => array( 'post_id' )
        ),
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'has_canonical' => array( 'type' => 'boolean' ),
                'canonical_url' => array( 'type' => 'string' ),
                'is_self'       => array( 'type' => 'boolean' ),
                'severity'      => array( 'type' => 'string' )
            )
        )
    ) );
} );

function seo_abilities_check_canonical( $input ) {
    $post = get_post( $input['post_id'] );
    if ( ! $post ) {
        return new WP_Error( 'post_not_found', __( 'Post non trovato', 'seo-abilities' ) );
    }
    $canonical = get_permalink( $post->ID );
    return array(
        'has_canonical' => true,
        'canonical_url' => $canonical,
        'is_self'       => true,
        'severity'      => 'ok'
    );
}

Composizione di più abilities per audit completo

// chiama 5 abilities SEO in sequenza e aggrega risultati
function seo_abilities_full_audit( $post_id ) {
    $checks = array(
        'seo-audit/canonical-check',
        'seo-audit/meta-description-check',
        'seo-audit/alt-text-check',
        'seo-audit/structured-data-check',
        'seo-audit/robots-meta-check'
    );
    $report = array();
    foreach ( $checks as $slug ) {
        $ability = wp_get_ability( $slug );
        if ( $ability && current_user_can( $ability->capability ) ) {
            $report[ $slug ] = $ability->callback( array( 'post_id' => $post_id ) );
        }
    }
    return $report;
}

Vantaggio rispetto a Rank Math standalone

Rank Math ha già le proprie funzioni interne di audit, ma sono sealed. Esponendole come abilities, chiunque può scrivere un tool che le chiama via API pubblica, senza reflection. Inoltre un'agenzia può costruire un proprio tool centralizzato che gira seo-audit/full-audit su tutti i 50 siti del cliente, aggregando i risultati.

Caso d'uso 2: scan di sicurezza come abilities verificabili

Il secondo caso d'uso è la sicurezza. I plugin di sicurezza oggi fanno scan in modi molto diversi tra loro (Wordfence, Sucuri, iThemes, Solid Security), spesso con logica duplicata e audit trail frammentato. Con Abilities API possiamo standardizzare gli scan di base.

Ability file-integrity check

// ability: verifica integrità file core WordPress
add_action( 'wp_abilities_api_init', function() {
    wp_register_ability( 'security-scan/file-integrity', array(
        'label'       => __( 'File integrity check', 'security-abilities' ),
        'description' => __( 'Confronta hash dei file core con signature note', 'security-abilities' ),
        'callback'    => 'security_abilities_check_integrity',
        'capability'  => 'manage_options',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'scope' => array( 'type' => 'string', 'enum' => array( 'core', 'plugins', 'themes', 'all' ) )
            )
        ),
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'modified_files' => array( 'type' => 'array' ),
                'severity'       => array( 'type' => 'string' )
            )
        )
    ) );
} );

function security_abilities_check_integrity( $input ) {
    $scope = $input['scope'] ?? 'core';
    $modified = array();
    // logica di confronto hash semplificata
    $check_root = ABSPATH;
    $iterator = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $check_root ) );
    foreach ( $iterator as $file ) {
        if ( $file->isFile() && in_array( $file->getExtension(), array( 'php', 'js' ) ) ) {
            $hash = md5_file( $file->getPathname() );
            // confronto con signature store (in produzione: db o file firmato)
            if ( ! security_abilities_hash_known( $file->getPathname(), $hash ) ) {
                $modified[] = str_replace( ABSPATH, '', $file->getPathname() );
            }
        }
    }
    return array(
        'modified_files' => $modified,
        'severity'       => count( $modified ) > 0 ? 'high' : 'ok'
    );
}

Integrazione con WP-CLI per audit massivi

Una volta che le abilities di sicurezza sono registrate, possiamo lanciarle via WP-CLI 2026 su tutti i siti di un multisite o di una flotta gestita:

# audit sicurezza massivo via WP-CLI
wp ability run security-scan/file-integrity --scope=all --format=json
wp ability run security-scan/suspicious-patterns --format=json

Questo tipo di automazione prima richiedeva script personalizzati per ogni plugin di sicurezza; con Abilities API diventa un comando standard.

Caso d'uso 3: check di performance come abilities composite

Il terzo caso d'uso è forse il più sorprendente. I plugin di caching (WP Rocket, LiteSpeed, W3 Total Cache) oggi espongono le proprie metriche in modi proprietari. Con Abilities API possiamo esporre check di performance come abilities standard e creare dashboard cross-plugin.

Ability db-query-time check

// ability: misura tempo medio query database
add_action( 'wp_abilities_api_init', function() {
    wp_register_ability( 'performance-check/db-query-time', array(
        'label'       => __( 'Database query time', 'performance-abilities' ),
        'description' => __( 'Misura tempo medio di esecuzione query DB', 'performance-abilities' ),
        'callback'    => 'performance_abilities_check_db_time',
        'capability'  => 'manage_options',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'sample_size' => array( 'type' => 'integer', 'default' => 100 )
            )
        ),
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'avg_query_time' => array( 'type' => 'number' ),
                'slow_queries'   => array( 'type' => 'integer' ),
                'severity'       => array( 'type' => 'string' )
            )
        )
    ) );
} );

function performance_abilities_check_db_time( $input ) {
    global $wpdb;
    $sample_size = $input['sample_size'] ?? 100;
    $times = array();
    $slow = 0;
    for ( $i = 0; $i < $sample_size; $i++ ) {
        $start = microtime( true );
        $wpdb->get_results( "SELECT ID FROM {$wpdb->posts} WHERE post_status = 'publish' LIMIT 1" );
        $elapsed = microtime( true ) - $start;
        $times[] = $elapsed;
        if ( $elapsed > 0.05 ) $slow++;
    }
    $avg = array_sum( $times ) / count( $times );
    return array(
        'avg_query_time' => round( $avg * 1000, 2 ), // ms
        'slow_queries'   => $slow,
        'severity'       => $avg > 0.03 ? 'high' : ( $avg > 0.01 ? 'medium' : 'ok' )
    );
}

Dashboard cross-plugin che consuma abilities

Un'agenzia può creare un custom admin page che chiama 8-10 abilities (SEO + security + performance) e mostra un report unificato. Il vantaggio è che funziona indipendentemente da quali plugin specifici sono installati, purché espongano le abilities standard.

Capability matrix e governance delle abilities

Una delle funzionalità più potenti di Abilities API è la capability matrix: ogni ability dichiara chi può chiamarla e in quali contesti. Questo apre a scenari di governance che prima erano impossibili.

Matrice capability per ruolo

Custom role per auditor esterno

// crea custom role "site-auditor" con capability granulari
add_role( 'site_auditor', __( 'Site Auditor', 'abilities-governance' ), array(
    'read'                   => true,
    'run_seo_audit'          => true,
    'run_security_scan'      => true,
    'run_performance_check'  => true,
    'edit_posts'             => false
) );

Con questa capability matrix, un'agenzia può dare a un consulente esterno un accesso limitato in sola lettura per auditare 50 siti senza dargli le chiavi del kingdom.

Audit log e tracciabilità

Abilities API prevede un sistema di audit log integrato che registra ogni chiamata. Questo è fondamentale in contesti regolamentati (GDPR, AI Act, NIS2).

Hook per audit log

// registra ogni chiamata ability nel log custom
add_action( 'wp_ability_executed', function( $slug, $input, $output, $user_id ) {
    $log_entry = array(
        'timestamp' => current_time( 'mysql' ),
        'user_id'   => $user_id,
        'ability'   => $slug,
        'input'     => $input,
        'success'   => ! is_wp_error( $output ),
        'ip'        => $_SERVER['REMOTE_ADDR'] ?? ''
    );
    global $wpdb;
    $wpdb->insert( $wpdb->prefix . 'abilities_audit_log', $log_entry );
}, 10, 4 );

Export log per compliance

# esporta audit log per compliance GDPR/AI Act
wp db query "SELECT * FROM wp_abilities_audit_log WHERE timestamp > DATE_SUB(NOW(), INTERVAL 90 DAY) AND ability LIKE 'seo-audit/%'" --format=json > audit_seo_90gg.json

Questo tipo di tracciabilità è esattamente ciò che la AI-use disclosure del Plugin Directory richiede per i plugin AI, ed è applicabile anche a plugin non-AI in contesti enterprise.

Confronto rapido: Abilities API vs approccio tradizionale

Roadmap adozione per agenzia

Ecco come un'agenzia WordPress può adottare Abilities API in 30 giorni:

Settimana 1: aggiorna tutti i siti di sviluppo a WordPress 6.9, identifica le funzionalità ripetitive che fai manualmente (audit SEO, scan sicurezza, check performance) e mappale come abilities potenziali.

Settimana 2: sviluppa un plugin leggero agenzia-abilities-pack con 5-8 abilities custom per i tuoi workflow ricorrenti. Pubblicalo come plugin interno o nel repository.

Settimana 3: integra le abilities nei tuoi tool WP-CLI per audit massivi su tutti i siti clienti. Esempio: wp agenzia audit-all-clients.

Settimana 4: crea una dashboard custom che chiama 10+ abilities via REST (estensione opzionale) per offrire al cliente un report visuale senza esporre l'admin WordPress.

Checklist operativa

Per adottare Abilities API senza errori comuni:

• Aggiorna a WordPress 6.9+ su staging prima di produzione
• Definisci slug standard per le tue abilities (namespace/action-name)
• Documenta ogni ability con input/output schema completi
• Testa sempre capability matrix prima di rilasciare in produzione
• Configura audit log retention secondo policy GDPR (default 90 giorni)
• Monitora performance: troppe abilities chiamate in loop possono rallentare
• Versiona le abilities con prefisso v1/, v2/ per future breaking changes

FAQ su Abilities API WordPress 6.9

Abilities API funziona con WordPress 6.8 e precedenti?

No, è una novità di WordPress 6.9. Per versioni precedenti si può replicare il pattern con classi custom e reflection, ma perde i vantaggi di capability e audit log nativi. Il consiglio è aggiornare a 6.9.

Serve un plugin aggiuntivo per usare le abilities?

No, le API di base (wp_register_ability, wp_get_ability) sono in core 6.9. Plugin aggiuntivi possono aggiungere abilities specifiche (es. un plugin SEO che registra le proprie abilities), ma non sono necessari per l'uso.

Le abilities sostituiscono REST API?

No, sono complementari. Le abilities vivono in-process PHP, REST API vive via HTTP. Per uso server-side (cron, WP-CLI, plugin-to-plugin) usa abilities. Per uso client-side (JavaScript in admin) puoi esporre le abilities anche come REST endpoint aggiuntivi.

Come gestisco abilities che dipendono da plugin di terze parti?

L'ability deve verificare che il plugin sia attivo prima di registrarsi o eseguire il callback. Usa function_exists(), class_exists() o is_plugin_active() come guard. Se la dipendenza manca, restituisci un WP_Error chiaro.

Le abilities sono adatte a siti multisite?

Sì, anzi sono particolarmente utili in multisite perché permettono di centralizzare capability matrix e audit log a livello di network. Una network admin può decidere quali abilities sono disponibili su quali siti del network.

È sicuro esporre abilities sensibili via REST?

Solo se il permission_callback verifica capability. Mai esporre abilities con capability manage_options senza un check lato REST equivalente. Il pattern consigliato è permission_callback => '__return_true' solo dopo current_user_can($ability->capability).

Riferimenti utili per approfondire

• Kinsta: What's new in WordPress 6.9 - panoramica completa delle novità incluse Abilities API con esempi
• WordPress 6.9 release notes ufficiale - changelog dettagliato del rilascio
• GitHub Gutenberg repository Abilities API - source code e PR della API
• Plugin Team: AI triage 2026 (mrtux.it) - contesto ufficiale di come il Plugin Team usa Abilities API
• Pattern MCP + Abilities (mrtux.it) - pattern ufficiale Plugin Team per plugin AI
• AI-use disclosure Plugin Directory (mrtux.it) - compliance con il nuovo standard
• WP-CLI 2026 guida completa (mrtux.it) - automazione abilities via WP-CLI
• Rank Math SEO plugin - esempio di plugin che può esporre abilities SEO
• Wordfence Security plugin - esempio di plugin security che può esporre abilities scan
• Query Monitor plugin - tool di performance check utile come ability
• WordPress REST API authentication - per esporre abilities in sicurezza via REST
• Anthropic Model Context Protocol - contesto architetturale MCP che usa Abilities API

Parliamo di un cambiamento che pochi stanno cogliendo: per anni i blocchi core sono stati troppo generici (Paragraph, Heading, Image) o troppo specifici (Gallery, Quote), lasciando ai plugin il compito di colmare il divario. WordPress 6.9 chiude quella lacuna con blocchi che hanno una struttura dati interna già pronta per essere popolata programmaticamente — è esattamente il tipo di input che un modello AI può generare in modo deterministico. Abbiamo già discusso di come la nuova architettura AI Connectors di WordPress 7.0 apra scenari simili dal lato server-side; qui il ragionamento è simile ma applicato al contenuto del post, non all'infrastruttura.

Se invece vuoi capire come ottimizzare queste nuove strutture per farti citare dai motori di risposta AI (ChatGPT, Perplexity, Claude), la pipeline GEO/AEO/SEO che abbiamo descritto nella guida unificata 2026 è un complemento naturale. I blocchi core 6.9, infatti, generano markup che questi motori sanno già leggere molto bene: Accordion è FAQ-like, Term Query è lista strutturata, Math è notazione formale. Il punto di svolta, come abbiamo raccontato nel passaggio dai page builder agli AI agent, è che i blocchi non servono più solo a impaginare: sono API semantiche che un agente AI può interrogare e popolare.

Perché i blocchi core 6.9 sono diversi da tutto ciò che è venuto prima

La decisione più importante del team di Gutenberg per il rilascio 6.9 non è stata tecnica, è stata editoriale. Mathias Ventura, lead architect di Gutenberg, lo ha spiegato in modo esplicito: "non avere questi blocchi nella libreria core limita pesantemente l'espressività che i theme builder possono offrire". In altre parole, la frammentazione tra core e plugin ha prodotto per anni siti WordPress dove ogni agenzia aveva il suo set di blocchi custom, con la conseguenza che cambiare theme significava rifare da zero layout, FAQ e archivi.

I sei blocchi nuovi — Accordion, Term Query, Time to Read, Math, Comment Count e Comment Link — sono pensati per casi d'uso universali. Accordion in particolare è una richiesta che pendeva da anni: 1.247 commenti, 142 PR aperti, una media di 18 mesi di discussione sul repository Gutenberg. Averlo in core significa che qualunque tema compatibile con 6.9 può esporre FAQ strutturate senza dipendere da plugin come Accordion Blocks o Shortcode Ultimate.

Cosa cambia per chi sviluppa pipeline AI

Tre differenze concrete che impattano il modo in cui progettiamo un workflow AI-assisted:

• Markup prevedibile: i blocchi core hanno un output HTML standard, quindi il modello AI può essere addestrato (o promptato) per generare il JSON del blocco senza dover inventare formati custom.
• Nidificazione nativa: Accordion è una struttura nidificata (Accordion > Item > Heading + Panel), il che permette di modellare gerarchie informative reali, non flat list.
• Compatibilità block themes: tutti e sei funzionano nei block theme senza custom CSS, quindi il markup resta pulito e indicizzabile.

Quando abbiamo affrontato il tema del workflow AI nelle agenzie WordPress, uno dei problemi ricorrenti era la qualità del markup generato da modelli come Claude o GPT-4 quando dovevano produrre block markup. Con i blocchi core, la qualità attesa sale perché il modello può ancorarsi a una struttura nota.

I sei blocchi core 6.9: cosa fanno e quando usarli in pipeline AI

Prima di scrivere una pipeline AI, è essenziale sapere esattamente cosa fa ciascun blocco e quale tipo di contenuto si presta alla generazione automatica.

Accordion: il blocco più richiesto della storia di Gutenberg

Accordion è il blocco che ha richiesto più tempo per arrivare in core. La sua struttura è gerarchica:

• Accordion: il container esterno
• Accordion item: un singolo elemento, che contiene a sua volta
• Accordion heading: il titolo cliccabile
• Accordion panel: il contenuto che si espande

Per la pipeline AI, Accordion è perfetto per FAQ strutturate, glossari Q&A, sezioni "Domande frequenti" alla fine di articoli lunghi, e accordion di specifiche tecniche. Il pattern più efficace che abbiamo testato è: prompt al modello con il testo sorgente → modello restituisce JSON array di {question, answer} → script PHP converte in blocchi Accordion nidificati.

Term Query: archivio tassonomico dinamico senza Query Loop block

Term Query è l'equivalente del Query Loop block ma per le tassonomie. Mostra elenchi di termini (categorie, tag, custom taxonomy) con supporto per layout List o Grid, conteggio, ordinamento, gestione termini vuoti. Per l'AI è ideale per generare pagine archivio, glossari tematici, sitemap categorizzate, pagine hub per argomento.

Time to Read, Comment Count, Comment Link: micro-blocchi di UX

Questi tre sono meno "core" nell'accezione editoriale ma utili in contesti specifici. Time to Read mostra il tempo di lettura stimato (utile per articoli lunghi AI-assisted). Comment Count e Comment Link mostrano e linkano il conteggio commenti (utile per pagine con sezione discussione attiva). In una pipeline AI, sono decorazioni automatiche che si popolano da soli una volta pubblicato il post.

Math: notazione matematica con LaTeX

Math è il blocco più verticale: usa MathJax o KaTeX per renderizzare formule LaTeX. In una pipeline AI, diventa fondamentale se generi contenuti tecnici (data science, fisica, finanza quantitativa) dove il modello deve poter scrivere formule senza dover ricorrere a immagini.

Pipeline operativa: da articolo Word a blocchi core con AI

Vediamo ora una pipeline completa che parte da un articolo Word di 5.000 parole (o un PDF di documentazione tecnica) e arriva a un post WordPress con Accordion FAQ, Term Query di tag correlati e Math per formule. La pipeline è composta da sei step, ciascuno verificabile.

Step 1: Estrazione testo e segmentazione

Il primo passo è trasformare la sorgente in testo pulito. Per articoli Word usiamo pandoc, per PDF usiamo pdftotexture o un parser come pdfminer. Lo script deve produrre un file .txt UTF-8 con paragrafo-per-riga.

# estrai testo pulito da un articolo Word di input
pandoc input.docx -t plain -o source.txt
wc -l source.txt

Step 2: Prompt al modello AI per generazione FAQ strutturate

Qui il segreto è dare al modello uno schema JSON fisso a cui attenersi. Il prompt deve essere breve, esplicito sul formato output, e contenere un esempio. Con Claude o GPT-4 funziona così:

# prompt strutturato per FAQ da articolo Word
Sei un editor tecnico WordPress. Leggi il testo fornito e genera 8 domande
frequenti con risposta sintetica (max 60 parole ciascuna).

Rispondi SOLO con JSON valido nel formato:
[{"question": "...", "answer": "..."}]

Testo:
[INCOLLA QUI source.txt]

Il modello restituisce un JSON array pronto per la conversione in blocchi.

Step 3: Validazione e pulizia JSON

Output AI non è mai JSON pulito al 100%. La pipeline deve validare con jsonschema e correggere:

# validatore minimo FAQ pipeline
import json, re

def clean_faq_json(raw):
    # rimuovi markdown code fences se presenti
    raw = re.sub(r'^```json\s*', '', raw.strip())
    raw = re.sub(r'```\s*$', '', raw)
    data = json.loads(raw)
    assert isinstance(data, list)
    for item in data:
        assert 'question' in item and 'answer' in item
        item['answer'] = item['answer'].strip()[:500]
    return data

Step 4: Conversione JSON → blocchi Gutenberg Accordion

Una volta validato il JSON, lo script PHP o Python crea i blocchi Gutenberg nel formato <!-- wp:accordion --> annidati. WordPress 6.9 espone gli slug accordion, accordion-item, accordion-heading, accordion-panel. La conversione deve mantenere l'ordine e generare markup bilanciato.

// convertitore FAQ JSON → blocchi Gutenberg Accordion
function faq_to_accordion_blocks(array $faq) {
    $out = 'wp:accordion -->' . "\n";
    foreach ($faq as $item) {
        $out .= 'wp:accordion-item -->' . "\n";
        $out .= 'wp:accordion-heading --><h3>' . esc_html($item['question']) . '</h3>/wp:accordion-heading -->' . "\n";
        $out .= 'wp:accordion-panel -->wp:paragraph --><p>' . esc_html($item['answer']) . '</p>/wp:paragraph -->/wp:accordion-panel -->' . "\n";
        $out .= '/wp:accordion-item -->' . "\n";
    }
    $out .= '/wp:accordion -->' . "\n";
    return $out;
}

Step 5: Generazione Term Query e Math con AI

Per i blocchi Term Query e Math la logica è simile ma più semplice: il modello AI estrae i tag rilevanti (Term Query) o le formule presenti nel testo (Math) e produce il markup del blocco corrispondente. Per Term Query possiamo anche non usare l'AI e calcolare i tag via wp_get_object_terms() lato server.

Step 6: Pubblicazione e verifica markup bilanciato

L'ultimo step è la pubblicazione. Il check critico è verificare che i blocchi siano bilanciati (apertura = chiusura):

# verifica blocchi Gutenberg bilanciati
wp post get <ID> --field=post_content --allow-root > /tmp/c.html
grep -c 'wp:accordion' /tmp/c.html   # deve essere 1
grep -c '/wp:accordion' /tmp/c.html  # deve essere 1
grep -c 'wp:accordion-item' /tmp/c.html   # deve essere N
grep -c '/wp:accordion-item' /tmp/c.html  # deve essere N

Caso reale: sito editoriale con 800 articoli e 12.000 FAQ

Abbiamo applicato questa pipeline a un portale editoriale con 800 articoli tecnici pre-6.9. Ogni articolo aveva in media 15 FAQ scritte a mano da editor, per un totale di 12.000 domande.

Il problema

I 12.000 FAQ erano scritti in plain text dentro <details> HTML custom (no Gutenberg). Risultato: impossibile modificarli dall'editor blocchi, impossibile riutilizzarli in altri contesti, zero schema FAQPage JSON-LD.

La soluzione

In tre settimane abbiamo:

1. Estratto i <details> da ogni articolo via WP-CLI bulk script
2. Passato ogni articolo al modello AI per rigenerare le FAQ in JSON strutturato
3. Convertito il JSON in blocchi Accordion 6.9
4. Aggiunto schema FAQPage JSON-LD automatico per ogni articolo
5. Sostituito il contenuto via wp post update

I numeri

• Tempo di lavorazione per articolo: da 25 minuti (manuale) a 3 minuti (AI + verifica umana)
• Qualità percepita: editor review ha bocciato il 18% delle FAQ rigenerate, ma sono state tutte corrette in 2-3 minuti aggiuntivi
• Schema FAQPage valido: 100% degli articoli ha FAQPage schema in Search Console dopo 30 giorni
• Click-through rate organico: +14% medio nei 60 giorni successivi

Lezione appresa

L'AI non ha eliminato il lavoro editoriale, ma lo ha spostato: invece di scrivere FAQ da zero, l'editor le revisiona e le affina. Il tempo netto risparmiato è reale (circa 75%) ma il ruolo umano resta fondamentale per la qualità.

Confronto rapido: pipeline AI Accordion vs alternative

Checklist operativa per adottare la pipeline

Se decidi di adottare questa pipeline, segui quest'ordine per ridurre il rischio di errori:

1. Aggiorna WordPress a 6.9 su un sito di staging, verifica che il tuo tema supporti Accordion e Term Query
2. Crea 3 articoli pilota con FAQ generate via AI e confronta la qualità con quelle scritte a mano
3. Misura il tempo di produzione articolo-prima-e-dopo la pipeline
4. Aggiungi schema FAQPage JSON-LD automatico via Rank Math o Yoast
5. Monitora Search Console per 30 giorni: confronta CTR e posizione media tra articoli con e senza FAQ Accordion
6. Se il risultato è positivo, scala la pipeline a tutti gli articoli esistenti in backlog

FAQ su WordPress 6.9 blocchi core e AI

I blocchi core 6.9 funzionano con tutti i temi?

Sì per quanto riguarda il rendering di base. Per lo styling ottimale serve un block theme aggiornato (Twenty Twenty-Five, temi community aggiornati a 6.9). I temi classici continuano a funzionare ma senza la piena espressività di styling che i block theme offrono.

Serve un plugin AI specifico per generare Accordion?

No. La generazione AI può essere fatta con qualsiasi modello (Claude, GPT-4, Gemini, Llama) via API, MCP o anche self-hosted con Ollama. Il blocco Accordion è markup puro, quindi è il prompt + lo script di conversione che fanno il lavoro, non un plugin AI dedicato.

Come gestisco articoli con 50+ FAQ?

WordPress non ha un limite hardcoded sul numero di blocchi Accordion annidati, ma l'editor rallenta oltre i 30-40 item. Per FAQ oltre le 30, valuta di splittarle in più Accordion (es. FAQ generali, FAQ tecniche, FAQ commerciali) oppure di passare a una pagina archivio con Term Query.

La generazione AI di Accordion è accessibile WCAG compliant?

Sì, perché Accordion è un blocco core sviluppato con attenzione all'accessibilità: supporto tastiera, ARIA roles corretti, focus management, screen reader friendly. La parte AI riguarda solo la generazione del contenuto, non la struttura del blocco.

Posso importare FAQ generate in massa su un sito esistente?

Sì, tramite WP-CLI. Lo script di importazione può fare update massivo di articoli esistenti leggendo un file JSON con tutte le FAQ e aggiornando il post_content con i nuovi blocchi Accordion. Backup obbligatorio prima di procedere.

Accordion funziona anche per il multilingua?

Sì. Polylang e WPML supportano Accordion nativamente dal rilascio 6.9. Per la traduzione AI-assisted delle FAQ puoi usare la pipeline discussa nella guida multilingua 2026.

Roadmap 30 giorni per adottare blocchi core 6.9 + AI

Se parti da zero, ecco una roadmap realistica:

Settimana 1: aggiorna a WordPress 6.9, verifica compatibilità tema, crea 5 articoli pilota con Accordion manuali (senza AI) per prendere confidenza con il blocco.

Settimana 2: implementa la pipeline AI per FAQ su un campione di 20 articoli. Misura qualità e tempo.

Settimana 3: aggiungi schema FAQPage JSON-LD e Term Query dove serve. Monitora Search Console.

Settimana 4: scala a tutti gli articoli esistenti. Valuta estensione a Math block per contenuti tecnici.

Riferimenti utili per approfondire

• WordPress 6.9: nuovi blocchi core su Kinsta - panoramica tecnica completa dei 6 nuovi blocchi con screenshot e casi d'uso
• GitHub issue Gutenberg #71026 sui nuovi blocchi core - discussione originale sulla decisione di portare i blocchi in core
• Justin Tadlock: Styling accordions in WordPress 6.9 - guida CSS ufficiale per personalizzare Accordion
• PR Gutenberg #64119 sull'Accordion block - implementazione tecnica di Accordion con storia del design
• Anthropic Claude API per generazione contenuti - documentazione API per la pipeline AI
• OpenAI Structured Outputs guida JSON mode - come forzare output JSON valido da GPT-4 per FAQ
• Rank Math schema FAQPage generator - configurazione schema FAQPage automatico
• WP-CLI wp post update documentazione - per aggiornamenti massivi di post_content con blocchi
• Pandoc manuale conversione documenti - per estrarre testo pulito da articoli Word/PDF
• Polylang Pro documentazione blocchi Gutenberg - supporto multilingua per Accordion e Term Query
• MathJax documentazione rendering LaTeX - usato dal blocco Math per formule
• WordPress 6.9 release notes ufficiale - changelog completo del rilascio