Audit přístupnosti pro AI a připravenosti pro agenty

AI systémy nemohou citovat, doporučovat ani pracovat s obsahem, který nedokážou spolehlivě získat. Tato fáze testuje tento základ, než tým změří viditelnost nebo zadá obsah určený pro odpovídací stroje.

Fáze: P4, Fáze A — Porozumění. Časový rámec: 3–5 pracovních dnů pro typický marketingový web; 5–10 pro velký e-commerce, tržiště nebo aplikaci silně závislou na klientském vykreslování. Vlastník: odpovídá technický SEO specialista, přičemž engineering provádí testy načítání a vykreslování, vedoucí obsahu kontroluje extrahovatelnost a obchodní nebo právní vlastník rozhoduje o politice crawlerů.

Proč tato fáze přichází právě sem

Běžný technický audit zjišťuje, zda vyhledávače mohou web prolézat, vykreslovat, indexovat a řadit. Tato fáze se ptá, zda AI crawleři, systémy pro získávání informací a úkolově orientovaní agenti mohou dosáhnout a interpretovat stejné užitečné informace. Mohou používat různé uživatelské agenty, cesty načítání, schopnosti vykreslování, časové limity a metody extrakce. Indexovatelná stránka může AI klientovi stále vrátit prázdnou skořápku, souhlasovou stěnu, bot výzvu nebo nesouvislé fragmenty.

Audit přístupnosti pro AI proto patří vedle auditu technického základu , nikoli na konec produkce obsahu. Klientské vykreslování znamená, že JavaScript vytváří důležitý obsah až po doručení počátečního HTML. Systémy pro získávání informací tento kód nemusí spustit, mohou se zastavit před jeho dokončením nebo mohou extrahovat pouze počáteční odpověď. Pokud název produktu, odpověď, cena, dostupnost nebo důkaz existují až po spuštění JavaScriptu, pozdější optimalizace obsahu nemůže selhání přístupu napravit.

Tato fáze spotřebovává ověřené účty, analýzy, logy crawlerů, zdroje sitemap, sadu kritických URL a mapu vlastnictví z fáze přístupu, sledování a zdrojů dat . Pokud by se provedla dříve, tým by nedokázal rozlišit skutečnou nepřítomnost od chybějícího přístupu. Pokud by se provedla až po měření výchozího stavu, kontaminovala by výchozí stav: nulové citace mohou odrážet nepřístupný web, nikoli slabý obsah nebo poptávku.

Přeskočení této fáze plýtvá prací: autoři vylepšují pasáže, které crawler nikdy neobdrží, vývojáři přidávají schéma za ověřovací bránu nebo si tým plete platný llms.txt s celkovou připraveností webu. Přístup, extrakce, porozumění a akce jsou samostatné schopnosti.

Vstupy a výstupy

Vstupy činí testy reprodukovatelnými. Výstupy tvoří kontrakt s P5: měření začíná až poté, co jsou známá selhání přístupu opravena nebo explicitně akceptována.

Kontrolní seznam

Testujte reprezentativní sadu URL, nejen domovskou stránku, a uchovávejte reprodukovatelné důkazy.

1. Rozhodněte o přístupu crawlerů vědomě

Co dělat: inventarizujte pravidla pro AI crawleery v robots.txt , ovládacích prvcích botů na CDN, webových aplikačních firewallech, souhlasových vrstvách a konfiguraci původního serveru. Proč to záleží: povolení v robots je pouze preference; okrajová služba může požadavek stále zablokovat, zatímco neúmyslné blokování zástupným znakem není politika. Jak to udělat: porovnejte živá pravidla s maticí politik, načtěte reprezentativní URL s příslušnými uživatelskými agenty a zaznamenejte kompromis. Nástroj: AmICited Robots.txt & Sitemaps, schválený klient pro požadavky a logy CDN/původního serveru. Hotovo, když: každá rodina crawlerů má schválené povolení, blokování nebo podmíněné rozhodnutí a živé chování mu odpovídá.

2. Porovnejte odpověď bez JavaScriptu s užitečnou stránkou

Co dělat: porovnejte počáteční HTML s normální stránkou v prohlížeči. Proč to záleží: klient pro získávání informací nemusí spouštět skripty, které vkládají odpovědi, nabídky, odkazy nebo data produktů. Jak to udělat: otestujte každou důležitou šablonu před hydratací, tedy procesem, který připojuje aplikační chování k serverovému HTML. Nástroj: prohlížeč bez skriptů nebo HTTP klient plus vykreslená stránka. Hotovo, když: počáteční odpověď obsahuje titulek, H1, primární obsah, základní fakta a objevitelné odkazy; jakákoli výjimka má důkazy a vlastníka.

3. Otestujte extrahovatelnost vykresleného DOM

Co dělat: extrahujte hlavní obsah z vykresleného Document Object Model (DOM), strukturované reprezentace stránky v prohlížeči, bez navigace, textu souhlasu nebo skrytých variant. Proč to záleží: přijímat text není totéž jako identifikovat správný text; šum ze šablony může znehodnotit získávání informací. Jak to udělat: porovnejte extrahovaný titulek, odpověď, vydavatele, data, fakta a odkazy s viditelným zdrojem napříč dlouhými, řídkými a komerčními stránkami. Nástroj: kontrola prohlížeče, extrakce textu a zdroj stránky. Hotovo, když: záznam uchovává primární význam a fakta bez vizuální pozice nebo nedokumentovaných selektorů.

4. Prozkoumejte strom přístupnosti

Co dělat: zkontrolujte strom přístupnosti: role, názvy, stavy, nadpisy, orientační body a ovládací prvky. Proč to záleží: sémantika odlišuje nadpisy od dekorace, tlačítka od ikon a primární obsah od navigace. Jak to udělat: otestujte kritické šablony na jeden H1, seřazené nadpisy, pojmenované ovládací prvky, orientační body, popisné odkazy a smysluplné alternativy obrázků. Nástroj: kontrola stromu přístupnosti v AmICited a kontrola v prohlížeči. Hotovo, když: skóre splňuje práh, žádný kritický ovládací prvek nemá chybějící název a hlavní oblast a další akce jsou identifikovatelné.

5. Ověřte pokrytí a pravdivost strukturovaných dat

Co dělat: porovnejte viditelná fakta se strukturovanými daty , standardizovaným kódem jako Schema.org JSON-LD. Proč to záleží: kód objasňuje entity, nabídky, autorství a data, ale nepřesný kód sděluje špatná fakta. Jak to udělat: ověřte použitelná schémata a porovnejte názvy, URL, ceny, měny, dostupnost, data, hodnocení a identifikátory se zdrojovými systémy. Nástroj: validátor, vykreslené HTML a zdrojové záznamy. Hotovo, když: kritické šablony mají platné použitelné kódy, hodnoty odpovídají viditelným faktům a každé závažné upozornění je vyřešeno nebo vysvětleno.

6. Zkontrolujte llms.txt jako průvodce, ne bránu

Co dělat: zkontrolujte, zda /llms.txt přesně shrnuje organizaci a odkazuje na kanonické veřejné zdroje. Jde o navrhovaného prostého textového průvodce, nikoli kontrolu přístupu nebo zaručený signál pro řazení. Proč to záleží: stručná mapa snižuje nejednoznačnost; zastaralá mapa zavádí agenty. Jak to udělat: ověřte status, strukturu Markdown, popis, cíle, kanonické URL a vlastníka. Nástroj: kontrola llms.txt v AmICited a přímé načtení. Hotovo, když: soubor, pokud je používán, nemá nefunkční/soukromé odkazy a má vlastníka údržby; absence je zjištění ke zlepšení, nikoli důkaz neviditelnosti.

7. Vzorkujte samostatně stojící pasáže

Co dělat: zkontrolujte nezávisle získané definice, odpovědi, fakta, srovnání, kroky a omezení. Proč to záleží: získávání informací může oddělit odstavec od jeho nadpisu; „funguje jim to lépe" pak ztratí svůj předmět i srovnání. Jak to udělat: přečtěte alespoň 20 pasáží bez jejich nadpisu nebo předchozího odstavce. Nástroj: výstup extrakce a redakční kontrola. Hotovo, když: každá pasáž uvádí svůj předmět, odpovídá na identifikovatelnou otázku, zachovává podmínky nebo jednotky a vyhýbá se nevyřešeným odkazům.

8. Potvrďte jasnost kanonické entity

Co dělat: ověřte, že web uvádí, kdo organizace je, co nabízí a jak souvisí její značky, produkty, lidé, místa a profily. Kanonická entita je primární reálná věc, na kterou název odkazuje. Proč to záleží: nekonzistentní názvy, stará loga, rozporné popisy a nepropojené URL profilů usnadňují sloučení dvou entit nebo rozdělení jedné entity na několik. Jak to udělat: porovnejte domovskou stránku, stránku O nás, kontaktní údaje, strukturovaná data, sociální profily, autorské stránky, právní název a důležité profily třetích stran. Nástroj: faktový list entity, vykreslené stránky a výstup strukturovaných dat. Hotovo, když: jeden schválený faktový list řeší oficiální název, aliasy, kanonickou URL, logo, popis, vlastnictví, primární nabídky a profily stejné entity, přičemž rozpory jsou zaznamenány k opravě.

9. Otestujte dobu odezvy a spolehlivost načítání

Co dělat: měřte status, Time to First Byte (TTFB), přesměrování, časové limity a konzistenci odezvy při normálních a relevantních uživatelských agentech crawlerů. TTFB je interval od začátku požadavku do příchodu prvního bajtu odpovědi. Proč to záleží: občasné 403, 429, 5xx odpovědi, dlouhé řetězce přesměrování nebo pomalé zdroje činí obsah nespolehlivým, i když jediná návštěva prohlížeče uspěje. Jak to udělat: spusťte opakovatelný vzorek definovaný v tabulce prahů z více než jednoho síťového umístění, pokud geografie záleží, poté slučte selhání s logy a Core Web Vitals. Nástroj: monitor požadavků, logy CDN/původního serveru a AmICited Web Vitals. Hotovo, když: kritické URL splňují prahy spolehlivosti a latence nebo mají závažnost, příčinu, vlastníka a datum přetestování.

10. Vyhodnoťte WebMCP a obchodní protokoly tam, kde vytvářejí hodnotu

Co dělat: testujte WebMCP a obchodní připravenost pouze tam, kde obchodní model podporuje akce agentů. WebMCP je vznikající způsob, jak web vystavuje volatelné nástroje, jako je vyhledávání, rezervace nebo přidání položky do košíku. Agentický obchod zahrnuje objevování produktů a transakce s asistencí agentů, včetně protokolů jako ACP nebo UCP. Proč to záleží: čitelný obsah podporuje odpovědi; explicitní nástroje a obchodní data podporují spolehlivou akci bez screen scrapingu. Jak to udělat: namapujte hodnotné uživatelské úkoly, prohlédněte deklarované nástroje nebo protokoly, ověřte popisy vstupů a výstupů a zkontrolujte chování při potvrzení, autentizaci, oprávnění, ceně, inventáři a chybách. Nástroj: kontroly WebMCP a Agentického obchodu v AmICited plus řízené testovací prostředí. Hotovo, když: použitelné schopnosti jsou detekovány a bezpečně testovatelné, nebo je kontrola označena jako nepoužitelná se schváleným důvodem obchodního modelu a spouštěčem revize.

Nástroje v AmICited

Otevřete https://app.amicited.com/accessibility pro konsolidovaný audit a vysvětlení funkce Přístupnost pro AI a připravenost pro agenty . Produkt vykazuje nezávislá měření, místo aby schovával různé typy selhání do jediného smíšeného skóre.

1. Pomocí souhrnu zkontrolujte skóre přístupnosti pro agenty a zaznamenejte každou komponentu, nejen stav titulku.
2. Pomocí Robots.txt a Sitemap zkontrolujte pokrytí robots.txt a sitemap , poté porovnejte uvedené pravidlo s živým načtením stylem crawleru.
3. Pomocí kontroly souboru zkontrolujte llms.txt a otevřete každý uvedený cíl.
4. Pomocí kontroly stránky prozkoumejte strom přístupnosti stránky pro každou kritickou šablonu.
5. Pomocí kontrol připravenosti zkontrolujte připravenost WebMCP a zkontrolujte připravenost agentického obchodu tam, kde tyto schopnosti platí.
6. Otevřete https://app.amicited.com/audit/web-vitals pro kontrolu Core Web Vitals a propojte výkon v terénu s testy požadavků za podmínek crawleru.

Rozhodovací pravidla

Toto jsou provozní akceptační prahy, nikoli tvrzení o řadicích algoritmech. Zpřísněte je pro revenue-kritické cesty nebo regulovaný obsah a zaznamenejte jakoukoli alternativu před testováním, aby výsledek nebyl upravován dodatečně.

Skóre nikdy nepřebíjí konkrétní důkazy. Skóre přístupnosti 85 neomlouvá neoznačené tlačítko pokladny a povolení v robots nepřeváží ověřovací stránku vrácenou skutečnému požadavku. „Nekontrolováno" je neznámé, nikoli prošlé ani nulové.

Výstup: registr zjištění o připravenosti pro agenty

Předejte jeden registr zjištění, nikoli prezentaci a samostatný AI backlog. Přidejte každé zjištění do seznamu priorit z P2 s těmito poli:

ID a název:
Dotčené URL/šablony:
Kontrola a pozorovaný stav:
Očekávaný stav/práh:
Důkazy: časové razítko, uživatelský agent, status, odkaz na snímek nebo log
Obchodní důsledek:
Závažnost: Kritické | Závažné | Poradenské
Doporučená akce:
Vlastník a schvalovatel:
Úsilí a závislost:
Termín a datum přetestování:
Rozhodnutí o politice, pokud relevantní:
Dopad na měření v P5:
Status: Otevřeno | Akceptované riziko | Opraveno | Ověřeno

Kritické znamená, že selhání brání spolehlivému přístupu, materiálně mění extrahovaný význam nebo umožňuje nebezpečnou akci. Závažné znamená, že přístup nebo porozumění je degradováno, ale reprezentativní klient může stále získat hlavní obsah. Poradenské znamená užitečné zlepšení bez důkazu aktuálního selhání. Akceptované riziko vyžaduje jmenovaného vlastníka firmy, odůvodnění, dotčený rozsah, datum vypršení nebo revize a způsob detekce změněných podmínek.

Deduplikujte podle hlavní příčiny: jedna CDN výzva postihující běžné i AI crawleery je jedna položka s více záznamy důkazů.

Co se pokazí

Považování fáze za volitelnou. Sledování promptů a přepisování obsahu nemůže nahradit selhání získávání informací. Udělejte P4 vstupní podmínkou pro interpretovatelný výchozí stav.

Blokování ve výchozím nastavení a následné nazývání toho politikou. Pravidlo bez vlastníka rozhodnutí, odůvodnění nebo data revize je konfigurace, nikoli politika. Představte kompromis mezi objevováním a kontrolou a získejte explicitní rozhodnutí.

Přidání llms.txt a prohlášení hotovo. Tento soubor nemůže přepsat pravidla robots, bloky CDN, prázdné počáteční HTML, zavádějící kód, slabé pasáže nebo časové limity. Považujte ho za jednoho průvodce v rámci širší sady důkazů.

Testování pouze přátelského uživatelského agenta nebo domovské stránky. Okrajové kontroly se liší podle cesty, geografie, rychlosti a identity. Testujte každou vysoce hodnotnou šablonu a uživatelského agenta v matici politik.

Záměna vzhledu za extrahovatelnost. Upravená stránka může skrývat skryté duplicity, nesmyslné názvy ovládacích prvků nebo prázdnou odpověď bez skriptů. Uchovávejte důkazy zdroje, DOM, stromu přístupnosti a extrahovaného textu samostatně.

Považování neznámého za selhání nebo úspěch. Znovu testujte časové limity a nekontrolované crawleery; nikdy nepřevádějte chybějící důkazy na pohodlné skóre.

Instalace experimentálních schopností agentů bez případu užití. WebMCP nebo obchodní protokoly by měly vystavovat hodnotné, oprávněné akce. Nasazení nebezpečné nebo nepřesné akce je horší než označení schopnosti jako nepoužitelné.

Předání k měření výchozího stavu

Fáze měření výchozího stavu obdrží sloučený seznam priorit, balíček důkazů z testů, záznam politiky crawlerů, reprezentativní sadu URL a poznámku o připravenosti. Vlastník P4 musí identifikovat jakékoli omezení, které mění interpretaci: blokované rodiny crawlerů, nepřístupné šablony, přerušované regiony, chybějící pasáže nebo nedávnou opravu, jejíž účinek se ještě neprojevil.

P5 může pokračovat, když jsou kritické URL záměrně přístupné rodinám crawlerů zahrnutým do měření, platný primární obsah je extrahovatelný a žádné nevyřešené Kritické zjištění by činilo nulové nebo nízké skóre neinterpretovatelným. Může pokračovat s anotacemi, když vědomé blokování vylučuje známého crawlera nebo Závažný problém ovlivňuje ohraničenou šablonu. Mělo by počkat, když záměr přístupu není znám, kritické stránky selhávají v načítání nebo extrahovaný obsah materiálně odporuje viditelnému zdroji.

Předání je kompletní, když vlastník P5 může odpovědět na tři otázky bez znovuotevření auditu: kteří agenti měli mít přístup, které stránky a fakta mohli spolehlivě získat a která známá omezení musí být uvedena vedle výchozího stavu.

FAQ

Často kladené otázky