Domenica sera 20 settembre 2026 Amazon mostrava un popup a chi provava a comprare tramite Muse, l’agente personale di Meta: l’accesso continuato da parte di un agente AI non autorizzato viola le Condizioni d’uso del sito. Amazon gli contesta di nascondere la propria identità mentre naviga e di trattenere le credenziali del cliente. Un negozio ha messo per iscritto che un agente non autorizzato non può comprare, e lo ha scritto sulla pagina, a chi stava usando l’agente. Sul tuo WooCommerce quella decisione è già presa — dal WAF dell’hosting e dal JSON-LD che il tema genera — solo che non l’hai presa tu.

Quello che l’agente legge non è la pagina che vedi

Un agente che compra non guarda la galleria, non apre l’accordion delle specifiche e non aspetta che il widget del builder calcoli il prezzo. Legge due cose: l’HTML che il server restituisce alla prima richiesta e il JSON-LD dentro quell’HTML. WooCommerce lo genera da solo su ogni scheda prodotto — nome, descrizione, immagine, sku e un oggetto offers con prezzo, valuta e disponibilità — e lo espone al filtro woocommerce_structured_data_product. Il canale alternativo, il feed prodotti dell’Agentic Commerce Protocol, per una PMI oggi non è una scorciatoia: il feed si spinge a un endpoint concordato dopo una registrazione da commerciante, con aggiornamenti accettati fino a ogni quindici minuti. Quindi la superficie su cui puoi agire questa settimana è una sola: la pagina come esce dal server. Se lì dentro il prezzo non c’è, per l’agente quel prodotto non ha prezzo, e un’offerta che non si legge è un’offerta che non esiste.

Il test: chiedilo al server, non al browser

Il browser è il testimone sbagliato, perché esegue JavaScript, accetta i cookie e viene trattato bene dal firewall. L’agente no. Il controllo giusto dura un minuto: scarica la pagina come la scarica lui e stampa solo l’offerta. Serve la scheda di un prodotto reale, meglio se variabile o in promozione, perché è lì che i dati si rompono.

curl -sL "https://tuosito.it/prodotto/esempio/" \
  -A "Mozilla/5.0 (compatible; test-agente)" \
| python3 -c "
import sys, re, json
for b in re.findall(r'<script type=\"application/ld\+json\">(.*?)</script>', sys.stdin.read(), re.S):
    d = json.loads(b)
    for n in (d.get('@graph') or [d]):
        if n.get('@type') == 'Product':
            print(n.get('name'), '|', n.get('sku'), '|', n.get('offers'))
"

Se non stampa nulla, il JSON-LD è assente o malformato e vale la pena guardare se un plugin di cache serve una versione vecchia della pagina. Se stampa un prezzo diverso da quello a schermo, hai due fonti di verità e l’agente citerà quella sbagliata. Se il prodotto è variabile, il campo tipico è un intervallo: accettabile per un umano, inutile per chi deve decidere se rientri nel budget. Ripeti la prova su tre schede — una semplice, una variabile, una in sconto — perché il guasto quasi mai riguarda tutto il catalogo.

I tre campi che decidono, e il doppione che li annulla

Dentro offers contano tre valori e nessuno è decorativo. price deve essere un numero, non una stringa con il simbolo di valuta dentro. priceCurrency deve esserci sempre: senza codice ISO l’agente non sa se quei 49 sono franchi o euro, e su un negozio ticinese che vende anche in Italia l’ambiguità è reale. availability deve riflettere il magazzino vero, non essere fissa a InStock perché il tema l’ha scritta a mano. Aggiungi sku o un identificatore stabile: è la chiave con cui il tuo prodotto viene riconosciuto come lo stesso oggetto in due risposte diverse. Il guasto più frequente però non è un campo mancante, è il doppione: con Rank Math o un plugin SEO che emette a sua volta uno schema Product, la pagina serve due blocchi che si contraddicono su prezzo e disponibilità. Tienine uno solo attivo e correggi quello, dal filtro di WooCommerce se serve un campo in più.

L’errore da evitare: il 403 che vedi solo tu

Qui si perde più tempo che sullo schema. Molti WAF di hosting condivisi rispondono 403 a qualunque richiesta senza User-Agent da browser: l’ho misurato sul mio stesso dominio, dove una POST REST autenticata passa da Chrome e viene respinta con lo User-Agent predefinito di urllib, a parità di corpo e credenziali. Il risultato è una pagina perfetta per te e una porta chiusa per chiunque non sia un browser, incluso l’agente che avrebbe comprato. Stesso effetto con la scorciatoia opposta: un Disallow generico verso gli user-agent AI nel robots.txt, copiato per proteggere gli articoli e applicato senza accorgersene anche a /prodotto/. Le due decisioni sono separate e vanno prese separatamente: puoi rifiutare che i tuoi testi finiscano in un dataset di addestramento e allo stesso tempo volere che un assistente citi il tuo catalogo con il prezzo giusto. Verifica entrambe dal server, con l’user-agent del caso, non dalla scheda del browser che hai già aperta.

Chi può comprare da te, deciso da te

L’ordine operativo è questo: controlla il JSON-LD servito su tre prodotti, elimina lo schema doppio, verifica che prezzo, valuta e disponibilità coincidano con la pagina, poi prova la stessa URL con uno user-agent non-browser per scoprire se il firewall risponde al posto tuo. Sono venti minuti, validi qualunque piega prenda la guerra fra piattaforme. La take: nel commercio mediato da agenti non vince la scheda più curata, vince quella che un client senza JavaScript legge in una sola richiesta — lo stesso lavoro della SEO tecnica, applicato a un lettore che invece di indicizzare compra. Amazon può permettersi di chiudere la porta a un agente perché il traffico lo ha comunque. Un negozio da PMI ha il problema opposto: il rischio non è l’agente indesiderato, è essere illeggibile per tutti quanti, compresi quelli disposti a pagare.