A bizonyosság azt mondja meg, mennyire megbízható egyetlen vizsgálat eredménye, a lefedettség pedig azt, hogy a vizsgálat az oldal mekkora részére terjedt ki. A kettő együtt adja meg, mennyit ér a kapott kép: egy magas bizonyosságú mérés is félrevezet, ha az oldalnak csak a töredékét nézted meg.
A három bizonyossági szint
A legtöbb auditáló eszköz három szinten dolgozik. Érdemes tudni, melyik állítás honnan jön.
- Magas: technikai, gépi mérés. HTTP-státuszkód, fejléc megléte, JSON-LD szintaxisa, válaszidő. Ezek reprodukálhatók, újrafuttatva ugyanazt kapod.
- Közepes: AI-értelmezés. Például az, hogy a szövegből kiderül-e a fő szolgáltatás. Itt egy nyelvi modell olvassa a tartalmat, és a válasza futásonként kissé eltérhet.
- Alacsony: heurisztika. Becslés minták alapján, például CMS-felismerés a HTML nyomaiból vagy a tartalmi zaj aránya. Jó irány, de nem bizonyíték.
Mit jelent a lefedettség
A lefedettség nem a szerveren lévő oldalak száma. Az számít, hányat olvasott be ténylegesen a vizsgálat, és azokon hány szabály futott le. Egy feltérképezés mindig korlátos: időkeret, oldalszám, és csak a publikusan elérhető HTML.
Ebből következik egy fontos dolog. Ha egy szabály nem tudott lefutni, az nem hiba, hanem nem ellenőrizhető állapot. A riportokban ezt látjuk félreérteni a leggyakrabban: az ügyfél hiányosságnak veszi, pedig csak annyi történt, hogy nem volt mérhető adat.
Mikor számít igazán
Akkor, amikor döntesz. Ha egy alacsony bizonyosságú tételre akarsz fejlesztési budget-et költeni, előbb ellenőrizd kézzel. Ha egy magas bizonyosságú tétel piros, ott nincs mérlegelés, az mérhető tény. A pontszám ezért sosem önmagában értelmes, csak a mögötte lévő bizonyossággal együtt.
Mit néz ebből a riport
A riport minden vizsgálathoz eltárolja a bizonyossági szintet, és ebből plusz a lefedettségből számol egy Megbízhatóság százalékot. Beleszámít, hány oldalt olvasott be (legfeljebb kb. 15), hány szabály futott le a 80+ szabályból, és hány lett nem ellenőrizhető. A nem ellenőrizhető tételek nem rontják a pontszámot, csak a megbízhatóságot árnyalják.
Röviden: a bizonyosság azt mondja meg, mennyire hihető egy állítás, a lefedettség azt, hogy mennyiről szól.
Miért fontos
Rossz döntéseket előz meg
Egy audit eredménye feladatlistává válik. Ha nem tudod, melyik tétel mérés és melyik becslés, ugyanakkora súllyal kezeled őket. Így fordul elő, hogy egy heurisztikus jelzés miatt átírtok egy működő sablont, miközben egy mért hiba marad a helyén.
Az AI-olvasat természete más
A technikai vizsgálatok determinisztikusak. Egy fejléc vagy megvan, vagy nincs. Az AI-értelmezés ezzel szemben szövegértés: ugyanaz az oldal két futásban kaphat kissé eltérő összegzést. Ezt nem hibának kell tekinteni, hanem a módszer tulajdonságának.
A lefedettség határozza meg az általánosíthatóságot
Ha egy vizsgálat 15 oldalt nézett meg egy 4000 termékes webshopból, a termékoldalakra vonatkozó állítás mintavétel. A minta jó irányt ad, de nem mondja meg, hogy a 4000-ből pontosan hányon hiányzik a Product séma. Erre már Search Console vagy teljes crawl kell.
Üzleti következmény
A megbízhatósági adat véd a túlígéréstől. Ha egy jelentés 100%-os biztonsággal állít olyat, amit heurisztikával mért, az előbb-utóbb kiderül. A magyar KKV-oldalak többségén ráadásul pont az ilyen tételek a legérdekesebbek: a jogi és tartalmi kérdések ritkán mérhetők gépi pontossággal.
Technikai példa
Magas bizonyosságú tétel például az, hogy van-e HSTS-fejléc. Ez egy paranccsal ellenőrizhető, és bárki ugyanezt kapja:
curl -sI https://pelda.hu/ | grep -i "strict-transport-security"
# Strict-Transport-Security: max-age=31536000; includeSubDomains
Ha a sor megjelenik, a válasz egyértelmű. Nincs értelmezés, nincs szórás.
Egy auditáló eszköz belső adatszerkezete jellemzően így tárolja a tételeket:
{
"checks": [
{
"id": "hsts",
"status": "pass",
"confidence": "high",
"method": "http-header"
},
{
"id": "fo-szolgaltatas-felismerheto",
"status": "pass",
"confidence": "medium",
"method": "llm-extraction"
},
{
"id": "cms-felismeres",
"status": "info",
"confidence": "low",
"method": "heuristic"
},
{
"id": "product-sema",
"status": "not_verifiable",
"confidence": null,
"method": "html-parse",
"reason": "nem volt termekoldal a beolvasott mintaban"
}
],
"coverage": {
"pages_fetched": 14,
"checks_run": 78,
"not_verifiable": 6
}
}
A confidence és a coverage mező együtt adja ki a megbízhatóságot. A not_verifiable tétel hiányzó adat, nem bukott vizsgálat.
Gyakori kérdések
Miért csak néhány oldalt néz meg egy ilyen vizsgálat?
Mert a teljes feltérképezés idő- és erőforrásigényes, és terheli a szervert is. Egy gyors felmérés jellemzően a legfontosabb oldalakból vesz mintát: főoldal, szolgáltatás- vagy kategóriaoldalak, kapcsolat, néhány aloldal. Ez a technikai állapot megítéléséhez általában elég, a teljes tartalmi leltárhoz nem.
Ha alacsony a megbízhatóság, akkor rossz a riport?
Nem. Az alacsonyabb megbízhatóság azt jelzi, hogy kevesebb adat állt rendelkezésre, jellemzően blokkolás, jelszavas védelem vagy kevés beolvasott oldal miatt. Az abban szereplő magas bizonyosságú tételek ettől még érvényesek. Érdemes megnézni, mi akadályozta a vizsgálatot, és megismételni.
Miért kaphat két futás kissé eltérő eredményt?
A technikai mérések szinte mindig ugyanazt adják. Az AI-értelmezésre épülő tételeknél viszont a nyelvi modell válasza futásonként árnyalatnyit eltérhet. Ehhez jön a hálózati ingadozás és a szerver aktuális terhelése. Ez a közepes bizonyossági szint természetes velejárója.
Hogyan tudom növelni a lefedettséget a saját oldalamon?
Engedd át a robotokat a robots.txt-ben és a WAF-on, tartsd karban az XML sitemapet, és gondoskodj arról, hogy a fő tartalom HTML-ben is ott legyen. A jelszóval védett vagy karbantartás alatt álló oldal kívülről nem vizsgálható. A tiszta belső linkelés szintén segít, mert abból indul a felderítés.
A nem ellenőrizhető tételekkel kell kezdenem valamit?
Nem minden esetben. Ha azért nem futott le a szabály, mert nincs olyan oldaltípus az oldaladon, akkor nincs teendő. Ha viszont blokkolás vagy technikai akadály okozta, azt érdemes megszüntetni, mert ugyanez a keresőrobotokat is érintheti.
