Az utóbbi egy-két évben egyre több dokumentációs oldalon látni, hogy ha az URL végére odaírod a .md kiterjesztést, a formázott weboldal helyett tiszta markdown-szöveget kapsz. Ez az AI-ügynököknek és fejlesztői eszközöknek készül, amelyek így menü, sütisáv és szkriptek nélkül, kevesebb tokenből olvassák be a lényeget. Ebben a cikkben megnézzük, mikor éri meg ezt bevezetni egy vállalkozás oldalán, hogyan kapcsolódik az llms.txt-hez, és hogyan oldd meg úgy, hogy a Google ne lásson belőle duplikált tartalmat.
A szövegben háromféle jelölést használunk. Hivatalosan igazolt, ha szabvány vagy a szolgáltató saját dokumentációja mondja ki. Saját tapasztalat, ha a munkánk során láttuk. Szakmai feltételezés, ha logikus következtetés, de nincs rá nyilvános bizonyíték.
Mi az a markdown-változat, és kinek szól valójában?
A markdown-változat ugyanannak az oldalnak a tartalma, sallangok nélkül, egyszerű szövegformátumban, elsősorban gépi olvasóknak. A címsorok # jelekkel, a listák kötőjelekkel, a linkek [szöveg](url) alakban jelennek meg. Ember is el tudja olvasni, de nem neki tervezték.
A célközönség három csoport:
- AI-ügynökök, amelyek a felhasználó nevében böngésznek, összehasonlítanak, információt gyűjtenek.
- Fejlesztői eszközök, például kódszerkesztőkbe épített asszisztensek, amelyek dokumentációt húznak be a kontextusba.
- Saját RAG-rendszerek, vagyis cégek belső chatbotjai, amelyek a te oldaladat is forrásként használhatják.
A klasszikus keresőrobotok, például a Googlebot, ma is a HTML-t dolgozzák fel, és képesek JavaScriptet is renderelni. Nekik a markdown nem ad pluszt. (Szakmai feltételezés, amely a Google nyilvános dokumentációjával összhangban van.)
Hogyan kapcsolódik a markdown-változat az llms.txt-hez?
Az llms.txt egy tartalomjegyzék, a markdown-változatok pedig azok a fejezetek, amelyekre ez a tartalomjegyzék mutat. A kettő együtt adja ki azt, amit a javaslat szerzői elképzeltek.
Az llms.txt javaslatot Jeremy Howard (Answer.AI) tette közzé 2024 szeptemberében. A javaslat két dolgot ír le. Az egyik a gyökérkönyvtárban álló /llms.txt fájl, egy markdown formátumú áttekintés a legfontosabb oldalak linkjeivel. A másik, hogy a fontos oldalaknak legyen tiszta markdown-párja ugyanazon az URL-en, .md végződéssel. (Hivatalosan igazolt, a javaslat szövege szerint. Ez egy közösségi javaslat, nem W3C- vagy IETF-szabvány.)
A gyakorlatban ez azt jelenti, hogy az llms.txt-ben érdemes rögtön a .md változatokra linkelni. Egy ügynök így az áttekintésből egy lépésben eljut a tiszta tartalomhoz, és nem kell HTML-t takarítania.
Fontos tisztázni, mit nem tud az llms.txt. A Google képviselői nyilvánosan jelezték, hogy a Google Keresés nem használja, és a nagy AI-szolgáltatók sem erősítették meg hivatalosan, hogy rendszeresen olvasnák. (Hivatalos nyilatkozat a Google részéről, a többi szolgáltatónál a megerősítés hiánya a tény.) Saját tapasztalatunk az, hogy a szervernaplókban az llms.txt-re és a .md fájlokra érkező kérések túlnyomó része ma fejlesztői eszközöktől és kísérleti ügynököktől jön, nem a nagy keresőrobotoktól.
Mikor érdemes markdown-változatot kiszolgálni, és mikor felesleges?
Akkor éri meg, ha az oldaladon sok, sűrű, gyakorlati információ van, amit valaki egy AI-eszközzel szeretne feldolgozni. Egy ötoldalas bemutatkozó weboldalnál a ráfordítás jó eséllyel nem térül meg.
Érdemes lehet, ha:
- szoftvert, API-t vagy integrációt kínálsz, és van dokumentációd,
- részletes tudásbázisod, GYIK-oldalad vagy szakmai cikkgyűjteményed van,
- B2B-szolgáltatást árulsz, ahol a vevő AI-asszisztenssel hasonlít össze ajánlatokat,
- a HTML-oldalaid nehezek (sok szkript, page builder, beágyazott elemek), és a tartalom nehezen nyerhető ki belőlük.
Kevésbé érdemes, ha:
- helyi szolgáltató vagy, és a vevőid a Google Cégprofilon vagy telefonon keresnek,
- a tartalom főleg kép, videó vagy interaktív kalkulátor,
- nincs kapacitásod a karbantartásra, mert egy elavult markdown-változat rosszabb, mint ha egyáltalán nem lenne.
Saját tapasztalat, hogy a jól strukturált, szemantikus HTML (rendes címsor-hierarchia, valódi listák, kevés felesleges beágyazás) már önmagában sokat segít az AI-eszközöknek. Ha az oldalad ilyen, a markdown-változat csak kisebb pluszt ad. Ha az oldalad egy page builderrel épült, és a forráskódban a szöveg tíz egymásba ágyazott div mélyén ül, a különbség nagyobb lehet. (Ez utóbbi szakmai feltételezés.)
.md végződés vagy tartalomegyeztetés, melyiket válaszd?
A .md végződés egyszerűbb és könnyebben tesztelhető, a tartalomegyeztetés elegánsabb, de több buktatója van. Kezdésnek a .md végződést ajánljuk.
A .md végződéses megoldás
Minden fontos oldalnak lesz egy párja, például a /szolgaltatasok/weboldal-karbantartas/ mellett a /szolgaltatasok/weboldal-karbantartas.md. Előnye, hogy külön URL, így naplóban, böngészőben és llms.txt-ben is egyértelműen hivatkozható. Hátránya, hogy minden oldalhoz plusz URL keletkezik, amit kezelni kell a duplikáció szempontjából.
A tartalomegyeztetéses megoldás
Ugyanazon az URL-en a szerver a kérés Accept fejléce alapján dönt. Ha a kliens Accept: text/markdown fejlécet küld, markdownt kap, egyébként HTML-t. A HTTP-szabvány (RFC 9110) ezt pontosan leírja, és a text/markdown médiatípust az RFC 7763 rögzíti. (Hivatalosan igazolt.)
Itt két dologra kell figyelni. A válaszba kell a Vary: Accept fejléc, különben egy gyorsítótár (CDN, cache-bővítmény) a markdownt kiszolgálhatja egy böngészős látogatónak is, vagy fordítva. A másik, hogy ma nem tudható biztosan, mely ügynökök küldenek ilyen fejlécet. Szakmai feltételezés, hogy a fejlesztői eszközök egy része már kéri, a legtöbb általános célú robot viszont nem.
A kettő kombinálható. A .md végződés a biztos út, a tartalomegyeztetés pedig kényelmi ráadás azoknak a klienseknek, amelyek kérik.
Milyen canonical és noindex beállítás kell, hogy ne legyen duplikáció?
A .md fájl HTTP-válaszába tegyél egy Link fejlécet, amely canonicalként a HTML-oldalra mutat. A noindexet csak akkor vedd elő, ha a markdown-változat ennek ellenére megjelenik a találatok között.
A Google dokumentációja szerint a nem HTML-dokumentumoknál a canonical HTTP-fejlécben is megadható, és a robots-utasítások (például noindex) az X-Robots-Tag fejlécben adhatók át. (Hivatalosan igazolt, Google Search Central.) Egy jól beállított válasz fejlécei így néznek ki:
Content-Type: text/markdown; charset=utf-8Link: <https://example.hu/szolgaltatasok/weboldal-karbantartas/>; rel="canonical"
Miért nem mindkettő egyszerre? A Google a duplikált URL-ek összevonásáról szóló útmutatójában azt írja, hogy egy oldalon belüli canonical kiválasztására ne a noindexet használd. A canonical azt mondja, hogy ez a másik oldal másolata, a noindex azt, hogy ezt az oldalt hagyd ki. A kettő együtt ellentmondásos jelzés lehet. (Az útmutató hivatalos, a konkrét .md-esetre vonatkozó értelmezés szakmai feltételezés.)
Saját gyakorlatunkban ezért a canonical az alapbeállítás. Ha a Search Console-ban azt látod, hogy a .md URL-ek mégis indexelt oldalként jelennek meg, akkor válts X-Robots-Tag: noindex fejlécre.
Két tipikus hiba, amit kerülj el:
- Robots.txt tiltás. Ha a
Disallow: /*.md$sort beírod, a robotok a canonical és a noindex fejlécet sem látják, és pont az ügynökök nem érik el a tartalmat, akiknek készült. - A .md URL-ek a sitemapben. Az oldaltérképbe csak a kanonikus HTML-oldalak valók. A .md változatokra az llms.txt mutasson.
Hogyan maradjon szinkronban a markdown a HTML-változattal?
Úgy, hogy a markdown soha nem kézzel írt másolat, hanem ugyanabból az adatbázis-tartalomból készül, kérésre vagy mentéskor. Amint két külön szöveg él, az egyik előbb-utóbb elavul.
Három bevált elv:
- Egy forrás. WordPressnél a bejegyzés tartalma (
post_content) a forrás, a HTML és a markdown is ebből készül. - Gyorsítótár-ürítés mentéskor. Ha a markdownt gyorsítótárazod, a
save_posteseménynél töröld az adott oldal cache-ét. - Dátum a fájlban. A markdown elejére kerüljön a cím, a kanonikus URL és az utolsó módosítás dátuma. Ebből az ügynök és te is látod, mennyire friss a tartalom.
Ellenőrzésként érdemes havonta lefuttatni egy egyszerű összevetést, ami néhány fontos oldalnál letölti a HTML-t és a .md-t, kinyeri a szöveget, és jelzi, ha jelentős eltérés van. Saját tapasztalat, hogy a hibák többsége nem a szövegben, hanem a kimaradt elemekben jelentkezik. Egy shortcode-dal vagy page builder modullal beszúrt táblázat, árlista vagy GYIK könnyen hiányzik a markdownból, mert nem a post_content része.
Hogyan vezesd be lépésről lépésre egy WordPress-oldalon?
Kevés oldallal, tesztkörnyezetben kezdd, a fejléceket ellenőrizd, és csak utána bővítsd. Az alábbi lépéssor egyedi kóddal dolgozik. Bővítmény is létezik erre a célra, de azoknál is ugyanezeket a pontokat kell ellenőrizni.
- Válaszd ki az oldalakat. Kezdd 10-30 olyan oldallal, amelyek a legtöbb érdemi információt hordozzák (szolgáltatásleírások, GYIK, tudásbázis-cikkek).
- Készíts mentést, és dolgozz staging oldalon. Az átírási szabályok hibája az egész oldal elérhetőségét érintheti.
- Vegyél fel átírási szabályt és lekérdezési változót. Egy egyedi bővítményben vagy a gyerektéma
functions.phpfájljában például így:add_rewrite_rule('^(.+?)\.md$', 'index.php?pagename=$matches[1]&md=1', 'top');ésadd_filter('query_vars', fn($v) => array_merge($v, ['md']));. Bejegyzéseknél a permalink-szerkezettől függően más szabály kell. - Mentsd újra a permalinkeket. A Beállítások, Közvetlen hivatkozások oldalon egy mentés frissíti az átírási szabályokat.
- Szolgáld ki a markdownt. A
template_redirecthorogban, ha amdváltozó be van állítva, alakítsd át a tartalmat egy HTML-markdown konverter könyvtárral (példáulleague/html-to-markdown), és küldd el a fejlécekkel:header('Content-Type: text/markdown; charset=utf-8');ésheader('Link: <' . get_permalink() . '>; rel="canonical"');, utánaexit;. - Futtasd le előtte a shortcode-okat. Konvertálás előtt az
apply_filters('the_content', ...)hívással dolgozd fel a tartalmat, különben a shortcode-ok nyers formában maradnak. - Ellenőrizd parancssorból. A
curl -I https://example.hu/oldal.mdparanccsal nézd meg, hogy 200-as kódot,text/markdowntípust és helyes canonical fejlécet kapsz-e. - Frissítsd az llms.txt-t. A fájlban a kiválasztott oldalak .md változataira linkelj, rövid leírással.
- Figyeld a Search Console-t és a naplót. Két-négy hét után nézd meg, hogy a .md URL-ek nem jelentek-e meg indexelt oldalként, és kik kérik le őket.
Ha cache-bővítményt vagy CDN-t használsz, győződj meg róla, hogy a .md URL-eket a HTML-től elkülönítve tárolja, tartalomegyeztetésnél pedig figyelembe veszi a Vary: Accept fejlécet.
Hol tart ma valójában a gyakorlat?
Őszintén szólva a markdown-változat ma egy korai, főleg fejlesztői körökben elterjedt gyakorlat, amelynek a vállalkozói weboldalakra gyakorolt hatása nincs igazolva.
Ami tény. Több ismert dokumentációs platform és fejlesztői cég kínál .md változatot vagy llms.txt fájlt, és egyes dokumentációs rendszerek ezt alapból generálják. (Nyilvánosan ellenőrizhető megfigyelés.) Ami nem tény, az az, hogy a ChatGPT, a Gemini, a Claude vagy a Perplexity keresési funkciói előnyben részesítenék az ilyen oldalakat. Ezt egyik szolgáltató sem jelentette be hivatalosan.
Saját tapasztalatunk az, hogy magyar KKV-oldalakon a .md kérések száma ma elenyésző az összes robotforgalomhoz képest. Szakmai feltételezésünk szerint ez az ügynökalapú böngészés terjedésével nőhet, de hogy mennyire és milyen ütemben, azt senki nem tudja megbízhatóan megmondani.
Emiatt mi úgy kezeljük, mint egy olcsó, alacsony kockázatú kísérletet azoknál az oldalaknál, ahol a tartalom sűrű és gyakorlati, és ahol a technikai háttér rendben van. Nem helyettesíti a jó szerkezetű HTML-t, a strukturált adatokat és a valódi, hasznos tartalmat, és nem garantál AI-említést.
Ellenőrzőlista bevezetés előtt és után
- Van legalább 10 oldal, amelyik érdemi, sűrű információt hordoz?
- A markdown ugyanabból a forrásból készül, mint a HTML?
- A válasz típusa
text/markdown; charset=utf-8? - A
Linkfejlécben a canonical a HTML-oldalra mutat? - A .md URL-ek kimaradtak a sitemapből, és nincsenek tiltva robots.txt-ben?
- Tartalomegyeztetésnél ott van a
Vary: Acceptfejléc? - A shortcode-ok és page builder modulok tartalma megjelenik a markdownban?
- Az llms.txt a .md változatokra linkel?
- Van havi összevetés a HTML és a markdown között?
Források és további olvasnivalók
- Google Search Central, Duplikált URL-ek összevonása és a canonical megadása
- Google Search Central, Robots meta címke és X-Robots-Tag HTTP-fejléc
- llms.txt javaslat (llmstxt.org, Answer.AI)
- IETF RFC 7763, The text/markdown Media Type
- IETF RFC 9110, HTTP Semantics (tartalomegyeztetés, Vary fejléc)
- WordPress Developer Resources, Rewrite API és template_redirect
- OpenAI dokumentáció, az OpenAI robotjai (GPTBot, OAI-SearchBot)
- A markdown-változat elsősorban ügynököknek és fejlesztői eszközöknek szól, a Google rangsorolására nincs igazolt hatása.
- Az llms.txt javaslat maga ajánlja, hogy a fontos oldalaknak legyen .md végződésű párja, így a kettő egymásra épül.
- Duplikáció ellen a legtisztább megoldás a HTTP Link fejlécben megadott canonical, amely a HTML-oldalra mutat.
- A szinkron akkor biztos, ha a markdown nem kézzel írt másolat, hanem a WordPress-tartalomból kérésre generált kimenet.
- Robots.txt-ben ne tiltsd a .md fájlokat, mert akkor pont azok az ügynökök nem érik el, akiknek készültek.
Gyakori kérdések
Rangsorolási előnyt ad a Google-ben a markdown-változat?
Nincs rá hivatalos megerősítés. A Google a HTML-oldalakat dolgozza fel, a markdown-változat elsősorban AI-ügynököknek és fejlesztői eszközöknek szól.
Duplikált tartalomnak számít a .md változat?
Lehet belőle duplikáció, ha nincs jelölve. A HTTP Link fejlécben megadott canonical, amely a HTML-oldalra mutat, jelzi a Google-nek, melyik az elsődleges változat.
Tiltsam le a .md fájlokat robots.txt-ben?
Nem érdemes. A tiltás miatt a robotok nem látják a canonical és noindex fejléceket, és azok az ügynökök sem érik el a tartalmat, akiknek készült.
Kell llms.txt a markdown-változathoz?
Nem kötelező, de a kettő egymásra épül. Az llms.txt áttekintést ad, és a fontos oldalak .md változataira mutat.
Kézzel kell megírnom a markdown-változatot?
Nem ajánlott. A legbiztosabb, ha a WordPress-tartalomból automatikusan generálod, így a HTML módosítása után a markdown is frissül.
Melyik AI-szolgáltató használja a markdown-változatokat?
Egyik nagy szolgáltató sem jelentette be hivatalosan, hogy előnyben részesítené őket. A lekérések ma főleg fejlesztői eszközöktől és kísérleti ügynököktől érkeznek.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.