Co v článku najdete
Posledních několik týdnů bylo poměrně rušných. Google představil něco, čemu se říká Open Knowledge Format (OKF). Následně byla prostřednictvím Google Developers oznámena specifikace Agentic Resource Discovery (ARD).
Mezitím se každý SEO feed na LinkedInu zaplnil lidmi, kteří buď prohlašují Markdown za budoucnost webu, nebo naopak vysvětlují, proč byste to všechno měli ignorovat. Pravda ale jako obvykle leží někde mezi těmito dvěma tábory.
Web si buduje paralelní strojově čitelnou infrastrukturu (MCP/WebMCP, OKF, ARD, LLMs.txt…) a SEO specialisté, kteří chápou, co jednotlivé vrstvy skutečně dělají, místo toho, aby vše označovali za „AI SEO“ nebo za zázračné řešení, se budou moci lépe rozhodovat, kam investovat svůj čas.
Za prvé: Vrstvený dort
Pod zastřešujícím pojmem „připravit web na AI“ se ve skutečnosti diskutuje alespoň šest různých věcí. Každá z nich funguje na jiné vrstvě a má jiný účel:
HTML stránky dostupné pro procházení: Stále představují základ a v tomto ohledu se nic nezměnilo. Vše ostatní stojí na této vrstvě.
Schema.org / strukturovaná data: Sémantické informace vložené do HTML, které strojům explicitně říkají, o čem daná stránka je. V podstatě jde o určitý slovník.
LLMs.txt: V zásadě se jedná o navigační soubor. Jeho účelem je říct AI agentovi, který se už na vašem webu nachází, které stránky jsou důležité.
Jak ale uvádí John Mueller v podcastu Search Off the Record:
„Pokud už někdo na vašem webu je, může být nějaký automatizovaný systém užitečný. Když například řekne: Chci jít k Martinovi Splittovi a koupit si fotografii, LLM systém může přejít na váš web a podívat se, jak se fotografie kupuje. Možná tam má nějaké pokyny, které mi jako agentovi pomohou s nákupem fotografií. To dává určitý smysl.“
MCP / WebMCP: Ještě před příchodem ARD jsme dostali jiné řešení problému interoperability. MCP lze jednoduše vysvětlit jako standardizovaný způsob, jak se AI může připojit k vašim službám, získávat z nich informace nebo provádět určité akce. WebMCP, jak už název napovídá, umožňuje webům přímo komunikovat s agenty.
WebMCP je určen pro živé interakce s webovou stránkou v prohlížeči, zatímco MCP slouží pro nástroje a služby mimo samotnou stránku.
Open Knowledge Format: Balíček Markdown souborů s YAML frontmatterem.
Agentic Resource Discovery: Nová otevřená specifikace, která určuje, jak mohou agenti na webu vyhledávat a ověřovat nástroje, dovednosti a další agenty. Tady není hlavním tématem váš obsah, ale vaše schopnosti a možnosti, které agentům nabízíte.
V případě e-commerce stojí za samostatnou zmínku ještě jedna vrstva, a to produktový feed, který je dost možná budoucností objevování produktů v retailu.
Každá vrstva má za úkol něco jiného. V tomto seznamu bychom mohli pokračovat dál. Každých pět minut se zkrátka objevuje nějaká nová vrstva.
Co je to OKF?
Google specifikaci OKF zveřejnil poměrně nenápadně, v souvislosti s přejmenováním Dataplexu na Knowledge Catalog.
Samotný formát je až překvapivě jednoduchý. Jedná se totiž o adresář Markdown souborů, z nichž každý obsahuje krátkou hlavičku YAML definující typ, název, popis, zdroj a některé štítky. Soubory jsou navzájem propojeny stejně jako jakýkoli jiný Markdown dokument. A to je v zásadě celé.
SEO specialista Suganthan Mohanadasan toto vysvětluje velmi názorně v rámci svého přehledu. OKF popisuje jako jedno patro v technologickém stacku, který dnes zahrnuje také sitemap.xml (tzn. jaké URL na webu existují), LLMs.txt (které stránky má AI číst přednostně) a OKF (samotnou knihovnu). Tyto vrstvy se navzájem doplňují, nikoli konkurují.
Zmatek ale nevzniká při pohledu na to, co OKF je, nýbrž na to, co skutečně dělá a do jaké vrstvy celého chaosu kolem agentů a vyhledávání vlastně patří.
OKF tedy není systém pro vyhledávání a získávání informací. Nenahrazuje crawling. A nemyslíme si, že nás čeká budoucnost, ve které AI systémy přestanou zpracovávat obrovské množství HTML nebo ve které vyhledávání a RAG přestanou fungovat jako vícekrokové a komplexní procesy kombinující signály, které weby samy poskytují, s dalšími, „nepodloženými“ signály.
Jakýkoliv systém založený na informacích, které o sobě poskytuje samotný web, může být, a také bude, zneužíván. Představa, že stačí na web nahrát hromadu Markdown souborů a automaticky se tak stát preferovanou volbou pro vyhledávání a objevování obsahu, je proto přitažená za vlasy.
OKF je zdrojem s kvalitnějším signálem mezi mnoha dalšími zdroji. Může snížit náklady na zpracování a zlepšit kvalitu signálu, ale nenahrazuje stávající procesy.
Je také fér říct, že OKF bylo vytvořeno pro datové týmy, nikoli pro marketingové weby.
Vzniklo jako způsob sdílení interních znalostí, například schémat tabulek, provozních postupů nebo definic metrik mezi AI agenty uvnitř organizací. Jeho použití na veřejných webech je proto spíše trochu jako další případ, kdy technologii znovu využíváme pro úplně jiný účel.
Francois Vanderseypen velmi přesně popisuje, co OKF skutečně je a není: řízený graf Markdown souborů je síť dokumentů, nikoli znalostní graf. Skutečný znalostní graf obsahuje dotazovatelné vztahy. U OKF je význam jednotlivých odkazů zcela ponechán na autorovi a LLM musí při každém čtení znovu odvozovat jejich sémantiku.
OKF nemění celý technologický stack. Pouze do něj přidává další vstup. Není to zkratka. Žádné zkratky neexistují.
Paralela se Schema.org a proč na ní záleží
Jedním ze vzorců, které je zde dobré pochopit, je vývoj, kterým už prošlo Schema.org.
Strukturovaná data prošla poměrně předvídatelným vývojem: adopce → zvýhodnění v hodnocení → masové používání → učení platforem → menší závislost na strukturovaných datech jako hodnoticím signálu.
FAQ schéma mělo své období slávy ve výsledcích vyhledávání (SERP), následně ale Google přestal zobrazovat rozšířené výsledky FAQ. Platformy se učí ze signálů, zapracovávají získané poznatky do algoritmu a explicitní značkování se postupně stává méně potřebným.
OKF a LLMs.txt mohou projít stejným vývojem. Největší hodnotu mají zpočátku, kdy představují jasné signály ve světě, v němž se AI systémy teprve učí web správně interpretovat.
Postupem času, pokud se tyto formáty osvědčí, se systémy naučí jejich obsah samy rozpoznávat. Explicitní značkování se pak stane nadbytečným, případně zůstane jako vrstva pro ověřování. Například v e-commerce je stále důležitější soulad mezi strukturovanými daty a produktovým feedem. Je to další argument pro společné vlastnictví produktového feedu mezi SEO a PPC týmy!
Za zmínku stojí také méně zřejmý aspekt vztahu mezi Schema.org a objevováním obsahu. Podrobná analýza produktových variant od Jarno van Driela v Search Engine Journal toto dobře ilustruje: Google Search a Google Merchant Center měly po řadu let rozdílné požadavky na strukturovaná data, což vydavatele nutilo duplikovat značkování. Schema.org se postupně vyvíjí tak, aby tyto mezery uzavíralo, ale celý proces je pomalý, složitý a implementace je stále často značně problematická.
Strukturovaná data nikdy nebyla nástrojem pro okamžité zvýšení pozic ve vyhledávání. A OKF na tom nebude jinak.
Je třeba převést web do Markdownu?
Jednoznačně ne. To ale neznamená, že to nebudu testovat a případně opatrně využívat.
John Mueller to uvedl v podcastu Search Off the Record:
„Pokud jde o vyhledávač nebo pravděpodobně také obecný LLM systém, je zásadní mít web, jehož stránky používají standardní HTML. Vyhledávač nebo crawler se na takovou stránku může jednoduše dostat a rozpoznat všechny ostatní odkazy, které se na webu nacházejí.“
Strukturální informace v HTML, tedy navigační odkazy, patičky, hierarchie nadpisů nebo interní odkazy, pomáhají crawlerům pochopit strukturu vašeho webu. Markdown soubory o velkou část těchto informací přicházejí.
Převodem celého webu do Markdownu byste tak mohli narušit objevování a procházení webu jen proto, abyste trochu zlepšili strojovou čitelnost jednotlivých stránek.
Na LinkedInu byl nedávno publikován výzkum, který ukazoval, jak může „vaše navigace spotřebovávat rozpočet LLM na čtení“ (ve skutečnosti šlo o Deep Research v ChatGPT).
Jono Alderson toto vystihl skvěle: „Stránka není jen kontejner na slova. Je to redakční výstup.“ Hierarchie, důraz, umístění, to, co je uvedeno jako první, co je nejvýraznější a co je naopak schované v poznámce pod čarou… to nejsou jen hezké dekorace pro lidi. „Jsou to signály významu.“
„Když stránku převedete do plochého Markdownu, neodstraníte jen nepotřebné prvky. Odstraníte také rozhodování a kontext.“ A ve chvíli, kdy zveřejníte reprezentaci určenou pouze pro stroje, vytvořili jste druhou potenciální verzi reality.
Stále funguje ta původní nudná cesta: sémantické HTML, jasná struktura, smysluplná hierarchie a obsah, který je dostupný hned při načtení stránky.
John Mueller se debatě o Markdownu v podcastu věnuje poměrně podrobně. Mluví o problému paralelních verzí, o lekcích z dynamického renderování, které jsme se už jednou tvrdě naučili, a o tom, proč udržování „stínové“ verze webu pro AI zdvojnásobuje nároky na údržbu a vytváří noční můru při hledání a opravování chyb, o které vám nikdo předem neřekne.
Mueller uvádí jednu výjimku, a tou je dokumentace pro vývojáře:
„Pokud máte například dokumentaci pro vývojáře, agent nebo LLM systém už váš web zná a uživatel se zeptá: Jak toto API použiji? Nebo pak pokud LLM systému poskytnete Markdown soubor, je pro něj mnohem jednodušší porozumět mu.“
Právě zde je jednoduchý a smysluplný způsob využití.
Co ARD skutečně dělá?
Specifikace Agentic Resource Discovery (ARD), kterou Google oznámil 17. června 2026, je úplně jiný typ technologie. Objevila se jen několik dní po OKF, což není náhoda, a už teď vyvolává velkou pozornost.
Problém, který ARD řeší, se týká koordinace. V současné době musí být agent předem napojen na každý nástroj, MCP server nebo API, které má používat, aby s nimi mohl něco dělat.
To funguje ve chvíli, kdy propojujete několik málo známých služeb. Přestává to ale být škálovatelné ve chvíli, kdy počet dostupných možností překročí množství, které může jakýkoli tým ručně předem nakonfigurovat.
ARD přesouvá objevování z fáze nastavení přímo do běhu systému. Agent tak může najít to, co právě potřebuje, ve chvíli, kdy to potřebuje, místo aby znal pouze to, o čem byl předem informován.
Je postaven na dvou základních prvcích:
- Katalogy: Soubor ai-catalog.json umístěný na vaší doméně, který popisuje dostupné možnosti a funkce, například MCP servery, A2A agenty nebo nástroje založené na OpenAPI. Vlastnictví domény zde slouží jako kryptografický základ pro identitu a důvěryhodnost.
- Registry: Vyhledávače pro agentický web. Procházejí katalogy, indexují je a vracejí odpovídající možnosti společně s metadaty potřebnými k ověření vydavatele před navázáním spojení.
Pokud je OKF o přípravě a strukturování znalostí pro jejich další zpracování, ARD je o prezentaci a zpřístupnění schopností, ke kterým se mohou agenti připojit.
Jde o paralelní snahy, které fungují na různých vrstvách vznikajícího agentického technologického stacku. Obě technologie byly představeny téměř současně a některé velké technologické společnosti je nyní přebírají nebývalou rychlostí, například Hugging Face se svým nástrojem Discover Tool.
Mezera, kterou stojí za to sledovat
Během několika dní po vydání obou specifikací otevřel jeden z přispěvatelů související případy v repozitářích ARD a OKF a upozornil na poměrně základní chybějící prvek: pro balíček OKF neexistuje dohodnutý typ média. Katalog tak sice může OKF balíček uvést, ale bez kontroly jeho obsahu ho nedokáže jednoznačně rozpoznat jako OKF.
Mezitím už vydavatelé v produkčním prostředí tyto balíčky inzerují pomocí vlastních dočasných typů. Ty se ale, jak samotný případ upozorňuje, nebudou navzájem shodovat.
Na první pohled to vypadá jako drobnost: jednoduše požadavek na společný štítek.
Po trochu hlubším ponoření do tohoto konkrétního tématu se ale ukazuje, že jde o poměrně běžnou praxi. Čekat s vydáním technologie na úplnou shodu všech zúčastněných je přesně způsob, jak může specifikace zemřít v nekonečných diskusích. Rychlé vydání a následné úpravy podle toho, jak se technologie skutečně začne používat, jsou naopak osvědčenou strategií.
Například application/json nebyl formálně zaregistrován až do roku 2006, tedy přibližně pět let poté, co se JSON už široce a neformálně používal. Nikomu to příliš nevadilo, protože cena za to, že tento štítek nebyl definitivně sjednocený, byla nízká: parser mohl něco odmítnout nebo si s tím poradit nepříliš elegantním způsobem.
U OKF je ale situace jiná, protože to, co se děje po načtení dat, je zásadně odlišné. Obsah za tímto štítkem představuje balíček, který má autonomní agent načíst, ověřit a případně podle něj provést nějakou akci. To vše v rámci systému pro objevování zdrojů vytvořeného přímo pro propojování agentů mezi sebou a agentů s nástroji.
Pokud je zde typ uveden nesprávně nebo je agent ponechán, aby ho sám odhadl, rizikem není jen chyba při zpracování. Rizikem je, že systém začne pracovat s něčím, čemu neměl důvěřovat, aniž by výsledek předem někdo zkontroloval.
Jaké riziko v tomto případě přináší řešit tento problém až později namísto co nejdříve? Nejspíš záleží na tom, jak rychle se podaří problém vyřešit v porovnání s rychlostí, jakou bude adopce těchto technologií postupovat.
Co to vše znamená pro SEO specialisty?
Pro většinu marketingových a obsahových webů se ve skutečnosti příliš nezměnilo. HTML, dobře strukturované pro lidi, je stále správným základem. Kontaktní formulář a čistá architektura webu vám poslouží lépe než jakýkoli OKF balíček. Objevování webu stále závisí na odkazech, autoritě, uživatelských signálech… a indexaci.
LLMs.txt je směrovka, nikoli SEO nástroj
Je užitečný pro navigaci agenta uvnitř vašeho webu ve chvíli, kdy už se na něm nachází. Velmi pravděpodobně ale nijak zásadně neovlivňuje, jak vás agenti vůbec objeví. A nejspíš ani nikdy nebude.
MCP/WebMCP
Pro většinu marketingových webů dnes ani jedno nepředstavuje naléhavou potřebu. Pokud ale vytváříte něco s programovými rozhraními nebo e-commerce procesy, které chcete zpřístupnit agentům, právě tímto směrem se infrastruktura ubírá.
OKF dává velký smysl, pokud máte velké množství strukturovaných interních znalostí, například dokumentaci, reference k API, produktové specifikace a podobně, a chcete agentům usnadnit jejich zpracování. Bezplatný generátor OKF, který vytvořil Suganthan, vytvoří balíček a jako vedlejší benefit vám nabídne také grafické zobrazení struktury interních odkazů. Už samotný strukturální audit podle mě stojí za to. Na svém webu ho ale nejdřív vyzkouším já, nikoli na webu klienta.
ARD stojí za sledování, pokud vytváříte služby s programovými rozhraními. Pokud máte nástroje, agenty nebo API, které chcete zpřístupnit pro objevování jiným agentům, ARD se stává nově vznikajícím standardem pro to, jak toho dosáhnout. Jen je potřeba vědět, že vrstva identity, která za tím stojí, tedy co přesně agent vidí, když objeví váš záznam v katalogu, se stále vyvíjí v reálném čase. Zatím proto ARD vnímejte spíše jako infrastrukturu, kterou je dobré pozorně sledovat, než na ní stavět kriticky důležité části systému.
Cyklus adopce Schema.org se může opakovat. Tyto formáty mají největší hodnotu právě teď, kdy fungují jako nové signály. Pokud je můžete implementovat levně, udělejte to. Nestavte ale svou strategii na předpokladu, že si svou hodnotu udrží navždy, a rozhodně na ně nespoléhejte jako na zázračné řešení.
A především si dávejte pozor na všechny ty nové a lákavé technologie. Pokud má vaše firma větší problémy k řešení, například hrozný web, značku, kterou nikdo nezná nebo o ni nemá zájem, případně publikum, kterému nerozumíte, řešte nejdříve tyto věci, než se necháte strhnout některou z těchto novinek.
Základní změna
To všechno ukazuje na web, který skutečně začíná vytvářet druhou vrstvu, možná dokonce třetí. Jednu vrstvu psanou pro stroje vedle té, která je určena pro prohlížeče a lidi.
Sitemap.xml říká crawlerům, jaké URL existují. Robots.txt jim říká, kam nemají chodit. LLMs.txt, OKF a ARD představují podobnou infrastrukturu pro agentické systémy: navigační nápovědu, strukturování obsahu a objevování schopností.
Dnes nic z toho není povinné. Nic z toho nenahrazuje kvalitní HTML, důvěryhodný obsah, smysluplnou strukturu ani to, co je pod tím vším skutečně nejdůležitější: značku, kterou stojí za to hledat.
SEO specialisté, kteří pochopí, co jednotlivé vrstvy skutečně dělají, místo aby je vnímali jako jednu nerozlišenou kategorii „AI SEO“, se ale budou moci lépe rozhodovat, kam investovat svůj čas.
Scénář se „třetí vrstvou (hlavou)“, kdy se agentické systémy zcela oddělí od webu určeného lidem, by vyžadoval úplně jiný přístup, než jaký dnes kdokoli z nás předpokládá.
FAQ
Co je OKF a k čemu slouží?
OKF je formát založený na propojených Markdown souborech, který pomáhá AI systémům lépe pracovat se strukturovanými znalostmi. Nenahrazuje crawling ani klasické HTML, ale přidává další strojově čitelný zdroj informací.
Jaký je rozdíl mezi OKF, LLMs.txt a ARD?
LLMs.txt slouží především jako navigační pomůcka, OKF strukturuje a zpřístupňuje znalosti a ARD umožňuje agentům vyhledávat a ověřovat dostupné nástroje, služby nebo jiné agenty.
Měli by SEO specialisté převádět weby do Markdownu?
Určitě ne. Základem by mělo zůstat kvalitní a sémanticky strukturované HTML, zatímco Markdown a další nové formáty má smysl využívat pouze tam, kde přinášejí konkrétní výhodu.
Co by teď měli SEO specialisté dělat?
Nové technologie je vhodné sledovat a levně implementovatelné formáty případně testovat, ale nestavět na nich celou SEO strategii. Důležitější zůstává kvalitní web, obsah, struktura, autorita a silná značka.
Zdroj: searchengineland.com, searchenginejournal.com, marketingland.com, facebook.com, cpcstrategy.com
Autor: Vlastimil Malík
Foto zdroj: AI, pixabay.com
