Kiegészítő felmérés · veszpremcatering.hu

Technikai audit: biztonság, akadálymentesség és webstandardok

A meta & AEO ajánlat mellett elvégeztünk egy átfogó technikai felmérést is a veszpremcatering.hu weboldalon. Az alábbi megállapítások mind mérésen alapulnak, és mindegyikhez konkrét javaslatot adunk. Ezek a javítások nem részei a meta & AEO ajánlatnak — külön, tetszőleges sorrendben elvégezhetők.

3 magas prioritás 11 közepes 5 alacsony 13 rendben lévő terület

Megállapítások Vissza az ajánlatra

Módszer

Hogyan készült a felmérés

2026. augusztus 3., kizárólag nyilvánosan elérhető adatokból

A felmérés a weboldal mind a 24 nyilvános aloldalára kiterjedt, bejelentkezés nélkül. Nem végeztünk behatolásvizsgálatot, nem próbáltunk belépni, és nem módosítottunk semmit az oldalon: minden megállapítás a kiszolgáló nyilvános válaszaiból, a megjelenített oldalak szerkezetéből és a domain nyilvános névkiszolgálói adataiból származik.

HTTP válaszfejlécek, átirányítások, hibakezelés és nyilvános rendszervégpontok ellenőrzése
Akadálymentességi vizsgálat a WCAG 2.1 AA szempontrendszere szerint, számított színkontraszt-mérésekkel és billentyűzetes bejárással
A W3C nyilvános érvényességi ellenőrzőjének futtatása három reprezentatív oldalon
Betöltési mérések a böngésző saját teljesítménynaplójából, valós állományméretekkel
A domain levelezési és tanúsítvány-beállításainak lekérdezése (SPF, DKIM, DMARC, CAA)

A weboldalt nem a CM Design fejlesztette, ezért a javítások egy részét a weboldal fejlesztőjével együttműködésben lehet elvégezni. A felmérés célja nem a hibakeresés önmagáért, hanem hogy Önök tudják, min érdemes dolgozni — és milyen sorrendben.

1 · Biztonság

Biztonsági megállapítások

A weboldal alapvető védelmi beállításai jó irányban vannak, két területen viszont indokolt a beavatkozás: a bejelentkezéshez tartozó adatok nyilvánosak, és hiányoznak a böngészőnek szóló védelmi fejlécek.

A nyilvános API kiadja az adminisztrátori fiók e-mail-címét

Magas

Amit mértünk: A /wp-json/wp/v2/users végpont bejelentkezés nélkül visszaadja a fiók nevét: manager@hotelhistoria.hu, valamint a hozzá tartozó azonosítót (managerhotelhistoria-hu). A /?author=1 hívás átirányít ugyanerre a szerzői oldalra, a /wp-login.php pedig nyilvánosan elérhető.
Miért fontos: A belépéshez tartozó azonosító és e-mail-cím ismeretében a támadónak már csak a jelszót kell kitalálnia. Az automatizált jelszótörő kísérletek pontosan ilyen nyilvános végpontokból gyűjtik a fióknevet.
Javaslatunk: A felhasználói végpont lezárása bejelentkezés nélküli hívásokra, a szerzői archívum letiltása, valamint a belépési oldal védelme (kísérletszám-korlátozás és kétfaktoros belépés). A fióknévként használt e-mail-cím megjelenítési nevét is érdemes külön beállítani.

Hiányzó biztonsági HTTP fejlécek

Közepes

Amit mértünk: A válaszban nincs Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (vagy frame-ancestors), Referrer-Policy és Permissions-Policy fejléc. Ami megvan: X-Content-Type-Options: nosniff, illetve a mára elavult X-XSS-Protection.
Miért fontos: A HSTS nélkül az első, még HTTP-s kérés lehallgatható; a keretezést tiltó fejléc nélkül az oldal idegen felületbe ágyazható (kattintás-eltérítés); a hivatkozási irányelv nélkül a kilépő linkeken a teljes URL átadódik.
Javaslatunk: A fejlécek beállítása a kiszolgálón vagy a tartalomkezelőben. A HSTS, a keretezés tiltása, a hivatkozási irányelv és az engedélyezési irányelv azonnal bevezethető; a tartalombiztonsági irányelv (CSP) fokozatosan, először csak jelentési módban.

16 nyilvános űrlap, automatizált visszaélés elleni védelem nélkül

Közepes

Amit mértünk: A 24 aloldalon összesen 16 űrlap található (ajánlatkérés, kapcsolat, hírlevél). Egyik oldalon sem találtunk reCAPTCHA, hCaptcha vagy Turnstile védelmet.
Miért fontos: A védelem nélküli ajánlatkérő űrlapokat a levélszemét-küldő robotok rendszeresen megtalálják. Ez egyrészt terheli a postafiókot, másrészt a valódi megkeresések elveszhetnek a zajban.
Javaslatunk: Láthatatlan ellenőrzés (Turnstile vagy reCAPTCHA v3) bekapcsolása, illetve egyszerű csapdamező és időalapú szűrés az űrlapkezelőben.

A tartalomkezelő olvasmányfájlja nyilvánosan elérhető

Közepes

Amit mértünk: A /readme.html bejelentkezés nélkül letölthető (HTTP 200). Ezzel szemben a /license.txt, a /.git/config, a /.env és a hibanapló hívása helyesen 403-at ad.
Miért fontos: Az ilyen fájlok megkönnyítik a rendszer és a verzió azonosítását, ami a célzott, automatizált támadások első lépése.
Javaslatunk: A fájl törlése vagy hozzáférésének letiltása a kiszolgálón, a többi rendszerfájl mintájára.

A kiszolgáló és a szerkesztő azonosítható a válaszokból

Alacsony

Amit mértünk: A válaszfejlécben szerepel az x-httpd-modphp, a HTML-ben pedig egy szerkesztőt és verziót megnevező generator meta elem.
Miért fontos: Önmagában nem sebezhetőség, de csökkenti a szükségtelen felderíthetőséget, ha nem hirdetjük, milyen komponensek futnak az oldalon.
Javaslatunk: A verziót közlő meta elem eltávolítása és a szükségtelen fejlécek elhagyása.

A domain levelezési és tanúsítvány-beállításai nincsenek végig szigorítva

Alacsony

Amit mértünk: SPF (~all) és DKIM be van állítva, a DMARC azonban p=none, jelentési cím nélkül. Nincs CAA rekord, és a névfeloldás nem ad hitelesített választ (DNSSEC nincs). A domain gyökerében található egy hibás TXT rekord is: egy zónafájl-sor („default._domainkey 14400 IN TXT …") került be értékként.
Miért fontos: A DMARC jelentés nélkül nem látszik, ki küld levelet a domain nevében; a CAA hiányában bármely tanúsítványkibocsátó kiállíthat tanúsítványt a domainre; a hibás TXT rekord pedig félreértelmezhető a fogadó levelezőrendszereknek.
Javaslatunk: A hibás TXT rekord törlése, CAA rekord felvétele, a DMARC jelentési cím beállítása, majd fokozatos szigorítás (p=none → quarantine) a jelentések alapján. A DNSSEC bekapcsolása a névkiszolgálón.

2 · Akadálymentesség

Akadálymentesség — WCAG 2.1 AA

A vizsgálat a szabvány AA szintjéhez mérte az oldalt. A címkék és a fókuszjelzés rendben vannak, a színkontraszt és a képek kezelése viszont több ponton elmarad a követelménytől.

A márkaszínek nem érik el a WCAG AA kontrasztkövetelményt

Magas

Amit mértünk: A gombokon a fehér szöveg az arany #BDA25E háttéren 2,47:1 arányt ad (a követelmény 4,5:1), ugyanez az arany szöveg fehér háttéren szintén 2,47:1 — a 40 pixeles címeknél is (ott 3,0:1 a minimum). A zöld #9EBCB3 párosítás 2,04:1. Mérésünkben a főoldalon 24, a céges catering oldalon 20, a kapcsolat oldalon 8 elem esett a küszöb alá; a háttérképen álló szövegeket nem számoltuk bele.
Miért fontos: Ez érinti az összes gombot („Ajánlatkérés", „Bővebben", „Küldés"), a kapcsolati űrlap címkéit és több szekciócímet. Erős napfényben, gyengébb kijelzőn vagy csökkent látás esetén ezek a feliratok nehezen olvashatók — miközben éppen ezek vezetnek a megkereséshez.
Javaslatunk: A két márkaszín sötétebb változatának bevezetése szöveg- és gombhasználatra (a dekoratív felületeken az eredeti árnyalat maradhat). Így a márkaarculat megőrizhető, és a feliratok megfelelnek a szabványnak.

A tartalmi képek háttérképként jelennek meg, ezért nincs alternatív szövegük

Magas

Amit mértünk: A 24 aloldal kiszolgált HTML-jében egyetlen <img> elem sincs; a képek CSS háttérképként töltődnek (a főoldalon 21, a galéria oldalon 36 ilyen elem). A böngészőben megjelenő két <img> a süti-tájékoztató két ikonja.
Miért fontos: A háttérképhez nem tartozhat alternatív szöveg, így a képernyőolvasót használó látogató számára a helyszínfotók nem léteznek. Ugyanezért a képek a Google képkeresőjében sem jelennek meg, és nem tölthetők be a képernyőméret szerint optimalizált változatban.
Javaslatunk: A tartalmi jelentéssel bíró képek (helyszínek, referenciák, galéria) valódi képelemként való megjelenítése, kitöltött alternatív szöveggel és méretjelöléssel. A díszítő hátterek maradhatnak háttérképnek.

Az „Ugrás a tartalomhoz" link nem működik, és nincs fő tartalmi régió

Közepes

Amit mértünk: Az első billentyűzet-fókusz az „Ugrás a tartalomhoz" linkre esik, amely a #content horgonyra mutat — ez az elem nem létezik az oldalon. Egyetlen vizsgált oldalon sem található <main> régió.
Miért fontos: A billentyűzettel navigáló látogató minden oldalon végigkénytelen lépni a teljes menün, mert az átugró link nem visz sehová. A régiók hiánya miatt a képernyőolvasó sem tud a tartalomra ugrani.
Javaslatunk: A fő tartalom <main id="content"> elembe foglalása, így az átugró link egyetlen mozdulattal működőképessé válik.

Nyolc oldalon nincs H1 főcím, és a címsorszintek ugranak

Közepes

Amit mértünk: H1 nélküli oldalak: /rendezveny-tipusok-veszprem/, /kapcsolat/, /rolunk/, /eskuvoi-catering/, /referenciak/, /galeria/, /feliratkozas-hirlevelre/, /karbantartas/. A főoldalon a H3 után közvetlenül H5 következik, a kapcsolat oldalon a H2 után H5 — a W3C ellenőrző is jelzi.
Miért fontos: A címsorstruktúra a képernyőolvasók legfontosabb navigációs eszköze, és a keresőknek is ez jelzi az oldal témáját. Hiányában az oldal „névtelen" marad mindkét irányban.
Javaslatunk: Oldalanként egy beszédes H1 beállítása és a szintek folytonossá tétele. Ez egybeesik a meta & AEO munkacsomag célszövegeivel, tehát egy körben elvégezhető.

Név nélküli linkek: a logó és az ikonos hivatkozások

Közepes

Amit mértünk: A fejléc logólinkje üres tartalommal szerepel (a logó háttérképként jelenik meg), és a naptár-ikonos hivatkozásokon sincs feliratot pótló attribútum. Oldalanként 9 olyan hivatkozást találtunk, amelynek nincs kiolvasható szövege.
Miért fontos: A képernyőolvasó ilyenkor a nyers webcímet olvassa fel a link helyett, ami használhatatlanná teszi a navigációt, és a keresők számára sem hordoz jelentést.
Javaslatunk: A logóhoz és minden ikonos hivatkozáshoz feliratot pótló attribútum vagy rejtett szöveg hozzáadása.

Duplikált azonosítók és érvénytelen kisegítő attribútumok

Alacsony

Amit mértünk: Minden oldalon két azonosító kétszer szerepel (menu-1-…, menu-2-…, az asztali és a mobil menü miatt), és hat <label> elemen érvénytelen módon szerepel feliratot felülíró attribútum.
Miért fontos: A duplikált azonosító megzavarja a horgonyokat, a szkripteket és a kisegítő technológiákat; az érvénytelen attribútum pedig felülírhatja a mezőhöz tartozó valódi címkét.
Javaslatunk: Egyedi azonosítók a menük két példányához, és a felirat-attribútum eltávolítása a címkeelemekről.

3 · Webstandardok

Kódszerkezet és webstandardok

A HTML szerkezeti érvényessége befolyásolja, hogyan értelmezik az oldalt a keresőrobotok és a kisegítő technológiák.

A HTML nem érvényes: oldalanként 14–15 hiba

Közepes

Amit mértünk: A W3C ellenőrzője a főoldalon 14, a kapcsolat oldalon 15, a galéria oldalon 5 hibát jelez (és 27–35 figyelmeztetést). A visszatérő hibák: <header> a <header>-en belül, <footer> a <footer>-en belül, <a> elem cél nélkül, <style> a törzsben, <div> a címkeelemen belül, valamint defer attribútum beágyazott szkripten (ahol nincs hatása).
Miért fontos: Az érvénytelen szerkezet a böngészőkben ma még megjelenik, de a kisegítő technológiák és a keresőrobotok értelmezése kiszámíthatatlanná válik. A kettős fejléc- és lábléc-régió például elbizonytalanítja a képernyőolvasó régiónavigációját.
Javaslatunk: A szerkezeti hibák javítása a sablonban. A többségük egy-egy soros javítás, és az egész oldalra egyszerre érvényesül.

4 · Teljesítmény

Betöltés és teljesítmény

A kiszolgáló válaszideje és a gyorsítótárazás példás; a letöltött kód és a képek kezelése viszont indokolatlanul nagy terhet ad minden oldalbetöltéshez.

Minden oldalbetöltés mintegy 850 kilobájt stílus- és szkriptállományt hoz magával

Közepes

Amit mértünk: Az egyesített stíluslap 426 KB, az egyesített szkript 425 KB, ezen kívül külön betöltődik a jQuery (86 KB) — összesen körülbelül 956 KB saját erőforrás, egy 24 aloldalas bemutatkozó weboldalon. A kiszolgáló válaszideje ugyanakkor jó (92 ms), a tömörítés (brotli) és az egyéves gyorsítótárazás rendben van.
Miért fontos: A letöltött kód mérete elsősorban mobilhálózaton és gyengébb készüléken érződik: későbbi megjelenés, később kattintható gombok. A Google felhasználói élmény-mutatói ezt közvetlenül mérik.
Javaslatunk: Oldalankénti kódbetöltés (csak a valóban használt elemek), a nem használt stílusok elhagyása és a jQuery-függés felülvizsgálata. Ez a weboldal fejlesztőjével közösen tervezhető feladat.

A képek nem a képernyőméret szerint töltődnek be

Közepes

Amit mértünk: Mivel a képek háttérképként jelennek meg, nincs hozzájuk méretváltozat-jelölés, és a betöltésüket a beépített késleltetett betöltés sem érinti (a betöltéskezelő szkript csak valódi képelemekre hat).
Miért fontos: A mobilon is a nagy méretű változat töltődik le, ami a leglátványosabb tartalmi elem megjelenését késlelteti.
Javaslatunk: A tartalmi képek valódi képelemként, méretváltozatokkal és késleltetett betöltéssel. Ez ugyanaz a javítás, amely az alternatív szövegek problémáját is megoldja.

A betűtípusok a Google kiszolgálójáról töltődnek

Alacsony

Amit mértünk: Az oldal 14 beágyazott @font-face szabállyal és 15 hivatkozással tölt be betűkészleteket a fonts.gstatic.com címről.
Miért fontos: Külső kérés minden oldalbetöltésnél, ami a megjelenítést késleltetheti — és adatvédelmi kérdést is felvet (lásd alább).
Javaslatunk: A betűkészletek saját kiszolgálóra helyezése. Ez egyszerre gyorsít és megszünteti a külső adattovábbítást.

5 · Adatvédelem

Adatvédelem és megfelelés

A süti-hozzájárulás kezelése működik. Két ponton érdemes pontosítani: a külső betűkészletek betöltésénél és a tájékoztató szövegénél.

A betűtípusok a látogató IP-címét hozzájárulás előtt továbbítják a Google-nek

Közepes

Amit mértünk: A süti-hozzájárulás kérése előtt is lefut a betűkészletek betöltése a fonts.gstatic.com címről, ami minden látogató IP-címét eljuttatja a szolgáltatóhoz.
Miért fontos: Az európai adatvédelmi gyakorlat szerint ez hozzájárulás nélküli adattovábbításnak minősül; több hasonló ügyben ez volt a jogsértés alapja.
Javaslatunk: A betűkészletek saját kiszolgálóra helyezése — ezzel a kérdés véglegesen megszűnik, és az oldal gyorsul is.

A süti-tájékoztató olyan adatkezelésről szól, amely jelenleg nem történik

Alacsony

Amit mértünk: A süti-sáv szövege személyre szabott hirdetésekről és forgalomelemzésről tájékoztat, miközben a 24 aloldal egyikén sem található analitikai vagy hirdetési mérőkód.
Miért fontos: A tájékoztatás és a valóság közötti eltérés ellenőrzés esetén nehezen magyarázható, a látogató számára pedig félrevezető.
Javaslatunk: A szöveg összehangolása a tényleges adatkezeléssel — vagy a mérés bevezetése (lásd a következő pontot), amivel a leírás válik igazzá.

6 · Mérhetőség

Mérés és mérhetőség

Ez a pont önmagában nem hiba, de minden további fejlesztés értékelését meghatározza.

Az oldalon nincs semmilyen mérés

Közepes

Amit mértünk: Egyik aloldalon sem található Google Analytics, Google Tag Manager vagy közösségi mérőkód, és az oldal HTML-je nem tartalmaz keresőkonzol-igazolást sem.
Miért fontos: Mérés nélkül nem tudható, hány érdeklődő érkezik, melyik szolgáltatásoldal hozza a megkereséseket, és mekkora eredményt hoz bármilyen fejlesztés — így a meta & AEO munka hatása sem igazolható számokkal.
Javaslatunk: Google Analytics 4 és Tag Manager beállítása az űrlapbeküldések és a telefonos kattintások mérésével, valamint a keresőkonzol hozzáférés rendezése. Ez a meta & AEO projekt mérési munkacsomagjának előfeltétele.

Pozitív oldal

Ami rendben van

Egy audit könnyen egyoldalúvá válik, ezért érdemes rögzíteni azt is, ami már most jól működik. Az alábbi 13 pontot ellenőriztük, és megfelelőnek találtuk.

A HTTP kérések 301-es átirányítással HTTPS-re, a www változat pedig a fő címre megy.

A nem létező címek helyesen 404-es választ adnak, és értelmes hibaoldalt jelenítenek meg visszalinkkel.

A távoli eljáráshívási felület (xmlrpc.php) nem válaszol — a kapcsolatot a kiszolgáló bontja.

A könyvtárlisták, a verziókezelő és a környezeti fájlok, valamint a hibanapló hívása 403-at ad.

A tartalom brotli tömörítéssel érkezik, a statikus állományok egy éves gyorsítótárazással.

A válaszban ott van a X-Content-Type-Options: nosniff fejléc.

A levelezéshez SPF és DKIM is be van állítva, és van DMARC rekord (bár még csak megfigyelő módban).

Minden űrlapmezőhöz tartozik kiolvasható címke — ez a leggyakoribb akadálymentességi hiba, és itt nincs jelen.

A billentyűzetes fókusz látható jelzést kap, és van „Ugrás a tartalomhoz" link (a célja viszont javításra vár).

Az oldal nyelve helyesen hu, és a megjelenítési beállítás nem tiltja a nagyítást.

Minden oldalon van egyedi kanonikus hivatkozás, a robots.txt és az oldaltérkép rendben van.

A süti-hozzájárulás kezelése működik, kategóriákkal, és alapból minden nem szükséges süti kikapcsolt állapotban van.

Az űrlapokon szerepel az adatkezelési hozzájárulás jelölése, a láblécben pedig az adatvédelmi tájékoztató és az ÁSZF.

Következő lépés

Melyikkel érdemes kezdeni?

Javaslatunk szerint a három magas prioritású ponttal: az adminisztrátori adatok elrejtésével, a márkaszínek kontrasztjának javításával és a képek helyes megjelenítésével. Ez a három egymástól függetlenül is elvégezhető, és a leglátványosabb eredményt adja. Ha kéri, a fenti megállapításokra külön árajánlatot készítünk, munkacsomagokra bontva.

Ajánlatot kérek a javításokra Vissza a meta & AEO ajánlatra

A felmérés a 2026. augusztus 3-i állapotot tükrözi, kizárólag nyilvánosan elérhető adatok alapján.