Audit di Accessibilità AI per la Prontezza degli Agenti

I sistemi AI non possono citare, raccomandare o agire su contenuti che non riescono a recuperare in modo affidabile. Questa fase verifica questa base prima che il team misuri la visibilità o commissioni contenuti destinati ai motori di risposta.

Fase: P4, Stadio A — Comprendere. Timebox: 3–5 giorni lavorativi per un sito di marketing tipico; 5–10 per un grande e-commerce, marketplace o applicazione fortemente renderizzata lato client. Proprietario: il responsabile SEO tecnico è accountable, con l’ingegneria che esegue i test di fetch e rendering, il responsabile dei contenuti che revisiona l’estraibilità, e un responsabile aziendale o legale che decide la politica sui crawler.

Perché questa fase viene qui

Un audit tecnico convenzionale chiede se i motori di ricerca possono eseguire crawling, rendering, indicizzazione e posizionamento del sito. Questa fase chiede se i crawler AI, i sistemi di recupero e gli agenti orientati alle attività possono raggiungere e interpretare le stesse informazioni utili. Essi possono utilizzare diversi user agent, percorsi di fetch, capacità di rendering, timeout e metodi di estrazione. Una pagina indicizzabile può comunque restituire un guscio vuoto, una parete di consenso, una challenge bot o frammenti disconnessi a un client AI.

Un audit di accessibilità AI appartiene quindi accanto all’audit baseline tecnico , non alla fine della produzione di contenuti. Il rendering lato client significa che JavaScript costruisce contenuti importanti dopo l’arrivo dell’HTML iniziale. I sistemi di recupero potrebbero non eseguire quel codice, potrebbero fermarsi prima del suo completamento, o potrebbero estrarre solo la risposta iniziale. Se il nome del prodotto, la risposta, il prezzo, la disponibilità o l’evidenza esistono solo dopo l’esecuzione di JavaScript, l’ottimizzazione successiva dei contenuti non può riparare il fallimento di accesso.

Questa fase consuma gli account verificati, le analisi, i log dei crawler, le fonti delle sitemap, il set di URL critici e la mappa delle proprietà dalla fase di accesso, tracciamento e fonti dati . Eseguirla prima lascia il team incapace di distinguere un’assenza genuina da una mancanza di accesso. Eseguirla dopo la misurazione baseline contamina la baseline: zero citazioni potrebbero riflettere un sito inaccessibile, non contenuti deboli o domanda.

Saltare la fase spreca lavoro: gli scrittori migliorano passaggi che un crawler non riceve mai, gli sviluppatori aggiungono schema dietro una challenge, o il team scambia un llms.txt valido per una prontezza a livello di sito. Accesso, estrazione, comprensione e azione sono capacità separate.

Input e output

Gli input rendono i test riproducibili. Gli output formano un contratto con P5: la misurazione inizia solo dopo che i fallimenti di accesso noti sono stati risolti o esplicitamente accettati.

La checklist

Testa il set di URL rappresentativi, non solo la homepage, e conserva evidenze riproducibili.

1. Decidi deliberatamente l’accesso dei crawler

Cosa fare: inventaria le regole per i crawler AI in robots.txt , controlli bot del CDN, firewall per applicazioni web, layer di consenso e configurazione dell’origine. Perché è importante: un allow in robots è solo una preferenza; un servizio edge può comunque bloccare la richiesta, mentre un blocco wildcard accidentale non è una policy. Come farlo: confronta le regole live con la matrice delle policy, recupera URL rappresentativi con user agent applicabili e registra il compromesso. Strumento: AmICited Robots.txt & Sitemaps, un client di richiesta approvato e log CDN/origine. Completato quando: ogni famiglia di crawler ha una decisione approvata di allow, block o condizionale e il comportamento live corrisponde.

2. Confronta la risposta non-JavaScript con la pagina utile

Cosa fare: confronta l’HTML iniziale con la pagina browser normale. Perché è importante: un client di recupero potrebbe non eseguire script che inseriscono risposte, offerte, link o dati prodotto. Come farlo: testa ogni template importante prima dell’hydratation, il processo che collega il comportamento dell’applicazione all’HTML del server. Strumento: un browser senza script o client HTTP più la pagina renderizzata. Completato quando: la risposta iniziale contiene il titolo, H1, contenuto primario, fatti principali e link di scoperta; ogni eccezione ha evidenza e un proprietario.

3. Testa l’estraibilità del DOM renderizzato

Cosa fare: estrai il contenuto principale dal Document Object Model (DOM) renderizzato, la rappresentazione strutturata della pagina nel browser, senza navigazione, testo di consenso o varianti nascoste. Perché è importante: ricevere testo non equivale a identificare il testo corretto; il rumore del template può corrompere il recupero. Come farlo: confronta titolo, risposta, editore, date, fatti e link estratti con la fonte visibile su pagine lunghe, concise e commerciali. Strumento: ispezione browser, estrazione testo e sorgente pagina. Completato quando: il record preserva il significato principale e i fatti senza posizione visiva o selettori non documentati.

4. Ispeziona l’albero di accessibilità

Cosa fare: revisiona l’albero di accessibilità: ruoli, nomi, stati, intestazioni, landmark e controlli. Perché è importante: la semantica distingue le intestazioni dalla decorazione, i pulsanti dalle icone e il contenuto primario dalla navigazione. Come farlo: testa i template critici per un H1, intestazioni ordinate, controlli nominati, landmark, link descrittivi e alternative significative per le immagini. Strumento: controllo Albero di Accessibilità di AmICited e ispezione browser. Completato quando: il punteggio raggiunge la soglia, nessun controllo critico manca di un nome e la regione principale e l’azione successiva sono identificabili.

5. Valida la copertura e la veridicità dei dati strutturati

Cosa fare: confronta i fatti visibili con i dati strutturati , markup standardizzato come Schema.org JSON-LD. Perché è importante: il markup chiarisce entità, offerte, paternità e date, ma un markup inaccurato comunica il fatto sbagliato. Come farlo: valida gli schemi applicabili e riconcilia nomi, URL, prezzi, valuta, disponibilità, date, valutazioni e identificatori con i sistemi sorgente. Strumento: validatore, HTML renderizzato e registri sorgente. Completato quando: i template critici hanno markup applicabile valido, i valori corrispondono ai fatti visibili e ogni avviso materiale è risolto o spiegato.

6. Revisiona llms.txt come guida, non come cancello

Cosa fare: verifica se /llms.txt riassume accuratamente l’organizzazione e rimanda a risorse pubbliche canoniche. È una guida testuale semplice proposta, non un controllo di accesso o un segnale di ranking garantito. Perché è importante: una mappa concisa riduce l’ambiguità; una obsoleta disorienta gli agenti. Come farlo: verifica stato, struttura Markdown, descrizione, destinazioni, URL canonici e proprietario. Strumento: revisione llms.txt di AmICited e fetch diretto. Completato quando: il file, se utilizzato, non ha link rotti/privati e un proprietario della manutenzione; l’assenza è un’opportunità di miglioramento, non una prova di invisibilità.

7. Campiona passaggi autonomi

Cosa fare: revisiona definizioni, risposte, fatti, confronti, passaggi e limitazioni recuperati indipendentemente. Perché è importante: il recupero può separare un paragrafo dalla sua intestazione; “funziona meglio per loro” perde quindi il soggetto e il confronto. Come farlo: leggi almeno 20 passaggi senza il loro titolo o paragrafo precedente. Strumento: output di estrazione e revisione editoriale. Completato quando: ciascuno nomina il proprio soggetto, risponde a una domanda identificabile, preserva condizioni o unità ed evita riferimenti irrisolti.

8. Conferma la chiarezza dell’entità canonica

Cosa fare: verifica che il sito dichiari chi è l’organizzazione, cosa offre e come si relazionano i suoi marchi, prodotti, persone, sedi e profili. Un’entità canonica è la cosa reale primaria a cui un nome si riferisce. Perché è importante: nomi incoerenti, loghi vecchi, descrizioni contrastanti e URL di profili disconnessi rendono facile fondere due entità o dividerne una in più. Come farlo: confronta la homepage, la pagina Chi Siamo, i dettagli di contatto, i dati strutturati, i profili social, le pagine autore, il nome legale e i profili importanti di terze parti. Strumento: scheda informativa dell’entità, pagine renderizzate e output dei dati strutturati. Completato quando: una scheda informativa approvata risolve nome ufficiale, alias, URL canonico, logo, descrizione, proprietà, offerte primarie e profili della stessa entità, con i conflitti registrati per la correzione.

9. Testa il tempo di risposta e l’affidabilità del fetch

Cosa fare: misura stato, Time to First Byte (TTFB), redirect, timeout e consistenza della risposta in condizioni normali e con user agent crawler rilevanti. TTFB è l’intervallo dall’inizio della richiesta all’arrivo del primo byte di risposta. Perché è importante: 403, 429, 5xx intermittenti, lunghe catene di redirect o origini lente rendono il contenuto inaffidabile anche quando una singola visita browser riesce. Come farlo: esegui il campione ripetibile definito nella tabella delle soglie da più di una posizione di rete quando la geografia è rilevante, poi riconcilia i fallimenti con i log e i Core Web Vitals. Strumento: monitor delle richieste, log CDN/origine e AmICited Web Vitals. Completato quando: gli URL critici soddisfano le soglie di affidabilità e latenza o hanno una gravità, causa, proprietario e data di ripetizione test.

10. Valuta WebMCP e i protocolli commerciali dove creano valore

Cosa fare: testa WebMCP e la prontezza commerciale solo dove il modello di business supporta azioni degli agenti. WebMCP è un modo emergente per un sito web di esporre strumenti richiamabili, come ricerca, prenotazione o aggiunta di un articolo al carrello. Il commercio agentivo copre la scoperta di prodotti e le transazioni assistite da agenti, inclusi protocolli come ACP o UCP. Perché è importante: contenuti leggibili supportano risposte; strumenti espliciti e dati commerciali supportano azioni affidabili senza screen scraping. Come farlo: mappa le attività utente di valore, ispeziona gli strumenti o i protocolli dichiarati, valida le descrizioni di input e output e verifica conferma, autenticazione, permessi, prezzo, inventario e comportamento in caso di errore. Strumento: controlli WebMCP e Commercio Agentivo di AmICited più un ambiente di test controllato. Completato quando: le capacità applicabili sono rilevate e testabili in sicurezza, oppure il controllo è contrassegnato come non applicabile con una motivazione approvata basata sul modello di business e un trigger di revisione.

Strumenti in AmICited

Apri https://app.amicited.com/accessibility per l’audit consolidato e la spiegazione della funzionalità Accessibilità AI e Prontezza degli Agenti . I prodotti riportano letture indipendenti piuttosto che nascondere diversi tipi di fallimento all’interno di un unico punteggio misto.

1. Usa il riepilogo per controllare il Punteggio di Accessibilità degli Agenti e registra ogni componente, non solo lo stato principale.
2. Usa Robots.txt & Sitemaps per controllare la copertura di robots.txt e sitemap , poi confronta la regola dichiarata con un fetch live in stile crawler.
3. Usa la revisione file per revisionare llms.txt e apri ogni destinazione elencata.
4. Usa il controllo pagina per ispezionare l’albero di accessibilità di una pagina per ogni template critico.
5. Usa i controlli di prontezza per verificare la prontezza WebMCP e verificare la prontezza del commercio agentivo quando tali capacità si applicano.
6. Apri https://app.amicited.com/audit/web-vitals per controllare i Core Web Vitals e collegare le performance sul campo con i test di richiesta in condizioni crawler.

Regole decisionali

Queste sono soglie operative di accettazione, non affermazioni su algoritmi di ranking. Stringile per percorsi critici per le entrate o contenuti regolamentati e registra qualsiasi alternativa prima del test, in modo che il risultato non venga aggiustato dopo il fatto.

I punteggi non sostituiscono mai le evidenze concrete. Un punteggio di accessibilità di 85 non giustifica un pulsante di checkout senza etichetta, e un allow in robots non supera una pagina challenge restituita alla richiesta reale. “Non controllato” è sconosciuto, non un superamento né uno zero.

Deliverable: il registro dei risultati sulla prontezza degli agenti

Consegna un unico registro dei risultati, non una presentazione e un backlog AI separato. Aggiungi ogni risultato alla lista prioritaria P2 con questi campi:

ID e titolo:
URL/template interessati:
Controllo e condizione osservata:
Condizione/soglia attesa:
Evidenza: timestamp, user agent, stato, cattura o riferimento log
Conseguenza aziendale:
Gravità: Critico | Maggiore | Consultivo
Azione raccomandata:
Proprietario e approvatore:
Sforzo e dipendenza:
Data di scadenza e data di ripetizione test:
Decisione politica, se pertinente:
Impatto sulla misurazione P5:
Stato: Aperto | Rischio accettato | Risolto | Verificato

Critico significa che il fallimento impedisce l’accesso affidabile, modifica materialmente il significato estratto o consente un’azione non sicura. Maggiore significa che l’accesso o la comprensione sono degradati ma un client rappresentativo può comunque recuperare il contenuto principale. Consultivo significa che un miglioramento utile manca di evidenze di fallimento attuale. Rischio accettato richiede il proprietario aziendale nominato, la motivazione, l’ambito interessato, la data di scadenza o revisione e un modo per rilevare condizioni modificate.

Deduplica per causa principale: una challenge CDN che colpisce crawler convenzionali e AI è un unico elemento con molteplici registri di evidenza.

Cosa va storto

Trattare la fase come opzionale. Il monitoraggio dei prompt e le riscritture dei contenuti non possono compensare un recupero fallito. Rendi P4 una condizione di ingresso per una baseline interpretabile.

Bloccare per default e chiamarlo retroattivamente policy. Una regola senza decisore, motivazione o data di revisione è configurazione, non policy. Presenta il compromesso scoperta-controllo e ottieni una decisione esplicita.

Aggiungere llms.txt e dichiarare completamento. Il file non può sovrascrivere le regole robots, i blocchi CDN, l’HTML iniziale vuoto, il markup fuorviante, i passaggi deboli o i timeout. Trattalo come una guida all’interno del più ampio set di evidenze.

Testare solo uno user agent amichevole o la homepage. I controlli edge variano per percorso, geografia, frequenza e identità. Testa ogni template e user agent ad alto valore nella matrice delle policy.

Confondere aspetto con estraibilità. Una pagina rifinita può esporre duplicati nascosti, nomi di controllo privi di significato o una risposta senza script vuota. Conserva separatamente le evidenze di sorgente, DOM, albero di accessibilità e testo estratto.

Trattare l’ignoto come fallimento o successo. Ripeti i test sui timeout e sui crawler non controllati; non convertire mai evidenze mancanti in un punteggio comodo.

Installare capacità agentive sperimentali senza un caso d’uso. I protocolli WebMCP o commerciali dovrebbero esporre azioni preziose e autorizzate. Rilasciare un’azione non sicura o inaccurata è peggio che contrassegnare la capacità come non applicabile.

Passaggio alla misurazione baseline

La fase di misurazione baseline riceve la lista prioritaria unificata, il pacchetto di evidenze dei test, il registro della politica sui crawler, il set di URL rappresentativi e la nota di prontezza. Il proprietario P4 deve identificare qualsiasi limitazione che cambi l’interpretazione: famiglie di crawler bloccate, template inaccessibili, regioni intermittenti, passaggi mancanti o una correzione recente il cui effetto non si è ancora propagato.

P5 può procedere quando gli URL critici sono intenzionalmente accessibili alle famiglie di crawler incluse nella misurazione, il contenuto primario valido è estraibile e nessun risultato Critico irrisolto renderebbe un punteggio zero o basso non interpretabile. Può procedere con annotazioni quando un blocco deliberato esclude un crawler noto o un problema Maggiore riguarda un template delimitato. Dovrebbe attendere quando l’intento di accesso è sconosciuto, le pagine critiche falliscono i fetch o il contenuto estratto contraddice materialmente la fonte visibile.

Il passaggio è completo quando il proprietario P5 può rispondere a tre domande senza riaprire l’audit: quali agenti avevano accesso previsto, quali pagine e fatti potevano recuperare in modo affidabile e quali limitazioni note devono apparire accanto alla baseline.

FAQ

Domande frequenti