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

• Kinsta Blog: Kinsta launches Bot Protection for WordPress sites, included free on all plans - annuncio ufficiale del 9 giugno 2026 con screenshot della dashboard
• Kinsta Blog: Why scaling infrastructure doesn't fix bot traffic problems - articolo di base su come i bot degradano le performance
• Kinsta Blog: How to reduce bandwidth waste without blocking legitimate users - complemento sui pattern di filtraggio bot
• Kinsta Documentation: Bot Protection MyKinsta - documentazione tecnica del pannello
• Kinsta API Reference - endpoint per gestire Bot Protection via API
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida mrtux.it sui 14 AI crawler principali
• AI bot WordPress 2026: perché il blanket blocking non funziona più - strategia selettiva alternativa al blocco totale
• AEO WordPress 2026: llms.txt e infrastruttura per AI bot - infrastruttura AEO per essere citati
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout - focus chirurgico su endpoint WooCommerce
• Cloudflare Bot Management - alternativa enterprise se non sei su Kinsta
• WooCommerce sotto attacco bot AI: proteggere il checkout - protezione specifica WooCommerce
• Anthropic ClaudeBot documentation - specifica bot Anthropic per gestire eccezioni