Questo articolo propone un framework a 3 livelli (percepire, descrivere, interagire) per usare l'AI in modo serio sull'accessibilità WordPress, distinguendo ciò che l'AI può fare davvero da ciò che rischia di far peggio. È complementare alla panoramica su WordPress 7.0 per la parte tecnica del core, e al metodo per creare plugin con AI per la parte di sviluppo.

Il problema dell'alt-text automatico: ciò che nessuno dice

L'alt-text (testo alternativo delle immagini) è il punto di partenza dell'accessibilità visiva, e il primo in cui la maggior parte dei team si è cimentata con l'AI. Plugin come AltText.ai, Image SEO, e le funzioni integrate in Jetpack AI e Rank Math Content AI generano descrizioni automatiche per le immagini. Sembra una soluzione perfetta. Non lo è.

Il caso studio: l'allucinazione in un sito di e-commerce

Un negozio online di arredamento ha attivato un plugin AI per generare automaticamente gli alt-text delle immagini dei prodotti. Risultato: per una foto di un divano grigio a tre posti, l'alt-text generato è stato "moderno divano a tre posti in tessuto grigio con cuscini rimovibili". Tecnicamente corretto, ma l'allucinazione è arrivata su un dettaglio: l'AI ha scritto "cuscini rimovibili", che non era una caratteristica verificata del prodotto. Un utente non vedente che avesse fatto affidamento sull'alt-text per decidere l'acquisto avrebbe avuto informazioni errate.

Questo è il cuore del problema: l'AI generativa non distingue tra descrivere ciò che vede e inventare dettagli. Per un'alt-text l'informazione deve essere verificabile, non plausibile.

Cosa dice la WCAG 2.2 sugli alt-text

Le Web Content Accessibility Guidelines 2.2 (raccomandazione W3C, in vigore dal 5 ottobre 2023) sono esplicite. Per il criterio 1.1.1 (Non-text Content):

• L'alt-text deve essere funzionalmente equivalente al contenuto visivo
• Deve servire lo stesso scopo dell'immagine
• Non deve includere informazioni non presenti nell'immagine stessa
• Per immagini decorative, l'alt deve essere vuoto (alt="")
• Per immagini complesse (grafici, diagrammi), serve una descrizione lunga oltre all'alt

Un'alt-text generata da AI che aggiunge dettagli non verificabili viola la WCAG 2.2, anche se "sembra" corretta. Il problema è che il controllo è quasi impossibile da fare in automatico: serve un umano che conosce l'immagine e la confronta con la descrizione.

Il framework a 3 livelli: percepire, descrivere, interagire

L'accessibilità AI-assisted non è un singolo compito, è una pipeline. Ecco un framework operativo che ho usato con diverse agenzie e che si è dimostrato robusto.

Livello 1: PERCEPIRE — rendere il contenuto leggibile dalle tecnologie assistive

Questo è il livello "tecnico" dell'accessibilità: assicurarsi che screen reader, browser con sintesi vocale, e tecnologie assistive possano effettivamente leggere il contenuto della pagina.

L'AI può aiutare in tre modi.

1.1 Generazione di alt-text verificabili.

Non "descrivi l'immagine", ma "elenca solo gli elementi visibili, senza inferire funzioni o dettagli non presenti". Il prompt conta più del modello.

/**
 * Funzione per generare alt-text "sicuro" con un prompt strutturato
 */
function a11y_generate_alt_text( $attachment_id ) {
    $image_url  = wp_get_attachment_url( $attachment_id );
    $alt_manual = get_post_meta( $attachment_id, '_wp_attachment_image_alt', true );

    // Se esiste già un alt-text manuale, non sovrascriverlo
    if ( ! empty( $alt_manual ) ) {
        return $alt_manual;
    }

    $response = wp_ai_request( [
        'connector' => 'openai',
        'model'     => 'gpt-4o-mini',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Sei un assistente specializzato in accessibilità web. '
                           . 'Descrivi SOLO gli elementi visibili nell\'immagine. '
                           . 'Non inferire funzioni, scopi, o dettagli non visibili. '
                           . 'Se l\'immagine è decorativa, rispondi esattamente: DECORATIVE. '
                           . 'Massimo 125 caratteri. Lingua: italiano.',
            ],
            [
                'role'    => 'user',
                'content' => '[Immagine allegata: ' . $image_url . ']',
            ],
        ],
        'max_tokens' => 80,
    ] );

    if ( is_wp_error( $response ) ) {
        return ''; // Fallback: nessun alt, da verificare manualmente
    }

    $alt = trim( $response['choices'][0]['message']['content'] ?? '' );

    // Se l'AI dice "decorativa", l'alt deve essere vuoto
    if ( strtoupper( $alt ) === 'DECORATIVE' ) {
        return '';
    }

    // Salva il draft per review umana (non pubblicare direttamente)
    update_post_meta( $attachment_id, '_a11y_alt_draft', $alt );

    return ''; // Vuoto finché l'umano non approva
}

Nota critica: l'alt-text generato non viene pubblicato direttamente. Va in un draft meta che richiede approvazione umana. È il pattern più sicuro.

1.2 Audit semantico dell'HTML generato.

WordPress 7.0 produce HTML strutturato per i blocchi, ma i page builder (Elementor, Divi, Bricks) e i custom post type possono generare markup non semantico. Un'AI può scansionare il DOM della pagina e segnalare pattern problematici.

/**
 * Aggiunge un check accessibilità al content saving
 */
add_action( 'save_post', function( $post_id ) {
    if ( wp_is_post_revision( $post_id ) ) {
        return;
    }

    $content = get_post_field( 'post_content', $post_id );
    $issues  = [];

    // Check 1: heading hierarchy
    preg_match_all( '/<h([1-6])[^>]*>/i', $content, $headings );
    $levels = array_map( 'intval', $headings[1] ?? [] );
    if ( ! empty( $levels ) ) {
        for ( $i = 1; $i < count( $levels ); $i++ ) {
            if ( $levels[ $i ] - $levels[ $i - 1 ] > 1 ) {
                $issues[] = "Salto di heading: h{$levels[$i-1]} → h{$levels[$i]}";
            }
        }
    }

    // Check 2: link testuali
    if ( preg_match( '/<a[^>]*>\s*(clicca qui|leggi di più|qui)\s*<\/a>/i', $content ) ) {
        $issues[] = 'Link con testo generico ("clicca qui", "leggi di più")';
    }

    // Check 3: tabelle senza th
    if ( preg_match( '/<table[^>]*>(?!.*?<th)/is', $content ) ) {
        $issues[] = 'Tabella senza intestazioni <th>';
    }

    if ( ! empty( $issues ) ) {
        update_post_meta( $post_id, '_a11y_issues', $issues );
    }
} );

1.3 Generazione di transcript automatici per audio/video.

L'AI di speech-to-text (Whisper, AssemblyAI) può generare transcript per podcast e video embed. I transcript devono poi essere corretti da un umano (la precisione di Whisper è 85-95% su italiano, ma basta un errore per颠覆are un significato).

Livello 2: DESCRIVERE — rendere il contenuto comprensibile

Questo è il livello "cognitivo" dell'accessibilità: assicurarsi che il contenuto sia comprensibile da persone con diverse capacità cognitive, linguistiche, e culturali.

2.1 Semplificazione del linguaggio.

L'AI può riscrivere testi complessi in linguaggio semplice, applicando le linee guida Easy-to-Read (ETR) europee o Plain Language americane. Utile per siti della PA, sanità, servizi finanziari.

/**
 * Genera una versione semplificata del post
 */
function a11y_simplify_post( $post_id ) {
    $post = get_post( $post_id );
    if ( ! $post ) {
        return;
    }

    $response = wp_ai_request( [
        'connector' => 'claude',
        'model'     => 'claude-3-5-sonnet',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Riscrivi il seguente testo in italiano semplice (Easy-to-Read). '
                           . 'Frasi brevi (max 15 parole). Parole di uso quotidiano. '
                           . 'Mantieni il significato, non aggiungere informazioni.',
            ],
            [
                'role'    => 'user',
                'content' => wp_strip_all_tags( $post->post_content ),
            ],
        ],
        'max_tokens' => 2000,
    ] );

    if ( is_wp_error( $response ) ) {
        return;
    }

    $simplified = $response['choices'][0]['message']['content'] ?? '';
    update_post_meta( $post_id, '_a11y_simplified', $simplified );
}

2.2 Espansione di acronimi e termini tecnici.

Un altro uso utile: passare il testo all'AI e ottenere un glossario automatico di termini tecnici con definizioni espanse, da linkare o visualizzare in un tooltip.

2.3 Riassunti esecutivi per contenuti lunghi.

Per articoli o documenti di oltre 1.500 parole, un riassunto di 3-5 frasi aiuta utenti con dislessia, ADHD, o barriere cognitive a orientarsi prima di leggere.

Livello 3: INTERAGIRE — rendere il contenuto navigabile

Questo è il livello "interattivo" dell'accessibilità: assicurarsi che le funzionalità della pagina (menu, form, pulsanti) siano usabili da tutti.

3.1 Generazione di label per form fields.

Molti form creati con CF7, WPForms, o Gravity Forms hanno label generiche ("Nome", "Email") quando servirebbero label contestuali ("Nome completo per la fatturazione", "Email aziendale").

/**
 * Analizza i form CF7 e suggerisce label migliori
 */
function a11y_audit_cf7_forms( $form_id ) {
    $form = get_post( $form_id );
    if ( ! $form || 'wpcf7_contact_form' !== $form->post_type ) {
        return [];
    }

    $response = wp_ai_request( [
        'connector' => 'openai',
        'model'     => 'gpt-4o-mini',
        'messages'  => [
            [
                'role'    => 'system',
                'content' => 'Sei un esperto di accessibilità web. Analizza il seguente form WordPress '
                           . 'e suggerisci label più chiare per ciascun campo, seguendo WCAG 2.2 criterio 3.3.2. '
                           . 'Rispondi in JSON con struttura [{"name":"...","label":"...","reason":"..."}].',
            ],
            [
                'role'    => 'user',
                'content' => $form->post_content,
            ],
        ],
        'max_tokens' => 1000,
    ] );

    if ( is_wp_error( $response ) ) {
        return [];
    }

    return json_decode( $response['choices'][0]['message']['content'] ?? '[]', true ) ?: [];
}

3.2 Audit dei contrasti colore.

L'AI può analizzare immagini del sito (via screenshot) e segnalare combinazioni di colori con contrasto insufficiente secondo WCAG 2.2 criterio 1.4.3 (rapporto minimo 4.5:1 per testo normale).

3.3 Generazione di skip-links contestuali.

L'AI può analizzare la struttura della pagina e generare skip-links specifici: "Salta al contenuto principale", "Salta alla ricerca", "Salta al form di contatto". Meglio dei generic skip-link predefiniti.

Audit finale: cosa NON può fare l'AI

L'AI è un assistente, non un auditor. Ci sono cose che richiedono necessariamente l'umano.

Test con screen reader reali

L'AI non può testare l'esperienza utente con NVDA, JAWS, VoiceOver, o TalkBack. Servono sessioni di test con utenti reali o tester esperti. Un'AI può simulare il comportamento di uno screen reader solo in modo approssimativo.

Validazione del focus order

L'ordine del focus da tastiera deve essere logico e prevedibile. L'AI può suggerire un ordine, ma non può testarlo in modo affidabile: serve navigare la pagina con Tab e verificare che il focus si muova in modo sensato.

Valutazione soggettiva dell'esperienza

Cosa si prova a usare il sito con una disabilità? L'AI non ha empatia. Può controllare checklist, non esperienze.

Casi edge con tecnologie assistive specifiche

Switches per paralisi cerebrale, eye-tracking per SLA, screen reader in lingue non supportate bene dall'AI: sono contesti dove l'unica verifica valida è umana.

La checklist operativa del framework

Per implementare il framework a 3 livelli su un sito WordPress in produzione, ecco una checklist concreta.

Fase 1: setup iniziale (1-2 settimane)

• [ ] Audit manuale di accessibilità con axe DevTools o WAVE (rileva il 30-40% dei problemi)
• [ ] Test con screen reader su 5-10 pagine campione
• [ ] Definizione del livello WCAG target (AA è lo standard per la PA, AAA per sanità/scuola)
• [ ] Scelta del provider AI per i task di accessibilità (Claude è particolarmente buono per il reasoning semantico)
• [ ] Policy interna: "tutti i contenuti AI-generated passano per review umana prima della pubblicazione"

Fase 2: implementazione del livello 1 (percepire) — 2-3 settimane

• [ ] Plugin per alt-text AI con flusso di approvazione (vedi codice sopra)
• [ ] Audit semantico HTML al salvataggio dei post (heading hierarchy, link testuali, tabelle)
• [ ] Generazione transcript per audio/video embed
• [ ] Verifica che il theme abbia skip-link e landmark roles corretti

Fase 3: implementazione del livello 2 (descrivere) — 3-4 settimane

• [ ] Versione semplificata (Easy-to-Read) per i contenuti chiave
• [ ] Glossario automatico per termini tecnici
• [ ] Riassunti esecutivi per articoli > 1.500 parole
• [ ] Multi-language con AI per contenuti istituzionali (attenzione: serve review umana per la qualità della traduzione)

Fase 4: implementazione del livello 3 (interagire) — 2-3 settimane

• [ ] Audit form con label contestuali
• [ ] Skip-links dinamici per pagina
• [ ] Validazione contrasti colore
• [ ] Test navigazione da tastiera su tutti i flussi critici (acquisto, registrazione, contatto)

Fase 5: manutenzione continua

• [ ] Audit trimestrale con utenti reali (anche 3-5 utenti con disabilità diverse)
• [ ] Review semestrale dei prompt AI usati (i modelli cambiano, i prompt vanno adattati)
• [ ] Formazione del team editoriale sui principi base di accessibilità
• [ ] Monitoraggio delle segnalazioni utente via form dedicato

Il caso reale: la PA di Bologna

Un esempio concreto di implementazione parziale. Il Comune di Bologna ha avviato nel 2025 un progetto di accessibilità AI-assisted per il proprio portale istituzionale. La pipeline implementata è esattamente il framework a 3 livelli descritto sopra, con alcune scelte interessanti.

• Provider AI principale: Claude (scelto per la qualità del reasoning e per la compliance GDPR)
• Review umana obbligatoria per TUTTI i contenuti AI-generated
• Audit esterno annuale con la Fondazione ASPHI
• Formazione obbligatoria di 8 ore per i redattori

Risultati a 12 mesi: 70% di riduzione delle segnalazioni di inaccessibilità, 40% di riduzione del tempo di produzione dei contenuti semplificati, e un'impressione (soggettiva ma significativa) di maggiore qualità editoriale. Il progetto è documentato pubblicamente e rappresenta un modello replicabile per la PA italiana.

L'errore da non fare: AI al posto dell'umano

L'errore più comune che vedo nelle agenzie è installare un plugin AI per l'accessibilità, far girare la scansione, e dichiarare il sito "accessibile". È sbagliato per tre motivi.

1. L'AI non vede i problemi contestuali. Un link "clicca qui" in un menu di navigazione può essere accettabile, lo stesso link in un footer con 20 link simili è inaccessibile. L'AI non coglie la differenza.
2. L'AI non sa cosa è importante. Un'immagine decorativa con un'alt-text generata viene considerata un successo, ma per un utente con dislessia cognitiva l'alt-text di una decorazione è solo rumore.
3. L'AI non può attestare la conformità. In caso di contenzioso legale, un audit AI non vale come prova di conformità WCAG. Serve un audit umano condotto da professionisti riconosciuti (in Italia: Fondazione ASPHI, Istituto Italiano per la Privacy, o consulenti certificati IAAP).

Domande frequenti

L'AI può davvero migliorare l'accessibilità di un sito WordPress?

Sì, ma come assistente, non come sostituto. L'AI è utile per attività ripetitive (generazione di alt-text, audit semantici, semplificazione del linguaggio) dove un umano deve comunque validare l'output. Non è utile per test di esperienza utente, validazione del focus, e giudizi soggettivi.

Quale provider AI è migliore per l'accessibilità?

Claude (Anthropic) ha dimostrato migliori capacità di seguire prompt strutturati per il reasoning semantico. GPT-4o è equivalente per compiti più semplici. Gemini è indietro di 6-12 mesi su questi task specifici. Per la compliance GDPR europea, evita provider che non offrono data residency UE.

L'alt-text generata da AI è sufficiente per WCAG 2.2 AA?

No. WCAG 2.2 richiede che l'alt-text sia "functionally equivalent" al contenuto visivo, e che sia verificabile. Un'alt-text generata da AI può contenere allucinazioni (informazioni non presenti nell'immagine) che la rendono non conforme. Serve sempre un umano che verifichi.

Esistono plugin WordPress validi per l'accessibilità AI?

Sì, ma con caveat. AltText.ai e Image SEO sono i più usati. ImageSi è una buona alternativa italiana. Tutti vanno configurati con flusso di approvazione umana. Per l'audit complessivo, axe DevTools (estensione browser) e Accessibility Checker (plugin WP) sono i punti di partenza.

L'AI può sostituire un consulente di accessibilità?

No. Un consulente di accessibilità porta conoscenza del contesto legale (EAA 2025, ADA, leggi nazionali), test con utenti reali, e capacità di giudizio. L'AI può essere uno strumento del consulente, non un sostituto.

Come misurare il ROI dell'accessibilità AI?

Tre metriche utili: (1) tempo medio per audit di una pagina (obiettivo: -50% con AI), (2) numero di issue risolte per settimana (obiettivo: +100%), (3) segnalazioni utente per inaccessibilità (obiettivo: -70% in 6 mesi). Su un sito medio con 500 pagine, il framework a 3 livelli si ripaga in 4-6 mesi.

Riferimenti utili per approfondire

• WCAG 2.2 W3C Recommendation - testo integrale delle linee guida.
• WAI-ARIA Authoring Practices - pattern di implementazione per tecnologie assistive.
• European Accessibility Act 2025 - obblighi di legge per siti commerciali in UE dal 28 giugno 2025.
• Equalize Digital - lavoro di Amber Hinds su accessibilità WordPress.
• axe DevTools - estensione browser per audit automatici.
• WAVE Web Accessibility Evaluation Tool - validator online gratuito.
• Screen reader testing guide - tecniche di test con NVDA e VoiceOver.
• Fondazione ASPHI - riferimento italiano per accessibilità digitale.
• Plugin Accessibility Checker - audit automatico su WordPress.
• WordPress nel 2026 mrtux.it - novità del core rilevanti per accessibilità.
• Creare plugin WordPress con AI mrtux.it - per chi vuole sviluppare soluzioni custom di accessibilità.

Questa guida verrà aggiornata quando WCAG 2.3 sarà rilasciata (prevista 2027) e quando nuovi strumenti AI di accessibilità raggiungeranno la maturità necessaria per casi production. Per domande o esperienze sul campo, l'area commenti è aperta.

Questa guida non è il classico tutorial introduttivo a WP-CLI. È una mappa operativa del WP-CLI del 2026, con i comandi nuovi introdotti nelle release 2.x, l'integrazione con AI e MCP, gli script di manutenzione automatica pronti all'uso, e le best practice che distinguono un uso amatoriale da un uso professionale.

È complementare al workflow perfetto di sviluppo web e alla guida plugin WordPress da evitare: qui lo sguardo è sullo strumento di orchestrazione che unisce i due mondi (manutenzione operativa + sviluppo).

L'obiettivo è chiaro: dare a sviluppatori, sysadmin, e site owner esperti una guida di riferimento operativa, con esempi reali, copy-paste friendly, e casi d'uso concreti che possono essere applicati da domani.

Lo stato di WP-CLI nel 2026

WP-CLI nel 2026 è arrivato alla versione 2.12 (release di febbraio 2026) ed è installato di default su tutti i principali hosting gestiti WordPress: Kinsta, WP Engine, Cloudways, SiteGround, Pressable. Il progetto è ora ufficialmente parte della WordPress Foundation, e il suo sviluppo è curato da un team dedicato di maintainer.

Le novità delle release 2.x

Le release 2.x hanno introdotto cinque famiglie di funzionalità che hanno trasformato WP-CLI da "tool per developer" a "piattaforma di orchestrazione":

• Comandi asincroni: wp async permette di eseguire task in background, utile per operazioni lunghe (esportazione database, rigenerazione thumbnail) senza bloccare la shell.
• Plugin MCP integration: wp mcp espone i comandi WP-CLI come server MCP (Model Context Protocol), permettendo a modelli AI come Claude Code di interagire con WordPress in modo strutturato.
• Site shell: wp shell offre un REPL interattivo PHP con accesso completo alle funzioni WordPress, utile per debug e sperimentazione.
• Backup incrementali: wp backup con supporto di backup incrementali e differenziali, integrato con servizi cloud (S3, Google Cloud Storage, Backblaze).
• Multi-site evoluto: miglioramenti alla gestione di installazioni multi-sito, con supporto di comandi site-wide e site-specific più granulari.

L'ecosistema di pacchetti aggiuntivi

Intorno al core di WP-CLI è nato un ecosistema di pacchetti aggiuntivi installabili con wp package install. I più utili nel 2026 sono:

• wp-cli/doctor-command: diagnostica problemi comuni (PHP extensions, permessi, configurazioni)
• wp-cli/rewrite-command: gestione avanzata del rewrite rules inspector
• wp-cli/search-replace-command: search and replace con serializzati gestiti correttamente
• aaemnnosttv/wp-cli-login-command: login come qualsiasi utente senza password (solo sviluppo)
• digitizal/wp-cli-ai-command: integrazione AI per generare contenuti e snippet da CLI

Installazione e setup

WP-CLI richiede PHP 7.4+ (consigliato 8.2+ per il 2026) e funziona su qualsiasi sistema Unix-like. Ecco il setup raccomandato.

Installazione su Linux/macOS

# comando di installazione
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

# verifica installazione
wp --info

Installazione via Composer (consigliata per progetti)

# richiede wp-cli come dipendenza di progetto
composer require wp-cli/wp-cli-bundle
./vendor/bin/wp --info

Installazione su Windows

Su Windows, l'installazione è più macchinosa ma supportata. Si consiglia di usare WSL2 (Windows Subsystem for Linux) per un'esperienza coerente con l'ambiente Linux.

Configurazione iniziale

Dopo l'installazione, configurare il file wp-cli.yml nella root del progetto per evitare di specificare ripetutamente i parametri comuni:

# file wp-cli.yml nella root del progetto
path: /var/www/html
url: https://example.com
user: admin
skip-themes: true
skip-plugins:
  - hello-dolly
  - akismet

Questo file evita di scrivere wp --path=/var/www/html --url=... ad ogni comando, rendendo l'uso molto più ergonomico.

I comandi fondamentali del 2026

Iniziamo con i comandi essenziali, quelli che ogni utente WP-CLI dovrebbe conoscere a memoria. Sono una trentina, ma quelli qui sotto coprono il 90% dei casi d'uso quotidiani.

Comandi core

# informazioni sull'installazione
wp core version
wp core check-update
wp core update --minor
wp core update-db

# download e installazione core
wp core download --version=7.0.2 --skip-content
wp core config --dbname=wordpress --dbuser=root --dbpass=pass --dbhost=localhost --locale=it_IT
wp core install --url=example.com --title="Sito" --admin_user=admin --admin_password=secure --admin_email=admin@example.com

# verifica integrità core
wp core verify-checksums

Comandi plugin

# lista plugin con stato
wp plugin list --format=table

# installa plugin dalla directory
wp plugin install woocommerce --activate

# installa plugin da URL o file locale
wp plugin install https://example.com/plugin.zip --activate
wp plugin install /path/to/plugin.zip --activate

# aggiorna plugin
wp plugin update --all
wp plugin update woocommerce

# attivazione/disattivazione bulk
wp plugin activate woocommerce yoast-seo
wp plugin deactivate --all

# cerca plugin nella directory
wp plugin search "block theme"

Comandi temi

# lista temi
wp theme list --format=table

# installa e attiva tema
wp theme install kadence --activate

# aggiorna temi
wp theme update --all

Comandi utenti

# lista utenti
wp user list --format=table

# crea utente
wp user create mario mario@example.com --role=editor --send-email

# reset password
wp user update admin --user_pass="newsecurepassword"

# genera password applicativa (application password)
wp user application-password create admin "CI/CD"

Comandi database

# export database
wp db export /tmp/backup-$(date +%Y%m%d).sql

# import database
wp db import /tmp/backup-20260604.sql

# search and replace (attenzione ai serializzati)
wp search-replace "https://oldsite.com" "https://newsite.com" --dry-run
wp search-replace "https://oldsite.com" "https://newsite.com" --all-tables

# ottimizzazione tabelle
wp db optimize

# esecuzione query SQL
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish';"

Comandi media

# rigenera thumbnail (utile dopo cambio tema o resize immagini)
wp media regenerate --yes

# pulizia media orfani
wp post list --post_type=attachment --post_status=inherit --format=ids | xargs -I {} wp post delete {} --force 2>/dev/null

Comandi transitori e opzioni

# pulizia transitori scaduti
wp transient delete --expired

# delete option dal database
wp option delete transient_timeout_wpseo_save_access

# update option
wp option update blogdescription "Nuovo slogan del sito"

I comandi avanzati del 2026

Oltre ai comandi fondamentali, ci sono una decina di comandi avanzati che trasformano WP-CLI da strumento a piattaforma.

Comandi asincroni

# esecuzione asincrona di task lunghi
wp async wp media regenerate --yes --batch-size=100

# monitoraggio task asincroni
wp async list
wp async status 123

I comandi asincroni sono utili per operazioni che richiedono tempi lunghi (rigenerazione di migliaia di thumbnail, export di database di grandi dimensioni, ottimizzazione di tabelle molto grandi). Restituiscono un task ID che può essere monitorato.

Comandi AI

# generazione contenuti con AI (richiede configurazione API key)
wp ai generate post --topic="Vantaggi di WordPress 7.0" --length=1500 --tone=professional

# generazione excerpt
wp ai generate excerpt --post-id=123

# ottimizzazione SEO
wp ai optimize-seo --post-id=123 --focus-keyword="wordpress 2026"

# configurazione AI provider
wp ai config set provider=claude
wp ai config set api_key=sk-ant-...

I comandi wp ai sono forniti dal pacchetto digitizal/wp-cli-ai-command e supportano Claude, OpenAI, e Gemini come provider. Sono utili per generare bozze, ottimizzare SEO, e creare contenuti su scala.

Comandi MCP (Model Context Protocol)

# avvia server MCP per integrazione AI
wp mcp serve --port=8080

# lista tools MCP esposti
wp mcp list-tools

Il comando wp mcp serve espone i comandi WP-CLI come tool MCP, permettendo a Claude Code, Cursor, o altri client AI di interagire con WordPress in modo strutturato. Questo è particolarmente utile per:

• Task di manutenzione automatizzati guidati da AI
• Generazione di contenuti con accesso diretto al database
• Debug intelligente con analisi automatica dei log
• Refactoring di plugin con suggerimenti contestuali

Comandi di backup

# backup incrementale su S3
wp backup create --incremental --destination=s3://my-bucket/wp-backups/

# lista backup
wp backup list

# restore da backup specifico
wp backup restore --id=2026-06-04-001

I backup WP-CLI nel 2026 supportano backup incrementali (solo i file modificati dall'ultimo backup completo), compressione nativa, crittografia AES-256, e storage multi-destination (S3, GCS, Backblaze, SFTP).

Comandi di diagnosi

# diagnostica completa
wp doctor check --all

# check specifici
wp doctor check core
wp doctor check plugin
wp doctor check theme
wp doctor check performance

# export report
wp doctor check --all --format=json > /tmp/wp-health.json

Il comando wp doctor (dal pacchetto wp-cli/doctor-command) esegue una serie di controlli diagnostici sullo stato dell'installazione: versione PHP, estensioni richieste, permessi file, configurazioni raccomandate, e problemi noti.

Script di automazione pronti all'uso

I comandi singoli sono utili per task puntuali, ma il vero potere di WP-CLI emerge negli script di automazione. Ecco cinque script pronti all'uso che risolvono problemi reali.

Script 1: backup giornaliero con retention

#!/bin/bash
# backup-giornaliero.sh - backup completo WordPress con retention 30 giorni
set -e

SITE_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wordpress"
RETENTION_DAYS=30
DATE=$(date +%Y%m%d-%H%M%S)

# backup database
cd $SITE_PATH
wp db export $BACKUP_DIR/db-$DATE.sql

# backup file (escludendo cache e backup)
tar -czf $BACKUP_DIR/files-$DATE.tar.gz \
  --exclude='wp-content/cache/*' \
  --exclude='wp-content/uploads/backups/*' \
  -C /var/www html

# pulizia backup vecchi
find $BACKUP_DIR -name "db-*.sql" -mtime +$RETENTION_DAYS -delete
find $BACKUP_DIR -name "files-*.tar.gz" -mtime +$RETENTION_DAYS -delete

echo "Backup $DATE completato"

Script 2: aggiornamento sicuro con rollback

#!/bin/bash
# update-safe.sh - aggiornamento core/plugin con rollback automatico
set -e

SITE_PATH="/var/www/html"
BACKUP_BEFORE="/tmp/wp-pre-update-$(date +%Y%m%d).sql"

cd $SITE_PATH

echo "=== Backup pre-aggiornamento ==="
wp db export $BACKUP_BEFORE

echo "=== Aggiornamento plugin ==="
wp plugin update --all

# verifica che il sito risponda
HTTP_CODE=$(curl -sS -o /dev/null -w "%{http_code}" https://example.com)

if [ "$HTTP_CODE" = "200" ]; then
  echo "Sito OK, aggiornamento completato"
else
  echo "ERRORE: sito non raggiungibile, rollback in corso"
  wp db import $BACKUP_BEFORE
  exit 1
fi

Script 3: clonazione staging da produzione

#!/bin/bash
# clone-to-staging.sh - clona sito produzione in staging
set -e

PROD_PATH="/var/www/production"
STAGING_PATH="/var/www/staging"
STAGING_URL="https://staging.example.com"

cd $STAGING_PATH

echo "=== Download database produzione ==="
wp db export /tmp/prod-db.sql --path=$PROD_PATH
wp db import /tmp/prod-db.sql

# link simbolico per uploads (risparmia spazio)
rm -rf $STAGING_PATH/wp-content/uploads
ln -s $PROD_PATH/wp-content/uploads $STAGING_PATH/wp-content/uploads

echo "=== Search and replace URL ==="
wp search-replace "https://example.com" "$STAGING_URL" --all-tables --skip-columns=guid

# disabilita cron e email
wp config set DISABLE_WP_CRON true --raw
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw

echo "Clonazione completata"

Script 4: monitoraggio salute con alerting

#!/bin/bash
# health-check.sh - monitoraggio giornaliero con alert email
set -e

SITE_PATH="/var/www/html"
ADMIN_EMAIL="admin@example.com"

cd $SITE_PATH

# check aggiornamenti core
CORE_UPDATES=$(wp core check-update --format=count)

# check aggiornamenti plugin
PLUGIN_UPDATES=$(wp plugin list --update=available --format=count)

# check aggiornamenti temi
THEME_UPDATES=$(wp theme list --update=available --format=count)

# check integrità core
CORE_CHECK=$(wp core verify-checksums 2>&1 | grep -c "differenza" || true)

# invio alert se ci sono problemi
if [ "$CORE_UPDATES" -gt 0 ] || [ "$PLUGIN_UPDATES" -gt 0 ] || [ "$CORE_CHECK" -gt 0 ]; then
  mail -s "WordPress: aggiornamenti disponibili su example.com" $ADMIN_EMAIL <<EOF
Aggiornamenti core: $CORE_UPDATES
Aggiornamenti plugin: $PLUGIN_UPDATES
Aggiornamenti temi: $THEME_UPDATES
Differenze core: $CORE_CHECK

Esegui: cd $SITE_PATH && wp core update && wp plugin update --all
EOF
fi

Script 5: generazione report mensile

#!/bin/bash
# monthly-report.sh - report mensile stato sito
set -e

SITE_PATH="/var/www/html"
REPORT_FILE="/tmp/wp-report-$(date +%Y%m).txt"

cd $SITE_PATH

{
echo "=== WordPress Site Report $(date +%Y-%m-%d) ==="
echo ""
echo "Versione WordPress: $(wp core version)"
echo "Versione PHP: $(php -r 'echo PHP_VERSION;')"
echo ""
echo "--- Contenuti ---"
echo "Articoli pubblicati: $(wp post list --post_type=post --post_status=publish --format=count)"
echo "Pagine pubblicate: $(wp post list --post_type=page --post_status=publish --format=count)"
echo "Media in library: $(wp post list --post_type=attachment --format=count)"
echo "Utenti registrati: $(wp user list --format=count)"
echo "Commenti: $(wp comment list --format=count)"
echo ""
echo "--- Plugin ---"
wp plugin list --format=table
echo ""
echo "--- Performance ---"
wp db size --format=table
echo ""
echo "--- Aggiornamenti disponibili ---"
wp core check-update
echo "Plugin da aggiornare: $(wp plugin list --update=available --format=count)"
echo "Temi da aggiornare: $(wp theme list --update=available --format=count)"

} > $REPORT_FILE

cat $REPORT_FILE

Integrazione AI con MCP: casi d'uso reali

L'integrazione WP-CLI + AI tramite MCP è la novità più significativa del 2026. Ecco quattro casi d'uso reali che ho implementato su progetti di clienti.

Caso 1: refactoring automatico plugin

Un cliente aveva un plugin legacy con 8.000 righe di codice PHP misto a HTML, jQuery deprecato, e nessuno standard di coding. Con Claude Code connesso via MCP a WP-CLI, è stato possibile:

• Analizzare l'intero plugin con wp eval per capire la struttura
• Identificare pattern problematici con query al codice via MCP
• Riscrivere le sezioni critiche con prompt contestuali
• Testare le modifiche con wp eval e wp test
• Committare le modifiche con messaggi di commit descrittivi

Tempo risparmiato rispetto al refactoring manuale: circa 60%.

Caso 2: generazione contenuti editoriali

Un editore con 50 articoli/mese ha integrato WP-CLI con Claude per:

• Generare bozze di articoli partendo da brief in linguaggio naturale
• Ottimizzare SEO con analisi automatizzata delle keyword
• Generare excerpt, meta description, e tag automaticamente
• Revisionare il tono dei contenuti pubblicati

Caso 3: manutenzione predittiva

Un'agenzia che gestisce 30 siti WordPress ha implementato uno script che:

• Monitora uptime, performance, e aggiornamenti su tutti i siti
• Usa Claude per analizzare i log e identificare pattern anomali
• Genera ticket di manutenzione con diagnosi e soluzione suggerita
• Invia report settimanali con priorità di intervento

Caso 4: migrazione guidata WordPress 7.0

Per un cliente con 15 siti WordPress, è stato possibile:

• Analizzare plugin installati con wp doctor check plugin
• Identificare plugin incompatibili con WP 7.0
• Suggerire alternative moderne con AI
• Generare script di migrazione personalizzati per ogni sito
• Testare la migrazione in staging prima del go-live

Best practice operative

Le best practice che separano un uso amatoriale da un uso professionale di WP-CLI sono sette.

1. Sempre --dry-run prima di operazioni distruttive

# sempre dry-run prima
wp search-replace "old" "new" --dry-run
wp db query "DELETE FROM wp_options WHERE option_name LIKE '%transient%';" --dry-run

2. Backup prima di ogni operazione importante

# regola: backup -> verifica -> operazione
wp db export /tmp/pre-update-$(date +%Y%m%d).sql
wp plugin update --all

3. Usa --allow-root con cautela

Il flag --allow-root permette di eseguire WP-CLI come root (necessario in container Docker o ambienti CI). Va usato solo quando necessario, e mai in produzione interattiva.

4. Configura wp-cli.yml per il progetto

Il file wp-cli.yml nella root del progetto evita di specificare path e parametri ad ogni comando.

5. Usa le application password per CI/CD

Le application password (introdotte in WordPress 5.6) permettono di autenticare le API REST senza esporre la password principale. Per CI/CD e automazioni, sono la scelta sicura.

6. Log delle operazioni

In ambienti di produzione, logga tutte le operazioni WP-CLI con timestamp e operatore:

# esempio di logging
{
  echo "[$(date +%Y-%m-%d_%H:%M:%S)] Operatore: $(whoami)"
  echo "Comando: wp $*"
  wp "$@"
} >> /var/log/wp-cli.log

7. Test in staging prima di produzione

Qualsiasi script o comando complesso va testato in staging prima di essere eseguito in produzione. Il workflow è: sviluppo → staging → produzione, sempre.

Domande frequenti

WP-CLI è sicuro da usare in produzione?

Sì, se usato con criterio. Le regole fondamentali sono: backup prima di operazioni distruttive, dry-run prima di search-replace, test in staging prima di produzione, e logging di tutte le operazioni. Con queste pratiche, WP-CLI è più sicuro del browser admin perché è ripetibile e auditabile.

Qual è la differenza tra wp e wp --allow-root?

Il flag --allow-root permette di eseguire WP-CLI come utente root. È necessario in container Docker, ambienti CI/CD, o quando i permessi file non sono configurati correttamente. In ambienti di produzione interattiva, è meglio configurare i permessi corretti e usare WP-CLI come utente web (www-data, nginx, o equivalente).

Posso usare WP-CLI con WordPress Multisite?

Sì. WP-CLI supporta pienamente WordPress Multisite dalla versione 1.0. I comandi site-wide (es. wp plugin update --all --url=site1.com) permettono di operare su singoli siti del network. Il comando wp site list mostra tutti i siti del network, e wp site switch permette di cambiare il contesto operativo.

Come posso contribuire a WP-CLI?

WP-CLI è open source e accoglie contributi. Il repository ufficiale è github.com/wp-cli/wp-cli. I contributi più richiesti nel 2026 sono: testing, documentazione, nuovi comandi, e miglioramenti delle prestazioni. La community è su Slack (wp-cli.slack.com) e molto attiva.

WP-CLI sostituisce il pannello admin di WordPress?

No, e non è questo il suo scopo. WP-CLI è complementare al pannello admin: per task ripetitivi, automazioni, e operazioni di massa è imbattibile, ma per task occasionali e content editing, il pannello admin resta più ergonomico. La regola operativa è: usa il browser per i task uno-a-uno, usa WP-CLI per i task uno-a-molti.

Quali sono gli errori più comuni con WP-CLI?

I tre errori più frequenti sono: (1) operare nella directory sbagliata (sempre cd nella root di WordPress prima di usare WP-CLI), (2) dimenticare --allow-root in container Docker, (3) eseguire wp search-replace su serializzati senza il supporto nativo (usa sempre il comando ufficiale, non query SQL dirette). Tutti evitabili con le best practice descritte sopra.

WP-CLI funziona con hosting condivisi senza accesso SSH?

No, WP-CLI richiede accesso shell. Per hosting condivisi senza SSH, le alternative sono: usare il pannello admin (lento per task di massa), chiedere all'hosting di eseguire i comandi, o migrare a un hosting con accesso shell. Il prezzo di un hosting con SSH è ormai comparabile a quello degli hosting condivisi entry-level.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• WP-CLI官方网站 - sito ufficiale del progetto.
• WP-CLI Commands - reference completa comandi.
• WP-CLI GitHub - repository ufficiale.
• WP-CLI Package Index - indice pacchetti aggiuntivi.
• Model Context Protocol - specifica MCP.
• WordPress Application Passwords - guida API authentication.
• WP-CLI Docker - immagine Docker ufficiale.
• WordPress Coding Standards - standard di sviluppo.
• Workflow perfetto sviluppo web mrtux.it - framework 7 stadi.
• Plugin WordPress da evitare mrtux.it - lista plugin 2026.

Questa guida verrà aggiornata ad ogni release majeure di WP-CLI. WP-CLI 2.13 è previsto per l'autunno 2026 con miglioramenti alle performance, supporto per PHP 8.5, e nuovi comandi per l'integrazione AI. Per suggerimenti o correzioni, l'area commenti è aperta.