Cosa vedono le macchine

Un motore di ricerca dispone di risorse computazionali e di banda limitate davanti a un numero di indirizzi potenzialmente infinito. Nel post del gennaio 2007 «C'è un buco nella tela del ragno», l'analisi partiva da una constatazione ingegneristica: un crawler organizza la propria scansione della rete attraverso due code coordinate:

• La coda di priorità: determina quali pagine esplorare per prime, ponderando l'autorevolezza del documento e la frequenza con cui i contenuti vengono storicamente aggiornati.
• La coda di cortesia: scagliona le richieste verso il medesimo host per evitare di saturare la banda o le risorse di calcolo del server ospitante.

Per elaborare centinaia di pagine al secondo, l'architettura dei primi crawler scaricava unicamente il codice HTML statico, ignorando fogli di stile ed esecuzione di script.

La prima discrepanza strutturale del web risiede nella distanza tra il codice sorgente grezzo e la resa grafica finale. Il crawler legge il codice sorgente restituito dalla risposta HTTP; l'utente interagisce con il layout calcolato dal browser dopo l'applicazione di CSS e JavaScript.

Questa distanza alimentò storicamente pratiche manipolative: mostrare contenuti differenti al crawler rispetto alle persone (cloaking), oppure nascondere blocchi di testo tramite fogli di stile (colori coincidenti con lo sfondo, o coordinate estreme come left: -3001px).

Per un algoritmo automatico è sempre stato complesso distinguere una tendina di navigazione legittima — resa invisibile con display: none via CSS e rivelata al passaggio del cursore — da un blocco di parole chiave nascosto per forzare il posizionamento.

Queste tecniche vanno studiate per riconoscerle e tenerle lontane dai siti in produzione, non per applicarle, in piena conformità con le norme di Google sullo spam.

Poiché nessun parser automatico poteva comprendere appieno il contesto visivo ed esperienziale delle pagine, i motori di ricerca hanno integrato le metriche algoritmiche con il lavoro di revisori specializzati.

Come chiarito da Danny Sullivan per Google, i valutatori umani non intervengono a mano per modificare le posizioni dei singoli siti web: il loro compito è valutare campioni di risultati per verificare se gli aggiornamenti generali dell'algoritmo migliorano o peggiorano l'esperienza reale delle persone.

Mentre Googlebot ha gradualmente integrato un runtime Chromium headless per renderizzare il codice JavaScript delle applicazioni web moderne, la medesima asimmetria tra sorgente e browser si è riaperta con i crawler dei modelli linguistici (LLM).

Secondo lo studio condotto da Vercel nel dicembre 2024, i principali crawler AI (tra cui GPTBot di OpenAI, ClaudeBot di Anthropic e PerplexityBot) non eseguono JavaScript durante la scansione, con l'eccezione di Gemini — che sfrutta l'infrastruttura di Googlebot — e AppleBot.

Un sito web che costruisce i propri testi esclusivamente nel browser a runtime (come una Single Page Application non prerenderizzata) rischia di apparire a questi agenti quasi vuoto. Sebbene i bot possano estrarre metadati e script JSON-LD inclusi nell'HTML iniziale, il contenuto dinamico non viene renderizzato.

Poiché il comportamento dei crawler AI evolve rapidamente, prendete i dati come indicazione architetturale: verificate nei log del vostro server quali bot passano e se scaricano solo l'HTML o richiedono anche gli asset JavaScript.

Per garantire la presenza dei propri contenuti nei modelli AI, la risposta architetturale è tornare alle origini del web: consegnare markup semantico completo e dati strutturati direttamente nell'HTML iniziale distribuito dal server.

È qui che la riflessione del 2007 si ricongiunge con l'architettura dei sistemi moderni: il cloaking dell’era AI si basa sulla medesima asimmetria tra browser e macchina, con testo invisibile alle persone ma ingerito direttamente dall’agente automatico. Solo che oggi il testo nascosto non contiene più elenchi di parole chiave, ma istruzioni in linguaggio naturale rivolte al modello (indirect prompt injection).

Non si tratta di un'ipotesi accademica, ma di una realtà documentata sul campo:

• Il primo caso noto (dicembre 2024): nel caso del Guardian, scheda dell'OECD AI Incidents Monitor, un testo nascosto all'interno di una pagina web ha alterato radicalmente ciò che ChatGPT Search riportava di quella fonte.
• Lo studio di Google su Common Crawl (aprile 2026): nello studio di Google su Common Crawl (aprile 2026, Google Security), i ricercatori hanno trovato istruzioni nascoste create appositamente per la manipolazione SEO, ovvero siti che forzano l’assistente a raccomandare la propria azienda a scapito dei concorrenti. Nella categoria malevola i casi sono cresciuti del 32% tra novembre 2025 e febbraio 2026, pur restando ancora a uno stadio preliminare.
• I casi di Unit 42 di Palo Alto Networks (marzo 2026): nel report di Unit 42 di Palo Alto Networks, «Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild», sono state documentate 22 tecniche osservate in uso reale, tra cui un sito di phishing spinto nelle risposte raccomandate dai modelli e un annuncio truffa fatto approvare aggirando un moderatore AI.

Le tecniche per nascondere il testo sono quasi le stesse del 2007: fogli di stile CSS (display: none), posizioni fuori dallo schermo a coordinate estreme, colori del carattere identici allo sfondo. A queste si aggiungono oggi il testo inserito negli attributi HTML (data-*, aria-label, alt, commenti) o stringhe costruite ed eseguite dagli script dopo il caricamento.

Per un'azienda questo tema ha due risvolti operativi fondamentali:

1. Chi è tentato di usarlo si espone allo stesso rischio della SEO black-hat di allora, ma aggravato: Google tratta queste manovre come un problema di sicurezza e addestra i propri modelli, a partire da Gemini, a riconoscerle e ignorarle; il testo nascosto resta comunque vietato dalle norme sullo spam. Un sito scoperto a manipolare gli assistenti rischia di perdere credibilità proprio presso i sistemi da cui vorrebbe essere raccomandato.
2. Chi costruisce agenti che leggono il web deve trattare i contenuti esterni come dati e mai come istruzioni: è indispensabile tenere rigorosamente separate le istruzioni affidabili di sistema (system prompt) dal contesto informativo estratto dalla rete, imponendo sempre una conferma umana (Human-in-the-Loop) prima di compiere azioni con conseguenze irreversibili, come pagamenti, invii di comunicazioni o cancellazioni di record.

Un controllo pratico richiede solo tre passi per verificare se la vostra architettura soffre di asimmetria tra codice sorgente e browser:

1. Ispezione sorgente: aprite una pagina di contenuto (non la home) e usate Visualizza sorgente pagina (Ctrl+U, su Mac Cmd+Opzione+U): il testo che leggete a schermo deve comparire nel sorgente HTML grezzo.
2. Simulazione crawler AI: chiedete al team tecnico di eseguire curl -sL -A "GPTBot" <url> e di confrontare il testo restituito con la pagina vista nel browser: se la risposta è vuota o priva del corpo dell'articolo, i bot AI vedono una pagina inesistente.
3. Controllo testi nascosti: chiedete al team di cercare nel codice sorgente e nei fogli di stile testi nascosti con display: none, coordinate fuori schermo (es. left: -9999px) o attributi HTML (aria-label, alt, data-*) contenenti direttive in linguaggio naturale non pertinenti.