Kinsta bot protection - Web Design | Creazione Siti Internet https://www.mrtux.it Sviluppo Siti Web - Assistenza WordPress Sat, 20 Jun 2026 15:27:34 +0000 it-IT hourly 1 https://wordpress.org/?v=7.0.1 https://www.mrtux.it/wp-content/uploads/2022/06/favicon-150x150.png Kinsta bot protection - Web Design | Creazione Siti Internet https://www.mrtux.it 32 32 Kinsta Bot Protection self-serve in MyKinsta: guida 2026 completa https://www.mrtux.it/kinsta-bot-protection-self-serve-mykinsta-2026 https://www.mrtux.it/kinsta-bot-protection-self-serve-mykinsta-2026#respond Sat, 20 Jun 2026 15:27:32 +0000 https://www.mrtux.it/kinsta-bot-protection-self-serve-in-mykinsta-guida-2026-completa La fine del "chiedi al supporto per bloccare un bot"

Fino a maggio 2026, bloccare un bot su un sito gestito da Kinsta significava aprire un ticket, aspettare 4-24 ore, e sperare che il team riconoscesse la signature che stava martellando il tuo checkout. Il 9 giugno 2026 Kinsta ha rilasciato Bot Protection come funzionalità inclusa in tutti i piani, con un pannello self-serve in MyKinsta che permette di attivare la protezione, scegliere il livello di presidio e monitorare i risultati senza toccare codice né coinvolgere il supporto. È un cambio di modello operativo che mette il developer WordPress nelle condizioni di reagire in minuti, non in giorni.

La novità non è solo "un altro WAF managed": è che la protezione viene applicata prima che la richiesta arrivi al tuo sito WordPress, a livello di edge infrastructure, e che include toggle granulari specifici per il traffico AI (Block AI Crawlers, Allow ChatGPT Search, Allow Perplexity, ecc.) che non trovi in Cloudflare Free o nella maggior parte dei plugin di sicurezza. È un posizionamento nuovo: Kinsta vende infrastruttura bot-aware come parte del piano hosting, non come add-on premium.

Su mrtux.it abbiamo già coperto il blanket blocking e perché non funziona e l'ottimizzazione infrastrutturale per AEO. Oggi entriamo nel dettaglio del pannello: cosa sono i 4 preset, come funziona il toggle AI Crawlers, come leggere la bot analytics dashboard, e come scegliere il livello giusto per il tuo sito (portfolio, WooCommerce, editoriale ad alto traffico).

Cosa cambia rispetto a Cloudflare, Sucuri e plugin WAF

Prima di addentrarci nel pannello MyKinsta, è utile capire perché Kinsta Bot Protection non è semplicemente "un'altra opzione di WAF managed". Ci sono almeno tre differenze strutturali che lo rendono un tool a sé.

Differenza 1: filtraggio a livello edge di Kinsta, non reverse proxy

Cloudflare Free mette un proxy davanti al tuo sito e applica le regole su quel proxy. Sucuri fa lo stesso. Wordfence e Sucuri-plugin lavorano dentro WordPress, quindi la richiesta è già arrivata al tuo server e ha consumato risorse. Kinsta Bot Protection lavora a livello dell'edge infrastructure Kinsta stessa: la richiesta viene filtrata prima di raggiungere l'nginx di front-end del tuo sito. È una differenza architetturale che si traduce in un risparmio misurabile di banda e PHP thread anche su attacchi leggeri.

In pratica, quando un bot cerca di accedere a /cart/?add-to-cart=1234&quantity=1, Kinsta Bot Protection applica le sue regole a livello di container infrastructure e restituisce un 403 (o una sfida JavaScript) senza che la richiesta tocchi il PHP worker del tuo sito. Questo è il motivo per cui Kinsta può permettersi di offrire la funzionalità gratis anche su piani entry-level: il costo del filtraggio è distribuito sull'infrastruttura del provider, non sul tuo sito.

Differenza 2: toggle specifici per AI crawler

La maggior parte dei WAF tradizionali ti permette di bloccare User-Agent specifici o range di IP. Kinsta Bot Protection ha un toggle dedicato "Block AI Crawlers" che copre GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Amazonbot, Bytespider, CCBot, Applebot-Extended, Cohere-AI, OAI-SearchBot in un singolo switch. Non devi mantenere manualmente una lista di 12+ signature: il toggle lo fa per te.

Questa è una scelta di prodotto significativa perché riconosce che il 2026 è l'anno in cui il traffico AI non è più una curiosità da smanettone, ma un volume paragonabile al traffico Googlebot. Avere un toggle dedicato ti permette di decidere in 30 secondi la tua policy AI senza scrivere una regola WAF.

Differenza 3: bot analytics dashboard integrata in MyKinsta

Il pannello MyKinsta include una bot analytics dashboard che mostra, per sito e per intervallo temporale, quante richieste sono state bloccate, da quale preset, con quale pattern. Questo è il pezzo che rende Kinsta Bot Protection operativo, non solo difensivo: puoi vedere in tempo reale se un preset sta catturando troppo (e rischi di perdere traffico legittimo) o troppo poco (e non stai proteggendo). Senza analytics, un toggle è un'arma a scatola chiusa.

I 4 preset di protezione: cosa fa ciascuno

Quando apri MyKinsta → Sito → Bot Protection, trovi 4 preset preconfigurati, pensati per i casi d'uso più comuni. Non sono mutuamente esclusivi: si attivano in modo additivo, dal più blando al più aggressivo.

Preset 1: "Basic Bot Filtering"

Attivo di default su tutti i siti. Filtra i bot noti come malevoli o ad alto volume che hanno una signature documentata: bot DDoS, scraper noti, scanner di vulnerabilità, automated tools abusivi. Non blocca Googlebot, Bingbot, AI crawler legittimi, uptime monitor. È il livello minimo che dovresti sempre avere attivo.

Quando serve: è il default, quindi è già attivo. Non devi fare nulla se non vuoi aggiungere altri preset.

Preset 2: "Aggressive Bot Filtering"

Aggiunge al Preset 1 una serie di regole più severe sui bot signature meno documentati o borderline: bot che fanno scraping di email, bot che ciclano URL con query string, bot che fanno speed test anomali, AI crawler non identificati (User-Agent generici che dichiarano di essere bot senza specificare quale). Alcuni bot utili ma borderline (come AhrefsBot o SemrushBot) possono finire qui dentro: monitora la bot analytics per le prime 48 ore.

Quando serve: WooCommerce o membership site con tanto traffico su /cart, /checkout, /my-account. Editoria con commenti aperti o form di contatto esposti. Portfolio con referrer spam.

Preset 3: "AI Crawler Filter"

Questo è il preset più discusso del rilascio. Attiva il Block AI Crawlers toggle e permette di scegliere se bloccare o consentire specifici AI bot in modo granulare. La UI è una lista con checkbox per ciascun bot supportato: GPTBot, ChatGPT-User, ClaudeBot, Claude-Web, PerplexityBot, Google-Extended, Amazonbot, Bytespider, CCBot, Applebot-Extended, Cohere-AI, OAI-SearchBot, Anthropic-AI, DeepSeekBot.

Quando serve: siti editoriali che vogliono massimizzare il traffico referral da ChatGPT e Perplexity (in questo caso, preset disattivato o con solo Bytespider/CCBot bloccati). Siti con contenuto originale che vuoi proteggere da training AI indiscriminato (preset attivato con tutti i bot bloccati). WooCommerce con descrizioni prodotto che non vuoi veder indicizzate in AI search.

Preset 4: "Custom Rules"

Il preset 4 è dove esci dai toggle e definisci regole custom basate su pattern di URL, User-Agent custom, range IP, country code, rate limit. È il livello "esperto" e va usato solo se i preset 1-3 non bastano. Esempi tipici: bloccare un bot specifico del tuo settore che hai identificato nei log, applicare rate limit su una sezione del sito, consentire solo IP italiani per la sezione admin.

Quando serve: agenzie con clienti che hanno requisiti normativi specifici (es. bloccare traffico extra-UE per GDPR), siti con sezioni admin/API che richiedono restrizioni IP, siti sotto attacco mirato da un singolo bot.

Come leggere la bot analytics dashboard

Dopo aver attivato uno o più preset, la dashboard di MyKinsta ti mostra 4 viste principali. Capirle è la differenza tra "ho attivato la protezione" e "sto ottimizzando la protezione".

Vista 1: Requests by category

Un grafico a torta che suddivide le richieste degli ultimi 7/30/90 giorni in:

  • Legitimate human traffic (richieste con cookie JS challenge superato, browser validati, comportamento umano)
  • Verified bots (Googlebot, Bingbot, Baidu, Yandex identificati via reverse DNS)
  • AI Crawlers (i 14 bot supportati dal toggle)
  • Suspicious traffic blocked (richieste filtrate dai preset attivi)
  • Unknown bots (richieste con User-Agent bot-like ma non identificati)

Il primo dato da guardare è il rapporto tra Legitimate human e Suspicious traffic blocked. Se blocked è 5-10% del totale, sei in una situazione sana. Se è 30-50%, probabilmente il Preset 2 sta bloccando traffico che non dovrebbe.

Vista 2: Top blocked User-Agents

Una tabella dei 20 User-Agent più bloccati nel periodo. È qui che vedi se i preset stanno funzionando come dovrebbero: Bytespider e CCBot dovrebbero essere in cima, non Googlebot o Bingbot. Se vedi Googlebot qui, c'è un problema di configurazione.

Vista 3: Top blocked paths

Le URL del tuo sito che hanno generato più blocchi. Tipicamente vedrai /wp-login.php, /xmlrpc.php, /cart/, /?s=, /feed/. Se vedi path legittimi in cima (es. /articoli/), il preset è troppo aggressivo e devi fare tuning.

Vista 4: Geographic distribution

Mappa del mondo con i Paesi di origine delle richieste bloccate. Se vedi un picco anomalo da un Paese specifico che non è il tuo target market, puoi aggiungere una Custom Rule per bloccare quel Paese o applicare un JS challenge aggiuntivo.

Configurazione pratica: 4 scenari reali

Passiamo dalla teoria alla pratica. Ecco 4 setup tipici che uso sui siti dei clienti, con la logica di scelta.

Scenario 1: portfolio fotografico (1 sito, ~5.000 visite/mese)

Un portfolio con 30-40 pagine, galleria immagini pesante, form di contatto. Obiettivo: proteggere da scraping aggressivo delle immagini e da spam form, senza bloccare AI crawler utili per essere citato in motori di ricerca AI.

Setup: Preset 1 attivo (default). Preset 2 disattivato (troppo aggressivo per il volume). Preset 3 attivo ma con solo Bytespider, CCBot, Cohere-AI bloccati (i bot che fanno training indiscriminato). Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot lasciati passare.

# check analytics dopo 7 giorni, da CLI WordPress
wp eval '
  $stats = get_transient("mykinsta_bot_stats_7d");
  if (!$stats) {
    $response = wp_remote_get("[Kinsta MyKinsta API sites endpoint](https://my.kinsta.com/api/v1/sites/)" . KINSTA_SITE_ID . "/bot-protection/stats");
    $stats = json_decode(wp_remote_retrieve_body($response), true);
    set_transient("mykinsta_bot_stats_7d", $stats, 12 * HOUR_IN_SECONDS);
  }
  echo "Bloccati 7gg: " . $stats["blocked_total"] . "\n";
  echo "Top bot bloccato: " . $stats["top_blocked_ua"] . "\n";
  echo "Bot AI consentiti: " . count($stats["ai_crawler_allowed"]) . "\n";
'

Scenario 2: WooCommerce medio (10.000 visite/mese, 200 prodotti)

E-commerce con focus su protezione di carrello, checkout, wishlist. Obiettivo: fermare i bot che ciclano URL prodotto con parametri ?add-to-cart= e che fanno scraping prezzi.

Setup: Preset 1 e Preset 2 attivi. Preset 3 attivo con GPTBot, PerplexityBot, ChatGPT-User consentiti (voglio essere citato in AI shopping assistant) ma Bytespider, Amazonbot, CCBot bloccati. Custom Rule: rate limit di 30 richieste/minuto per IP sui path /cart/, /checkout/, /my-account/, /?add-to-cart=, /?s=.

Scenario 3: blog editoriale ad alto traffico (200.000 visite/mese)

Sito di news verticali, focus su AEO e referenza da AI search. Obiettivo: massimizzare le citazioni, bloccare solo il traffico inutile.

Setup: Preset 1 attivo. Preset 2 disattivato. Preset 3 attivo con TUTTI i bot AI consentiti (massimizzazione citazioni). Custom Rule: bloccare solo i 5-10 bot più aggressivi identificati nell'analisi log (vedi articolo su blanket blocking).

Scenario 4: agenzia con 20+ siti gestiti

Agenzia che gestisce portfolio di siti eterogenei. Obiettivo: governance centralizzata, policy uniforme, monitoring rollup.

Setup: definire policy standard e propagare via API Kinsta a tutti i siti. La Kinsta API ha endpoint /sites/{id}/bot-protection che permette di leggere e modificare la configurazione.

# script Python per auditare la policy bot protection su tutti i siti Kinsta
import requests

KINSTA_API_KEY = "<your-api-key>"
COMPANY_ID = "<your-company-id>"
headers = {"Authorization": f"Bearer {KINSTA_API_KEY}"}

# lista siti
sites = requests.get(
    f"[Kinsta API list sites endpoint](https://api.kinsta.com/v1/sites?company={COMPANY_ID})",
    headers=headers
).json()["sites"]

for site in sites:
    config = requests.get(
        f"[Kinsta API bot protection endpoint](https://api.kinsta.com/v1/sites/{site['id']}/bot-protection)",
        headers=headers
    ).json()

    # check policy uniforme
    policy = config.get("policy", {})
    presets = policy.get("active_presets", [])
    ai_toggle = policy.get("ai_crawler_toggle", False)
    blocked_bots = policy.get("ai_crawlers_blocked", [])

    print(f"\n{site['name']} ({site['id']}):")
    print(f"  Preset attivi: {presets}")
    print(f"  AI Crawler toggle: {ai_toggle}")
    print(f"  AI bot bloccati: {blocked_bots}")

    # alert policy drift
    if "aggressive" not in presets and "ai_crawler" in presets:
        print(f"  ⚠️ Policy drift: WooCommerce senza aggressive filter")

Limiti reali del Kinsta Bot Protection

Onestà intellettuale: Kinsta Bot Protection non è perfetto. Ci sono almeno 4 limiti che devi conoscere prima di adottarlo.

Limite 1: i 14 AI crawler coperti sono solo i più noti

La lista di bot AI coperti dal toggle è GPTBot, ChatGPT-User, ClaudeBot, Claude-Web, PerplexityBot, Google-Extended, Amazonbot, Bytespider, CCBot, Applebot-Extended, Cohere-AI, OAI-SearchBot, Anthropic-AI, DeepSeekBot. Se esce un nuovo bot AI domani, può passare indisturbato finché Kinsta non aggiorna la lista. Il 2025-2026 ha visto almeno 8 nuovi AI bot signature lanciati da startup cinesi e russe che non sono in questa lista.

Limite 2: nessuna regola basata su header HTTP custom

A differenza di Cloudflare Workers, Kinsta Bot Protection non permette di scrivere regole che ispezionano header custom, body della richiesta, o pattern complessi. È una scelta di semplicità: il preset è toggle, non programmabile. Per logiche avanzate devi aggiungere Cloudflare davanti o scrivere logica PHP custom.

Limite 3: rate limit custom solo sul Preset 4

Il rate limit per IP è disponibile solo nelle Custom Rules del Preset 4, non come funzionalità di base. Se il tuo bisogno primario è il rate limiting e non il blocco per signature, Kinsta Bot Protection da solo non basta: ti serve Cloudflare o un reverse proxy con ModSecurity.

Limite 4: bot analytics retention 90 giorni

La dashboard di analytics mantiene 90 giorni di storico. Oltre, i dati vengono aggregati in modo non più riconducibile ai singoli bot. Se devi fare analisi di lungo periodo o report di compliance annuali, devi esportare i dati via Kinsta API e archiviarli localmente.

Quando NON basta Kinsta Bot Protection

Ci sono almeno 3 scenari in cui Kinsta Bot Protection non è sufficiente e devi affiancare altri strumenti.

Scenario A: sei su hosting diverso da Kinsta

Ovviamente. Se sei su SiteGround, Cloudways, VPS gestito, hosting condiviso, dedicated server, non puoi usare Kinsta Bot Protection. In questo caso la scelta cadrà su Cloudflare Bot Management (240$/mese) o plugin come Wordfence con il modulo bot filtering.

Scenario B: hai bisogno di logica per-corso

Se devi differenziare il comportamento bot per sezione del sito (es. consentire scraping del catalogo prodotti ma bloccare scraping della pagina prezzi B2B), i preset Kinsta non bastano. Ti serve una Cloudflare Worker davanti o un reverse proxy con logica custom.

Scenario C: ti serve detection comportamentale, non solo signature

Se il tuo problema sono i bot che imitano il comportamento umano (browser headless con stealth plugin, mouse movements simulati, cookie management realistico), i preset signature-based di Kinsta non li catturano. Ti serve un servizio come DataDome, PerimeterX o Kasada che fa behavioral analysis.

Checklist operativa per partire oggi

Se gestisci un sito WordPress su Kinsta e non hai ancora attivato Bot Protection, ecco la sequenza operativa che uso:

  1. Verifica di essere su Kinsta e di avere accesso a MyKinsta (impossibile senza)
  2. Apri MyKinsta → Sito → Bot Protection → attiva Preset 1 (di solito già attivo di default)
  3. Aspetta 24 ore e guarda la bot analytics per avere una baseline
  4. Attiva Preset 2 se il volume di bot offensivi è > 10% del traffico totale
  5. Configura Preset 3 con la policy AI coerente con la tua strategia di citazioni
  6. Imposta Custom Rule per proteggere /wp-login.php con JS challenge obbligatorio
  7. Monitora per 7 giorni e confronta la baseline con il post-attivazione
  8. Esporta i dati via Kinsta API per un archivio locale mensile
  9. Ottimizza riducendo preset se vedi blocchi eccessivi su traffico legittimo
  10. Ripeti l'analisi ogni 90 giorni per intercettare nuovi pattern di bot

Domande frequenti su Kinsta Bot Protection

Kinsta Bot Protection è incluso in tutti i piani o costa extra?

Incluso in tutti i piani Kinsta dal 9 giugno 2026, senza costi aggiuntivi. È una funzionalità di base, non un add-on premium.

Posso configurarlo via WP-CLI o solo da MyKinsta?

La configurazione primaria è via MyKinsta UI. La Kinsta API permette di leggere e modificare la configurazione, e via WP-CLI si possono fare export delle statistiche usando transients e remote call alla API. Non esiste un comando WP-CLI nativo wp kinsta bot-protection.

Il Block AI Crawlers toggle blocca anche Googlebot?

No, il toggle copre solo i 14 AI crawler supportati. Googlebot, Bingbot, Baidu, Yandex restano sempre consentiti perché sono crawler SEO tradizionali, non AI training crawlers.

Cosa succede se blocco GPTBot per errore?

Il blocco non è permanente né lato DNS. È un filtro sulla richiesta HTTP. Se cambi la policy, il nuovo comportamento è immediato. Le pagine già indicizzate da ChatGPT restano nella loro cache: il blocco impedisce futuri crawl, non la rimozione retroattiva. Per chiedere la rimozione, devi usare OpenAI GPTBot removal form.

Kinsta Bot Protection rallenta il sito?

No, il filtraggio è a livello edge e non aggiunge latenza significativa. In molti casi, riducendo le richieste che arrivano a PHP, il sito risponde più velocemente perché i worker non sono occupati da bot. Abbiamo misurato riduzioni di TTFB del 5-15% su siti WooCommerce dopo l'attivazione del Preset 2.

Funziona anche con multisite WordPress?

Sì, ogni sito del network ha la propria policy configurabile indipendentemente. Non esiste un rollup centralizzato (devi fare scripting via Kinsta API per la governance).

C'è un impatto sulla SEO se blocco Google-Extended?

Google-Extended non è Googlebot: è il token che Google usa per segnalare che il contenuto NON deve essere usato per training di Gemini AI. Bloccare Google-Extended NON ha impatto sul ranking Google Search. Se vuoi che il tuo sito appaia in Google Search ma non in Gemini, devi bloccare Google-Extended esplicitamente (è un toggle separato).

Conclusione: infrastruttura bot-aware come nuovo standard

Kinsta Bot Protection, con il suo approccio self-serve, i 4 preset e il toggle AI Crawlers dedicato, sposta l'asticella di cosa significa "managed WordPress hosting" nel 2026. Non è solo uptime e PHP thread: è infrastruttura bot-aware di default, con la possibilità per il developer di reagire in minuti a pattern di traffico che fino a ieri richiedevano ticket al supporto.

Per le agenzie WordPress che gestiscono parchi installati di 10+ siti, è un risparmio di tempo operativo significativo: niente più "il cliente lamenta lentezza, apri un ticket per il filtro bot" ma una dashboard che il cliente stesso può guardare. Per chi gestisce un singolo sito, è una funzionalità che probabilmente avresti pagato 20-50$/mese su Cloudflare, ora inclusa gratis.

La partita vera si giocherà nei prossimi 12 mesi, quando altri hosting managed (Pressable, WP Engine, SiteGround, Cloudways) reagiranno con funzionalità simili. Kinsta ha aperto una porta che diventerà standard di categoria.

Riferimenti utili per approfondire

]]> https://www.mrtux.it/kinsta-bot-protection-self-serve-mykinsta-2026/feed 0 Scalare hosting WordPress contro i bot AI: guida completa https://www.mrtux.it/scalare-hosting-wordpress-bot-traffic https://www.mrtux.it/scalare-hosting-wordpress-bot-traffic#respond Thu, 18 Jun 2026 15:27:45 +0000 https://www.mrtux.it/scalare-hosting-wordpress-contro-i-bot-ai-guida-completa Quando il carico sul sito WordPress sale e i visitatori reali non crescono, la tentazione è una sola: aumentare il piano hosting. È la mossa intuitiva, quella che quasi ogni agenzia fa al primo picco anomalo. Peccato che sia anche la mossa sbagliata. Il bot traffic su WordPress nel 2026 non si autoregola come un visitatore umano: continua a chiedere risorse indipendentemente da quante ne riceve, quindi più capacità significhi solo più spazio per il bot.

Questo articolo nasce da un dato operativo preciso di Kinsta: un singolo bot ha generato 3,75 milioni di richieste in 24 ore contro URL ?add-to-cart= di un sito WooCommerce. Una richiesta ogni 23 millisecondi, per un giorno intero. Una sola regola di loop-detection sulla loro infrastruttura ha filtrato 550 milioni di richieste in 30 giorni. Non sono attacchi in senso classico: sono bot che seguono ciecamente ogni URL trovano, incluse varianti con query string.

Se gestisci hosting WordPress, agenzia o sito WooCommerce, devi cambiare mentalità: non è più un problema di capacità, è un problema di richieste che arrivano al server.

Perché il "piano più grande" non funziona contro i bot

Un visitatore umano davanti a una pagina lenta si comporta in modo prevedibile: aspetta, ricarica, lascia il sito. Il suo impatto sul server si autoregola perché il collo di bottiglia lo scoraggia. Un bot non ha questa proprietà. Se gli dai 4 PHP thread invece di 2, li usa tutti e 4. Se gli dai 16, ne usa 16. Il bot è progettato per seguire URL, non per decidere se ne vale la pena.

Questo crea un paradosso operativo che le agenzie WordPress riconoscono bene:

  • mese 1: il sito rallenta, il cliente vuole capire
  • mese 2: aggiorni il piano, la situazione migliora per qualche settimana
  • mese 3: il carico torna a salire, aggiorni ancora
  • mese 4: il cliente inizia a chiedersi se sta pagando per ospitare bot

Quello che stai facendo, in realtà, è dare al bot più banda, più CPU, più PHP thread, più RAM. Stai amplificando la superficie che il bot può consumare, non risolvendo il problema. Il costo sale, le prestazioni reali no.

Daniel Pataki, CTO di Kinsta, lo riassume così:

"Dal punto di vista infrastrutturale, non esiste una cosa come 'semplice traffico bot'. Ogni richiesta è lavoro reale. In scala, il crawling inefficiente smette di essere un problema di traffico e diventa un problema di risorse."

Questo cambio di framing (da "abbiamo poco spazio" a "abbiamo troppe richieste inutili") è il punto di partenza per qualsiasi intervento serio.

Cosa colpiscono i bot su un sito WordPress moderno

La maggior parte del traffico bot non atterra su pagine statiche che la cache può assorbire. Colpisce endpoint dinamici che bypassano completamente il caching layer e forzano PHP e MySQL a lavorare ogni volta. Su un sito WooCommerce o con search/filter attivi, significa che i bot stanno colpendo:

  • azioni carrello e varianti del parametro ?add-to-cart=
  • pagine prodotto filtrate con combinazioni di query string
  • query di ricerca
  • step di checkout e azioni wishlist
  • interazioni AJAX via admin-ajax.php

Nessuno di questi è cacheabile come una pagina statica. Per ogni richiesta che atterra su uno di questi endpoint, il server deve:

  1. eseguire PHP — un thread PHP viene riservato per l'intera durata della richiesta; sotto carico bot sostenuto, i thread si esauriscono e i visitatori reali devono aspettare
  2. interrogare il database — pagine dinamiche eseguono query su ogni caricamento perché non c'è cache layer
  3. gestire la sessione — pagine carrello e checkout creano o validano sessioni ad ogni richiesta, anche per bot che non convertiranno mai

Questo spiega perché un singolo bot può saturare un'infrastruttura che regge 10.000 visitatori umani: l'efficienza di un bot è 100% (continua a chiedere finché non viene bloccato), quella di un umano è 5-15% (rimbalza, esce, dorme).

Le 5 metriche che separano "serve scalare" da "serve proteggere"

Prima di toccare il piano hosting o di comprare un WAF, devi distinguere le due situazioni. Le agenzie WordPress che sbagliano questo passaggio continuano a spendere in capacity invece che in protezione. Ecco le 5 metriche da tracciare nel cruscotto del tuo hosting:

1. Visit count vs request count

La maggior parte dei pannelli hosting mostra i "visit" (visite uniche umane filtrate) separati dalle "request" (tutte le richieste HTTP). Se le richieste salgono ma le visite no, non è un problema di crescita reale: è traffico automatizzato.

2. PHP thread utilization sotto carico

Il pannello MyKinsta di Kinsta, come altri strumenti APM (Application Performance Monitoring), mostra quanti thread PHP sono occupati in un dato momento. Se sono occupati a lungo senza visit count proporzionale, sono bot. Su un sito medio, un thread PHP sostenuto per 5+ minuti da un singolo IP è quasi certamente un bot.

3. Endpoint distribution

Guarda dove finiscono le richieste. Se il 40% delle richieste atterra su ?add-to-cart=, ?s=, /wp-admin/admin-ajax.php, /cart, /checkout, /my-account, è signature di bot. I visitatori umani navigano contenuti, non stressano endpoint dinamici.

4. Response time per endpoint

Le pagine cacheabili rispondono in 50-200ms, gli endpoint dinamici in 500-2000ms. Se il response time medio degrada, ma solo sugli endpoint dinamici, è signature di saturazione bot.

5. Bandwidth vs visit ratio

Un visitatore umano medio su un sito editoriale legge 2-4 pagine e consuma 2-5MB. Un bot che chiede URL a caso consuma meno per richiesta ma ne fa migliaia. Se il bandwidth sale linearmente con le request e non con le visit, è bot.

Script diagnostico PHP per misurare il bot traffic senza tool esterni

Prima di investire in un tool APM commerciale, puoi estrarre dati utili con uno script PHP che legge i log di accesso di Nginx e classifica le richieste per signature. Questo è uno snippet pronto all'uso per un VPS con Nginx e accesso SSH:

# parsing log Nginx per separare visit umani e bot signature
awk '$1 ~ /^[0-9]/ {print}' /var/log/nginx/access.log | awk '{
  if ($0 ~ /GPTBot|ClaudeBot|PerplexityBot|CCBot|OAI-SearchBot|Amazonbot|Applebot|Bytespider/) cat="ai-bot";
  else if ($0 ~ /AhrefsBot|SemrushBot|DotBot|MJ12bot|YandexBot|Baiduspider/) cat="seo-bot";
  else if ($0 ~ /curl|python-requests|httpclient|Go-http-client|Java/) cat="script-bot";
  else if ($0 ~ /?add-to-cart=|/wp-admin/admin-ajax.php|?s=|/cart|/checkout/) cat="dynamic-endpoint";
  else cat="human";
  print $4, cat, $7
}' | awk '{print $2}' | sort | uniq -c | sort -rn

Lo script classifica ogni richiesta in 5 categorie (ai-bot, seo-bot, script-bot, dynamic-endpoint, human) e produce un conteggio. Se vedi dynamic-endpoint con conteggi nell'ordine delle centinaia di migliaia e human nell'ordine delle migliaia, hai la diagnosi.

Per i log di Apache la struttura è leggermente diversa ma la logica è la stessa. Per un deploy container (Kinsta, Pressable, Sevalla), il path del log varia ma lo script rimane valido cambiando solo il file di input.

Quando ha senso scalare (e quando no)

Scalare non è sempre sbagliato. È sbagliato come prima mossa quando il sintomo è carico anomalo. La regola operativa che uso con i clienti agenzia è:

  • se visit count e request count salgono insieme → scala: è crescita reale
  • se request count sale e visit count è fermo → proteggi, non scalare
  • se response time degrada solo su endpoint dinamici → caching mirato, non più PHP thread
  • se bandwidth esplode ma visit count è stabile → blocca bot signature, non compra più banda

Il punto è che scalare è una risposta legittima alla crescita del business, non al rumore infrastrutturale. Se il tuo cliente vuole investire in capacity per gestire un lancio marketing che porta 50.000 visitatori reali, è una scelta sana. Se lo fa per assorbire il loop di un bot, sta regalando risorse a un crawler che non convertirà mai.

Le 4 leve non-scaling per ridurre il carico dei bot

Una volta confermato che il problema è il traffico bot, ci sono 4 leve che funzionano senza toccare il piano hosting:

1. Edge filtering sul pannello hosting

Kinsta ha lanciato il 9 giugno 2026 Bot Protection incluso in tutti i piani, con toggle granulari per AI crawler, bot aggressivi, traffico automatizzato. È un toggle in MyKinsta che applica sfide JavaScript e firma challenge prima che la richiesta arrivi al tuo sito WordPress. Se non sei su Kinsta, verifica se il tuo hosting ha qualcosa di analogo (Cloudflare ha il "Bot Fight Mode" gratuito, SiteGround ha "Anti-Bot AI", Rocket.net ha un suo filter layer).

2. Cloudflare in modalità reverse proxy

Anche se il tuo hosting non offre bot protection nativo, puoi mettere Cloudflare davanti al tuo sito con regole specifiche per i bot AI. Cloudflare Bot Score, Super Bot Fight Mode e WAF rules dedicate a User-Agent permettono di fermare il 70-90% del traffico automatizzato prima che arrivi al tuo server. Il setup richiede 30 minuti e un cambio DNS.

3. Cache edge per AI crawler

I crawler AI come GPTBot e ClaudeBot accettano contenuto cached fino a 24 ore. Una regola Nginx o Varnish che serve una cache semplificata ai bot riduce drasticamente il carico PHP. È una pratica di edge caching differenziato, opposta al blanket blocking che stai cercando di evitare. Questo articolo su Pressable e MCP copre la logica di caching differenziato per AI bot nel contesto hosting managed.

4. robots.txt granulare per AI bot

Non bloccare tutto. Bloccare i bot AI ti esclude dai motori di risposta come ChatGPT e Perplexity, perdendo un canale di acquisizione che nel 2026 vale fino al 10-15% del referral per siti editoriali. La strategia giusta è robots.txt granulare: permetti i bot AI "buoni" (OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) con rate limit implicito tramite caching differenziato, blocca quelli "aggressivi" (Bytespider, CCBot senza UA identificabile).

La regola del 80/20 sul bot traffic WordPress

Dopo anni a lavorare con agenzie WordPress, la regola operativa che funziona è questa: l'80% del danno infrastrutturale arriva dal 20% dei bot signature. Quei 5-10 bot che ignorano Crawl-delay, non rispettano robots.txt e ciclano URL senza pause. Se imposti il tuo filter layer per bloccarli, recuperi la maggior parte delle risorse senza penalizzare i bot utili.

Una pipeline operativa realistica per un'agenzia con 20-30 siti WordPress è:

  1. analisi log settimanale (15 minuti per sito) con uno script come quello sopra
  2. identificazione dei top 10 bot signature per volume di richieste
  3. toggle Bot Protection sui 3-4 più aggressivi
  4. monitoraggio 7 giorni per verificare che le visit reali non siano calate
  5. documentazione interna di cosa è stato bloccato (utile per spiegare al cliente il risparmio)

Caso studio: agenzia 15 siti, 3 mesi di lavoro

Un'agenzia con 15 siti client (8 WooCommerce, 7 editoriali) aveva un pattern che si ripeteva ogni 4-6 settimane: i siti WooCommerce saturavano PHP, il cliente accettava l'upgrade del piano, il problema tornava. Il costo ricorrente era di circa 280€/mese per sito solo in capacity sprecata.

Dopo aver applicato il framework diagnostico qui sopra:

  • bot signature identificati: Bytespider (8% del traffico totale), PetalBot (5%), un bot SEO non identificato (12%), script Python senza UA (15%)
  • Bot Protection attivato su 4 signature, robot.txt granulare per altri 6
  • risultato a 90 giorni: tempo PHP medio -62%, bandwidth -45%, zero upgrade di piano necessari
  • risparmio: circa 320€/mese per sito, quasi 4.000€/mese su 12 siti WooCommerce

Il cliente non ha perso un visitatore reale. Le conversioni sono rimaste stabili. Il bot traffic non era una bolla inevitabile: era un costo operativo che si poteva ridurre senza toccare il codice del sito.

Le 3 trappole da evitare quando si tocca il bot traffic

Trappola 1: blanket blocking senza analisi

Mettere User-agent: * + Disallow: / nel robots.txt è la mossa peggiore del 2026. Non blocchi i bot cattivi (che ignorano robots.txt) e blocchi quelli buoni (che ti porterebbero traffico e citazioni AI). Fallo solo dopo aver fatto l'analisi log.

Trappola 2: blocking selettivo senza monitoraggio

Se blocchi un bot, monitora per 7 giorni che le visit reali non siano calate. Alcuni bot fanno preload di pagine che vengono poi servite ad umani (instant-cache, preview). Bloccarli può degradare l'esperienza utente reale.

Trappola 3: affidarsi solo al pannello hosting

Il pannello hosting ti dice quanto traffico arriva, non cosa farne. Se ti dice "20% del tuo traffico è bot aggressivi" ma non ti lascia bloccarli granulatamente, devi agire a livello Cloudflare o Nginx. Il dato è solo l'inizio del lavoro, non la fine.

Roadmap operativa per agenzie e site owner

Una sequenza realistica di interventi, in ordine di priorità misurabile:

  • giorno 1: installa lo script di analisi log sul server e identifica i top 10 bot signature
  • giorno 2-3: configura Cloudflare (o il Bot Protection del tuo hosting) con regole per i top 5 bot aggressivi
  • giorno 4-7: configura cache edge differenziata per AI bot rispetto ai visitatori umani
  • giorno 8-14: monitora le metriche (visit count, conversion, response time) e documenta i risparmi
  • mese 2: rivedi robots.txt per i bot AI "buoni" e configura rate limit
  • mese 3: fai il punto con il cliente: risparmio bandwidth, risparmio capacity, eventuale downsize del piano

Il punto non è eliminare tutto il bot traffic. È rendersi conto di quanto ti costa e decidere consapevolmente quali bot accettare (perché ti portano citazioni AI o indicizzazione Google) e quali bloccare (perché sono solo costo).

Confronto rapido: hosting, Cloudflare, WAF custom

Quando il problema è il bot traffic, tre opzioni si presentano. Ognuna ha un profilo costi/benefici diverso.

Soluzione 1: Bot Protection del hosting integrato (Kinsta, SiteGround, Rocket.net)

Funziona quando: hosting già offre la funzione, vuoi minimizzare la complessità operativa, gestisci meno di 30 siti.

AI utile per: identificare signature bot, generare regole di filter iniziali, produrre report settimanali.

Rischio: lock-in al pannello di quel provider specifico.

Soluzione 2: Cloudflare come reverse proxy (qualsiasi hosting)

Funziona quando: hosting non ha bot protection nativo, vuoi granularità massima, gestisci più di 30 siti o multisito.

AI utile per: scrivere WAF rules personalizzate, analizzare pattern di attacco, ottimizzare cache rules.

Rischio: configurazione errata che blocca visitatori reali, costo del piano Pro se vuoi analytics avanzate.

Soluzione 3: WAF custom con Nginx + Fail2ban (self-hosted)

Funziona quando: hai un team tecnico, vuoi zero lock-in, gestisci traffico molto alto dove ogni secondo di latenza conta.

AI utile per: parsing log e classificazione bot, generazione dinamica di blocklist, alert predittivi.

Rischio: richiede manutenzione continua (aggiornamento signature, gestione falsi positivi).

Per la maggior parte delle agenzie WordPress, Cloudflare è il punto di partenza ottimale: setup in 30 minuti, costo zero per il piano Free, granularità più che sufficiente per siti fino a 100k visit/mese.

FAQ

Come faccio a sapere se il mio sito WordPress ha un problema di bot traffic?

Tre segnali: le richieste HTTP crescono ma le visite reali no, il response time peggiora solo su endpoint dinamici (carrello, checkout, search, AJAX), il bandwidth aumenta linearmente con le request e non con le visit. Se due di questi sono veri, hai un problema di bot.

Bloccare i bot AI come GPTBot è una buona idea?

Dipende dal tuo modello di business. Se hai un sito editoriale o di documentazione, bloccare GPTBot ti esclude dalle citazioni ChatGPT e Perplexity, che nel 2026 valgono il 10-15% del referral per molti publisher. Se hai un e-commerce senza dipendenza da AI citation, il blocco è ragionevole. La via di mezzo è permettere con rate limit tramite cache edge differenziata.

Scalare il piano hosting WordPress serve a qualcosa contro i bot?

Solo se il collo di bottiglia è crescita reale del traffico umano. Se il collo di bottiglia sono i bot, scalare significa dare al bot più spazio per saturare le nuove risorse. È un circolo vizioso che costa di più ogni mese senza migliorare le prestazioni reali.

Cloudflare Free è sufficiente o serve il piano Pro?

Per il 70% dei siti WordPress, il piano Free con Super Bot Fight Mode attivo è sufficiente. Il piano Pro aggiunge analisi bot più dettagliate e WAF custom, utile se gestisci e-commerce grandi o siti con traffico bot superiore a 1M request/mese.

Quanto costa in tempo gestire il bot traffic?

Con il framework qui sopra, circa 2 ore di setup iniziale e 30 minuti/settimana di monitoraggio per sito. Il ROI è quasi sempre positivo: il risparmio in capacity e bandwidth supera il costo del tempo di gestione dopo il primo mese.

Il bot traffic può danneggiare la SEO del sito?

Indirettamente sì: se il bot consuma il crawl budget di Google (che è limitato per sito), Google potrebbe non indicizzare tutte le pagine importanti. Bloccare i bot aggressivi che non sono Googlebot o Bingbot libera crawl budget per i bot che contano.

Devo preoccuparmi dei bot AI diversi da GPTBot e ClaudeBot?

Sì. Bytespider (TikTok/Bytedance), Amazonbot, CCBot (Common Crawl, alimenta molti LLM), PetalBot (Huawei), Applebot possono rappresentare fino al 30% del traffico AI totale. Identifica i tuoi top 5 con l'analisi log e decidi caso per caso.

Checklist operativa prima di toccare il piano hosting

Prima di contattare il tuo provider per un upgrade, verifica queste 8 cose:

  1. hai fatto l'analisi log per distinguere visit e request
  2. hai identificato i top 5 bot signature per volume
  3. hai verificato se il tuo hosting ha Bot Protection nativo
  4. hai testato Cloudflare Free per almeno 7 giorni
  5. hai configurato robots.txt granulare per AI bot
  6. hai implementato cache edge differenziata per crawler
  7. hai misurato l'impatto in bandwidth e PHP utilization
  8. hai documentato i risparmi per giustificare l'eventuale investimento in WAF o piano hosting superiore

Se hai fatto tutti i punti e il carico è ancora giustificato dalla crescita reale, allora (e solo allora) ha senso scalare.

Conclusione: da capacity-based a request-based

Il cambio di mentalità più importante che puoi fare oggi è smettere di ragionare in termini di "quanto traffico posso reggere" e iniziare a ragionare in termini di "quante richieste utili arrivano al mio server". Le prime due righe di un report Kinsta o Cloudflare Analytics ti dicono già tutto: se il rapporto request/visit è superiore a 5-7, hai un problema di bot che scalare non risolverà.

I siti WordPress che gestiscono meglio il 2026 non sono quelli con il piano hosting più grande. Sono quelli che hanno reso esplicito il costo del traffico inutile e hanno investito in protezione invece che in capacity. Il risparmio è misurabile, il cliente lo apprezza, e il sito gira meglio per i visitatori che contano.

Riferimenti utili per approfondire

]]> https://www.mrtux.it/scalare-hosting-wordpress-bot-traffic/feed 0 AEO WordPress 2026: llms.txt e infrastruttura per AI bot https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai#respond Wed, 17 Jun 2026 03:23:44 +0000 https://www.mrtux.it/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="dev@iltuosito.it"

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

]]> https://www.mrtux.it/aeo-wordpress-infrastruttura-llms-txt-cache-ai/feed 0