Markdown vs. HTML: na ile to sensowne dla GEO i widoczności w AI?

W ciągu ostatnich jedenastu dni zarejestrowaliśmy 9822 zapytania od 37 różnych botów AI na 4eck-media.de. Co rzuca się w oczy: 83 procent tych botów pobrało wersję Markdown naszych stron, a zaledwie 12 procent klasyczny HTML. Kto w 2026 roku poważnie mówi o GEO, a wciąż dostarcza tylko HTML, ten naszym zdaniem marnuje potężną dźwignię. W tym artykule pokazujemy, dlaczego tak jest, dlaczego Google nie chce o tym słyszeć, co właśnie wdraża Cloudflare i jak samodzielnie, w sensowny sposób, udostępnić Markdown na swojej stronie.

O co właściwie chodzi w Markdown – krótkie wyjaśnienie

GEO to skrót od Generative Engine Optimization. Chodzi o optymalizację stron internetowych pod kątem systemów wyszukiwania AI, takich jak ChatGPT, Claude, Perplexity czy AI Overviews w Google. Pytanie, które za tym stoi: jak sprawić, by moja treść trafiła czysto do odpowiedzi, którą model językowy przedstawia użytkownikowi?

Markdown to prosty format tekstowy. Wyobraźmy sobie, że piszemy list w Wordzie i chcemy coś pogrubić, dodać nagłówek albo utworzyć listę. Zwykle klikamy w tym celu małe ikony. W Markdown zamiast tego używamy kilku drobnych symboli bezpośrednio w tekście:

# Meine Überschrift     →  wird zu einer großen Überschrift
**wichtig**             →  wird zu fettem Text

To wszystko. Czysty tekst z kilkoma znakami specjalnymi. Człowiek może to bezpośrednio przeczytać, a komputer jednoznacznie zinterpretować. Dla porównania: gdy przeglądarka otwiera stronę, otrzymuje w odpowiedzi HTML. Wygląda to zazwyczaj tak:

<div class="container-fluid bg-white shadow-lg p-4">
  <header role="banner" data-track="hero">
    <h1 class="title-xl mb-3">Willkommen</h1>
  </header>
  <nav><ul class="menu"><li><a href="...">Home</a></li>...

Przeglądarka jest stworzona właśnie do tego gąszczu. Z kodu (markup) tworzy przyciski, menu, banery cookie, czcionki i kolory. Agent AI, taki jak ChatGPT, Claude czy Perplexity, ma znacznie trudniej. Chce wiedzieć, co faktycznie znajduje się w artykule. Nawigacja go nie interesuje, 14 skryptów śledzących również nie. Na typowej stronie HTML jest z grubsza 80 procent wizualnego opakowania i około 20 procent treści. Markdown dostarcza te 20 procent bezpośrednio.

Co pokazują nasze logi botów AI na 4eck-media.de

Od pewnego czasu śledzimy 160 znanych botów AI i User Agentów na naszej stronie. W okresie analizy od 5 do 16 maja 2026 roku rozkład wyglądał następująco:

Po wszystkich udanych dostarczeniach 83,3 procent wyszło jako Markdown, 12,5 procent jako HTML, a reszta rozkłada się na zwykły tekst, JSON i kilka kanałów XML. Inaczej mówiąc: boty LLM tam w sieci same bardzo wyraźnie komunikują swoimi nagłówkami, czego chcą. Chcą Markdown. Gdy tylko mogą go dostać, biorą go.

Równie pouczająca jest druga strona. Te boty w ciągu jedenastu dni nie wysłały w naszych logach ani jednego zapytania o Markdown: PetalBot (Huawei), Applebot, FacebookExternalHit, GoogleOther i AgentReadinessScanner. Nadal pobierają HTML. Kto więc chce obsłużyć boty, musi opanować oba formaty równolegle.

A trend wyraźnie zmierza w jednym kierunku. 5 maja byliśmy na poziomie 67 procent udziału Markdown dziennie. W drugim tygodniu maja wskaźnik wahał się między 86 a 94 procent. 16 maja byliśmy na poziomie 97 procent. Boty szybko uczą się, że strony obsługują Markdown, i odpowiednio przestawiają swoje zapytania.

Efekt uboczny: logowanie botów opłaca się podwójnie

Staranne logowanie wszystkich wejść botów AI przynosi dwa wnioski, które nie mają nic wspólnego z samą kwestią Markdown, ale już same uzasadniają nakład pracy na śledzenie.

Odzyskiwanie zapomnianych adresów URL ze starych danych treningowych

Boty AI regularnie kierują się do adresów URL na 4eck-media.de, do których od lat już aktywnie nie linkujemy. Nie pojawiają się ani w menu, ani w mapie strony, ani w linkach wewnętrznych. Mimo to boty o nie pytają, prawdopodobnie dlatego, że adresy te znajdują się w jakimś indeksie danych treningowych, użytym przy wcześniejszym tworzeniu modelu.

W logu te próby pojawiają się jako błędy 404, czasem także 500. I właśnie tu tkwi praktyczna dźwignia: widzimy pożądane adresy, których inaczej w ogóle nie mielibyśmy na radarze, i możemy skonfigurować dla nich czyste przekierowania 301 na pasujące, aktualne strony. W ten sposób przechwytujemy ruch, którego klasyczne narzędzia SEO, jak Search Console czy audyty mapy strony, w ogóle by nie wykryły, ponieważ źródło tych zapytań leży poza otwartą siecią – głęboko w treningowym snapshocie LLM-a. To rodzaj inżynierii wstecznej starych indeksów, która bez logowania botów pozostałaby po prostu niewidoczna.

Wykrywanie problemów z wydajnością z perspektywy botów

Drugi efekt dotyczy szybkości serwera. Gdy bot taki jak GPTBot czy ChatGPT-User zażąda strony i w wąskim oknie czasowym nie otrzyma pełnej odpowiedzi, przerywa. W logu ląduje to jako HTTP 499 (Client Closed Request) lub 504 (Gateway Timeout). Niezaładowane treści nie trafiają tym samym ani do puli treningowej, ani do puli retrieval. Państwa marka znika z późniejszej odpowiedzi AI, choć merytorycznie byłaby istotna.

W społeczności GEO krąży reguła kciuka mówiąca o progu przerwania na poziomie 500 do 700 milisekund. Liczba ta nie jest oficjalnie udokumentowana przez OpenAI czy Anthropic, wynika z obserwacji praktycznych. Mimo to jest wiarygodna, ponieważ leży dokładnie w obszarze przejściowym, w którym także klasyczne metryki wydajności sieci, takie jak Time to First Byte czy Core Web Vitals, wyznaczają różnicę między dobrym a złym doświadczeniem użytkownika. Jako reguła kciuka dla konfiguracji crawlerów AI jest więc użyteczną wskazówką. Odwołujemy się do tego progu również w naszym 4eck GEO-Framework dla widoczności i rekomendacji AI.

Konkretnie oznacza to dla Państwa witryny: kto częściej widzi w logu błędy 499 lub 504 od botów AI, ma problem z wydajnością, który z klasycznej analityki internetowej często w ogóle się nie ujawnia, ponieważ ludzie z reguły czekają dłużej niż boty. Buforowanie (caching), optymalizacja bazy danych i odchudzony output Markdown (patrz niżej) działają tu wszystkie trzy w tym samym kierunku.

Google mówi: niepotrzebne. Cloudflare mówi: obowiązkowe.

Google opublikował w kwietniu swój oficjalny przewodnik po optymalizacji pod generatywne funkcje AI. W sekcji „Mythbusting” pada dosłownie stwierdzenie, że nie potrzeba ani llms.txt, ani specjalnego znacznika (markup), ani dodatkowego wyjścia Markdown. Google mówi w sensie: zostańcie przy HTML, my to zrozumiemy.

Mała dygresja na marginesie: na stronach dokumentacji samego Google – dokładnie na tej stronie z zaleceniem przeciwko Markdown – tuż obok nagłówka znajduje się przycisk „Kopiuj stronę jako Markdown”. Google chętnie więc udostępnia własną dokumentację jako Markdown. Ale dla treści wszystkich innych miałoby to być zbędne. Znamienne.

Dlaczego to Cloudflare jest tu wagą ciężką

Przez sieć Cloudflare przechodzi około 22,7 procent wszystkich stron internetowych na świecie (stan na 16 maja 2026, źródło W3Techs). W usługach reverse proxy firma ma udział 83 procent. Tendencja nadal rosnąca. Kolejny co do wielkości dostawca, Amazon CloudFront, osiąga 1 do 2 procent. Gdy dostawca infrastruktury tej skali zajmuje stanowisko techniczne, dotyczy to istotnej części publicznej sieci.

Dzięki funkcji Markdown for Agents Cloudflare od lutego 2026 dostarcza na życzenie każdą stronę HTML bezpośrednio w Markdown. We własnej dokumentacji firma dodatkowo umieściła na samej górze baner z informacją, który krzyczy do botów wielkimi literami: STOP! If you are an AI agent or LLM, read this before continuing. This is the HTML version of a Cloudflare documentation page. Always request the Markdown version instead. HTML wastes context.

W tym samym banerze Cloudflare wyraźnie odsyła do plików llms.txt dla własnej dokumentacji. To dokładnie to, co Google w swoim fragmencie o obalaniu mitów ogłasza jako zbędne.

Dwie wagi ciężkie, dwie przeciwstawne wypowiedzi. Komu wierzyć?

Nasze stanowisko jest jednoznaczne: Cloudflare ma uczciwszy punkt widzenia. Google ma strategiczny własny interes w tym, by właściciele stron nie robili niczego, co ułatwia dystrybucję treści do innych systemów AI. Każdy plik Markdown, który ChatGPT czy Claude mogą sprawnie przetworzyć, to treść, która bez kliknięcia (click-through) w Google ląduje u konkurenta. Z perspektywy Google racjonalne jest framowanie tego jako „niepotrzebne”.

Nasze własne dane dość wyraźnie obalają to framowanie. 97 procent udziału Markdown w ostatnich dniach to nie jest statystyka przemawiająca za tezą „Markdown nic nie daje”.

Oprócz Markdown aktywowaliśmy u siebie także serwer MCP i llms.txt oraz dodaliśmy do robots.txt dyrektywy Content Signal dla ai-train, search i ai-input, które zaleca Cloudflare. Jedynym efektem ubocznym jest to, że PageSpeed Insights daje nam teraz w SEO tylko 92 zamiast 100, ponieważ nie uwzględnia jeszcze tych dyrektyw.

Dlaczego Markdown ma technicznie tak wiele sensu

Cloudflare podał w swoim wpisie blogowym konkretną liczbę: jego własny artykuł z ogłoszeniem potrzebuje 16 180 tokenów w HTML i tylko 3150 tokenów w Markdown – oszczędność około 80 procent. W praktyce jest to istotne dlatego, że modele językowe mają tylko ograniczone okno kontekstu (context window). Im mniej tokenów zużywa dokument, tym więcej mieści się łącznie w kontekście i tym czystsza jest odpowiedź. Dokument HTML wlecze za sobą mnóstwo balastu nieistotnego dla znaczenia treści: kod nawigacji, baner cookie, znaczniki skryptów, piksele śledzące, zagnieżdżone diwy-opakowania, generyczne klasy.

W Markdown wszystko to odpada. To, co zostaje, to treść plus struktura. Dokładnie to, czego LLM potrzebuje do odpowiedzi na pytanie użytkownika.

Markdown to język ojczysty modeli

Często pomijana właściwość: modele językowe, takie jak GPT, Claude i Gemini, same wewnętrznie produkują Markdown. Gdy ChatGPT pokazuje w odpowiedzi pogrubienie, wyliczenie czy blok kodu, z modelu wychodzi pierwotnie składnia Markdown, którą klient czatu następnie wizualnie renderuje. Kto dostarcza modelowi input w Markdown, zwraca się do niego w jego własnym języku roboczym. Ma to dwa efekty: model oszczędza sobie wewnętrzne tłumaczenie HTML na reprezentację, którą i tak z powrotem przesuwa w stronę Markdown. A formatowania rzadziej się gubią lub rzadziej są błędnie interpretowane.

Markdown daje się czysto cytować

Systemy odpowiadające AI cytują Państwa treści niemal zawsze we fragmentach. Akapit tu, lista punktowana tam, może dwa zdania z dłuższego tekstu. W Markdown każdy fragment pozostaje zrozumiały sam w sobie. Akapit to akapit, link to link, wyliczenie pozostaje wyliczeniem. W HTML każde cięcie rozrywa się przez zagnieżdżone znaczniki, brakuje elementów zamykających, a model musi zgadywać lub naprawiać.
Z perspektywy GEO jest to być może najmocniejszy argument za Markdown. Czysta cytowalność zwiększa prawdopodobieństwo, że Państwa treści zostaną w ogóle w pełni odtworzone, z poprawnie zachowanymi linkami z powrotem do strony. Okaleczone fragmenty częściej trafiają do filtra modeli i w ogóle nie pojawiają się w finalnej odpowiedzi. Widoczność w maszynach odpowiadających rozstrzyga się dokładnie w tym punkcie.

Budżet crawlowania i przepustowość

Oszczędność tokenów przekłada się niemal bezpośrednio na przepustowość. Przeciętna strona HTML w sieci waży według HTTP Archive Web Almanac obecnie kilkaset kilobajtów, z tendencją rosnącą. Wariant Markdown tej samej strony ląduje zazwyczaj na poziomie 5 do 20 kilobajtów. To odciąża Państwa serwer, oszczędza koszty ruchu i zmniejsza obciążenie, które crawlery AI generują na Państwa infrastrukturze.

W klasycznym SEO mówimy w przypadku Google o budżecie crawlowania (crawl budget), czyli o tym, ile stron Googlebot pobiera z witryny w danym okresie. W przypadku crawlerów AI jest podobnie, tylko zdecydowanie agresywniej. Już w naszych logach meta-externalagent wykonał w jedenaście dni 3481 zapytań, gptbot kolejne 728, a chatgpt-user 1404. Jeśli te boty mogą wziąć Markdown, pobierają na zapytanie około 80 procent mniej danych. Im więcej botów AI puka do Państwa drzwi, tym bardziej ten efekt się sumuje.

Wynikają z tego trzy mierzalne korzyści dla Państwa widoczności:

• Systemy AI mogą przetworzyć więcej Państwa treści za jednym razem, ponieważ dokument Markdown jest bardziej odchudzony.
• Jakość odpowiedzi opartych na Państwa treściach rośnie, bo model musi odfiltrować mniej zbędnych danych.
• Państwa hosting pozostaje lżejszy, ponieważ crawlery generują mniejsze obciążenie. Kto jest cytowany częściej i czyściej, zyskuje zasięg w maszynach odpowiadających, nie płacąc za to większym ruchem serwerowym.

Jak wdrożyć Markdown na stronie WordPress

Wyjście Markdown na 4eck-media.de zaimplementowaliśmy samodzielnie, a nie przez Cloudflare. Powód jest prosty: chcieliśmy mieć pełną kontrolę nad rezultatem i żadnej usługi między naszymi treściami a botami. Kto i tak korzysta z Cloudflare, może dołączyć tę funkcję jednym przełącznikiem. Kto chce wziąć sprawę we własne ręce – oto plan działania.

Mechanizm: HTTP Content Negotiation

Każdy bot, który żąda strony, wysyła nagłówek Accept. Zawiera on informację, jakie formaty potrafi przetworzyć. Klasyczna przeglądarka mówi na przykład Accept: text/html. Nowoczesny bot LLM, jak ChatGPT, mówi Accept: text/markdown, text/html. Zadaniem jest odczytać ten nagłówek i w zależności od potrzeby dostarczyć HTML albo Markdown.

Krok 1: ustawić hook w WordPress

Poniższy snippet należy umieścić w pliku functions własnego motywu lub – jeszcze lepiej – we własnej miniwtyczce:

add_action('template_redirect', function () {
    if (!is_singular()) {
        return;
    }

    $accept = $_SERVER['HTTP_ACCEPT'] ?? '';
    if (!str_contains($accept, 'text/markdown')) {
        return;
    }

    $post = get_queried_object();
    if (!$post instanceof WP_Post) {
        return;
    }

    header('Content-Type: text/markdown; charset=utf-8');
    header('Vary: Accept');
    header('X-Content-Format: markdown');

    echo render_post_as_markdown($post);
    exit;
});

To są drzwi wejściowe. Gdy tylko bot z text/markdown w nagłówku Accept zażąda pojedynczej strony (artykuł blogowy, landing page, własny typ wpisu), kod uruchamia się i dostarcza Markdown zamiast HTML. get_queried_object() jest w hooku template_redirect pewniejszym sposobem dotarcia do bieżącego wpisu, ponieważ globalna zmienna $post nie jest w tym miejscu jeszcze niezawodnie ustawiona.

Krok 2: przekonwertować HTML na Markdown

Do samej konwersji polecamy bibliotekę league/html-to-markdown. Zainstalowaną przez Composer:

composer require league/html-to-markdown

Funkcja konwertująca wygląda wówczas tak:

use League\HTMLToMarkdown\HtmlConverter;

function render_post_as_markdown(WP_Post $post): string {
    $converter = new HtmlConverter([
        'strip_tags'    => true,
        'remove_nodes'  => 'script style nav footer aside',
        'header_style'  => 'atx',
    ]);

    $title    = wp_strip_all_tags($post->post_title);
    $url      = get_permalink($post);
    $updated  = get_the_modified_date('c', $post);
    $content  = apply_filters('the_content', $post->post_content);
    $markdown = $converter->convert($content);

    // Title als JSON-String escapen, das ist auch gueltiges YAML
    $frontmatter  = "---\n";
    $frontmatter .= 'title: ' . json_encode($title, JSON_UNESCAPED_UNICODE) . "\n";
    $frontmatter .= "url: {$url}\n";
    $frontmatter .= "updated: {$updated}\n";
    $frontmatter .= "---\n\n";

    return $frontmatter . "# {$title}\n\n" . $markdown;
}

Front-matter na górze (blok między kreskami) jest opcjonalny, ale bardzo zalecany. Boty mogą odczytać z niego metadane bez konieczności parsowania treści. Tytuł przepuszczamy przez json_encode, aby cudzysłowy, dwukropki czy znaki specjalne nie wytrąciły parsera YAML z rytmu.

Krok 3: nie zapomnieć o buforowaniu

Strony WordPress z page cache (WP Rocket, LiteSpeed, Varnish) muszą respektować nagłówek Vary: Accept. W przeciwnym razie cache dostarcza wszystkim botom tę samą wersję, niezależnie od tego, jaki nagłówek Accept przychodzi. W większości wtyczek cachujących można to włączyć w ustawieniach. W razie wątpliwości warto porozmawiać bezpośrednio z hostingodawcą.

Krok 4 (opcjonalnie): udostępnić równolegle adres .md

Niektóre crawlery treningowe ignorują nagłówek Accept albo wysyłają go niepoprawnie. Kto chce uwzględnić również je, może udostępnić drugi adres URL, czyli /blog/moj-wpis/ dodatkowo dostępny jako /blog/moj-wpis/index.md. Czysto da się to zrobić w WordPress przez add_rewrite_rule z własnym query-var:

add_filter('query_vars', function ($vars) {
    $vars[] = 'as_markdown';
    return $vars;
});

add_action('init', function () {
    add_rewrite_rule(
        '^(.+?)/index\.md/?$',
        'index.php?name=$matches[1]&as_markdown=1',
        'top'
    );
});

W hooku z kroku 1 wystarczy wtedy dodatkowo sprawdzić parametr zapytania (query parameter):

$wants_markdown =
       str_contains($_SERVER['HTTP_ACCEPT'] ?? '', 'text/markdown')
    || (int) get_query_var('as_markdown') === 1;

Po dodaniu reguły rewrite należy raz zapisać w ustawieniach WordPress permalinki, aby WordPress przejął regułę.
W naszych logach istotne boty AI pobierają swoją treść niemal w całości przez nagłówek Accept. Krok 4 jest więc dodatkiem, a nie koniecznością.

Krok 5: opcjonalnie opublikować llms.txt

Plik llms.txt w katalogu głównym domeny (porównywalny z robots.txt) wymienia najważniejsze treści strony w formie, którą LLM-y dobrze konsumują. Cloudflare otwarcie to zaleca, Google twierdzi, że jest zbędne. Nasza rekomendacja: warto to zrobić – nakład pracy jest niewielki, szkoda zerowa, a możliwa korzyść realna.

Co z ryzykiem?

Często pojawia się uzasadnione pytanie: jeśli udostępniam Markdown, czy nie ułatwiam botom kradzieży mojej treści?

Kto chce zeskrobać (scrape) Państwa stronę, i tak to zrobi. Z HTML idzie to równie dobrze, tylko nieco drożej. Markdown nie zapobiega kradzieży, czyni ją jedynie wydajniejszą. Co można zrobić zamiast tego:

• Po pierwsze: za pomocą nagłówka Content-Signal w odpowiedzi jasno określić, co jest dozwolone, a co nie. Cloudflare używa do tego frameworka Content Signals. Boty, które się do tego stosują, respektują Państwa wytyczne.
• Po drugie: za pomocą robots.txt wykluczyć określone boty. Dotyczy to HTML tak samo jak Markdown.
• Po trzecie: pamiętać, że właściwym celem jest widoczność. Kto nie istnieje w maszynach odpowiadających, ma większy problem niż ktoś, czyje treści są tam czysto cytowane.

Czy powinienem stosować Markdown na swojej stronie?

Nasze dane pokazują to jednoznacznie: boty AI chcą Markdown, aktywnie o niego pytają, a ich udział rośnie z tygodnia na tydzień. Kto udostępnia swoje treści równolegle jako Markdown, daje botom dokładnie ten format, który mogą sprawnie przetworzyć. Rezultatem są czystsze cytaty, mniejsze obciążenie własnej infrastruktury i lepsza pozycja wyjściowa wobec kolejnej fali narzędzi agentowych. Czy wyniknie z tego również większa widoczność w ChatGPT, Perplexity, Claude i Meta AI, pozostaje kwestią otwartą. Zakładam, że tak, ale nie mogę jeszcze przedstawić na to jednoznacznych dowodów. Wiem tylko, że co tydzień otrzymujemy nowe zapytania od klientów z regionów całego obszaru DACH, które jeszcze w zeszłym roku nigdy by do nas nie trafiły.

Oficjalne zalecenie Google, by to wszystko ignorować, jest naszym zdaniem motywowane strategicznie. Mówi więcej o własnej sytuacji konkurencyjnej Google niż o rzeczywistości po stronie botów. Kto chce wykorzystać tę dźwignię, nie powinien dać się tym zniechęcić.

Wdrożenie jest niezbyt skomplikowane. Wtyczka, biblioteka, kilka godzin pracy programistycznej. U klientów Cloudflare wystarczy przełącznik. Kto wdroży to samodzielnie, ma kontrolę i może ukształtować wyjście Markdown dokładnie tak, jak jest to najsensowniejsze dla własnych treści.

Markdown jest naszym zdaniem nadchodzącym standardowym językiem między stronami internetowymi a systemami AI. Kto jest wcześnie, korzysta dłużej. Kto czeka, aż Google oficjalnie to potwierdzi, płaci kosztem utraconych szans.

Źródła:

• Google Search Central, AI Optimization Guide

• Cloudflare Blog, Introducing Markdown for Agents

• Cloudflare Docs, Markdown for Agents Reference

• Content Signals Framework

• league/html-to-markdown na GitHubie

• W3Techs, udział rynkowy Cloudflare

• HTTP Archive Web Almanac, Page Weight

O danych: 9822 wejścia botów z naszego własnego systemu logowania na 4eck-media.de, okres od 5 do 16 maja 2026, 37 aktywnych botów spośród 160 śledzonych User Agentów.