WooCommerce sotto attacco bot AI: proteggere il checkout

Un cliente mi ha chiamato la scorsa settimana: "il checkout del nostro e-commerce è lentissimo, ma GTmetrix non segnala nulla". Ho aperto i log del server e in venti minuti ho trovato 14 crawler AI - GPTBot, ClaudeBot, PerplexityBot, CCBot e altri dieci - che in dodici ore avevano generato 380.000 richieste, di cui 47.000 contro endpoint WooCommerce. La meta description, le product gallery e le pagine carrello venivano scaricate a ripetizione da bot che non avrebbero mai comprato nulla, e ogni richiesta attivava un wp_options lookup, un WC_Session e un transient query. È un caso estremo, ma non è raro. WooCommerce non è un blog, e quando parliamo di bot AI i numeri sono diversi da qualsiasi altro sito WordPress.

Se hai letto la mia guida generale alla gestione dei bot AI su WordPress, sai che il tema è caldo. Quello che mancava era l'angolo WooCommerce-specific: cosa cambia quando il sito ha un carrello, transient di sessione, HPOS e una logica di checkout che non può essere rallentata neanche di 200ms. Questo articolo chiude quel gap.

Perché WooCommerce è diverso dai blog

I crawler AI trattano qualsiasi URL come candidabile. Su un blog questo significa decine di richieste al minuto; su WooCommerce significa richieste contro endpoint che hanno effetti collaterali concreti sul database e sulla cache.

I tre endpoint WooCommerce che i bot adorano

1. WPGUTENBERGBLOCKPLACEHOLDER0X e WPGUTENBERGBLOCKPLACEHOLDER1X: pagine prodotto. Su un catalogo medio di 3.000 articoli, ogni crawler scarica 3.000+ pagine. Ogni pagina esegue una query principale WP_Query, secondarie per tassonomie, e - se hai abilitato la cache oggetto - letture da Redis. Sono lente, non catastrofiche, ma si sommano.
2. WPGUTENBERGBLOCKPLACEHOLDER0X e WPGUTENBERGBLOCKPLACEHOLDER1X: pagine carrello. Queste sono il problema vero. WooCommerce esegue WC()->session->get_customer_data(), legge i transient wc_cart_hash, valuta coupon, e calcola totali. Una singola richiesta bot a /cart/ non fa danni, ma 10 crawler che chiamano /cart/ ogni 30 secondi generano 28.800 sessioni al giorno, ognuna con il proprio record in woocommerce_sessions.
3. WPGUTENBERGBLOCKPLACEHOLDER0X e WPGUTENBERGBLOCKPLACEHOLDER1X: endpoint autenticabili. Ancora peggio, perché qui le capability check WordPress vengono combinate con i check WooCommerce. I bot che arrivano qui non comprano, ma riscaldano processi PHP che dovrebbero essere freddi fino a quando un cliente reale non arriva.

Il caso studio reale

Il cliente di cui sopra aveva 3.000 articoli, hosting managed Kinsta, Redis attivo, Cloudflare davanti. Risultato dell'analisi:

• CPU media del container PHP: 75% con picchi al 95% durante le ore dei bot (quelle asiatiche notturne e americane diurne)
• Banda mensile: 412GB di cui 248GB (60%) attribuibili a bot AI identificati
• Transazione di checkout reali: 85 al giorno, con tempo medio di risposta 1,8s, di cui 0,9s spesi in operazioni preliminari che non avrebbero dovuto essere attivate
• Costo hosting: +340€ al mese per gestire traffico non convertente

Dopo la strategia 4 livelli che descrivo qui sotto: CPU 25%, banda -40%, checkout a 0,9s.

I 4 livelli di protezione WooCommerce-aware

Una strategia efficace non è "blocco totale" né "apertura totale", ma una serie di decisioni granulari basate su cosa fa WooCommerce e cosa no.

Livello 1: permessi robots.txt per AI bot

Il livello base è dichiarare cosa i bot possono e non possono indicizzare. WooCommerce ha una particolarità: le pagine carrello, checkout e account devono essere sempre vietate a tutti i bot (non solo AI), pena l'indicizzazione in Google di URL con parametri dinamici.

# robots.txt WooCommerce-aware
User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /?add-to-cart=
Disallow: /?s=
Disallow: /search/

# AI bot specifici: permettere solo pagine informative
User-agent: GPTBot
Allow: /
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /wp-admin/
Disallow: /wp-json/wc/

User-agent: ClaudeBot
Allow: /
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/

User-agent: PerplexityBot
Allow: /
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/

User-agent: CCBot
Disallow: /          # blocco totale: CCBot non porta conversioni

Nota: Disallow: /wp-json/wc/ impedisce ai bot di scaricare l'intero catalogo prodotti via REST API in pochi secondi. WooCommerce espone /wp-json/wc/v3/products con un rate limit proprio, ma i bot non lo rispettano sempre.

Livello 2: blocco granulare per user-agent e IP reputation

Il robots.txt è una dichiarazione di intenti, non un firewall. Per il blocco reale servono regole server-side. Ecco una configurazione Nginx pensata per WooCommerce.

# Blocca bot AI su endpoint WooCommerce sensibili
location ~ ^/(cart|checkout|my-account)(/|$) {
    if ($http_user_agent ~* "(GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|Amazonbot)") {
        return 403;
    }
}

# Blocca bot AI su REST API WooCommerce
location ~ ^/wp-json/wc/v[0-9]+/ {
    if ($http_user_agent ~* "(GPTBot|ClaudeBot|CCBot)") {
        return 403;
    }
}

# Limita rate su pagine prodotto per bot noti
location ~ ^/product/ {
    if ($http_user_agent ~* "(GPTBot|ClaudeBot|PerplexityBot)") {
        limit_req zone=ai_bots burst=10 nodelay;
    }
}

Per Apache, l'equivalente .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|Amazonbot) [NC]
RewriteRule ^(cart|checkout|my-account) - [F,L]
</IfModule>

Livello 3: protezione a livello applicazione PHP

Per una protezione che vada oltre il semplice user-agent matching, agganciati al boot di WordPress e intercetta le richieste WooCommerce-aware.

add_action( 'init', 'wc_proteggi_da_bot_ai', 1 );
function wc_proteggi_da_bot_ai() {
    if ( ! class_exists( 'WooCommerce' ) ) {
        return;
    }
    $ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
    $bot_ai_pattern = '/(GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|Amazonbot|Google-Extended|Bytespider)\b/i';
    if ( ! preg_match( $bot_ai_pattern, $ua ) ) {
        return;
    }
    $path = $_SERVER['REQUEST_URI'] ?? '';
    $endpoint_bloccati = array( '/cart', '/checkout', '/my-account', '/?add-to-cart' );
    foreach ( $endpoint_bloccati as $ep ) {
        if ( strpos( $path, $ep ) === 0 ) {
            status_header( 403 );
            nocache_headers();
            exit;
        }
    }
    // Log audit
    if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
        error_log( sprintf( 'WC bot AI: %s path=%s', $ua, $path ) );
    }
}

Questo snippet è minimale ma efficace: agisce prima di WooCommerce, evitando di attivare sessioni, transient o query inutili. La priorità 1 sull'hook init è fondamentale: WooCommerce si aggancia a priorità 10, quindi arriviamo prima.

Livello 4: regole Cloudflare WAF (se usi Cloudflare)

Se il tuo WooCommerce sta dietro Cloudflare, il livello 4 è il più efficace in assoluto. Cloudflare WAF + Bot Fight Mode identifica i bot AI noti e li blocca a livello edge, prima ancora che tocchino il tuo server.

Configurazione consigliata nel pannello Cloudflare:

1. Security → Bots → Bot Fight Mode: ON. Blocca automaticamente i bot verificati come malevoli.
2. Security → WAF → Custom Rules: aggiungi una regola che blocca i bot AI su /cart/* e /checkout/* con sfida JS (non hard block, per evitare falsi positivi).
3. Caching → Configuration → Tiered Cache Topology: separa le pagine prodotto dai carrelli. Le pagine prodotto vanno in cache con regole aggressive, le pagine carrello bypass totale.
4. Speed → Optimization → Auto Minify: HTML, CSS, JS. WooCommerce spara 200KB di JS non minificato su /cart/.

Caso studio: e-commerce moda con 12.000 prodotti

Un e-commerce di abbigliamento con 12.000 SKU e 4 lingue, hosting SiteGround, Cloudflare free. Problema: TTFB pagina prodotto passato da 800ms a 2.4s in sei mesi, senza modifiche al codice.

Audit iniziale

# analisi log per user agent e path
grep -E "GET /(product|shop|cart|checkout)" access.log | awk '{print $12, $7}' | sort | uniq -c | sort -rn | head -30

Output tipico per questo profilo di sito:

18432 GPTBot /product/
 8421 ClaudeBot /product/
 3201 PerplexityBot /product/
  892 CCBot /wp-json/wc/v3/products
  441 Bytespider /cart/
  112 OAI-SearchBot /checkout/

Quasi la metà delle richieste a /product/ era di bot AI. Il sito aveva già noindex su carrello e checkout, ma i bot ignoravano il meta tag.

Intervento in 3 fasi

Fase 1 - robots.txt granulare: implementato il robots.txt del Livello 1 sopra, con differenziazione per bot. Risultato: -25% richieste bot in 48 ore (alcuni bot rispettano robots.txt, altri no).

Fase 2 - WAF custom rule Cloudflare: bloccati 6 bot AI su /cart/* e /checkout/* con JS challenge. Risultato: -90% richieste bot su endpoint sensibili.

Fase 3 - PHP guard: aggiunto lo snippet del Livello 3 per intercettare bot sfuggiti a Cloudflare. Risultato: blocco totale su carrello e checkout anche in caso di bypass del WAF.

Dopo 7 giorni: TTFB 850ms (vicino al baseline originale), CPU media 28% (era 71%), banda mensile -38%.

Configurazioni WooCommerce specifiche che aiutano

Alcune impostazioni WooCommerce riducono l'impatto dei bot senza toccare codice custom.

Disabilita la cache oggetto per le sessioni

// Non cachare le sessioni WC: sono un per-user data
add_filter( 'wc_session_use_redis', '__return_false' );

WooCommerce di default cacha anche le sessioni in Redis. Su un sito trafficato da bot, questo riempie Redis di sessioni anonime che non verranno mai completate. La sessione WC deve restare in MySQL o in un backend dedicato.

Abilita HPOS e riduci il carico transiente

High-Performance Order Storage (HPOS), attivo da WooCommerce 8.x, sposta gli ordini dalle tabelle postmeta a tabelle dedicate. Questo non blocca i bot, ma riduce drasticamente il carico di query durante un attacco bot: HPOS usa indici nativi e join efficienti, mentre le tabelle postmeta sono il collo di bottiglia classico di WooCommerce.

// verifica HPOS attivo
add_action( 'admin_notices', function() {
    if ( ! class_exists( 'Automattic\\WooCommerce\\Utilities\\FeaturesUtil' ) ) return;
    $hpos_enabled = 'yes' === get_option( 'woocommerce_custom_orders_table_enabled' );
    if ( ! $hpos_enabled ) {
        echo '<div class="notice notice-warning"><p>HPOS non attivo. Valuta di attivarlo per migliorare le performance sotto carico bot.</p></div>';
    }
} );

Pulisci transient orfani regolarmente

I bot che attivano carrelli anonimi generano transient wc_cart_hash_<session_id> che non vengono mai puliti. Una volta al giorno, un cron job deve rimuoverli.

add_action( 'wc_pulisci_transient_orfani', 'wc_pulisci_transient_orfani_handler' );
function wc_pulisci_transient_orfani_handler() {
    global $wpdb;
    $wpdb->query( "DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_wc_cart_hash_%' AND option_name NOT LIKE '_transient_timeout_wc_cart_hash_%'" );
    $wpdb->query( "DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_timeout_wc_cart_hash_%' AND option_value < UNIX_TIMESTAMP()" );
}
// schedula il cron se non esiste
if ( ! wp_next_scheduled( 'wc_pulisci_transient_orfani' ) ) {
    wp_schedule_event( time(), 'daily', 'wc_pulisci_transient_orfani' );
}

Test e monitoraggio continuo

Una strategia di protezione non è mai definitiva: i bot cambiano user-agent, Cloudflare aggiorna le regole, WooCommerce rilascia nuovi endpoint. Serve un monitoraggio.

Dashboard minimale con WP-CLI

# richieste bot AI ultime 24 ore per path
wp eval '
$log_file = WP_CONTENT_DIR . "/debug.log";
if ( ! file_exists( $log_file ) ) { echo "no log\n"; return; }
$lines = file( $log_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES );
$cutoff = time() - 86400;
$counts = array();
foreach ( $lines as $line ) {
    if ( strpos( $line, "WC bot AI" ) === false ) continue;
    $counts[ substr_count( $line, "/product/" ) ? "product" : ( substr_count( $line, "/cart/" ) ? "cart" : "other" ) ]++;
}
print_r( $counts );
'

Questo script va schedulato in cron con invio report via email o salvataggio in wp_options per trend settimanali.

Metriche di successo da tracciare

Tre numeri che metto in dashboard per ogni cliente WooCommerce con questo problema:

1. Rapporto richieste bot/umani: target < 3:1 (significato: 3 richieste bot per ogni umano reale)
2. TTFB pagina carrello: target < 500ms (sotto carico, non a freddo)
3. Dimensione tabella WPGUTENBERGBLOCKPLACEHOLDER0X: target < 50MB (se sale, hai transient orfani)

FAQ

I bot AI sono davvero un problema per WooCommerce o è esagerato?

Non è esagerato se il tuo e-commerce supera i 1.000 prodotti o se hai endpoint di checkout pesanti. Il problema non è il singolo bot, è l'effetto moltiplicatore: WooCommerce attiva operazioni di sessione e transient su ogni richiesta, e i bot fanno migliaia di richieste. Su un blog con 50 articoli il problema è trascurabile; su un e-commerce con 3.000+ SKU diventa strutturale.

Posso bloccare tutti i bot AI senza perdere visibilità?

Dipende dal tuo modello di business. Se vendi prodotti fisici, la risposta è sì: nessun utente ChatGPT comprerà mai un paio di scarpe. Se vendi software, SaaS o servizi, valuta: le citazioni AI possono portare conversioni indirette. La mia guida AEO WordPress spiega come diventare fonte citata senza subire l'impatto del crawler.

Cloudflare Bot Fight Mode basta da solo?

No, è un primo livello. Cloudflare identifica i bot noti con alta confidenza, ma i bot più sofisticati ruotano user-agent e usano residential proxy. La difesa in profondità - robots.txt, WAF, PHP guard - è l'unica che regge sotto attacco reale.

Come distinguo un bot AI da un bot SEO tradizionale?

Dalla stringa user-agent. I bot AI del 2026 hanno UA distintivi: GPTBot/1.0, ClaudeBot/1.0, PerplexityBot, CCBot, OAI-SearchBot, Amazonbot, Google-Extended, Bytespider, Applebot-Extended. Tieni una blocklist aggiornata: ogni mese escono nuovi bot, e Mozilla mantiene un repository di user-agent noti utile per il check.

Il blocco bot AI influenza la SEO tradizionale Google?

No. Googlebot ha user agent proprio e non è nella lista dei bot AI. Google-Extended è un bot separato che Google usa per Gemini: bloccarlo non pregiudica l'indicizzazione Google Search, ma impedisce a Gemini di usare i tuoi contenuti. È una scelta consapevole, non un effetto collaterale.

I bot AI rispettano robots.txt?

Alcuni sì, altri no. OpenAI dichiara che GPTBot rispetta robots.txt, ma nella pratica non sempre lo fa correttamente. ClaudeBot rispetta robots.txt in modo più rigoroso. CCBot (Common Crawl) spesso ignora le regole. Non fare affidamento solo sul robots.txt, usalo come dichiarazione di intenti e affianca blocchi server-side.

Cosa cambia con HPOS rispetto al carico dei bot?

HPOS non blocca i bot, ma riduce l'impatto delle loro richieste. Le tabelle ordini dedicate hanno indici efficienti e non si appoggiano al sistema postmeta, che è il vero collo di bottiglia di WooCommerce sotto carico. Su un e-commerce con HPOS attivo e bot bloccati, le performance restano stabili anche con tentativi di scraping massicci.

Conclusione operativa

WooCommerce non è un blog, e la protezione dai bot AI non può essere una copia-incolla delle regole generiche WordPress. Serve una strategia WooCommerce-aware a 4 livelli, con monitoraggio continuo e cleanup dei transient orfani. Il ROI è quasi sempre positivo entro il primo mese, anche per e-commerce di medie dimensioni.

Checklist operativa pre-produzione

• [ ] robots.txt con regole specifiche per /cart/, /checkout/, /my-account/, /wp-json/wc/
• [ ] WAF custom rule (Cloudflare o Nginx) per bloccare 6+ bot AI su endpoint sensibili
• [ ] PHP guard con priorità 1 su init per intercettare bot sfuggiti al WAF
• [ ] HPOS attivo su WooCommerce 8.x+
• [ ] Sessioni WC non cachate in Redis
• [ ] Cron giornaliero per pulizia transient orfani wc_cart_hash_*
• [ ] Dashboard con rapporto bot/umani, TTFB carrello, dimensione tabella sessioni
• [ ] Backup log audit dei bot bloccati per 30 giorni

Se tutti i punti sono verdi, il tuo WooCommerce è pronto a gestire il traffico bot AI del 2026 senza sacrificare le performance del checkout.

Riferimenti utili per approfondire

• AI bot traffic WordPress: gestire crawler AI nel 2026 - guida generale sui bot AI, da leggere prima di questo articolo
• AEO WordPress: come farsi citare da ChatGPT e Claude - l'altra faccia del problema: come essere fonte citata
• WooCommerce + AI per sviluppatori: schede prodotto e checkout - come usare AI per generare contenuti WooCommerce
• WooCommerce e AI: strategie per vendere di più - lato business, conversione AI-assisted
• Documentazione ufficiale WooCommerce HPOS - guida completa al nuovo storage ordini
• Repository Cloudflare WAF rules - reference per costruire regole custom
• Lista user-agent bot AI aggiornata 2026 - check periodico per nuovi bot
• Kinsta research: AI bot traffic findings - dati reali su 10 miliardi di richieste analizzate
• WordPress performance under bot load - articolo Kinsta sul caso WooCommerce specifico
• WordPress hardening 2026 - guida completa hardening che include protezione bot
• WooCommerce debugging avanzato - documentazione sviluppatore ufficiale
• GDPR compliance per log bot AI - come gestire i log in modo conforme