Rubriky
Blog o SEO - Optimalizace pro vyhledávače Umělá inteligence v analytice a marketingu

Má smysl používat Cloudflare Markdown pro AI Agenty?

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ě.

Stav k 20. dubnu 2026.

Krátký závěr

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.

OtázkaKrátká odpověď
Pomáhá AI visibility?Neprokázáno.
Pomáhá retrievalu nebo ingestu?Ano, v některých případech.
Pomáhá Google rankings?Není důkaz.
Má smysl testovat?Ano, pokud už běžíš na Cloudflare.
Je to náhrada za technické SEO?Ne.

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/client stacku 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 44 dní zaznamenal 1421 markdown requestů
  • requesty šly od headless Chrome poolů, Claude infrastruktury, axios klientů 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.

  1. Ověř, že endpoint skutečně vrací Content-Type: text/markdown.
  2. Zkontroluj, že odpověď vrací i Vary: Accept a chová se jako varianta stejného zdroje (Cloudflare docs).
  3. Porovnej HTML a markdown variantu, jestli zůstávají významově ekvivalentní.
  4. Loguj requesty s Accept: text/markdown, ať víš, zda ti to někdo reálně stahuje.
  5. Sleduj, které URL a kteří klienti markdown variantu čtou nejčastěji.
  6. 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-only vrstva 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 penalty sama o sobě spíš ne
  • cloaking nebo trust problém potenciálně ano, pokud se obsah významově rozjede

Proč:

  • Markdown for Agents typicky 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.

.