A WordPress oldal nem egy legyártott, majd letett tárgy. Egy folyamatosan futó szoftverrendszer, ami magától is változik alatta: frissül a PHP a szerveren, kijön egy új WordPress-verzió, egy bővítmény fejlesztője abbahagyja a karbantartást, a Google módosít valamit a mérésben. Ha hónapokig senki nem néz rá, az oldal nem robban fel látványosan, hanem lassan romlik: eltűnik egy űrlap, elszáll egy kép, betöltődik három másodperccel lassabban, aztán egy nap már nem is jön be.
(Saját tapasztalat) A legtöbb hívás, ami "tegnap még jó volt" kezdettel érkezik, valójában hetekkel korábban indult el rossz irányba. A karbantartás lényege pontosan az, hogy ezt a hetekkel korábbi pontot elkapd.
Miért más a helyzet egy miskolci cégnél?
Rövid válasz: Miskolcon sok cégnél a weboldal nem az elsődleges üzletszerzési csatorna volt évekig, ezért az üzemeltetés is elmaradt mögötte, és most kell utolérni egy elhanyagolt rendszert.
Miskolc erős ipari múltra épült, és a gazdaság szerkezete azóta átalakult: a nehézipar mellé feljöttek a szolgáltatások, a mérnöki és fejlesztői munka, az egyetemi háttérből érkező vállalkozások. (Szakmai feltételezés) Ez a kettősség a digitális jelenlétben is látszik. Egy évtizedek óta működő gyártó vagy alkatrészes cég sokáig kapcsolatból és ajánlásból élt, a weboldal inkább névjegy volt, mint munkaeszköz. Egy fiatalabb szolgáltató cég viszont eleve az internetről szerzi az ügyfeleit, ezért ott az üzemeltetés természetes költség.
A gyakorlati következmény: ha miskolci ipari vagy B2B háttérből jössz, jó eséllyel egy olyan oldalt kell karbantartásba venni, amin évek óta nem történt rendszeres munka. Ilyenkor az első hónap nem karbantartás, hanem felzárkóztatás, és ezt érdemes külön kezelni.
Mit jelent pontosan a havi WordPress karbantartás?
Rövid válasz: öt terület tartozik ide: frissítés, mentés, biztonsági figyelés, hibakeresés és sebesség. Ha bármelyik hiányzik, az nem teljes üzemeltetés.
Nézzük végig, mit takar mindegyik a valóságban.
1. Frissítés
A WordPress mag, a sablon és a bővítmények frissítése. (Hivatalosan igazolt) A WordPress alapból automatikusan telepíti a kisebb biztonsági javításokat, de a nagyobb verzióváltásokat és a bővítményfrissítéseket nem feltétlenül. A hivatalos dokumentáció is jelzi, hogy a frissítés előtt mentés készítése az ajánlott gyakorlat.
A helyes sorrend:
- Teljes mentés (fájlok plusz adatbázis) a frissítés előtt.
- Először a WordPress mag, utána a sablon, végül a bővítmények, egyesével vagy kis csoportokban.
- Frissítés után átkattintás az oldalon: főoldal, egy szolgáltatásoldal, egy blogbejegyzés, kapcsolati űrlap, kereső, webshop esetén kosár és pénztár.
- Ha valami eltört, azonnali visszaállítás, nem másnapi.
(Saját tapasztalat) A legtöbb frissítési baleset nem a WordPress magtól jön, hanem attól, hogy egy oldalépítő bővítmény és egy kiegészítője külön ütemben frissül, és pár napig nem beszélnek egymással. Ezért éri meg a nagy oldalépítőket nem az első napon frissíteni.
2. Mentés
A mentésnél három kérdés dönt: milyen gyakran, hova, és vissza lehet-e állítani.
- Statikus bemutatkozó oldal: heti mentés általában elég.
- Rendszeresen frissülő blog vagy hírportál: napi.
- Webshop, ahol rendelés érkezik: napi vagy sűrűbb, mert egy elveszett nap valódi rendeléseket jelent.
A "hova" a fontosabb. Ha a mentés ugyanazon a tárhelyen fekszik, mint az oldal, akkor az nem mentés, hanem másolat. Szerverhiba, zsarolóvírus vagy fióklezárás esetén együtt tűnik el a kettő. Kérj külső tárolást: felhő, másik szerver, vagy legalább egy letölthető, nálad is meglévő példány.
És a harmadik, amit szinte soha nem kérnek számon: próbáltátok már visszaállítani? Egy sosem tesztelt mentés csak reménykedés. Évente legalább egyszer érdemes egy próbaverzióban visszaállítani, és megnézni, hogy tényleg működő oldal jön-e ki belőle.
3. Biztonsági figyelés
(Szakmai feltételezés, bár sok biztonsági jelentés ebbe az irányba mutat) A kis- és középvállalati WordPress-oldalak esetében a feltörések döntő része nem célzott támadás, hanem automatizált szkennelés: robotok végigpróbálják az ismert, javítatlan sebezhetőségeket és a gyenge jelszavakat. Vagyis nem azért törnek fel egy miskolci gépipari cég oldalát, mert érdekli őket a cég, hanem mert az oldal nyitva volt.
Amit a havi rutinban ellenőrizni kell:
- Van-e ismert sebezhetőségű bővítmény vagy sablon telepítve.
- Van-e olyan telepített bővítmény, amit a fejlesztő már nem támogat (ez a csendes időzített bomba).
- Kétlépcsős azonosítás vagy legalább belépési korlátozás az adminfelületen.
- Ismeretlen adminisztrátor-fiók megjelenése.
- Nem várt fájlmódosulás a
wp-content/uploadsmappában, ahol PHP-fájlnak semmi keresnivalója. - Érvényes SSL-tanúsítvány és működő HTTPS-átirányítás.
Egy egyszerű, mégis sokat érő beállítás a wp-config.php fájlban a szerkesztő kikapcsolása, hogy egy megszerzett admin-hozzáféréssel se lehessen a felületről kódot írni:
define('DISALLOW_FILE_EDIT', true);
Ez önmagában nem véd meg, de eggyel nehezebbé teszi a támadó dolgát.
4. Hibakeresés
A hibák nagy része nem az admin szeme előtt történik. A havi átnézésbe tartozzon bele:
- Törött belső és külső linkek keresése.
- 404-es hibák nézése a Google Search Console-ban: ha egy régi, jól teljesítő URL eltűnt, azt észre kell venni.
- Kapcsolati űrlap tesztküldése, és annak ellenőrzése, hogy az üzenet tényleg megérkezett a postafiókba, nem a spam mappába. (Saját tapasztalat) Ez az egyik leggyakoribb néma hiba: az oldal jónak látszik, csak hónapok óta nem jön ajánlatkérés, mert a levélküldés elakadt.
- PHP-hibanapló átfutása, mert a figyelmeztetések gyakran előre jelzik a következő nagyobb bajt.
- Mobilnézet valódi telefonon, nem csak kicsinyített böngészőablakban.
5. Sebesség
(Hivatalosan igazolt) A Google dokumentációja szerint az oldalélmény-mutatók, köztük a Core Web Vitals, a rangsorolási jelek között szerepelnek, ugyanakkor a Google maga is hangsúlyozza, hogy a tartalom relevanciája erősebb tényező. Vagyis a gyorsítás segítheti a láthatóságot, de önmagában nem garantál jobb helyezést.
A havi sebességellenőrzés minimuma:
- PageSpeed Insights mérés a főoldalra és egy fontos aloldalra, elsőként mobilon.
- A Search Console Core Web Vitals jelentésének átnézése, mert az valós felhasználói adatból dolgozik, nem laborból.
- Adatbázis-tisztítás: felesleges bejegyzésváltozatok, lejárt átmeneti adatok, spam hozzászólások.
- Nagy méretű, feltöltés óta nem optimalizált képek keresése.
- Gyorsítótár működésének ellenőrzése frissítés után, mert egy nagyobb változás után gyakran ki kell üríteni.
Mit kérj számon a szolgáltatón?
Rövid válasz: írásos havi jelentést, konkrét listával arról, mi frissült, mit ellenőriztek, mit találtak, és mit javasolnak. Ha ez nincs, nem tudod megkülönböztetni az elvégzett munkát a nem elvégzettől.
Ez a kritikus pont. A karbantartás jórészt láthatatlan munka: ha jól végzik, semmi nem történik. Épp ezért nagyon könnyű nem csinálni. A jelentés az egyetlen olcsó eszközöd arra, hogy ellenőrizd.
Kérdések, amiket nyugodtan feltehetsz:
- Milyen gyakran készül mentés, és hol tárolódik? Hány visszamenőleges példány van meg?
- Volt már éles vagy próba visszaállítás? Mennyi ideig tartott?
- A frissítéseket próbakörnyezetben nézitek át, vagy közvetlenül az éles oldalon?
- Ki fér hozzá az adminfelülethez, és hány adminisztrátor-fiók van most?
- Mi történik, ha hétvégén áll le az oldal? Van bejelentési út és vállalt reakcióidő?
- Kié a tárhely, a domain és a WordPress-hozzáférés? Ha holnap váltanál, mit viszel magaddal?
- Figyelitek-e külön eszközzel, hogy az oldal elérhető-e, vagy akkor derül ki, ha én szólok?
(Saját tapasztalat) Az utolsó előtti kérdés a legfontosabb, és a legritkábban elhangzó. Sok cég csak akkor szembesül vele, amikor a szolgáltatóval megromlik a viszony, és kiderül, hogy a domain valaki más nevén van. Kérd el írásban, hogy a domain, a tárhely és az oldal a te cégnevedre szól, és legyen nálad is egy hozzáférés.
Mi az, amit magad is meg tudsz nézni havonta?
Rövid válasz: tíz perc alatt, technikai tudás nélkül is ellenőrizheted a lényeget: bejön-e az oldal, működik-e az űrlap, él-e a tanúsítvány, és nem lassult-e be.
Rövid, laikus ellenőrzőlista:
- Nyisd meg az oldalt egy olyan böngészőben, amit nem szoktál használni (így nem a gyorsítótárad szépíti a képet).
- Nézd meg, hogy a címsorban ott van-e a lakat, és hogy a
http://változat átirányít-e a biztonságos verzióra. - Küldj magadnak egy tesztüzenetet a kapcsolati űrlapon, és várd meg, hogy megérkezik-e.
- Keress rá a Google-ben a
site:paranccsal a saját domainedre. Ha idegen nyelvű vagy értelmetlen oldalak jelennek meg, az fertőzésre utalhat. - Nyisd meg az oldalt mobilon, mobilneten, wifi nélkül. Ez a valódi ügyfélélmény.
- Kattints végig három-négy fontos aloldalt, és nézd meg, van-e törött kép vagy hiányzó szöveg.
Ez nem helyettesíti a szakmai üzemeltetést, de idejében jelez, ha valami félrement.
Mikor elég a saját karbantartás, és mikor kell szakember?
Rövid válasz: ha az oldal nem hoz közvetlen bevételt és kevés bővítmény fut rajta, a rendszeres saját ellenőrzés sokáig kitart. Ha ajánlatkérés vagy rendelés érkezik rajta, a leállás költsége hamar meghaladja az üzemeltetés terhét.
Néhány jel, ami után érdemes átadni a feladatot:
- Több mint húsz aktív bővítmény fut az oldalon.
- Webshop üzemel rajta, valódi fizetéssel.
- Volt már olyan frissítés, ami eltörte az oldalt, és nem tudtad, mit csinálj.
- Nem tudsz biztos választ adni arra, hol van a legutóbbi mentés.
- Egyedi fejlesztés vagy egyedi sablon van az oldalon, aminek a kódját nem te írtad.
(Szakmai feltételezés) Egy hosszú múltú, ipari háttérrel működő cégnél a mérnöki gondolkodás sokat segít itt: aki megszokta, hogy a gépnek karbantartási terve van, az általában gyorsan elfogadja, hogy a weboldalnak is kell egy. A nehézség inkább az, hogy a weboldal romlása nem hallatszik és nem füstöl, ezért nem sürget.
Hogyan kapcsolódik a karbantartás a láthatósághoz és az AI-válaszokhoz?
Rövid válasz: a rosszul karbantartott oldal nemcsak a keresőben szerepel gyengébben, hanem az AI-alapú válaszokban is nehezebben idézhető, mert a hibás, lassú vagy elérhetetlen oldalt a feldolgozó rendszerek is átugorhatják.
(Hivatalosan igazolt) A Google Search Central dokumentációja szerint a bejárás alapfeltétele, hogy az oldal elérhető legyen, és a szerver ne adjon vissza tartós hibát. Ha az oldal rendszeresen leáll vagy időtúllépéssel válaszol, a bejárás ritkulhat.
(Szakmai feltételezés) A generatív keresőknél és AI-asszisztenseknél ugyanez a logika jó eséllyel érvényes, sőt szigorúbban: ezek a rendszerek gyakran gyorsan, JavaScript-futtatás nélkül próbálják olvasni az oldalt. Egy elszállt sablon, egy hibás strukturált adat vagy egy nagyon lassú válasz miatt könnyen kimaradsz az idézett források közül. A jól karbantartott, gyors, hibamentes oldal nem garantál AI-említést, de eltávolítja az egyik gyakori technikai akadályt az útból.
Milyen ütemterv szerint érdemes dolgozni?
Rövid válasz: heti szinten mentés és elérhetőség, havi szinten frissítés és átvizsgálás, negyedévente mélyebb technikai és tartalmi átnézés.
- Hetente: mentés lefutásának ellenőrzése, elérhetőség figyelése, biztonsági riasztások átnézése.
- Havonta: mag, sablon és bővítmény frissítése mentés után, működéspróba, űrlapteszt, hibanapló, sebességmérés, adatbázis-tisztítás, írásos jelentés.
- Negyedévente: mentés-visszaállítás próbája, felesleges bővítmények kigyomlálása, PHP-verzió ellenőrzése, felhasználói fiókok átnézése, törött linkek nagy körben, Search Console lefedettségi jelentés.
- Évente: sablon és technológiai alap felülvizsgálata, hozzáférések és jogosultságok teljes átnézése, domain- és tanúsítványlejáratok.
Ha ebből csak egyetlen dolgot viszel el: a mentés és a visszaállítás tesztje a legfontosabb. Minden más hiba javítható, ha van hova visszanyúlni.
Források és további olvasnivalók
- Google Search Central: dokumentáció a bejárásról, indexelésről és az oldalélmény-mutatókról
- Google Search Console súgó: Core Web Vitals és lefedettségi jelentések
- WordPress.org: Hardening WordPress és Updating WordPress fejlesztői dokumentáció
- WordPress.org Support: Backing Up Your WordPress Site
- OWASP Top Ten: webalkalmazás-biztonsági kockázatok áttekintése
- Schema.org: strukturált adat szókincs
- W3C: webes szabványok és akadálymentességi irányelvek
- Nemzeti Kibervédelmi Intézet: általános tájékoztató anyagok kkv-k informatikai biztonságáról
- A frissítés önmagában nem karbantartás: mentés, visszaállítás-teszt és utólagos ellenőrzés nélkül kockázat.
- A mentés csak akkor mentés, ha külső tárhelyen van, és valaki már visszaállította legalább egyszer.
- A legtöbb WordPress-feltörés elavult bővítményen vagy gyenge belépési védelmen keresztül történik, nem célzott támadással.
- Kérj havi írásos jelentést arról, mi frissült, mi tört el, és mit ellenőriztek: ez a legolcsóbb minőségbiztosítás.
- A sebességet mérési adatra érdemes alapozni, nem érzésre, és a mobil eredményt nézd elsőként.
Gyakori kérdések
Milyen gyakran kell frissíteni a WordPress oldalt?
A biztonsági javításokat érdemes néhány napon belül telepíteni, a többi frissítést pedig egy tervezett havi körben átnézni. A fontos az, hogy legyen fix ütem: a szabálytalanul, hónapokat kihagyva végzett frissítés kockázatosabb, mert egyszerre sok verzióugrás jön össze, és nehezebb megtalálni, mi tört el.
Elég, ha a tárhelyszolgáltató csinál mentést?
Sok szolgáltató készít mentést, de ezek gyakran csak korlátozott ideig érhetők el, és ugyanazon az infrastruktúrán vannak, mint az oldal. Érdemes tisztázni, hány napra visszamenőleg van példány, mennyi idő alatt lehet visszaállítani, és van-e a saját kezedben is egy letöltött másolat. A biztos megoldás a szolgáltatói mentés plusz egy független, külső mentés.
Honnan tudom, hogy feltörték-e az oldalamat?
Tipikus jelek: idegen nyelvű vagy értelmetlen aloldalak jelennek meg a Google találatai között a site: keresésre, ismeretlen adminisztrátor-fiók született, átirányítás történik egy idegen oldalra, hirtelen lelassul az oldal, vagy a böngésző biztonsági figyelmeztetést ad. Ha bármelyiket látod, ne csak töröld a látható részt: mentésből érdemes visszaállni és utána befoltozni a belépési pontot.
Muszáj próbakörnyezetben tesztelni a frissítéseket?
Egyszerű bemutatkozó oldalnál, friss mentés mellett általában megoldható közvetlen frissítés is, ha utána azonnal átnézik az oldalt. Webshopnál, egyedi fejlesztésnél vagy sok bővítménynél viszont a próbakörnyezet komoly kockázatot vesz ki a folyamatból, mert ott az esetleges hiba nem az ügyfél előtt jelenik meg.
Mit tegyek, ha megszűnik egy bővítmény támogatása?
Ne hagyd az oldalon abban a reményben, hogy még működik. A nem támogatott bővítmény idővel biztonsági rés lesz, mert a felfedezett hibákat már senki nem javítja. Keress karbantartott alternatívát, vagy nézd meg, kiváltható-e a funkció a sablon vagy a WordPress saját eszközeivel, esetleg egy kis egyedi kóddal.
Javít a karbantartás a Google-helyezésemen?
Közvetlen helyezésjavulást nem garantál semmilyen karbantartás. Amit tesz: eltávolítja a technikai akadályokat, tehát az oldal elérhető, gyors és hibamentes marad, ami segítheti a bejárást és a felhasználói élményt. A helyezés ezen felül nagyban a tartalom relevanciáján és a piaci versenyen múlik.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.