Miért Számít a Weboldal Ellenőrzés?
A legtöbb cég akkor néz rá először komolyan a saját oldalára, amikor már baj van.
Zuhan a forgalom, nem jönnek az ajánlatkérések, vagy egy vásárló jelzi, hogy nem működik az űrlap.
Ekkor jön a pánik és a gyors PageSpeed teszt.
A weboldal ellenőrzés ennél sokkal több: a technikai működés, a technikai SEO, a sebesség, a biztonság, az akadálymentesség és a konverziós útvonalak együttes vizsgálata.
Nem egyetlen pontszám, hanem egy diagnózis, amiből kiderül, hol veszít pénzt az oldal.
Itt szokott elcsúszni a dolog.
A tulajdonos lefuttat egy eszközt, meglát egy 62-es számot zöld helyett sárgában, és vagy pánikba esik, vagy legyint.
Üzleti kontextus nélkül viszont egy Lighthouse-pontszám pontosan annyit ér, mint egy vérkép orvos nélkül: adat, de nem döntés.
Egy 2026-os weboldal mércéje már nem az, hogy tetszik-e a dizájn.
A mérce a mérhető gyorsaság, az elrendezés stabilitása, az indexelhetőség, a hozzáférhetőség és az, hogy éles környezetben, valódi eszközökön, valódi hálózaton hibátlanul működik-e.
A Google valós felhasználói adatokból számol, a látogató pedig három másodperc után továbblép.
Egy weboldal nem attól jó, hogy szép. Attól jó, hogy megtalálható, gyors, használható és eladja azt, amiért készült.
Ebben a cikkben végigvezetünk egy teljes weboldal audit folyamaton. Tisztázzuk, mikor melyik ellenőrzésre van szükség, lépésenként átnézzük az indexelhetőséget, a Core Web Vitals értékeket, a mobilos működést, a biztonságot, a WCAG 2.2 szerinti akadálymentességet és az adatvédelmi megfelelést.
A végén pedig megkapod azt, ami a legtöbb auditból kimarad: egy döntési szabályt arra, hogy melyik hibát javítsd először.
Mert a hibalista önmagában nem eredmény.
A prioritás az.
Weboldal Ellenőrzés Fajtái és Célja
Nem minden ellenőrzés ugyanaz a munka.
Más eszköz, más hozzáférés, más kérdés, más következtetés. Ha ezt nem tisztázod az elején, órákat pazarolsz olyan adatra, ami nem válaszolja meg a kérdésedet.
Saját Oldal Auditja vagy Idegen Oldal?
A saját oldalad esetében luxushelyzetben vagy: van Google Search Console hozzáférésed, látod az analitikát, hozzáférsz a szerverhez, a CMS adminfelületéhez és a hibanaplókhoz. Itt a cél a teljesítmény, a kereshetőség és a konverzió javítása.
Egy idegen oldal, például egy potenciális beszállító vagy egy versenytárs vizsgálatakor csak nyilvános eszközök maradnak. Ilyenkor az SSL Labs a tanúsítvány és a titkosítási beállítások minőségét mutatja meg, a VirusTotal és a Google Safe Browsing pedig a kártékony tartalomra utaló jeleket.
A kérdés is más.
Saját oldalnál azt kérdezed: hol veszítek bevételt?
Idegen oldalnál azt: megbízhatok-e ebben a cégben annyira, hogy adatot vagy pénzt adjak neki?
SEO-Audit, Biztonsági Ellenőrzés és QA
Ezt a három dolgot szinte mindenki összemossa, pedig más szakértelem kell hozzájuk. A SEO-audit a kereshetőségre és a rangsorolásra fókuszál: indexelhetőség, robots.txt, XML sitemap, canonical URL-ek, HTTP státuszkódok, belső linkelés, strukturált adatok, tartalmi hierarchia.
A biztonsági ellenőrzés a sérülékenységeket keresi. Elavult CMS és pluginverziók, hiányzó biztonsági fejlécek, rossz jogosultságkezelés, védelem nélküli űrlapok, kiszivárgó hibaüzenetek.
A QA, vagyis a funkcionális minőségbiztosítás megint más.
Itt nem elméletet ellenőrzünk, hanem végigklikkelünk minden folyamatot valódi eszközökön: működik-e az ajánlatkérő űrlap, megjön-e az e-mail, jó helyre visz-e a köszönőoldal, nyílik-e a mobilmenü iPhone-on és Androidon is.
Egyszeri Teszt vagy Folyamatos Audit
Egy új weboldal átadása előtt egy alapos, egyszeri minőségbiztosítás a minimum. Ez a lista véges: minden oldaltípus átnézése, minden űrlap tesztelése, sebességmérés, mobilos ellenőrzés, átirányítások és 404-es hibák kezelése, analitika és sütikezelés validálása.
Az élő oldal viszont folyamatosan romlik.
Frissül egy plugin, feltölt valaki egy 4 MB-os képet, belekerül egy új harmadik féltől származó szkript, és máris csúszik az LCP.
Ezért javasolt ritmus: minden nagyobb módosítás és minden kiadás után egy rövid ellenőrzés, negyedévente egy mélyebb weboldal audit, és havonta egy gyors pillantás a Search Console lefedettségi és Core Web Vitals jelentésére.
Ez összesen kevesebb idő, mint egyszer kijavítani egy fél évig észrevétlen indexelési hibát.
Az Ellenőrzési Folyamat Lépésről Lépésre
A sorrend nem véletlen.
Ha az oldal nincs indexelve, tökéletesen hiába gyors.
Ha gyors, de a mobilmenü nem nyílik, hiába találják meg.
Fentről lefelé haladunk: láthatóság, sebesség, használhatóság.
Indexelhetőség és Google Láthatóság
- Futtass egy site: keresést. Írd be a Google keresőbe, hogy site:sajatdomain.hu, és nézd meg, hány találat jön vissza. Ha nulla, az oldal láthatatlan a keresőben, és ez azonnali beavatkozást igényel.
- Nyisd meg a Search Console lefedettségi jelentését. Itt derül ki, mennyi URL van indexelve, és pontosan miért maradt ki a többi: noindex, canonical konfliktus, szerverhiba vagy crawl-tiltás.
- Ellenőrizd a robots.txt fájlt. A domain.hu/robots.txt címen egy véletlen Disallow: / sor egy egész webshopot kivon a keresőből. Ez gyakoribb hiba, mint hinnéd, főleg tesztkörnyezetből átmásolt beállításoknál.
- Nézd át a canonical URL-eket és a sitemapot. Minden oldal önmagára vagy a szándékolt kanonikus verzióra mutasson, az XML sitemap pedig csak 200-as HTTP státuszkódú, indexelhető URL-eket tartalmazzon.
Core Web Vitals és Sebesség
A Google 2026-ban is három mutatóval mér valós felhasználói élményt. A jó értékek küszöbei egyszerűek és számon kérhetők.
- Mérd az LCP-t. A Largest Contentful Paint azt mutatja, mennyi idő alatt jelenik meg a legnagyobb tartalmi elem. A jó érték 2,5 másodperc alatt van, és a leggyakoribb bűnös egy optimalizálatlan hero kép.
- Mérd az INP-t. Az Interaction to Next Paint a válaszkészséget jelzi: mennyi idő telik el a kattintás és a látható reakció között. 200 milliszekundum alatt jó, felette már érezhetően lomha az oldal.
- Mérd a CLS-t. A Cumulative Layout Shift a beugráló elrendezést pontozza. 0,1 alatt jó, és a legtöbb problémát méret nélküli képek, későn betöltő hirdetések vagy webfontok okozzák.
- Vesd össze a labor- és a valós adatokat. A PageSpeed Insights és a Lighthouse szimulált környezetben mér egyetlen betöltést, míg a CrUX és a Search Console tényleges felhasználói eszközökről gyűjt adatot 28 napon át. Ha a kettő eltér, a valós adat a döntő.
- Ne keverd össze a pontszámot a helyezéssel. Egy 100-as Lighthouse-eredmény nem garantál első helyet, mert a rangsorolást elsősorban a tartalom relevanciája és a linkprofil határozza meg. A sebesség finomhangoló tényező, ami hasonló minőségű oldalak között dönt.
Mobilbarát Működés és Hibás Linkek
- Teszteld valódi mobilon. A böngésző fejlesztői eszközeinek eszközemulátora hasznos, de nem helyettesíti a tényleges készüléket. Nézd meg a menü nyithatóságát, a gombok mérrhetőségét ujjal, a vízszintes csúszkálást és a betűméretet.
- Ellenőrizd a reszponzív webdesign töréspontjait. A 360, 768 és 1024 pixeles szélesség a három kritikus pont, ahol a legtöbb layout szétesik. Egy táblázat vagy egy beágyazott térkép szinte mindig itt bukik el.
- Crawlold végig az oldalt. A Screaming Frog ingyenes verziója 500 URL-ig feltárja a 404-es hibákat, az átirányítási láncokat, a hiányzó title és meta description elemeket, valamint a belső linkelés szerkezetét.
- Javítsd a törött linkeket 301-es átirányítással. Minden 404-es oldalt vagy irányíts át a legrelevánsabb élő tartalomra 301-es kóddal, vagy frissítsd a rá mutató belső linket. Átirányítási láncokat kerülj: egy ugrás legyen, ne három.
Biztonság, Akadálymentesség és Üzleti Folyamatok
Itt szokott kiderülni, hogy egy oldal valójában mennyire profi.
A sebességet mindenki méri, a biztonsági fejléceket és a billentyűzetes navigációt szinte senki.
Biztonsági Réteg és Frissítések
A HTTPS 2026-ban nem eredmény, hanem alapfeltétel.
A kérdés az, mi van a tanúsítvány mögött.
Kezdd a frissítési stratégiával.
A WordPress-oldalak nagy részét nem célzott hacker támadja, hanem egy automatizált szkript, ami egy hónapokkal korábban javított pluginsérülékenységet keres.
Egy világos szabály többet ér minden tűzfalnál: a CMS és a pluginok frissítése heti ritmusban, staging környezetben tesztelve.
Ezután jönnek a biztonsági fejlécek.
A HSTS kikényszeríti a titkosított kapcsolatot, a CSP korlátozza, hogy honnan futhat szkript az oldalon, az X-Content-Type-Options és a Referrer-Policy pedig további támadási felületeket zár be.
Ezek szerveroldalon néhány sor konfiguráció, hatásuk viszont aránytalanul nagy.
A jogosultságkezelés a másik klasszikus lyuk.
Hány admin fiók van, és mindegyikre valóban szükség van? Van kétfaktoros hitelesítés? A távozott fejlesztő hozzáférését visszavonták?
Az OWASP Top 10:2025 listájából a weboldalak esetében leggyakrabban a hibás jogosultságkezelés, a biztonsági konfigurációs hiányok, a sérülékeny külső komponensek és a hiányzó naplózás üt vissza.
Az űrlapoknál pedig kötelező a spamvédelem: rate limiting, honeypot mező vagy kockázatalapú captcha, különben a kapcsolati űrlapot napi száz szemétlevél fogja használni.
Akadálymentesség a Gyakorlatban
Az akadálymentes weboldal nem az alt szövegek kipipálása.
A WCAG 2.2 szerinti ellenőrzés jóval gyakorlatibb, és a legtöbb pontját kézzel, öt perc alatt tesztelheted.
- Billentyűzetes navigáció: csak a Tab és az Enter használatával végig tudsz menni a teljes vásárlási vagy ajánlatkérési folyamaton? Ha valahol elakadsz, ott egy felhasználói csoport is elakad.
- Látható fókuszállapot:
- Színkontraszt: a normál szövegnél legalább 4,5:1, nagy szövegnél 3:1 kontrasztarány szükséges. A világosszürke szöveg fehér háttéren a leggyakoribb dizájnhiba.
- Űrlaphiba-üzenetek: a hibát szövegesen is jelezni kell, ne csak piros kerettel, és mondja meg, mit kell javítani.
- Képernyőolvasós logika: értelmes címkék, helyes heading hierarchia, kihagyható navigáció, ARIA attribútumok csak ott, ahol tényleg kellenek.
A látható fókuszállapot külön hangsúlyt érdemel: ha a dizájner kikapcsolta az outline-t, a billentyűzettel navigáló látogató nem tudja, hol tart az oldalon.
Ez egyetlen CSS sorral javítható, és azonnal érezhető javulást ad a felhasználói élmény terén.
Adatvédelem, Sütik és Konverziós Tesztek
A magyar és EU-s szabályozás szerint az analitikai és marketing sütik csak előzetes, tényleges hozzájárulás után aktiválódhatnak. Ez technikai kérdés, nem jogi: ellenőrizd a böngésző fejlesztői eszközeivel, hogy a hozzájárulás előtt milyen sütik és szkriptek töltődnek be.
Három dolgot nézz meg a sütikezelés kapcsán: az elutasítás ugyanolyan könnyű-e, mint az elfogadás, a hozzájárulás valóban blokkolja-e a mérőkódokat, és elérhető-e egy sablonmondatoknál konkrétabb adatkezelési tájékoztató a láblécből.
Végül jön az, ami a bevételt közvetlenül érinti.
Ezeket a folyamatokat semmilyen automatikus eszköz nem teszteli helyetted, kézzel kell végigmenni rajtuk, asztali gépen és mobilon egyaránt.
- Ajánlatkérő űrlap: elküldés után valóban megérkezik az e-mail, a megfelelő címre, olvasható formában, spam mappa helyett a beérkező levelek között.
- Kapcsolatfelvételi űrlap: a kötelező mezők validálása működik, és a hibás kitöltés nem törli az addig beírt adatokat.
- Telefonos CTA: a telefonszám mobilon egyetlen koppintással hívható, a tel: link helyes formátumban van.
- Mobilos menü: nyílik, záródik, minden menüpont kattintható, és nem takarja ki a tartalmat.
- Köszönőoldal: létezik, tartalmaz visszaigazolást, és a konverziós esemény rögzítésre kerül az analitikában.
Melyik Hibát Javítsd Először?
Egy tisztességes weboldal audit 40 és 120 közötti hibát talál. Ha ezt a listát prioritás nélkül adod át a fejlesztőnek, két dolog történik: vagy a legkönnyebb tételekkel kezd, vagy semmivel.
A döntési szabály egyetlen mondat: ami blokkolja a bevételt, mindig megelőzi azt, ami csak zavarja a szemet.
Egy nem működő ajánlatkérő űrlap sürgősebb, mint 30 hiányzó alt szöveg, még akkor is, ha az utóbbi jobban kirívik egy Lighthouse-riportban.
Így néz ki egy használható auditjelentés szerkezete.
Minden sor egy döntés, nem egy megfigyelés.
| Hiba | Bizonyíték | Üzleti kockázat | Prioritás | Javítási javaslat | Felelős | Újratesztelés |
|---|---|---|---|---|---|---|
| Ajánlatkérő űrlap nem küld e-mailt | 5 tesztküldés mobilon és desktopon, 0 beérkezett levél | Minden bejövő érdeklődés elveszik, közvetlen bevételkiesés | P0 (24 óra) | SMTP beállítás javítása, tranzakciós e-mail szolgáltató bekötése | Fejlesztő | Javítás után azonnal, majd hetente |
| Kategóriaoldalak noindex címkével | Search Console lefedettség: 120 URL kizárva noindex miatt | A kereslet 60 százalékát fedő oldalak láthatatlanok a Google-ben | P0 (48 óra) | Noindex eltávolítása, sitemap újraküldése, URL-ellenőrzés kérése | SEO felelős | 7 nap múlva indexelés ellenőrzése |
| LCP mobilon 5,8 másodperc | CrUX valós adat 28 napra, PageSpeed Insights mobil nézet | Becsült 15-20 százalék visszafordulás a betöltés előtt | P1 (2 hét) | Hero kép WebP formátumba, méretezés, lazy loading a hajtás alatt | Fejlesztő | 14 nap múlva CrUX újramérés |
| Mobilmenü nem záródik iOS Safariban | Videófelvétel iPhone 13 Safari böngészőben | A mobilforgalom 55 százaléka nem tud navigálni | P1 (1 hét) | JavaScript eseménykezelő javítása, touch esemény hozzáadása | Frontend fejlesztő | Javítás után 3 eszközön |
| Hiányzó HSTS és CSP fejléc | Nyilvános fejléc-ellenőrző eredménye, D besorolás | Emelt támadási felület, megfelelőségi kockázat | P2 (1 hónap) | Fejlécek beállítása szerveroldalon, CSP fokozatos szigorítása | Rendszergazda | Bevezetés után SSL Labs teszt |
| 38 kép alt szöveg nélkül | Screaming Frog crawl export | Akadálymentességi hiányosság, kisebb SEO veszteség | P3 (folyamatos) | Alt szövegek pótlása tartalomfeltöltési szabállyal | Tartalomkezelő | Negyedéves crawl |
Mikor elég egy automatikus eszköz?
Akkor, ha a hibák pontszerűek és javíthatók: egy nagy kép, egy hibás átirányítás, egy hiányzó meta leírás.
Ezeket egy crawler megtalálja, és bárki kijavítja.
Szakértői átvizsgálásra akkor van szükség, amikor a hibák architekturálisak.
Ha a sebességprobléma egy túlterhelt oldalépítő sablonból jön, ha az URL-struktúra alapból kannibalizálja a saját oldalait, vagy ha a konverziós arány hónapok óta romlik anélkül, hogy egyetlen eszköz hibát jelezne, akkor nem javításra, hanem újratervezésre van szükség.
Gyakorlati példa a másik végről: a CompletApp saját fejlesztésű weboldalai közel maximális Lighthouse-pontszámmal és stabil éles működéssel indulnak, mert a QA nem utólagos lépés, hanem a fejlesztés része.
Amikor az indexelhetőség, a Core Web Vitals és a WCAG-szempontok már a tervezésnél beépülnek, az átadás utáni hibalista néhány kozmetikai tételre zsugorodik.
Ez a különbség egy megtervezett és egy összerakott oldal között.
Egy Ellenőrzés, Amit Ma Elkezdhetsz
Egyetlen lépés, ami ma, húsz perc alatt elvégezhető. Futtass le egy PageSpeed Insights mérést a kezdőlapra és a legfontosabb konverziós oldalra mobil nézetben, majd nyisd meg a Search Console lefedettségi jelentését.
Ezután írd fel a három legnagyobb üzleti kockázatú hibát.
Nem a három legalacsonyabb pontszámot, hanem azt a hármat, ami valóban megakadályozza, hogy egy érdeklődő megtaláljon, betöltsön és kapcsolatba lépjen veled.
Az automatikus eszközök jó kiindulópontot adnak, de nem tudják, mennyit ér egy ajánlatkérés.
A végső döntést mindig üzleti hatás alapján kell meghozni, és ezt a döntést senki nem hozza meg helyetted.
És itt jön a perspektívaváltás.
A weboldal ellenőrzés nem egy projekt, amit egyszer letudsz, hanem a termékfejlesztés folyamatos része, ugyanúgy, mint a tesztelés egy szoftvernél.
Minden kiadás után egy rövid ellenőrzés, negyedévente egy mélyebb audit.
Aki így dolgozik, annak soha nem lesz “weboldal-felújítási projektje”.
Csak egy oldala, ami működik.
