Hogyan nézd meg az oldaladat úgy, ahogy egy kereső robot látja

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

Ha egy oldal nem jelenik meg a Google-ben, vagy egy AI-asszisztens rendre más forrást idéz helyette, az első gyanú általában a tartalom minősége. Sokszor ennél prózaibb a gond. A robot mást kap a szervertől, mint amit te a böngészőben látsz. Ez a cikk egy saját gépen, néhány paranccsal elvégezhető módszert ad arra, hogyan állítsd elő a robot-nézetet, és mit nézz meg benne.

Háromféle állítást jelölünk a szövegben. Hivatalosan igazolt az, ami a Google Search Central vagy az adott szolgáltató dokumentációjában szerepel. Saját tapasztalat az, amit weboldalak átvizsgálása közben rendszeresen látunk. Szakmai feltételezés az, ami logikus következtetés, de hivatalos megerősítés nincs rá.

Mit jelent, hogy úgy nézed az oldalt, ahogy a robot látja?

Azt jelenti, hogy az oldalnak két változatát vizsgálod. Az egyik a nyers HTML, amit a szerver egy böngésző nélküli kliensnek küld, a másik a renderelt változat, ami a JavaScript lefutása után áll elő. A legtöbb indexelési rejtély a kettő közötti különbségből ered.

Hivatalosan igazolt. A Google a JavaScriptet használó oldalakat három lépésben dolgozza fel, ezek a feltérképezés, a renderelés és az indexelés. A renderelést rendszeresen frissített, Chromium alapú motor végzi, az oldal viszont előbb egy renderelési sorba kerül. A JavaScript által előállított tartalmat tehát a Google később látja, mint a nyers HTML-t. Ezt a Search Central JavaScript SEO alapjairól szóló útmutatója írja le.

Szakmai feltételezés. Az AI-keresők robotjairól kevesebb a hivatalos információ. Az OpenAI dokumentálja a robotjai nevét (GPTBot, OAI-SearchBot, ChatGPT-User) és a céljukat, de részletesen nem írja le, hogy futtatnak-e JavaScriptet. Független mérések szerint több AI-robot csak a nyers HTML-t dolgozza fel. Ha ez igaz, akkor ami a nyers forrásban nincs benne, az ezeknek a rendszereknek jó eséllyel nem létezik.

Saját tapasztalat. A nyers forrás átnézése nagyjából öt perc, és a „miért nem indexeli a Google” típusú kérdések nagy részét már itt el lehet dönteni. Rossz canonical, bent felejtett noindex, JavaScriptből betöltött főszöveg, gomb a link helyén. Ezek mind kiderülnek, mielőtt bármilyen fizetős auditeszközt megnyitnál.

Hogyan töltsd le az oldalt böngésző nélkül?

A legegyszerűbb eszköz a curl. macOS-en és a legtöbb Linuxon eleve telepítve van, Windows 10 óta pedig a parancssorban is elérhető. Letölti a szerver válaszát, és semmit nem futtat belőle.

Kezdd a válasz fejlécével, mert az állapotkód és néhány fejléc önmagában is eldönthet egy kérdést.

curl -sIL https://pelda.hu/oldal/

Az -I csak a fejlécet kéri, az -L követi az átirányításokat. Figyeld az állapotkódot (200, 301, 404, 5xx), az átirányítási lánc hosszát, az X-Robots-Tag fejlécet és az esetleges Link fejlécet canonical értékkel. Az X-Robots-Tag azért érdekes, mert abban is állhat noindex, és a forráskódban ezt sosem látod.

Utána mentsd el magát a HTML-t fájlba.

curl -sL --compressed https://pelda.hu/oldal/ -o nyers.html

A --compressed azért kell, mert enélkül egyes szerverek tömörített választ küldenek, és a fájl olvashatatlan lesz. Nézd meg a fájl méretét is (wc -c nyers.html). Ha gyanúsan kicsi, néhány kilobájt egy tartalmas oldalnál, az már jelzés. Egy tipikus egyoldalas JavaScript-alkalmazás nyers HTML-je gyakran egyetlen üres div és néhány script-hivatkozás.

Böngészőben is megnézheted a nyers forrást. Chrome-ban az URL elé írt view-source: előtag a szerver eredeti válaszát mutatja, a Fejlesztői eszközök Elements panelje viszont már a renderelt állapotot. Saját tapasztalatunk szerint ezt a kettőt nagyon sokan összekeverik, és a renderelt nézetből vonnak le következtetést a nyers forrásra.

Mit keress a nyers HTML-ben?

Öt dolgot érdemes végignézni, a főszöveget, a címsorokat, a belső linkeket, a strukturált adatot, végül a canonicalt a meta robots címkével együtt.

Megvan-e a főszöveg?

Válassz ki egy jellegzetes mondatrészletet az oldal közepéről, amit a böngészőben látsz, és keresd meg a letöltött fájlban.

grep -c 'jellegzetes mondatrészlet' nyers.html

Ha az eredmény 0, a szöveg nem a szerverről érkezik, a böngészőben áll elő. Ékezetes szövegnél számíts rá, hogy a forrásban HTML-entitásként is szerepelhet (például á), ezért érdemes ékezet nélküli szavakból álló részletet keresni. Ha az egész látható szöveget akarod átfutni, a lynx -dump nyers.html olvasható szöveggé alakítja a fájlt, és a hivatkozásokat a végén számozva listázza.

Rendben vannak-e a címsorok?

grep -o '<h[1-3][^>]*>[^<]*' nyers.html

Ez kilistázza a H1-H3 címsorok elejét. Nézd meg, van-e H1, egy van-e belőle, és azt mondja-e, amiről az oldal szól. Saját tapasztalat, hogy sok sablon a logót vagy egy slider feliratát teszi H1-be, a valódi oldalcím pedig egy nagy betűs, formázott div lesz.

Valódi linkek-e a belső linkek?

grep -o 'href="[^"]*"' nyers.html | sort -u > linkek_nyers.txt

Nyisd meg a listát, és keresd meg benne a főmenü, a kategóriák és a lapozó hivatkozásait. Hivatalosan igazolt. A Google akkor tudja megbízhatóan követni a linkeket, ha azok a elemek href attribútummal. A kattintásra JavaScriptből navigáló gombot vagy az onclick eseményt nem tekinti feltérképezhető linknek. Ha a menüd a nyers forrásban nem jelenik meg href-ként, a mélyebb oldalakat a robot csak a sitemapből vagy külső hivatkozásokból ismerheti meg.

Ott van-e a strukturált adat?

grep -c 'application/ld+json' nyers.html

Ha a JSON-LD blokkot egy címkekezelő, például a Google Tag Manager szúrja be, a nyers forrásban nem lesz ott. Hivatalosan igazolt, hogy a Google a JavaScripttel beillesztett strukturált adatot is fel tudja dolgozni, de ehhez a renderelésig várnia kell. Szakmai feltételezés, hogy az AI-keresők számára a nyers HTML-ben elhelyezett JSON-LD a biztosabb út, mert nem függ attól, fut-e náluk JavaScript.

Mit mond a canonical és a meta robots?

grep -io '<link[^>]*canonical[^>]*>' nyers.html

grep -io '<meta[^>]*robots[^>]*>' nyers.html

Ellenőrizd, hogy a canonical abszolút URL-e, a saját oldalra mutat-e (vagy szándékosan máshova), és egyezik-e a protokoll, a www-s alak és a záró perjel az élő változattal. A meta robotsnál a fejlesztés közben bent felejtett noindex a leggyakoribb baleset. Hivatalosan igazolt, hogy ha a nyers HTML-ben noindex áll, a Google kihagyhatja a renderelést, így hiába veszi ki később a JavaScript. A Google azt is kéri, hogy JavaScripttel ne írd át a canonicalt más értékre, mint ami a nyers forrásban szerepel.

Hogyan derül ki, mi hiányzik JavaScript nélkül?

Úgy, hogy a nyers forrás mellé előállítod a renderelt változatot is, és a kettőt összeveted. A különbség pontosan az a tartalom, ami a robot számára csak a renderelés után létezik.

A renderelt DOM-ot fej nélküli Chrome-mal mentheted le. macOS-en ez a parancs így néz ki.

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless --dump-dom https://pelda.hu/oldal/ > renderelt.html

Linuxon ugyanez google-chrome --headless --dump-dom alakban fut. Ezután jöhet az összevetés, először a linkekre.

diff <(grep -o 'href="[^"]*"' nyers.html | sort -u) <(grep -o 'href="[^"]*"' renderelt.html | sort -u)

A > jellel kezdődő sorok azok a linkek, amelyek csak a renderelés után jelennek meg. Ugyanezt megcsinálhatod a címsorokra, a canonicalra és a JSON-LD blokkokra, a korábbi grep mintákkal. Ha a főszöveg jellegzetes mondata a renderelt fájlban megvan, a nyersben nincs, akkor biztosan tudod, hogy a tartalmad JavaScript-függő.

Gyorsabb, kevésbé precíz alternatíva, ha a böngészőben kapcsolod ki a JavaScriptet. Chrome-ban a Fejlesztői eszközök parancspalettáján (Ctrl+Shift+P, Macen Cmd+Shift+P) a „Disable JavaScript” paranccsal teheted meg, majd újratöltöd az oldalt. Amit így nem látsz, az a nyers forrásban sincs benne.

Hivatalosan igazolt. A Google saját renderelt nézetét a Search Console URL-ellenőrzés eszközében látod. Az élő URL tesztelése után a tesztelt oldal megtekintésénél a Google által renderelt HTML-t, a további információknál pedig a be nem töltött erőforrásokat is megtalálod. A Szabályos keresési eredmények teszt ugyanígy megmutatja a renderelt kódot. Ez a legközelebbi hivatalos megfelelője annak, amit a Google lát, ezért a saját parancsaid eredményét érdemes ezzel visszaigazolni.

Mire jó a felhasználó-azonosító karakterlánc cseréje, és mire nem?

A user-agent cseréjével azt ellenőrzöd, hogy a szerver más tartalmat ad-e egy robotnak, mint egy böngészőnek. Magát a robotot nem utánozza, csak a névjegyét küldi el.

curl -sL --compressed -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://pelda.hu/oldal/ -o googlebot.html

curl -sL --compressed -A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36' https://pelda.hu/oldal/ -o bongeszo.html

wc -c googlebot.html bongeszo.html

Ha a méret és a tartalom érdemben eltér, nézd meg a különbséget diff paranccsal. AI-robotok esetén a szolgáltató dokumentációjában megadott aktuális karakterláncot használd, az OpenAI például külön oldalon közli a GPTBot és az OAI-SearchBot azonosítóját. Saját tapasztalatunk szerint az eltérés mögött általában három ok egyike áll.

• Dinamikus renderelés, amikor a robot előre renderelt, gyakran elavult pillanatképet kap.
• Gyorsítótárazó bővítmény vagy CDN, amely robotoknak külön változatot tárol, és azt ritkábban frissíti.
• Biztonsági szabály, amely a robot nevű kéréseket blokkolja, lassítja vagy captchával válaszol rájuk.

Hivatalosan igazolt. A Google a dinamikus renderelést megkerülő megoldásnak tekinti, hosszú távra a szerveroldali vagy statikus renderelést javasolja. Ha a robot és a látogató ugyanazt a tartalmat kapja, csak más technikával, az a Google szerint nem álcázás. Ha a robotnak szánt változat tartalmilag eltér, az már sértheti a spam-irányelveket.

Mikor félrevezető ez a teszt?

Akkor, ha a szerver nem a user-agent alapján dönt, vagy ha a Google renderelése többet lát, mint a te nyers letöltésed. Ilyenkor a saját parancsod mást mutat, mint ami a valóságban történik, és a helyes következtetéshez a Search Console adataira van szükség.

• IP-alapú ellenőrzés. Sok tűzfal és CDN visszaellenőrzi, hogy a Googlebot nevű kérés tényleg a Google címeiről jön-e. A Google ehhez hivatalosan közzéteszi az IP-tartományait, és leírja a fordított DNS-ellenőrzést. A hamis Googlebot user-agenttel küldött curl-t ezek letilthatják, miközben a valódi robot gond nélkül átjut. A 403-as válasz ilyenkor a te gépedről szól, a Google élményéről nem.
• Földrajzi eltérés. A Google dokumentációja szerint a Googlebot jellemzően amerikai IP-címekről tölt le. Ha az oldal ország vagy nyelv alapján irányít át, a magyar IP-ről futtatott teszted mást kap, mint a robot.
• Gyorsítótár. A CDN neked más változatot adhat ki, mint egy órával korábban a robotnak. Ha gyanús, töltsd le többször, vagy nézd a Search Console-ban a feltérképezett változatot.
• A Google mégis látja a JavaScriptes tartalmat. Ha a főszöveg csak a renderelt változatban van meg, a Google jó eséllyel indexeli, csak később. A nyers forrás hiánya tehát önmagában nem Google-probléma. Az AI-robotoknál és a lassú indexelésnél számít igazán.
• Interakcióhoz kötött tartalom. A Google renderelője nem kattint fülekre, és hivatalos útmutatója szerint a görgetésre betöltődő tartalmat sem érdemes görgetéshez kötni. A --dump-dom ugyanígy nem kattint, tehát a fülek mögé, kattintásra betöltött szöveg egyik nézetben sem jelenik meg.
• Mobil és asztali változat. A Google mobilos indexelést használ, ezért ha az oldal eszköz szerint mást küld, mobilos user-agenttel is töltsd le.

Mi az ötperces ellenőrzőlista?

Ez a lista egy oldal átnézésére elég. A sorrend szándékos, elöl vannak a legolcsóbban kideríthető és legnagyobb hatású hibák.

1. Az állapotkód 200, és legfeljebb egy átirányítás van előtte (curl -sIL).
2. Nincs noindex sem a meta robots címkében, sem az X-Robots-Tag fejlécben.
3. A robots.txt nem tiltja az URL-t, és a CSS- meg JavaScript-fájlokat sem (curl -s https://pelda.hu/robots.txt).
4. A canonical abszolút URL, a helyes oldalra mutat, és a nyers meg a renderelt változatban ugyanaz.
5. A főszöveg egy jellegzetes mondata benne van a nyers HTML-ben.
6. Egy H1 van, és a nyers forrásban is az a szöveg áll benne, amit a látogató lát.
7. A menü és a fontos belső linkek href attribútummal szerepelnek a nyers forrásban.
8. A JSON-LD blokk a nyers forrásban van, és a Schema.org validátor vagy a Szabályos keresési eredmények teszt nem jelez hibát.
9. Robot és böngésző user-agenttel letöltve lényegében ugyanaz a tartalom jön.
10. A Search Console URL-ellenőrzésben a renderelt HTML megerősíti a fentieket.

Ha mind a tíz pont rendben van, és az oldal mégsem kerül be az indexbe, a technikai elérhetőség valószínűleg nem akadály. Ilyenkor a tartalom egyediségét, a duplikációt és a belső linkelés súlyát érdemes vizsgálni. A lista ezt a kört zárja le, indexelést vagy AI-hivatkozást garantálni nem tud, de megmutatja, hogy a robot egyáltalán megkapja-e azt, amit szerinted kap.

Források és további olvasnivalók

• Google Search Central, A JavaScript SEO alapjai
• Google Search Central, A Google feltérképező robotjainak és IP-címeinek ellenőrzése
• Google Search Central, Dinamikus renderelés mint megkerülő megoldás
• Google Search Central, Strukturált adatok generálása JavaScripttel
• Google Search Central, Feltérképezhető linkek
• Google Search Console Súgó, URL-ellenőrzés eszköz
• OpenAI dokumentáció, Overview of OpenAI Crawlers
• Schema.org dokumentáció és validátor
• Chrome for Developers, Headless Chrome