Markdown czy HTML dla AI: co naprawdę pokazują testy z 2026 roku

Dlaczego pytanie wróciło w połowie 2026 roku

Spór ożył w maju, kiedy Andrej Karpathy zasugerował coś wbrew panującej modzie: poproś model o odpowiedź w HTML, a potem otwórz ją w przeglądarce. Tydzień później Thariq Shihipar, inżynier z zespołu Claude Code w Anthropicu, opisał, dlaczego przestał używać markdown przy generowaniu treści przez AI. Dwóch ludzi blisko źródła; dwa przeciwne wnioski.

Część branży poszła jeszcze dalej. Salesforce Agentforce przetwarza ponad 4 miliony sesji rocznie i renderuje odpowiedzi jako karuzele czy przyciski wyboru, nie jako gołe markdown. Microsoft Copilot Studio robi to przez Adaptive Cards, Google testuje protokół A2UI. Wniosek jest prosty, choć niewygodny dla fanów jednego, uniwersalnego formatu: surowy tekst (markdown czy HTML, wszystko jedno) coraz częściej jest tylko warstwą pośrednią, którą system i tak przerabia na coś innego.

Dla twojej strony WordPress liczy się jednak inny, znacznie bardziej przyziemny problem: czy crawler ChatGPT, Perplexity albo Google AI Overview odwiedzi ją chętniej, jeśli dostanie markdown zamiast HTML. Tu właśnie wchodzi test Profound.

Co pokazał test Profound na 381 stronach

Profound podzielił 381 stron z sześciu serwisów na dwie grupy. Jedna prezentowała botom AI normalny HTML, identyczny z tym, co widzi człowiek. Druga, w tym samym czasie, serwowała botom czystą wersję markdown tej samej treści. Ludzie zawsze widzieli HTML, więc żadny użytkownik nie zauważył różnicy. Po trzech tygodniach pomiaru strony z markdown zarejestrowały medianę jednej dodatkowej wizyty bota. Kierunkowo plus; statystycznie nic.

Wcześniejszy eksperyment OtterlyAI poszedł jeszcze dalej i sprawdził modny trik z plikiem llms.txt. Wynik? W 90 dni plik ten przyciągnął zaledwie 0,1% ruchu botów AI – trzy razy mniej niż przeciętna strona z treścią na tej samej domenie. Zero wizyt, zero wpływu na cytowania. Nie jest to argument przeciw markdownowi jako takiemu; jest to argument przeciw traktowaniu publikacji plików .md jako samodzielnej taktyki GEO.

Czemu Google ostrzega przed osobnymi stronami dla robotów

Tworzenie odrębnej wersji strony wyłącznie dla botów AI, różnej od tej, którą widzi człowiek, łamie podstawową zasadę polityki cloakingu Google: ta sama treść dla każdego odwiedzającego. Mueller i Canel ostrzegli przed tym wprost na początku 2026 roku, a SALT.agency dodało, że okrojenie strony do markdown często usuwa strukturę, której boty potrzebują, żeby zrozumieć relacje między podstronami.

Mueller ma rację co do jednego: modele trenowane na zwykłym wyglądzie sieci radzą sobie z HTML bez problemu, od zawsze. Nie znaczy to jednak, że markdown jest bezużyteczny – po prostu nie powinien istnieć jako osobny, indeksowalny adres URL, który Google może uznać za próbę pokazania mu czegoś innego niż człowiekowi.

Bezpieczny wariant to content negotiation: ten sam URL, inna reprezentacja w zależności od nagłówka żądania (na przykład Accept albo specjalny nagłówek), bez tworzenia nowego, osobno linkowanego adresu. Wersję markdown oznaczasz wtedy jako nieindeksowalną przez X-Robots-Tag, więc Google ją widzi, ale traktuje jako narzędziową, nie jako konkurencyjną stronę.

Gdzie markdown wygrywa: tokeny i RAG

Markdown wygrywa nie w SERP-ach, a w portfelu. Analiza Cloudflare wykazała, że wersja markdown typowego wpisu blogowego zajmuje około 80% mniej tokenów niż jej odpowiednik w HTML. Przy tysiącach zapytań dziennie do własnego chatbota czy pipeline’u RAG ta różnica przekłada się na realne pieniądze, nie na abstrakcyjny wskaźnik.

W systemach RAG dane są jeszcze wyraźniejsze: ustrukturyzowany markdown podnosił dokładność odpowiedzi o nawet 35%, jednocześnie ścinając koszt tokenów o 20-30%. Przy zadaniach polegających na wyciąganiu danych z tabel modele oparte na GPT radziły sobie lepiej z markdown (około 60,7% dokładności) niż z HTML (53,6%).

Nie każdy zysk jest tak spektakularny w praktyce. Przy krótkich tekstach do 500 słów różnica w koszcie bywa kosmetyczna, a sam efekt zależy od tego, jak „brudny” jest twój HTML – strona z dziesiątkami zagnieżdżonych divów i inline’owych stylów straci więcej na konwersji niż czysty, semantyczny markup.

Wniosek: markdown ma sens jako format wejściowy do twoich własnych narzędzi (chatbot na stronie, wewnętrzny RAG, pipeline w n8n), nie jako publiczna, indeksowalna alternatywa dla strony WordPress.

Jak wdrożyć to bezpiecznie: cztery kroki bez ryzyka cloakingu

Sposób, który nie wzbudzi podejrzeń Google, a jednocześnie daje korzyść kosztową tam, gdzie ona faktycznie istnieje, wygląda tak:

1. Zostaw jeden kanoniczny URL z czystym, semantycznym HTML – to wersja, którą widzi i człowiek, i każdy crawler bez specjalnego traktowania.
2. Generuj markdown na żądanie, na tym samym adresie, w zależności od nagłówka żądania (na przykład Accept: text/markdown), zamiast publikować osobny, linkowalny plik .md.
3. Oznacz wersję markdown jako nieindeksowalną przez nagłówek X-Robots-Tag: noindex, żeby było jasne, że to narzędziowa reprezentacja, nie konkurencyjna treść.
4. Wymuszaj kodowanie UTF-8 w nagłówku Content-Type: text/markdown; charset=utf-8 – bez tego polskie znaki diakrytyczne (ą, ę, ł, ż) mogą zamienić się w mojibake, bo serwer domyślnie zgaduje ISO-8859-1.

Ten ostatni punkt brzmi jak detal techniczny, ale dla polskiego contentu jest praktyczny: bez wymuszonego UTF-8 strona o „łatwych zwrotach” może w wersji markdown wyglądać jak ciąg przypadkowych znaków, co dla bota oznacza realną utratę jakości danych wejściowych.