JavaScript-renderelés és az AI-botok: amit nem látnak

Scheo · 2026-08-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A böngésződben minden rendben van: betölt az oldal, ott a szolgáltatáslista, a GYIK, a kapcsolati adatok. Aztán megkérdezed a ChatGPT-t vagy a Perplexityt a saját cégedről, és olyan válasz érkezik, mintha a fél oldalad nem is létezne. Ez a legtöbb esetben nem büntetés és nem is valami rejtélyes algoritmus: egyszerűen arról van szó, hogy a bot mást lát, mint te. Amit te látsz, azt a böngésződ JavaScript-motorja rakta össze a szerverről érkező adatokból. Amit a bot lát, az sokszor csak a szerver első válasza, a nyers HTML. Ebben a cikkben végigmegyünk azon, miért válik szét ez a kettő, milyen tartalom szokott eltűnni egy magyar kkv-oldalán, és hogyan tudod húsz perc alatt, fejlesztő nélkül is megnézni, mi van tényleg a forrásban.

Miért olvassa a legtöbb AI-crawler csak a nyers HTML-t?

Rövid válasz: mert a JavaScript futtatása lassú és erőforrás-igényes, a legtöbb AI-crawler pedig egyszerű, gyors HTTP-lekérésre épül, ami a szerver első válaszát dolgozza fel, és nem indít teljes böngészőt minden URL-hez.

Hivatalosan igazolt. A Google Search Central JavaScript SEO dokumentációja részletesen leírja a folyamatot: a Googlebot letölti az oldalt, egy külön renderelő szolgáltatás (Web Rendering Service) egy Chromium-alapú környezetben lefuttatja a JavaScriptet, és a feldolgozás csak ezután fejeződik be. A Google tehát tud rendereleni, de sorban állással és erőforrás-korláttal. Az OpenAI publikus crawler-leírása azonosítja a saját botjait (GPTBot, OAI-SearchBot, ChatGPT-User), leírja a robots.txt kezelését és a felhasználói ügynök karakterláncokat, viszont nem ígér teljes böngésző-szintű renderelést. Ugyanez a helyzet a többi nagy szereplő nyilvános leírásánál: a bot azonosítója és a robots-szabály dokumentált, a JavaScript-végrehajtás nem.

Szakmai feltételezés. Amit egy szolgáltató nem dokumentál, arra nem érdemes építeni. Abból, hogy egy AI-crawler nyilvánosan nem beszél renderelésről, logikusan következik, hogy legalábbis nem minden lekérésnél, nem minden oldalon és nem kiszámítható módon futtat JavaScriptet. Egy nyelvi modell tanításához vagy egy valós idejű válaszhoz sok millió URL-t kell begyűjteni: ilyen léptéknél a nyers HTML feldolgozása nagyságrendekkel olcsóbb.

Saját tapasztalat. Amikor egy oldal szerverlogjában megnézzük a bot-kéréseket, jellemzően egyetlen HTML-lekérést látunk, és nem követi a CSS-, JS- és képfájlok tömege, ahogy egy valódi böngészőnél történne. Ez erős jelzés arra, hogy a bot nem épített fel teljes oldalt, csak elolvasta, amit a szerver visszaadott. A gyakorlati következtetés egyszerű: amit a szerver az első válaszban nem küld el, az bizonytalan sorsú.

Mi tűnik el pontosan, ha kliensoldalon renderelsz?

Rövid válasz: minden, ami csak egy JavaScript-hívás után kerül a DOM-ba, tehát tipikusan a szövegtörzs, a listák, az akkordionba rejtett GYIK, a vélemények és sokszor még a title és a leíró meta is.

Egy tipikus kliensoldali (CSR) oldal forrása néhány sorból áll: egy üres <div id="root"></div>, néhány script-hivatkozás, és kész. A tartalom onnan érkezik, hogy a böngésző letölti a JS-csomagot, lefuttatja, meghívja az API-t, és csak utána rajzolja ki a szöveget. Ha a bot ezt a láncot nem futtatja le, a rendelkezésére álló információ nagyjából annyi, hogy létezik egy HTML-fájl.

A gyakorlatban ezek szoktak kiesni egy kkv-oldalnál:

• a szolgáltatásokat leíró szövegek, ha tabokba vagy legördülő elemekbe kerülnek, és csak kattintásra töltődnek be,
• a GYIK-blokk, ha a kérdés-válasz párokat egy JS-komponens húzza be egy külső adatforrásból,
• a vélemények és az értékelések, ha külső widget jeleníti meg őket,
• a webshop kategórialistája és a termékleírás, ha az oldal egyoldalas alkalmazásként működik,
• a kapcsolati adatok, ha egy térkép- vagy kontakt-komponens rendereli őket,
• a strukturált adat (JSON-LD), ha címkekezelővel, kliensoldalon injektálod be,
• a belső linkek, ha a menü kizárólag JS-eseményekre épül, és nincs mögötte valódi <a href>.

A belső linkek hiánya a legalattomosabb eset. Ha a bot nem talál kattintható hivatkozást, akkor nemcsak az adott oldal tartalmát nem látja, hanem az aloldalaidhoz vezető utat sem.

Hogyan ellenőrzöd húsz perc alatt, mi van tényleg a forrásban?

Rövid válasz: kérd le az oldalt böngésző nélkül, és keress rá a saját mondataidra. Ha nem találod, a bot sem találja.

1. Nyers forrás megtekintése. A böngészőben ne a fejlesztői eszközök Elements fülét nézd, mert az már a JavaScript utáni állapotot mutatja. Használd a view-source:https://pelda.hu/szolgaltatasok címet, és a Ctrl+F segítségével keress rá egy jellemző mondatra az oldalról.
2. Lekérés parancssorból. Ez a leggyorsabb és legőszintébb teszt: curl -s https://pelda.hu/ | wc -c megmutatja, hány bájt jön vissza, a curl -s https://pelda.hu/ | grep -i "kulcsmondat" pedig azt, hogy benne van-e a keresett szöveg. Ha az első parancs pár ezer bájtot ad vissza egy hosszú aloldalnál, ott a tartalom nagy része kliensoldalon áll össze.
3. JavaScript kikapcsolása. A böngésző beállításaiban vagy egy bővítménnyel tiltsd le a JS-t, és töltsd újra az oldalt. Amit ilyenkor látsz, az egy jó közelítése annak, amivel egy egyszerű crawler dolgozik.
4. Kettős összevetés. Egy asztali feltérképező eszközzel (például a Screaming Frog vagy hasonló) futtass le két bejárást: egyet renderelés nélkül, egyet renderelt módban, majd hasonlítsd össze a szószámot, a címsorokat és a talált linkek számát. A különbség pontosan az, amit kockáztatsz.
5. Google URL-vizsgálat. A Search Console URL-vizsgálat funkciója megmutatja a Google által renderelt HTML-t. Fontos: ez a Google renderelését mutatja, nem a többi AI-crawlerét, tehát felső becslés, nem alsó.

Ha a második pontnál a keresett mondat nincs meg a válaszban, ott érdemes megállni és fejlesztővel beszélni. Ez az a pillanat, amikor egy technikai probléma tartalmi problémává válik.

Mikor elég a kliensoldali renderelés, és mikor nem?

Rövid válasz: a nyilvános, keresésből és AI-válaszokból behozandó tartalomnak a szerver első válaszában kell szerepelnie; a bejelentkezés utáni, interaktív felületeknél a kliensoldali működés teljesen rendben van.

Három megközelítést érdemes megkülönböztetni. A kliensoldali renderelés (CSR) esetén a szerver üres vázat küld, és a böngésző rakja össze az oldalt. A szerveroldali renderelés (SSR) esetén a szerver már kész HTML-t ad vissza, és a JavaScript utólag teszi interaktívvá (ezt hívják hidratálásnak). A statikus generálás (SSG) esetén az oldalak előre elkészülnek, és a szerver fájlként szolgálja ki őket. Bot szempontjából a második és a harmadik egyformán jó: mindkettőnél a lényeg benne van az első válaszban.

Egy szolgáltató kkv-nál, ahol a tartalom naponta nem változik, a statikus generálás jellemzően a legjózanabb választás: gyors, olcsón üzemeltethető, és nincs mit elrontani rajta. Egy webshopnál, ahol a készlet és az árazás dinamikus, a szerveroldali renderelés a kézenfekvő irány, esetleg gyorsítótárral kiegészítve.

Milyen megoldás jöhet szóba egy magyar kkv-nál?

Rövid válasz: a legtöbb hazai kkv-oldal WordPressen vagy dobozos webshopmotoron fut, ahol a probléma nem a rendszerből, hanem egy-egy sablonelemből vagy bővítményből ered, tehát célzottan javítható.

Vegyünk egy székesfehérvári asztalos vállalkozást. A WordPress alapból szerveroldalon állítja elő a HTML-t, tehát a helyzet jó kiindulás. A gond általában ott kezdődik, hogy az oldalépítő bővítmény tabokba szervezi a szolgáltatásokat, a referenciagaléria pedig lapozva, kérésre töltődik. A javítás nem oldalcsere: elég, ha a tabok tartalma a HTML-ben eleve ott van (csak CSS-sel rejtve), a galéria pedig szerveroldali lapozást kap valódi linkekkel.

Egy debreceni állatorvosi rendelőnél tipikusan a foglalórendszer és a nyitvatartás jelenti a kockázatot: ha mindkettő beágyazott, külső rendszerből jövő komponens, akkor a bot nem látja, mikor vagy nyitva. Ilyenkor érdemes a nyitvatartást és a címet sima HTML-szövegként is kiírni az oldalra, a strukturált adat pedig szerveroldalon, közvetlenül a forráskódba kerüljön, ne címkekezelőn keresztül.

Ha egyedi, React vagy Vue alapú oldalad van, a fejlesztőnek szóló kérés röviden ennyi: a nyilvános aloldalak szerveroldali rendereléssel vagy előre generálva készüljenek, a menü valódi <a href> elemekből álljon, és a JSON-LD a szerver által küldött HTML-ben legyen benne. Ez a legtöbb modern keretrendszerben (Next.js, Nuxt, SvelteKit, Astro) beépített képesség, nem egyedi fejlesztés.

Milyen hibákat érdemes elkerülni közben?

Rövid válasz: ne a botnak gyárts külön tartalmat, és ne bízd a lényeget felhasználói interakcióra.

• Eltérő kiszolgálás bot és ember számára. Ha a bot más szöveget kap, mint a látogató, az a keresőoptimalizálási irányelvek szerint kockázatos terület. A helyes cél az azonos tartalom, nem a bot kiszolgálása külön változattal.
• Végtelen görgetés alternatíva nélkül. Ha a listaoldalak csak görgetésre töltenek be, tegyél mellé valódi, linkelt lapozást.
• Túlzott lusta betöltés. A képeknél hasznos, a szövegnél viszont azt eredményezi, hogy a szöveg csak akkor kerül a DOM-ba, ha valaki odagörget.
• Blokkolt erőforrások. Ha a robots.txt letiltja a JS- vagy CSS-fájlokat, akkor még az a bot sem tud renderelni, amelyik egyébként tudna.
• Kliensoldali strukturált adat. A címkekezelővel beszúrt JSON-LD működhet a Google-nél, de a nem renderelő botoknál nincs jelen.
• Tartalmat takaró sáv. Ha a sütikezelő vagy egy felugró ablak a HTML-ben elrejti a törzsszöveget, az ugyanaz a hatás, mintha nem is lenne ott.

Milyen ellenőrzőlistával zárd le a munkát?

Rövid válasz: a javítás akkor kész, ha a legfontosabb öt aloldalad nyers forrásában megtalálod a lényegi tartalmat, a címsorokat, a belső linkeket és a strukturált adatot.

1. A főoldal, a szolgáltatásoldalak és a kapcsolat oldal nyers forrásában szerepel a törzsszöveg.
2. A H1 és a H2 címsorok a forrásban vannak, nem JS tölti be őket.
3. A menü és a lábléc linkjei valódi href attribútummal rendelkeznek.
4. A GYIK kérdései és válaszai szöveges formában megtalálhatók a forrásban.
5. A JSON-LD a szerver által küldött HTML-ben van, és érvényes.
6. A title és a leíró meta szerveroldalon áll elő, aloldalanként eltérően.
7. A robots.txt nem tiltja a megjelenítéshez szükséges CSS- és JS-fájlokat.
8. Egy curl-lekérés válasza tartalmazza mindazt, amit egy AI-válaszban látni szeretnél.

Ez a lista nem varázsszer, és önmagában nem jelent biztos megjelenést az AI-válaszokban: azt sok más tényező is befolyásolja, a tartalom minőségétől a márkád külső említéseiig. Azt viszont kiveszi az egyenletből, hogy technikai okból egyáltalán ne legyen esélyed. Egy oldal, amit a bot el sem tud olvasni, semmilyen tartalmi erőfeszítéssel nem tud versenybe szállni, míg egy jól olvasható oldal legalább az asztalnál ül.

Források és további olvasnivalók

• Google Search Central: JavaScript SEO alapjai, illetve a dinamikus megjelenítésről szóló útmutató
• Google Search Console súgó: URL-vizsgálat eszköz
• OpenAI dokumentáció: OpenAI crawlers (GPTBot, OAI-SearchBot, ChatGPT-User)
• Anthropic súgóközpont: ClaudeBot és a webes hozzáférés kezelése
• Schema.org: hivatalos típusdefiníciók és példák
• W3C: HTML Living Standard és a WAI-ARIA ajánlások
• robots.txt szabvány: RFC 9309 (Robots Exclusion Protocol)