Mi a weboldal-audit, és mit nem mér?

Mert a hibák nem látszanak a szemnek

Egy oldal lehet szép és mégis törött. A noindex nem látszik a böngészőben. A hiányzó biztonsági HTTP-fejlécek sem. A rossz Canonical URL sem. Ezek csak akkor derülnek ki, ha valaki célzottan megnézi a válaszfejléceket és a HTML fejrészét.

Mert megelőzi a drága döntéseket

A legdrágább hiba, amikor valaki új dizájnt épít egy rossz alapra. A régi URL-ek átirányítás nélkül eltűnnek, a séma kimarad, a sebesség romlik. Egy audit a redesign előtt lényegesen kevesebb, mint a javítás utána.

Mert az AI-láthatóság ma külön kérdés

A generatív keresők nem ugyanazt olvassák, mint a Google crawlere. Ha az oldal JavaScriptből tölti be a szöveget, egy egyszerű letöltés semmit nem talál. A magyar KKV-oldalak többségén az oldal sehol nem írja le egyértelműen, mivel foglalkozik: ezt ember kikövetkezteti a képekből, egy gép nem.

Mert prioritást ad

Egy jó audit nem hibalistát ad, hanem sorrendet. A hatás és a hatókör együtt mondja meg, mit kell holnap javítani, és mi várhat félévet. A gyors győzelmek külön kiemelése azért hasznos, mert így az első nap is van eredmény.

Kikre vonatkozik

• Minden publikus weboldalra: bemutatkozó oldal, blog, portál, landing
• Webshopokra kiemelten: ott a hibák közvetlen forintban mérhetők
• KKV-oldalakra: itt jellemzően nincs belső fejlesztő, aki figyelné az állapotot
• Régi, rég nem frissített oldalakra: ott a legnagyobb a technikai adósság
• Átvett projektekre: ahol nem tudod, mit hagyott maga után az előző fejlesztő

Kikre nem vagy csak részben

• Staging és fejlesztői környezet: ott a noindex és a jelszavas védelem helyes, nem hiba
• Zárt, bejelentkezés utáni rendszerek: egy külső audit a login-falon nem jut túl
• Egyoldalas kampány-microsite: néhány szabály értelmezhetetlen rá, a sebesség és a jogi rész viszont igen
• Nagy, több tízezer URL-es portálok: ott a minta-alapú audit nem elég, dedikált crawl-eszköz kell

Ha az oldal mögött csak egy darab Facebook-oldal van, az audit akkor is hasznos. Az alap-hiányok ugyanazok.

Kézi ellenőrzés lépésenként

1. Nyisd meg a főoldalt inkognitóban, és nézd meg, betöltődik-e HTTPS-en, zárt lakattal.
2. Nyomj Ctrl+U-t (oldal forrása), és keress rá a canonical, robots, application/ld+json szavakra.
3. Nyisd a devtools Network fülét, kattints az első dokumentum-kérésre, és olvasd el a válaszfejléceket.
4. Kérd le a fejléceket terminálból: curl -I https://pelda.hu - itt látszik a státuszkód és a fejléc-készlet.
5. Ellenőrizd a robots.txt-t és a sitemap.xml-t közvetlenül a böngészőben.
6. Futtass PageSpeed Insights mérést mobilra és desktopra is.
7. Tedd be egy termék- vagy szolgáltatásoldalt a Rich Results tesztbe, és nézd meg, felismer-e sémát.
8. Nézd meg a Search Console Oldalak jelentését: mennyi URL van indexelve, mennyi kizárva.
9. Kapcsold ki a JavaScriptet, és töltsd újra: ami eltűnik, azt a gépi olvasó sem biztosan látja.

Jó jelek

• A főoldal 200-as kóddal válaszol, a http:// és a www változat 301-gyel a végleges címre megy
• Van érvényes JSON-LD blokk Organization vagy iparági típussal
• A curl -I válaszban ott van a strict-transport-security és az x-content-type-options
• A sitemap elérhető, valós URL-eket tartalmaz, és a lastmod (a sitemap frissítés-dátuma) dátumok hihetőek
• JavaScript nélkül is olvasható a fő szöveg
• A Search Console-ban az indexelt URL-ek száma közel van a sitemap méretéhez

Rossz jelek

• noindex a főoldalon vagy fontos kategóriaoldalon
• Nincs egyetlen ld+json blokk sem
• http:// hivatkozások HTTPS-oldalon (mixed content (kevert tartalom))
• A server vagy x-powered-by fejléc kiírja a pontos verziószámot
• Az oldal 3 másodperc után sem mutat szöveget mobilon
• A sitemap 404-et ad, vagy törölt URL-eket sorol
• Nincs impresszum, vagy nincs benne adószám és székhely

Automatizált eszközök

Kézzel 5-10 URL-t érdemes átnézni. Ennél többnél eszköz kell: Lighthouse a böngészőben, GEO-audit az AI-értelmezhetőséghez, dedikált crawler a nagy oldalakhoz. Az eszközök egymást ellenőrzik, ne bízz egyetlen számban.

Az audit maga nem javít. A talált hibákat platformonként máshogy kell orvosolni. Mindig prioritási sorrendben haladj: kritikus, aztán magas hatású, aztán a többi.

WordPress

1. Beállítások > Olvasás: ellenőrizd, nincs-e bepipálva a keresőmotorok kizárása.
2. Telepíts egy SEO-plugint (Yoast, Rank Math, SEOPress), és futtasd le a beállítási varázslót.
3. Frissítsd a PHP-verziót a hostingnál 8.2 vagy újabbra, előtte készíts mentést.
4. Töröld a nem használt pluginokat, ne csak kapcsold ki: a kód így is ott marad.
5. Adj hozzá cache- és képoptimalizáló plugint, WebP konverzióval.
6. A biztonsági fejléceket a .htaccess-ben vagy a hosting felületén állítsd be, nem pluginból.
7. Írd meg kézzel az impresszumot és az adatvédelmi tájékoztatót, a generált minta nem elég.

Shopify

1. A séma a téma sablonjaiban van: a product.liquid vagy a json-ld snippet a javítás helye.
2. Online Store > Preferences: itt ellenőrizd a title és description alapértékeket.
3. Csökkentsd az appok számát: minden app JavaScriptet ad az oldalhoz.
4. A robots.txt szerkeszthető a robots.txt.liquid fájlon keresztül, óvatosan.
5. A fejléceket a platform adja, ezeken korlátozottan tudsz változtatni.

Unas

1. Nyisd a Marketing > SEO menüt, és töltsd ki a hiányzó meta-adatokat.
2. A Tartalom menüben pótold az impresszumot, ÁSZF-et és elállási tájékoztatót.
3. A sablon fejlécébe szúrható be plusz JSON-LD blokk a HTML-szerkesztőn keresztül.
4. A termékleírásokat töltsd fel: a gyári rövid leírás vékony tartalom.
5. A rendszerszintű technikai beállításokért a platform ügyfélszolgálatát kérdezd.

Shoprenter

1. Beállítások > SEO: itt kapcsolható a barátságos URL és a canonical-kezelés.
2. A sablonban (Twig) javítható a címhierarchia és a séma-kimenet.
3. A Tartalom oldalaknál pótold a jogi szövegeket.
4. A képeket töltsd fel megfelelő méretben: a platform átméretez, de a nagy eredeti lassít.
5. Az alkalmazás-piactérről telepített modulokat nézd át, a nem használtakat távolítsd el.

Egyedi fejlesztés

1. Vedd fel a szabályokat a CI-be: Lighthouse CI vagy egy egyszerű fejléc-ellenőrző szkript.
2. A biztonsági fejléceket a webszerver konfigjában állítsd be (nginx, Apache), ne alkalmazás-szinten.
3. Szerver oldali renderelést használj, ha SPA-t építesz: a gépi olvasók a HTML-t kérik.
4. A JSON-LD-t szerveren generáld az adatbázisból, ne kézzel írd be.
5. Vezess változásnaplót: melyik javítás mikor került ki, hogy mérhető legyen a hatás.
6. Ismételd az auditot a javítás után, ne feltételezd, hogy megoldódott.

• Az auditot marketing-riportnak tekinteni: forgalmi és konverziós számokat vár tőle, amiket az nem is lát.
• Csak a pontszámot olvasni: a 72 pont önmagában semmit nem mond, a kritikus tételek listája mond valamit.
• Mindent egyszerre akarni javítani: a 60 tételes lista lebénít, a 3 kritikus tétel viszont elvégezhető.
• Egyszer megcsinálni és elfelejteni: fél év alatt a pluginok elavulnak, a technikai adósság visszaépül.
• Staging-oldalt éles szabályokkal mérni: ott a noindex helyes, a hibajelzés félrevezet.
• Csak a főoldalt vizsgálni: a hibák jellemzően a kategória- és termékoldalakon halmozódnak.
• A javítás után nem újramérni: a riportokban rendszeresen látjuk, hogy a javítás félbemaradt vagy nem élesedett.

Az audit első lépése szinte mindig a válaszfejlécek megnézése. Egy sor terminálban többet mond, mint tíz perc kattintgatás:

curl -sI https://pelda.hu | grep -iE 'HTTP/|location|strict-transport|content-type-options|x-frame|server'

Egy jó válasz körülbelül így néz ki:

HTTP/2 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

Itt a 200 azt jelenti, hogy az oldal él. A strict-transport-security fejléc a HTTPS-t kényszeríti ki. Ha a server fejléc kiírná, hogy Apache/2.4.29 (Ubuntu), az felesleges információ egy támadónak.

A másik gyors ellenőrzés a strukturált adat. A HTML fejrészében ilyen blokkot keresel:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Példa Kft.",
  "url": "https://pelda.hu",
  "telephone": "+36 1 234 5678",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Budapest",
    "postalCode": "1051",
    "addressCountry": "HU"
  }
}

Ha ez a blokk nincs meg, a gépnek nincs egyértelmű forrása arról, ki üzemelteti az oldalt. A lábléc szövegéből ezt ki lehet következtetni, de a kikövetkeztetés bizonytalan.