Proč vznikl tento článek?
Mám svou knowledge base kolem AI a SEO a měl jsem diskuzi, jestli máme investovat do markdownu pro AI agenty.
Interně jsme se shodli, že to aktuálně nemá smysl, ale chtěl jsem si k tomu udělat veřejné podklady.
V budoucnu bych vydával postupně více takových článků, cíl je ukázat realistický pohled na hype témata v SEO / GEO / AEO komunitě.
Ano, ale hlavně jako delivery a retrieval optimization, ne jako prokázaný AI visibility hack.
- Pomáhá některým agentům a retrieval pipeline dostat čistší a levnější verzi obsahu.
- Může snížit tokenovou a parsing režii.
- Zatím ale nemáme dobrý důkaz, že by samo o sobě zvyšovalo AI citations, mentions nebo referral traffic.
Pokud tomu kolem launch hype nevěříš jako visibility páce, dnešní data ti zatím dávají spíš za pravdu.
1. Co ta funkce skutečně dělá
Potvrzené z oficiální dokumentace
Cloudflare to staví jako content negotiation přes Accept: text/markdown, tedy formátové doručení stejného zdroje v čistší podobě, ne jako nový discovery mechanismus (Cloudflare docs, Cloudflare blog).
Podle oficiální dokumentace nejde o nový URL pattern ani o nový soubor jako llms.txt (Cloudflare docs).
Jde o content negotiation:
- agent pošle
Accept: text/markdown - Cloudflare si stáhne HTML verzi stránky
- na edge ji převede do markdownu
- vrátí markdown odpověď s
Content-Type: text/markdown
To je důležitá nuance. Funkce neřeší discovery, ale delivery. Jinými slovy: nepomáhá botovi najít stránku, ale pomáhá mu přečíst ji v čistší podobě, pokud už si o ni řekl (Cloudflare blog).
2. Co Cloudflare tím zjevně optimalizuje
Oficiální framing Cloudflare je silně postavený na efektivitě: token count, context window planning, méně HTML šumu a snazší parsování pro agenty (Cloudflare docs).
To je vidět i z toho, že markdown odpověď vrací x-markdown-tokens a že dokumentace feature popisuje hlavně jako pohodlný způsob, jak agentům dodat čistší dokument (Cloudflare blog).
První realistický závěr tedy je:
- tahle funkce zjevně pomáhá
Cloudflare + agent/clientstacku s efektivnějším přenosem a zpracováním dat - sama o sobě ještě nedokazuje zlepšení visibility webu
3. Používá to někdo reálně?
Externí experiment
Máme už consumption evidence, že některé agentické workflow markdown variantu opravdu vyžadují. Zatím ale nejde o důkaz, že z toho plyne lepší výkon ve visibility nebo referrals (Suganthan).
Tady je odpověď zajímavější než u llms.txt.
U llms.txt zatím většina evidence ukazuje velmi slabé reálné používání ve veřejném crawl workflow. U Cloudflare markdown negotiation už máme signál, že některé systémy ji opravdu používají.
Nejlepší dnešní praktická evidence je Suganthanův experiment (Suganthan):
- za
44dní zaznamenal1421markdown requestů - requesty šly od headless Chrome poolů,
Claudeinfrastruktury,axiosklientů a několika markdown-specific nástrojů
To znamená:
- není to čistě marketingová fantazie
- některé retrieval pipeline si markdown verzi skutečně vyžadují
To je podstatný rozdíl oproti llms.txt, kde je často problém už samotná absence requestů.
4. Znamená to lepší AI visibility?
Inference / pracovní závěr
Nejsilnější dnešní závěr je, že tu vidíme reálné používání pro ingest, ale pořád nevidíme prokázaný dopad na citations, mentions ani referral vrstvu. Hype kolem visibility je proto zatím silnější než evidence.
Tady je potřeba brzdit.
Suganthan výslovně uvádí, že jeho data neprokazují vyšší citovanost v AI odpovědích, vyšší referral traffic ani lepší visibility v ChatGPT, Claude, Perplexity nebo Google AI výsledcích (Suganthan).
Ukazuje jen to, že někdo markdown variantu opravdu čte, ale nevíme, co z toho downstream plyne.
To je zásadní rozdíl mezi consumption evidence a performance evidence. Dnešní data zatím máme hlavně pro první z těchto dvou rovin.
5. Jak to ověřit na vlastním webu
Pokud to chceš posoudit bez víry v launch hype, nejpraktičtější je krátký ověřovací workflow.
- Ověř, že endpoint skutečně vrací
Content-Type: text/markdown. - Zkontroluj, že odpověď vrací i
Vary: Accepta chová se jako varianta stejného zdroje (Cloudflare docs). - Porovnej HTML a markdown variantu, jestli zůstávají významově ekvivalentní.
- Loguj requesty s
Accept: text/markdown, ať víš, zda ti to někdo reálně stahuje. - Sleduj, které URL a kteří klienti markdown variantu čtou nejčastěji.
- Teprve potom vyhodnocuj, jestli se mění citation footprint, referral signály nebo jiná assisted business hodnota.
Bez takového ověření se snadno stane, že testuješ feature, která sice existuje v konfiguraci, ale v praxi na tvém webu nepřináší měřitelnou změnu.
Osobní zkušenost: Zde jsem já sám narazil, protože jednoduše nemám web na Cloudflare, což je přesně ukázka limitu. Z access logu serveru vím, že zatím se mě žádný robot nesnažil získat Content-Type: text/markdown, takže vlastně nemám, co moc reportovat. Bavil jsem se o tom i s dalšími lidmi a jednoduše nám aktuálně nestojí za to toto stavět, protože vynaložený čas můžeme investovat jinam a chytřeji.
V budoucnu budu mít web, kde to budu moci reálně použít, ale čekám na jeho nasazení. Až se tak stane přidám sem mnou naměřené data. S článkem se mi už nechtělo dál čekat.
6. Pomáhá to webu nebo hlavně Cloudflare?
Poctivá odpověď je: obojí, ale asymetricky.
Kde to zjevně pomáhá Cloudflare a agent stacku
- menší payload než plné HTML
- menší tokenová režie
- méně šumu z navigace, JS a boilerplate
- jednodušší ingest do retrieval nebo agentických workflow
Tohle je dnes nejlépe podložená část příběhu, protože přesně na ni míří i oficiální dokumentace a launch messaging (Cloudflare docs, Cloudflare blog).
Kde to může pomáhat webu
- pokud agent skutečně preferuje čistý markdown před horší HTML extrakcí
- pokud web běží na těžkém JS nebo složitém DOMu
- pokud obsah potřebuješ učinit snadno čitelný pro AI-assisted tooling
- pokud cílíš na docs, knowledge base nebo agentic product use cases
Kde je to zatím neprokázané
- růst citations
- růst mentions
- růst referral traffic
- lepší pozice v AI search surfaces
Právě tady byl kolem launch hype největší a právě tady je dnes evidence nejslabší.
7. Kdy to může reálně pomoci
Největší smysl to dává tam, kde je hlavní problém parsing friction, ne discovery deficit.
Typicky:
- API a developer docs
- knowledge base
- stránky s těžkým front-endem
- weby, které chtějí být použitelné v agentických workflow
V těchto případech je věrohodná hypotéza: pokud agent už stránku navštíví, markdown verze může zlepšit kvalitu ingestu nebo snížit náklady retrieval systému. To ale pořád neznamená, že agent tu stránku častěji objeví nebo že ji bude častěji citovat.
8. Kdy to pravděpodobně nepomůže moc
A. Web už má čisté HTML a dobrou SSR/ISR vrstvu
Pokud je stránka rychlá, textově čistá, dobře server-renderovaná a bez kritického obsahu schovaného v JS, markdown varianta často řeší menší problém.
B. Hlavní problém webu je discoverability
Pokud web není dobře indexovaný, interně propojený, entitně srozumitelný a obsahově citovatelný, Markdown for Agents řeší až druhotnou fázi.
C. Web čeká od feature přímý traffic nebo citation boost
To je dnes nejrizikovější očekávání. Evidence na takový efekt zatím nemáme.
9. Provozní a metodické limity
Tady je dobré být opatrný i technicky.
Oficiální dokumentace uvádí provozní limity, například převod jen z HTML a limit velikosti odpovědi. Externí experiment navíc ukazuje, že feature nemusí fungovat konzistentně na všech stackech a může tiše vracet HTML (Cloudflare docs, Suganthan).
To znamená, že před jakýmkoli vyhodnocením je potřeba ověřit:
- že opravdu vracíš
text/markdown - že odpověď má rozumnou kvalitu
- že obsah zůstává významově ekvivalentní
Jinak můžeš snadno měřit efekt funkce, která ve skutečnosti neběží.
10. Riziko: druhá reprezentace reality
Vedle hype je tu i druhý problém: důvěra.
Jakmile existuje zvláštní reprezentace stránky pro agenta, vzniká otázka:
- je to opravdu jen čistší forma téhož obsahu?
- nebo se z toho může stát
machine-onlyvrstva s odlišným významem?
To je důležité proto, že v AI search už teď existuje velká citlivost na cloaking-like chování, skryté instrukce a jiné ceny, claims nebo fakta pro stroj a pro člověka. Kritický pohled na tento trust problém zazněl i v SEO komunitě bezprostředně po launchi (Search Engine Land).
U Cloudflare implementation je sice základní příběh automatický převod HTML, ale jakmile se začne okolo toho cíleně optimalizovat, tlak na divergence mezi human a agent view roste.
Z hlediska governance je zdravé pravidlo:
- používat to jako formátový převodník
- nepoužívat to jako skrytou druhou obsahovou vrstvu
11. Hrozí duplicate content nebo postih?
Nejpravděpodobnější odpověď je:
duplicate content penaltysama o sobě spíš necloakingnebo trust problém potenciálně ano, pokud se obsah významově rozjede
Proč:
Markdown for Agentstypicky nevytváří novou veřejnou URL, ale jinou reprezentaci stejného zdroje přes content negotiation- to je technicky jiná situace než klasické
dvě URL se stejným obsahem - Cloudflare navíc vrací
Vary: Accept, takže jde o variantu jedné odpovědi, ne o nový samostatný indexační endpoint (Cloudflare docs)
Z pohledu vyhledávačů je proto větší problém ne duplicitní obsah, ale otázka, jestli markdown verze zůstává ekvivalentní HTML verzi. Google dlouhodobě říká, že duplicate content obvykle není porušení spam policy, pokud nejde o klamání nebo manipulaci (Google FAQ).
Právě tady vzniká riziko cloaking-like chování. Pokud markdown varianta mění fakta, přidává extra instrukce, skrývá nebo přepisuje důležité informace nebo ukazuje jinou komerční či obsahovou vrstvu než HTML, pak už nejde o neškodný formátový převod, ale o jiný dokument pro stroj. Google výslovně považuje za problém ukazovat crawlerům jiný obsah než lidem (Google website testing).
Praktické bezpečné pravidlo je:
- stejný význam
- stejná fakta
- stejná hlavní obsahová vrstva
- žádné bot-only doplňky, které bys nechtěl ukázat i lidskému návštěvníkovi
Jestli je markdown opravdu jen čistší serializace stejného obsahu, duplicate risk je nízký. Jestli se z něj stane agent-only page without a new URL, riziko není primárně duplicate, ale důvěryhodnost, similarity checks a případná klasifikace jako cloaking. Podobné varování zaznělo i od zástupců Google a Bing v debatě o separátních markdown verzích pro LLM (Search Engine Land).
12. Nejrealističtější verdict
Markdown for Agents není podle dnešních dat nesmysl. Ale taky to není prokázaný visibility lever.
Nejlepší současné čtení je:
llms.txt= dnes hlavně experimentální mapovací vrstva, slabě používanáMarkdown for Agents= reálně používaná retrieval utility na některých agentických cestách
Z pohledu webu to znamená:
- jako low-friction technické zlepšení to smysl mít může
- jako priorita před indexovatelností, kvalitním HTML, strukturou obsahu a crawler governance to dnes smysl nemá
Praktické doporučení
Zapnout dává smysl, pokud
- už běžíš na Cloudflare
- máš docs nebo knowledge-heavy web
- chceš pomoci agentům s čistším ingestem
- náklad implementace je minimální
Nečekal bych od toho sám o sobě
- více citations
- více AI referrals
- lepší Google AI Overviews visibility
- lepší AI Mode performance
Co měřit po zapnutí
- requesty s
Accept: text/markdown - které URL si markdown variantu žádají
- kteří klienti nebo user-agenty to dělají
- jestli se mění AI citation footprint těchto URL
- jestli se mění referral nebo assisted business value
Bez tohoto měření je z toho jen další AEO hypotéza.
FAQ
Pomůže to Google AI Overviews?
Z dnešních dat to nevyplývá. Může to zlepšit ingest některým agentům, ale nemáme důkaz, že by to samo o sobě zvyšovalo Google AI visibility.
Je to cloaking?
Samo o sobě ne, pokud markdown zůstává jen čistší reprezentací stejného obsahu. Riziko vzniká až tehdy, když bys crawlerům ukazoval významově jinou verzi než lidem.
Má to smysl mimo Cloudflare?
Princip čistšího strojového doručení smysl mít může, ale tenhle konkrétní mechanismus je Cloudflare-native. Mimo Cloudflare už řešíš jinou implementaci i jiný cost-benefit profil.
Má to smysl pro malý obsahový web?
Obvykle až jako pozdější optimalizace. Dřív dává větší smysl vyřešit indexovatelnost, kvalitní HTML, interní prolinkování a obsah s reálnou citační hodnotou.
