Fülek és lenyíló blokkok mögé rejtett tartalom indexelése

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

Szinte minden weboldal-tervezésnél előjön a kérdés, hogy a GYIK-et, a műszaki adatokat vagy a hosszabb leírást szabad-e fülek, akkordeonok vagy egy „tovább olvasom” gomb mögé tenni. A rövid válasz az, hogy a megoldás technikai módjától függ, és ma már két közönségre kell gondolni, a Google-re és az AI-alapú válaszmotorok crawlereire. Ez a cikk végigveszi, mit tudunk biztosan, mit tapasztalunk a gyakorlatban, és hogyan ellenőrizheted a saját oldaladon tíz perc alatt.

A szövegben jelölöm, melyik állítás hivatalosan igazolt (a Google vagy más szolgáltató nyilvános dokumentációja, illetve képviselőinek nyilvános nyilatkozata), melyik saját tapasztalat (oldalak vizsgálata során visszatérően látott jelenség), és melyik szakmai feltételezés (logikus, de nyilvánosan nem megerősített következtetés).

Látja-e a Google a fülek és akkordeonok mögé rejtett szöveget?

Igen, ha a szöveg az oldal betöltésekor már benne van a HTML-ben, és csak CSS-sel vagy egy osztály-váltással van elrejtve. Ilyenkor a Google a tartalmat indexeli, és a mobil-első indexelés óta a súlyozásban sem kezeli hátrányosan.

Hivatalosan igazolt. A Google képviselői (többek között Gary Illyes és John Mueller) a mobil-első indexelés bevezetésekor többször kijelentették, hogy a felhasználói élmény miatt összecsukott, fülekbe rendezett tartalmat teljes értékűként kezelik. Az indoklás egyszerű. Mobilon a képernyőhely szűkös, ezért az akkordeon bevett, felhasználóbarát minta, és a Google nem akarja büntetni. Korábban, az asztali indexelés idején az volt a hivatalos szóhasználat, hogy a rejtett tartalom kisebb súlyt kaphat. Ezt a mobil-első váltással felülírták.

Fontos határvonal, hogy ez a jóindulat a felhasználói élményt szolgáló elrejtésre vonatkozik. A Google spam-irányelvei továbbra is tiltják a rejtett szöveget, amelynek célja a keresőmotor manipulálása (például kulcsszólista fehér betűvel, a képernyőn kívülre tolt blokk, nulla méretű betű). A különbség a szándékban és a hozzáférhetőségben van. Ha a látogató egy kattintással ugyanazt a szöveget elolvashatja, amit a Googlebot lát, akkor nincs gond.

Mi a különbség a DOM-ban rejtett és a kattintásra betöltött tartalom között?

A DOM-ban rejtett tartalom már megérkezett a böngészőbe, csak nem látszik. A kattintásra betöltött tartalom viszont addig nem is létezik az oldalon, amíg valaki rá nem kattint, és a crawlerek nem kattintanak. Ez a cikk legfontosabb megkülönböztetése.

1. típus: jelen van, de vizuálisan rejtett

Ide tartozik minden olyan megoldás, ahol a szerver a teljes szöveget elküldi, és a böngésző csak a megjelenítést szabályozza. Tipikus példák:

• a natív <details> és <summary> elempár,
• CSS-sel display: none vagy max-height: 0 állapotban tartott akkordeon-panel, amit egy osztály-váltás nyit ki,
• a legtöbb WordPress-építő (Elementor, Gutenberg-blokkok) alapértelmezett fül- és akkordeon-eleme, amely a szöveget előre kiírja a HTML-be,
• a hidden="until-found" attribútum, amelyet a böngésző oldalon belüli keresése automatikusan kinyit.

Egy tiszta, keresőbarát akkordeon így néz ki:

<details><summary>Mennyi ideig tart a beköltözés előtti festés?</summary><p>Egy átlagos, két szobás lakásnál ...</p></details>

Itt a válasz szövege a nyers forrásban szerepel, JavaScript sem kell hozzá.

2. típus: kattintásra JavaScripttel lekért tartalom

A másik csoportban a gombnyomás egy hálózati kérést indít (fetch, AJAX, admin-ajax.php), és a válasz csak ezután kerül az oldalba. Leegyszerűsítve:

gomb.addEventListener('click', () => fetch('/api/gyik/12').then(r => r.text()).then(html => panel.innerHTML = html));

Hivatalosan igazolt. A Google lusta betöltésről (lazy loading) szóló dokumentációja kifejezetten kimondja, hogy a Googlebot nem interakcióba lépve tölti be az oldalt, nem kattint és nem görget úgy, mint egy felhasználó. Ezért azt javasolja, hogy a tartalom akkor töltődjön be, amikor a nézetablakba kerül, ne felhasználói műveletre. A fenti mintában a panel tartalma a renderelt HTML-ben üres marad, tehát a Google számára jellemzően nem létezik.

Ugyanez igaz a „tovább olvasom” gombokra. Ha a gomb csak egy CSS-osztályt kapcsol, és a teljes szöveg már ott van, akkor 1. típusú. Ha a gomb a cikk második felét külön kéréssel hozza le, akkor 2. típusú, és a második fél a keresők szemében jó eséllyel hiányzik.

Mit látnak ebből az AI-crawlerek, például a GPTBot vagy a ClaudeBot?

A legtöbb AI-crawler csak a nyers HTML-t olvassa, JavaScriptet nem futtat. Az 1. típusú rejtett szöveget így jó eséllyel látják, a 2. típusút szinte biztosan nem.

Szakmai feltételezés, független mérésekkel alátámasztva. Egy 2024-es, nagy forgalmú oldalakon végzett iparági elemzés (Vercel és MERJ) azt találta, hogy az OpenAI és az Anthropic crawlerei letöltenek ugyan JavaScript-fájlokat, de nem hajtják végre azokat. A szolgáltatók dokumentációja (OpenAI, Anthropic) a crawlerek céljait és a robots.txt-kezelést írja le, a renderelésről viszont nem ad részletes, hivatalos leírást, ezért ezt nem tekintem véglegesnek. A gyakorlati következmény mindenesetre az, hogy egy JavaScripttel összerakott oldal ezeknek a crawlereknek akár üresnek is tűnhet.

Más a helyzet a Google saját AI-felületeivel. Az AI-áttekintések (AI Overviews) és a Gemini a Google keresési indexére és renderelő infrastruktúrájára épülnek, a Google-Extended pedig nem külön crawler, csak egy robots.txt-token, amellyel a Googlebot által begyűjtött tartalom AI-modellekhez való felhasználását szabályozhatod. Ezeknél tehát nagyjából ugyanaz a szabály érvényes, mint a klasszikus keresésnél.

Saját tapasztalat. Szerver naplók vizsgálatakor rendszeresen azt látjuk, hogy az AI-botok egy oldalt egyszer, gyorsan lekérnek, és nem kérik le a fülek mögötti tartalmat kiszolgáló admin-ajax vagy REST-végpontokat. Ami tehát nincs benne az első HTML-válaszban, az a gyakorlatban kimarad abból, amit idézni tudnak.

Hogyan tesztelheted, hogy a rejtett tartalom indexelhető-e?

Válassz ki egy egyedi mondatot a fül vagy akkordeon belsejéből, és keresd meg háromféle nézetben: a JavaScript nélküli forrásban, a renderelt HTML-ben és a Google találatai között. Ha mindháromban megvan, rendben vagy.

1. Egyedi tesztmondat kiválasztása. Olyan mondatot keress a lenyíló blokk belsejéből, amely máshol nem szerepel az oldalon (például egy konkrét kérdésre adott válasz második mondatát).
2. Nyers forrás ellenőrzése. Nyisd meg az oldal forrását (Chrome-ban Ctrl+U, Macen Cmd+Option+U), és keress rá a mondatra. Fontos, hogy ez a szerver eredeti válasza, nem a fejlesztői eszközök Elements panelje, mert az már a JavaScript utáni állapotot mutatja. Ha itt megtalálod, az AI-crawlerek jó eséllyel látják.
3. Próba JavaScript nélkül. A Chrome DevTools parancspalettájában (Ctrl+Shift+P) írd be, hogy „Disable JavaScript”, majd töltsd újra az oldalt. Ha a lenyíló blokkok ilyenkor üresek, vagy a szöveg el sem érhető, valószínűleg 2. típusú megoldásod van. Parancssorból is gyors a próba, például curl -s -A "GPTBot" https://pelda.hu/oldal | grep "tesztmondat".
4. Renderelt HTML a Search Console-ban. Az URL-vizsgálat eszközben futtass élő tesztet, majd a „Tesztelt oldal megtekintése” panelen nyisd meg a HTML fület, és keress rá a mondatra. Ez azt mutatja, amit a Google renderelő szolgáltatása lát. Ha nincs Search Console-hozzáférésed, a Gazdag találatok tesztje ugyanilyen renderelt HTML-t ad.
5. Indexállapot ellenőrzése. Néhány nappal a feltérképezés után keress rá a Google-ben idézőjelek között a tesztmondatra, a site: operátorral szűkítve. Ez csak jelzésértékű, mert a Google nem minden indexelt szövegrészt mutat meg ilyen keresésre, de ha a mondat megjelenik, az erős visszaigazolás.

Az eredmény értelmezése egyszerű. Ha a mondat a nyers forrásban is megvan, mindenkinek elérhető. Ha csak a renderelt HTML-ben látszik, a Google látja, az AI-crawlerek többsége nem. Ha egyik helyen sincs, akkor kattintásra töltődik, és a gépek számára gyakorlatilag nem létezik.

Mi kerülhet nyugodtan lenyíló blokkba, és mi ne?

Az a tartalom maradjon nyitva, amire az oldal választ ad, vagyis amiért a látogató és a válaszmotor jön. Lenyíló blokkba az kerülhet, ami kiegészít, pontosít vagy csak a látogatók egy kisebb részét érdekli.

A gyakorlatban ezt a döntési szabályt használom (ez saját tapasztalaton alapuló szakmai ajánlás, nem a Google előírása):

Maradjon nyitva, látható szövegként

• az oldal fő kérdésére adott tömör válasz, az első bekezdés,
• a szolgáltatás vagy termék lényege (mit, kinek, hol, milyen feltételekkel),
• a települések és szolgáltatási terület felsorolása, ha helyi keresésre is szeretnél megjelenni (például „Székesfehérváron és Budapesten is vállaljuk”),
• minden olyan állítás, amelyet szeretnéd, ha egy AI-válasz idézne vagy hivatkozna.

Mehet lenyíló blokkba (1. típusú megoldással)

• GYIK-válaszok, ha a kérdések maguk látszanak,
• részletes műszaki adatok, méretek, kompatibilitási listák,
• szállítási, jótállási és visszaküldési részletek egy termékoldalon,
• hosszabb háttérmagyarázat, amely a fő választ csak alátámasztja.

Ne kerüljön kattintásra betöltött (2. típusú) blokkba

• semmi, aminek a keresőkben vagy AI-válaszokban meg kellene jelennie,
• strukturált adattal (például FAQPage) jelölt tartalom, mert a jelölésnek a látható oldalt kell tükröznie,
• belső linkek, amelyeken keresztül a crawler más oldalakat fedezne fel.

Egy gyors önellenőrző kérdés segít. Ha ezt a blokkot valaki egyáltalán nem nyitja ki, akkor is megkapta, amiért jött? Ha igen, a blokk mehet lenyíló formába. Ha nem, a tartalom túl fontos ahhoz, hogy elrejtsd.

Számít-e a súlyozásban, hogy a szöveg alapból rejtett?

A Google hivatalos álláspontja szerint mobil-első indexelésnél nem. A gyakorlatban ettől függetlenül érdemes a lényeget láthatóan tartani, mert a felhasználói jelek és a kiemelt részletek kiválasztása is ezt díjazhatja.

Szakmai feltételezés. Arra nincs nyilvános bizonyíték, hogy egy akkordeonban lévő bekezdés rosszabbul rangsorolna, mint ugyanaz nyitva. Azt viszont logikusnak tartom, hogy az oldal tetején, látható helyen lévő, jól tagolt válasz könnyebben kerül kiemelt részletbe vagy AI-összefoglalóba, mert egyértelműbb, mi az oldal fő mondanivalója. Ugyanígy feltételezés, de életszerű, hogy egy AI-modell a szöveg sorrendjét és hangsúlyát is figyelembe veszi, amikor eldönti, mi a legjobb idézhető rész.

Saját tapasztalat. A rendezett, kérdés-válasz szerkezetű GYIK-akkordeonok a natív <details> megoldással jellemzően gond nélkül indexelődnek. A problémák szinte mindig a bővítményekből jönnek, amelyek a teljesítmény javítására hivatkozva csak kattintáskor kérik le a tartalmat, vagy egy keresőbarát elemet utólag cserélnek JavaScript-alapúra egy frissítés során.

Milyen gyakori hibákat érdemes ellenőrizni?

A leggyakoribb hiba az, hogy a lenyíló elem a fejlesztő gépén jól működik, de a tartalom nincs benne a szerver első válaszában. Ezeket érdemes rendszeresen végignézni:

• Teljesítmény-bővítmény késleltetett JavaScripttel. Egyes optimalizáló bővítmények a fül-szkriptet csak az első interakció után töltik be. Ha a fül tartalmát is a szkript rakja össze, az a crawlernek üres.
• Kliensoldali renderelés (React, Vue) szerveroldali renderelés nélkül. Ilyenkor a nyers forrásban szinte semmi nincs, és az AI-crawlerek egy üres vázat kapnak.
• Eltérő mobil- és asztali tartalom. Ha mobilon kevesebb szöveg kerül a HTML-be, a Google a mobil változatot indexeli, így a többlet elveszik.
• FAQPage jelölés kattintásra töltött válaszokkal. A strukturált adat ilyenkor olyan szöveget ír le, amely a renderelt oldalon nem látszik, ez ellentmond a Google irányelveinek.
• Fül-váltás URL-paraméterrel. Ha minden fül külön URL-en (például ?tab=adatok) érhető el, kanonikus és duplikált tartalmi kérdések jöhetnek elő, ezt külön érdemes rendezni.

Rövid ellenőrzőlista a következő oldaladhoz

Ha az alábbi pontok mindegyikére igen a válasz, a lenyíló blokkjaid jó eséllyel nem okoznak indexelési gondot.

• A lenyíló blokkok szövege benne van a nyers HTML-forrásban.
• JavaScript kikapcsolásával is elérhető a szöveg, vagy legalább a forrásban ott van.
• A Search Console URL-vizsgálat renderelt HTML-jében megtalálod a tesztmondatot.
• Az oldal fő válasza és a szolgáltatás lényege nyitva, látható helyen áll.
• A strukturált adat csak olyan tartalmat jelöl, ami az oldalon tényleg elérhető.
• Mobilon és asztalon ugyanaz a szöveg kerül a HTML-be.
• Egy bővítmény-frissítés után újra lefuttatod a tesztet.

Ezek a lépések nem adnak biztos rangsor-előnyt, és nem pótolják a jó tartalmat. Annyit viszont elérhetsz velük, hogy a gondosan megírt szöveged ne vesszen el a gépek elől egy technikai döntés miatt.

Források és további olvasnivalók

• Google Search Central: Mobil-első indexelés, ajánlott eljárások
• Google Search Central: A lusta betöltésű tartalom javítása (lazy loading)
• Google Search Central: A JavaScript SEO alapjai
• Google Search Central: Spam-irányelvek, rejtett szöveg és linkek
• Google Search Console súgó: URL-vizsgálat eszköz
• Google Search Central: GYIK (FAQPage) strukturált adat
• OpenAI dokumentáció: Az OpenAI crawlerei (GPTBot, OAI-SearchBot)
• Anthropic támogatási oldal: Az Anthropic webes crawlerei
• WHATWG HTML szabvány: a details, a summary elem és a hidden attribútum
• Vercel és MERJ: Az AI-crawlerek JavaScript-kezelésének elemzése (2024)