Wprowadzenie
W czerwcu 2026 na polskim LinkedInie i w kanałach inżynierskich wraca to samo pytanie: jak serwować treść agentom AI? Czysty Markdown, bo modele zdają się go lubić? Osobny endpoint dla maszyn? Nowy format wiedzy? Dyskusja jest głośna, pełna mocnych tez i w większości mija się sama ze sobą.
Postawmy stanowisko praktyka od razu, bo mamy w tej grze swoją skórę. Jako polska agencja pracująca głównie dla klientów zagranicznych już teraz serwujemy czysty, semantyczny, renderowany po stronie serwera HTML plus Schema.org z frontu opartego na Astro na Cloudflare. Ta debata potwierdza ten wybór, nie podważa go. Niemal każdy argument w stylu “musisz przejść na Markdown dla agentów” rozpada się w chwili, gdy rozdzielisz trzy warstwy, które są bez przerwy zlepiane w jedną.
To nie komentarz z trybun. Działamy dokładnie na tej infrastrukturze, o której toczy się spór, i prowadzimy już tę warstwę agentową, na którą debata wskazuje jako na właściwą przyszłość. Więc to relacja od środka, nie streszczenie z tanich miejsc.
Najważniejsze w skrócie
- Spór miesza trzy warstwy, które nie są tym samym problemem: Markdown jako output agenta, Markdown jako sposób serwowania stron i OKF jako warstwę wiedzy.
- Markdown jako output agenta to decyzja o renderowaniu maszyna do człowieka, a jedna z osób, które najmocniej go forsowały, właśnie porzuciła go na rzecz HTML.
- Serwowanie Markdownu robotom pod tym samym adresem, pod którym człowiek dostaje HTML, jest w najlepszym razie zbędne, a w najgorszym to cloaking. Google i Bing powiedziały to wprost i bez ogródek.
- OKF to format wyselekcjonowanej wiedzy dla pipeline’ów agentowych, a nie format serwowania stron. To inna warstwa niż SEO.
- Jedyny sygnał serwowania treści, który zarówno Google, jak i Bing dokumentują jako faktycznie konsumowany, to czysty, semantyczny HTML plus Schema.
- Obserwuj, nie pędź do wdrażania nowych formatów serwowania. Prawdziwy forward-bet to warstwa akcji agenta, i to jest część, którą już zbudowaliśmy.
Trzy warstwy, które wszyscy mylą
Większość emocji w tej debacie bierze się z traktowania trzech osobnych pytań jak jednego. Rozdziel je, a sprzeczności znikają.
Warstwa 1: Markdown jako output agenta
Tu chodzi o to, co model odpisuje człowiekowi, a nie o to, jak serwowana jest strona. Gdy agent generuje raport, odpowiedź na czacie albo dokument, w jakim formacie ma to wypluć?
Przez długi czas domyślną odpowiedzią był Markdown. Czysty, tani w tokenach, ładnie renderuje się w dymku czatu. Potem Thariq Shihipar, który pracuje nad Claude Code w Anthropic, publicznie się z tego wycofał. Po zbudowaniu porównań skuteczności HTML i Markdown jego wniosek brzmiał: do outputu agenta wygrywa HTML, bo niesie strukturę, semantykę i interaktywność, których potrzebuje bogatsza powierzchnia skierowana do człowieka. Markdown za bardzo spłaszcza.
Przeczytaj to uważnie, bo regularnie cytuje się to na odwrót. Osoba najbliżej outputu agenta idzie w stronę HTML, nie od niego. I co kluczowe, ta warstwa nic nie mówi o tym, jak serwować swój serwis robotowi. To komunikacja maszyna do człowieka. Kto cytuje Thariqa jako powód, żeby przerobić stronę na Markdown, odwrócił jego własny argument do góry nogami.
Warstwa 2: serwowanie stron przez Markdown-for-Agents
To warstwa, która dotyka nas bezpośrednio, bo działamy na Cloudflare. Markdown-for-Agents od Cloudflare konwertuje twój HTML do Markdown w locie, gdy klient wyśle Accept: text/markdown, raportuje liczbę tokenów przez x-markdown-tokens i podaje około 80 procent redukcji tokenów względem surowego HTML. Jest w becie na płatnych planach, a klienci tacy jak Claude Code i OpenCode już wysyłają ten nagłówek. Steruje tym Content-Signal, który na Cloudflare jest domyślnie opt-in, więc może to być włączone na twojej domenie bez świadomej decyzji. To właśnie ten detal z domyślnym włączeniem każdy klient Cloudflare powinien u siebie sprawdzić.
Oszczędność tokenów jest realna. Obietnica widoczności już nie. Nie ma udokumentowanego dowodu, że serwowanie reprezentacji Markdown zmienia, czy system AI cię cytuje. A w chwili, gdy serwujesz robotom inną reprezentację tego samego adresu niż dostaje człowiek, stoisz tuż przy linii cloakingu.
John Mueller z Google ujął to bez krzty dyplomacji:
“Converting pages to markdown is such a stupid idea. Did you know LLMs can read images? WHY NOT TURN YOUR WHOLE SITE INTO AN IMAGE?”
Czyli: konwersja stron do Markdown to taki głupi pomysł, że równie dobrze, skoro LLM-y czytają obrazy, zamień cały serwis w obrazek. To sarkazm z tezą w środku. Jeśli model i tak czyta twój HTML, równoległy kanał Markdown nie jest nowym sygnałem, jest drugą rzeczą do utrzymania i trzymania w synchronie. Fabrice Canel z Bing był bardziej rzeczowy i chyba jeszcze bardziej bolesny dla tych, którzy liczą na oszczędność crawl budgetu:
“Really want to double crawl load? We’ll crawl anyway to check similarity.”
Innymi słowy, wyszukiwarka i tak pobiera HTML, żeby zweryfikować, że Markdown zgadza się z tym, co widzi człowiek. Nie zmniejszasz obciążenia, dokładasz powierzchnię, która musi się zgadzać z kanoniczną, albo dostajesz flagę. Dwaj z największych operatorów crawlowania na planecie powiedzieli ci publicznie, że to nie robi tego, na co liczą zwolennicy.
Warstwa 3: OKF jako warstwa wiedzy
12 czerwca 2026 Google Cloud opublikowało Open Knowledge Format, OKF, z publicznym repozytorium referencyjnym. Jest celowo skromny: pliki Markdown z frontmatterem YAML, jeden koncept na plik, wymagane tylko pole type, producent i konsument trzymani niezależnie. Hasło brzmi “format, nie platforma”, a dług wobec gista LLM-wiki Andreja Karpathy’ego jest oczywisty, to idea bazy wiedzy redagowanej przez człowieka, ale pisanej dla maszyn.
I tu rzecz, którą streszczenia gubią. OKF nie jest sposobem serwowania serwisu. To sposób pakowania wyselekcjonowanej wiedzy tak, żeby pipeline agentowy mógł ją skonsumować. Żyje powyżej retrievalu, w warstwie kontekstu i ugruntowania, a nie pod adresem, gdzie robot spotyka twoją stronę. Jak celnie ujął jeden z komentujących ogłoszenie, Adam Rogala: “OKF ma sens, ale na innej warstwie niż SEO”. Mylenie “Google wydało format wiedzy w Markdown” z “Google chce, żebyś serwował serwis jako Markdown” to najczęstszy błąd obecnego cyklu, a to nawet nie jest blisko to samo.
Jest też zdrowa wersja Markdownu w stacku publikacyjnym i warto ją nazwać, żeby nikt nie usłyszał tego jako anty-Markdown. Markdown w źródle, renderowany do HTML na etapie buildu, to dokładnie sposób, w jaki powstał ten artykuł. To jego właściwe miejsce. Jak zauważył w tej samej dyskusji Bartosz Łaszczewski, surowy Markdown wysyłany do przeglądarki nie ma sensu, bo konsument po drugiej stronie, czy to przeglądarka, czy AI, jest zbudowany wokół HTML.
Dlaczego ta debata potwierdza nasz stack
Rozdziel trzy warstwy, a wniosek jest niemal nudny, i o to chodzi. To, co już działa, dalej działa.
Serwujemy renderowany po stronie serwera, semantyczny HTML. Nagłówki są nagłówkami, listy listami, article, nav i time znaczą to, co mówią, a dane strukturalne to prawdziwe Schema.org, a nie dekoracja. To ta reprezentacja, którą indeksuje Google, którą crawluje Bing i którą pobiera LLM, gdy sięga po stronę. To też, nieprzypadkowo, reprezentacja, która szybko renderuje się człowiekowi. Nie ma rozwidlenia do utrzymania, nie ma drugiego kanału, który mógłby się rozjechać, nie ma ryzyka cloakingu.
Wszystko, czego ta debata się boi, my dostajemy za darmo, po prostu tego nie goniąc. Gdy Mueller mówi, że konwersja do Markdown jest bezcelowa, bo model czyta twój HTML, to opis naszego setupu działającego zgodnie z założeniem. Gdy Canel mówi, że Bing i tak crawluje HTML, w porządku, bo HTML jest artefaktem kanonicznym i nie ma nic innego do uzgadniania. Nie musieliśmy reagować na żadne z tych zdań. Architektura już na nie odpowiedziała.
Jedyny udokumentowany sygnał
Jeśli chcesz reguły, która przetrwa kolejne ogłoszenie formatu, oto ona. Czysty, renderowany po stronie serwera, semantyczny HTML z poprawnym Schema.org to jedyne podejście do serwowania treści, które zarówno Google, jak i Bing dokumentują jako coś, co faktycznie konsumują. Cała reszta w tej przestrzeni to albo propozycja bez zmierzonej konsumpcji, albo optymalizacja kosztu, a nie widoczności.
Bing, przez Copilot, czyta dane strukturalne. Google czyta dane strukturalne na własne powierzchnie. Duże modele językowe pobierają wyrenderowany HTML. Żaden z nowych formatów serwowania, llms.txt, Markdown-for-Agents, ai.txt, nie ma udokumentowanego wpływu na to, czy zostaniesz zacytowany. Więc uczciwa postawa inżynierska brzmi: trzymaj HTML czysty, Schema poprawne, a nowe formaty serwowania traktuj jak coś do obserwacji, nie do wdrażania. Ta sama dyscyplina dotyczy headless WooCommerce na Astro: dane sklepu to prawdziwy semantyczny markup, a nie boczny kanał tylko dla robotów.
Uczciwie o llms.txt
Publikujemy /llms.txt i /llms-full.txt, więc to autokrytyka, nie tania zaczepka pod czyimś adresem. Sceptycy mają mocne argumenty. Mueller mówi, że format jest w praktyce ignorowany, a niezależne badanie logów serwerowych nie znalazło ani jednego zapytania robota AI o llms.txt na setkach domen przez kilka miesięcy. Jako samotny plik rzucony na serwer w nadziei, że coś go przeczyta, robi bardzo niewiele.
Nasz własny playbook widoczności w AI mówi dokładnie to, czarno na białym: żaden duży dostawca LLM nie zobowiązał się formalnie do czytania tych plików, ale pojawiają się w naszych logach wystarczająco często, by uzasadnić ich utrzymanie. Trzymamy obie myśli naraz. Generyczny, osierocony llms.txt jest bliski martwemu balastowi. Ten sam plik jako jeden węzeł zintegrowanego setupu agent-discovery, podpięty do realnej warstwy akcji, to inny obiekt o innym bilansie kosztów i korzyści. Błąd polega na cytowaniu badań “nikt nie czyta llms.txt”, jakby zamykały sprawę dla każdej implementacji. Zamknęły ją dla przypadku samotnego pliku.
Prawdziwy forward-bet: warstwa akcji agenta
Tu rozchodzimy się z ekipą “po prostu serwuj Markdown” całkowicie i tu jest naprawdę ciekawa przyszłość. Następny krok to nie lepszy dokument do przeczytania przez agenta. To pozwolenie agentowi działać bez czytania dokumentu w ogóle.
To jest warstwa akcji agenta: WebMCP, Agent2Agent (A2A) i Model Context Protocol. Zamiast scrapować stronę usług i zgadywać, agent wywołuje funkcję, request_quote, browse_services, search_site, i dostaje typowaną odpowiedź. WebMCP, współpraca Google i Microsoftu, jest w developer preview w Chrome od lutego 2026 i celuje wprost w ten model: strona udostępnia możliwości, agent je wywołuje.
To już zbudowaliśmy. Pod public/.well-known/ publikujemy A2A AgentCard, MCP server-card zgodny z SEP-1649, deskryptor ACP oraz negocjację treści w Markdown przez sufiks .md w adresie i obsługę Accept: text/markdown w middleware, a całość ogłaszamy nagłówkami Link i regułami robots. Skill fetch_markdown na naszym AgentCard wskazuje na /llms-full.txt, i to jest właśnie powód, dla którego pliki llms nie są tu osierocone, są wpięte w warstwę akcji, a nie leżą same.
Zauważ asymetrię. Markdown-for-Agents i negocjację treści, formaty serwowania, traktujemy jako obserwuj-nie-wdrażaj, są obecne, bo oferuje je infrastruktura, a nie dlatego, że zmierzyliśmy korzyść. Warstwę akcji traktujemy jako świadomą inwestycję w przyszłość, bo tam celuje argument Thariqa o HTML, WebMCP i cała fala narzędzi agentowych. Czytanie to teraźniejszość. Działanie to zakład.
Co konkretnie robimy
Żeby postawę uczynić namacalną, oto podział.
- Serwowanie: czysty, semantyczny HTML plus Schema.org, renderowany po stronie serwera, szybki. To decyzja nośna i ona się nie zmienia.
- Markdown-for-Agents i Content-Signal: obecne na Cloudflare, zostawione włączone tam, gdzie są nieszkodliwe, ale sprawdzone, bo domyślny opt-in oznacza, że mogą być włączone bez decyzji. Bez doczepionej obietnicy widoczności.
- llms.txt i llms-full.txt: publikowane, ale jako wpięte węzły systemu agent-discovery, nie jako samodzielny zakład, i uczciwie opisane w naszym własnym playbooku.
- OKF: zaszufladkowane jako warstwa wiedzy. Istotne wtedy, gdy będziemy podawać wyselekcjonowaną wiedzę do pipeline’u agentowego. To nie jest zmiana w serwowaniu serwisu.
- Warstwa akcji agenta, A2A, MCP, okolice WebMCP: świadoma inwestycja, już wdrożona pod
/.well-known/, i część tej całej debaty, której jesteśmy najpewniejsi.
Podsumowanie
Debata 2026 “HTML kontra Markdown dla agentów” wygląda na rozwidlenie drogi. Nie jest. Gdy raz rozdzielisz output agenta od serwowania strony i od warstwy wiedzy, trzy argumenty przestają sobie przeczyć i wszystkie wskazują w tę samą stronę. Serwuj czysty, semantyczny HTML i poprawne Schema, bo to jedyny sygnał, którego konsumpcję dokumentują obaj duzi crawlerzy. Obserwuj nowe formaty serwowania zamiast je gonić, bo żaden nie ma zmierzonego wpływu na cytowania. A energię na przyszłość wkładaj w warstwę akcji agenta, bo tam czytanie zamienia się w działanie.
Nie trafiliśmy tu, przewidując debatę. Trafiliśmy, budując na nudnym, udokumentowanym sygnale i traktując wszystko nowsze jako coś, co najpierw się mierzy. To cała metoda. Głośna część internetu kłóci się o format. Cicha, udokumentowana odpowiedź się nie zmieniła.
Jeśli chcesz szerszy obraz widoczności, nasz playbook widoczności w AI i LLM zbiera resztę dźwigni w kolejności priorytetów.
Ostatnia aktualizacja: 15 czerwca 2026.
