Sütibanner és consent-fal hatása az AI-botokra

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

Miért láthatja üresnek az oldaladat egy AI-bot a sütibanner miatt?

Ha a sütibanner vagy a consent-fal úgy működik, hogy a tényleges szöveg csak a gombnyomás után kerül be az oldalba, akkor a bot egy szinte üres HTML-t kap, benne egy beleegyezést kérő dobozzal. A bot nem kattint az „Elfogadom” gombra, így számára a cikk, a termékleírás vagy a szolgáltatásoldal egyszerűen nem létezik.

A keresőrobotok és az AI-rendszerek lekérői jellemzően tiszta lappal érkeznek, sütik nélkül, minden lekérésnél elölről. Ezért minden alkalommal azt a változatot látják, amit egy első látogató a döntés előtt. Ha ez a változat egy teljes képernyős fal, és mögötte semmi nincs, a válaszmotornak nincs mit idéznie, és az oldal forrásként való megjelenésének esélye is csökken.

Hivatalosan igazolt. A Google Search Central JavaScript SEO útmutatója szerint a Google renderelője minden URL-t önállóan tölt be, a HTTP-sütiket, a local storage és a session storage tartalmát nem viszi át egyik betöltésről a másikra. A Google azt is jelzi, hogy a renderelés során nem lép interakcióba az oldallal, tehát nem kattint és nem görget úgy, mint egy ember. Az OpenAI, az Anthropic és a Perplexity nyilvánosan leírja a botjai nevét (például GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot), a JavaScript-futtatásról viszont nem adnak részletes, kötelező érvényű leírást.

Szakmai feltételezés, független mérésekkel alátámasztva. Több nyilvános elemzés szerint az AI-cégek tanító- és keresőbotjainak jelentős része a nyers HTML-t dolgozza fel, a JavaScriptet nem futtatja. Ha a tartalmad csak kliensoldali szkripttel kerül a helyére, ezek a botok jó eséllyel semmit nem látnak belőle, banner nélkül sem.

A böngészővel dolgozó AI-ügynökök más helyzetben vannak. Ők valódi böngészőt használnak, tehát látják a bannert, és megpróbálhatnak rákattintani. Ez azonban lassítja őket, elakadhatnak egy rosszul felcímkézett gombon, és ha a tartalom a döntésig rejtve marad, a feladatukat (például egy nyitvatartás vagy egy szolgáltatás kikeresését) félbehagyhatják. Szakmai feltételezés.

Mi a különbség a tartalmat elfedő és a tartalom felett megjelenő megoldás között?

A tartalom felett megjelenő banner a már betöltött oldal fölé rajzol egy réteget, a szöveg ott van a HTML-ben, csak vizuálisan takarja. Az elfedő megoldás a döntésig ki sem adja a tartalmat, vagy úgy rejti el, hogy a feldolgozó rendszerek számára ne legyen értelmezhető. Az első a botok szempontjából többnyire ártalmatlan, a második komoly kockázat.

A tartalom felett megjelenő réteg

Ilyenkor a szerver a teljes oldalt visszaküldi, a banner pedig egy külön elem: alsó sáv, sarokdoboz vagy középre helyezett ablak áttetsző háttérrel. A botok a HTML-ből kiolvassák a címeket, a bekezdéseket és a strukturált adatot. A látogató is látja, hogy mögötte ott az oldal, és akkor dönt, amikor akar.

A középre helyezett modális ablak a felhasználói élményt jobban megakasztja, és gyakran a görgetést is letiltja a body elemen (overflow:hidden). Ez a nyers HTML-t olvasó botokat nem érinti, hiszen a szöveg ott van. Egy böngészős ügynököt viszont zavarhat, ezért az alsó sáv vagy a sarokdoboz általában barátságosabb választás.

A tartalmat elfedő megoldás

Ide tartozik minden, ami a döntés előtt visszatartja vagy eltünteti a szöveget. Tipikus minták:

• a szerver a beleegyezési süti hiányában egy külön kapuoldalt ad vissza, átirányítással vagy ugyanazon az URL-en;
• a teljes oldaltörzs egy szkriptben vár, és csak az elfogadás után kerül be a DOM-ba;
• a fő tartalom display:none stílust vagy hidden attribútumot kap, amit csak az elfogadás old fel;
• a tartalom egy iframe-ben vagy harmadik féltől betöltött modulban él, ami beleegyezésig nem töltődik be.

Saját tapasztalat. Auditok során a második és a harmadik minta fordul elő a leggyakrabban. A sablon vagy a bővítmény a „biztonság kedvéért” elrejti a fő tartalmat. A böngészőben ez fel sem tűnik, mert egy kattintás után minden rendben van, a nyers HTML-ben viszont csak a menü, a lábléc és a banner szövege marad.

A display:none külön eset. A szöveg technikailag benne van a HTML-ben, így egy nyers HTML-t olvasó bot kiolvashatja. A renderelő rendszerek viszont a rejtett tartalmat jó eséllyel kisebb súllyal kezelik, és egy böngészős ügynök sem látja azt, ami vizuálisan nincs ott. Szakmai feltételezés.

Egy egyszerű példa a hibás és a jó felépítésre. Hibás, ha a fő elem így indul, és csak a beleegyezés után kap láthatóságot: <main id="tartalom" style="display:none">. Jó, ha a <main> mindig látható, a banner pedig egy külön, rögzített pozíciójú elem, például <div id="consent" role="dialog" aria-label="Sütibeállítások">, amely a tartalom fölött jelenik meg, de nem nyúl hozzá.

Mi a helyzet a beleegyezés előtt nem betöltődő elemekkel?

A beleegyezésig visszatartott elemek többsége rendben van, gond csak akkor adódik, ha tartalmi elem is a beleegyezés mögé kerül. A mérőkódok, remarketing-címkék, chat-widgetek és beágyazott közösségi modulok visszatartása adatvédelmi szempontból indokolt, és a botoknak nem hordoz lényeges információt.

Tartalmi veszteség például ezekben az esetekben keletkezik:

• beágyazott YouTube-videó, amelynek a helyén beleegyezésig csak egy szürke doboz van, és a videó mondanivalója sehol máshol nem szerepel az oldalon;
• Google Térkép beágyazás, amely az egyetlen hely, ahol a cím olvasható;
• harmadik féltől jövő értékelés-widget, amely az egyetlen vélemény-forrás az oldalon;
• külső foglaló- vagy űrlapmodul, amelyben a nyitvatartás vagy a szolgáltatások listája is megjelenik.

Ezeknél az a cél, hogy a lényegi információ szövegként is ott legyen. A cím és a nyitvatartás kerüljön HTML-szövegként az oldalra, a videó mellé írj rövid összefoglalót vagy átiratot, a véleményekből pedig emelj ki néhányat saját szövegként, ha valós és felhasználható idézetről van szó. Így a beágyazás maradhat beleegyezéshez kötve, a tartalom mégsem vész el.

Hivatalosan igazolt. A Google Consent Mode dokumentációja szerint a Google-címkék a beleegyezés állapota szerint módosítják a működésüket. Ez a mérést és a hirdetési funkciókat érinti, az oldal saját tartalmának megjelenítését nem.

Hogyan ellenőrizd lépésről lépésre, mit kap meg egy bot?

Három lekéréssel jó eséllyel kiderül, hogy a banner takarja-e a tartalmat. Kell egy JavaScript nélküli letöltés, egy bot user-agentjével végzett lekérés és a visszakapott HTML szöveges átnézése, ezt pedig a renderelt nézet ellenőrzése egészíti ki.

1. Letöltés JavaScript nélkül. Nyiss egy terminált, és kérd le az oldalt sütik nélkül: curl -s -L https://pelda.hu/szolgaltatas/ -o nyers.html. A -L követi az átirányításokat, így azt is látod, ha a szerver egy kapuoldalra dob. A curl -s -I paranccsal a státuszkódot és a fejléceket is megnézheted.
2. Bothoz hasonló lekérés. Ismételd meg bot user-agenttel, mert egyes bannerek, CDN-ek és tűzfalak a user-agent alapján másképp viselkednek: curl -s -L -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.1; +https://openai.com/gptbot" https://pelda.hu/szolgaltatas/ -o gptbot.html. Ugyanígy kipróbálhatod a Googlebot és a ClaudeBot azonosítójával. Ez csak utánzás, a valódi botot a szerver IP-cím alapján is kezelheti másképp, ezért a szervernaplóban is nézd meg, milyen státuszkódot kapott a valódi bot.
3. A visszaadott HTML átnézése. Keress rá a fő szöveg egy jellegzetes mondatára: grep -c "a bekezdés egy egyedi mondata" nyers.html. Ha az eredmény 0, a szöveg nincs a HTML-ben. Nézd meg a fájlméretet is (wc -c nyers.html gptbot.html), és vesd össze a két változatot (diff nyers.html gptbot.html | head -40).
4. Szöveg kinyerése. Egy közelítő képet ad arról, mit olvas ki egy egyszerű feldolgozó, ha a tageket kiszeded: sed -e 's/<[^>]*>/ /g' nyers.html | less. A szkriptek szövege is megjelenik, azt ugord át, és figyeld, hogy a menü után jön-e érdemi tartalom, vagy rögtön a banner szövege.
5. Renderelt nézet. A Google Search Console URL-ellenőrzőjében az élő URL tesztelése után a renderelt HTML-t és a képernyőképet is látod. Ha a képen csak a consent-fal látszik, a Google renderelője is ezt kapta.
6. Ügynök-szemmel. Egy friss, sütik nélküli böngészőprofilban nyisd meg az oldalt egyszer bekapcsolt, egyszer kikapcsolt JavaScripttel. Nézd meg, olvasható-e a tartalom a döntés előtt, és egyértelmű-e a gombok felirata.

Saját tapasztalat. A hibák nagy része már az első két lépésnél kiderül. Ha a nyers HTML néhány kilobájt, és a lényegi szövegből semmi nincs benne, azzal már van mit a fejlesztő elé tenni.

Mit keress a visszaadott HTML-ben?

A nyers HTML akkor jó, ha a valós oldaltartalom benne van, és a banner csak egy kiegészítő elem. Ezt az ellenőrzőlistát érdemes végigvenni:

• A title, a meta description és a H1 a valós oldaltartalmat tükrözi, nem a banner szövegét.
• A fő szöveg első bekezdései megtalálhatók, nem csak a menü és a lábléc.
• A strukturált adat (JSON-LD) ott van a forrásban, és nem a beleegyezéskezelő vagy egy címkekezelő tölti be.
• A státuszkód 200, és nincs átirányítás egy külön beleegyezési oldalra.
• A fő tartalmat hordozó elemen nincs display:none, hidden attribútum vagy aria-hidden="true".
• A banner szövege külön elemben van, és nem ez az oldal leghosszabb szövegrésze.
• A kanonikus URL és a belső linkek a nyers HTML-ben is megvannak.

Hogyan alakítsd át úgy, hogy az adatvédelmi megfelelés ne sérüljön?

A megoldás lényege, hogy a beleegyezés a sütiket és a követőkódokat szabályozza, a tartalmat pedig mindenki megkapja. Ez a botoknak is jó, és adatvédelmi szempontból is tisztább, mert a látogató kényszer nélkül dönthet.

Hivatalosan igazolt. Az Európai Adatvédelmi Testület (EDPB) hozzájárulásról szóló 05/2020-as iránymutatása szerint a cookie wall, vagyis amikor a tartalomhoz csak a sütik elfogadása után lehet hozzáférni, általában nem eredményez önkéntes, érvényes hozzájárulást. A tartalmat elzáró fal tehát jogi szempontból is kockázatos, a lebontása nem ütközik a megfeleléssel. A Google pedig a jogi kötelezettségből (például sütihasználat miatt) megjelenő felugrókat nem sorolja a zavaró felugró ablakok közé.

A gyakorlati lépések sorrendben:

1. A szerver a fő tartalmat mindig adja ki, beleegyezéstől függetlenül.
2. A banner legyen külön réteg (alsó sáv vagy doboz), amely nem veszi ki a tartalmat a DOM-ból, és stílussal sem rejti el.
3. A mérő-, hirdetési és egyéb nem feltétlenül szükséges szkriptek maradjanak a beleegyezéshez kötve. Google-címkéknél ezt a Consent Mode alapértelmezett „denied” állapotával érdemes beállítani.
4. A beágyazott tartalmi elemek (videó, térkép) helyén legyen szöveges helyettesítő, például rövid leírás, cím és link.
5. A beleegyezéskezelő (CMP) szkriptje töltődjön aszinkron módon, és ne legyen a tartalom megjelenítésének előfeltétele.
6. Ne adj a botoknak külön, banner nélküli változatot user-agent alapján. Ha a felhasználó és a bot lényegesen más tartalmat kap, az könnyen cloakingnak minősülhet, ezért egyszerűbb és biztonságosabb, ha mindenki ugyanazt a HTML-t kapja. Szakmai feltételezés a határesetekre.

Saját tapasztalat. WordPress alatt a legtöbb elterjedt beleegyezéskezelő bővítménynél ez beállítás kérdése. A „teljes oldal blokkolása” vagy „tartalom elrejtése a döntésig” jellegű opciót kell kikapcsolni, és sáv vagy doboz megjelenést választani. Bővítményfrissítés után érdemes újra lefuttatni a fenti ellenőrzést, mert a beállítások ritkán, de visszaállhatnak.

Az adatvédelmi részletekben (melyik sütihez kell hozzájárulás, mit tartalmazzon a tájékoztató) mindig az adatvédelmi tanácsadód vagy jogászod véleménye a mérvadó. Ez a cikk a technikai oldalt írja le.

Mikor kell fejlesztőt bevonni?

Fejlesztő akkor kell, ha a hiba a szerveroldalon vagy a sablon kódjában van, és bővítménybeállítással nem oldható meg. Tipikus jelek:

• a nyers HTML-ben egyáltalán nincs fő tartalom, mert az oldal egy JavaScript-keretrendszerrel (React, Vue, Angular) kliensoldalon épül fel, és nincs szerveroldali renderelés vagy előrenderelés;
• a szerver süti hiányában átirányít vagy más oldalt ad vissza;
• a CDN vagy a tűzfal a bot user-agentekre 403-as hibát vagy kihívás-oldalt ad, ami nem a banner hibája, de a tünet ugyanúgy üres oldal;
• a beleegyezéskezelő egyedi fejlesztés, és a kódban a tartalom megjelenítése a beleegyezési eseményhez van kötve;
• a strukturált adatot a CMP vagy egy címkekezelő tölti be, így a nyers HTML-ből hiányzik.

A fejlesztőnek add át a két lementett HTML-fájlt, a Search Console renderelt képernyőképét és egy mondatban a célt. A fő tartalom legyen benne a nyers HTML-ben, a banner maradjon külön réteg, a követőkódok pedig maradjanak a beleegyezés mögött. Ezzel a feladat pontosan körülírható, és a javítás után ugyanazokkal a parancsokkal vissza is tudod mérni.

Mi hivatalos, mi tapasztalat és mi feltételezés ebben a témában?

• Hivatalosan igazolt. A Google renderelője állapot nélkül, sütik megőrzése nélkül tölti be az oldalakat, és nem lép interakcióba velük. A sütihasználat miatti, jogi kötelezettségből adódó felugrókat a Google nem kezeli zavaró felugróként. Az EDPB szerint a tartalomhoz kötött kényszerű elfogadás általában nem érvényes hozzájárulás. Az AI-cégek nyilvánosan közzéteszik a botjaik nevét.
• Saját tapasztalat. A leggyakoribb hiba a tartalmat stílussal vagy szkripttel elrejtő banner-beállítás. A nyers HTML-lekérés gyorsan megmutatja a gondot, és bővítményfrissítés után érdemes újra ellenőrizni.
• Szakmai feltételezés. Az AI-botok jelentős része nem futtat JavaScriptet, ezért náluk a nyers HTML számít. A böngészős ügynökök a bannernél elakadhatnak. A tartalom felett megjelenő réteg az idézhetőséget jó eséllyel nem rontja. A javítás segítheti a megjelenést, de egyik lépés sem garantál helyezést vagy idézést egy AI-válaszban.

Források és további olvasnivalók

• Google Search Central, A JavaScript SEO alapjai
• Google Search Central, Lusta betöltés (lazy loading) és a Google keresés
• Google Search Console súgó, URL-ellenőrző eszköz
• Google Search Central, Oldalélmény és zavaró felugró ablakok
• Google Search Central, Spam irányelvek (cloaking)
• Google Tag Platform, Consent Mode dokumentáció
• OpenAI, Overview of OpenAI Crawlers
• Anthropic Support, a Claude botjai és a robots.txt
• Perplexity, Perplexity Crawlers
• Európai Adatvédelmi Testület (EDPB), 05/2020 iránymutatás a hozzájárulásról
• W3C, WAI-ARIA specifikáció (aria-hidden, dialog szerepkör)