Audit del sito web con l’AI: come verificare un sito con agenti AI, dalle evidenze alla correzione verificata

1. Che cos’è un audit del sito con l’AI

Un audit del sito verifica come è costruito, consegnato e collegato: se è protetto, se motori di ricerca e sistemi AI possono leggerlo, se le persone possono usarlo, quanto è veloce e quali servizi di terze parti carica. Un audit del sito con l’AI aggiunge un agente AI a questo lavoro. L’agente avvia i controlli, legge i risultati, li spiega in linguaggio semplice, decide con te che cosa correggere per primo e scrive la richiesta di modifica per la persona o l’agente di coding che farà l’intervento.

Con le stesse parole si descrivono tre cose molto diverse:

Questa guida riguarda il terzo approccio, perché è quello in cui l’AI fa risparmiare tempo vero mantenendo ogni rilievo legato a evidenze verificabili. I controlli restano ripetibili; l’agente aggiunge giudizio, contesto e il passaggio di consegne alle persone e agli strumenti che rilasciano le modifiche. Se MCP è nuovo per te, la guida a MCP spiega in modo semplice host, client, server e strumenti.

2. Che cosa può e non può fare un agente AI da solo

Un modello linguistico è molto bravo a leggere, riassumere e scrivere. Non è uno strumento di rete. Se l’applicazione non gli mette a disposizione uno strumento adatto, non può vedere ciò che un browser o un crawler vedono sotto la pagina visibile. La tabella confronta un agente che lavora da solo, al massimo con uno strumento di navigazione web, con lo stesso agente che parte da controlli strutturati.

Anche gli agenti di coding con un terminale, come Claude Code, Codex o Cursor, possono eseguire da soli curl, dig o openssl. Questo aiuta a confermare un singolo rilievo, ma l’agente sceglie i comandi strada facendo: la copertura dipende da ciò a cui pensa di guardare, i risultati cambiano da un’esecuzione all’altra e nulla limita le sue prove ai domini che hai verificato.

Il rischio della colonna centrale ha un nome. L’elenco OWASP dei rischi per le applicazioni LLM descrive la misinformation come un output falso o fuorviante che appare credibile, con le allucinazioni tra le cause principali, aggravato dalla fiducia delle persone senza verifica. In un audit si presenta come “la tua policy DMARC è impostata su none” per un dominio il cui record il modello non ha mai letto, oppure come un header dato per mancante che il server invece invia.

Un secondo rischio viene dalle pagine stesse. Un agente che legge un sito legge testo non attendibile, e una pagina può contenere istruzioni rivolte al modello, a volte nascoste ai visitatori umani. OWASP lo chiama indirect prompt injection. Una configurazione di audit accurata tratta il contenuto delle pagine come dati su cui riferire, mai come istruzioni, e fa approvare da una persona ogni azione dell’agente.

L’agente è bravo in tutto ciò che sta attorno alle evidenze: spiegare che cosa significa un rilievo per questo sito in particolare, raggruppare rilievi correlati, chiedere il contesto che i controlli non possono conoscere (quel vecchio sottodominio di staging è ancora in uso?) e scrivere una richiesta di correzione abbastanza precisa per un agente di coding. Questa divisione del lavoro è il cuore di un buon audit con l’AI.

3. Le sei aree da coprire, con una checklist per ciascuna

Un audit completo guarda sei livelli. Ognuno risponde a una domanda diversa e produce un tipo diverso di evidenza. La guida all’audit del sito segue un unico percorso cliente attraverso tutte e sei; qui trovi la checklist operativa.

Sicurezza

• HTTPS e TLS: una catena di certificati attendibile, nessuna scadenza nelle prossime settimane, TLS 1.2 o 1.3 e reindirizzamento da HTTP a HTTPS.
• Header di sicurezza: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, protezione dal framing e un Referrer-Policy sulle risposte HTML.
• CORS: nessun Access-Control-Allow-Origin: * sulle risposte che contengono dati privati e nessuna origine riflessa combinata con le credenziali.
• DNS e DNS della posta: record SPF e DMARC validi per ogni dominio che invia posta e record restrittivi (v=spf1 -all, p=reject) per i domini che non inviano mai posta.
• File e segreti esposti: nulla raggiungibile in percorsi come /.env, /.git/ o vecchi backup, e nessuna chiave API nel JavaScript front-end.
• Sottodomini: nessun record DNS che punti a risorse cloud eliminate che qualcun altro potrebbe rivendicare (subdomain takeover).
• Superficie di attacco: solo le porte aperte e i metodi HTTP che intendi esporre, pagine di accesso e amministrazione note a te, e CMS e plugin aggiornati se usi WordPress.
• Supply chain: script di terze parti caricati solo da fonti scelte da te.

Alcuni di questi controlli leggono solo informazioni pubbliche. Altri, come richiedere percorsi sensibili o scansionare le porte, inviano richieste che il proprietario dovrebbe autorizzare: per questo uno strumento di audit dovrebbe eseguirli solo su target di cui hai verificato la proprietà. La guida all’audit di sicurezza del sito tratta il lato applicativo: account, permessi e accesso.

SEO tecnica

• Scansionabilità: robots.txt non blocca pagine o risorse che vuoi indicizzare.
• Indicizzazione: nessun noindex fuori posto sulle pagine importanti e una sitemap che elenca gli URL canonical.
• Title e meta description: presenti, univoci e descrittivi della pagina.
• Intestazioni: un titolo principale chiaro e una struttura logica.
• Canonical: ogni pagina punta al proprio URL preferito, mai a un redirect o a una pagina di errore.
• Dati strutturati: JSON-LD valido e coerente con il contenuto visibile.
• Link interni e redirect: pagine importanti raggiungibili dalla navigazione o dai contenuti e nessuna catena di più redirect.
• Dati di Search Console: pagine con molte impressioni ma un CTR basso e query in cui ti posizioni appena sotto i primi risultati. Spesso sono i miglioramenti più rapidi.

Qui conta un limite. Google esegue il rendering del JavaScript prima di indicizzare una pagina, ma le sue nozioni di base sulla SEO per JavaScript raccomandano comunque il rendering lato server o il pre-rendering, anche perché alcuni bot non eseguono JavaScript. Un audit che legge HTML statico vede la pagina come la vedono quei bot; su un sito che costruisce i contenuti nel browser, confronta i suoi rilievi con la pagina renderizzata. La guida all’audit SEO tecnico approfondisce.

Prontezza per la visibilità AI

• Policy per i crawler AI: le regole di robots.txt per ciascun crawler AI corrispondono a ciò che hai deciso, non a un’impostazione predefinita di un plugin che nessuno ha scelto. Diversi fornitori documentano token separati per i crawler di ricerca e di addestramento; Google, per esempio, descrive Google-Extended accanto ai suoi crawler di ricerca.
• llms.txt: facoltativo. Un breve indice in Markdown delle pagine più utili, da aggiungere soprattutto ai siti ricchi di documentazione; la guida a llms.txt spiega che cosa fa e che cosa non fa.
• Chiarezza dell’entità: stesso nome dell’attività, stessa descrizione, sede e contatti ovunque, sostenuti da dati strutturati Organization.
• Capacità di rispondere: pagine che rispondono direttamente alle domande reali dei clienti, in alto, in forma di testo e non di immagini.
• Copertura dei prompt: un elenco delle domande che gli acquirenti pongono a un assistente e, per ciascuna, la pagina del tuo sito che risponde.
• Segnali di fonte: un autore o un’organizzazione indicati, date e citazioni che rendono una pagina facile da citare e attribuire.

Sono controlli di prontezza sui tuoi contenuti. Non dicono se un assistente ti citi oggi; per questo serve un registro separato di domande e risposte. Google afferma che le sue funzionalità AI non hanno requisiti aggiuntivi oltre all’idoneità normale per la Ricerca, quindi accesso ai crawler e contenuti chiari vengono prima. La guida all’audit della visibilità AI mostra come costruire l’insieme di domande.

Accessibilità

• Alternative testuali: ogni immagine informativa ha un testo alternativo significativo e le immagini decorative ne hanno uno vuoto.
• Moduli: ogni campo ha un’etichetta associata a livello di codice, non solo un testo segnaposto.
• Struttura: intestazioni in ordine, landmark come main e nav e un link per saltare ai contenuti.
• Nomi: ogni pulsante e link ha un nome accessibile e non ci sono link vuoti.
• Lingua: la pagina dichiara la lingua con l’attributo lang.
• Controlli manuali: uso solo da tastiera, focus visibile, contrasto dei colori, zoom e reflow e una verifica con uno screen reader.

Il W3C è esplicito: gli strumenti non possono controllare automaticamente tutti gli aspetti dell’accessibilità e serve il giudizio umano. Un controllo automatico trova l’etichetta mancante; solo una persona può dire se l’etichetta ha senso. La guida all’audit di accessibilità descrive la verifica manuale rispetto alle WCAG 2.2.

Prestazioni

• Core Web Vitals: Largest Contentful Paint entro 2,5 secondi, Interaction to Next Paint entro 200 millisecondi e Cumulative Layout Shift pari o inferiore a 0,1, al 75° percentile dei caricamenti di pagina (web.dev).
• Prima i dati sul campo: i dati del Chrome UX Report mostrano ciò che gli utenti reali di Chrome hanno vissuto negli ultimi 28 giorni, quando la pagina o il sito ha abbastanza traffico per essere incluso; i risultati di laboratorio di Lighthouse aiutano a trovare la causa.
• Prima il mobile: testa la versione mobile delle pagine che contano, come la home page, una pagina di prodotto o servizio e il checkout o il modulo di contatto.
• Cause tipiche: un’immagine hero troppo pesante, script e font che bloccano il rendering, spostamenti di layout causati da immagini senza dimensioni o da banner tardivi e tag di terze parti pesanti.

La documentazione di PageSpeed Insights osserva che dati di laboratorio e dati sul campo possono differire e che un buon punteggio di laboratorio non significa che i visitatori reali abbiano avuto una buona esperienza. La guida all’audit delle prestazioni mostra come collegare una metrica lenta all’elemento che la causa.

Integrazioni

• Inventario: ogni strumento di analytics, tag manager, pixel pubblicitario, strumento di consenso e tag di verifica del sito presente nella pagina, e chi ne è responsabile.
• Duplicati e residui: due copie dello stesso tag di analytics o un pixel di una campagna terminata l’anno scorso.
• Consenso: uno strumento di consenso dove serve e tag che lo aspettano.
• Dati personali: nessun indirizzo email, numero di telefono o nome nel data layer, negli URL o nei titoli di pagina letti dai tag. La guida di Google Analytics, per esempio, chiede ai proprietari dei siti di tenere le informazioni personali identificabili fuori da URL, titoli ed eventi.

I controlli statici mostrano ciò che il markup dichiara. Se un tag aspetta davvero il consenso, o quali eventi partono dopo un clic, richiede una sessione di browser con gli strumenti per sviluppatori aperti. La guida all’audit delle integrazioni descrive passo per passo questa verifica.

4. Come fare un audit del sito con l’AI, passo dopo passo

Il Model Context Protocol (MCP) è un modo comune per un’applicazione AI di chiamare strumenti di altri servizi. Con un servizio di audit collegato, l’agente nella tua chat o nel tuo strumento di coding può eseguire controlli e lavorare direttamente con i risultati. Il flusso ha nove passaggi; i primi due si fanno una volta per sito, gli altri si ripetono a ogni audit.

1. Collega. Aggiungi il servizio di audit come connessione MCP nel tuo client AI e accedi dal browser. I server MCP remoti che richiedono un account usano di norma OAuth, come descritto nella specifica di autorizzazione MCP: approvi l’accesso in una finestra di accesso e non incolli mai una password o una chiave API nella chat. Sitelemetry si collega così in ChatGPT, Claude, Claude Code, Codex e Cursor; la guida alla connessione MCP riporta i passaggi per ogni client.
2. Definisci perimetro e autorizzazione. Decidi quali siti e pagine rientrano nell’audit e verifica solo siti tuoi o per i quali hai un permesso scritto di test. I controlli passivi leggono ciò che vede qualsiasi visitatore; i controlli di sicurezza attivi inviano richieste di sondaggio, quindi vanno eseguiti solo dopo aver verificato il controllo del dominio. Indica all’agente il perimetro a parole semplici: solo produzione, questi tre URL, nessun invio di moduli.
3. Esegui l’audit. Chiedi un audit completo o di una sola area: “Esegui un audit completo di https://www.example.com ed elenca i rilievi per gravità.” Gli audit lunghi possono girare come attività in background; lascia che l’agente attenda il risultato invece di avviare una seconda scansione.
4. Leggi le evidenze. Ogni rilievo dovrebbe avere una gravità, l’evidenza osservata, l’impatto e una correzione. Chiedi all’agente di citare l’evidenza per tutto ciò che ha gravità alta e riproduci tu stesso uno o due rilievi con curl -sI o dig. Un rilievo riproducibile è un rilievo che puoi correggere con sicurezza.
5. Dai priorità. Ordina per gravità, poi per esposizione (la pagina è pubblica, gestisce accessi o pagamenti?), poi per sforzo. Raggruppa i rilievi che condividono un’unica correzione, come più header impostati nella stessa configurazione del server, e chiedi all’agente quali rilievi contano per questo sito e quali comportano poco rischio qui.
6. Consegna all’agente di coding un prompt di correzione pronto all’uso. Trasforma i rilievi scelti in un’unica richiesta di modifica precisa, con evidenze, vincoli, criteri di accettazione e passaggi di ritest (segue un esempio). Consegnala all’agente di coding che lavora nel tuo repository, oppure lascia che lo stesso client faccia entrambe le cose se ha accesso al repository.
7. Rilascia con il tuo processo abituale. Rivedi il diff, testa su staging e distribuisci come per qualsiasi modifica. L’audit non sostituisce la code review e un agente di coding non dovrebbe distribuire senza l’approvazione di una persona.
8. Ripeti l’audit per verificare. Esegui lo stesso controllo sullo stesso target dopo il rilascio. Un rilievo è chiuso quando un nuovo risultato non lo mostra più, non quando l’agente dice di aver modificato un file.
9. Monitora. Pianifica la ripetizione dell’audit, così che un aggiornamento di plugin, un nuovo tag o un certificato in scadenza emergano prima che li notino i visitatori. Una cadenza settimanale va bene per la maggior parte dei piccoli siti; i siti che rilasciano ogni giorno traggono vantaggio da esecuzioni quotidiane.

La specifica MCP raccomanda un human in the loop che possa negare le chiamate agli strumenti, e OWASP elenca l’excessive agency, cioè il rischio di azioni dannose quando un agente ha più funzionalità, permessi o autonomia di quelli necessari al suo compito, come rischio a sé. In pratica: lascia che gli strumenti di audit leggano e fai approvare da una persona le modifiche al codice e i rilasci.

Un prompt di correzione su cui un agente di coding può agire senza tirare a indovinare ha questa forma (esempio illustrativo):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Ogni parte ha un compito. L’evidenza dice all’agente di coding che cosa è stato osservato, così non deve riscoprire il problema. I vincoli mantengono piccola la modifica; partire con HSTS con un max-age breve e alzarlo per gradi è la via prudente descritta nella guida a HSTS. I criteri di accettazione sono comandi che chiunque può eseguire e il passaggio di ritest chiude il ciclo con lo stesso controllo che ha trovato il problema.

5. Come valutare uno strumento di audit del sito con l’AI

Cerca il miglior strumento AI per l’audit di un sito e troverai lunghi elenchi. La scelta giusta dipende dal tuo sito, ma le domande che separano un buon strumento di audit con l’AI da un chatbot con uno scanner attaccato sono le stesse per ogni prodotto.

Poi metti alla prova ogni candidato sul tuo sito prima di affidarti:

• Eseguilo due volte sulla stessa pagina senza modifiche. Rilievi e gravità devono coincidere.
• Verifica a mano tre rilievi, uno ciascuno per sicurezza, SEO e accessibilità, con curl, dig o il sorgente della pagina.
• Inserisci un problema noto su staging, come un’immagine senza testo alternativo o un title duplicato, e verifica se viene segnalato.
• Correggi un rilievo e ripeti l’audit. Deve sparire e non deve cambiare nulla di non correlato.
• Leggi i limiti. Uno strumento che dice che cosa non controlla è più facile da considerare affidabile di uno che dichiara di controllare tutto.

La sezione 8 elenca ciò che copre Sitelemetry, come passa le correzioni e dove sono i suoi limiti.

6. Errori comuni e come evitarli

Il filo conduttore è sempre lo stesso. Tratta l’agente come un collega rapido e brillante che non ha mai visto il server: dagli evidenze, tieni stretti i suoi permessi e controlla il risultato sul sito attivo.

7. Un esempio concreto: il sito di un piccolo studio dentistico

Uno studio dentistico gestisce un sito WordPress su www.example-clinic.com con un modulo di prenotazione online. La responsabile dell’ufficio collega un servizio di audit al suo assistente AI, verifica il dominio e chiede un audit completo della home page e della pagina di prenotazione. Tra i rilievi (illustrativi, non dati reali):

L’agente spiega perché i primi due vengono prima: il backup espone dati a chiunque indovini il percorso e l’indirizzo nel codice di tracciamento viene passato a ogni tag di terze parti che legge il data layer. Chiede se il blocco dei crawler AI fosse voluto. Nessuno lo aveva deciso, quindi diventa una decisione del titolare e non una correzione.

Per il backup la soluzione non è codice: eliminare il file, cercare altre copie sul server e scoprire quale processo l’ha creato. Poi controllare nei log di accesso se ci sono stati download precedenti, cambiare le password o le chiavi contenute nel backup e, se i dati dei pazienti potrebbero essere stati esposti, seguire la procedura dello studio per le violazioni dei dati. Per le etichette del modulo, l’agente scrive un prompt di correzione che indica i cinque campi e la pagina di prenotazione in cui si trovano, con il vincolo che il design visivo resti invariato e il criterio di accettazione che uno screen reader annunci un’etichetta per ogni campo. L’agente di coding dello sviluppatore fa la modifica, lo sviluppatore la rivede e la distribuisce e un nuovo audit mostra che il rilievo è sparito. Il record DMARC va a chi gestisce il DNS, partendo da p=none con i report, come spiega la guida all’adozione di DMARC. Ogni voce finisce allo stesso modo: modificata, distribuita e ricontrollata con l’audit che l’aveva trovata.

8. Applicare questo flusso con Sitelemetry

Sitelemetry è uno strumento di audit del sito con l’AI costruito per il flusso descritto in questa guida:

• Sei aree. Sicurezza, con fino a 27 moduli nel piano Enterprise: DNS, SPF e DMARC, TLS, postura HTTPS, header di sicurezza, CORS, file esposti, esposizione di API e segreti, subdomain takeover, supply chain, superficie di autenticazione, porte aperte, metodi HTTP, WordPress e altro. SEO tecnica, inclusi clic, CTR, posizione e quick win di Google Search Console. Prontezza per la visibilità AI, accessibilità, prestazioni tramite PageSpeed Insights, Lighthouse e dati sul campo CrUX, e integrazioni.
• Evidenze e correzioni. I rilievi riportano gravità, evidenza, impatto e correzione, e ogni audit può produrre un prompt di correzione pronto per l’agente con vincoli, criteri di accettazione e passaggi di ritest.
• Dentro i tuoi strumenti AI. Funziona via MCP con accesso OAuth in ChatGPT, Claude, Claude Code, Codex e Cursor; la guida alla connessione MCP mostra come collegarlo. L’accesso OAuth significa che approvi l’accesso in una finestra del browser e non incolli mai una password o una chiave API nella chat.
• Verifica e monitoraggio. Ripeti l’audit dopo una correzione per confermarla sul sito attivo. A seconda del piano, il monitoraggio gira ogni settimana, ogni giorno o ogni ora. I report si esportano in JSON o PDF, con report white-label nel piano Enterprise.
• Piani. Starter a $49/mese, Professional a $149/mese ed Enterprise a $249/mese; la pagina dei prezzi elenca che cosa include ciascuno.

I suoi limiti sono quelli che questa guida ti invita a cercare. Gli audit ospitati osservano il target senza modificarlo e i controlli di sicurezza attivi vengono eseguiti solo su target verificati. I controlli di SEO, visibilità AI, accessibilità e integrazioni leggono HTML statico senza eseguire JavaScript. La visibilità AI controlla la prontezza dei contenuti e non interroga gli assistenti AI. I controlli di accessibilità sono statici e orientati alle WCAG 2.2, non una valutazione manuale completa, e l’audit di sicurezza non è un penetration test. Mantieni i controlli manuali della sezione 3 per ciò che l’analisi statica non vede.