Google e Microsoft vietano il web parallelo per AI: servire Markdown ai bot è cloaking

Questa decisione ha stroncato il sogno degli sviluppatori di creare versioni in Markdown o JSON dei siti web per alimentare gli algoritmi, considerandola una violazione delle policy invece che un’ottimizzazione intelligente.

C’è un certo fascino ingegneristico, quasi seducente, nell’idea di ripulire il web dal suo rumore visivo per darlo in pasto alle macchine.

Per mesi, una parte della comunità di sviluppatori — specialmente quelli che lavorano con architetture Next.js e sistemi RAG — ha cullato il sogno di creare un “web parallelo”: una versione speculare dei propri siti servita esclusivamente in Markdown o JSON agli agenti AI.

L’obiettivo era nobile, almeno sulla carta: ridurre il consumo di token, velocizzare l’ingestione dei dati da parte dei Large Language Model (LLM) e fornire informazioni strutturate senza il peso del DOM, del CSS o degli script di tracciamento.

Sembrava una soluzione elegante, efficiente, tecnicamente ineccepibile. Ma il 5 febbraio 2026, Google e Microsoft hanno deciso di chiudere bruscamente questa porta, trasformando quella che sembrava un’ottimizzazione intelligente in una violazione delle policy.

La sentenza è arrivata chiara: servire pagine diverse agli umani e ai bot non è “ottimizzazione per l’AI”, è cloaking.

E nel mondo dei motori di ricerca, il cloaking è un peccato capitale.

Questa presa di posizione, apparentemente conservatrice, nasconde in realtà una verità tecnica che molti di noi sviluppatori tendiamo a dimenticare: le macchine che stiamo cercando di “aiutare” sono state addestrate proprio su quel disordine che stiamo cercando di nascondere.

L’illusione della purezza del dato

Per capire la frustrazione di chi scrive codice oggi, bisogna guardare al “peso” di una moderna pagina web. Tra l’idratazione lato client, librerie di terze parti e markup semantico spesso abusato, il rapporto segnale/rumore dell’HTML contemporaneo è disastroso.

L’idea di intercettare lo User-Agent di un bot (come GPTBot o ClaudeBot) tramite un middleware e servire un file Markdown pulito nasceva da un’esigenza di efficienza.

I benchmark iniziali erano promettenti. Alcuni test mostravano una riduzione dell’uso dei token fino al 95% per pagina, un dato che per chi gestisce infrastrutture LLM su larga scala si traduce in un risparmio economico massiccio.

Se un bot deve leggere milioni di pagine per aggiornare il suo indice o per rispondere a una query in tempo reale, perché costringerlo a parsare migliaia di righe di HTML inutile?

La risposta di Google, tuttavia, è stata tagliente. John Mueller, Search Advocate di Google, non si è limitato a sconsigliare la pratica, ma ne ha smontato la premessa tecnica con un sarcasmo raro per i canali ufficiali di Mountain View.

Convertire le pagine in markdown è un’idea così stupida. Sapevate che gli LLM possono leggere le immagini? PERCHÉ NON TRASFORMARE TUTTO IL VOSTRO SITO IN UN’IMMAGINE?

— John Mueller, Search Advocate presso Google

Dietro la provocazione c’è una realtà tecnica fondamentale: gli LLM attuali non sono parser XML rigidi degli anni 2000. Sono reti neurali addestrate su petabyte di dati presi dal Common Crawl, che è essenzialmente una discarica di HTML sporco, rotto e malformato.

Un modello come Gemini o GPT-4 “capisce” l’HTML meglio di quanto capisca il Markdown, perché l’HTML porta con sé informazioni strutturali — gerarchie, relazioni spaziali, enfasi semantiche — che nel passaggio a Markdown vengono inevitabilmente appiattite.

Il costo nascosto dell’infrastruttura

Se Google attacca sulla semantica, Microsoft, tramite Bing, punta il dito sull’insostenibilità operativa. Fabrice Canel, dirigente di Microsoft, ha sollevato un problema che demolisce l’argomentazione dell’efficienza: il crawl budget.

L’idea di servire contenuti diversi in base allo User-Agent costringe i motori di ricerca a un doppio lavoro. Devono scaricare la versione per utenti (per verificare cosa vedono le persone e garantire la sicurezza) e poi, potenzialmente, la versione per bot.

Invece di risparmiare risorse, stiamo chiedendo all’infrastruttura globale di ricerca di raddoppiare le richieste HTTP verso i nostri server per verificare che non stiamo mentendo.

Fabrice Canel mette in guardia contro le pagine markdown separate per gli LLM, citando il raddoppio del carico di scansione e i rischi legati alle policy.

— Fabrice Canel, Principal Program Manager presso Microsoft

Inoltre, c’è il problema della “deriva dei contenuti”. Chiunque abbia mantenuto un sistema software complesso sa che due versioni della stessa risorsa tenderanno inevitabilmente a divergere. La pagina HTML viene aggiornata dal team di marketing, mentre il template Markdown generato dal backend rimane indietro.

Il risultato?

L’AI risponde con dati obsoleti mentre l’utente vede dati aggiornati. Per un motore di ricerca che basa la sua reputazione sulla freschezza e l’accuratezza, questo disallineamento è inaccettabile.

È interessante notare come questo dibattito si colleghi al fallimento di iniziative precedenti come llms.txt, proposta nel 2024 per standardizzare le preferenze dei contenuti per l’AI. Anche in quel caso, Google ha chiarito che non supporterà protocolli specifici per LLM, ribadendo che gli standard web esistenti (HTML, Sitemap, Robots.txt) sono sufficienti e preferibili.

Oltre il codice: la battaglia per il controllo

La vera questione, però, non è solo tecnica.

È politica ed economica.

Consentire ai siti web di servire una versione “solo dati” del proprio contenuto significa rendere il web agnostico rispetto alla presentazione. Significa trasformare ogni sito in un database pubblico, facilmente consumabile, remixabile e monetizzabile da terzi senza che l’utente debba mai atterrare sulla pagina originale.

Google e Bing, che vivono di traffico e di ecosistemi visuali (dove risiedono le pubblicità), non hanno alcun interesse a incentivare un web “headless”, privo di interfaccia. La loro insistenza sull’HTML non è solo purismo tecnico; è una difesa dello status quo in cui il contenuto è indissolubilmente legato alla sua presentazione visiva.

C’è poi un aspetto di sicurezza e fiducia. La tecnica di mostrare una cosa al bot e un’altra all’utente è, storicamente, lo strumento preferito dagli spammer. Anche se le intenzioni degli sviluppatori oggi sono benigne, il meccanismo è identico a quello utilizzato per nascondere malware o siti di gambling illegale.

I motori di ricerca non possono permettersi di fare distinzioni basate sulle “buone intenzioni” dichiarate in un thread su Reddit o Bluesky.

John Mueller ha sollevato dubbi tecnici sulla capacità degli LLM di seguire i link in file di testo, evidenziando come la struttura di navigazione interna rischi di andare persa in una conversione brutale verso il Markdown. Se un bot AI riceve solo un blocco di testo, come può comprendere la gerarchia del sito o l’importanza relativa delle pagine collegate?

La lezione per noi sviluppatori è amara ma necessaria. Spesso cerchiamo di reingegnerizzare il mondo per renderlo più “pulito” per i nostri algoritmi, dimenticando che la resilienza del web sta proprio nella sua ridondanza e nella sua natura visiva.

L’HTML, con tutti i suoi difetti, rimane la lingua franca. Tentare di creare corsie preferenziali per l’AI non solo viola le regole del gioco, ma paradossalmente sottovaluta proprio l’intelligenza di quelle macchine che stiamo cercando di facilitare.

Se un’AI non riesce a estrarre valore da una pagina HTML ben formattata, forse il problema non è il formato, ma l’AI stessa.

O forse, più inquietante, il problema è che stiamo cercando di risolvere con l’ingegneria quello che è essenzialmente un conflitto di interessi tra chi produce contenuti e chi li consuma automaticamente.