- A Google a Googlebot Smartphone által látott tartalmat indexeli, az asztali nézet többlete önmagában nem segít.
- A legtöbb veszteséget a mobilról kihagyott szöveg, a hiányzó strukturált adat, a megkurtított menü és a kattintásra betöltődő tartalom okozza.
- A Search Console URL-vizsgálata megmutatja a feltérképezett HTML-t, egy mobil user-agenttel futtatott crawler pedig az egész oldalra kiterjeszti az összevetést.
- Oldalépítőnél a külön mobil- és asztali blokk kétszeres karbantartást jelent, és a két példány idővel szinte mindig eltér egymástól.
- Az egyetlen, reszponzívan átrendeződő tartalom a legbiztosabb megoldás, mert nincs mit szinkronban tartani.
Sok weboldalt asztali monitoron terveznek, asztali monitoron hagynak jóvá, és a mobilnézet a végén kap egy gyors igazítást. Ilyenkor kerül le mobilról egy hosszabb szövegblokk, egy táblázat vagy a menü fele, mert kis képernyőn „nem fért el”. A látogató ebből keveset érzékel, a kereső viszont a mobilváltozatból dolgozik. Ez a cikk azt mutatja meg, hol szokott eltérni a két változat, hogyan tudod ezt kimérni, és mit érdemes átnézned, ha az oldalad oldalépítővel készült.
A szövegben három jelölést használunk. A Hivatalosan igazolt állítások a Google nyilvános dokumentációjában szerepelnek. A Saját tapasztalat az auditjaink során rendszeresen látott mintákat jelenti. A Szakmai feltételezés olyan következtetés, amelyet észszerűnek tartunk, de hivatalos megerősítés nincs mögötte.
Miért a mobilváltozat számít az indexelésben?
A Google az oldalak mobilváltozatát térképezi fel és indexeli a Googlebot Smartphone nevű robottal, így a rangsoroláshoz is az ott talált tartalmat használja. Ha egy bekezdés, egy belső link vagy egy strukturált adat csak az asztali változatban létezik, azzal a kereső nagy valószínűséggel nem számol.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint a mobile-first indexelés azt jelenti, hogy a Google a tartalom mobilváltozatát használja indexelésre és rangsorolásra. Az átállást a Google lezártnak tekinti, és közölte, hogy azokat az oldalakat, amelyek mobileszközről egyáltalán nem érhetők el, nem indexeli. A dokumentáció azt is kimondja, hogy a mobil- és az asztali változaton ugyanannak a tartalomnak kell szerepelnie, és ha a mobilváltozaton szándékosan kevesebb a tartalom, forgalomvesztésre lehet számítani.
Fontos félreértés, hogy nincs külön mobil és asztali index. Egyetlen index van, és abba a mobilváltozat kerül. Aki asztali gépen keres, az is a mobilváltozatod alapján rangsorolt találatot látja.
A kérdés súlya attól függ, hogyan szolgálod ki a mobilt. Három megoldás létezik:
- Reszponzív kialakítás. Ugyanaz a HTML megy minden eszközre, a CSS rendezi át. Itt a legkisebb az eltérés esélye, de oldalépítőknél így is előfordul.
- Dinamikus kiszolgálás. Azonos URL-en a szerver a user-agent alapján más HTML-t küld. Itt a mobil HTML-ből tényleg hiányozhat tartalom.
- Külön mobil URL. Például egy m. aldomain, saját sablonnal. Ez a legkockázatosabb, mert két külön oldalt kell szinkronban tartani.
Milyen eltérések okoznak láthatatlan veszteséget?
A veszteség azért láthatatlan, mert nincs hibaüzenet, nincs figyelmeztetés a Search Console-ban, és asztali böngészőben minden rendben lévőnek tűnik. Az alábbi öt terület adja az esetek túlnyomó részét.
Mobilon hiányzó vagy elrejtett szövegblokkok
Két eset van, és érdemes szétválasztani őket. Az elsőben a tartalom egyáltalán nincs benne a mobil HTML-ben, mert a szerver vagy a sablon ki sem küldi. Ez egyértelmű veszteség. A másodikban a tartalom ott van a forrásban, csak CSS rejti el (display:none), vagy lenyíló elembe, fülbe került.
Hivatalosan igazolt: a Google szerint a helytakarékossági okból lenyíló elembe vagy fülre tett tartalom elfogadott megoldás, amennyiben a szöveg az oldal betöltésekor már a HTML-ben van. Szakmai feltételezés: a mobilon tartósan, minden felhasználói elérés nélkül elrejtett szöveg súlya bizonytalan. A Google látja a forrásban, de arról nincs nyilvános adat, hogy mennyire veszi figyelembe azt, amit a látogató soha nem érhet el. Mi ezt kockázatként kezeljük.
Hiányzó strukturált adat
Hivatalosan igazolt: a Google azt kéri, hogy a strukturált adat mindkét változaton azonos legyen, és a benne lévő URL-ek a mobilváltozatra mutassanak. Saját tapasztalat: külön mobil sablonnál gyakran lemarad a Product, a BreadcrumbList vagy az Organization jelölés, mert a sablont egyszer egyszerűsítették, és a JSON-LD blokkot nem másolták át. Ugyanez megtörténik, ha a jelölést egy olyan modul írja ki, amelyet mobilon kikapcsoltak. Az eredmény az, hogy a bővített találati megjelenés jogosultsága csendben megszűnhet.
Rövidebb menü és kevesebb belső link
A mobilmenüből sokszor kimaradnak az alkategóriák, a láblécből a linkoszlopok, a cikkek aljáról a kapcsolódó tartalmak. A kereső a belső linkeken keresztül találja meg az oldalakat és ezekből következtet a szerkezetre. Ha egy aloldalra mobilon alig mutat link, lassabban kerülhet be az indexbe, és gyengébb jelzést kap. Saját tapasztalat: a nehezen megtalálható, „árva” oldalak mögött gyakran pont egy megkurtított mobilnavigáció áll.
Lusta betöltésű tartalom
Hivatalosan igazolt: a Googlebot nem kattint, nem görget és nem gépel. A Google dokumentációja kifejezetten azt kéri, hogy az elsődleges tartalom betöltése ne függjön felhasználói interakciótól. Ami csak a „Tovább olvasom” gomb megnyomására, görgetési eseményre vagy koppintásra érkezik meg a szerverről, azt a robot jó eséllyel nem látja. A nézetablakba kerüléskor betöltő megoldás (például az IntersectionObserver) és a képek natív loading=lazy attribútuma ezzel szemben jellemzően rendben működik, mert a Google magas nézetablakkal rendereli az oldalt.
Eltérő címek, meta adatok és képek
Hivatalosan igazolt: a title, a meta description, a robots meta tag és a címsorok legyenek azonosak a két változaton, a képek pedig kapjanak ugyanolyan alt szöveget és megfelelő felbontást. Külön veszélyforrás a mobilváltozaton felejtett noindex, illetve a robots.txt, amely mobilon más erőforrásokat tilt, mint asztalin.
Mit jelent mindez az AI-keresők és válaszmotorok szempontjából?
A válaszmotorok abból tudnak idézni, amit a robotjuk a letöltött HTML-ben megtalál, ezért a mobilról hiányzó vagy csak JavaScripttel előálló tartalom itt is hátrány lehet. A Google AI-alapú találati funkciói ugyanarra az indexre épülnek, amelybe a mobilváltozatod kerül.
Szakmai feltételezés: a nagy nyelvi modellek mögötti crawlerek jelentős része a megfigyelések szerint nem futtat JavaScriptet, vagyis a nyers HTML-választ olvassa. Az OpenAI dokumentációja felsorolja a saját robotjait és azok user-agentjeit, a renderelés részleteiről viszont nem ad teljes képet, ezért ezt nem tekintjük igazolt ténynek. A gyakorlati következtetés ettől még egyszerű. Ha a legfontosabb válaszaid már a szerverről érkező HTML-ben benne vannak, mobil és asztali kérésre egyaránt, akkor egyik robotnál sem kell találgatnod.
Hogyan vetheted össze a két változatot URL-vizsgálattal?
A Search Console URL-vizsgálata megmutatja, melyik robottal térképezte fel a Google az oldalt, és letölthetővé teszi azt a HTML-t, amelyet ténylegesen látott. Ez a legmegbízhatóbb forrás, mert a Google saját nézetét adja vissza.
- Illeszd be a vizsgálandó URL-t a Search Console felső keresősávjába.
- Az oldalindexelési résznél nézd meg a feltérképezés módját. Itt jó eséllyel az okostelefonos Googlebot szerepel.
- Kattints a feltérképezett oldal megtekintésére, és másold ki a HTML-t egy szövegfájlba.
- Keress rá benne három-négy jellegzetes mondatra az oldal különböző részeiről, főleg azokra, amelyek asztalin jól láthatók, mobilon viszont lejjebb vagy lenyíló elemben vannak.
- Keress rá az
application/ld+jsonkifejezésre, és számold meg a strukturált adatblokkokat. - Futtass élő tesztet, és nézd meg a képernyőképet, valamint a betöltetlen erőforrások listáját.
- Ismételd meg sablononként egy-egy oldallal (főoldal, kategória, termék vagy szolgáltatás, cikk).
Kiegészítésként a Bővített találatok tesztje (Rich Results Test) lehetővé teszi, hogy okostelefonos és asztali robot között válts. Ha a két futás más strukturált adatot talál, megvan az eltérés. Saját tapasztalat: sablononként egy URL vizsgálata általában elég a mintázat felismeréséhez, mert a hiba ritkán egyedi oldalhoz, sokkal inkább sablonhoz kötődik.
Hogyan ellenőrizd crawlerrel, mobil user-agenttel?
Egy crawlert kétszer futtatsz le ugyanazon az oldalon, egyszer mobil, egyszer asztali Googlebot user-agenttel, majd URL-enként összeveted a kimenetet. Így az egész webhelyről kapsz képet, és a különbségek táblázatban szűrhetők.
A legtöbb SEO crawler (például a Screaming Frog vagy a Sitebulb) kínál beépített Googlebot Smartphone profilt. Kapcsold be a JavaScript-renderelést is, mert a Google is renderel, a mobil nézetablak méretével. A két futásból ezeket az oszlopokat érdemes egymás mellé tenni:
- szószám és a tartalom hash értéke,
- title, meta description, H1 és H2 címsorok,
- kimenő belső linkek száma oldalanként,
- strukturált adat típusa és darabszáma,
- canonical, robots meta tag és hreflang,
- képek száma és a hiányzó alt szövegek,
- bejárási mélység, vagyis hány kattintásra van az oldal a főoldaltól.
Gyors szúrópróbához parancssor is elég. Ezzel a kéréssel a nyers mobil HTML-t kapod meg, renderelés nélkül:
curl -s -A 'Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' https://pelda.hu/oldal/ -o mobil.html
Futtasd le asztali user-agenttel is egy asztali.html fájlba, majd hasonlítsd össze a kettőt. A grep -c 'application/ld+json' mobil.html megszámolja a strukturált adatblokkokat, a grep -o '<a ' mobil.html | wc -l pedig a linkeket. A Chrome DevTools hálózati beállításainál szintén megadható egyedi user-agent, ha böngészőben néznéd meg.
Egy korlátot tarts észben. Néhány szerver és tűzfal IP-cím alapján ellenőrzi, hogy a kérés valóban a Google-től jön-e, és a hamisított user-agentre mást válaszol vagy letiltja. Ezért a crawler eredménye közelítés, a végső szót az URL-vizsgálat mondja ki.
Mit ellenőrizz oldalépítővel készült oldalon?
Oldalépítőnél a leggyakoribb gond a megkettőzött blokk: ugyanaz a szekció elkészül asztalira és külön mobilra, eszközönkénti láthatósággal, és a két példány tartalma idővel eltér. Az Elementor, a Divi, a WPBakery és a hasonló eszközök mind kínálnak „elrejtés mobilon” vagy „elrejtés asztalin” kapcsolót.
Saját tapasztalat: ezek a kapcsolók jellemzően csak CSS-sel rejtik el az elemet, tehát mindkét példány benne marad a HTML-ben. Ebből két külön probléma lesz. Egyrészt a szöveg, a címsor és a link duplán szerepel a forrásban, ami akár két H1-et is jelenthet egy oldalon. Másrészt amikor valaki frissíti a szöveget, többnyire csak az asztali példányt írja át, a mobil pedig a régi tartalommal marad. Egyes megoldások (bizonyos bővítmények, témák vagy gyorsítótárak) szerveroldalon döntenek, és a rejtett blokkot ki sem küldik. Azt, hogy nálad melyik eset áll fenn, a forrásból lehet megállapítani, feltételezni nem érdemes.
Ellenőrzőlista oldalépítős oldalakhoz:
- Nyisd meg az oldalt az építőben mobilnézetben, és listázd ki az összes elemet, amelyen eszközfüggő láthatóság van beállítva.
- Minden „csak asztali” blokknál nézd meg, van-e mobil párja, és szóról szóra ugyanaz-e a szövege.
- Számold meg a H1 címsorokat a mobil HTML-ben. Egynél több megkettőzött fejlécblokkra utal.
- Vesd össze a mobilmenü és az asztali menü pontjait, a lábléc linkjeivel együtt.
- Ellenőrizd, hogy a GYIK, a táblázatok és az összehasonlító blokkok mobilon is megvannak-e, akár lenyíló formában.
- Nézd meg, hogy a strukturált adatot egy SEO-bővítmény írja-e ki sablonszinten, vagy egy olyan modul, amely mobilon rejtve van.
- Keresd meg a „Tovább” és „Még több betöltése” gombokat, és derítsd ki, hogy a tartalom a kattintás előtt benne van-e a forrásban.
- Ellenőrizd a csúszkákat és a füleket. A nem aktív diák és fülek szövege legyen ott a betöltött HTML-ben.
- Vesd össze a mobil- és az asztali képek alt szövegét, különösen akkor, ha mobilra külön, vágott kép van feltöltve.
- Ha gyorsítótár vagy CDN külön mobil cache-t tart, ürítsd mindkettőt, és utána mérj újra.
- Minden sablonmódosítás után ismételd meg az URL-vizsgálatot legalább egy érintett oldalon.
Milyen sorrendben érdemes javítani?
Először azt állítsd helyre, ami a mobil HTML-ből teljesen hiányzik, utána jöhet a megkettőzött blokkok összevonása, a végén a finomhangolás. A sorrend a kockázat nagyságát követi.
- Első kör. Hiányzó fő szöveg, hiányzó strukturált adat, mobilon felejtett noindex, kattintásra betöltődő elsődleges tartalom.
- Második kör. Megkurtított menü és lábléc, hiányzó kapcsolódó linkek, eltérő title és címsorok.
- Harmadik kör. Megkettőzött blokkok kiváltása egyetlen reszponzív szekcióval, képek alt szövegének egységesítése.
A tartós megoldás az, ha egy tartalom egyszer szerepel az oldalon, és a CSS rendezi át a képernyőmérethez. Ha a hosszú szöveg mobilon zavaró, a lenyíló elem a Google szerint is vállalható megoldás, a törlés viszont veszteséggel járhat. A javítás után kérj újraindexelést az érintett oldalakra, és figyeld a Search Console teljesítményjelentését. A változás segítheti a láthatóságot, de helyezést vagy forgalomnövekedést senki nem tud garantálni, és a hatás megjelenése a feltérképezés ütemétől is függ.
Források és további olvasnivalók
- Google Search Central: Mobile-first indexing best practices
- Google Search Central: Fix lazy-loaded content
- Google Search Central: Overview of Google crawlers and fetchers (user agents)
- Google Search Console Súgó: URL Inspection Tool
- Google Search Central: Rich Results Test dokumentáció
- Schema.org: Product, BreadcrumbList és Organization típusleírások
- OpenAI dokumentáció: Overview of OpenAI Crawlers
- W3C: HTML és WAI-ARIA Authoring Practices (lenyíló és füles elemek)
Gyakori kérdések
Számít még egyáltalán az asztali változat a Google-nek?
A látogatóidnak igen, az indexelésnek alig. A Google dokumentációja szerint a mobilváltozat tartalmát használja indexelésre és rangsorolásra, vagyis az asztali nézetben lévő többlet önmagában nem kerül be az indexbe. Az asztali élményt a felhasználók és a konverzió miatt érdemes rendben tartani.
Baj, ha mobilon lenyíló elembe teszem a hosszú szöveget?
A Google hivatalos álláspontja szerint a helytakarékossági céllal lenyíló elembe vagy fülre tett tartalom elfogadott, ha a szöveg az oldal betöltésekor már benne van a HTML-ben. Akkor van gond, ha a tartalom csak kattintás után töltődik be a szerverről, mert a Googlebot nem kattint.
Honnan tudom, hogy a Google melyik robottal járja be az oldalamat?
A Search Console URL-vizsgálatában az oldalindexelési adatok között szerepel a feltérképezés módja. Itt ma már szinte minden oldalnál az okostelefonos Googlebot látható. Ugyanitt megnézheted a feltérképezett HTML-t is, ami a legbiztosabb összehasonlítási alap.
Az oldalépítő „elrejtés mobilon” kapcsolója kiveszi a tartalmat a HTML-ből?
Tapasztalataink szerint a legtöbb oldalépítő ilyenkor csak CSS-sel rejti el az elemet, tehát a forrásban benne marad. Vannak viszont bővítmények és témák, amelyek szerveroldalon döntenek, ezért mindig az adott oldal mobil HTML-jében ellenőrizd. A CSS-sel elrejtett, megkettőzött blokkok dupla címsort és dupla linket is okozhatnak.
Elég, ha a crawlerben átállítom a user-agentet mobilra?
Jó közelítést ad, de nem tökéletes. Egyes szerverek és tűzfalak IP-cím alapján ellenőrzik a Googlebotot, és a hamisított user-agentre más választ adnak. A crawler az egész webhely mintázatait mutatja meg, a végső ellenőrzést az URL-vizsgálat élő tesztjével érdemes elvégezni.
Mennyi idő alatt látszik a javítás hatása?
Erre nincs biztos válasz, mert a feltérképezés ütemétől és az oldal súlyától függ. Az érintett URL-ekre kérhetsz újraindexelést a Search Console-ban, de ez kérés, és semmit nem garantál. A javítás segítheti a láthatóságot, konkrét helyezést vagy forgalmat viszont nem lehet előre megígérni.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.