Mobilbarát teszt: amit tudnod kell róla

Scheo · 2026-08-13 · Frissítve: 2026-10-03 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Mit jelent ma a mobilbarát teszt, és mit keres az, aki beírja?

A mobilbarát teszt annak ellenőrzése, hogy egy weboldal telefonon is teljes értékűen használható-e: olvasható a szöveg nagyítás nélkül, ujjal is eltalálhatók a gombok, nem kell vízszintesen húzgálni a tartalmat, és a Google mobilos robotja ugyanazt látja, mint a látogató. Aki erre a kifejezésre keres, jellemzően három dolgot akar egyszerre: egy eszközt, amivel megnézheti a saját oldalát, egy értelmezést arról, hogy mit jelentenek az eredmények, és egy konkrét listát arról, mit javítson.

A helyzet annyiban változott, hogy a mobilbarát teszt sokáig egyetlen konkrét Google-eszközt jelentett: bemásoltad az URL-t, és zöld pipát vagy piros figyelmeztetést kaptál. Ez az egygombos megoldás ma nem elérhető, a vizsgálat maga viszont továbbra is elvégezhető, csak több eszköz összerakásával. Ez a cikk pontosan azt a folyamatot írja le, amit egy komolyabb átvizsgálásnál én is végigcsinálok.

Miért nem találod meg a Google hivatalos mobilbarát tesztjét?

Mert a Google kivezette. Hivatalosan igazolt: a Search Central 2023 novemberében jelentette be, hogy 2023. december 1-jétől megszünteti a Mobile-Friendly Test eszközt, a hozzá tartozó API-t és a Search Console Mobilhasználhatóság (Mobile Usability) jelentését. Az indoklás az volt, hogy a mobilos web azóta megérett, és számos jó, harmadik féltől származó eszköz áll rendelkezésre ugyanerre a célra.

Fontos félreértést tisztázni: a kivezetés nem azt jelenti, hogy a mobilbarát működés lett kevésbé fontos. Hivatalosan igazolt: a Google jelezte, hogy 2024. július 5-től minden webhelyet kizárólag a mobil Googlebottal térképez fel, és ami mobileszközön nem tölthető be vagy nem elérhető, az akár indexelés nélkül maradhat. Vagyis a mérőeszköz tűnt el, nem a követelmény.

Saját tapasztalat: az ügyfelek egy része pontosan emiatt hagyta abba a mobilos ellenőrzést. Eltűnt a piros figyelmeztetés a Search Console-ból, és ebből azt a következtetést vonták le, hogy megoldódott a probléma. A gyakorlatban a hibák ugyanúgy ott vannak, csak nincs, aki szóljon értük.

Mivel teszteld a mobilbarát működést a hivatalos eszköz helyett?

Négy eszköz fedi le együtt azt, amit régen egy csinált: a Search Console URL-ellenőrzése (renderelés), a PageSpeed Insights és a Lighthouse (sebesség és technikai jelzések), a Chrome DevTools eszközemulációja (layout), és egy valódi telefon (használhatóság).

• Search Console, URL-ellenőrzés: az Élő URL tesztelése után a megjelenített HTML és a képernyőkép mutatja, mit lát a Googlebot renderelés után. Ez áll a legközelebb a régi eszközhöz.
• PageSpeed Insights: mobil fülön futtat egy laborvizsgálatot, és ha van elég forgalmad, valós felhasználói mezőadatot is mutat.
• Lighthouse a Chrome DevTools-ban: ugyanaz a motor, de helyben, bejelentkezett vagy még nem publikus oldalakon is futtatható.
• DevTools eszközemuláció: a device toolbar segít gyorsan megtalálni a kilógó elemeket és a törött rácsokat.
• Rich Results Test: szintén mobil Googlebot-renderelést használ, így strukturált adatok ellenőrzése közben a renderelésről is kapsz visszajelzést.

Saját tapasztalat: az emulátor és a valódi telefon nem ugyanaz. Az emulátorban nem érzed, hogy a mobil menü gombja a hüvelykujjaddal kényelmetlenül elérhető, és nem derül ki, hogy egy űrlapmezőre koppintva az iOS ránagyít az oldalra. Ezt a két hibát csak kézzel találod meg.

Hogyan végezz teljes mobilbarát tesztet lépésről lépésre?

Egy alapos ellenőrzés kilenc lépésből áll, és egy közepes méretű oldalon nagyjából fél óra. Érdemes mindig ugyanabban a sorrendben csinálni, mert a korábbi lépések magyarázzák a későbbi eredményeket.

1. Válassz ki legalább négy oldaltípust: főoldal, szolgáltatás- vagy kategóriaoldal, egy cikk, és a kapcsolat vagy kosár oldal. Egyetlen URL vizsgálata félrevezető.
2. Futtasd le mindegyikre a PageSpeed Insights mobil vizsgálatát, és jegyezd fel az LCP, INP és CLS értékeket, ha van mezőadat.
3. Nyisd meg a Search Console URL-ellenőrzését, kérj élő tesztet, és nézd meg a megjelenített HTML-t. Keresd meg benne a fő szöveget, a menüpontokat és az árlistát vagy terméklistát.
4. Vesd össze a mobil és az asztali tartalmat: ugyanaz a szöveg, ugyanazok a belső linkek, ugyanaz a strukturált adat van meg mindkettőn?
5. Chrome DevTools-ban kapcsold be az eszközemulációt, állíts be egy 360 pixel széles nézetet, és görgesd végig az oldalt. Ha megjelenik vízszintes csúszka, keresd meg a kilógó elemet.
6. Ellenőrizd a viewport metacímkét és a betűméreteket a forráskódban.
7. Próbáld ki a legfontosabb műveletet valódi telefonon: űrlap kitöltése, hívásgomb, kosárba tétel, időpontfoglalás.
8. Nézd meg lassú hálózaton is: a DevTools hálózati fojtásával vagy egyszerűen mobilneten, wifi nélkül.
9. Írd össze a talált hibákat hatás szerint, ne felfedezési sorrendben. Ami a konverziós útvonalon van, az megy előre.

Milyen technikai beállítások döntik el, hogy mobilbarát-e az oldal?

Négy beállítás okozza a mobilbarát hibák többségét: a hiányzó vagy rossz viewport metacímke, a túl kicsi betűméret, a túl közel lévő koppintható elemek, és a rögzített szélességű elemek, amelyek nem férnek ki a képernyőn.

A viewport metacímke a kiindulópont. Enélkül a böngésző asztali szélességgel rendereli az oldalt, majd lekicsinyíti, és minden apró lesz:

<meta name="viewport" content="width=device-width, initial-scale=1">

Kerüld a user-scalable=no és a maximum-scale=1 beállítást, mert ezek megakadályozzák a nagyítást, ami akadálymentességi szempontból problémás. A vízszintes túlcsordulás megtalálásához ez a gyors ellenőrzés szokott segíteni a DevTools konzoljában:

document.querySelectorAll('*').forEach(e => { if (e.scrollWidth > document.documentElement.clientWidth) console.log(e); });

Ha megvan a kilógó elem, a javítás legtöbbször két általános CSS-szabállyal elintézhető. A képek, videók és beágyazások ne lehessenek szélesebbek a tárolójuknál:

img, video { max-width: 100%; height: auto; } iframe { max-width: 100%; }

A széles táblázatokat pedig tedd egy saját tárolóba, amely csak önmagában görgethető oldalra, így az oldal többi része a helyén marad:

.tabla-doboz { overflow-x: auto; }

Az iOS jellegzetes bosszúsága, hogy koppintáskor ránagyít az űrlapmezőre, ha a betűméret 16 pixelnél kisebb. Ezt egy sorral megelőzheted:

input, select, textarea { font-size: 16px; }

A koppintható elemeknél nem a látható méret számít, hanem a tényleges érintési terület. Szakmai feltételezés a mérési tapasztalataim alapján: körülbelül 44 CSS pixel körüli magasság az a határ, ami alatt a hibás koppintások aránya észrevehetően nő, különösen egymáshoz közeli linkeknél a lábléc- és menüsorokban.

Mi köze a mobilbarát tesztnek a Core Web Vitals-hoz?

A mobilbarát működés és a sebesség két külön dolog, de a felhasználó számára egyben jelentkezik: hiába fér ki minden a képernyőn, ha a gomb megnyomása után másfél másodpercig nem történik semmi. Hivatalosan igazolt: a Google 2024. március 12-én az INP (Interaction to Next Paint) mérőszámot tette a korábbi FID helyére a Core Web Vitals mutatók között.

A hivatalos küszöbértékek: az LCP legyen legfeljebb 2,5 másodperc, az INP legfeljebb 200 ezredmásodperc, a CLS pedig legfeljebb 0,1. Ezeket a valós felhasználói adatok 75. percentilisén értelmezi a Google, tehát nem az átlag számít, hanem az, hogy a látogatók háromnegyede jobb élményt kap-e ennél.

Hivatalosan igazolt az is, hogy a Search Console Core Web Vitals jelentése továbbra is elérhető. Mobil és asztali bontásban, hasonló URL-ek csoportjaira összesítve mutatja, melyik oldalak jók, melyek javítandók és melyek gyengék. A megszűnt Mobilhasználhatóság jelentés helyett ez áll a legközelebb egy automatikus jelzéshez. Kis forgalmú webhelyen viszont üres maradhat, mert nincs elég valós felhasználói adat, ilyenkor csak a laborvizsgálatra támaszkodhatsz.

Saját tapasztalat: mobilon szinte mindig az INP és a CLS okozza a bajt, nem az LCP. Az elrendezés-elcsúszást tipikusan a méret nélkül beillesztett képek, a később betöltődő sütibanner és a webfontok cseréje okozza. Az INP-t pedig a sok külső script: mérőkódok, chat-widgetek, hőtérkép-eszközök. Ezek asztali gépen alig érződnek, egy három éves középkategóriás telefonon viszont nagyon.

Milyen hibákat találunk a leggyakrabban a mobilbarát ellenőrzésen?

A tapasztalatom szerint az esetek többségében nem a reszponzív sablon hiányzik, hanem egy-két elem viselkedik rosszul benne. Saját tapasztalat, gyakorisági sorrendben:

• Egyetlen túl széles elem (táblázat, beágyazott térkép, kódrészlet, hosszú URL) vízszintes csúszkát okoz az egész oldalon.
• A mobil menü elrejt olyan menüpontokat, amelyek az asztali változatban ott vannak, így a belső linkstruktúra mobilon szegényebb.
• A sütibanner vagy egy feliratkozó ablak a képernyő nagy részét eltakarja, és a bezárás gombja apró.
• Kattintható telefonszám helyett képre írt telefonszám szerepel a fejlécben.
• A termékleírás vagy a GYIK mobilon lenyíló elemben van, és a tartalom csak kattintásra kerül a DOM-ba, tehát a renderelt HTML-ben nem szerepel.
• Az űrlapok mezői nem kapnak megfelelő type és autocomplete értéket, így telefonon rossz billentyűzet jön fel.

Az ötödik pont a legköltségesebb, mert nem látszik hibának: a látogató megtalálja a tartalmat, a kereső viszont nem. Ha a szöveg csak JavaScript-esemény hatására kerül be az oldalba, akkor a renderelt HTML-ben sem lesz ott, és ezzel indexelési szempontból elveszett.

Mit jelent a mobilbarát teszt az AI-válaszmotorok korában?

Az AI-asszisztensek és válaszmotorok nem néznek képernyőt, hanem forráskódot olvasnak, ezért a mobilbarát ellenőrzés egyik szakasza, a renderelt HTML vizsgálata, közvetlenül az AI-láthatóságodat is méri.

Hivatalosan igazolt annyi, hogy a Google mobil Googlebottal indexel, és a renderelt HTML az, amiből dolgozik. Szakmai feltételezés: a nagy nyelvi modellek mögötti kereső- és böngészőrétegek jellemzően jóval kevesebb JavaScriptet futtatnak le, mint a Googlebot, ezért ami nálad csak kliensoldali szkript után jelenik meg, az az AI-válaszokból nagy eséllyel kimarad. Ez nem hivatalos állásfoglalás, hanem a megfigyelt viselkedésből levont következtetés, de a gyakorlati teendő ugyanaz: a lényegi tartalom legyen benne a szerver által kiszolgált HTML-ben.

Ebből következik egy egyszerű munkamódszer. Amikor mobilbarát tesztet csinálsz, mentsd le a renderelt HTML-t, és keress rá benne a legfontosabb tíz mondatodra: a szolgáltatás megnevezésére, a helységnévre, a nyitvatartásra, a GYIK válaszaira. Ha ezek megvannak benne szövegként, akkor jó eséllyel az AI-rendszerek is hozzáférnek. Ha csak a képernyőn látszanak, akkor van dolgod.

Hogyan ellenőrizd rendszeresen, ha már nincs automatikus figyelmeztetés?

Mivel a Search Console már nem szól a mobilhasználhatósági hibákért, a felelősség átkerült hozzád: érdemes negyedévente, illetve minden sablon- vagy bővítményfrissítés után újra végigfutni az ellenőrzőlistát.

• Van viewport metacímke, és nem tiltja a nagyítást?
• 360 pixeles szélességnél sincs vízszintes csúszka egyik oldaltípuson sem?
• A törzsszöveg legalább 16 pixel, és a sorhossz kényelmesen olvasható?
• A fő gombok és menüpontok elég nagyok és távol vannak egymástól?
• A renderelt HTML tartalmazza a teljes szöveget, a menüt és a strukturált adatot?
• Ugyanaz a tartalom van mobilon, mint asztali nézetben?
• Az LCP, INP és CLS mezőadatok a küszöbértékeken belül vannak mobilon?
• A képek méretezettek, és van szélesség-magasság megadva, hogy ne csússzon az elrendezés?
• A telefonszám és az e-mail-cím koppintható link?
• A sütibanner és a felugró ablakok bezárhatók egy hüvelykujjal?

Ez a lista önmagában nem hoz jobb helyezést, és több érdeklődőt sem. Azt viszont megakadályozhatja, hogy technikai apróságok miatt veszíts el olyan látogatókat, akik már megtaláltak. A tapasztalatom szerint a mobilos javítások hatása leggyorsabban a kapcsolatfelvételi arányon látszik, nem a rangsorban.

Hogyan értelmezd a mobilbarát teszt eredményét?

A mobilbarát teszt eredménye ma nem egy igen-nem válasz, hanem három részeredmény. A renderelt HTML megmutatja, hogy a Google látja-e a tartalmat, a PageSpeed Insights mezőadata azt, hogy a valódi látogatók jó élményt kapnak-e, a kézi próba pedig azt, hogy a fő művelet elvégezhető-e telefonon. Akkor mondhatod az oldaladra, hogy mobilbarát, ha mindhárom rendben van.

PageSpeed Insights: a pontszám vagy a mezőadat számít?

Hivatalosan igazolt, hogy a PageSpeed Insights két külön dolgot mutat. A felső rész a Chrome valós felhasználóitól gyűjtött mezőadat (CrUX), a lenti 0 és 100 közötti pontszám pedig egy szimulált laborvizsgálat eredménye. A pontszám színkódja szerint 90 és 100 között jó, 50 és 89 között javítandó, 50 alatt gyenge. A Core Web Vitals értékelésénél a Google a mezőadatot használja, a laborpontszám diagnosztikai segédeszköz. Ha a kettő ellentmond egymásnak, a mezőadat a mérvadó.

Saját tapasztalat: ugyanarra az URL-re egymás után futtatva is eltérhet néhány ponttal a laborpontszám, ezért egyetlen futásból ne vonj le következtetést. Én háromszor futtatom, és a középső értéket jegyzem fel. A pontszám helyett a lenti diagnosztikai javaslatok a hasznosabbak, mert konkrétan megnevezik a lassító képet, szkriptet vagy betűtípust.

Search Console URL-ellenőrzés: mit nézz meg benne?

A képernyőkép gyakran csak az oldal első képernyőnyi részét mutatja, ezért a megjelenített HTML a fontosabb. Három dolgot keress az élő teszt eredményében:

• A fő szöveg szó szerint benne van a megjelenített HTML-ben, nem csak egy üres tároló.
• A menüpontok valódi linkként, a elemként szerepelnek, href értékkel.
• A További információk résznél nincsenek betölthetetlen oldalerőforrások, például robots.txt által tiltott CSS- vagy JavaScript-fájlok, és a JavaScript-konzol üzenetei között sincs hiba, ami a tartalom megjelenítését akasztja meg.

Kézi próba: mikor sikeres?

Akkor, ha egy kívülálló a saját telefonján, segítség nélkül végig tudja csinálni a fő műveletet, és közben egyszer sem kell nagyítania vagy oldalra húznia a képernyőt. Saját tapasztalat: a legtöbbet az árul el, ha nem mondod meg előre, hova kell kattintani, csak a feladatot adod meg, például hogy kérjen időpontot. Ahol megakad, ott a hiba.

Mire figyelj a mobilbarát tesztnél, ha WordPress-oldalad van?

WordPress-oldalon a mobilbarát teszt hibáinak nagy része nem a témából jön, hanem az oldalépítőből, a bővítményekből és a gyorsítótárból, ezért ezeket külön is érdemes végignézni. Saját tapasztalat alapján ezek a leggyakoribb pontok:

• Az oldalépítő reszponzív beállításai. Elementorban, Diviben és a hasonló eszközökben minden elemnek külön mobil margója, betűmérete és oszlopszélessége lehet. Az asztali nézetben beállított fix szélesség mobilon is érvényben marad, ha a mobil értéket senki nem állította át.
• Mobilon elrejtett elemek. Az oldalépítők elrejtés kapcsolója általában csak CSS-sel takarja el az elemet, így az a HTML-ben ott marad. Indexelés szempontjából ez rendben van, de ha emiatt egy szekció két változatban töltődik be, az lassítja az oldalt.
• Optimalizáló bővítmények. A CSS- és JavaScript-fájlok összevonása vagy a szkriptek késleltetett betöltése gyakran éppen mobilon töri el a menüt vagy a csúszkát. Minden ilyen beállítás után ürítsd a gyorsítótárat, és nézd meg az oldalt telefonon.
• Külön mobil gyorsítótár. Egyes bővítmények külön tárolják a mobil változatot. Ha módosítás után a telefonon még a régi oldal jelenik meg, nagy valószínűséggel ez az oka.
• Felugró ablakok és sütibannerek. Sok ilyen bővítmény asztali méretre készült, és mobilon a teljes képernyőt kitakarja.

Saját tapasztalat: a legtöbb félreértés abból adódik, hogy a módosítás után bejelentkezve nézzük az oldalt, ahol a gyorsítótár ki van kapcsolva, a látogató viszont egy régebbi, gyorsítótárazott változatot kap. A mobilbarát tesztet ezért mindig kijelentkezett állapotban vagy privát böngészőablakban futtasd.

Források és további olvasnivalók

• Google Search Central Blog: a Mobile-Friendly Test eszköz és a Mobile Usability jelentés kivezetéséről szóló bejelentés
• Google Search Central Documentation: Mobile-first indexing best practices
• Google Search Console súgó: URL-ellenőrző eszköz és a megjelenített HTML vizsgálata
• Google Search Console súgó: Core Web Vitals jelentés
• web.dev: Core Web Vitals, valamint az INP mérőszám dokumentációja
• Chrome for Developers: Lighthouse, PageSpeed Insights és a Chrome DevTools eszközemuláció dokumentációja
• W3C: Web Content Accessibility Guidelines (WCAG), Target Size irányelvek
• MDN Web Docs: Viewport meta tag és reszponzív tervezési alapok
• Schema.org: strukturált adat típusok hivatalos leírása