Weboldal-karbantartás 2026: feladatok, felelősségek és költségterv

A karbantartási díj akkor értelmezhető, ha tudod, milyen hibát előz meg, ki reagál rá, és milyen működést állít helyre. Egy céges bemutatkozó oldal és egy fizetést, készletet, számlázást kezelő webshop ugyanabban a tárhelycsomagban is egészen eltérő üzemeltetési feladatot jelenthet.

Nincs minden weboldalra érvényes havi frissítésszám vagy kötelező auditritmus. A szükséges munka az alkalmazásoktól, az adatváltozástól, a külső kapcsolatoktól és a kiesés következményétől függ. Az ajánlatban ezekből kell levezetni a vállalásokat, nem egy hosszú, de ellenőrizhetetlen szolgáltatáslistából.

Először készíts rendszerleltárt

Írd össze, hol van a domain, a DNS, a weboldal, a levelezés, a kódtár, a szerkesztői felület és az adatbázis. Minden elem mellé kerüljön tulajdonos, technikai felelős, számlázási kapcsolat és helyreállítási elérhetőség. A hozzáférés ne kizárólag egy korábbi fejlesztő magánfiókjában létezzen.

A függőségek között szerepeljen az űrlapküldő, a kereső, az analitika és a fizetési vagy számlázási kapcsolat is. Egy főoldal elérhetősége nem bizonyítja, hogy az ajánlatkérés megérkezik az értékesítőhöz. A működést a fontos ügyfélfolyamatok mentén kell ellenőrizni.

Magyar KKV-nál jó kiindulópont lehet az ajánlatkérés beérkezése, webshopnál pedig a rendelés, fizetési állapot, számla és szállítás összekapcsolása. Ezek üzleti ellenőrzések; az infrastruktúra felügyelete önmagában nem helyettesíti őket.

Más feladat a kirakat és a kereskedelmi háttér

Rendszerrész	Mit szükséges külön kezelni?
Statikus felület	Forráskód, függőségek, építés, telepítés, űrlapok és külső szkriptek
Tartalomkezelő	Felhasználók, bővítmények, tartalom és média mentése, előnézet
Kereskedelmi motor	Rendelési állapotok, jogosultságok, üzleti szabályok és verzióváltások
Adatbázis	Mentés, helyreállítás, hozzáférés, kapacitás és adatséma-változások
Fizetési kapcsolat	Értesítések hitelessége, megszakadt folyamatok, ismételt feldolgozás
Számlázás és szállítás	Hibás vagy elakadt műveletek, újrapróbálás, egyeztetés

Statikus HTML kiszolgálásakor nem feltétlenül fut saját adatbázis a nyilvános felület mögött. Ettől a kódtár, telepítési folyamat és külső szolgáltatás még karbantartandó. Ha pedig a kirakat mögött kereskedelmi motor és Postgres működik, az egész webshopot nem lehet statikus oldalként kezelni.

A Neocart ilyen összetett rendszer: Medusa 2 és Postgres háttérhez kapcsolódik az Astro-kirakat. A magyar adminisztráció, SimplePay, Számlázz.hu és GLS kapcsolata külön ellenőrzési feladatot jelent. A gyors termékoldal nem igazolja automatikusan a számlázás vagy a rendeléskezelés hibamentességét.

Frissítési rend kockázat alapján

Legyen felelős, aki figyeli a használt összetevők biztonsági értesítéseit és támogatottságát. Egy aktívan kihasznált, a saját rendszerben is elérhető sérülékenység más sürgősséget jelent, mint egy megjelenési finomítás. A döntést befolyásolja a támadhatóság, az érintett adat és az átmeneti védekezés lehetősége.

A WordPress hivatalos biztonsági útmutatója is kockázatcsökkentésként kezeli a védelmet, és külön tárgyalja a frissítést, hozzáférést és mentést. Ebből nem következik garantált biztonság, de az sem, hogy maga a WordPress szükségszerűen rossz választás.

Rutinfrissítés előtt legyen mentés és a változás jelentőségéhez illő próba. Webshopnál nézd meg a belépést, kosarat, pénztárat és a kapcsolódó értesítéseket. Sürgős javításnál rövidülhet a folyamat, de a kockázatot és a döntést akkor is rögzíteni kell. Ha nincs javítás, szóba jöhet az érintett funkció ideiglenes kikapcsolása vagy elérésének korlátozása.

A verziófrissítés visszavonhatóságát külön vizsgáld. A régi alkalmazáskód visszatöltése nem mindig állítja vissza a közben módosított adatbázist. Ezért adatbázis-változtatás előtt külön helyreállítási terv szükséges.

A mentés értéke a visszaállíthatóság

Először üzleti határt kell kijelölni: mennyi adat veszhet el, és mennyi ideig állhat a szolgáltatás? Egy ritkán frissülő bemutatkozó oldal és egy egész nap rendeléseket fogadó bolt külön választ kíván. A mentés gyakorisága és módja ebből következzen.

A PostgreSQL dokumentációja megkülönbözteti az adatbázismentés fő megoldásait. Az időpontra történő helyreállításhoz az alapmentés mellett megfelelő tranzakciónapló-archiválás szükséges; egy egyszerű adatbázis-export nem ugyanaz. A részleteket a folyamatos archiválás leírása tartalmazza.

A mentés terjedjen ki a szükséges képekre, fájlokra és konfigurációra is. A hozzáférési titkokat biztonságosan, a helyreállításhoz mégis elérhetően kell kezelni. Legyen a fő rendszertől megfelelően elkülönített másolat, hogy egyetlen hozzáférési incidens ne vigye el az éles adatot és minden mentést.

Visszaállítási próbán külön környezetben kell bizonyítani, hogy az alkalmazás elindul, az adatok olvashatók, és a fontos folyamatok működnek. A próbán ne induljanak valódi ügyféllevelek vagy fizetési műveletek. Rögzítsd a helyreállítás idejét és a hibákat; a mentési feladat zöld jelzése ehhez kevés.

Webshopnál a régi adatállapot visszatöltése után egyeztetni kell a közben lezajlott fizetésekkel és számlákkal. A külső szolgáltató nyilvántartása nem fordul vissza attól, hogy a saját adatbázist helyreállítottad. Az ilyen eltérésekhez kezelési eljárás kell.

Ki mit tesz incidenskor?

A szerződés különböztesse meg a bejelentés fogadását, a hiba vizsgálatának megkezdését és a megoldást. A rövid reakcióidő nem azonos a rövid helyreállítási idővel. Szerepeljen benne az elérhetőségi időszak, a sürgős eset definíciója és a helyettes kapcsolattartó.

Egy rendelési hiba esetén legyen megnevezve, ki állíthatja le a pénztárat, ki vizsgálja a naplókat, és ki tájékoztatja az érintett ügyfeleket. Először a további károkozást kell megállítani és a kivizsgáláshoz szükséges adatot megőrizni. A naplók ne tartalmazzanak szükségtelenül teljes személyes adatokat vagy hozzáférési titkokat.

Minden ember saját fiókot használjon, ahol lehet, többtényezős belépéssel. A fejlesztői és éles jogosultságok váljanak el, a szükségtelen fiókokat pedig vonjátok vissza. Hosszú távon a dokumentált hozzáféréskezelés teszi lehetővé, hogy a karbantartót szolgáltatáskimaradás nélkül lehessen lecserélni.

Mennyivel tervezz? Számolj azonos tartalommal

A havi költségterv képlete: infrastruktúra + licencek + tervezett munka + vállalt készenlét + külön elszámolt feladatok. Az egyszeri rendbetételt és az új funkciók fejlesztését ne rejtsd a rendszeres karbantartási sorba. Két ajánlatot csak azonos felelősségi és rendelkezésre állási határokkal hasonlíts össze.

Kizárólag számítási példa, nem piaci ársáv vagy Conen-ajánlat: 8 000 Ft havi infrastruktúra, 4 000 Ft licencköltség és 2 óra munka feltételezett 15 000 Ft-os óradíjjal összesen 42 000 Ft havonta. Ez évi 504 000 Ft, azonos nettó elszámolási alapon. A példa nem tartalmaz külön készenlétet vagy nagyobb helyreállítást. Ha ezekre is szükség van, azokat külön kell árazni.

Az ajánlatban kérdezz rá, mi történik a fel nem használt órákkal, ki fizeti a külső szolgáltató hibájának vizsgálatát, és a mentésből visszaállítás benne van-e a díjban. A „korlátlan támogatás” kifejezés önmagában nem mondja meg, mire számíthatsz egy péntek esti pénztárhibánál.

A mi karbantartási modellünk

A Neocart 2026. október 18-i ajánlatában a webáruház-motor és az alapfunkciók licencdíja 0 Ft, nincs havi szoftverdíj vagy forgalmi jutalék. A tárhely díja 4 990 vagy 9 990 Ft/hó + áfa, az élesítés 49 900 Ft + áfa. A domain díja külön, a regisztrátor szerint fizetendő. Az egyedi weboldalak ajánlat alapján készülnek.

Ezeket a díjakat nem szabad teljes karbantartási csomagként értelmezni. A rendelkezésre álló ajánlati tények nem rögzítenek hozzájuk általános díjmentes auditot, folyamatos DNS- vagy tanúsítványfelügyeletet, illetve meghatározott helyreállítási vállalást. A konkrét üzemeltetési feladatokat, mentést, támogatási időt és felelősséget írásban kell hozzárendelni a választott szolgáltatáshoz.

Mi kerüljön a rendszeres jelentésbe?

A jelentésből derüljön ki, mely változtatások történtek meg, mi maradt nyitva, mikor volt sikeres helyreállítási próba, és működtek-e az üzletileg fontos folyamatok. Tartalmi felülvizsgálatkor az árakat, elérhetőségeket és megszűnt szolgáltatásokat a cég kijelölt munkatársa ellenőrizze.

A képek, űrlapok és új tartalmak használhatóságát is követni kell; az akadálymentességet nem igazolja önmagában egy automatikus pontszám. A W3C útmutatója szerint az eszközös ellenőrzést emberi értékelés egészíti ki. A vizsgálatok ritmusát a változásokhoz és a kockázathoz igazítsd. A jó karbantartás végül abból látszik, hogy a cég ismeri a rendszer állapotát, és hiba esetén tudja, ki mit fog tenni.