MEIKAIAudit di crawlability per l’AI: dalla SEO alla leggibilità per le macchine
Un audit di crawlability per l’AI verifica se i sistemi automatizzati riescono a raggiungere le pagine strategiche di un sito, a renderizzarne i contenuti e a estrarre i dati fattuali visibili a un utente umano. Deve produrre riscontri oggettivi e riproducibili, non un vago punteggio aggregato di “maturità AI”.
La distinzione è cruciale perché sistemi diversi possono interrogare la stessa pagina: indici di ricerca tradizionali, crawler per l’addestramento dei modelli linguistici, fetcher in tempo reale attivati dagli utenti e strumenti di navigazione autonoma. L’accesso concesso a uno di essi non garantisce l’accesso agli altri, e la crawlability di per sé non assicura che un assistente citerà effettivamente la pagina.
Partire da una pagina e da una richiesta reale
L’unità fondamentale dell’audit deve essere una pagina reale su un percorso effettivo. Per ciascun template prioritario, registra l’URL, l’user agent richiedente, la risposta HTTP, il testo renderizzato, l’URL canonical e i campi effettivamente estratti.
| Test | Condizione di successo | Evidenza da conservare |
|---|---|---|
| Accesso | Il richiedente riceve lo stato HTTP e il contenuto attesi. | Header di richiesta, stato di risposta, redirect e riga corrispondente nei log del server. |
| Rendering | Le informazioni essenziali sono presenti senza richiedere interazioni non supportate. | HTML iniziale, DOM renderizzato e screenshot quando il layout incide sul significato. |
| Estrazione | I campi nominati possono essere estratti mantenendo etichette e unità di misura intatte. | Valori estratti a confronto con la pagina visibile. |
| Identità | La pagina identifica prodotto, organizzazione o policy senza ambiguità. | URL canonical, identificativi di entità e dati strutturati. |
| Freschezza | Date, disponibilità e informazioni di versione coincidono su tutte le superfici. | Assenza di contraddizioni tra testo della pagina, metadati, feed e dati strutturati. |
L’accesso va oltre il file robots.txt
Le direttive del file robots.txt sono soltanto il primo punto di controllo. L’audit deve monitorare anche redirect, flussi di autenticazione, protezioni anti-bot, routing per lingua o paese e comportamenti della rete CDN. Un URL pubblico può comunque restituire una pagina di verifica captcha o un guscio applicativo vuoto a un crawler automatizzato.
I log del server costituiscono la prova più solida che un crawler ha effettivamente raggiunto il sito. Un test riuscito da un browser locale non dimostra affatto che l’edge di produzione abbia restituito la stessa risposta a un crawler specifico o a un fetcher in tempo reale attivato da un utente.
Verificare le informazioni che guidano le decisioni
Una pagina può renderizzarsi correttamente pur nascondendo i dati fondamentali. Denominazioni di prodotto, codici articolo, prezzi, disponibilità, dimensioni, ingredienti, compatibilità, date di validità e limitazioni geografiche devono trovarsi nel testo visibile, associati a etichette inequivocabili.
I casi di errore più ricorrenti includono:
- contenuti caricati esclusivamente dopo un clic, uno scroll o una richiesta asincrona lato client;
- schede a tab i cui pannelli inattivi non esistono nel documento iniziale;
- valori numerici visualizzati graficamente senza un’etichetta o un’unità di misura adiacente;
- dati strutturati che contraddicono quanto mostrato visivamente sulla pagina;
- pagine regionali che condividono lo stesso URL canonical pur presentando prodotti o condizioni contrattuali differenti;
- pagine di errore che restituiscono erroneamente uno stato HTTP 200.
Quest’ultimo caso passa spesso inosservato. Nel nostro studio sul decadimento delle citazioni su Alibaba, gli articoli rimossi restituivano una breve pagina di errore generica con codice HTTP 200. Un monitoraggio basato unicamente sullo status code avrebbe classificato quegli URL come perfettamente attivi.
Selezionare le pagine in base al rischio, non al volume
Un campione efficace copre template e scenari ad alto impatto commerciale anziché limitarsi alle sole pagine con più visite. Un audit per l’e-commerce dovrebbe includere un prodotto disponibile, una variante esaurita, un articolo dismesso, una pagina sui resi e una con restrizioni territoriali. Un audit B2B dovrebbe comprendere listini prezzi, documentazione tecnica, una pagina di sicurezza, un caso studio e una policy soggetta a versionamento.
Per ciascun template, definisci i campi che devono sopravvivere all’estrazione automatizzata. “Pagina renderizzata” è un criterio di successo troppo debole se mancano il codice modello o la data di decorrenza.
Trasformare l’audit in un test di regressione continuo
La prima esecuzione fissa la baseline di riferimento. Il valore duraturo deriva dall’eseguire regolarmente le stesse richieste dopo ogni rilascio del CMS, modifica di navigazione, aggiornamento delle policy CDN o revisione dei dati strutturati.
Sii estremamente preciso nel documentare gli errori: quale richiedente, quale URL, quale campo specifico e quale livello architetturale è variato. In questo modo, i team tecnici possono intervenire su anomalie riproducibili anziché su vaghi screenshot accompagnati dal commento “l’AI non legge il sito”.
Cosa non dimostra questo audit
Una pagina conforme risulta tecnicamente idonea al recupero nelle condizioni testate. Questo non dimostra che una piattaforma l’abbia indicizzata, che la selezionerà per un determinato prompt, che la riterrà autorevole o che manterrà lo stesso comportamento in futuro.
Crawlability, visibilità nelle risposte e accuratezza delle citazioni devono pertanto formare linee di reportistica distinte. L’audit stabilisce se la fonte è tecnicamente fruibile; la misurazione a livello delle risposte rivela se e come le piattaforme se ne sono effettivamente servite.