Weboldal újratervezése vagy javítás? Döntési útmutató osztrák vállalatok számára tartós biztonsági problémák esetén

Rövid válasz
Egy új fejlesztés akkor indokolt, ha ismétlődő, rendszerszintű problémák (pl. tartós biztonsági rések, rossz Core Web Vitals mutatók a legfontosabb konverziós oldalakon, vagy elavult architektúra frissítési lehetőség nélkül) veszélyeztetik az üzleti működést, a konverziós arányokat vagy a szabályozási követelményeket. Ha viszont a technikai adósságok helyileg korlátozottak, és a kulcsfontosságú funkciók, valamint a biztonsági folyamatok tartósan helyreállíthatók, akkor a célzott javítások és átalakítások gyakran olcsóbbak és gyorsabbak. (Lásd az alábbi döntési útmutatót.)

Ellenőrzött tények (rövid)

• A weboldalak alapvető teljesítménymutatói = LCP, INP, CLS; célértékek: LCP ≤ 2,5 másodperc, INP < 200 ms, CLS < 0,1. Ezek a mutatók a Google Page Experience-jelzői közé tartoznak. (developers.google.com)
• A Google a rangsoroláshoz a mezőben mért értékeket használja (Chrome felhasználói élmény Jelentés / CrUX), és jelentéseket tesz közzé a Search Console-ban. (support.google.com)
• A Google 2026 júniusától a Search Console-ban külön teljesítményjelentéseket kínál a generatív mesterséges intelligencia által generált eredményekről (láthatóság az AI-áttekintésekben / AI-módban). Ez befolyásolja, hogy a tartalmak hogyan jelennek meg a mesterséges intelligencián alapuló válaszokban. (developers.google.com)
• Az OWASP közzéteszi a leggyakoribb biztonsági réseket (Top 10), és a webes biztonsági kockázatok terén irányadó forrásnak számít. (top10.owasp.org)
• A NIS-2 uniós irányelv (2023. január 16-tól hatályos) kiterjeszti az informatikai biztonsággal kapcsolatos kötelezettségeket; a kisvállalkozások elvileg mentesülnek ezek alól, de bizonyos esetekben vagy az ellátási láncokon keresztül érintettek lehetnek. Ausztria erről központi szinten tájékoztat. (nis.gv.at)

Probléma és tünetek

• Biztonsági tünetek: visszatérő vagy javítatlan CVE-riasztások, idegen fájlok/hátsó ajtók, kényszerített jelszó-visszaállítások, gyanús bejelentkezések vagy biztonsági incidensek utáni leállások. (Ellenőrizze a viselkedési és naplóadatokat.)
• Teljesítmény/felhasználói élmény – tünetek: magas kilépési arány a termék- vagy fizetési oldalakon, hosszú betöltési idők (látható a PageSpeedben / Search Console-ban), észrevehetően rossz Core Web Vitals-értékek az árbevételt befolyásoló oldalakon. Példa: A hős-kép vagy egy harmadik féltől származó szkript miatt az LCP értéke a termékoldalakon 4 másodperc fölé emelkedik. (developers.google.com)
• SEO/AI-láthatóság: hirtelen forgalomcsökkenés az organikus keresésben; 2026 óta emellett olyan esetek is előfordulnak, amikor a tartalmak alig vagy egyáltalán nem jelennek meg a Google AI-válaszokban (lehetséges új mutató a Search Console-ban). (developers.google.com)
• Karbantartási problémák: olyan bővítmény-ökoszisztéma, amelyben vannak már támogatást megszüntetett verziók, hiányoznak a gyártó által kiadott biztonsági frissítések, és a kritikus hibák kijavításához hosszú időre van szükség.

Mit mérjünk – és milyen pontossággal?

• Core Web Vitals (terepi adatok): Search Console → Core Web Vitals-jelentés (CrUX-alapú, 28 napos gördülő ablak, p75). A PageSpeed Insights a terepi és laboratóriumi adatokat jeleníti meg; a Lighthouse laboratóriumi adatokat szolgáltat az egyes auditokhoz. Használja a web-vitals JavaScript-könyvtárat saját RUM-nyomkövetéshez. (support.google.com)
  Eljárás: Határozza meg a forgalom szempontjából legfontosabb 10 URL-t (termék, kategória, fizetési folyamat), majd ellenőrizze azok p75-értékeit a Search Console-ban.
• Biztonsági helyzet: eszközleltár, aktuális javításlista (operációs rendszer, tartalomkezelő rendszer, bővítmények, könyvtárak), nyitott/lezárt CVE-k az első bejelentés dátumával, valamint incidensnaplók (szám és hatás). Referenciaként használja az OWASP webalkalmazásokra vonatkozó ellenőrzőlistáit. (top10.owasp.org)
• SEO-/AI-láthatóság: Search Console teljesítmény + 2026-tól a generatív AI-teljesítményjelentés (megjeleníti a megjelenítéseket/URL-eket az AI-funkciókban). Ellenőrizze a rangsorváltozásokat, az organikus megjelenítéseket és a kattintásokat a kulcsfontosságú időpontok előtt és után. (developers.google.com)
• Üzemeltetési költségek és piacra lépési idő: Határozza meg az alábbiakra fordított munkaórák számát és költségeket: (a) rövid távú javítások; (b) átfogó átalakítás; (c) teljes újraindítás (tervezés + migráció). Ezek az adatok döntő fontosságúak a befektetési megtérülés (ROI) összehasonlításához.

Üzleti hatások (konkrét)

• Konverzió/bevétel: A betöltési idő minden másodperce ronthatja a konverziót; különösen a fizetési és termékoldalak rendkívül érzékenyek erre. (A konkrét százalékos értékek változhatnak; mérje meg a saját konverziós csatornáin.) (developers.google.com)
• Hírnév és jogi kockázatok: A biztonsági események az érintett, EU-szintű bejelentési kötelezettség alá tartozó esetekben bejelentési kötelezettségeket és bírságokat vonhatnak maguk után (NIS-2: bejelentési határidők és az érintett vállalkozásokra kiszabható szankciók). A kisvállalkozásokra általában enyhítések vonatkoznak, de vannak kivételek is. (nis.gv.at)
• Láthatóság 2026+: A mesterséges intelligencián alapuló keresési funkciók megváltoztathatják a forgalom eloszlását és a kattintási arányt; a mesterséges intelligencia által generált válaszokban való láthatóság hiánya új versenytényezővé válik. Használja a Search Console jelentéseit a változások számszerűsítéséhez. (developers.google.com)

Prioritások: Most / Következő lépések / Később

• Most (azonnal, 0–2 hét)

  • Biztonsági gyorsellenőrzés: biztonsági mentések, hozzáférés-korlátozás (MFA), rendszergazdák jelszavainak rendszeres cseréje, kritikus CVE-k vészhelyzeti javítása. (Azonnali intézkedések, minimális erőfeszítés.) (top10.owasp.org)
  • Gyors mérés: Search Console Core Web Vitals + PageSpeed Insights az Ön legfontosabb oldalaihoz; állítson össze egy prioritási listát az oldalakról az árbevételre gyakorolt hatásuk szerint. (developers.google.com)

• Következő lépések (2–8 hét)

  • Rövid távú refaktorálás: a legnépszerűbb oldalakon a betöltést gátló szkriptek eltávolítása vagy késleltetése, képoptimalizálás, CDN-beállítások. Mérje meg a hatásokat a RUM és a PageSpeed segítségével. (web.dev)
  • Biztonsági megerősítés: bővítmények ellenőrzése, elavult bővítmények/kiegészítők eltávolítása, WAF használata, rendszeres sebezhetőségi vizsgálatok. (top10.owasp.org)
  • Jelentésbeállítás: Search Console-proprietás + az AI-teljesítményjelentéshez való hozzáférés engedélyezése; RUM-szkriptek (Web Vitals) beépítése. (support.google.com)

• Később (2–6 hónap)

  • Architektúra-döntés: Ha a problémák újra és újra felmerülnek, a költségek, a piacra lépésig eltelő idő és a biztonsági követelmények alapján döntsön a refaktorálás és az újjáépítés között (lásd a döntési kritériumokat).
  • Tesztelés és üzembe helyezés: átmeneti tesztelés, zárótesztelés, áttelepítési terv visszavonási lehetőséggel és felügyelettel.

Döntési szempontok: javítás/átalakítás vagy új fejlesztés
Értékelje szisztematikusan a következő kérdések alapján (minden “Igen” válasz → erősebb érv az új fejlesztés mellett)

1. A kulcsfontosságú függőségek (keretrendszer, CMS, PHP/Node-verziók) már nem frissíthetők, vagy lejárt a támogatásuk?
2. A biztonsági rések inkább strukturális jellegűek (architektúra, hibás hitelesítési logika), vagy inkább lokálisak (egy bővítmény)?
3. A legfontosabb KPI-problémák (konverzió, árbevétel, SEO-forgalom) számos oldaltípusra vonatkoznak, és nem csupán egyes oldalakra?
4. A tervezett termékstratégia (pl. omnichannel, headless, kiterjedt személyre szabás, külső rendszerekkel való integráció) olyan műszaki követelményeket támaszt-e, amelyeknek a meglévő rendszer nem tud megfelelni?
5. A 2–3 évre számított ismétlődő karbantartási és frissítési költségek (teljes tulajdonlási költség) meghaladják-e a tiszta újraindítás becsült költségeit?

Ha a válaszok többsége „nem“, akkor általában költséghatékonyabb a célzott javítás/átalakítás. Ha a válaszok többsége „igen“, akkor érdemes megfontolni egy új fejlesztést.

Konkrét példák (illusztrációként)

• A. példa (a javítás indokolt): WordPress-webáruház, amelyben egyetlen elavult, biztonsági réseket tartalmazó bővítmény található, egyébként a PHP-verzió naprakész, és a forgalom mérsékelt. Megoldás: a bővítmény cseréje, gyorsítótár használata és képoptimalizálás.
• B példa (új fejlesztés indokolt): Saját fejlesztésű webáruház-platform monolitikus, elavult kódbázissal, tesztelési lefedettség nélkül, ismétlődő biztonsági incidensekkel, valamint a javítások ellenére is tartósan gyenge teljesítménnyel az összes termékoldalon. Megoldás: Tervezhető újjáépítés (pl. moduláris, felhőalapú architektúra, automatizált tesztek, CI/CD).

Konkrét mérő- és vizsgálati eszközök (kezdéshez)

• Google Search Console (Core Web Vitals, Teljesítmény, Indexelési állapot). (support.google.com)
• PageSpeed Insights / Lighthouse (laboratóriumi és terepi). (developers.google.com)
• Chrome UX Report (CrUX) a p75-értékekhez; BigQuery/eszközök a részletesebb elemzésekhez. (developer.chrome.google.cn)
• Web Vitals JS-könyvtár saját RUM-hoz. (app.unpkg.com)
• OWASP-ellenőrzőlisták és WAF a biztonsági felülvizsgálathoz. (top10.owasp.org)

Döntéshozatali ellenőrzőlista (rövid)

• Van-e leltáruk az összes technikai alkatrészről és azok élettartam-végéről? (igen/nem)
• Főbb teljesítménymutatók: 75. oldal LCP ≤ 2,5 másodperc, INP < 200 ms, CLS < 0,1? (igen/nem) — ellenőrizze a Search Console segítségével. (developers.google.com)
• Vannak-e olyan kritikus CVE-k, amelyekre 72 órán belül nem lehet javítást telepíteni? (igen/nem)
• A jelenlegi platform olyan havi üzemeltetési és támogatási költségekkel jár-e, amelyek indokolják egy új rendszer kifejlesztését? (igen/nem)
• Szükség van-e megfelelésre/jelentéstételre (NIS-2 vagy ellátási láncra vonatkozó előírások)? (igen/nem) — tekintse meg az osztrák információkat. (nis.gv.at)
• Mérhető-e vagy csökken-e a láthatósága a mesterséges intelligencia által támogatott keresési formátumokban? (igen/nem) — Ellenőrizze a Search Console mesterséges intelligencia-jelentését. (developers.google.com)

Záró megjegyzés
Kezdje a mérési adatokkal: érvényes Search Console-/CrUX-adatok és naprakész biztonsági leltár nélkül minden döntési elemzés csupán spekulatív. Gyűjtse össze a fent említett mérési adatokat (legnépszerűbb URL-ek, biztonsági lista, karbantartási költségek), és használja a fenti ellenőrzőlistát, hogy tárgyilagos döntést hozhasson a javítás és az újratelepítés között.