Una pagina web non viene più letta solo da persone. Viene attraversata da motori di ricerca, crawler AI, sistemi di anteprima, strumenti SEO e automazioni che spesso hanno bisogno di risposte diverse da quelle pensate per un browser umano.
Il web non ha più un solo lettore
Per anni abbiamo progettato siti immaginando un utente davanti a uno schermo. Oggi quella è solo una parte della storia. La stessa pagina può essere richiesta da Googlebot, da un crawler AI, da uno strumento di anteprima o da un browser tradizionale.
Il problema è che tutti questi client non leggono il sito nello stesso modo. Un browser può gestire JavaScript, animazioni e interazioni. Un crawler AI può preferire contenuto compatto e leggibile. Un motore di ricerca può avere bisogno di metadati chiari, canonical coerenti e dati strutturati.
LLM Proxy Worker nasce da questa idea: non cambiare il sito origine, ma aggiungere davanti un livello capace di adattare la risposta in base a chi sta leggendo.
Un proxy edge come livello intelligente
Il Worker gira su Cloudflare Workers e si comporta come un middleware all'edge. Riceve la richiesta, osserva URL, query param, User-Agent e header, poi decide quale percorso applicare.
Se arriva un browser umano, il sito continua a rispondere in modo normale, con eventuale arricchimento SEO. Se arriva un crawler AI o una route di debug LLM, il Worker può trasformare l'HTML in markdown. Se arriva un crawler che fatica con JavaScript, può servire HTML prerenderizzato.
Questa architettura è interessante perché aggiunge capacità trasversali senza riscrivere CMS, frontend o backend principale.
- browser: pagina originale o arricchita con metadati
- crawler AI: versione markdown più pulita e leggibile
- crawler di ricerca: HTML prerenderizzato quando serve
- debug route: risposte diagnostiche per capire cosa sta succedendo
Markdown per LLM: meno rumore, più contenuto
Una pagina HTML completa contiene molto più di ciò che un sistema linguistico deve davvero leggere: script, style, footer, navigazione, banner, SVG, form e altri elementi tecnici.
Per un crawler AI, tutto questo rumore consuma token e può spostare l'attenzione lontano dal contenuto reale. La conversione in markdown serve a restituire una versione più compatta, ordinata e vicina al testo utile della pagina.
Non è una scorciatoia magica. È una scelta di interfaccia tra sito e sistemi automatici: se il lettore non è umano, la risposta può essere più adatta al suo modo di elaborare informazioni.
SEO generata con AI, ma con vincoli
La parte più delicata non è chiamare un modello. È evitare che il modello diventi una scatola nera. Nel progetto, la generazione SEO parte da dati reali: HTML della pagina, keyword, dati SERP, intento di ricerca, competitor e vincoli calcolati dal codice.
OpenAI è il provider principale, Claude è il fallback, ma l'output non viene accettato alla cieca. Il risultato deve essere JSON valido e deve superare controlli su title, description, Open Graph, canonical e JSON-LD.
Questo cambia il ruolo dell'AI: non decide da sola cosa sia importante, ma lavora dentro un perimetro definito dal sistema.
Prerender solo quando serve davvero
Molte pagine moderne dipendono da JavaScript. Un browser umano le vede correttamente, ma alcuni crawler possono fermarsi all'HTML iniziale e perdere parte del contenuto.
Per questi casi il Worker può usare Cloudflare Browser Rendering con Puppeteer: apre la pagina, lascia eseguire JavaScript e restituisce l'HTML finale. È potente, ma anche costoso rispetto a una normale richiesta.
Per questo il prerender non viene applicato a tutti. Si attiva solo per crawler, policy specifiche o debug esplicito. Gli utenti normali restano sul percorso più leggero.
Cache, fallback e sostenibilità
Una soluzione basata su LLM e Chromium può diventare fragile se ogni richiesta genera lavoro costoso. Per questo il progetto usa Cloudflare KV per salvare metadati SEO e HTML prerenderizzato.
La prima richiesta può generare il risultato. Le successive possono riusarlo. Questo riduce token, chiamate esterne, latenza e variabilità dell'output.
La parte più importante, però, è il comportamento in caso di errore. Se DataForSEO non risponde, se OpenAI fallisce, se Claude non è disponibile o se Chromium va in timeout, il sito non deve rompersi. Il Worker torna a fallback ragionevoli oppure alla pagina originale.
La parte senior: decidere cosa non fare
La cosa interessante di un progetto così non è usare più servizi possibili. È decidere quando non usarli. Un LLM a ogni richiesta sarebbe scenografico, ma costoso, lento e poco prevedibile. Un browser headless per ogni visita sarebbe potente, ma sproporzionato. Una cache usata come database diventerebbe presto un problema di coerenza.
Il lavoro architetturale sta nel disegnare confini chiari: quali richieste meritano AI, quali meritano prerender, quali possono restare sul percorso standard e cosa succede quando un provider esterno non risponde.
Questa è la differenza tra una demo che funziona nel caso ideale e un sistema che può vivere davanti a traffico reale. Non basta aggiungere intelligenza: bisogna contenerla, misurarla e renderla sostituibile.
Un web leggibile anche dalle macchine
LLM Proxy Worker non prova a sostituire il sito. Prova a renderlo più leggibile per i diversi lettori del web moderno: persone, motori di ricerca, crawler AI e strumenti automatici. È un piccolo esempio di architettura adattiva: stessa origine, risposte diverse, costi controllati e fallback sempre presenti.
Continua a leggere