Egy webshop az AI-keresési láthatóságának 47%-át elvesztette, miután egy frissítés megváltoztatta az oldalak renderelését. Ugyanezek a termékoldalak a Google-ben továbbra is rangsoroltak. A ChatGPT, a Claude és a Perplexity viszont nulla találatot adott. A különbséget a JavaScript-renderelés okozta.
Ez minden olyan oldalon megtörténik, amely kliensoldali renderelésre épít. A Vue.js-sel épített SaaS-nyitóoldal soha nem jelenik meg a ChatGPT válaszaiban. A JavaScript-keretrendszeren futó hírportálnak nulla jelenléte van a Perplexityben. A Reacttel renderelő tudásbázis láthatatlan marad az AI-bejárók számára. Ezek nem szélsőséges esetek. A legtöbb modern webes keretrendszer alapértelmezett működése ez.
A JavaScriptre épülő oldal és az AI számára látható oldal különbsége nem a bonyolultságról vagy a költségvetésről szól. Arról szól, hogy megérted, mi történik azokban az első ezredmásodpercekben, amikor a bejáró megérkezik.
Mit lát az AI-bejáró, amikor letölti az oldaladat
A Google bejárója futtat JavaScriptet. Megvárja, amíg az oldal renderelődik, rögzíti a végső vizuális állapotot, és indexeli. A legtöbb AI-bejáró nem.
Amikor a ChatGPT bejárója (GPTBot) megérkezik az oldaladra, ez a sorrend: 1. Letölti a HTML-fájlt 2. Kinyeri a nyers HTML-ben látható szöveges tartalmat 3. Továbblép a következő oldalra
A JavaScript, amely a címsorodat, a termékleírásodat és a cikked szövegét rendereli, soha nem fut le. A bejáró látja a JavaScript-fájlokra mutató hivatkozásokat, de figyelmen kívül hagyja őket. Az oldalad üres héjnak tűnik, tartalom nélkül.
Ez azért van, mert az AI-bejárókat sebességre és hatékonyságra tervezték. A JavaScript futtatása lassú. Böngészőt kell indítani, meg kell várni az erőforrások betöltését, kezelni kell a hibákat és az időtúllépéseket. Ha naponta milliárdnyi oldalt jársz be, a JavaScript futtatása megfizethetetlenül drága lesz.
A Google azért fektet be ebbe az infrastruktúrába, mert a keresési találatok a vizuális renderelés megértésén múlnak. Az AI-keresők a nyers szöveg kinyerését helyezik előtérbe. Arra optimalizálnak, hogy a tényeket és az idézeteket közvetlenül a HTML-ből vegyék ki, nem abból, amit a JavaScript átalakítása után látni.
Mely renderelési módok okoznak gondot az AI-bejáróknak
Nem minden JavaScript-keretrendszer okoz ugyanakkora láthatósági veszteséget. A probléma kifejezetten a kliensoldali rendereléssel (CSR) van, ahol a JavaScript *a böngészőben* fut, és a HTML betöltése után építi fel az oldalt.
Kliensoldali renderelés (CSR): React, Vue, Angular, Svelte, ha CSR-re állítják. A HTML üresen vagy vázbetöltőkkel érkezik. A JavaScript a letöltés után tölti fel a tartalmat. Az AI-bejárók nem várnak.
Szerveroldali renderelés (SSR): Next.js, Nuxt, Remix, SvelteKit. A szerver úgy építi fel az oldalt, hogy a tartalom már benne van a HTML-ben. A böngésző teljes HTML-t kap. Az AI-bejárók azonnal mindent látnak.
Statikus generálás (SSG): Statikus oldalgenerátorok. Az oldalak előre elkészülnek, és statikus HTML-fájlként kerülnek ki. Kéréskor nem történik renderelés. Az AI-bejárók azonnal megkapják a teljes tartalmat.
Egyoldalas alkalmazások (SPA-k): A legnagyobb kockázatú kategória. Az SPA egyetlen HTML-fájlt tölt be, és JavaScripttel cseréli a tartalmat a navigáció alapján. Minden útvonal azonosnak látszik a bejáró számára, hacsak a szerver nem kezeli külön az egyes útvonalakat.
Abban a pillanatban, hogy a CSR-t választod renderelési stratégiának, láthatatlan akadályt emelsz a tartalmad és az internet minden AI-bejárója közé.
Miért fontosabb ez, mint gondolnád
Az AI-keresés még korai szakaszban van, de az elterjedése gyorsul. A tanulmányok szerint az AI-keresések száma gyorsabban nő, mint a hagyományos webes kereséseké. A ChatGPT, a Perplexity és a Claude egyre inkább elsődleges kutatóeszközzé válik a szakemberek, a diákok és a döntéshozók számára.
Amikor valaki a ChatGPT-ben a „legjobb weboldalépítők kisvállalkozásnak” kifejezésre keres, az AI választja ki, mely márkákat idézi. Ez a döntés azon múlik, melyik tartalmat tudja elolvasni. Ha az oldalad JavaScriptre épül, láthatatlan.
Ez nem jövőbeli probléma. Egy 2025-ös, 500 milliót meghaladó GPTBot-kérést elemző vizsgálat szerint a JavaScriptre épülő oldalak jelentősen kevesebb idézést kaptak, mint a szerveren renderelő versenytársak ugyanabban az ágazatban. A különbség a műszaki tartalmaknál, a termékoldalaknál és az útmutatóknál nőtt a legnagyobbra, pedig az AI-motorok pontosan ezeket a tartalomtípusokat részesítik előnyben.
A B2B- és webshop-vállalkozások számára az AI-idézések versenyképességi láthatósági eszközzé válnak. Egy ChatGPT-válaszban vagy egy Perplexity-kivonatban idézve lenni ugyanakkora forgalmi értéket hozhat, mint egy Google-találati első oldal. Csakhogy nem idézhetnek, ha a bejáró nem tudja elolvasni a tartalmadat.
Hogyan döntsd el, mit tegyél
Nem minden oldalnak kell elhagynia a kliensoldali renderelést. A döntés három tényezőn múlik: a tartalom típusán, a közönségeden, és azon, mennyi üzleti értéke van az AI-keresési láthatóságnak a te helyzetedben.
Először tedd fel magadnak ezeket a kérdéseket:
Idézésre méltó a tartalmad az AI számára? Hírek, útmutatók, termékösszehasonlítások, kutatási cikkek, szakértői tanácsok. Ezeket idézi az AI. Műszaki dokumentáció, interaktív eszközök, elsősorban bejelentkezett felhasználóknak szolgáló vezérlőpultok. Ezeket nem. Ha az oldalad főleg az utóbbi, a JavaScript-renderelés kevésbé számít.
Keres a közönséged AI-motorokban? B2B-szakemberek, termékkutatók, diákok, fejlesztők. Ők sokat használják az AI-keresést. Ha a közönséged nagyon szűk, és kizárólag a Google-ben keres, az AI-láthatóság kevésbé hoz azonnali megtérülést.
Mennyibe kerül a láthatatlanság? Egy hírportálnak vagy tudásbázisnak a nulla AI-idézés versenyhátrány. Egy céges intranetnek vagy csak tagoknak szóló SaaS-nak mindegy. Egy webshopnál azon múlik, hogy a vásárlóid AI-s vásárlási ajánlásokon keresztül találnak-e termékeket.
Ha az „AI-idézésre méltó tartalom”, az „igen, a közönségem használ AI-keresést” és a „az elvesztett láthatóság valódi költség” válaszok igazak, folytasd. Ha vegyesek a válaszok, lehet, hogy máshogy priorizálsz.
Szerveroldali renderelés: a legteljesebb megoldás
Az SSR átfogóan megoldja a JavaScript-problémát. A szerver az összes tartalommal együtt építi fel a teljes oldalt, mielőtt elküldi a böngészőnek. Mire bármelyik bejáró megérkezik, a tartalom már ott van.
Így működik: Amikor valaki (vagy egy bot) kér egy oldalt, a szervered lefuttatja a kódodat, és előállítja a végső HTML-t. Ebben benne van a címsorod, a cikked szövege, a termékadataid. A böngésző kész oldalt kap, és azonnal megjeleníti. A JavaScript továbbra is bővítheti az interaktivitást, de a tartalom már elérhető.
Platformok, amelyekkel egyszerű az SSR: Next.js (React), Nuxt (Vue), Remix, SvelteKit. Ezeket a keretrendszereket kifejezetten arra építették, hogy az SSR egyszerű legyen. Egyszer megírod a komponenseidet, a keretrendszer a szerveren kezeli a renderelést, és az oldal készen érkezik.
A kompromisszum: Az SSR szervererőforrást igényel. A szervered minden kérést feldolgoz, felépíti a HTML-t, és kiküldi. Ez több processzort és memóriát igényel, mint az előre elkészített statikus fájlok kiszolgálása. A lassú vagy összetett oldalak növelhetik a válaszidőt, ami hat a teljesítménymutatókra, például a First Contentful Paintre (FCP) és a Core Web Vitalsra.
A legtöbb oldalnál a teljesítménycsökkenés kicsi. A nagy forgalmú, összetett oldalaknál észrevehetővé válik. Ez gyorsítótárazással, edge computinggal vagy kódoptimalizálással megoldható, de építészeti döntéseket igényel.
Előrenderelés: könnyebb megoldás statikus tartalomhoz
Az előrenderelés előre felépíti az oldalaidat, és statikus HTML-fájlként teszi közzé őket. Amikor egy bejáró megérkezik, azonnal teljes oldalt kap. Amikor valaki meglátogatja, egy statikus fájlt kap, amely rendkívül gyorsan betöltődik.
Az előrenderelő szolgáltatások automatizálják ezt. Rámutatsz az oldaladra, ők végigmennek az oldaltérképed minden URL-jén, megrenderelik az oldalakat (lefuttatva a JavaScriptet), rögzítik a végső HTML-t, és ezeket a statikus változatokat szolgálják ki a bejáróknak, miközben a böngészők továbbra is az interaktív változatot kapják.
Akkor működik, ha: A tartalmad ritkán változik. Blogbejegyzések, termékoldalak, dokumentáció. Olyan tartalom, amely legfeljebb naponta egyszer frissül.
Akkor nem működik, ha: A tartalmad dinamikus. Készletszámok, felhasználóspecifikus adatok, valós idejű információk, személyre szabott tartalom. Ha az oldalad minden látogatónak másképp néz ki, az előrenderelés nem fogja lefedni az összes változatot.
Költség és bonyolultság: Egy ilyen szolgáltatás 99-499 dollárba kerül havonta az oldalak számától függően. Két tartalomkészletet kell fenntartanod: egyet a böngészőnek (JavaScript), egyet előrenderelve a bejáróknak. Ez megduplázza a karbantartás terhét. Amikor új cikket teszel közzé, újra kell építened és telepítened a statikus változatot.
Stabil tartalmú oldalaknál az előrenderelés gyakorlatias középút a semmittevés és az SSR-re áttérés között.
Dinamikus renderelés: taktikai lehetőség egyes oldalaknak
A dinamikus renderelés felismeri, melyik user agent küldi a kérést. Ha bejáró, szerveren renderelt HTML-t szolgál ki. Ha böngésző, a JavaScript-változatot. Így megmarad a meglévő technikai megoldásod, a bejárók pedig teljes tartalmat kapnak.
Elméletben az ötlet elegáns. A gyakorlatban törékeny. Neked kell:
Karbantartanod az AI-bejárók User-Agent listáját, és folyamatosan frissítened, ahogy új bejárók jelennek meg. Ha egyet kihagysz, az a bejáró az üres oldalt látja.
Szerveroldali renderelést építened kifejezetten a bejáróknak, miközben a böngészőknek megmarad a kliensoldali renderelés. Ez lényegében az oldalad két változatának megépítése.
Tesztelned, hogy a két változat szinkronban marad. A bejárói változat hibája csendben tönkreteszi az AI-keresési láthatóságodat.
A dinamikus renderelés egyszerű tartalmi oldalaknál működik. Összetett alkalmazásoknál több a fáradság, mint a haszon. Ha úgyis szerveren renderelsz a bejáróknak, akár mindenkinek renderelhetsz (ez az SSR).
Hogyan derítsd ki, hogy most van-e ilyen problémád
Nem kell találgatnod. Közvetlenül ellenőrizheted.
Nézd meg az oldal forrását: Kattints jobb gombbal az oldaladra, válaszd az „Oldal forrásának megtekintése” lehetőséget, és keresd meg a címsorodat. Ha a címsorod nincs a nyers HTML-ben, JavaScript rendereli. Az AI-bejárók nem fogják látni.
Kérd le curllel: A terminálban futtasd a curl https://yoursite.com/your-page parancsot. Ha a tartalom nincs ott, JavaScript renderelte.
Ellenőrizd a robots.txt-et: Ha megakadályozod, hogy a bejárók JavaScriptet futtassanak, csak a nyers HTML-t fogják látni. Nézd meg a robots.txt fájlodat vagy az oldalad bejárási beállításait.
Használj bejáróeszközt: Egy SEO-bejáróeszköz úgy tudja lekérni az oldalaidat, ahogy egy bejáró. Ha a tartalom megjelenik a böngészőben, de a bejáróban nem, a JavaScript a bűnös.
Keress közvetlenül AI-motorokban: Keress rá a ChatGPT-ben, a Perplexityben vagy a Claude-ban az oldalaid konkrét mondataira. Ha a tartalmad soha nem jelenik meg, JavaScript-láthatósági problémád van.
Platformspecifikus optimalizálás a különböző AI-bejárókhoz
Nem minden AI-bejáró viselkedik egyformán. Eltérő a renderelési képességük, a bejárási gyakoriságuk és a tartalmi preferenciáik.
ChatGPT (GPTBot): Nem futtat JavaScriptet. Nyers HTML-t tölt le. Valós idejű tartalomhoz egy külső keresőindexet használ. Gyakoriság: a már bejáratott tartalomnál nagyjából hetente.
Claude (külső keresőindex): Nem futtat JavaScriptet. Nyers HTML-t tölt le. A friss, tekintélyes tartalmat részesíti előnyben. Gyakoriság: a tartalom frissességi jeleitől függően változik.
Perplexity: Nem futtat JavaScriptet. Nyers HTML-t tölt le. Erősen súlyozza a frissességet. A 48 óránál régebbi tartalom hátrébb sorolódhat. Gyakoriság: felkapott témáknál magas, statikus tartalomnál alacsony.
A Google AI-áttekintései: *Futtat* JavaScriptet, mert ugyanazt a renderelési infrastruktúrát használja, mint a Google Keresés. De optimalizálj úgy, mintha nem tenné, így a többi AI-keresőben is láthatóbb leszel.
A gyakorlati tanulság: ne egy bejáróra optimalizálj. Renderelj szerveren a kulcsfontosságú tartalmaidat, és mindegyik számára látható leszel.
Miben segít a WEMASY
A WEMASY weboldalépítője alapértelmezetten szerveren renderelt HTML-t készít. Minden oldalad úgy épül fel, hogy a tartalom már a HTML-ben van, mielőtt a böngészőhöz ér. Nincs JavaScript-renderelés. Az oldalaid azonnal láthatók az AI-bejárók számára.
Ha weboldalépítőt választasz, és az AI-keresési láthatóság fontos az üzleted számára, a szerveroldali renderelésnek követelménynek kell lennie, nem utólagos ötletnek. Nézd meg, mit tartalmaz az egyes WEMASY-csomagok.
Gyakran ismételt kérdések
Használhatok JavaScriptet interaktív funkciókhoz anélkül, hogy kizárnám az AI-bejárókat?
Igen. Renderelj szerveren a lényegi tartalmat (a címsorodat, a cikked szövegét, a termékadataidat), és használj JavaScriptet a kiegészítésekhez (animációk, űrlapellenőrzés, interaktív widgetek). Ezt hívják progresszív fejlesztésnek. A tartalom már a HTML-ben van, a JavaScript pedig csak csiszol rajta. Az AI-bejárók a lényegi tartalmat látják. A böngészők a teljes interaktív élményt kapják. A WEMASY weboldalépítőjével ezt közvetlenül a weboldaladon állíthatod be.
Lelassítja az oldalamat a szerveroldali renderelésre váltás?
Lassíthat, ha a szervered gyenge, vagy az oldalaid összetettek. A modern, gyorsítótárazási rétegekkel (például modern tárhelyplatformok edge gyorsítótárával) működő szerveroldali renderelés valójában gyorsabb is lehet a kliensoldalinál. A különbség a legtöbb oldalnál kicsi. Ha a teljesítmény aggaszt, a döntés előtt teszteld tesztkörnyezetben.
Le kell cserélnem a teljes technikai megoldásomat?
Ha a Reactet, a Vue-t vagy más JavaScript-keretrendszert CSR-ként használod, a Next.js-re, a Nuxtra vagy hasonló SSR-keretrendszerre váltás azt jelenti, hogy át kell írnod a komponenseidet a szerveroldali rendereléshez. Ez nem gyors csere. Ha az oldalad vadonatúj, az elejétől SSR-first keretrendszert válassz. Ha már működő oldalad van, rövid távon az előrenderelés vagy a dinamikus renderelés lehet a gyakorlatiasabb.
Mi van, ha az AI-bejárók egyszer támogatják a JavaScript futtatását?
Lehetséges, de nem egyhamar. A JavaScript futtatása nagy léptéken számításilag drága. Amíg az AI-idézések üzleti értéke nem indokolja az infrastruktúra költségét, a bejárók továbbra is nyers HTML-t fognak letölteni. Egyelőre renderelj szerveren, és csökkentsd a kockázatot.
Árt a Google-rangsorolásomnak az oldalam JavaScript-renderelési problémája?
Nem. A Google bejárója futtat JavaScriptet, így a Google-rangsorolásodat nem érinti. A gond az olyan AI-keresőkkel van, mint a ChatGPT, a Claude és a Perplexity. Ők nem futtatnak JavaScriptet. Akkor renderelj szerveren, ha láthatóságot akarsz az AI-keresési találatokban, nem azért, mert a Google megköveteli. Ez a SEO-tól külön probléma.
A hírportáloknak ugyanez a JavaScript-problémájuk?
Igen, és gyakran figyelmen kívül marad. A kliensoldalon renderelő JavaScript-keretrendszerre épülő hírportál nulla AI-idézést kap, még ha a tartalom közzé van téve és indexelve is. A hírkiadók véletlenül jöttek rá erre, amikor a Google Hírekben rangsoroló cikkek nulla említést kaptak a ChatGPT-ben vagy a Perplexityben. Nézd meg az oldal forrását. Ha a címsorod nincs ott, javítsd ki.