Jak AI agenti vidí vaše webové stránky (a jak je pro ně navrhovat)?

Každá hlavní AI platforma dnes dokáže autonomně procházet webové stránky. Automatické prohlížení v Chromu umí scrollovat a klikat. ChatGPT Atlas vyplňuje formuláře a dokončuje nákupy. Perplexity Comet provádí výzkum napříč kartami. Ale žádný z těchto agentů nevidí váš web tak, jak ho vidí člověk.

Základní poznatek je tento: nejdůležitější věc, kterou můžete udělat pro kompatibilitu s AI agenty, je stejná práce, kterou zastánci webové přístupnosti prosazují už desítky let. Strom přístupnosti (accessibility tree), původně vytvořený pro čtečky obrazovky, se stává hlavním rozhraním mezi AI agenty a vašimi webovými stránkami.

Podle zprávy Imperva Bad Bot Report 2025 (Imperva je kyberbezpečnostní společnost) automatizovaný provoz poprvé v roce 2024 překonal lidský provoz a tvořil 51 % všech interakcí na webu. Ne vše z toho je agentní procházení webu, ale směr je jasný: nelidské publikum vašich webových stránek je už dnes větší než lidské – a stále roste. V celém tomto článku čerpáme výhradně z oficiální dokumentace, recenzovaného výzkumu a oznámení společností, které tuto infrastrukturu budují.

Tři způsoby, jak agenti „vidí“ váš web
Když člověk navštíví vaše webové stránky, vnímá barvy, rozvržení, obrázky a typografii. Když web navštíví AI agent, vidí něco úplně jiného. Pochopení toho, co agenti skutečně vnímají, je základem pro tvorbu webů, které pro ně fungují.

Hlavní AI platformy používají tři odlišné přístupy a rozdíly mezi nimi mají přímé dopady na to, jak byste měli strukturovat svůj web.

Vize: čtení screenshotů

Anthropicův Computer Use používá nejdoslovnější přístup. Claude pořizuje screenshoty prohlížeče, analyzuje vizuální obsah a rozhoduje, na co kliknout nebo co napsat na základě toho, co „vidí“. Jde o nepřetržitou zpětnovazební smyčku: screenshot, uvažování, akce, screenshot. Agent pracuje na úrovni pixelů, identifikuje tlačítka podle jejich vizuální podoby a čte text z vykresleného obrazu.

Project Mariner následuje podobný model s tím, co Google popisuje jako smyčku „pozoruj-plánuj-jednej“: pozorování zachycuje vizuální prvky a základní strukturu kódu, plán vytváří sekvence akcí a akce simulují interakce uživatele. Mariner dosáhl v benchmarku WebVoyager úspěšnosti 83,5 %.

Přístup založený na vizi funguje, ale je výpočetně náročný, citlivý na změny rozvržení a omezený tím, co je vizuálně vykresleno na obrazovce.

Strom přístupnosti: čtení struktury

OpenAI zvolilo u ChatGPT Atlas jinou cestu. Jejich FAQ pro vydavatele a vývojáře to uvádí jasně:

ChatGPT Atlas používá ARIA tagy, tedy stejné popisky a role, které podporují čtečky obrazovky, k interpretaci struktury stránky a interaktivních prvků.

Atlas je postaven na Chromiu, ale místo analýzy vykreslených pixelů se dotazuje stromu přístupnosti (accessibility tree) na prvky s konkrétními rolemi („button“, „link“) a přístupnými názvy. Jde o stejnou datovou strukturu, kterou používají čtečky obrazovky jako VoiceOver a NVDA, aby pomohly lidem se zrakovým postižením orientovat se na webu.

Microsoft Playwright MCP, oficiální MCP server pro automatizaci prohlížeče, používá stejný přístup. Poskytuje „snímky“ přístupnosti namísto screenshotů, čímž AI modelům dává strukturovanou reprezentaci stránky. Microsoft u svého standardu pro automatizaci prohlížeče záměrně zvolil data z přístupnosti místo vizuálního vykreslování.

Hybridní přístup: obojí zároveň

V praxi nejpokročilejší agenti kombinují oba přístupy. Jak Computer-Using Agent (CUA) od OpenAI, který pohání jak Operator, tak Atlas spojují analýzu screenshotů se zpracováním DOM a parsováním stromu přístupnosti. Upřednostňují ARIA štítky a role a v případě, že data přístupnosti nejsou k dispozici, přecházejí na textový obsah a strukturální selektory.

Výzkum Perplexity potvrzuje stejný vzorec. Jejich článek BrowseSafe, který popisuje bezpečnostní infrastrukturu za prohlížečovým agentem Comet, uvádí použití „hybridní správy kontextu kombinující snímky stromu přístupnosti se selektivním viděním“.

Dokonce i platformy, které začaly s přístupem založeným primárně na vizi, začleňují data z přístupnosti. A platformy, které optimalizují spolehlivost a efektivitu (Atlas, Playwright MCP), staví na stromu přístupnosti jako na základním přístupu.

Strom přístupnosti vašeho webu není jen artefakt souladu s předpisy. Stále častěji jde o hlavní rozhraní, které agenti používají k pochopení a interakci s vaším webem.

Minulý rok, před tím než vstoupil v platnost Evropský zákon o přístupnosti (European Accessibility Act), specialisté říkali, že by bylo ironické, kdyby věc, která nakonec přiměje lidi brát přístupnost vážně, nebyli lidé, pro které byla navržena, ale AI agenti. Už to ale není vtip.

Strom přístupnosti je vaše rozhraní pro agenty

Strom přístupnosti je zjednodušená reprezentace DOM vašeho webu, kterou prohlížeče vytvářejí pro asistivní technologie. Zatímco plný DOM obsahuje každý div, span, styl a skript, strom přístupnosti odstraňuje šum a zpřístupňuje jen to podstatné: interaktivní prvky, jejich role, názvy a stavy.

Proto to pro agenty funguje tak dobře. Typický DOM stránky může obsahovat tisíce uzlů. Strom přístupnosti jej zredukuje na prvky, se kterými může uživatel (nebo agent) skutečně interagovat: tlačítka, odkazy, formulářová pole, nadpisy a orientační oblasti (landmarks). Pro AI modely, které zpracovávají webové stránky v omezeném kontextovém okně, je tato redukce zásadní.

FAQ pro vydavatele a vývojáře od OpenAI to uvádí velmi jasně:

Dodržujte osvědčené postupy WAI-ARIA tím, že přidáte popisné role, popisky a stavy k interaktivním prvkům, jako jsou tlačítka, menu a formuláře. To pomáhá ChatGPT rozpoznat, co jednotlivé prvky dělají, a přesněji s vaším webem pracovat.

A zpřístupnění vašeho webu pomáhá ChatGPT Agentovi v Atlasu lépe mu porozumět.

Tento závěr podporují i výzkumná data. Nejpřesvědčivější důkazy v tomto směru pocházejí ze studie UC Berkeley a University of Michigan publikované pro CHI 2026, přední akademickou konferenci v oblasti interakce člověka s počítačem. Výzkumníci testovali Claude Sonnet 4.5 na 60 reálných webových úlohách v různých podmínkách přístupnosti a shromáždili 40,4 hodiny interakčních dat napříč 158 325 událostmi. 

Výsledky byly překvapivé:

Za standardních podmínek dosáhl agent úspěšnosti téměř 80 %. Při omezení na ovládání pouze klávesnicí (simulující způsob, jakým se pohybují uživatelé čteček obrazovky) klesá úspěšnost na 42 % a dokončení úloh trvá dvojnásobnou dobu. Při omezení viewportu (simulace nástrojů pro zvětšení obsahu) klesá úspěšnost na 28 % a doba řešení se více než ztrojnásobí.

Studie identifikuje tři kategorie nedostatků:

Percepční mezery: agenti nemají spolehlivý přístup k oznámením čteček obrazovky nebo změnám stavu ARIA, které by jim řekly, co se stalo po provedení akce.
Kognitivní mezery: agenti mají problém sledovat stav úlohy napříč více kroky.
Akční mezery: agenti nedostatečně využívají klávesové zkratky a selhávají při interakcích, jako je například drag-and-drop.

Implikace je přímá. Weby, které poskytují bohatý a dobře označený strom přístupnosti, dávají agentům informace, které potřebují k úspěchu. Weby, které spoléhají na vizuální vodítka, stavy při najetí myší (hover) nebo složité JavaScriptové interakce bez přístupných alternativ, vytvářejí podmínky pro selhání agentů.

Architektonický dokument Perplexity k jejich vyhledávacímu API ze září 2025 tento závěr potvrzuje z pohledu obsahu. Jejich indexační systém upřednostňuje obsah, který je „vysoce kvalitní jak po stránce obsahu, tak formy, přičemž informace jsou zachyceny způsobem, který zachovává původní strukturu a rozložení obsahu“. Weby „bohaté na dobře strukturovaná data ve formě seznamů nebo tabulek“ těží z „vícepravidlového (formulovaného) parsování a extrakce“. Struktura není jen užitečná. Je to to, co umožňuje spolehlivé parsování.

Sémantické HTML: základ pro agenty

Strom přístupnosti je vytvářen z vašeho HTML. Používejte sémantické prvky a prohlížeč automaticky vytvoří užitečný strom přístupnosti. Pokud je vynecháte, strom bude neúplný nebo zavádějící.

Tohle není nová rada. Zastánci webových standardů už dvě desetiletí zdůrazňují „používejte sémantické HTML“. Ne všichni je poslouchali. Nové je to, že se rozšířilo publikum. Dříve šlo o čtečky obrazovky a relativně malé procento uživatelů. Dnes jde o každého AI agenta, který navštíví váš web.

Používejte nativní prvky. Element <button> se automaticky objeví ve stromu přístupnosti s rolí „button“ a svým textovým obsahem jako přístupným názvem. Naproti tomu <div onclick="doSomething()"> ne. Agent neví, že je klikací.

HTML: 

<!-- Agent dokáže tento prvek identifikovat a interagovat s ním -->
<button type="submit">Hledat lety</button>

<!-- Agent nemusí rozpoznat tento prvek jako interaktivní -->
<div class="btn btn-primary" onclick="searchFlights()">Hledat lety</div>

Označujte svá formulářová pole. Každý vstup musí mít přiřazený popisek (label). Agenti čtou popisky, aby pochopili, jaký typ dat se v poli očekává.

HTML: 

<!-- Agent ví, že jde o pole pro e-mail -->
<label for="email">E-mailová adresa</label>
<input type="email" id="email" name="email" autocomplete="email">

<!-- Agent vidí neoznačené textové pole -->
<input type="text" placeholder="Zadejte e-mail...">

Atribut autocomplete si zaslouží pozornost. Říká agentům (i prohlížečům) přesně, jaký typ dat se v poli očekává, pomocí standardizovaných hodnot jako name, email, tel, street-address a organization. Když agent vyplňuje formulář jménem uživatele, atributy autocomplete rozhodují mezi jistým přiřazením polí a hádáním.

Vytvářejte hierarchii nadpisů. Používejte H1 až H6 v logickém pořadí. Agenti používají nadpisy k pochopení struktury stránky a k vyhledávání konkrétních sekcí obsahu. Přeskakování úrovní (například skok z H1 na H4) způsobuje zmatek v tom, jak spolu jednotlivé části obsahu souvisejí.

Používejte orientační (landmark) oblasti. HTML5 prvky pro orientaci v rozvržení stránky (<nav>, <main>, <aside>, <footer>, <header>) říkají agentům, kde se na stránce nacházejí. Element <nav> je jednoznačně navigace. Naproti tomu <div class="nav-wrapper"> vyžaduje interpretaci. Vždy vyhrává srozumitelnost.

HTML: 

<nav aria-label="Hlavní navigace">

 <ul>

   <li><a href="/products">Produkty</a></li>

   <li><a href="/pricing">Ceník</a></li>

 </ul>

</nav>

<main>

 <article>

   <h1>Vyhledávání letů</h1>

   <!-- Hlavní obsah -->

 </article>

</main>

Testovací agenti Microsoftu pro Playwright, představení v říjnu 2025, ve výchozím nastavení generují testovací kód, který používá přístupné selektory. Když AI generuje Playwright test, napíše například:

Javascript: 

const todoInput = page.getByRole('textbox', { name: 'Co je potřeba udělat?' });

Ne CSS selektory. Ne XPath. Přístupné role a názvy. Microsoft postavil své nástroje pro AI testování tak, aby nacházely prvky stejným způsobem jako čtečky obrazovky, protože je to spolehlivější.

ARIA: užitečné, ne magické

Začněte se sémantickým HTML. Používejte <button>, <nav>, <label>, <select> a další nativní prvky. Ty fungují správně automaticky.

Přidejte ARIA tam, kde nativní HTML nestačí. Vlastní komponenty, které nemají ekvivalent v HTML (záložkové panely, stromové pohledy, rozbalovací prvky), potřebují ARIA role a stavy, aby jim bylo možné porozumět.

Používejte ARIA stavy pro dynamický obsah. Když JavaScript mění stránku, atributy ARIA komunikují, co se stalo:

První pravidlo ARIA, jak ho definuje W3C:

Pokud můžete použít nativní HTML prvek nebo atribut, který už má požadovanou sémantiku a chování zabudované, místo přetváření jiného prvku a přidávání ARIA role, stavu nebo vlastnosti kvůli přístupnosti, udělejte to.

Skutečnost, že W3C muselo udělat z „nepoužívejte ARIA“ první pravidlo ARIA, vypovídá vše o tom, jak často se zneužívá.

Adrian Roselli, uznávaný expert na přístupnost webu, vznesl důležitou obavu ve své analýze doporučení OpenAI z října 2025. Tvrdí, že doporučování ARIA bez dostatečného kontextu může podporovat její nesprávné použití. Weby, které ARIA používají, jsou podle každoročního průzkumu WebAIM mezi milionem nejnavštěvovanějších webů obecně méně přístupné, protože ARIA se často aplikuje chybně jako „náplast“ na špatnou HTML strukturu. Roselli varuje, že doporučení OpenAI by mohla podpořit praktiky jako „keyword stuffing“ v atributech aria-label, podobně jako dříve u meta keywords v raném SEO.

Správný přístup je vrstvený:

HTML: 

<!-- Říká agentům, zda je menu otevřené, nebo zavřené -->
<button aria-expanded="false" aria-controls="menu-panel">Menu</button>
<div id="menu-panel" aria-hidden="true">
<!-- Obsah menu -->
</div>

Udržujte aria-label popisný a pravdivý. Používejte ho k doplnění kontextu, který není na obrazovce viditelný, například k rozlišení mezi více tlačítky „Smazat“ na stejné stránce. Nezahlcujte ho klíčovými slovy.

Princip je stejný jako u dobrého SEO: nejdřív tvořit pro uživatele, až potom optimalizovat pro systém. Sémantické HTML znamená tvorbu pro uživatele. ARIA je jemné doladění pro okrajové případy, kdy HTML nestačí.

Otázka vykreslování (renderingu)

Agenti založení na prohlížeči, jako Chrome auto browse, ChatGPT Atlas a Perplexity Comet, běží na Chromiu. Spouštějí JavaScript. Dokážou vykreslit vaši single-page aplikaci.

Ale ne všechno, co navštíví váš web, je plnohodnotný prohlížečový agent.

AI crawlery (PerplexityBot, OAI-SearchBot, ClaudeBot) indexují váš obsah pro vyhledávání a citace. Mnohé z těchto crawlerů nespouštějí klientský JavaScript. Pokud je vaše stránka jen prázdné <div id="root"></div>, dokud se React nenačte, tyto crawlery uvidí prázdnou stránku. Váš obsah je pro AI vyhledávací ekosystém neviditelný.

Pokud váš obsah není v počátečním HTML, není v indexu. Pokud není v indexu, nebude citován. Server-side rendering není jen optimalizace výkonu. Je to požadavek na viditelnost.

I u plnohodnotných prohlížečových agentů vytvářejí weby silně závislé na JavaScriptu třecí plochu. Dynamický obsah, který se načítá až po interakcích, nekonečný scroll, který nikdy neoznámí dokončení, a formuláře, které se po každém vstupu znovu rekonstruují, to vše vytváří příležitosti, aby agenti ztratili přehled o stavu. Výzkum A11y-CUA přisuzoval část selhání agentů „kognitivním mezerám“: agenti ztrácejí přehled o tom, co se děje během složitých vícekrokových interakcí. Jednodušší a předvídatelnější renderování tato selhání snižuje.

Doporučení Microsoftu se zde uplatňuje přímo: „Neskrývejte důležité odpovědi v záložkách nebo rozbalovacích menu: AI systémy nemusí vykreslit skrytý obsah, takže klíčové informace mohou být přeskočeny.“ Pokud je informace důležitá, dejte ji do viditelného HTML. Nevyžadujte interakci k jejímu zobrazení.

Praktické priority vykreslování:

• Vykreslujte obsah server-side nebo ho předrenderujte. Pokud ho AI crawler nevidí, v ekosystému AI neexistuje. 
• Vyhněte se „prázdným shell“ SPA pro obsahové stránky. Frameworky jako Next.js (který pohání tento web), Nuxt a Astro usnadňují SSR. 

Testování vašeho agentního rozhraní

Web byste nepublikovali bez testování v prohlížeči. Stejně důležité se stává testování toho, jak agenti váš web vnímají.

Testování pomocí čteček obrazovky je nejlepší aproximace. Pokud VoiceOver (macOS), NVDA (Windows) nebo TalkBack (Android) dokážou úspěšně procházet váš web, identifikovat tlačítka, číst popisky formulářů a sledovat strukturu obsahu, pak to pravděpodobně zvládnou i agenti. Obě skupiny spoléhají na stejný strom přístupnosti. Není to dokonalá náhrada (agenti mají schopnosti, které čtečky nemají, a naopak), ale odhalí většinu problémů.

Microsoft Playwright MCP poskytuje přímé snímky přístupnosti. Pokud chcete vidět přesně to, co vidí AI agent, Playwright MCP generuje strukturované snímky přístupnosti jakékoli stránky. Tyto snímky odstraňují vizuální vrstvu a ukazují role, názvy a stavy, se kterými agenti pracují. Balíček je publikovaný jako @playwright/mcp na npm a jde o nejpřímější způsob, jak se podívat na web očima agenta.

Výstup vypadá přibližně takto (zjednodušeně):

Neskrývejte klíčové informace za interakce. Ceny, specifikace, dostupnost a důležité detaily by měly být v počátečním HTML, ne za akordeony nebo záložkami.

Používejte standardní odkazy <a href> pro navigaci. Klientské routování, které neaktualizuje URL nebo používá onClick handlery místo skutečných odkazů, narušuje navigaci agentů.

[nadpis úrovně=1] Vyhledávání letů

[navigace "Hlavní navigace"]

 [odkaz] Produkty

 [odkaz] Ceník

[hlavní obsah]

 [textbox "Odletové letiště"] value=""

 [textbox "Příletové letiště"] value=""

 [tlačítko] Hledat lety

Pokud se vaše kritické interaktivní prvky v tomto „snímku“ neobjeví, nebo se objeví bez užitečných názvů, agenti budou mít s vaším webem potíže.

Stagehand od Browserbase (verze 3, vydaná v říjnu 2025 a skromně popisovaná jako „nejlepší framework pro automatizaci prohlížeče“) nabízí další perspektivu. Parsuje jak DOM, tak stromy přístupnosti a jeho mechanismus samoléčícího provádění (self-healing execution) se v reálném čase přizpůsobuje změnám DOMu. Je to užitečné pro testování, zda agenti dokážou na vašem webu dokončit konkrétní workflow, například vyplnění formuláře nebo dokončení nákupu.

Prohlížeč Lynx je nízkotechnologická možnost, kterou se vyplatí vyzkoušet. Jde o textový prohlížeč, který odstraňuje veškeré vizuální vykreslování a ukazuje zhruba to, co parsuje nevizuální agent. 

Spusťte VoiceOver nebo NVDA a projděte klíčové uživatelské cesty na svém webu. Dokážete dokončit základní úkoly bez vidění? Vygenerujte Playwright MCP snímky přístupnosti pro kritické stránky. Jsou interaktivní prvky označené a jednoznačně identifikovatelné? Podívejte se na zdrojový kód stránky. Je hlavní obsah v HTML, nebo vyžaduje JavaScript k vykreslení?

 Načtěte stránku v Lynxu nebo vypněte CSS a zkontrolujte, zda pořadí a hierarchie obsahu stále dávají smysl. Agenti nevidí vaše rozvržení.

Kontrolní seznam pro váš vývojový tým

Pokud tento článek sdílíte se svými vývojáři (a že byste měli), zde je prioritizovaný seznam implementačních kroků. Seřazený podle dopadu a náročnosti, začínající změnami, které ovlivní nejvíce interakcí s agenty při nejmenší práci.

Vysoký dopad, nízká náročnost:

Používejte nativní HTML prvky. <button> pro akce, <a href> pro odkazy, <select> pro rozbalovací menu. Nahraďte všude vzory <div onclick>.

Označujte každé formulářové pole. Propojte prvky <label> s inputy pomocí atributu for. Přidejte atributy autocomplete se standardizovanými hodnotami.

Vykreslujte obsah server-side. Zajistěte, aby hlavní obsah byl v počáteční HTML odpovědi.

Vysoký dopad, střední náročnost:

Implementujte orientační (landmark) oblasti. Zabalte obsah do prvků <nav>, <main>, <aside> a <footer>. Přidejte aria-label, pokud existuje více stejných landmarků na jedné stránce.

Opravte hierarchii nadpisů. Zajistěte jeden <h1> a logické pořadí <h2> až <h6> bez přeskakování úrovní.

Přesuňte kritický obsah ze „skrytých“ kontejnerů. Ceny, specifikace a klíčové informace by neměly vyžadovat kliknutí nebo interakci pro zobrazení.

Střední dopad, nízká náročnost:

Přidejte ARIA stavy do dynamických komponent. Používejte aria-expanded, aria-controls a aria-hidden pro menu, akordeony a přepínače.

Používejte popisný text odkazů. Místo „Klikněte zde“ použijte „Přečíst celou zprávu“. Agenti používají text odkazů k pochopení cíle.

Testujte pomocí čtečky obrazovky. Zařaďte to do QA procesu, ne jako jednorázový audit.

Klíčová zjištění

AI agenti vnímají webové stránky třemi způsoby: pomocí vizuálního přístupu (vision), parsování DOMu a stromu přístupnosti. Odvětví se postupně sbližuje na tom, že strom přístupnosti je nejspolehlivější metoda. OpenAI Atlas, Microsoft Playwright MCP a Perplexity Comet všechny spoléhají na data z přístupnosti.

Webová přístupnost už není jen otázkou souladu s pravidly. Strom přístupnosti je doslova rozhraní, které AI agenti používají k porozumění vašemu webu. Studie UC Berkeley a University of Michigan ukazuje, že úspěšnost agentů výrazně klesá, když jsou funkce přístupnosti omezené.

Sémantické HTML je základ. Nativní prvky jako <button>, <label>, <nav> a <main> automaticky vytvářejí užitečný strom přístupnosti. Není potřeba framework. Pro základy není potřeba ani ARIA.

ARIA je doplněk, ne náhrada. Používejte ji pro dynamické stavy a vlastní komponenty. Ale začněte se sémantickým HTML a ARIA přidávejte jen tam, kde nativní prvky nestačí. Nesprávné použití ARIA zhoršuje přístupnost webu, ne ji zlepšuje.

Server-side rendering je požadavek na viditelnost pro agenty. AI crawlery, které nespouštějí JavaScript, nevidí obsah v prázdných SPA aplikacích. Pokud váš obsah není v počátečním HTML, v AI ekosystému neexistuje.

Testování pomocí čteček obrazovky je nejlepší aproximace kompatibility s agenty. Pokud VoiceOver nebo NVDA dokážou procházet váš web, pravděpodobně to zvládnou i agenti. Pro přímou kontrolu poskytují Playwright MCP accessibility snapshots přesný pohled na to, co agenti vidí.

Tento článek se zaměřil na implementační vrstvu. Povzbuzující zpráva je, že tyto oblasti nejsou oddělené. Přístupné a dobře strukturované weby fungují lépe pro lidi, lépe se umisťují ve vyhledávání, častěji je cituje AI a lépe fungují pro agenty. Je to stejná práce pro čtyři různá publika.

A tato práce se vrství sama na sebe. Sémantické HTML a strukturovaná data popsaná zde jsou přesně to, na čem WebMCP staví svůj deklarativní přístup k formulářům. Strom přístupnosti, který dnes váš web vystavuje, se stává základem pro strukturovaná rozhraní nástrojů budoucnosti.

FAQ: 

Jak AI agenti „vidí“ webové stránky?
AI agenti vnímají web přes vizuální analýzu, DOM, a především strom přístupnosti, který se stává jejich hlavním rozhraním pro pochopení obsahu.

Co je nejdůležitější pro to, aby web dobře fungoval pro AI agenty?
Základem je dobře strukturované sémantické HTML, které vytváří kvalitní strom přístupnosti, protože ten rozhoduje o tom, jak agenti web interpretují.

Proč nestačí jen vizuální nebo JavaScriptově náročný web?
Protože AI crawlery často neprovádějí JavaScript a agenti se mohou ztrácet v komplexních interakcích, takže bez obsahu v HTML a přístupné struktury web pro AI prakticky „neexistuje“.