Adminisztrátor

Weboldal karbantartás ár: Magyarországon a nyilvános csomagajánlatok alapján nagyjából havi 14 és 35 ezer forint között mozog. Néhány szolgáltató ennél olcsóbban is hirdet, 10 ezer forint körüli díjtól. Az összeg önmagában keveset mond: az számít, hogy mi van benne. Egy jó havidíj frissítéseket, ellenőrzött mentést, biztonsági átnézést, gyors hibajavítást és havi jelentést takar. Egy rossz csak azt a nyugtató érzést adja, hogy „valaki foglalkozik vele”.

Ebben a cikkben sorra vesszük, mit tartalmaz tipikusan egy karbantartási csomag, mitől lesz drágább vagy olcsóbb, és mire figyelj, mielőtt aláírsz egy ajánlatot. Nem kell hozzá műszaki tudás, csak néhány jó kérdés.

Weboldal karbantartás ár: mi a piaci sáv, és mire jó a szám?

A fenti 14-35 ezer forintos tartomány piaci tájékozódásra való, nem árlista. Hazai karbantartó cégek és fejlesztők nyilvános csomagjaiból áll össze, és két okból nem szabad mechanikusan alkalmazni.

Az első: a sáv alján jellemzően az egyszerűbb, a tetején a bővebb csomagok vannak. Két, azonos havidíjú ajánlat között így is lehet nagy különbség abban, hogy mi történik, ha baj van.

A második: nézd meg, hogy az ár nettó vagy bruttó. A 27 százalékos áfa miatt ez egy 14 ezer forintos ajánlatnál is több mint 3 ezer forint különbség havonta, egy évre számolva pedig már egy komoly tétel.

A szám tehát arra jó, hogy kiszűrd a két szélsőséget: azt az ajánlatot, amely gyanúsan olcsó, és azt, amelyik indoklás nélkül sokkal drágább a piacnál.

Mit tartalmaz tipikusan a havidíj?

Egy tisztességes csomag öt dolgot ad, bármilyen néven fut.

• Frissítések. A WordPress, a sablon és a bővítmények rendszeres, ellenőrzött frissítése. Az „ellenőrzött” a lényeg: a frissítés előtt visszaállítási pont készül, utána pedig valaki megnézi, hogy az oldal tényleg működik-e. Hogy ez miért nem egy gombnyomás, ebben a cikkben írtunk róla részletesen.
• Mentés. Napi vagy heti rendszerességgel, külön helyre mentve. Az is számít, hogy valaki kipróbálja-e a visszaállítást, mert a mentés addig csak remény. Erről itt írtunk bővebben.
• Biztonsági ellenőrzés. Ismert sebezhetőségek keresése, elavult vagy veszélyes bővítmények kiszűrése, a tanúsítvány és a tárhely lejáratának figyelése.
• Gyors hibajavítás. Ha a rutinfeladatok során vagy utána valami elromlik, valaki foglalkozik vele. Hogy pontosan mennyi időn belül és mire terjed ki, az az ajánlat egyik legfontosabb sora.
• Havi jelentés. Egy rövid, érthető összefoglaló arról, mi történt az oldaladdal. Ha nincs jelentés, nem látod, mit fizetsz.

Gyakran ide jön még az elérhetőség figyelése: egy rendszer néhány percenként megnézi, hogy az oldal elérhető-e, és értesít, ha nem.

Weboldal karbantartás ár: mitől lesz drágább vagy olcsóbb?

Három tényező mozgatja a legtöbbet.

Webshop vagy bemutatkozó oldal?

Ez a legnagyobb különbség. Egy bemutatkozó oldal hibája kellemetlen, de az érdeklődő visszanéz vagy telefonál. Egy webshopnál a kosár és a pénztár működése maga a bevétel, ezért a webshop karbantartása több ellenőrzést kíván: a kosarat, a pénztárat, a fizetési módokat, a visszaigazoló leveleket. Hogy ez pontosan mit jelent, a webshopokról szóló cikkünkben végigvettük. Magánrendelőknél hasonló a helyzet az időpontfoglalóval, ezt itt írtuk le.

Mekkora és mennyire bonyolult az oldal?

Egy tucatnyi oldalas, kevés bővítményes weboldalt gyorsabb átnézni, mint egy sok bővítményből, külső szolgáltatásból és egyedi kódból álló rendszert. Több bővítmény több frissítést, több lehetséges ütközést és több ellenőrizendő pontot jelent.

Milyen gyorsan reagálnak?

Aki hétköznap egy-két munkanapon belül válaszol, az mást ígér, mint aki 24 órás támogatást hirdet. Ez utóbbi vonzó, de kérdezd meg, mit jelent pontosan: valaki valóban kijavítja éjjel a hibát, vagy csak fogadják a bejelentést? A gyorsabb, szorosabb vállalás drágább, és ez rendjén van, ha tényleg megvalósul.

Mire figyelj az ajánlatnál: nyolc figyelmeztető jel

Ezek nem azt jelentik, hogy az ajánlat rossz, hanem azt, hogy kérdezz rá.

1. Nincs leírva, mi van benne. Ha az ajánlat csak annyit mond, hogy „teljes körű karbantartás”, de nincs felsorolás, nem tudod számon kérni.
2. Nem derül ki a mentés gyakorisága és helye. Ha a mentés ugyanazon a szerveren van, mint az oldal, a legrosszabb napon a mentés is elvész az oldallal együtt.
3. Nincs havi jelentés. Nem látod, mit kapsz a pénzedért.
4. Nem tudni, nettó vagy bruttó az ár. Az áfa miatt ez komoly különbség.
5. „Korlátlan” fejlesztés vagy javítás a havidíjban. Ez ritkán igaz. Kérdezd meg, mit jelent a gyakorlatban, és mi számít már külön megrendelésnek.
6. Hosszú, kötött szerződés. Ha éves kötés van, de a szolgáltatás tartalma homályos, nehéz kilépni belőle. Kérdezd meg a felmondási időt.
7. Rejtett költségek. A bővítmények licencdíja, a tárhely és a domain gyakran külön fizetendő. Az ajánlatnak ki kell mondania, mi tartozik hozzád, és mi nem.
8. Nincs válaszidő, vagy minden azonnal megoldódik. Egy hiteles ajánlat leírja, mennyi időn belül reagálnak, és azt is, mit nem vállalnak.

Három kérdés, amit érdemes feltenni ajánlatkérés előtt

Mielőtt árakat hasonlítasz, kérdezd meg mindenkitől ugyanezt:

• Pontosan mit mentetek, milyen gyakran, és hol van a mentés?
• Mi történik, ha egy frissítés után elromlik az oldal, és ez a havidíjban van-e?
• Mi nem tartozik bele, és azt mennyiért vállaljátok külön?

Aki ezekre pontosan és érthetően tud válaszolni, annál világos, mit kapsz. Ha kitérő választ kapsz, kérd mindent írásban, mielőtt döntesz.

Hogyan viszonyítsd az árat a saját oldaladhoz?

Egy karbantartási havidíjat nem a piaci átlaghoz, hanem a saját kockázatodhoz érdemes mérni. Ha az oldalad csak névjegy, egy egyszerűbb csomag elég lehet. Ha az oldalon keresztül jön be a megrendelés, az időpontfoglalás vagy a megkeresések nagy része, akkor a havidíj azt a kérdést is megválaszolja, hogy mennyi kiesést bírsz el. Egy webshopnál könnyű kiszámolni, mennyi egy átlagos esti óra forgalma, és abból látszik, mekkora kiesést nem szeretnél elszenvedni.

Ha a mostani fejlesztőd már nem elérhető, és nem tudod, ki fér hozzá az oldaladhoz, ebben a cikkben leírtuk, mit tegyél először.

Weboldal karbantartás nálunk: mit vállalunk, és mit nem

A WooWebsite három csomagot kínál: egyszerűbb bemutatkozó oldalra, aktív szolgáltatói oldalra és WooCommerce webshopra. Az aktuális árakat és a csomagok pontos tartalmát a karbantartás oldalon találod meg, itt azért nem ismételjük, hogy ne kerüljön két helyre két, idővel eltérő szám.

Néhány dolgot előre kimondunk. A szolgáltatás nem ügyeleti jellegű: munkanapokon jellemzően egy, legkésőbb két munkanapon belül adunk első érdemi visszajelzést. A havidíj nem korlátlan fejlesztői órakeret, a csomagon kívüli munkát külön megrendelés alapján, előzetes költségjelzéssel végezzük. A feltört oldal megtisztítása nem része a havidíjnak. A szerződés határozatlan idejű, 30 napos felmondással, a domain és a tárhely díját pedig közvetlenül a szolgáltatódnak fizeted.

Gyakori kérdések

Mennyi egy átlagos weboldal karbantartás ára havonta?

A nyilvános csomagok alapján nagyjából 14 és 35 ezer forint között van, de ez piaci tájékozódási sáv, nem garantált ár. Az egyszerűbb csomagok a sáv alján, a bővebbek és a webshopra szabottak a tetején vannak. Az összehasonlításnál mindig ellenőrizd, hogy nettó vagy bruttó az összeg.

Miért nem elég egyszer rendbe tenni az oldalt?

Mert a WordPress, a sablon és a bővítmények folyamatosan újulnak, és a régi verziókban idővel biztonsági rések keletkeznek. Egy egyszeri rendbetétel pillanatnyi állapotot ad, a karbantartás azt tartja fenn.

Be kell-e fizetnem karbantartást, ha az oldalt valaki más készítette?

Nem kötelező, de ha nincs gazdája a frissítéseknek és a mentésnek, a kockázat megmarad. Új karbantartóval érdemes először egy állapotfelmérést kérni.

Elég-e, ha csak a tárhelyszolgáltatóm csinál mentést?

Nem biztos. A tárhely mentése a szolgáltató dolga, de az nem biztos, hogy tartalmaz minden fájlt és adatbázist, és hogy a visszaállítás gyors. Kérdezd meg, mit mentenek pontosan, és ki tudja-e próbálni veled a visszaállítást.

Mi a különbség a karbantartás és a hibajavítás között?

A karbantartás megelőz, a hibajavítás utólag cselekszik. Egy jó havidíj az előbbit adja, és tisztázza, hogy az utóbbiból mennyi tartozik bele.

Következő lépés

Ha ajánlatot hasonlítasz, vagy nem tudod, hogy a mostani karbantartásod mit tartalmaz, írd meg az oldalad címét és hogy WordPress vagy WooCommerce webshop-e. Átlátható ajánlatot küldünk, és megmondjuk azt is, ha nálad kisebb csomag elég. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül visszajelzünk. Az aktuális árakat a karbantartás oldalon találod.

A webshop karbantartás addig nem kerül szóba, amíg egy átlagos kedd este el nem akad a kosár. Addig minden rendben van: jönnek a rendelések, megy a csomagolás, a hirdetés hozza a látogatókat. Aztán egy frissítés után a „Fizetés” gomb nem reagál, és senki nem szól róla, mert a vásárló nem hibajegyet ír, hanem bezárja a lapot.

Ebben a cikkben végigszámoljuk, mennyit veszíthetsz egy ilyen órán, hol szokott elakadni egy WooCommerce webshop (a WordPress legelterjedtebb webáruház-bővítménye), és mit ellenőrizhetsz még ma, technikai tudás nélkül.

Miért más a webshop, mint egy bemutatkozó oldal

Egy bemutatkozó oldal hibája kellemetlen, de az érdeklődő visszanéz, vagy felhív. A webshopnál a bevétel nem mellékhatás, hanem maga az oldal működése. A kosár, a pénztár, a fizetési mód, a készlet, a szállítási díj és a visszaigazoló levél közül bármelyik elakadása azt jelenti, hogy a vásárló nem tud fizetni.

Aki épp vásárolni akart, nem vár. Megnyitja a következő boltot a keresőben, és onnantól valaki más kasszájába fizet.

Mennyit veszítesz egy óra alatt

Egyetlen igaz szám nincs, ezért érdemes a sajátodat kiszámolni. Vedd a havi forgalmadat, oszd el a napok számával, majd nézd meg a rendelések időpontjait: a napi rendelések mekkora része érkezik a legerősebb, mondjuk esti időszakban.

Egy kitalált példa, a számok csak az érthetőség kedvéért vannak itt: egy bolt havi forgalma 6 millió forint, vagyis napi átlagban 200 ezer. Ha a rendelések harmada az esti négy órában jön be, az 66 ezer forint, óránként átlagosan 16-17 ezer. A csúcsóra ennél több. Ha pont ekkor áll a pénztár, ennyi forgalom marad el.

Ehhez jön még két dolog, ami nem látszik a számlán. A hirdetés közben tovább költi a keretet, hiába viszi a látogatót egy működésképtelen pénztárhoz. A vásárló pedig, aki egyszer elakadt, nem biztos, hogy holnap visszatér. A forgalom persze nem egyenlő a nyereséggel, de a kiesés ettől még valós.

Hol akad el leggyakrabban egy WooCommerce webshop

Ezek tapasztalati pontok, nem statisztika, de érdemes őket egyenként végiggondolni:

• Frissítés után. A WooCommerce, egy bővítmény vagy a sablon frissítése után a kosár vagy a pénztár másképp viselkedik, mint előtte. Erről részletesen korábban írtunk.
• Fizetési mód. Egy fizetési lehetőség eltűnik, vagy hibaüzenetet ad a pénztárnál.
• Visszaigazoló levél. A rendelés megérkezik, de a vásárló nem kap visszaigazolást, ezért bizonytalan, újra próbálkozik, vagy lemond.
• Szállítási díj és készlet. A rossz szállítási díj vagy a nem csökkenő készlet csak később, a csomagoláskor derül ki.
• Lejárat és telítettség. Lejár az SSL-tanúsítvány vagy a domain, esetleg megtelik a tárhely.
• Háttérfeladatok. Az ütemezett feladatok, például az automatikus levélküldés vagy készletfrissítés megakadnak.

A legdrágább hiba az, amelyik csendben marad

A legrosszabb leállás nem az, amikor eltűnik az oldal. Az gyorsan kiderül. A legrosszabb az, amikor a webshop elérhető, a termékek látszanak, csak épp a pénztár nem megy végig. Nincs hibaüzenet a tulajdonosnak, csak egyre kevesebb rendelés, amit könnyű a szezonnak, a hirdetésnek vagy a rossz hétnek tulajdonítani.

Ezért nem elég azt figyelni, hogy az oldal elérhető-e. A bolt működését is nézni kell: a kosarat, a pénztárat és a visszaigazolásokat. Ha ezeket senki nem nézi rendszeresen, a hibát gyakran a vásárlók távolmaradása jelzi, nem a technika.

Tíz perc, amit ma megtehetsz

Nem kell fejlesztőnek lenned. Vedd a telefonodat, és menj végig a saját boltodon úgy, mintha vásárló lennél:

• Adj le egy próbarendelést mobilról. Próbáld ki az összes fizetési módot, amit kínálsz. Ha valamelyiket nem tudod kipróbálni, kérdezd meg a szolgáltatót, hogyan tesztelheted.
• Nézd meg, megérkezik-e a visszaigazoló levél. Nézd meg a levélszemét mappát is.
• Ellenőrizd, csökken-e a készlet a próbarendelés után.
• Próbálj ki két-három szállítási címet, és nézd meg, hogy a szállítási díj helyes-e.
• Nézd meg, mikor érkezett az utolsó rendelés. Ha szokatlanul régen, ne várd meg a hónap végi összesítést.
• Kérdezd meg, mikor frissült utoljára a WooCommerce és a bővítmények, és van-e friss, tesztelt mentés. A mentésről itt írtunk bővebben.
• Jegyezd fel, mikor jár le a domain, a tárhely és az SSL-tanúsítvány.

Ha ezek közül kettőre nem tudod a választ, az nem azt jelenti, hogy most baj van. Azt jelenti, hogy jelenleg nem te döntöd el, mikor derül ki.

Webshop karbantartás nálunk: mit vállalunk, és mit nem

Ugyanezt a gondolatot egy magánrendelő weboldalánál is leírtuk: ott az időpontfoglaló a pénztár megfelelője. A webshopoknak külön csomagunk van. Az aktuális árakat és a csomag pontos tartalmát a karbantartás oldalon találod meg. A Webshop csomagban ezek vannak:

• a WooCommerce és a kiegészítők ellenőrzött frissítése, a frissítés előtt visszaállítási ponttal;
• napi teljes fájlmentés és nyolcóránkénti adatbázismentés;
• a kosár, a pénztár, a fiók és a bejelentkezési oldal ellenőrzése, és annak ellenőrzése, hogy egy termék betehető-e a kosárba;
• a fizetési módok megjelenésének technikai ellenőrzése és a rendelés-visszaigazoló rendszerüzenetek alapellenőrzése;
• az ütemezett feladatok és a WooCommerce rendszerállapot alapellenőrzése;
• az oldal elérhetőségének ötpercenkénti figyelése, leállás esetén értesítéssel;
• havi, WooCommerce-specifikus állapotriport.

Érdemes a havidíjat a saját számoddal összevetni: a karbantartás oldalon megtalálod az aktuális árat, te pedig kiszámolhatod, mennyi egy átlagos esti óra forgalma a boltodban.

Az adatbázismentés gyakorisága azért lényeges, mert a rendelések az adatbázisban vannak. Egy visszaállításnál az számít, mennyi idős a legutóbbi mentés.

Amit nem ígérünk, azt is kimondjuk. A szolgáltatás nem ügyeleti jellegű, nincs benne garantált szolgáltatási szint, és nem azonnali hibaelhárítás. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül adunk első érdemi visszajelzést. A havidíj nem korlátlan fejlesztői órakeret: a csomagon kívüli javítást és fejlesztést külön megrendelés alapján, előzetes költségjelzéssel végezzük. A harmadik fél szolgáltatásának, például a fizetési szolgáltatónak a hibája, az egyedi integrációk javítása és a feltört oldal megtisztítása nem része a havidíjnak.

A domain és a tárhely díját közvetlenül te fizeted a szolgáltatódnak, nem mi viszonteladunk. A szerződés határozatlan idejű, 30 napos felmondási idővel, vagyis nem kötünk le évekre.

Egy webshopnál az a legnagyobb kockázat, ha baj esetén nincs kihez fordulni. Ezért a havi riportban hónapról hónapra látod, mi történt a háttérben, és tudod, kinek írj, ha elakad valami. Ha a mostani fejlesztőd már nem érhető el, ebben a cikkben leírtuk, mit tegyél.

Gyakori kérdések

Elég, ha az oldal elérhetőségét figyelitek?

Nem. Az ötpercenkénti figyelés azt mutatja meg, hogy az oldal elérhető-e, azt nem, hogy a pénztár végigmegy-e. Ezért tartalmazza a Webshop csomag a kosár, a pénztár és a fizetési módok megjelenésének ellenőrzését is.

Mennyi időn belül reagáltok, ha leáll a pénztár?

Ha az oldal elérhetetlenné válik, a figyelőrendszer figyelmeztetést küld. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül adunk első érdemi visszajelzést, de ez nem egyenlő a hiba teljes javításának idejével. Ügyeleti szolgáltatást nem vállalunk, és ezt előre kimondjuk.

Mi történik, ha egy általatok végzett frissítés után elromlik a bolt?

A frissítés előtt visszaállítási pontot készítünk. Ha az általunk végzett rutinfrissítés okoz közvetlenül hibát, elvégezzük az alapvizsgálatot, és szükség esetén visszaállítjuk az előző működő állapotot. Egyedi kompatibilitási fejlesztés vagy korábban is meglévő hiba javítása külön díjas lehet.

Mennyibe kerül, és mi az induló audit?

A havidíjat és az induló audit díját a karbantartás oldalon találod meg, itt nem ismételjük, hogy ne legyen eltérés. Mielőtt átvesszük a webshopot, ellenőrizzük a technikai állapotát, a mentéseit és a frissíthetőségét. Ha mi készítettük az oldalt, és közvetlenül karbantartásba kerül, nincs külön auditdíj. Konkrét helyzetedre kérj ajánlatot.

Minden webshophoz jó a Webshop csomag?

Nem feltétlenül. A csomag hagyományos WooCommerce-webshopokra szól. Többnyelvű, előfizetéses, piactér jellegű, nagy forgalmú vagy egyedi integrációkat használó boltnál egyedi ajánlatot adunk, ezt is itt kérheted.

Következő lépés

Ha nem vagy biztos benne, hogy a webshopod pénztára és visszaigazolásai most rendben működnek, írd meg a bolt címét, és hogy ismersz-e már technikai problémát, majd kérj ajánlatot. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül visszajelzünk. Az aktuális árakat a karbantartás oldalon találod.

A magánrendelő weboldal karbantartása ritkán kerül szóba addig a napig, amíg nincs rá szükség. Az oldal ott van, működik, az időpontfoglaló küldi a visszaigazolásokat, senki nem gondol rá. Aztán egyik napról a másikra lejár az SSL-tanúsítvány, vagy egy plugin-frissítés után eltűnik az űrlap, és a páciens, aki épp most keresett rá a rendelőre Google-ben, egy hibaüzenetet lát, majd továbblép a következő találatra.

Ez nem elméleti kockázat. Egy magánrendelő vagy klinika esetében a weboldal nem bemutatkozó kártya, hanem az első, sokszor egyetlen érintkezési pont a pácienssel, mielőtt az egyáltalán felhívna vagy befizetne egy vizitdíjat.

Miért más ez egy magánrendelőnél, mint egy átlagos kisvállalkozásnál

Egy éttermi weboldalnál, ha délután két órára nem tölt be a menü, a vendég többsége egyszerűen felhívja a helyet, vagy másnap visszanéz. Egy magánrendelőnél a tétek magasabbak, és ez nem túlzás.

A páciens, aki először keres fel egy magánszolgáltatót, jellemzően bizalmi döntést hoz: ki fogja megvizsgálni, kezelni, esetleg megműteni. Ha a weboldal elavultnak, lassúnak vagy bizonytalannak hat, ez nem „kicsit kellemetlen”, hanem közvetlenül azt az üzenetet közvetíti, hogy a háttérben talán a szakmai munka is így néz ki. Nem igazságos logika, de ez a valóság, ahogyan a páciensek döntenek.

Emellett a vásárlási sürgősség is más jellegű. Sok esetben nem „majd egyszer” keres valaki fogorvost vagy bőrgyógyászt, hanem most, mert fáj valami, vagy mert egy szűrésre van szüksége belátható időn belül. Ha pont akkor nem tud időpontot foglalni, mert hibás az oldal, a legtöbben nem várnak, hanem a következő rendelőt keresik meg.

Mi történik valójában, ha leáll az időpontfoglaló

Vedd végig, mi az a lánc, amit egyetlen hibás plugin vagy lejárt tanúsítvány elindít:

A beteg rákattint az „Időpontot kérek” gombra. A form nem küld semmit, vagy hibaüzenetet dob. Nem fog visszamenni és megpróbálni harmadszor is, inkább felhívja a recepciót, ha van, vagy egyszerűen megkeresi a következő találatot a keresőben. A recepció eközben nem tudja, hogy a weboldal hibás, csak azt látja, hogy aznap kevesebb a bejövő hívás, vagy hogy valaki furcsa kérdéseket tesz fel telefonon, mert valójában online akart foglalni.

Ez a veszteség nem jelenik meg sehol egy számlán. Nincs hibaüzenet, amit a tulajdonos lát, nincs riasztás, csak egyre kevesebb foglalás, amit nehéz egy konkrét okhoz kötni. Ez a legköltségesebb fajta hiba: az, amelyikről nem is tudod, hogy történik.

A GDPR és az adatvédelem nem formalitás egy orvosi weboldalon

Egy orvosi vagy egészségügyi weboldal nem csak nevet és telefonszámot kér el egy kapcsolati űrlapon. Gyakran egészségügyi jellegű információ is elindul a form kitöltésekor, akár csak annyi, hogy „mely panasz miatt szeretne időpontot kérni”. Ez érzékeny adat, és a kezelése nem technikai apróság, hanem jogi és bizalmi kérdés egyszerre.

Ha a weboldal elavult titkosítással fut, ha a form nem megfelelően tárolja vagy továbbítja az adatot, vagy ha egyáltalán nincs egyértelmű adatkezelési tájékoztató a form mellett, ez nem csak elvi kockázat. Egy páciens, aki ezt észreveszi, joggal gondolja meg magát.

Mit nézz meg, ha bizonytalan vagy a jelenlegi oldalad állapotában

Nem kell technikai szakembernek lenned ahhoz, hogy ellenőrizd a legfontosabb pontokat. Néhány perc alatt végigmehetsz ezeken:

• Nyisd meg az oldalt és nézd meg a címsor melletti lakat ikont. Ha figyelmeztetést kapsz, vagy nem zöld/szürke lakatot látsz, az SSL-tanúsítvánnyal van probléma, ami bizalmatlanságot kelt és a Google is rosszabbul rangsorolja az oldalt.
• Próbálj ki egy teszt-időpontfoglalást magadtól. Töltsd ki a formot úgy, mintha páciens lennél, és ellenőrizd, hogy valóban megérkezik-e a visszaigazolás vagy az értesítés a rendelőbe.
• Kérdezd meg, mikor volt utoljára frissítve a WordPress és a pluginok. Ha a válasz „nem tudom” vagy „régen”, az azt jelenti, hogy ismert biztonsági rések is nyitva lehetnek rajta.
• Kérdezd meg, van-e friss, tesztelt mentés az oldalról. Nem az a kérdés, hogy készül-e mentés, hanem hogy valaha visszaállították-e már egyet, és működött-e.

Ha ezekre a kérdésekre nincs egyértelmű válaszod, az nem feltétlenül jelenti, hogy most éppen baj van. Azt jelenti, hogy jelenleg nem te döntöd el, mikor derül ki, ha lesz.

Amit mi vállalunk ebben

Ugyanazt a fegyelmet alkalmazzuk egy magánrendelő weboldalánál, amit korábban megírtunk azzal kapcsolatban, hogy egy weboldal-fejlesztő miért tűnik el, és hogyan válassz olyat, aki nem teszi ezt. Egy orvosi praxisnál ez különösen fontos, mert itt a „majd ráérünk vele” hozzáállásnak közvetlen, mérhető ára van: elmaradt foglalás, bizalomvesztés, és adott esetben jogi kockázat.

A karbantartási szolgáltatásunk ezért nem egy homályos „mindig figyelünk” ígéret, hanem konkrét, dokumentált vállalás: rendszeres plugin- és WordPress-frissítés, folyamatos elérhetőség-figyelés, tesztelt biztonsági mentés, és havi riport arról, mi történt a háttérben. A domain és a tárhely a rendelő nevén fut, nem a miénken, írásban is rögzítve.

Amit nem ígérünk: 0-24 órás orvosi ügyeletszerű, azonnali technikai elérhetőséget. Ez tisztességtelen ígéret lenne egy havi karbantartási díjért, és aki ezt mondja, az valójában nem azt vállalja, amit mond.

Gyakori kérdések

Elég, ha csak az SSL-tanúsítványt figyelitek, a többi marad úgy, ahogy van?

Nem javasoljuk. Az SSL csak egy tünet a sok közül: ha az oldal elavult, a mögötte lévő WordPress-mag és a pluginok is azok, és pont ezek a legtöbb biztonsági rés forrásai. A karbantartás ezért mindig a teljes rendszerre vonatkozik, nem egyetlen beállításra.

Ti kezelitek a páciensek egészségügyi adatait is, vagy csak a weboldal kódját?

A weboldal technikai üzemeltetését és a forma-adatok biztonságos továbbítását végezzük, nem mi tároljuk vagy kezeljük a páciens egészségügyi adatait magát. Az adatkezelési felelősség a rendelőé marad, de abban segítünk, hogy a technikai háttér (titkosítás, biztonságos űrlap, naprakész rendszer) megfelelően támogassa ezt.

Mennyi idő alatt reagáltok, ha hirtelen leáll az időpontfoglaló?

Az oldal elérhetőségét 5 percenként figyeljük, úgyhogy egy leállásról gyorsan értesülünk. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül adunk első érdemi visszajelzést a hibáról és a következő lépésről. Fontos őszintén kimondani: ez nem 0-24 órás ügyeleti szolgáltatás, és nem azonnali hibaelhárítási garancia, ezt a szerződésben is pontosan így rögzítjük.

Mennyibe kerül ez havonta egy kisebb rendelőnek?

Ez a weboldal jelenlegi állapotától és a kívánt szolgáltatási szinttől függ. Az aktuális árakat és a csomagok pontos tartalmát a karbantartás oldalon megtalálod. Ha a rendelőd oldala egyedi igényekkel bír, kérj ajánlatot, és megmondjuk, mire van szükség.

Következő lépés

Ha bizonytalan vagy, hogy a rendelőd weboldala jelenleg mennyire van kitéve ennek a kockázatnak, írd le röviden, melyik oldalról van szó, és kérj ajánlatot. Munkanapokon jellemzően egy, legkésőbb két munkanapon belül visszajelzünk. A karbantartási csomagokat és az aktuális árakat a karbantartás oldalon találod.

Eltűnt a weboldal-fejlesztőd, és nem tudod, kihez fordulj? Nem vagy egyedül ezzel. Küldtél már üzenetet olyan fejlesztőnek, aki két héttel korábban még napi szinten válaszolt, aztán egyszer csak elnémult? Nem mondott fel, nem küldött búcsúüzenetet, egyszerűen leállt a kommunikáció. Közben az oldalad látszólag működik, egészen addig, amíg valami el nem romlik, és kiderül, hogy nincs kit hívni.

Ez nem ritka, kínos kivétel a magyar weboldal-piacon, hanem visszatérő, jól ismert helyzet. Ha most éppen ebben vagy benne, ez a cikk két dolgot tisztáz: mit tegyél most, azonnal, és mire figyelj, hogy legközelebb ne kerülj újra ugyanoda.

Miért tűnik el ilyen gyakran egy weboldal-fejlesztő

Ennek ritkán oka a rosszindulat. A magyar piacon a legtöbb weboldal-fejlesztő szabadúszóként vagy mellékállásban dolgozik, projekt alapon. A weboldal elkészül, kifizeted, a szerződés (ha egyáltalán volt írásos szerződés) ezzel lezárul. Karbantartásra, folyamatos elérhetőségre a legtöbb esetben senki nem kötelezte el magát, mert ez nem volt része az eredeti megállapodásnak.

Innentől a fejlesztő szemében lezárt projekt vagy, nem folyamatos ügyfél. Ha közben új megrendelést kap, ha megváltozik az élete, vagy ha egyszerűen nincs kapacitása a régi projekteket követni, a válaszidő nő, majd egy idő után teljesen elmarad. Nem azért, mert téged személy szerint faképnél hagyott volna, hanem mert soha nem volt olyan szerződéses vagy üzleti kötelezettsége, ami ennek ellenkezőjét garantálta volna.

Ez a struktúra a probléma, nem a konkrét ember. A megoldás ezért nem az, hogy „keress egy megbízhatóbb fejlesztőt”, hanem konkrét, számon kérhető feltételek, amiket a következő választásnál előre tisztázol.

Mit tegyél most, ha eltűnt a weboldal-fejlesztőd

1. Nézd meg, kinél vannak a hozzáférések. Ha a domain, a tárhely és a WordPress admin a te nevedhez, a te fiókjaidhoz tartozik, van időd rendesen körülnézni és új partnert választani. Ha bármelyik a fejlesztő nevén vagy fiókjában fut, ez most a legsürgősebb teendőd, mert enélkül gyakorlatilag nem tudsz sem fejlesztőt váltani, sem bármit módosítani az oldaladon.

2. Ne várj tovább „majd biztos jelentkezik” alapon. Ha két-három hete nincs érdemi válasz egyetlen üzenetre sem, ésszerű úgy kezelni a helyzetet, mintha nem jönne több. A halogatás ebben a helyzetben nem óvatosság, csak elveszett idő, amíg az oldalad karbantartás nélkül marad.

3. Kérj egy gyors technikai állapotfelmérést, mielőtt bárkivel új szerződést kötsz. Mielőtt fizetsz bárkinek bármiért, tudnod kell, milyen állapotban van most az oldalad: mikor volt utoljára frissítve, van-e működő mentés, lejárt-e valamelyik licenc. Enélkül vakon vásárolsz.

4. Ha most kell formálisan átvenned az oldalt, menj végig egy konkrét listán, ne emlékezetből. Van egy részletes, pontról pontra végigjárható ellenőrző listánk pontosan erre a helyzetre: mit kérj el, mit ellenőrizz, mielőtt bármit aláírsz vagy kifizetsz az átvételért. Ha az eltűnt fejlesztő még mindig nem válaszol, a lista azt is megmutatja, mi tehető akkor is, ha ő már nincs a képben.

Hogyan válassz olyan weboldal-fejlesztőt, akinél ez nem fordulhat elő

Nem lehet garantálni, hogy egy ember soha nem lesz beteg, nem megy szabadságra, vagy nem változtat karriert. Amit meg lehet nézni előre, azok a konkrét, ellenőrizhető feltételek, amik a válaszadást és a hozzáférést nem egyetlen ember jóindulatára bízzák.

• Van-e írásos szerződés, ami rögzíti a válaszidőt? Ha a „gyorsan reagálok” csak szóbeli ígéret, semmit nem ér. Kérdezd meg konkrétan: hány munkanapon belül kapsz első érdemi választ, ha probléma van.
• Ki nevén futnak a hozzáférések? A domain és a tárhely a te nevedhez, a te fiókodhoz tartozzon, ne a fejlesztőéhez. Ha ő ragaszkodik ahhoz, hogy ezek nála maradjanak „úgy egyszerűbb”, az önmagában figyelmeztető jel.
• Mi történik, ha a fejlesztő éppen nem ér rá? Egyetlen emberen múlik minden, vagy van mögötte olyan folyamat, ami akkor is működik, ha ő beteg vagy szabadságon van?
• Mióta dolgozik együtt hosszú távú ügyfelekkel? Egy több éve futó karbantartási kapcsolat sokkal erősebb bizonyíték, mint bármilyen ígéret az első beszélgetésen.
• Kapsz-e rendszeres visszajelzést, vagy csak akkor hallasz róla, ha baj van? Egy havi állapotriport azt jelzi, hogy valaki ténylegesen figyeli az oldaladat, nem csak akkor jelentkezik, amikor esedékes a számla.

Ha ezekre a kérdésekre nincs egyértelmű, konkrét válasz, az nem feltétlenül jelenti, hogy rossz fejlesztőt választasz, de azt jelenti, hogy megint a szerencsén fog múlni, mennyire lesz elérhető, amikor szükséged lesz rá.

Amit mi ígérünk, és amit szándékosan nem ígérünk

Fontos őszintén kezelni ezt: senki nem tud 0-24-es, azonnali ügyeletet vállalni tisztességesen havi néhány ezer forintért. Aki ezt ígéri, az vagy nem méri fel, mit vállal, vagy nem gondolja komolyan. Mi ezt nem ígérjük.

Amit vállalunk, konkrét és ellenőrizhető: munkanapokon jellemzően egy, legkésőbb két munkanapon belül érdemi választ kapsz, öt percenként figyeljük, elérhető-e az oldalad, és minden hónapban kapsz egy állapotriportot arról, mi történt a háttérben. A hozzáférések átvételét és dokumentálását ugyanaz a nyolc pontos lista vezeti, amit fentebb ajánlottunk neked is, mert ugyanezt a fegyelmet várjuk el magunktól is: a domain és a tárhely a te neveden fut, nem a miénken, és ez írásban is rögzítve van.

Ez nem azért van így, mert szeretnénk különlegesnek tűnni. Azért, mert pontosan azt a helyzetet akarjuk elkerülni, amiről ez a cikk szól. A karbantartási szolgáltatásunk nem egy homályos „mindig itt vagyunk neked” ígéret, hanem egy dokumentált, előre rögzített folyamat, aminek pontosan meg lehet mondani a határait is.

Gyakori kérdések

Mi van, ha a fejlesztőm hetek óta nem válaszol, de közben elvileg még dolgozik valamin nekem?

Ha két-három hete nincs érdemi válasz, ésszerű úgy tervezni tovább, mintha az adott munka nem fejeződne be. Ha közben mégis jelentkezik, az jó hír, de addig ne várj tétlenül, főleg ha közben az oldalad karbantartás nélkül marad.

Csak karbantartást szeretnék, nem új oldalt. Ehhez is kell szerződés?

Igen, mindenképpen. Egy szóbeli megállapodás semmit nem ér akkor, ha vita van a válaszidőről vagy a hozzáférésekről. Egy rövid, világos szerződés, ami rögzíti, mit vállal a karbantartó és mit nem, mindkét felet védi.

Mennyi idő alatt tudtok átvenni egy oldalt egy eltűnt fejlesztőtől?

Ha a hozzáférések rendezettek (a te neveden futnak), egy alapos technikai felmérés jellemzően néhány óra, és utána azonnal el tudjuk kezdeni a karbantartást. Ha a hozzáférések rendezetlenek, ennek rendezése az első lépés, ehhez tudunk segítséget adni.

Mi van, ha azt sem tudom biztosan, kinél vannak a hozzáférések?

Ez gyakoribb, mint gondolnád, és nem szégyellnivaló. Írd le röviden, mit tudsz a helyzetről (milyen domain, milyen tárhelyszolgáltató, ha ismered), és átnézzük veled, milyen lépésekkel deríthető ki és szerezhető vissza a hozzáférés.

Következő lépés

Ha most maradtál fejlesztő nélkül, vagy csak biztos akarsz lenni benne, hogy legközelebb nem kerülsz ugyanebbe a helyzetbe, írd le röviden, mi a jelenlegi helyzeted, és 24-48 órán belül visszajelzünk, mi az első értelmes lépés.

A WordPress admin felületén szinte mindig ott villog egy szám: „3 frissítés érhető el.” A legtöbb tulajdonos ilyenkor az egyik két dolgot teszi. Vagy rákattint, gondolkodás nélkül, mert „úgyis csak frissítés.” Vagy évekig halogatja, mert fél, hogy elront valamit. Mindkettő ugyanabból a téves feltevésből indul ki: hogy a frissítés egy egyszerű, kockázatmentes gombnyomás. Nem az.

Ez a cikk nem arról szól, hogy ne frissíts. Épp ellenkezőleg: a frissítés az egyik legfontosabb, rendszeresen elvégzendő karbantartási feladat. Arról szól, hogy miért nem szabad megfontolás nélkül, egyesével átkattintani rajta, és mi az a néhány lépés, amivel a frissítésből nem hiba, hanem tényleg biztonság lesz.

Miért kockázatos a vak „Frissítés” gomb

Egy WordPress oldal ritkán áll egyetlen darabból. Van maga a WordPress mag, van egy téma (gyakran egy gyermektéma egyedi módosításokkal), és van általában tíz-húsz plugin, amelyek mindegyike a saját ütemében, saját fejlesztőtől kap frissítést. Ezek a darabok folyamatosan egymásra épülnek: egy plugin gyakran a téma egy funkciójára támaszkodik, egy másik plugin egy harmadik plugin adatszerkezetére. Amikor az egyik elem frissül, a többi nem biztos, hogy vele tart.

Ebből három tipikus probléma adódik:

• Kompatibilitási törés. Egy plugin új verziója megváltoztat egy belső működést, amire a témád vagy egy másik plugin számít. Az oldal ilyenkor nem feltétlenül összeomlik, gyakran csak egy funkció áll le csendben (például az űrlap nem küld emailt, vagy egy termékoldal elem eltűnik), és ezt hetekig senki nem veszi észre.
• Hiba egy addig stabil oldalon. A frissítés önmagában is tartalmazhat hibát, még a fejlesztő oldalán is, még akkor is, ha az addig évek óta hibátlanul futott. Ez nem ritka eset, hanem a szoftverfejlesztés normális velejárója, és pont ezért nem szabad rá úgy gondolni, mintha garantáltan biztonságos lenne.
• Frissítés biztonsági mentés nélkül. Ha a frissítés mégis elromlik valamit, és nincs friss, ellenőrzött mentésed, a visszaállás nem néhány perces feladat, hanem órákig, akár napokig tartó vesződség, sok esetben fejlesztői segítséggel.

A frissítés maga a védelem, nem az ellenség

Fontos tisztázni: a fenti kockázatok nem azt jelentik, hogy jobb halogatni a frissítést. Épp fordítva. Ha korábban feltörték már a WordPress oldaladat, vagy csak utánaolvastál, mi okozza a legtöbb ilyen esetet, tudod: a legtöbb feltörés nem valami kifinomult támadás eredménye, hanem egy régóta ismert, javított biztonsági résen keresztül történik, egy plugin vagy téma elavult verziójában. A frissítés kihagyása nem óvatosság, hanem pontosan az a rés, amin keresztül a baj bejön.

A helyes kérdés tehát nem az, hogy frissíts-e. Hanem az, hogy hogyan frissíts úgy, hogy ne a frissítés okozza a következő problémát.

Hogyan kell helyesen csinálni

1. Mindig legyen friss, ellenőrzött mentés a frissítés előtt. Ez az egyetlen lépés, ami garantálja, hogy bármi történjen is, néhány perc alatt visszaállítható az előző, működő állapot. Ha nem vagy biztos benne, hogy a mentésed erre a célra tényleg alkalmas, ez a cikk pontosan azt nézi át, mit érdemes ma ellenőrizni rajta.

2. Nézd meg a changelog-ot, mielőtt kattintasz. Minden komolyabb plugin és téma közzéteszi, pontosan mi változott az új verzióban. Néhány sor elolvasása elég ahhoz, hogy lásd, egyszerű hibajavításról van-e szó, vagy egy nagyobb, a működést is érintő változtatásról, ami után érdemesebb alaposabban tesztelni.

3. Ha van staging (teszt) környezeted, ott próbáld ki először. A staging egy az élő oldal másolata, ahol nyugodtan lehet kísérletezni anélkül, hogy a látogatók bármit észrevennének. Ha a frissítés a staging-en gond nélkül lefut, sokkal nagyobb biztonsággal viheted fel az élő oldalra is. Ha nincs staging környezeted, ez önmagában is jelzés, hogy érdemes lenne beállítani egyet, különösen, ha az oldal aktívan hoz bevételt.

4. Nagyobb, összetettebb oldalon egyesével frissíts, ne egyszerre mindent. Ha tíz plugin frissítését egyszerre indítod el, és valami elromlik, szinte lehetetlen kideríteni, melyik volt a hibás. Egyesével haladva, minden lépés után egy gyors, néhány perces ellenőrzéssel (nyílik-e a főoldal, működik-e a kosár, jönnek-e be az űrlapok) sokkal gyorsabban beazonosítható, ha valami elakadt.

5. Frissítés után is nézz körül, ne csak előtte. Egy frissítés hatása nem mindig azonnal látszik. Érdemes néhány kulcsfontosságú oldalt (főoldal, egy termékoldal, egy űrlap) manuálisan is megnézni közvetlenül a frissítés után, nem csak arra hagyatkozni, hogy „nem dobott hibaüzenetet.”

Mit ellenőrizz frissítés előtt, fél óra alatt

• Van-e a mai napról friss, tesztelt mentés? Ha nem tudod biztosan, ez az első teendő, még a frissítés előtt.
• Elolvastad-e a changelog-ot? Ha nagyobb, működést érintő változás van benne, számíts rá, hogy alaposabb tesztelés kell utána.
• Van-e staging környezeted a teszteléshez? Ha nincs, és az oldal aktív bevételi forrás, ez megéri a beállítást.
• Egyesével haladsz-e, nem egyszerre mindent frissítesz-e? Különösen igaz ez, ha sok (tíz feletti) plugin fut az oldalon.
• Megnézted-e frissítés után is az oldal kulcsfunkcióit? Ne csak a hibaüzenet hiányára hagyatkozz.

Gyakori kérdések

Ha egyszerre sok frissítés vár, elég, ha mindet egyszerre végigkattintom?

Kis, egyszerű oldalon (kevés plugin, alacsony forgalom) ez általában belefér, kis kockázattal. Egy webshopnál vagy sok pluginos, összetettebb oldalnál viszont ez az egyik leggyakoribb módja annak, hogy egy frissítésből több órás hibakeresés legyen.

Mennyire biztonságos az automatikus frissítés bekapcsolása?

Kisebb, karbantartási (patch) verzióknál általában elfogadható kockázat, főleg biztonsági javításoknál, ahol a gyorsaság számít. Nagyobb verzióváltásnál (amikor a funkció is érdemben változik) jobb, ha ez nem történik automatikusan, felügyelet nélkül.

Mi van, ha egy frissítés után tényleg elromlik valami?

Ha van friss mentésed, ez általában néhány perces visszaállítás, nem katasztrófa. Pont ezért a mentés az első és legfontosabb lépés a fenti listában, nem egy opcionális extra.

Nekem nincs időm ezt minden hónapban végigcsinálni, mit tegyek?

Ez a leggyakoribb, teljesen valós helyzet, és pontosan ezért érdemes ezt egy folyamatos karbantartási feladat részévé tenni, amit valaki más figyel és végez el rendszeresen helyetted, nem egy alkalmi, amikor éppen ráérsz, teendő.

Következő lépés

Ha nem vagy biztos benne, hogy a plugin- és téma-frissítések jelenleg biztonságosan, mentéssel és ellenőrzéssel történnek az oldaladon, írd le röviden, milyen oldalról van szó, és átnézzük veled, mi a jelenlegi helyzet. Ha pedig azt szeretnéd, hogy ez ne rád háruló, havonta visszatérő feladat legyen, a karbantartási szolgáltatásunk gondoskodik arról, hogy a frissítések rendszeresen, biztonságosan és mentéssel a háttérben történjenek.

Van egy mondat, amit szinte minden webfejlesztő hallott már ügyféltől, pont akkor, amikor a legrosszabbkor jön elő: „de hát volt mentés”. Aztán kiderül, hogy a mentés három hónapos, vagy csak a fájlokat tartalmazza az adatbázis nélkül, vagy éppen ugyanazon a szerveren volt, amit feltörtek, és azzal együtt tűnt el. A mentés önmagában nem biztonság. A biztonságot az adja, hogy tudod, mennyi van belőle, hol van, és hogy tényleg vissza lehet-e állítani belőle bármit.

Ez a cikk nem arról szól, hogy „kell mentés”, mert ezt már mindenki tudja. Arról szól, hogy honnan tudod, hogy az, ami most a háttérben fut, valóban megvéd, vagy csak azt az érzést adja, hogy meg vagy védve.

Miért nem elég annyi, hogy „van mentés”

A legtöbb tárhelyszolgáltató kínál valamilyen automatikus mentést, és ez sok tulajdonosnak elég ahhoz, hogy ne gondoljon többet a témára. A gyakorlatban viszont ennek a mentésnek gyakran három gyenge pontja van egyszerre. Először: ugyanazon a szerveren tárolódik, mint maga az oldal, vagyis ha a szervert éri probléma (feltörés, hardverhiba, a szolgáltató saját üzemzavara), a mentés is ugyanazzal a kockázattal néz szembe. Másodszor: a megőrzési idő gyakran rövid, néhány nap vagy egy hét, és felülíródik, mielőtt bárki észrevenné, hogy valami elromlott. Harmadszor, és ez a legfontosabb: szinte soha senki nem próbálja ki előre, hogy a mentésből tényleg vissza lehet-e állítani egy működő oldalt.

A 3-2-1 szabály: ez a gyakorlati minimum, nem a luxus

Az informatikai biztonság egyik legrégebbi, legjobban bevált alapelve az úgynevezett 3-2-1 szabály, és egy WordPress oldalra lefordítva egyszerűen alkalmazható:

• 3 másolat az adatból: az élő oldal, plusz legalább két külön mentés.
• 2 különböző helyen tárolva: ne csak a tárhelyen belül, hanem legalább egy olyan helyen is, ami fizikailag/technikailag különálló (felhőtárhely, külső mentési szolgáltatás).
• 1 másolat teljesen külön helyen (offsite), ami akkor is elérhető, ha a tárhelyszolgáltatóval bármi történik.

Ez nem elméleti túlbiztosítás. Egy WordPress oldalnál ez a gyakorlatban azt jelenti, hogy nem elég, ha a tárhelyed „csinál valamit” a háttérben: kell egy külön, a tárhelytől független mentési megoldás is, ami a te kontrollod alatt van, és amihez akkor is hozzáférsz, ha a tárhelyfiókoddal bármi probléma adódik.

A leggyakoribb, drága hiba: soha nem próbálod ki a visszaállítást

A legtöbb mentési probléma nem azon a napon derül ki, amikor a mentés készül, hanem azon a napon, amikor szükség lenne rá. Ilyenkor jönnek elő a tipikus meglepetések: a mentés csak a fájlokat tartalmazza, az adatbázist nem (vagy fordítva), a mentési fájl sérült, vagy a visszaállításhoz olyan technikai tudás kell, amivel a helyszínen senki nem rendelkezik. Ha korábban feltörték az oldaladat, pontosan ez az a pillanat, amikor kiderül, hogy a mentésed valóban megbízható volt, vagy csak azt hitted róla. Egy mentést csak akkor lehet „jónak” nevezni, ha legalább egyszer, nyugodt körülmények között, valóban kipróbáltad belőle a visszaállítást, akár egy ideiglenes, nem élő környezetben.

Mit ellenőrizz ma, fél óra alatt

• Mikor készült az utolsó mentés? Ha nem tudod a választ percek alatt megmondani, az önmagában jelzés, hogy nincs kézben tartva a folyamat.
• Hol tárolódik? Ha kizárólag a tárhelyeden belül, ez nem valódi biztonsági mentés, csak egy másolat ugyanazon a helyen.
• Tartalmazza-e a teljes adatbázist és az összes fájlt is? A kettő külön-külön is elveszhet, és a legtöbb WordPress oldal mindkettő nélkül használhatatlan.
• Van-e automatikus, rendszeres ütemezés? Egy alkalmi, kézi mentés hónapokkal ezelőttről gyakorlatilag olyan, mintha nem lenne mentés.
• Próbáltál-e már egyszer tesztvisszaállítást? Ha a válasz nem, ez a leghasznosabb fél óra, amit ma erre a témára szánhatsz.

Ha most veszel át egy oldalt, ez már eleve szerepel a listádon

Ha éppen egy másik fejlesztőtől veszel át egy weboldalt, a mentés kérdése nem utólagos teendő, hanem az átvételi ellenőrzés egyik konkrét pontja: kérdezd meg, mikor készült az utolsó mentés, hol tárolják, és milyen gyakran fut automatikusan. Ha erre bizonytalan választ kapsz, az átvétel utáni első teendőd egy megbízható, tőled független mentési rendszer beállítása lesz, még mielőtt bármi máshoz hozzányúlnál.

Gyakori kérdések

Elég, ha a tárhelyszolgáltatóm csinál napi mentést?

Önmagában nem feltétlenül. Nézd meg, hol tárolja (ugyanazon a szerveren-e), meddig őrzi meg, és próbáltad-e már egyszer visszaállítani belőle. Ha ezekre nincs válaszod, ez csak részleges védelem.

Milyen gyakran kell mentés készüljön?

Attól függ, milyen gyakran változik az oldal tartalma. Egy webshopnál, ahol naponta érkeznek rendelések, napi mentés a minimum, különben tényleges üzleti adat (rendelés, ügyfél) veszhet el. Egy ritkán frissülő bemutatkozó oldalnál heti mentés is elegendő lehet.

Meddig kell megőrizni a régi mentéseket, nem elég csak a legutolsót tartani?

Nem elég. Ha egy hibát vagy feltörést csak napokkal, hetekkel később veszel észre, a „legutolsó” mentés már maga is a sérült állapotot tartalmazhatja. Érdemes több, visszamenőleges verziót megőrizni, nem csak egyet.

Nekem nincs időm és tudásom ezt magamnak kézben tartani, mit tegyek?

Ez a leggyakoribb, teljesen valós helyzet, és pontosan ezért érdemes ezt egy olyan karbantartási folyamat részévé tenni, amit valaki más rendszeresen figyel és ellenőriz helyetted, nem csak beállít egyszer, majd elfelejt.

Következő lépés

Ha nem vagy biztos benne, hogy a jelenlegi mentésed valóban megbízható, írd le röviden, milyen oldalról van szó, és átnézzük veled, mi van most beállítva, és mi hiányzik belőle. Ha pedig azt szeretnéd, hogy ez ne egyszeri ellenőrzés legyen, hanem folyamatosan valaki más figyeljen rá helyetted, a karbantartási szolgáltatásunk gondoskodik arról, hogy a mentésed ne csak létezzen, hanem tesztelt és megbízható is legyen.

Van egy visszatérő helyzet, amit a legtöbb webfejlesztő ismer: egy vállalkozó telefonál, hogy váltani szeretne, mert a korábbi fejlesztőjével elromlott a viszony, vagy egyszerűen eltűnt, nem válaszol. Aztán kiderül, hogy a domain nem is az ő nevén fut, a tárhelyhez nincs jelszava, és az egyetlen ember, aki mindenhez hozzáfér, pont az, akivel már nem akar dolgozni.

Ha most állsz ez előtt a helyzet előtt, akár mert váltasz fejlesztőt, akár mert egy meglévő vállalkozást vagy weboldalt veszel át, ez nem szokatlan vagy kínos helyzet. Ez egy nagyon gyakori, jól ismert probléma, aminek van egy egyszerű megoldása: egy konkrét ellenőrző lista, amit átvétel ELŐTT kell végigmenni, nem utána.

Miért nem formaság ez, hanem gyakorlati kockázat

Ha kihagyod ezt az ellenőrzést, és valami elromlik, könnyen olyan helyzetbe kerülhetsz, hogy a saját weboldaladhoz nem férsz hozzá. Nem azért, mert bárki rosszhiszeműen viselkedett, hanem mert soha senki nem tisztázta, ki a tulajdonosa a domainnek, a tárhelynek vagy a licenceknek. Ez akkor derül ki a legrosszabbkor, amikor sürgősen módosítani kellene valamit, és nincs kihez fordulni.

1. Ki fér hozzá mihez: gyűjtsd össze az összes hozzáférést egy helyre

Egy weboldal mögött jellemzően 5-6 különálló hozzáférés van, és ritkán van egyetlen ember fejében vagy egyetlen dokumentumban összegyűjtve mind:

• Domain-regisztrátor (ahol a domain nevet regisztrálták).
• Tárhely/hosting fiók (cPanel vagy hasonló felület).
• WordPress admin (adminisztrátori jogosultsággal, nem szerkesztői vagy közreműködői szinttel).
• FTP/SFTP vagy SSH hozzáférés a fájlokhoz.
• Adatbázis-hozzáférés (phpMyAdmin vagy hasonló).
• DNS-kezelés, ami néha külön szolgáltatónál van, mint maga a domain-regisztráció.

Ha bármelyik hiányzik, azt kérd el írásban, mielőtt bármit aláírsz vagy kifizetsz az átvételért.

2. Kire van regisztrálva a domain és a tárhely: ez tulajdonjogi kérdés, nem technikai

Ez a leggyakrabban elsikkadó pont. Sok esetben a korábbi fejlesztő a saját nevén vagy a saját fiókjában regisztrálta a domaint és a tárhelyet „kényelemből”, és soha nem került át a tényleges tulajdonoshoz. Ez nem feltétlenül rosszindulat, gyakran egyszerű mulasztás, de a gyakorlati következmény ugyanaz: ha a fejlesztő eltűnik, vagy megszakad a kapcsolat, a domain és a tárhely felett elveszik a kontroll.

Konkrétan nézd meg a domain WHOIS-adatait (vagy kérd el a regisztrátor felületén a tulajdonosi adatokat), és ellenőrizd, hogy a vállalkozás vagy a tényleges tulajdonos neve szerepel-e rajta, nem a fejlesztőé vagy egy régi, már nem elérhető cégé.

3. Prémium licencek: mi jár le, és ki fizeti

Sok WordPress oldal prémium sablonra és fizetős bővítményekre épül, amik éves licenc alapján kapnak biztonsági frissítést. Ha a licenc a korábbi fejlesztő fiókjához van kötve, az átvétel után előbb-utóbb lejár, és a bővítmény vagy sablon működik ugyan tovább, de frissítést már nem kap. Ez pontosan az a helyzet, ami a biztonsági résekhez vezet: egy el nem évülő, de frissítés nélkül maradt bővítmény idővel ismert, dokumentált sebezhetőséggel üzemel tovább.

Kérj listát minden fizetős bővítményről és sablonról, ellenőrizd a licenc lejárati dátumát, és gondoskodj róla, hogy a licencek a te fiókodra kerüljenek át, vagy legalább a fizetést te intézd tovább.

4. Biztonsági alapállapot: mennyire elhanyagolt az oldal a felszín alatt

Egy weboldal a legritkább esetben mutatja a felszínen, mennyire van karban tartva a háttérben. Nézd meg, mikor volt utoljára frissítve a WordPress mag, a sablon és a bővítmények, van-e olyan bővítmény, amit a fejlesztője évek óta nem frissített, és van-e egyáltalán biztonsági szűrő bővítmény telepítve. Ha az oldal hónapok vagy évek óta nem kapott figyelmet, ez önmagában komoly kockázati tényező, még akkor is, ha jelenleg minden működni látszik.

5. Sebesség: ne csak azt nézd, hogy „betölt-e”

Egy alapos átvételi ellenőrzés része egy gyors sebességteszt is (Google PageSpeed Insights vagy hasonló ingyenes eszköz). Ha az oldal lassú, érdemes tudni, mi okozhatja, mielőtt döntesz arról, hogy egyszerű karbantartással orvosolható-e a helyzet, vagy komolyabb technikai beavatkozás kell.

6. Mentés (backup): van-e egyáltalán, és hol van

Kérdezd meg konkrétan: mikor készült az utolsó mentés, hol tárolják (külső helyen, nem csak a tárhelyen belül), és milyen gyakran készül automatikusan. Ha a válasz bizonytalan vagy nincs válasz, ez azt jelenti, hogy az átvétel utáni első teendőd egy megbízható mentési rendszer beállítása lesz, még mielőtt bármi máshoz hozzányúlnál.

7. Dokumentáció és egyedi funkciók

Ha az oldalon van bármilyen egyedi fejlesztés (egyedi űrlap, integráció egy külső rendszerrel, egyedi funkció), kérdezd meg, van-e ehhez bármilyen írásos dokumentáció. A legtöbb esetben nincs, és ez nem meglepetés, de fontos tudni előre, hogy ilyenkor az új fejlesztőnek időt kell szánnia a kód átvizsgálására, mielőtt biztonságosan hozzá tudna nyúlni.

8. Analytics, Search Console és domain-alapú email-fiókok

Ne felejtsd el a láthatatlan, de értékes részeket sem: a Google Analytics és Search Console fiókot (ami éveken át gyűjtött adatot a keresési teljesítményről), valamint a domainhez tartozó email-fiókokat. Ha ezek a korábbi fejlesztő saját Google-fiókjához vagy tárhelyéhez vannak kötve, ugyanaz a kockázat áll fenn, mint a domainnél: elveszítheted a hozzáférést egy olyan adatvagyonhoz, amit nem lehet egyszerűen pótolni.

Mikor éri meg inkább újraépíteni, mint átvenni

Ha a fenti lista végigjárása után az derül ki, hogy szinte semmihez nincs hozzáférés, a kód dokumentálatlan, elavult, és a licencek is rendezetlenek, érdemes leülni és számot vetni: mennyibe kerülne egy teljesen új oldal a jelenlegi állapot feltérképezéséhez és rendbetételéhez képest. Nem minden esetben az újraépítés a jobb döntés, de érdemes tudatosan választani, nem csak azért ragaszkodni a régihez, mert „már megvan”.

Gyakori kérdések

Mi van, ha a korábbi fejlesztő egyáltalán nem válaszol?

Ha a domain és a tárhely a te (vagy a vállalkozásod) nevén van regisztrálva, a regisztrátornál és a tárhelyszolgáltatónál is kérhetsz jelszó-visszaállítást a tulajdonosi adatok igazolásával, fejlesztői közreműködés nélkül. Ha viszont a fejlesztő nevén futnak, ez sokkal nehezebb helyzet, és jó eséllyel jogi lépés vagy a szolgáltatóval való közvetlen egyeztetés szükséges.

Elég, ha csak a WordPress admin hozzáférést kérem el?

Nem. A WordPress admin önmagában nem ér semmit, ha nincs hozzáférésed a tárhelyhez vagy a domainhez, mert ezek nélkül nem tudsz fejlesztőt váltani, DNS-t módosítani vagy akár csak számlázási adatot frissíteni.

Mennyi idő egy alapos átvételi ellenőrzés?

Egy tapasztalt szemmel végzett technikai audit jellemzően néhány óra alatt végigmegy a fenti pontokon, és pontos, írásos állapotképet ad arról, mi rendben van és mi nem.

Mi van, ha kiderül, hogy a domain nem az én nevemen fut?

Ez rendezhető, de minél tovább vársz vele, annál nehezebb. A regisztrátor ügyfélszolgálatával kell egyeztetni a tulajdonos-átruházásról, ehhez általában szükség van a jelenlegi tulajdonos hozzájárulására is, ezért érdemes ezt minél korábban, még jó viszony mellett tisztázni.

Következő lépés

Ha most készülsz átvenni egy oldalt, vagy csak nem vagy biztos benne, mi mindent kellene ellenőrizni, írd le röviden a helyzetet, és átnézzük veled a fenti listát pontról pontra. Ha pedig azt szeretnéd, hogy ezután már ne kelljen újra átélned ezt a bizonytalanságot, a karbantartási szolgáltatásunk gondoskodik arról, hogy mindig egyértelmű legyen, kinél vannak a hozzáférések és ki felelős az oldaladért.

Van egy pillanat, amikor egy látogató eldönti, hogy megvár-e egy oldalt betöltődni, vagy egyszerűen visszalép, és a versenytársadnál köt ki. Ez a pillanat néhány másodperc, és a legtöbb weboldal-tulajdonos csak akkor kezd el foglalkozni vele, amikor már túl sok érdeklődőt veszített el, hogy pontosan tudja, mennyit.

Ha az oldalad lassú, ez nem azt jelenti, hogy rosszul csináltál valamit a kezdetekkor. Egy weboldal a legritkább esetben lassul le hirtelen, egyetlen okból. Sokkal jellemzőbb, hogy apró tényezők rakódnak egymásra hónapok alatt, amíg egy nap felnézel, és azt látod, hogy az oldal, ami régen villámgyors volt, most araszol.

Miért számít ez pénzben, nem csak kényelemben

A Google és a SOASTA 2017-es, 900 ezer mobil hirdetési céloldalt vizsgáló kutatása szerint, ha egy oldal betöltési ideje 1 másodpercről 10 másodpercre nő, a látogató 123 százalékkal nagyobb eséllyel lép ki anélkül, hogy bármit csinálna az oldalon. Ugyanez a kutatás azt is megmutatta, hogy minél több elemet (szöveget, képet, widgetet) zsúfolsz egy oldalra, annál rosszabb a konverzió: 400-ról 6000 elemre nőve az oldalon a vásárlási/megkeresési hajlandóság 95 százalékkal esett vissza.

Ez azt jelenti, hogy egy lassú vagy túlzsúfolt oldal nem esztétikai probléma, hanem közvetlenül csökkenti, hány érdeklődőből lesz tényleges telefonhívás, foglalás vagy vásárlás.

A leggyakoribb okok, amik lassítják a WordPress oldaladat

Nincs egyetlen „gyorsító gomb”. A lassúság szinte mindig ezek közül egy vagy több kombinációja:

• Túlterhelt oldalépítő vagy sablon. A vizuális oldalépítők (Elementor, Divi és hasonlók) kényelmesek, de minden egyes elemhez extra kódot generálnak a háttérben, amit a böngészőnek fel kell dolgoznia. Ez a fajta bővítmény nem csak sebesség szempontjából érdemel figyelmet: nemrég írtunk egy kritikus, 9.0-s súlyosságú Elementor Pro biztonsági résről is, ami jól mutatja, hogy egy ilyen összetett bővítmény karbantartása két fronton is (biztonság és sebesség) folyamatos figyelmet igényel.
• Tömörítetlen, túl nagy képek. Egy telefonnal készült, több megabájtos fotó feltöltve, tömörítés nélkül, minden egyes betöltésnél megterheli az oldalt.
• Bővítmény-özön. Minden aktív bővítmény saját kódot fut le minden oldalbetöltésnél. Tíz-húsz bővítmény, amiből a felénél már nem is emlékszel, mire való, komoly, felesleges terhet jelent.
• Hiányzó vagy rosszul beállított gyorsítótár (cache). Gyorsítótár nélkül a WordPress minden egyes látogatónál újra összerakja az oldalt a nulláról, ahelyett hogy egy már elkészített, kész változatot szolgálna ki.
• Gyenge minőségű tárhely. Ha az oldalad zsúfolt, olcsó, osztott tárhelyen fut, a szomszédos oldalak forgalma is lelassíthat téged, függetlenül attól, mennyire optimalizált maga a WordPress-installáció.
• Felduzzadt adatbázis. Évek alatt felhalmozódott, soha nem törölt piszkozatok, spam-hozzászólások és elavult bővítmény-adatok lassítják az adatbázis-lekérdezéseket.

Mit tehetsz ma, ingyen, fél óra alatt

• Futtass egy gyorsteszt. A Google PageSpeed Insights vagy a GTmetrix ingyenesen megmutatja, konkrétan mi lassítja az oldaladat, nem csak azt, hogy lassú.
• Tömörítsd a képeidet. Ma már léteznek ingyenes, mesterséges intelligencia (AI) alapú képtömörítő eszközök, amik a minőség számottevő romlása nélkül akár 70-80 százalékkal is csökkentik a fájlméretet. Ez a fajta eszköz az elmúlt hónapokban jelentősen olcsóbbá vált, tehát ma már egy kisvállalkozás számára is elérhető, nem csak a nagy cégeknek.
• Nézd át a bővítménylistát. Amit fél éve nem használtál, azt töröld, ne csak kapcsold ki. A kikapcsolt, de a szerveren maradt kód más szempontból (biztonság) is kockázatot jelent.
• Kapcsolj be egy gyorsítótár-bővítményt. Egy alapszintű cache-bővítmény önmagában is érezhető javulást hoz, komolyabb technikai tudás nélkül is beállítható.

Ha a takarítás után is lassú marad, ez önmagában is figyelmeztető jel lehet

Van egy kevésbé ismert ok, amit érdemes kizárni, mielőtt bármi mást csinálsz: ha az oldalad korábban feltört állapotban volt, a rosszindulatú kód gyakran a háttérben fut tovább még azután is, hogy a látható tünetek eltűntek. Rejtett kriptovaluta-bányászó szkriptek vagy spam-küldő folyamatok folyamatosan terhelik a szervert, miközben az oldal felszínen normálisan néz ki. Ha egy oldal hirtelen, indokolatlanul lassult le, és nem találsz rá egyértelmű, ártalmatlan magyarázatot (új funkció, megnövekedett forgalom), érdemes ezt a lehetőséget is átnézni, nem csak a megszokott gyanúsítottakat.

A sebesség ma már keresőoptimalizálási kérdés is, nem csak felhasználói élmény

A Google évek óta beépíti a mobil oldalbetöltési sebességet (Core Web Vitals) a rangsorolási tényezői közé, és ez a hangsúly csak erősödik. A 2026 augusztusi globális spam-frissítés is abba az irányba mutatott, hogy a Google egyre inkább a tényleges felhasználói élményt (ideértve a betöltési sebességet is) helyezi a középpontba, nem csak a kulcsszavakat és a tartalmat. Vagyis egy lassú oldal ma már nemcsak a látogatót veszíti el a helyszínen, hanem hosszabb távon a keresési láthatóságot is ronthatja.

Gyakori kérdések

Elég, ha csak egy cache-bővítményt telepítek, és kész vagyok?

Sokat javít, de nem old meg mindent. Ha a lassúság okai között gyenge tárhely, felduzzadt adatbázis vagy tömörítetlen képek is szerepelnek, a gyorsítótár csak elfedi a problémát, nem szünteti meg.

Miért lassú az oldalam, ha egyébként minden bővítményem naprakész?

A frissesség és a sebesség két külön kérdés. Egy naprakész, de eleve nehézkes bővítmény vagy egy túlterhelt oldalépítő ugyanúgy lassíthat, mint egy elavult verzió. A frissítés a biztonságot védi elsősorban, nem garantálja a sebességet.

Megéri lecserélni a tárhelyet, vagy elég egy jobb gyorsítótár-beállítás?

Ez attól függ, mekkora a lemaradás. Ha a szerver-válaszidő (nem az oldal teljes betöltése, hanem az, amíg a szerver egyáltalán reagál) önmagában lassú, azt semmilyen bővítmény nem tudja kompenzálni, ott a tárhely a szűk keresztmetszet.

Honnan tudom, hogy nálam melyik ok a fő probléma?

Egy alapos technikai audit pontosan megmutatja, melyik tényező okozza a legtöbb kiesést a te konkrét oldaladon, ahelyett hogy találgatnál, és feleslegesen a rossz dolgot próbálnád javítani.

Következő lépés

Ha nem tudod biztosan, mi lassítja az oldaladat, vagy egyszerűen nincs időd sorra venni a fenti listát, írd le röviden, milyen oldalról van szó, és megnézzük, mi a valós szűk keresztmetszet. Ha pedig azt szeretnéd, hogy ez ne csak egyszeri tisztogatás legyen, hanem valaki rendszeresen figyelje is, a karbantartási szolgáltatásunk pont erre való.

Ha idáig jutottál, valószínűleg most szembesültél vele először: idegen tartalom jelent meg az oldaladon, egy fura átirányítás dobott ki egy másik weboldalra, a Google figyelmeztetést tett az oldalad elé a keresőben, vagy a tárhelyszolgáltatód e-mailje arról szól, hogy felfüggesztették a fiókodat tömeges kéretlen levelezés miatt.

Az első pár perc a legfontosabb, és pontosan az első pár percben szoktuk hozni a legrosszabb döntéseket: pánikban törölni valamit, amire később szükség lenne, vagy éppen ellenkezőleg, halogatni, mert nem tudjuk, hol kezdjük. Minden elveszett óra több elszálló érdeklődőt és több bizalomvesztést jelent, ha az oldaladon keresztül jön a bevételed egy része. Ez a cikk nem általános ijesztgetés, hanem egy konkrét, végrehajtható sorrend, aminek a célja, hogy a kiesés és a károk a lehető legkisebbre csökkenjenek. Kövesd lépésről lépésre, akkor is, ha még soha nem nyúltál a WordPress admin felületnél mélyebbre.

1. Karantén: vedd offline vagy tedd karbantartás módba az oldalt

Az első feladat nem a javítás, hanem a további kár megállítása. Amíg az oldal nyilvánosan elérhető, a rosszindulatú kód tovább terjedhet, spam-tartalmat küldhet a látogatóknak, vagy tovább rontja a keresőben elfoglalt helyed.

Ehhez nem kell törölni semmit. Elég, ha egy karbantartás-mód bővítménnyel vagy egy jelszóval védett .htaccess beállítással ideiglenesen elrejted az oldalt a nyilvánosság elől, vagy megkéred a tárhelyszolgáltatót, hogy függessze fel átmenetileg a nyilvános elérést. A cél az, hogy senki ne lásson idegen tartalmat, miközben te dolgozol a háttérben.

Amit ne tegyél meg ezen a ponton: ne törölj ki fájlokat vagy adatbázis-táblákat találomra. Amíg nem tudod, mi történt pontosan, minden gyanús elem bizonyíték, ami segít kideríteni, hogyan jutottak be.

2. Cserélj minden jelszót, nem csak a WordPress admin fiókodét

Ez az a lépés, amit a legtöbben félig csinálnak meg, aztán csodálkoznak, hogy két nap múlva megint ott a baj. Ha valaki bejutott az oldaladra, minden olyan jelszót cserélni kell, amivel elvileg hozzáférhetett:

• WordPress admin fiókok: az összes, nem csak a sajátod. A támadók gyakran létrehoznak egy rejtett, saját maguknak szánt admin felhasználót, ami első pillantásra nem tűnik fel. Nézd át a Felhasználók listáját, és minden ismeretlen adminisztrátori jogú fiókot törölj.
• Adatbázis jelszó (a wp-config.php fájlban).
• FTP/SFTP és tárhely (cPanel) hozzáférés.
• Minden API-kulcs vagy alkalmazásjelszó, ami fizetési szolgáltatáshoz, e-mail-küldéshez vagy más külső integrációhoz kapcsolódik.

Ha van rá esély, hogy a saját géped is fertőzött (például egy gyanús letöltés vagy villámgyors, ismeretlen bejelentkezés után gyanakszol erre), a jelszavakat egy másik, tisztán tudott eszközről cseréld. Ha a géped kulcsnaplózóval (keyloggerrel) fertőzött, az új jelszó ugyanolyan gyorsan kiszivárog, mint a régi.

3. Értesítsd azonnal a tárhelyszolgáltatót

Ez nem formalitás. Ha osztott (shared) tárhelyen vagy, a fertőzés átterjedhet a szomszédos fiókokra is, ezért a szolgáltatónak is érdeke, hogy gyorsan reagáljon. Sok hazai és nemzetközi tárhelyszolgáltató kínál ingyenes alap malware-ellenőrzést, vagy legalább hozzáférést biztosít a szerver naplóihoz.

Kérd el konkrétan az access.log és error.log fájlokat, illetve ha van, a fájlmódosítási előzményeket. Ezekből jó eséllyel kiderül, mikor és melyik fájlon keresztül történt a behatolás, ami a 6. lépésnél kulcsfontosságú lesz.

4. Malware-szűrés és a rosszindulatú kód eltávolítása

Ezen a ponton egy biztonsági bővítmény (Wordfence, Sucuri, vagy hasonló) teljes körű vizsgálata a leggyorsabb út. Ha nincs ilyen telepítve, most van itt az ideje. Amit érdemes külön is átnézni:

• A wp-content/uploads mappában NEM szabadna .php fájloknak lenniük: ez a mappa képek és dokumentumok tárolására való, ha mégis van benne futtatható kód, az szinte biztosan rosszindulatú.
• Ismeretlen, nemrég módosított fájlok a téma vagy a bővítmények mappáiban, különösen ha a módosítási dátum nem egyezik egyetlen legutóbbi frissítéssel sem.
• Gyanús, ismeretlen ütemezett feladatok (wp_cron bejegyzések), amik rendszeresen lefutnak a háttérben.
• Ha van hozzáférésed a szerverhez parancssoron keresztül, a wp-cli core verify-checksums paranccsal összevetheted a WordPress alapfájljait a hivatalos, tiszta verzióval.

Érdemes megjegyezni: a modern malware-szűrő eszközök egyre inkább mesterséges intelligencia alapú mintafelismerést használnak, ami gyorsabban ismeri fel az új, még nem katalogizált kártevőket is. Az, hogy ezek az AI-alapú eszközök az elmúlt hónapokban jelentősen olcsóbbá váltak (a nagy modellek ára helyenként 80 százalékkal csökkent 2026 nyarán), azt jelenti, hogy ez a fajta automatizált, folyamatos ellenőrzés ma már egy kisvállalkozás számára is reális, megfizethető opció, nem csak a nagy cégeknek elérhető luxus.

5. Mentés-visszaállítás, ha van tiszta mentésed

Ha van olyan mentésed, ami biztosan a fertőzés előttről származik, ez a leggyorsabb és legbiztonságosabb út a helyreállításhoz. A kulcsszó a biztosan: ha nem tudod pontosan, mikor jutottak be, könnyen visszaállíthatsz egy már fertőzött állapotot. Egy korábbi cikkünkben részletesen bemutattuk, mi történik egy WordPress oldallal, ha hónapokig senki nem frissíti. Ha a te mentésed is hasonlóan régi vagy bizonytalan eredetű, inkább az alapos malware-szűrésre (4. lépés) támaszkodj, ne a visszaállításra.

Fontos sorrend: ha visszaállítasz egy tiszta mentést, ne kapcsold vissza azonnal a nyilvánosság elé, mielőtt a 6. lépést (a biztonsági rés bezárása) el nem végezted. Ha ugyanaz a sebezhetőség van még az oldaladon, ami miatt először bejutottak, a frissen visszaállított, tiszta oldal is percek-órák alatt újra fertőződhet.

6. Zárd be a biztonsági rést, ami miatt bejutottak, különben napokon belül visszajönnek

Ez a leggyakrabban kihagyott lépés, és pontosan ezért térnek vissza a támadók ugyanarra az oldalra újra és újra. A rosszindulatú fájlok törlése önmagában nem old meg semmit, ha az ajtó, amin bejutottak, nyitva marad.

A leggyakoribb belépési pont egy elavult, sebezhető bővítmény. Jó példa erre a nemrég nyilvánosságra hozott, 9.0-s súlyossági besorolású Elementor Pro sebezhetőség (CVE-2026-32475): ha egy ilyen kritikus hiba érinti az oldaladat és nem frissítesz időben, az pontosan az a fajta rés, amin keresztül a jelen cikkben leírt helyzet kialakulhat.

Konkrét teendők:

• Frissíts mindent: WordPress mag, minden bővítmény, minden sablon a legfrissebb verzióra.
• Töröld ki (ne csak kapcsold ki) az összes olyan bővítményt és sablont, amit nem használsz. A kikapcsolt, de a szerveren maradt kód ugyanúgy sebezhető marad.
• Keress külön, második backdoor-t (rejtett, utólag beépített bejutási pontot). A támadók gyakran több, egymástól független bejutási pontot hagynak hátra, hogy egy talált és bezárt rés után is vissza tudjanak jutni.
• Cseréld le a wp-config.php fájlban található titkosítási kulcsokat (salt-okat) egy friss, a WordPress hivatalos generátora által adott készletre.

Mit jelent, ha közben a Google figyelmeztetést tett ki az oldalad elé?

Ha a Google Search Console „Biztonsági problémák” jelentésében figyelmeztetés jelent meg, ezt a tisztítás után külön kell jelezned a Google felé egy felülvizsgálati kérelemmel, amíg ezt nem teszed meg, a figyelmeztetés a tisztítás után is ott marad a keresési találatokban.

Ez azért is fontos, mert a Google egyre következetesebben szűri ki a feltört, spam-tartalmat kiszolgáló oldalakat a találatok közül. A 2026 augusztusi globális spam-frissítés is ebbe az irányba mutatott: a keresőmotor egyre agresszívabban bünteti azokat az oldalakat, amik akár csak ideiglenesen is rosszindulatú vagy manipulatív tartalmat szolgáltak ki, még akkor is, ha a tulajdonos nem tehet róla, hogy feltörték.

7. Mikor hívj szakembert azonnal, ne próbáld egyedül végigvinni

Van néhány helyzet, ahol a saját idődet és idegeidet kímélve érdemesebb rögtön szakemberhez fordulni:

• Ha webshopot üzemeltetsz, és fennáll az esélye, hogy bankkártya- vagy egyéb fizetési adat is érintett volt.
• Ha 1-2 óra alatt sem sikerül megtalálnod, hogyan jutottak be.
• Ha a tárhelyszolgáltató tömeges kéretlen levelezés vagy más visszaélés miatt felfüggesztette a fiókodat, és ez önmagában is technikai problémát okoz.
• Ha nincs tiszta mentésed, és az oldal helyreállítása üzletileg sürgető.

Egy feltört oldal szakszerű helyreállítása komoly, több órás szakértői munka. Érdemes ezt összevetni azzal, mibe kerülne egy teljesen új oldal felépítése: egy átlagos magyar weboldal ára 2026-ban 100 ezer és 1,5 millió forint között mozog a projekt méretétől függően. A legtöbb esetben a helyreállítás jóval olcsóbb, mint az újraépítés, de csak akkor, ha időben, a megfelelő sorrendben történik.

Gyakori kérdések

Elég, ha csak kitörlöm a rosszindulatú fájlokat, és nem csinálok mást? Nem. Ez olyan, mintha egy betört ablakot csak letakarnál, de nem cserélnéd ki. A fájlok törlése megszünteti a látható tünetet, de a biztonsági rés, amin bejutottak, ettől még nyitva marad, és napokon belül újra megtörténhet ugyanaz.

Ha van napi mentésem, akkor nyugodt lehetek? Sokkal jobb helyzetben vagy, mint mentés nélkül, de nem automatikus a megoldás. A visszaállított mentés is fertőzött lehet, ha a támadó már napokkal a felfedezés előtt bejutott, és a biztonsági rést a visszaállítás után is be kell zárni, különben a tiszta állapot sem marad az.

Mennyi ideig tart helyreállítani egy feltört oldalt? Ez erősen függ attól, mennyire elterjedt a fertőzés, és van-e megbízható, tiszta mentésed. Friss, ellenőrzött mentéssel és gyors reagálással ez néhány óra alatt megoldható. Mentés nélkül, kiterjedt fertőzésnél ez akár több napos munka is lehet.

Elég, ha csak a WordPress admin jelszavamat cserélem le? Nem, ez a leggyakoribb hiba. Ha csak az admin jelszót cseréled, de az adatbázis, az FTP-hozzáférés vagy egy rejtett második admin fiók a támadó kezében marad, percek alatt visszajuthat.

Nem drágább rendszeres karbantartást fizetni, mint amennyit egy ilyen helyzet valójában kockáztat? Ha most éled át ezt a helyzetet, valószínűleg az egyik ok az volt, hogy korábban nem volt egyértelmű, kinek kellett volna rendszeresen ránéznie a frissítésekre és a biztonsági résekre. Ez a fajta széttöredezettség, amikor egy weboldalt senki nem gondoz igazán, mert nincs egyetlen felelőse, az egyik leggyakoribb oka annak, hogy egyáltalán idáig jut a helyzet.

Következő lépés

Ha most szembesülsz egy feltört oldallal, ne várj tovább: írd le röviden, mi történt, és soron kívül visszajelzünk. Ha pedig a jelenlegi helyzeted rendeződött, és azt szeretnéd, hogy legközelebb ne te vedd észre elsőként a bajt, hanem legyen egy konkrét ember, akit hívhatsz, mielőtt idáig fajulna, a karbantartási szolgáltatásunk pontosan erre való.

Rövid válasz: 2026 nyarán két esemény történt gyors egymásutánban az AI-piacon. Július 31-én az OpenAI bejelentette, hogy modelljei átlépték az 1 milliárd aktív felhasználót. Ezt megelőzően, július 30-án, illetve utána, augusztus 21-én, sorban csökkentek a GPT-5.6 modellcsalád árai, egyes esetekben 80 százalékkal. A kisvállalkozónak ez konkrétan azt jelenti, hogy amit fél éve még túl drágának gondolt egy AI-alapú automatizálásra, ma jó eséllyel egy nagyságrenddel olcsóbb.

Mi történt pontosan, dátumokkal

Július 31. Az OpenAI pénzügyi igazgatója, Sarah Friar bejelentette, hogy a vállalat modelljei „több mint 1 milliárd aktív felhasználót és több mint 2 millió vállalkozást érnek el.” Ez a szám a ChatGPT mellett a Codex nevű, programozást segítő modellt és a külső alkalmazásokat összekötő ChatGPT Work platformot is magában foglalja. Összehasonlításképp: a Facebooknak hat évébe telt elérni ugyanezt a felhasználószámot 2004-es indulása után, az OpenAI-nak kevesebb mint négy évbe a ChatGPT 2022-es indulása óta.

Július 30. Az OpenAI 80 százalékkal csökkentette a GPT-5.6 Luna, és 20 százalékkal a GPT-5.6 Terra árát. A Luna 1 dollárról 0,20 dollárra esett millió bemeneti tokenenként, a kimeneti ár pedig 6 dollárról 1,20 dollárra. A Terra 2,50 dollárról 2 dollárra, illetve 15 dollárról 12 dollárra csökkent. A csúcsmodell, a Sol ekkor még a július 9-i bevezetéskori áron maradt (5 dollár bemenet, 30 dollár kimenet millió tokenenként).

Augusztus 21-23. A Sol modell is kapott egy árcsökkentést, de ez fontos részletekben más, mint az előző kettő: ez egy időben korlátozott, legalább november 21-ig garantált promóciós ár, nem végleges listaár-módosítás. A bemeneti ár 20, a kimeneti ár körülbelül 33 százalékkal csökkent a promóció alatt.

Miért csökkennek ilyen gyorsan az árak

Három ok fonódik itt össze. Az OpenAI saját közlése szerint hatékonyságjavítást ért el a GPU-kihasználásban és a válaszgenerálás módjában, ami több mint 15 százalékkal növelte a token-generálási hatékonyságot, tehát ténylegesen olcsóbbá vált ugyanazt a munkát elvégezni. Emellett élesedik a verseny: az egyre kifinomultabb, de egyben egyre drágább AI-ügynökök felé mozduló piacon a vállalatok kezdenek árérzékenyebbé válni, és egyre több cég vált olcsóbb, köztük kínai nyílt forráskódú modellekre. Végül maga az OpenAI is nyomás alatt van: 2025-ben 13,07 milliárd dolláros bevétel mellett 21 milliárd dolláros veszteséget termelt, tehát a felhasználószám-növekedés önmagában egyelőre nem jelent nyereségességet, a piaci pozíció megtartásához viszont kritikus.

Mit jelent ez a gyakorlatban egy magyar kisvállalkozásnak

A legfontosabb gyakorlati üzenet nem az, hogy „az AI most már ingyenes”, hanem hogy azok a feladatok, amelyeket fél éve még túl drágának vagy túl bonyolultnak gondoltál AI-val megoldani, ma jó eséllyel egy nagyságrenddel olcsóbban elvégezhetők. Egy olyan feladat, ami korábban egy drágább modellt igényelt, ma gyakran egy olcsóbb, kifejezetten erre optimalizált modellel is megoldható, méghozzá tört áron.

Ez elsősorban azoknak a vállalkozásoknak fontos, akiknek van egy jól körülhatárolható, ismétlődő, szabályalapú feladatuk: egy ajánlatkalkuláció, egy riport összeállítása, egy termékleírás-tömeg elkészítése, egy adatfeldolgozási lépés. Ezeknél a feladatoknál nem egy általános célú „okos asszisztensre” van szükség, hanem egy erre a konkrét problémára megépített, kis eszközre, ami a háttérben egy AI-modellt hív meg, olcsón és kiszámíthatóan.

Nézzünk egy egyszerű, saját számítású példát, kizárólag illusztrációként, a fent idézett hivatalos árak alapján. Egy webáruház, amely havonta 500 termékleírást generáltat egy Luna-szintű modellel, termékenként átlagosan 200 bemeneti és 300 kimeneti tokent használva, összesen 100 000 bemeneti és 150 000 kimeneti tokent fogyaszt havonta. A júliusi árváltozás előtt ez körülbelül 1 dollárba került (0,10 dollár bemenet, 0,90 dollár kimenet). Az árváltozás után ugyanez a munka körülbelül 0,20 dollárba kerül. A tényleges összeg a konkrét feladat pontos token-igényétől függ, és a fenti szám egy leegyszerűsített becslés, nem az OpenAI hivatalos állítása, de jól mutatja a nagyságrendet: egy korábban is olcsó feladat mostanra gyakorlatilag elhanyagolható költségűvé vált.

Egy fontos árnyalás: nem minden árcsökkentés végleges

Érdemes tisztán látni, hogy a három bejelentés nem egyforma súlyú. A Luna és a Terra árcsökkentése listaár-módosításnak tűnik, határidő nélkül. A Sol modell augusztusi árcsökkentése ezzel szemben kifejezetten időzített promóció, amit az OpenAI legalább november 21-ig garantál, de a rendszer közlése szerint nem közölte, mi lesz utána. Ha valaki egy hosszabb távú, Sol modellre épülő projektet tervez kizárólag az augusztusi ár alapján, érdemes ezzel az egy hónappal, két hónappal előre kalkulálni, nem a mostani árral a végtelenségig.

Hol van már most értelme egy AI-alapú egyedi eszköznek

Nem minden vállalkozásnak kell azonnal beruháznia egy AI-alapú eszközbe csak azért, mert olcsóbb lett. Az alábbi helyzetekben viszont most már gazdaságilag is megéri, ami korábban talán nem érte volna meg:

• Ismétlődő, sablonos szövegtömeg készítése. Termékleírás, ajánlati szöveg, riport-összefoglaló, ahol a feladat jól körülhatárolható, és korábban a modellhasználat költsége önmagában eltántoríthatott volna a rendszeres használattól.
• Egy konkrét, számolható folyamat automatizálása. Egy ajánlatkalkulátor, egy készletfigyelő, egy műszakbeosztó, ahol az AI csak egy komponens a teljes eszközben, nem a teljes megoldás.
• Kis mennyiségű, de rendszeresen ismétlődő adatfeldolgozás. Egy heti riport összeállítása, egy visszatérő elemzési lépés, ahol korábban a modellhívások költsége miatt inkább kézzel csinálta valaki.

Ez az a pont, ahol egy kis, konkrét problémára szabott alkalmazás jobban megéri, mint egy általános célú, drága rendszer. Pontosan ez az egyedi kisalkalmazások szolgáltatásunk logikája: nem nagyvállalati rendszert építünk, hanem egy adott problémára szabott, AI-asszisztált fejlesztéssel gyorsan elkészíthető eszközt, ami a hátterében kihasználja, hogy az AI-modellek használata ma lényegesen olcsóbb, mint fél éve volt.

Érdemes-e várni egy még olcsóbb árra

Ez jogos kérdés, és nincs rá egyértelmű válasz, de érdemes tudni, milyen tempóban mozog ez a piac. 2026-ban ez már a Sol modell második nagyobb árváltozása néhány hónapon belül, és a Luna, illetve a Terra árazása is a júliusi bevezetés óta lefelé módosult. Ha a mostani árak alapján egy adott eszköz megéri, valószínűleg nem éri meg évekig halogatni a döntést abban a reményben, hogy majd még olcsóbb lesz, mert időközben elmaradsz attól az előnytől, amit az eszköz már most is hozna. Fordítva viszont: ha a mostani árak mellett sem éri meg egy ötlet, érdemes inkább néhány hónapot várni és újraszámolni, mint erőltetni egy határeset gazdaságosságú projektet.

Gyakran ismételt kérdések

Ez azt jelenti, hogy most már mindenkinek AI-t kellene használnia a vállalkozásában?

Nem feltétlenül. Az árcsökkentés azt jelenti, hogy a korábban gazdaságilag nem éri meg kategóriájú ötletek egy része most már megéri. Ha nincs konkrét, ismétlődő feladatod, amit ez megoldana, nincs ok a kapkodásra.

Miért csökkentette az OpenAI pont most az árakat?

A hatékonyságjavítás mellett a versenyhelyzet és a saját, egyelőre veszteséges működése is szerepet játszik benne. A vállalat versenytársai, köztük olcsóbb, nyílt forráskódú modellek, nyomás alatt tartják az árazást.

A Sol modell ára is véglegesen ilyen alacsony marad?

Nem biztos. A Sol árcsökkentése egy legalább november 21-ig garantált promóció, nem bejelentett végleges listaár-módosítás. Hosszabb távú tervezésnél érdemes ezzel számolni.

Mennyibe kerül egy ilyen, AI-t használó egyedi eszköz elkészítése?

Ez a konkrét feladattól függ, egy egyszerű, egy funkciós eszköz jellemzően 49 000 és 99 000 forint között készül el, egy összetettebb, több felhasználós rendszer ennél magasabb áron. A pontos ár mindig a feladat tisztázása után, írásban rögzített ajánlatban derül ki.

Mi a különbség egy általános chatbot és egy ilyen egyedi eszköz között?

Egy általános chatbot sokféle kérdésre próbál válaszolni, ezért nehéz kiszámíthatóvá és megbízhatóvá tenni. Egy konkrét problémára épített eszköz egy jól meghatározott feladatot old meg, ezért egyszerűbb, olcsóbb, és sokkal kiszámíthatóbb a viselkedése.

Következő lépés

Ha van egy konkrét, ismétlődő feladatod, amit eddig túl drágának gondoltál AI-val megoldani, most érdemes újra megnézni. Írd le röviden a egyedi kisalkalmazások oldalon, mi a probléma és ki fogja használni, és megmondjuk, megéri-e most már megvalósítani.