Hogyan olvassák az LLM-ek valójában a weboldaladat – és mi mehet félre
A ChatGPT, Gemini, Perplexity és Claude kapuőrökké váltak a weben. Aki nem AI-olvasható, az milliók számára egyszerűen nem létezik. Bemutatjuk a 10 döntő tényezőt – a Schema.org-tól a robots.txt-en és llms.txt-en át a hreflangig – és azt, hogyan reagálnak rájuk a nyelvi modellek.
A keresőoptimalizálás nem új keletű dolog. De amióta a nagy nyelvi modellek (LLM-ek) több száz millió ember elsődleges információforrásaként működnek, a játékszabályok alapvetően megváltoztak. Már nem csak arról van szó, hogy a Google első oldalára kerülj – arról is, hogy egy AI-asszisztens egyáltalán érti-e a tartalmaidat, helyesen értelmezi-e azokat, és végül idézi-e.
A RobotCheck.coffee egy élő szabálykatalógus alapján vizsgálja a webhelyeket, amelyet hetente frissítünk az AI-szolgáltatók hivatalos dokumentációiból. Ez a cikk részletesen bemutatja a tíz döntő tényezőt – a pontszámban betöltött súlyuk szerint rendezve: mi a technikai háttér, miért fontos az LLM-ek számára – és milyen konkrét lépéssel tudsz azonnal cselekedni?
Schema.org Markup
Mi ez egyáltalán?
A Schema.org egy közös szókészlet strukturált adatokhoz – a Google, Bing, Yahoo és Yandex fejlesztette. JSON-LD-vel, Microdatával vagy RDFa-val gépileg olvasható jelentést adsz a HTML-elemeknek: cikk, termék, GYIK, személy.
Az olyan séma-típusok, mint az Article, BreadcrumbList, FAQPage, HowTo, Product vagy LocalBusiness, a modern web szemantikai nyelvtanát alkotják. Egyetlen más tényező sem nyom többet a latba a RobotCheck-pontszámban.
Miért figyelnek erre az LLM-ek
A nyelvi modellek kiválóan dolgoznak fel szöveget – de értelmezniük kell. A Schema.org leveszi róluk ezt a terhet. Ha egy LLM helyes Article sémát lát egy oldalon, azonnal tudja: szerző, dátum, kiadó, fő tartalom – találgatás nélkül.
Különösen a FAQPage jelölés aranyat ér: az LLM-ek közvetlenül kinyerik a kérdéseket és válaszokat, és kiemelt találatként jelenítik meg őket.
- Nincs séma → a modellnek a folyó szövegből kell kikövetkeztetnie a kontextust (hibalehetőség)
- Jelen lévő author mező → jobb E-E-A-T értékelés (szakértelem, tekintély, bizalom)
- datePublished + dateModified → lehetővé teszi az időbeli besorolást
- Termékoldalak aggregateRatinggel → vásárlásra alkalmas AI-válaszok
- Hibás JSON-LD → a validátorhibák csökkentik a crawlerek bizalmát
robots.txt
Mi ez egyáltalán?
A robots.txt egy szöveges fájl a domain gyökérkönyvtárában. 1994 óta létezik – régebbi a Google-nál – és mégis aktuálisabb, mint valaha. Megmondja a crawlereknek, mely területeket látogathatják és melyeket nem.
Miért figyelnek erre az LLM-ek
Minden nagy AI-vállalatnak saját crawlerei vannak – gyakran több is, eltérő feladatokkal: ClaudeBot (Anthropic, betanítás), Claude-SearchBot (Anthropic, keresés), GPTBot (OpenAI), Google-Extended (Google/Gemini), PerplexityBot. Tiszteletben tartják a robots.txt-t – aki láthatóvá akarja tenni a tartalmát az AI-rendszerek számára, nem zárhatja ki ezeket a botokat.
A leggyakoribb hiba: a fejlesztők általánosan blokkolnak minden botot a User-agent: * / Disallow: / direktívával – és ezzel akaratlanul az összes LLM-crawlert is kizárják. Az eredmény: az AI egyszerűen nem ismeri a tartalmat. A második leggyakoribb hiba: egy szolgáltató botjai közül csak az egyiket engedélyezik, a többit elfelejtik – ekkor az oldal bekerül a betanításba, de nem jelenik meg az AI-asszisztens élő keresési találataiban.
Egy robots.txt explicit LLM-bot szabályok nélkül olyan, mint egy kirakatablak behúzott függönyökkel. – RobotCheck elemzés
- Blokkolt ClaudeBot/GPTBot → a tartalom nem jelenik meg az AI-válaszokban
- Csak a betanító bot engedélyezve, a kereső bot elfelejtve → láthatatlan az élő válaszokban
- Explicit szabad utak → magasabb indexelési valószínűség
- Hiányzó Sitemap: direktíva → a crawlerek nem találják automatikusan a sitemapet
llms.txt
Mi ez egyáltalán?
Az llms.txt a legfiatalabb szabvány ezen a listán – Jeremy Howard (Answer.AI) javaslata, amely rohamosan terjed. A robots.txt-hez hasonlóan a gyökérkönyvtárban található, és egy gondozott tartalomjegyzék Markdown formátumban: mit kínál ez a webhely, melyek a legfontosabb oldalak, hol találják az AI-rendszerek a lényeget?
Míg a robots.txt azt mondja meg, hová mehetnek a crawlerek, az llms.txt azt, mit találnak ott – olyan formában, amelyet az LLM-ek közvetlenül fel tudnak dolgozni: egy H1-cím, egy tömör összefoglaló idézetblokként, kommentált linklisták a kulcsoldalakhoz.
Miért figyelnek erre az LLM-ek
Az LLM-rendszerek korlátozott kontextusablakkal dolgoznak. Ahelyett, hogy több száz aloldalt crawlolnának és maguk súlyoznák őket, egy llms.txt segítségével egyenesen a lényegre ugorhatnak. Az Anthropic, a Perplexity és egyre több eszköz már feldolgozza a fájlt.
A szabvány fiatal és folyamatosan fejlődik – éppen ezért a RobotCheck az llms.txt-t mindig az llmstxt.org aktuális specifikációjához méri, nem egy befagyasztott állapothoz. Ami ma opcionális, az jövő hónapban már ajánlott lehet.
- Nincs llms.txt → az AI-nak magának kell kitalálnia az oldalstruktúrát
- Jelen lévő H1 + idézetblokk-összefoglaló → azonnali megértés a kínálatról
- Kommentált linkek a kulcsoldalakhoz → az AI a megfelelő oldalakat idézi
- Relatív, nem abszolút URL-ek → a linkek használhatatlanok külső rendszerek számára
Sitemap XML
Mi ez egyáltalán?
Az XML-sitemap a weboldalad tartalomjegyzéke – gépileg olvasható, strukturált, minden URL-ről metaadatokkal: módosítás dátuma, gyakoriság, prioritás. Ez a legközvetlenebb módja annak, hogy közöld egy crawlerrel: itt van minden, amim van.
Miért figyelnek erre az LLM-ek
A crawler-alapú AI-rendszerek (különösen a Perplexity, amely élőben crawlol) aktívan használják a sitemapeket az új tartalmak felfedezéséhez. Ha a sitemap hiányzik vagy elavult, az új blogbejegyzések vagy termékoldalak egyszerűen kimaradnak.
Különösen fontos a lastmod érték. Az LLM-ek a friss tartalmat részesítik előnyben. A helyesen beállított dátum aktualitást jelez, és növeli az esélyt, hogy időérzékeny lekérdezésekben idézzék.
- Hiányzó sitemap → a crawlerek csak belső linkeken keresztül fedezik fel a tartalmat
- Elavult lastmod adatok → a tartalmat elavultnak minősítik
- Jelen lévő kép-sitemap → a multimodális modellek jobban indexelik a képeket
- Sitemap-index → lehetővé teszi egyes szekciók szelektív crawlolását
Open Graph Meta Tagek
Mi ez egyáltalán?
Az Open Graphot (OG) eredetileg a Facebook fejlesztette a linkek megjelenítésére a közösségi hálózatokon. Ma az OG-tagek minden platformon és AI-eszközben szabványnak számítanak. A legfontosabb tagek: og:title, og:description, og:image, og:type.
Miért figyelnek erre az LLM-ek
Amikor egy LLM-rendszer lekér egy URL-t, először a head szakaszt olvassa. Az OG-tagek gyors, megbízható forrást jelentenek a címhez és az összefoglalóhoz – egy pontos og:description gyakran a forrás-előnézetek alapja az AI-válaszokban, és többnyire találóbb a folyó szövegnél.
Különösen a Perplexity használja intenzíven az OG-adatokat forráslinkekhez. A hiányzó og:description gyenge forrás-előnézetekhez vezet – és így kevesebb kattintáshoz. Az Open Graph önmagában nem teszi AI-olvashatóvá az oldalt, de a hiánya gyengébbnek mutathat egy egyébként jó oldalt.
- Hiányzó OG-tagek → a címet és a leírást a DOM-ból találgatják ki
- Egyedi og:image → növeli a közösségi megosztást és a multimodális láthatóságot
- og:type: article az article:published_time-mal → pontosabb időbeli besorolás
- Twitter-card tagek ráadásként → teljes lefedettség minden nagy platformon
HTML-struktúra és szemantika
Mi ez egyáltalán?
A HTML5 szemantikai elemeket hozott: article, section, nav, header, footer, main, aside. Ezek nem csak a megjelenést írják le, hanem a tartalom jelentését is.
A gyakorlatban ez a meglévő weboldalak leggyakoribb gyenge pontja: sok oldalt div-vel és span-nal építettek fel, mindenféle szemantikai struktúra nélkül.
Miért figyelnek erre az LLM-ek
Egy ember számára a rossz HTML vizuális probléma. Egy LLM számára fogalmi probléma. Szemantikai tagek nélkül a modellnek ki kell találnia, mi a fő tartalom – és mi a navigáció, a hirdetés vagy a lábléc.
A modern LLM-crawlerek a main elemet használják elsődleges tartalomtárolóként. Ha ez a tag hiányzik, az egész body-t feldolgozzák – beleértve a menüt, a cookie-bannert és a lábléclinkeket.
main elembe, ügyelj rá, hogy pontosan egy h1 legyen oldalanként, és használj article elemet az önálló tartalomrészekhez.- Nincs main → a crawler az egész body-t feldolgozza (navigációval, lábléccel együtt)
- Több h1 → az oldal témája tisztázatlan a modell számára
- Lapos címsor-hierarchia → a cikk struktúrája nem felismerhető
- Egymásba ágyazott div-tenger → magasabb hibaarány a tartalom kinyerésénél
- Helyes landmark-szerepek → a kisegítő technológiák ÉS az AI egyaránt profitálnak
Alt-szövegek a képekhez
Mi ez egyáltalán?
Az img-tag alt attribútuma egy kép szöveges leírása – elsősorban képernyőolvasókhoz fejlesztették. Az üres alt azt jelzi: ez a kép dekoratív. Egy tartalmas alt-szöveg leírja a kép tartalmát és kontextusát.
Miért figyelnek erre az LLM-ek
Még ha a multimodális modellek közvetlenül látják is a képeket – szöveges források crawlolásakor az LLM-ek szinte kizárólag az alt-szövegekre támaszkodnak. Egy alt-szöveg nélküli kép egy szövegalapú crawler-rendszer számára egyszerűen láthatatlan.
A jól megírt alt-szövegek javítják az oldal szemantikai mezőjét: olyan kulcsszavakat adnak hozzá, amelyek természetesen illeszkednek a témához – kulcsszótömés nélkül.
- Hiányzó alt-szövegek → a képeket figyelmen kívül hagyják a szöveges crawlolásnál; tartalmi hézagok keletkeznek
- Leíró alt-szövegek → az oldal kiterjesztett szemantikai mezője
- Kulcsszóval teletömött alt-szövegek → spamként azonosítva, negatív hatás lehetséges
- Alt-szövegek infografikákhoz → kritikus: a grafikák adatai egyébként elérhetetlenek az LLM-ek számára
Teljesítmény és Core Web Vitals
Mi ez egyáltalán?
A teljesítmény azt jelenti: milyen gyorsan és stabilan tölt be az oldalad? A Google a Core Web Vitals (LCP, CLS, INP/FID) révén konkrét mérőszámokat definiált. Az LCP a betöltési sebességet, a CLS a vizuális stabilitást, az INP az interaktivitást méri.
Miért figyelnek erre az LLM-ek
Az LLM-crawlerek számára a teljesítménynek más dimenziója van: a fej nélküli böngészők és a HTTP-kliensek nem várnak a végtelenségig. Az 5–10 másodpercnél tovább töltődő oldalakat egyes crawlerek megszakítják. A JavaScript-nehéz alkalmazások szerveroldali renderelés nélkül sok crawler számára láthatatlanok.
Ráadásul: a Google a teljesítményt rangsorolási jelként használja. Mivel az olyan LLM-ek, mint a Perplexity, a Google-találatokat veszik alapul, a teljesítmény közvetetten beépül az AI-láthatóságba.
- Tisztán kliensoldali JS-renderelés → a tartalom gyakran nem indexelődik
- Lassú TTFB → valószínűbb a crawler-timeout
- Nagy, tömörítetlen képek → alacsonyabb crawlolási gyakoriság
- Jó Core Web Vitals → közvetett előny a jobb Google-rangsorolás révén
Canonical Tagek
Mi ez egyáltalán?
Egy canonical tag közli a crawlerekkel: ez ennek az oldalnak a mérvadó, eredeti változata. Ez az ellenszere a duplikált tartalomnak – ugyanaz a tartalom több különböző URL-en.
Miért figyelnek erre az LLM-ek
Az LLM-ek crawler-adathalmazokon tanulnak. Ha ugyanaz az információ 5 különböző URL-en létezik, ötször crawlolják – de egyik sem kapja meg a teljes tekintélyt. A canonical tagekkel a linkerő koncentrálódik.
Különösen fontos a címkékkel, kategóriákkal és archívumoldalakkal rendelkező blogoknál: canonical nélkül minden archívumoldal hígítja az eredeti cikk tekintélyét.
- Hiányzó canonical → a tekintély szétoszlik a duplikátumok között
- Önhivatkozó canonical → helyes gyakorlat, megerősíti az eredetiséget
- Canonical HTTPS-en → kiküszöböli a HTTP/HTTPS duplikátum-problémát
- Lapozás canonical nélkül → a 2., 3., ... oldalt önálló dokumentumként kezelik
- Hreflang + canonical kombinálva → a többnyelvű oldalak helyesen strukturáltak
hreflang
Mi ez egyáltalán?
A hreflang attribútum megmondja a crawlereknek, milyen nyelvre és régióra szánták az oldalt – és hol találhatók a megfelelői más nyelveken. A head-ben <link rel="alternate" hreflang="hu" href="..."> formában szerepel, nyelvverziónként egy sor, plusz ideális esetben egy hreflang="x-default" tartalékként.
Miért figyelnek erre az LLM-ek
A hreflang nélküli többnyelvű oldalak összezavarják a crawlereket: nem tudják megbízhatóan felismerni, hogy a magyar és az angol változat ugyanaz az oldal – és legrosszabb esetben duplikátumként kezelik őket, amelyek kölcsönösen hígítják egymás tekintélyét. Helyes hreflanggal egy AI-rendszer tudja, melyik nyelvverziót szolgálja ki a felhasználónak.
Az x-default bejegyzés a biztonsági horgony: megmondja a rendszernek, melyik változatot mutassa, ha a felsorolt nyelvek egyike sem illik a felhasználó kéréséhez. Ennek hiányában a crawlerek találgatnak – általában a kisebb nyelvek kárára.
- Nincs hreflang-tag → a nyelvverziók versengő duplikátumoknak tűnnek
- Legalább két nyelv összekapcsolva → egyértelmű jelzés egy nemzetközi oldalról
- Beállított hreflang='x-default' → megbízható tartalék ismeretlen locale-okhoz
- Hreflang + canonical kombinálva → minden nyelvverzió megtartja a saját tekintélyét
Összefoglalás: A 10 tényező egy pillantásra
| # | Tényező | Fontosság az LLM-ek számára |
|---|---|---|
| 1 | Schema.org | Szemantikai értelmezés – a legerősebb tényező |
| 2 | robots.txt | Hozzáférés-vezérlés minden AI-crawlerhez |
| 3 | llms.txt | Gondozott tartalomjegyzék AI-rendszereknek |
| 4 | Sitemap XML | Teljes tartalomfelderítés |
| 5 | Open Graph | Gyors előnézet a head szakaszban |
| 6 | HTML-struktúra | Tartalomkinyerés és kontextus |
| 7 | Alt-szövegek | Képértelmezés multimodalitás nélkül |
| 8 | Teljesítmény | Crawler-elérhetőség és rangsorolás |
| 9 | Canonical tagek | Tekintély-koncentráció |
| 10 | hreflang | A nyelvverziók helyes hozzárendelése |
Egy weboldal AI-olvashatósága ma már nem luxus – alapfeltétele a láthatóságnak az információkeresés új korszakában. És ez mozgó célpont: a szabályok, amelyekhez a RobotCheck mér, hetente frissülnek az AI-szolgáltatók hivatalos forrásaiból – hogy ez hogyan működik, itt olvashatod.
Teszteld saját weboldaladat a robotcheck.coffee/check oldalon – ingyen, regisztráció nélkül, azonnali eredménnyel.