Audit de Accesibilitate AI pentru Pregătirea Agenților
Realizează un audit de accesibilitate AI care acoperă accesul crawlerelor, extracția, datele structurate, llms.txt, viteza, WebMCP și pregătirea pentru comerțul agentic pe paginile cheie.
Sistemele AI nu pot cita, recomanda sau acționa pe baza conținutului pe care nu îl pot recupera în mod fiabil. Această fază testează acea fundație înainte ca echipa să măsoare vizibilitatea sau să comande conținut destinat motoarelor de răspuns.
Faza: P4, Etapa A — Înțelegere. Timp alocat: 3–5 zile lucrătoare pentru un site de marketing tipic; 5–10 pentru un e-commerce mare, marketplace sau aplicație puternic renderizată pe client. Responsabil: liderul SEO tehnic este răspunzător, inginerii executând testele de preluare și renderizare, liderul de conținut revizuind extractibilitatea, iar un responsabil de afaceri sau juridic decidând politica pentru crawler-e.
De ce această fază vine aici
Un audit tehnic convențional întreabă dacă motoarele de căutare pot accesa cu crawl, renderiza, indexa și clasifica site-ul. Această fază întreabă dacă crawler-ele AI, sistemele de recuperare și agenții orientați pe sarcini pot ajunge și interpreta aceleași informații utile. Ei pot folosi agenți de utilizator diferiți, căi de preluare, capacități de renderizare, timeout-uri și metode de extracție diferite. O pagină indexabilă poate returna totuși o carcasă goală, un perete de consimțământ, o provocare bot sau fragmente deconectate unui client AI.
Un audit de accesibilitate AI aparține deci lângă auditul de bază tehnic , nu la sfârșitul producției de conținut. Renderizarea pe partea de client înseamnă că JavaScript construiește conținut important după ce HTML-ul inițial ajunge. Sistemele de recuperare pot să nu execute acel cod, se pot opri înainte ca acesta să se completeze sau pot extrage doar răspunsul inițial. Dacă numele produsului, răspunsul, prețul, disponibilitatea sau dovada există doar după execuția JavaScript, optimizarea ulterioară a conținutului nu poate repara eșecul de acces.
Această fază consumă conturile verificate, analizele, jurnalele crawlerelor, sursele de sitemap, setul de URL-uri critice și harta de proprietate din faza de acces, urmărire și surse de date . Realizarea ei mai devreme lasă echipa incapabilă să distingă o absență reală de o lipsă de acces. Realizarea ei după măsurarea valorii de bază contaminează valoarea de bază: zero citări pot reflecta un site inaccesibil, nu conținut slab sau cerere scăzută.
Omisiunea acestei faze risipește muncă: scriitorii îmbunătățesc pasaje pe care un crawler nu le primește niciodată, dezvoltatorii adaugă schemă în spatele unei provocări, sau echipa confundă un llms.txt valid cu o pregătire la nivel de site. Accesul, extracția, înțelegerea și acțiunea sunt capacități separate.
Intrări și ieșiri
Intrările fac testele reproductibile. Ieșirile formează un contract cu P5: măsurarea începe doar după ce eșecurile de acces cunoscute sunt remediate sau acceptate explicit.
| Direcție | Element | Condiție de acceptare |
|---|---|---|
| Intrare | Pachetul de acces și proprietate P2 | Include acces la producție, surse de analiză și jurnale, proprietari robots și CDN, proprietarul politicii juridice/de afaceri și calea de escaladare. |
| Intrare | Set de URL-uri reprezentativ | Include pagina principală plus cel puțin un URL de mare valoare pentru fiecare șablon important: produs, categorie, serviciu, articol, documentație, locație și pagină tranzacțională acolo unde este cazul. |
| Intrare | Matricea politicii pentru crawler-e | Listează familiile relevante de crawler-e, regula curentă, regula intenționată, proprietarul deciziei, rațiunea și data revizuirii; intenția necunoscută este înregistrată ca necunoscută, nu „blocat de politică." |
| Intrare | Constatări tehnice P3 | Furnizează dovezi privind canonical, status, renderizare, sitemap, performanță și date structurate, astfel încât această fază să poată izola comportamentul specific AI. |
| Intrare | Date despre entitate și oferte | Numește organizația canonică, produsele sau serviciile, numele alternative, URL-urile oficiale și faptele pe care un extractor trebuie să le identifice corect. |
| Ieșire | Pachet de dovezi de test | Stochează pentru fiecare test: timestamp, URL, agent de utilizator, statusul răspunsului, antetele răspunsului, HTML-ul inițial sau dovada arborelui și capturi de ecran. |
| Ieșire | Înregistrarea deciziei de politică | Arată permisiunea, blocarea sau accesul condiționat pentru fiecare familie de crawler-e, cu un aprobator responsabil și o verificare a implementării. |
| Ieșire | Registrul constatărilor privind pregătirea agenților | Oferă fiecărei condiții eșuate: severitate, domeniu afectat, dovezi, recomandare, proprietar, efort, dependență și dată de retestare. |
| Ieșire | Actualizarea listei de priorități P2 | Integrează constatările privind agenții în backlog-ul interfuncțional existent, în loc să creeze o coadă separată „SEO AI." |
| Ieșire | Notă de pregătire P5 | Indică ce limitări ar distorsiona măsurarea valorii de bază și dacă P5 poate continua, poate continua cu adnotări sau trebuie să aștepte. |
Lista de verificare
Testează setul de URL-uri reprezentativ, nu doar pagina principală, și păstrează dovezi reproductibile.
1. Decide accesul crawlerelor în mod deliberat
Ce trebuie făcut: inventariază regulile pentru crawler-e AI în robots.txt , controalele bot ale CDN-ului, firewall-urile aplicațiilor web, straturile de consimțământ și configurația originii. De ce contează: o permisiune în robots este doar o preferință; un serviciu de margine poate bloca totuși cererea, în timp ce o blocare accidentală cu wildcard nu este o politică. Cum se face: compară regulile live cu matricea de politici, preia URL-uri reprezentative cu agenți de utilizator aplicabili și înregistrează compromisul. Instrument: AmICited Robots.txt & Sitemap-uri, un client de cereri aprobat și jurnale CDN/origin. Terminat când: fiecare familie de crawler-e are o permisiune aprobată, o blocare sau o decizie condiționată, iar comportamentul live corespunde acesteia.
2. Compară răspunsul non-JavaScript cu pagina utilă
Ce trebuie făcut: compară HTML-ul inițial cu pagina normală din browser. De ce contează: un client de recuperare poate să nu ruleze scripturile care inserează răspunsuri, oferte, linkuri sau date despre produse. Cum se face: testează fiecare șablon important înainte de hidratare — procesul care atașează comportamentul aplicației la HTML-ul serverului. Instrument: un browser fără script sau un client HTTP, plus pagina renderizată. Terminat când: răspunsul inițial conține titlul, H1, conținutul principal, faptele de bază și linkurile de descoperire; orice excepție are dovezi și un proprietar.
3. Testează extractibilitatea DOM-ului renderizat
Ce trebui făcut: extrage conținutul principal din Document Object Model (DOM) renderizat — reprezentarea structurată a paginii în browser — fără navigare, text de consimțământ sau variante ascunse. De ce contează: a primi text nu înseamnă a identifica textul corect; zgomotul din șablon poate corupe recuperarea. Cum se face: compară titlul extras, răspunsul, editorul, datele, faptele și linkurile cu sursa vizibilă pe pagini lungi, scurte și comerciale. Instrument: inspecția browserului, extracția textului și sursa paginii. Terminat când: înregistrarea păstrează sensul principal și faptele fără poziție vizuală sau selectoare nedocumentate.
4. Inspectează arborele de accesibilitate
Ce trebuie făcut: revizuiește arborele de accesibilitate: roluri, nume, stări, titluri, repere și controale. De ce contează: semantica distinge titlurile de decor, butoanele de icoane și conținutul principal de navigare. Cum se face: testează șabloanele critice pentru un H1, titluri ordonate, controale denumite, repere, linkuri descriptive și alternative de imagine semnificative. Instrument: verificatorul Arborelui de Accesibilitate AmICited și inspecția browserului. Terminat când: scorul atinge pragul, niciun control critic nu lipsește de nume, iar regiunea principală și următoarea acțiune sunt identificabile.
5. Validează acoperirea și corectitudinea datelor structurate
Ce trebuie făcut: compară faptele vizibile cu datele structurate — markup standardizat precum Schema.org JSON-LD. De ce contează: markup-ul clarifică entitățile, ofertele, autoratul și datele, dar markup-ul incorect comunică faptul greșit. Cum se face: validează schemele aplicabile și reconciliază numele, URL-urile, prețurile, valuta, disponibilitatea, datele, ratingurile și identificatorii cu sistemele sursă. Instrument: validator, HTML renderizat și înregistrări sursă. Terminat când: șabloanele critice au markup valid aplicabil, valorile corespund faptelor vizibile și fiecare avertizare materială este rezolvată sau explicată.
6. Revizuiește llms.txt ca ghid, nu ca poartă
Ce trebuie făcut: verifică dacă /llms.txt sumarizează corect organizația și conține linkuri către resurse publice canonice. Este un ghid propus în text simplu, nu un control de acces sau un semnal garantat de clasare. De ce contează: o hartă concisă reduce ambiguitatea; una învechită induce în eroare agenții. Cum se face: verifică statusul, structura Markdown, descrierea, destinațiile, URL-urile canonice și proprietarul. Instrument: revizuirea llms.txt AmICited și preluarea directă. Terminat când: fișierul, dacă este folosit, nu are linkuri rupte/private și are un proprietar de întreținere; absența este o constatare de îmbunătățire, nu o dovadă de invizibilitate.
7. Eșantionează pasaje autosuficiente
Ce trebuie făcut: revizuiește definiții, răspunsuri, fapte, comparații, pași și limitări recuperate independent. De ce contează: recuperarea poate separa un paragraf de titlul său; „funcționează mai bine pentru ei" își pierde apoi subiectul și comparația. Cum se face: citește cel puțin 20 de pasaje fără titlul sau paragraful anterior. Instrument: rezultatul extracției și revizuire editorială. Terminat când: fiecare își numește subiectul, răspunde la o întrebare identificabilă, păstrează condițiile sau unitățile și evită referințe nerezolvate.
8. Confirmă claritatea entității canonice
Ce trebuie făcut: verifică că site-ul declară cine este organizația, ce oferă și cum se relaționează mărcile, produsele, persoanele, locațiile și profilele sale. O entitate canonică este lucrul real principal la care se referă un nume. De ce contează: nume inconsistente, sigle vechi, descrieri contradictorii și URL-uri de profil deconectate fac ușoară fuzionarea a două entități sau divizarea unei entități în mai multe. Cum se face: compară pagina principală, pagina Despre, detaliile de contact, datele structurate, profilele sociale, paginile de autor, numele legal și profilele terțe importante. Instrument: fișă de date a entității, pagini renderizate și rezultatul datelor structurate. Terminat când: o fișă de date aprobată rezolvă numele oficial, aliasurile, URL-ul canonic, sigla, descrierea, proprietatea, ofertele principale și profilele aceleiași entități, cu conflictele înregistrate pentru corectare.
9. Testează timpul de răspuns și fiabilitatea preluării
Ce trebuie făcut: măsoară statusul, Timpul până la Primul Byte (TTFB), redirecționările, timeout-urile și consistența răspunsului în condiții normale și cu agenți de utilizator crawler relevanți. TTFB este intervalul de la începutul cererii până la sosirea primului byte de răspuns. De ce contează: 403-uri, 429-uri, răspunsuri 5xx intermitente, lanțuri lungi de redirecționări sau origini lente fac conținutul nefiabil chiar și atunci când o singură vizită din browser reușește. Cum se face: rulează eșantionul reproductibil definit în tabelul de praguri din mai multe locații de rețea când geografia contează, apoi reconciliază eșecurile cu jurnalele și Core Web Vitals. Instrument: monitor de cereri, jurnale CDN/origin și AmICited Web Vitals. Terminat când: URL-urile critice satisfac pragurile de fiabilitate și latență sau au o severitate, cauză, proprietar și dată de retestare.
10. Evaluează WebMCP și protocoalele de comerț acolo unde creează valoare
Ce trebuie făcut: testează pregătirea WebMCP și de comerț doar acolo unde modelul de afaceri suportă acțiuni ale agenților. WebMCP este un mod emergent prin care un site poate expune instrumente apelabile, cum ar fi căutarea, rezervarea sau adăugarea unui articol în coș. Comerțul agentic acoperă descoperirea și tranzacțiile asistate de agenți, inclusiv protocoale precum ACP sau UCP. De ce contează: conținutul lizibil suportă răspunsuri; instrumente explicite și date de comerț suportă acțiuni fiabile fără screen scraping. Cum se face: mapează sarcinile valoroase ale utilizatorilor, inspectează instrumentele sau protocoalele declarate, validează descrierile de intrare și ieșire și verifică confirmarea, autentificarea, permisiunile, prețul, inventarul și comportamentul la erori. Instrument: verificările WebMCP și Comerț Agentic AmICited plus un mediu de test controlat. Terminat când: capacitățile aplicabile sunt detectate și testabile în siguranță, sau verificarea este marcată ca neaplicabilă cu un motiv aprobat bazat pe modelul de afaceri și un declanșator de revizuire.
Instrumente în AmICited
Deschide https://app.amicited.com/accessibility pentru auditul consolidat și explicația caracteristicii Accesibilitate AI și Pregătirea Agenților
. Produsul raportează lecturi independente, mai degrabă decât să ascundă diferite tipuri de eșec într-un singur scor combinat.
- Folosește sumarul pentru a verifica Scorul de Accesibilitate al Agenților și înregistrează fiecare componentă, nu doar starea principală.
- Folosește Robots.txt & Sitemap-uri pentru a verifica acoperirea robots.txt și a sitemap-urilor , apoi compară regula declarată cu o preluare live în stil crawler.
- Folosește revizuirea fișierului pentru a revizui llms.txt și deschide fiecare destinație listată.
- Folosește verificatorul de pagini pentru a inspecta arborele de accesibilitate al unei pagini pentru fiecare șablon critic.
- Folosește verificările de pregătire pentru a verifica pregătirea WebMCP și a verifica pregătirea pentru comerț agentic când acele capacități se aplică.
- Deschide
https://app.amicited.com/audit/web-vitalspentru a verifica Core Web Vitals și a conecta performanța din teren cu testele de cerere în condiții de crawler.
Reguli de decizie
Acestea sunt praguri operaționale de acceptare, nu afirmații despre algoritmii de clasare. Înăsprește-le pentru călătorii critice pentru venituri sau conținut reglementat și înregistrează orice alternativă înainte de testare, astfel încât rezultatul să nu fie ajustat după fapt.
| Verificare | Acceptabil sau promovat | Prag de constatare | Acțiune implicită |
|---|---|---|---|
| Proprietatea politicii | Fiecare crawler relevant are status de permis, blocat sau condiționat, rațiune, aprobator și dată de revizuire | Orice regulă live nu are proprietar sau intenție documentată | Major; escaladează decizia de afaceri în 2 zile lucrătoare |
| Acces declarat versus efectiv | Comportamentul live corespunde politicii aprobate pe fiecare URL critic | Crawler-ul permis primește un 401, 403, 429, 5xx, pagină de provocare sau conținut material diferit | Critic pe URL-uri critice; Major în altă parte |
| Răspuns non-JavaScript | Titlul, H1, conținutul principal, faptele de bază și linkurile de descoperire accesibile cu crawl sunt prezente | Orice element necesar există doar după JavaScript, sau HTML-ul inițial este o carcasă de aplicație goală | Critic pentru conținutul principal; Major pentru conținutul suport |
| Extracție din renderizare | Titlul extras, răspunsul sau oferta, faptele, datele și linkurile principale corespund paginii vizibile | Varianta greșită, text ascuns, zgomot de navigare sau context calificant lipsă schimbă sensul | Critic dacă faptele se schimbă; Major dacă extracția este incompletă |
| Arbore de accesibilitate | Scor AmICited 80–100 și niciun control critic nedenumit sau contur principal al conținutului întrerupt | 50–79 este Major; sub 50 este Critic; orice control de cumpărare, rezervare, autentificare sau lead neutilizabil este Critic indiferent de scor | Repară semantica și retestează șablonul afectat |
| Date structurate | Zero erori de sintaxă; proprietățile materiale corespund conținutului vizibil și înregistrărilor sursă | Orice proprietate obligatorie invalidă sau preț, disponibilitate, dată, identitate, rating sau URL canonic conflictual | Critic pentru fapte înșelătoare/conflictuale; Major pentru acoperire aplicabilă lipsă |
llms.txt | Dacă este prezent: HTTP 200, Markdown lizibil, sumar corect, zero linkuri rupte/private, proprietar numit | Fișierul lipsă este Consultativ; fișier invalid, învechit, redirecționat sau înșelător este Major | Creează sau corectează după blocajele de acces și extracție |
| Calitatea pasajelor | Cel puțin 20 de pasaje eșantionate; toate identifică subiectul și păstrează condițiile, unitățile și răspunsul | Un pasaj ambiguu este Major pentru acea pagină; ambiguitatea repetată la nivel de șablon este Critică pentru tiparul de conținut | Corectează tiparul, apoi re-eșantionează 20 de pasaje |
| Claritatea entității | Fișa de date aprobată corespunde paginilor critice și identității interpretabile de mașină | Nume oficial, URL canonic, proprietate, relație de produs sau referință aceeași-entitate conflictuală | Major; Critic când conflictul schimbă cine oferă oferta sau sfatul |
| Fiabilitatea preluării | 25 de cereri per șablon critic pe cel puțin 2 perioade de test: 100% 2xx valide după redirecționările așteptate, fără pagini de provocare și cel puțin 98% răspunsuri valide în eșantionul larg | Orice eșec pe URL critic, sau eșantionul larg sub 98% răspunsuri valide | Critic pentru URL-uri critice; Major pentru fiabilitatea largă |
| TTFB | Mediană la sau sub 800 ms și percentila 95 la sau sub 1.800 ms în mediul de test | Mediană peste 800 ms este Major; orice timeout repetat sau percentila 95 peste 1.800 ms este Critic pentru URL-urile critice afectate | Diagnostichează CDN, origine, cache, redirecționări sau rutare regională |
| Redirecționări | Zero salturi neașteptate; cel mult un salt intenționat pe același site înainte de un răspuns 200 | Buclă, surpriză cross-domain, redirecționare specifică crawlerului sau două sau mai multe salturi evitabile | Critic pentru buclă sau destinație greșită; Major pentru salturi în exces |
| WebMCP | Instrumentele aplicabile sunt expuse declarativ, descrise corect, cu permisiuni și testate | Detectare doar în JavaScript neverificată; instrument aplicabil lipsă sau acțiune nesigură este o constatare | Major pentru capacitate aplicabilă lipsă; Critic pentru execuție nesigură |
| Comerț agentic | Protocolul aplicabil este publicat, iar fluxul de test păstrează prețul, inventarul, consimțământul, confirmarea și gestionarea erorilor | Capacitatea neacceptată este absentă în mod corect, sau un flux publicat schimbă termenii sau acționează fără confirmare | Neaplicabil este acceptabil; flux nesigur sau înșelător este Critic |
Scorurile nu înlocuiesc niciodată dovezile concrete. Un scor de accesibilitate de 85 nu scuză un buton de finalizare a comenzii neetichetat, iar o permisiune în robots nu depășește o pagină de provocare returnată cererii reale. „Neverificat" este necunoscut, nu un promovat și nu un zero.
Rezultat: registrul constatărilor privind pregătirea agenților
Predă un singur registru de constatări, nu o prezentare și un backlog AI separat. Adaugă fiecare constatare în lista de priorități P2 cu aceste câmpuri:
ID și titlu:
URL-uri/șabloane afectate:
Verificare și condiție observată:
Condiție/prag așteptat:
Dovezi: timestamp, agent de utilizator, status, captură sau referință de jurnal
Consecință de afaceri:
Severitate: Critic | Major | Consultativ
Acțiune recomandată:
Proprietar și aprobator:
Efort și dependență:
Dată limită și dată de retestare:
Decizie de politică, dacă este relevantă:
Impact asupra măsurătorii P5:
Status: Deschis | Risc acceptat | Rezolvat | Verificat
Critic înseamnă că eșecul împiedică accesul fiabil, schimbă material sensul extras sau permite o acțiune nesigură. Major înseamnă că accesul sau înțelegerea sunt degradate, dar un client reprezentativ poate recupera totuși conținutul principal. Consultativ înseamnă o îmbunătățire utilă, dar fără dovezi ale unui eșec prezent. Risc acceptat necesită proprietarul de afaceri numit, rațiunea, domeniul afectat, data de expirare sau revizuire și o modalitate de a detecta condiții schimbate.
Deduplică după cauză principală: o provocare CDN care afectează crawler-e convenționale și AI este un singur element cu multiple înregistrări de dovezi.
Ce poate merge prost
Tratarea fazei ca opțională. Urmărirea prompturilor și rescrierea conținutului nu pot compensa recuperarea eșuată. Fă din P4 o condiție de intrare pentru o valoare de bază interpretabilă.
Blocarea implicit și numirea retroactivă a acesteia drept politică. O regulă fără proprietar de decizie, rațiune sau dată de revizuire este configurație, nu politică. Prezintă compromisul descoperire-versus-control și obține o decizie explicită.
Adăugarea llms.txt și declararea finalizării. Fișierul nu poate suprascrie regulile robots, blocurile CDN, HTML-ul inițial gol, markup-ul înșelător, pasajele slabe sau timeout-urile. Tratează-l ca pe un ghid în cadrul setului mai larg de dovezi.
Testarea doar a unui agent de utilizator prietenos sau a paginii principale. Controalele de margine variază după cale, geografie, rată și identitate. Testează fiecare șablon de mare valoare și agent de utilizator din matricea de politici.
Confundarea aspectului vizual cu extractibilitatea. O pagină lustruită poate expune duplicate ascunse, nume de controale fără sens sau un răspuns gol fără script. Păstrează separat dovezile din sursă, DOM, arbore de accesibilitate și text extras.
Tratarea necunoscutului ca eșec sau succes. Retestează timeout-urile și crawler-ele neverificate; nu transforma niciodată dovezile lipsă într-un scor convenabil.
Instalarea de capacități experimentale pentru agenți fără un caz de utilizare. Protocoalele WebMCP sau de comerț ar trebui să expună acțiuni valoroase, cu permisiuni. A publica o acțiune nesigură sau inexactă este mai rău decât a marca capacitatea ca neaplicabilă.
Predarea către măsurarea valorii de bază
Faza de măsurare a valorii de bază primește lista de priorități integrată, pachetul de dovezi de test, înregistrarea politicii pentru crawler-e, setul de URL-uri reprezentativ și nota de pregătire. Proprietarul P4 trebuie să identifice orice limitare care ar schimba interpretarea: familii de crawler-e blocate, șabloane inaccesibile, regiuni intermitente, pasaje lipsă sau o remediere recentă al cărei efect nu s-a propagat încă.
P5 poate continua când URL-urile critice sunt intenționat accesibile familiilor de crawler-e incluse în măsurare, conținutul primar valid este extractibil și nicio constatare Critică nerezolvată nu ar face un scor zero sau scăzut neinterpretabil. Poate continua cu adnotări când o blocare deliberată exclude un crawler cunoscut sau o problemă Majoră afectează un șablon delimitat. Ar trebui să aștepte când intenția de acces este necunoscută, paginile critice eșuează preluările sau conținutul extras contrazice material sursa vizibilă.
Predarea este completă când proprietarul P5 poate răspunde la trei întrebări fără a redeschide auditul: care agenți erau destinați să aibă acces, care pagini și fapte puteau recupera în mod fiabil și care limitări cunoscute trebuie să apară lângă valoarea de bază.
Întrebări frecvente
Întrebări frecvente
Ar trebui să permitem fiecărui crawler AI?
Este necesar un fișier llms.txt pentru a trece auditul?
Poate un site să treacă verificările SEO tehnice și să eșueze totuși la pregătirea pentru agenți?
WebMCP și comerțul agentic se aplică fiecărei afaceri?
Unde ajung constatările privind pregătirea pentru agenți?
Mai multe tutoriale în această secțiune
Gata să pui în practică?
Verificare gratuită · Perioadă de încercare de 7 zile · fără card de credit