Előrenderelés és eltérő kiszolgálás botoknak: mikor megengedett és mikor kockázatos

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

A kliensoldali keretrendszerek (React, Vue, Angular, Svelte) alapértelmezés szerint szinte üres HTML-t küldenek ki, és a tartalmat a böngészőben futó JavaScript rakja össze. A Google ezt általában meg tudja oldani, mert van renderelési fázisa, az AI-botok jelentős része viszont nem futtat JavaScriptet, így üres vázat lát. Innen jön a kísértés, hogy a botoknak külön, előre összerakott HTML-t adj, az embereknek pedig maradjon a megszokott alkalmazás. Ez a lépés önmagában nem tiltott, de van egy vékony határa, amin túl már az irányelvekbe ütköző burkolt átverés kezdődik. Végigveszem, hol húzódik ez a határ, milyen technikai utak vezetnek el ugyanide, melyiknek mekkora az üzemeltetési ára, és mit kell ellenőrizned, hogy ne csússz át a rossz oldalra.

Mi a különbség a dinamikus kiszolgálás és a burkolt átverés között?

A dinamikus kiszolgálás akkor rendben van, ha a bot és az ember tartalmilag ugyanazt kapja, csak más módon előállítva. Burkolt átverésről (cloaking) akkor beszélünk, ha a kettő tartalma érdemben eltér, jellemzően azért, hogy a kereső jobb helyezést adjon, mint amit az oldal az embereknek nyújt.

Hivatalosan igazolt. A Google spam-irányelvei a cloakingot úgy határozzák meg, hogy a felhasználóknak és a keresőmotoroknak eltérő tartalmat mutatsz azzal a céllal, hogy manipuláld a rangsorolást. Ugyanakkor a Search Central dokumentációja évek óta leírja a dinamikus renderelést is, és kifejezetten megkerülő megoldásnak (workaround) nevezi, nem hosszú távú architektúrának. Ez a két állítás nem mond ellent egymásnak. A renderelési mód különbözhet, a tartalom nem.

A gyakorlatban a határ ott van, hogy ha kimásolod a bot által kapott HTML szöveges részét, és mellé teszed azt, amit egy böngésző a JavaScript lefutása után mutat, a kettőnek ugyanazt kell mondania. Ugyanazok a címsorok, ugyanaz a törzsszöveg, ugyanazok a belső linkek, ugyanaz a strukturált adat. Ha a bot-verzióba bekerül három extra bekezdés kulcsszavakkal, amit ember soha nem lát, az már a másik oldal, akkor is, ha technikailag ugyanaz a rendszer állítja elő.

Hasznos próba, ha a saját szemeddel nézel rá a kérdésre. Képzeld el, hogy egy kolléga kinyomtatja a bot által kapott oldalt és a látogató által kapottat, majd egymás mellé teszi a két lapot. Ha bárki, aki nem ismeri a rendszert, rá tud mutatni egy különbségre a mondanivalóban, akkor baj van. Ha csak annyit lát, hogy az egyiken több a beágyazott szkript és kevesebb a sütiket kezelő sáv, akkor nincs.

Szakmai feltételezés. Az AI-botok esetében nincs a Google spam-irányelveihez hasonló, ilyen részletességű nyilvános szabálykönyv arról, mi számít megtévesztésnek. Abból érdemes kiindulni, hogy a nagy modellszolgáltatók előbb-utóbb ugyanazt a mércét alkalmazzák, és a bot-verzió eltérése hosszabb távon inkább kockázat, mint előny.

Milyen feltételekkel fogadható el az előrenderelt HTML kiszolgálása?

Akkor fogadható el, ha a bot-verzió az emberi verzió hűséges, gépi másolata, és minden eltérés technikai természetű. Ezt érdemes leírni magadnak feltételként, mielőtt bármit bekapcsolsz.

• Tartalmi azonosság. A látható szöveg, a címsor-hierarchia, a canonical, a meta robots, a hreflang és a strukturált adat megegyezik a két változatban.
• Nincs bot-specifikus többlet. Se rejtett kulcsszavak, se extra belső linkek, se olyan ajánlat, amit a látogató nem kap meg.
• A státuszkód átmegy. Ha az oldal 404, a bot is 404-et kap, nem egy szép 200-as hibaoldalt.
• A gyorsítótár frissül. Tartalomváltozás után belátható időn belül az előrenderelt verzió is követi a változást.
• Kiesés esetén nem romlik el minden. Ha az előrenderelő réteg nem válaszol, a bot a normál HTML-t kapja, nem hibaoldalt.
• Nem függ a bot kilététől a tartalom. A kiszolgálás módja igen, a mondanivaló nem.

Ha ebből bármelyik pont sérül, az nem feltétlenül szándékos megtévesztés, viszont a kívülről látszó eredmény ugyanaz. A kereső nem az indokodat méri, hanem a különbséget.

Melyik megvalósítási út mit kér tőled cserébe?

Három bevált út létezik, és üzemeltetési szempontból nagyon másképp viselkednek. Az egyik külső szolgáltatásra bíz egy kritikus réteget, a másik a saját alkalmazásodat terheli meg, a harmadik a build folyamatot.

Előrenderelő szolgáltatás vagy saját prerender réteg

A működés lényege, hogy egy fejetlen böngésző lefuttatja az oldalt, elmenti a kész HTML-t, és a webkiszolgáló a bot kéréseit erre a tárolt változatra irányítja. Gyorsan bevezethető, az alkalmazás kódjához nem kell hozzányúlni.

A hibalehetőségek viszont sűrűn jönnek. A leggyakoribb a néma elavulás, amikor a tartalom hetekkel korábbi állapotban ragad benne a gyorsítótárban, és erről semmilyen riasztás nem szól. A második a fejetlen böngésző időtúllépése, ami félig kész HTML-t ment el, benne a betöltés-jelzővel. A harmadik a státuszkód elvesztése, mert sok prerender réteg mindenre 200-at ad vissza. A negyedik a külső függőség, hiszen ha a szolgáltatás leáll, a keresők és az AI-botok pont abban az időablakban kapnak üres vagy hibás választ.

Szerveroldali renderelés

Itt az alkalmazás a szerveren állítja össze a HTML-t minden kérésre, függetlenül attól, ki kéri. Ez a megközelítés kiveszi a képletből az egész bot-felismerési problémát, mert nincs két változat. Az ember és a gép ugyanazt a HTML-t kapja, a böngésző pedig utána élesíti (hidratálja) az interaktivitást.

Az ára, hogy kell egy futó Node környezet vagy azzal egyenértékű háttér, és figyelni kell a válaszidőre. Tipikus hibák közé tartozik a hidratálási eltérés, amikor a szerveren és a kliensen más HTML keletkezik, továbbá az adatbázis-hívások megsokszorozódása, mert minden kérés újra lekér mindent. Mindkettő kezelhető, de mérni kell. Egy egyszerű oldal-szintű gyorsítótár a szerver előtt általában elviszi a terhelés nagy részét.

Statikus generálás

A tartalom a build során áll elő, és a kiszolgáló kész fájlokat ad vissza. Ez a legstabilabb és a legolcsóbb futtatás, mert nincs mit elrontani kérésenként. Blog, tudásbázis, szolgáltatás-oldalak, bemutatkozó oldalak esetében szinte mindig ez a legjobb választás.

A korlát a frissülés. Ha ötezer termékoldalad van, és mindegyik napi árváltozást követ, a teljes újraépítés lassú lesz. Erre való az inkrementális újragenerálás, ami oldalanként, igény szerint frissít. A gyakori hiba itt az, hogy a build hibára fut, a régi kimenet marad kint, és senki nem veszi észre napokig.

Érdemes a build kimenetére is tenni egy egyszerű őrt. Ha a generált oldalak száma vagy az összméret hirtelen a felére esik, az szinte mindig hibát jelez, és sokkal korábban szól, mint bármilyen forgalmi mutató. Ez néhány sor szkript, viszont sok kellemetlen hetet megspórol.

Hogyan kezeld a felhasználó-azonosító karakterláncot?

A felhasználó-azonosító karakterlánc (user agent) hamisítható, ezért önmagában nem alkalmas arra, hogy eltérő tartalmat kapcsolj hozzá. Ha mégis erre alapozol, legalább ellenőrizd a bot valódiságát.

Hivatalosan igazolt. A Google közzéteszi a crawlerei IP-tartományait gépi olvasható formában, és leírja a fordított DNS-ellenőrzés menetét is. Az OpenAI szintén publikálja a GPTBot IP-tartományait, és hasonló listát ad több nagy szolgáltató. Ezek a listák változnak, tehát nem elég egyszer letölteni őket.

Egy nginx elé tett egyszerű szabály így néz ki. map $http_user_agent $is_bot { default 0; "~*googlebot|bingbot|gptbot|claudebot|perplexitybot" 1; } Ezután a $is_bot értéke alapján irányíthatod a kérést az előrenderelt változatra. Fontos, hogy a válaszhoz kerüljön Vary: User-Agent fejléc, különben a CDN egyetlen változatot tárol el, és könnyen előfordul, hogy egy látogató kapja a bot-verziót, vagy fordítva. Saját tapasztalat, hogy ez a hiányzó fejléc okozza a legtöbb rejtélyes, nehezen reprodukálható esetet.

Praktikus szabály, hogy a listát tartsd rövidnek és karbantarthatónak. Húsz bot-minta helyett inkább öt, amit tényleg használsz, és amit időnként átnézel a naplóból.

Mi történik, ha az előrenderelő réteg kiesik?

A jó válasz az, hogy semmi látványos, mert a rendszer visszaesik a normál kiszolgálásra. A rossz válasz az, hogy a botok napokig 500-as hibát vagy üres oldalt kapnak, és erről akkor értesülsz, amikor a forgalom már esik.

Három dolgot érdemes beépíteni. Az első egy rövid időkorlát az előrenderelő hívásra, két-három másodperc körül, utána azonnali visszaesés az eredeti válaszra. A második a naplózás, amiből kiderül, hány bot-kérés ment az előrenderelt útra, és abból mennyi esett vissza. A harmadik egy napi ellenőrzés, ami néhány fontos URL-en összeveti a két változat szöveghosszát, és eltérés esetén szól.

Saját tapasztalat, hogy a legdrágább hiba nem a leállás, hanem a néma részleges működés. A HTTP 200 válasz, amiben nincs érdemi szöveg, hetekig elmegy a radar alatt, mert minden zöldnek látszik.

Hogyan ellenőrizd, hogy a bot tényleg ugyanazt látja?

Az ellenőrzés nem bonyolult, viszont rendszeresen kell futtatni, nem csak élesítéskor. Érdemes végigmenni ezen a sorrenden.

1. Kérd le az oldalt bot-azonosítóval. curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -s https://pelda.hu/oldal > bot.html
2. Kérd le ugyanazt szokásos böngésző-azonosítóval, és mentsd másik fájlba.
3. Vedd ki mindkettőből a puszta szöveget, és hasonlítsd össze. A szóhossz-különbség tíz százalék fölött már indokolja a vizsgálatot.
4. Nézd meg a Search Console URL-ellenőrzőjében a renderelt HTML-t, mert az mutatja, mit lát ténylegesen a Google.
5. Ellenőrizd a státuszkódot egy szándékosan nem létező URL-en mindkét azonosítóval.
6. Módosíts egy mondatot az oldalon, és nézd meg, mennyi idő múlva jelenik meg a bot-verzióban.

Az utolsó lépés a legárulkodóbb. Ha a változás órák alatt sem jön át, a gyorsítótár érvénytelenítése nincs megoldva, és előbb-utóbb ez fog fájni.

Mit tartalmazzon az élesítés előtti ellenőrzőlista?

• Tartalmi azonosság. Szöveg, címsorok, belső linkek, canonical, meta robots, hreflang, strukturált adat mindkét változatban egyezik.
• Gyorsítótár-frissülés. Van érvénytelenítés tartalomváltozáskor, és van maximális élettartam, ami után mindenképp újratöltődik.
• Felhasználó-azonosító kezelése. Szűk bot-lista, valódiság-ellenőrzés IP-tartomány vagy fordított DNS alapján, Vary: User-Agent fejléc a válaszban.
• Hibatűrés. Időkorlát, visszaesés a normál HTML-re, és a hiba nem eredményez 5xx választ a botnak.
• Státuszkódok. A 404, a 410 és az átirányítások a bot-úton is helyesen mennek át.
• Megfigyelés. Napi automatikus összevetés néhány fontos URL-en, riasztással.
• Kilépési terv. Egy kapcsolóval kikapcsolható az egész réteg, és az oldal működik nélküle is.

Miért javaslom kisebb magyar oldalnál inkább a szerveroldali renderelést?

Saját tapasztalat. Néhány száz vagy néhány ezer oldalas magyar weboldalaknál a botspecifikus kiszolgálás többe kerül figyelemben, mint amennyit hoz. A rendszer jól elvan hónapokig, aztán jön egy sablonváltás, egy CDN-beállítás vagy egy lejárt előfizetés, és a bot-verzió csendben elromlik. Az ilyen hibát tipikusan nem a monitorozás találja meg, hanem egy forgalomesés utáni vizsgálat, addigra viszont már hetek teltek el.

A szerveroldali renderelés vagy a statikus generálás ezzel szemben egyetlen igazságot tart fenn. Nincs két változat, tehát nincs mit szinkronban tartani, és nincs mit ellenőrizni azon kívül, hogy az oldal betöltődik-e. Egy magyar kkv-oldal forgalmi nagyságrendjénél a szerveroldali renderelés terhelése elhanyagolható, főleg egy egyszerű gyorsítótárral megtámogatva.

A botspecifikus kiszolgálásnak ott van helye, ahol egy meglévő, nagy kliensoldali alkalmazást nem lehet belátható időn belül átépíteni, és a rendes megoldásig kell egy áthidalás. Ilyenkor is érdemes határidő nélkül, de kimondott szándékkal ideiglenesnek tekinteni, és a vizsgálatokat beépíteni a napi rutinba. Ez a megközelítés jó eséllyel segítheti a láthatóság megtartását, de önmagában nem old meg rangsorolási problémát, és nem helyettesíti a tartalom minőségét.

Egy dolgot mindenképp érdemes külön kezelni. Az AI-botok többsége nem futtat JavaScriptet, ezért ha a tartalmad csak kliensoldalon jelenik meg, az AI-válaszokban jó eséllyel meg sem jelensz. Ez nem büntetés, egyszerűen nincs mit feldolgozni. Ebből a szempontból a szerveroldali renderelés nem SEO-trükk, hanem a tartalom elérhetővé tétele.

Források és további olvasnivalók

• Google Search Central, JavaScript SEO alapok és a dinamikus renderelésről szóló útmutató
• Google Search Essentials, spam-irányelvek (cloaking meghatározása)
• Google Search Central, a Google crawlereinek ellenőrzése és IP-tartományai
• OpenAI dokumentáció, GPTBot és a crawlerek IP-tartományai
• Schema.org, strukturált adat szókincs
• W3C, HTTP gyorsítótárazás és a Vary fejléc leírása (RFC 9110, RFC 9111)
• Bing Webmaster Guidelines, cloaking és dinamikus kiszolgálás