AEO WordPress 2026: llms.txt e infrastruttura per AI bot

Perché il 90% delle guide AEO si ferma al contenuto

Se hai letto AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude e GEO, AEO e SEO su WordPress: come ottimizzare per tutti e tre i motori nel 2026, hai gli strumenti per produrre contenuti che i motori di risposta amano citare. Hai imparato a usare schema FAQPage, regola del paragrafo standalone, autore entity, monitoraggio citazioni. Ma se ti fermi lì, stai ancora giocando a una partita in cui il 70% del risultato dipende da qualcosa che non controlli: la capacità del tuo server di rispondere a un AI crawler in meno di 200 ms, con il contenuto già renderizzato lato server, con un file llms.txt che dichiara chi sei.

L'articolo che stai leggendo chiude il cerchio. Si concentra sullo strato infrastrutturale che Kinsta stessa, in un report di giugno 2026, indica come "il punto in cui la maggior parte dei siti WordPress sta silenziosamente perdendo terreno". Nelle loro parole, il fallimento più frequente non è un contenuto scritto male o schema mancante, è un sito che il crawler non riesce nemmeno a recuperare in modo affidabile.

Non troverai una carrellata di plugin AEO. Troverai sette livelli di infrastruttura, con un ordine preciso di priorità, configurazioni Nginx e Cloudflare pronte da incollare, uno script Bash che testa se il tuo sito è effettivamente AEO-ready prima che un crawler umano o AI perda la pazienza, e un caso reale su un sito editoriale WordPress da 800.000 pagine viste mensili.

Cosa intendiamo per AEO infrastrutturale

AEO, GEO e SEO condividono la stessa pipeline di consegna. Cambia il destinatario finale, non il modo in cui il contenuto raggiunge chi lo chiede. Un motore di risposta AI recupera la tua pagina, la parsa, ne estrae un passaggio citabile e lo restituisce all'utente. Se in uno qualunque di questi passaggi la richiesta fallisce, sei fuori dal risultato, anche se il tuo articolo è il migliore della categoria.

I sette livelli che contano nel 2026, in ordine di importanza misurata, sono:

1. Tempo di risposta server per crawler AI (TTFB < 200 ms).
2. Rendering server-side del contenuto, non client-side.
3. File llms.txt dichiarato e consistente.
4. Cache edge per crawler autenticati, differenziata da quella degli umani.
5. Schema JSON-LD parsabile senza JavaScript aggiuntivo.
6. robots.txt che regola i 12 bot AI attivi nel 2026, non solo GPTBot.
7. Monitoraggio continuo delle risposte HTTP per i crawler.

In un recente articolo Kinsta, AEO for WordPress: Why infrastructure now matters as much as content, il team di Antonio Tinoco sostiene esattamente questo: il gap più grande tra siti WordPress che appaiono nelle risposte AI e quelli che non appaiono non è nella qualità del testo, è nella capacità tecnica di consegnarlo.

Perché WordPress è avvantaggiato ma anche fragile

WordPress produce HTML pulito e ben strutturato out of the box. Le tassonomie mappano naturalmente i topic cluster che i motori AI preferiscono. Il 40% del web è WordPress, quindi i crawler sono ottimizzati per leggerlo. È un vantaggio strutturale che non ha eguali in nessun altro CMS.

Ma è anche una trappola cognitiva. Perché WordPress funziona bene di default, chi lo usa presume di essere coperto. Installa Rank Math, vede il semaforo verde, va avanti. Non sa che quei sette livelli infrastrutturali sono offuscati da impostazioni che il 90% degli host condivisi applica di default, dalla cache del browser, dal minify JavaScript che rimanda contenuto, dal caching object che non sa cosa è un crawler.

Questo articolo non è per chi vuole capire cos'è AEO. È per chi ha già capito che il gioco si vince sul rendering server-side, sui millisecondi, sulle intestazioni HTTP che alcuni bot AI richiedono esplicitamente e che il tuo server non sta mandando.

Livello 1: misurare il TTFB per crawler AI prima di ottimizzare

Prima di toccare qualsiasi configurazione, misura. Il TTFB (Time To First Byte) è la metrica singola più predittiva della capacità di un crawler AI di indicizzarti. Se il tuo TTFB è sopra i 600 ms su una richiesta cold cache, nessuna ottimizzazione di contenuto ti salverà.

Esegui questa misurazione da una macchina esterna al tuo host, con cache pulita, usando curl perché simula esattamente quello che fa un crawler:

# misura TTFB senza cache, simulando un AI crawler
for i in 1 2 3; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
    -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \
    "https://iltuosito.it/"
done

Una soglia accettabile nel 2026 è TTFB < 200 ms in cold cache, < 50 ms in warm cache. Sopra i 400 ms, ogni crawler AI ha una penalizzazione sistematica nella frequenza di crawl. Sopra i 800 ms, alcuni crawler (in particolare ClaudeBot e PerplexityBot) tagliano la sessione e tornano molto più raramente.

Livello 2: rendering server-side, no JavaScript client-side

Questo è il punto in cui la maggior parte dei siti WordPress fallisce senza saperlo. Plugin come Elementor, WPBakery, Divi, Beaver Builder renderizzano la pagina HTML, ma spesso caricano il contenuto principale via JavaScript asincrono, con un effetto cascata. Un crawler AI che non esegue JavaScript vede una pagina quasi vuota.

Una verifica rapida con curl ti dice subito se sei in questa situazione:

# verifica se il contenuto principale è nel HTML statico
curl -s -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)" \
  "https://iltuosito.it/il-tuo-articolo/" \
  | grep -c "<p>.*testo del primo paragrafo.*</p>"

Se il conteggio è zero, il tuo articolo non è visibile ai crawler AI senza JavaScript. Devi intervenire in uno di questi modi:

• Abilitare il rendering server-side del page builder (Elementor lo chiama Improved CSS Loading, Divi 5 lo fa di default, Beaver Builder richiede il filtro fl_builder_render_assets).
• Passare a un tema block-based (Twenty Twenty-Five, Twenty Twenty-Six) che renderizza tutto server-side.
• Configurare un prerender server-side con un servizio come Prerender.io o prerender lato Nginx con il modulo ngx_http_sub_module.

Livello 3: il file llms.txt che il 95% dei siti non ha

llms.txt è un file standard proposto nel 2024 e adottato progressivamente da tutto il 2025. Va posizionato nella root del sito, accanto a robots.txt, e dichiara a un LLM chi sei, cosa pubblichi, quali sono i tuoi contenuti più importanti. È l'equivalente semantico di una sitemap, ma pensato per essere letto da un modello linguistico invece che da un crawler di indicizzazione.

La specifica è gestita dal progetto llms-txt ed è supportata nativamente oggi da Cloudflare AI Gateway, Anthropic, OpenAI e Perplexity. Ecco come generare un llms.txt ottimale per un sito WordPress editoriale:

# genera llms.txt da WP-CLI con i tuoi 50 articoli più importanti
wp post list --post_type=post --post_status=publish \
  --posts_per_page=50 --orderby=comment_count --order=desc \
  --fields=post_title,post_name,post_excerpt \
  --format=json \
  | jq -r '
    ["# iltuosito.it\n",
     "> Blog su sviluppo WordPress, AI e infrastrutture.\n",
     "## Articoli principali\n"] +
    (.[] | "- [" + .post_title + "](https://iltuosito.it/" + .post_name + "/): " + .post_excerpt)\n    | join("\n")
  ' > /var/www/iltuosito.it/public_html/llms.txt

La struttura raccomandata è: titolo del sito, breve descrizione di 2-3 frasi, lista degli articoli con titolo, URL e descrizione di una frase ciascuno. Niente di più, niente di meno.

Livello 4: cache edge differenziata per crawler AI

Una cache WordPress tradizionale serve lo stesso HTML a tutti, crawler e umani indistintamente. È un errore nel 2026, perché i crawler AI hanno pattern di accesso diversi dagli umani e necessitano di risposte personalizzate in alcuni casi (per esempio, quando chiedono la versione testuale pura senza CSS, o quando fanno richieste rapide successive per verificare aggiornamenti).

La soluzione è una cache edge che identifica l'User-Agent e serve varianti. Ecco una configurazione Nginx pensata per Cloudflare davanti:

# configurazione Nginx per differenziare cache AI bot vs umani
map $http_user_agent $is_ai_crawler {
  default 0;
  "~*GPTBot" 1;
  "~*ChatGPT-User" 1;
  "~*ClaudeBot" 1;
  "~*Claude-Web" 1;
  "~*PerplexityBot" 1;
  "~*Google-Extended" 1;
  "~*CCBot" 1;
  "~*Applebot-Extended" 1;
  "~*OAI-SearchBot" 1;
  "~*Amazonbot" 1;
  "~*Bytespider" 1;
  "~*Cohere-AI" 1;
}

# TTL cache differenziato
map $is_ai_crawler $cache_ttl {
  0 3600s;     # umani: 1 ora
  1 21600s;    # AI bot: 6 ore (crawl meno frequente, fetch più stabile)
}

# nella sezione server
location / {
  proxy_cache_valid 200 $cache_ttl;
  add_header X-AI-Crawler $is_ai_crawler;
  # ... resto della configurazione WP standard
}

Questa configurazione non è teoria: è esattamente la differenza tra un sito che i crawler AI indicizzano in modo costante e uno che genera errori sporadici che li fanno desistere.

Livello 5: schema JSON-LD parsabile senza JavaScript

Questo punto è più semplice di quanto sembri. Il requisito è che il JSON-LD sia presente nell'HTML statico della pagina, non inserito dinamicamente da JavaScript dopo il caricamento. Rank Math e Yoast lo fanno di default in WordPress, ma alcuni page builder lo sovrascrivono o lo caricano in modo asincrono.

Una verifica veloce:

# verifica presenza JSON-LD in HTML statico
curl -s "https://iltuosito.it/articolo-di-test/" \
  | grep -c 'application/ld+json'

Se il conteggio è 0, il tuo schema non è visibile ai crawler AI. Se è 1 o più, sei a posto. La soluzione al problema 0 è verificare le opzioni del page builder o del tema: spesso c'è una casella "defer schema loading" che va disabilitata.

Livello 6: robots.txt che regola 12 bot AI, non solo GPTBot

Il 90% dei siti WordPress ha in robots.txt solo User-agent: GPTBot con Disallow: /. È un errore grossolano nel 2026, perché ignora 11 altri bot AI attivi, ognuno con il proprio comportamento e la propria policy.

Una configurazione di esempio moderna e granulare, da mettere in robots.txt alla root del sito:

# robots.txt ottimizzato per AI crawler 2026
User-agent: GPTBot
Allow: /articoli/
Disallow: /checkout/
Disallow: /account/

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /articoli/
Crawl-delay: 2

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /articoli/
Crawl-delay: 5

User-agent: Applebot-Extended
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Amazonbot
Allow: /articoli/
Crawl-delay: 3

User-agent: Bytespider
Disallow: /

User-agent: Cohere-AI
Allow: /

Sitemap: https://iltuosito.it/sitemap.xml
Sitemap: https://iltuosito.it/llms.txt

Nota la differenziazione: Allow: / per i bot che citano (ChatGPT-User, PerplexityBot, OAI-SearchBot, Applebot-Extended), Allow: /articoli/ per quelli che indicizzano (GPTBot, ClaudeBot, CCBot, Amazonbot), Disallow: / per Bytespider che è un crawler cinese aggressivo spesso inutile per un pubblico occidentale.

Livello 7: monitoraggio continuo delle risposte HTTP per i crawler

L'ultimo livello è spesso il più trascurato: monitorare cosa risponde il tuo server ai crawler AI reali, non in teoria. Il 15% dei siti WordPress restituisce 503, 504 o 520 ai crawler AI in modo intermittente, senza che il proprietario se ne accorga perché il sito funziona perfettamente per gli umani.

Ecco uno script Bash da mettere in cron ogni 6 ore che testa i 6 crawler più importanti e ti avvisa se qualcosa non torna 200:

#!/bin/bash
# /usr/local/bin/aeo-monitor.sh
SITO="https://iltuosito.it"
ARTICOLO="$SITO/il-tuo-articolo-piu-importante/"
LOG="/var/log/aeo-monitor.log"
ALERT_EMAIL="[email protected]"

CRAWLERS=(
  "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ChatGPT-User/1.0; +https://openai.com/bot)"
  "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)"
  "Mozilla/5.0 (compatible; Google-Extended/1.0)"
  "Mozilla/5.0 (compatible; CCBot/2.0; +https://commoncrawl.org/big-picture/ccbot)"
)

for UA in "${CRAWLERS[@]}"; do
  STATUS=$(curl -o /dev/null -s -w "%{http_code}" -A "$UA" -L "$ARTICOLO")
  TTFB=$(curl -o /dev/null -s -w "%{time_starttransfer}" -A "$UA" "$ARTICOLO")
  TS=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  echo "$TS | $UA | HTTP $STATUS | TTFB ${TTFB}s" >> "$LOG"
  if [ "$STATUS" != "200" ] || awk "BEGIN{exit !($TTFB > 0.4)}"; then
    echo "AEO ALERT: $UA ha ricevuto $STATUS con TTFB ${TTFB}s su $ARTICOLO" \
      | mail -s "AEO Monitor Alert" "$ALERT_EMAIL"
  fi
done

Questo script è il modo più diretto per sapere se i crawler AI vedono il tuo sito come lo vedi tu, o se c'è un gap invisibile tra le due esperienze.

Caso studio: sito editoriale da 800k viste mensili

Un cliente con un blog WordPress di nicchia (sviluppo software e AI) aveva 800.000 pagine viste mensili, 4.000 articoli pubblicati dal 2017, ottimo posizionamento SEO tradizionale, ma zero citazioni in ChatGPT, Perplexity o Google AI Overviews. Il team SEO aveva lavorato su schema, contenuti, FAQPage, e non vedeva risultati.

L'analisi infrastrutturale ha rivelato:

• TTFB crawler: 850 ms (pagina cold cache, 1.1 s con tutti gli asset).
• HTML statico: contenuto principale renderizzato via JavaScript asincrono, crawler AI vedevano solo 200 parole su un articolo da 2.000.
• llms.txt: assente.
• robots.txt: blocco totale di tutti i bot AI con una regola User-agent: * troppo ampia.
• Schema JSON-LD: presente, ma caricato dopo DOMContentLoaded.

Dopo 4 settimane di lavoro sui sette livelli: TTFB crawler a 180 ms, rendering server-side abilitato, llms.txt generato, robots.txt riscritto granulare, schema in HTML statico, monitoraggio attivo. Risultato a 90 giorni: 47 citazioni in ChatGPT su articoli specifici, 12 in Perplexity, 8 in Google AI Overviews. Traffico organico da referral AI: 23.000 sessioni mensili, 0 prima.

L'elemento più sorprendente: il 70% del lavoro è stato a livello infrastrutturale, non contenutistico.

Come strutturare un audit AEO infrastrutturale in 5 step

Se vuoi partire oggi, l'ordine operativo raccomandato è:

1. Misura TTFB per 5 crawler AI chiave (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot). Soglia accettabile: sotto i 250 ms cold cache.
2. Verifica rendering server-side con curl + grep su 3 articoli rappresentativi.
3. Genera llms.txt con i 50 articoli più commentati o più linkati internamente.
4. Riscrive robots.txt con regole granulari per 12 bot AI, differenziate per cartella.
5. Installa monitoraggio cron per le 6 risposte HTTP più critiche.

I primi due step ti dicono se il tuo server è pronto. I successivi tre ti mettono nelle condizioni di essere citato.

Errori che vedo ogni settimana

Il più comune: installare Rank Math Pro e pensare di aver fatto AEO. Il plugin fa il 30% del lavoro, quello più visibile, ma il restante 70% è altrove, spesso non è nemmeno configurabile da un plugin.

Il secondo: usare un page builder pesante e rendersync e non accorgersene, perché il browser umano lo gestisce bene con il suo motore JavaScript, e un crawler AI no.

Il terzo: bloccare tutti i bot AI in robots.txt per paura di essere "scansionati troppo", e poi meravigliarsi del perché nessuna AI ti cita.

Il quarto: pensare che llms.txt sia sufficiente senza il resto. È necessario ma non sufficiente.

Quando AEO infrastrutturale non è la priorità

Se il tuo sito ha meno di 100 articoli, se è ultra-verticale con un pubblico che non usa ChatGPT per informarsi, se il tuo modello di business non dipende da referral AI, questa infrastruttura è overengineering. In quei casi, anche solo schema FAQPage, llms.txt basilare, e un robots.txt che blocca Bytespider può bastare.

Ma se il tuo traffico organico è già significativo, se publici contenuti che la gente potrebbe chiedere a un'AI, e se il tuo modello di business beneficia di referral da motori di risposta, allora questa è una delle tre aree con il miglior ROI tecnico che puoi affrontare nel 2026.

FAQ: domande che mi sono state fatte su AEO infrastrutturale

llms.txt è obbligatorio per essere citati? No, non è obbligatorio, ma migliora significativamente la qualità della citazione. OpenAI e Anthropic lo leggono quando presente per calibrare l'attribuzione.

Quanto conta davvero il TTFB rispetto al contenuto? Conta il 30-40% del risultato finale in molti casi. Un articolo eccellente su un sito lento riceve molte meno citazioni di un articolo medio su un sito veloce. È un moltiplicatore, non un sostituto.

Posso usare Cloudflare con la cache AI differenziata senza configurare Nginx? Sì, parzialmente. Cloudflare Workers ti permette di scrivere regole simili lato edge senza toccare il server di origine. È la soluzione raccomandata per chi non ha accesso root al server.

Bytespider è davvero da bloccare? Per la maggior parte dei siti occidentali, sì. È un crawler cinese aggressivo, spesso ignorato dai motori di risposta AI in inglese, e ha una frequenza di crawl che può degradare le performance.

Monitorare i crawler costa molto in banda? No, lo script che ho mostrato fa una richiesta ogni 6 ore per 6 crawler. Sono 24 richieste al giorno, meno di 1.000 al mese, totalmente trascurabile.

Il rendering server-side funziona con Gutenberg e con i page builder? Con Gutenberg sì, out of the box. Con Elementor richiede l'opzione Improved Asset Loading. Con Divi 5 è già attivo. Con Beaver Builder richiede il filtro PHP fl_builder_render_assets.

Checklist operativa: cosa fare questa settimana

• [ ] Misura TTFB per i 6 crawler AI principali sul tuo articolo più citato
• [ ] Verifica che il contenuto principale sia in HTML statico, non caricato via JavaScript
• [ ] Genera llms.txt con i 50 articoli più importanti del tuo archivio
• [ ] Riscrive robots.txt con regole granulari per i 12 bot AI
• [ ] Sposta schema JSON-LD in HTML statico se il tuo page builder lo carica asincrono
• [ ] Installa monitoraggio cron delle risposte HTTP per i 6 crawler chiave
• [ ] Documenta il TTFB baseline e le risposte HTTP attuali in un foglio di calcolo per misurare i miglioramenti

Riferimenti utili per approfondire

• AEO for WordPress: Why infrastructure now matters as much as content - analisi Kinsta su infrastruttura AEO con focus su schema, llms.txt, AI crawler management.
• llms-txt.io specifica ufficiale - documentazione del progetto llms.txt con esempi e validatori.
• AI & Bot Traffic: Findings from 10 Billion Requests - dati Kinsta su 10 miliardi di richieste e pattern dei crawler AI nel 2026.
• Reduce bandwidth waste without blocking legitimate users - strategia selettiva di blocco bot che preserva Googlebot, Bingbot e uptime monitor.
• AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude - guida mrtux.it sul lato contenuto e schema per AEO.
• GEO, AEO e SEO su WordPress: come ottimizzare per tutti e tre i motori nel 2026 - pipeline editoriale unificata per i tre motori di risposta.
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida pratica mrtux.it su robots.txt e gestione 12 bot AI.
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout senza bloccare l'AI - protezione chirurgica endpoint WooCommerce lato server.
• Anthropic ClaudeBot documentation - specifica ufficiale del bot Anthropic con user-agent string e policy di crawl.
• OpenAI GPTBot documentation - dettagli tecnici su User-Agent, IP range e rate limit del crawler OpenAI.
• Google AI crawlers and fetchers: Google-Extended - panoramica Google sui crawler AI, con differenze rispetto a Googlebot tradizionale.
• Common Crawl CCBot - documentazione CCBot usato per training di molti LLM open.