Ha valaki azt keresi, milyen karbantartást igényel egy WordPress weboldal hosszú távon, jellemzően nem elméleti választ akar. Vagy már van egy oldala, ami évek óta megy, és nem tudja, mi történik vele a háttérben, vagy éppen most készül el az oldala, és tudni szeretné, mire számítson a következő öt évben. Ez a cikk erre a két helyzetre válaszol: mit kell csinálni, milyen gyakran, milyen sorrendben, és mi az, ami elmaradhat.
Mit jelent pontosan a WordPress karbantartás, és mi nem tartozik bele?
A WordPress karbantartás öt visszatérő feladatkör: frissítés, mentés, biztonság, sebesség (ezen belül az adatbázis rendben tartása) és tartalmi felülvizsgálat. Ezek nem egyszeri projektek, hanem ismétlődő ellenőrzések, amelyek célja, hogy az oldal működjön, elérhető legyen és ne romoljon a teljesítménye.
Fontos leszögezni azt is, mi nem karbantartás. Nem az új funkció fejlesztése, nem az arculatváltás, nem a webshop bővítése új fizetési móddal, és nem a folyamatos tartalomgyártás sem. Ezek külön munkák. A karbantartás azt jelenti, hogy ami ma működik, az fél év múlva is működjön, biztonságosan és elfogadható sebességgel. Ha ezt a kettőt összekevered, vagy túl sokat vársz a karbantartástól, vagy alábecsülöd, mennyi figyelmet kér egy weboldal.
Miért nem elég egyszer megcsinálni egy WordPress oldalt?
Azért, mert a WordPress nem egyetlen program, hanem sok, egymástól független szoftver együttműködése: a WordPress alaprendszer (core), a sablon (téma), és jellemzően 10-30 bővítmény. Ezeket különböző fejlesztők írják, különböző ütemben adnak ki frissítéseket, és nem tesztelik egymás kódját.
Hivatalosan igazolt: a WordPress projekt rendszeresen ad ki biztonsági és karbantartási kiadásokat, és a kisebb (minor) verziókra alapértelmezetten működik automatikus háttérfrissítés. Ez a WordPress hivatalos dokumentációjában is olvasható. Saját tapasztalat: a hosszú távon problémás oldalak többségénél nem a core az elavult, hanem egy-két bővítmény és a sablon, amit senki nem mert hozzáérni, mert félt, hogy elromlik valami.
Ehhez jön a környezet változása: a tárhelyszolgáltató időnként PHP-verziót frissít, a böngészők szigorítanak, a Google mérési szempontjai módosulnak. Az oldal tehát akkor is mozgó célpont, ha te egy sort sem írsz át rajta.
Milyen feladatok tartoznak a heti, havi és éves ritmusba?
A karbantartás akkor kezelhető, ha ritmusra bontod. A gyakori, gyors ellenőrzések megelőzik a ritka, drága katasztrófákat.
Hetente:
- Fut-e a mentés, és van-e friss mentési fájl (nem elég, hogy a bővítmény be van kapcsolva).
- Elérhető-e az oldal, betölt-e a kezdőlap és 2-3 fontos aloldal.
- Megérkeznek-e a kapcsolati űrlap levelei egy tesztkitöltéssel.
- Van-e biztonsági (security) jelzésű frissítés a bővítményeknél.
Havonta:
- Core, sablon és bővítmények frissítése, ellenőrzött sorrendben.
- Felhasználói fiókok átnézése: van-e olyan admin, akinek már nem kellene lennie.
- Spam kommentek és felesleges piszkozatok törlése.
- 404-es hibák megnézése a Search Console-ban és a szerver naplójában.
- Sebességmérés legalább a kezdőlapra és egy tipikus aloldalra.
Negyedévente vagy évente:
- Mentés visszaállításának próbája egy tesztkörnyezetben.
- Adatbázis-tisztítás (revíziók, lejárt átmeneti adatok, árván maradt sorok).
- PHP-verzió és tárhelycsomag felülvizsgálata.
- Nem használt sablonok és bővítmények eltávolítása.
- Domain, SSL és a szolgáltatói hozzáférések lejáratának ellenőrzése.
- Tartalmi audit: elavult adatok, régi cikkek, hibás belső linkek.
Hogyan frissíts úgy, hogy közben ne álljon le az oldal?
A frissítés kockázatát nem az csökkenti, ha ritkábban csinálod, hanem az, ha van visszaút. A biztonságos sorrend: mentés, staging, frissítés, ellenőrzés.
- Készíts teljes mentést (fájlok és adatbázis együtt), és győződj meg róla, hogy a fájl letölthető.
- Ha lehet, futtasd le a frissítést előbb egy másolat (staging) oldalon. A legtöbb tárhelyszolgáltató panelje tud ilyet készíteni.
- Frissítsd először a WordPress core-t, utána a sablont, végül a bővítményeket.
- A webshopot, a fizetést vagy az űrlapokat érintő bővítményeket egyesével frissítsd, és minden lépés után nézd meg az oldalt.
- Ellenőrizd a kritikus funkciókat: kezdőlap, egy termék- vagy szolgáltatásoldal, kapcsolati űrlap, kosár és pénztár, bejelentkezés.
- Ha valami elromlik, kapcsold ki a legutóbb frissített bővítményt, és nézd meg a hibanaplót.
Hibakereséshez hasznos, ha a naplózás a képernyő helyett fájlba megy, mert így a látogató nem lát hibaüzenetet. A wp-config.php fájlban ez így néz ki:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
A hibanapló ilyenkor a wp-content/debug.log fájlba kerül. Saját tapasztalat: a frissítés utáni öt perces kézi ellenőrzés több bajt előz meg, mint bármilyen automatizált figyelő, mert a legtöbb hiba nem hibaüzenet formájában jelentkezik, hanem úgy, hogy egy gomb nem csinál semmit.
Mennyit ér a mentés, ha még soha nem állítottad vissza?
Gyakorlatilag semmit. A mentés csak akkor mentés, ha külön helyen tárolod, ha tudod, meddig visszamenőleg van, és ha már legalább egyszer sikeresen visszaállítottad.
A jó gyakorlat egyszerű: legyen legalább két különböző helyen mentés, és az egyik ne ugyanazon a szerveren legyen, ahol az oldal fut. Ha a tárhely megsérül vagy a fiók zárolódik, az ott tárolt mentés is elérhetetlenné válik. Külső tárhely (felhőszolgáltatás vagy másik szerver) nélkül a mentés csak részleges védelem.
Nézd meg azt is, mit ment a rendszer. A fájlok és az adatbázis együtt kellenek: a fájlok tartalmazzák a képeket és a sablont, az adatbázis a szövegeket, a beállításokat és a megrendeléseket. Webshopnál a mentés gyakoriságát a rendelésszám határozza meg, mert egy napi mentésnél a visszaállítás akár egy napnyi rendelést is elvihet. Szakmai feltételezés: a kis- és középvállalati oldalak jelentős részénél a mentés létezik, de soha nem tesztelték, így a valós helyreállítási idő senki számára nem ismert.
Milyen biztonsági karbantartás kell egy WordPress oldalhoz?
A WordPress-oldalak elleni támadások túlnyomó része nem célzott, hanem automatikus: robotok keresik a régi, ismert hibás verziókat és a gyenge jelszavakat. Ezért a védekezés is nagyrészt rutinból áll.
- Erős, egyedi jelszavak minden adminisztrátori fiókhoz, és kétlépcsős azonosítás, ahol megoldható.
- A felhasználók rendszeres átnézése: volt fejlesztő, volt kolléga, régi ügynökségi hozzáférés törlése vagy jogosultság-csökkentése.
- A nem használt bővítmények és sablonok törlése. A kikapcsolt, de fent hagyott bővítmény kódja is a szerveren van.
- A bejelentkezési kísérletek korlátozása, hogy a próbálgatás ne mehessen végtelenségig.
- Az SSL-tanúsítvány lejáratának figyelése.
- A beépített fájlszerkesztő kikapcsolása, hogy egy megszerzett admin fiók ne tudjon azonnal kódot módosítani:
define('DISALLOW_FILE_EDIT', true);
Hivatalosan igazolt: a Google Search Console külön jelentésben jelzi, ha kártékony kódot vagy biztonsági problémát észlel az oldalon, és ilyenkor a keresési megjelenés is sérülhet. Érdemes ezért a Search Console értesítéseit olyan e-mail-címre kérni, amit valóban olvas valaki.
Hogyan marad gyors egy WordPress oldal évek múlva is?
A lassulás ritkán egyetlen okra vezethető vissza. Jellemzően három dolog hízik együtt: az adatbázis, a médiatár és a bővítmények száma.
Az adatbázisban évek alatt felhalmozódnak a bejegyzésváltozatok (revíziók), a lejárt átmeneti adatok, a spam kommentek és a törölt bővítmények maradék beállításai. Ezek közül a leggyakoribb, észrevétlen teljesítménygyilkos az automatikusan betöltődő beállítások mérete, mert ezt a WordPress minden oldalletöltésnél beolvassa. A méretét egy egyszerű lekérdezéssel megnézheted:
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';
WP-CLI-vel a lejárt átmeneti adatok takarítása is gyors: wp transient delete --expired. Adatbázis-műveletet viszont csak friss mentés után indíts.
A médiatárnál a tipikus hiba a fényképezőgépből vagy telefonról feltöltött, több megabájtos kép. Érdemes a képeket feltöltés előtt méretre vágni és modern formátumban (például WebP) tárolni. A gyorsítótárazás (cache) sokat segít, de nem javítja ki a rossz alapokat, csak elfedi őket.
Végül a PHP-verzió: a régi, már nem támogatott verziók lassabbak és biztonsági szempontból is kockázatosak. A váltás előtt viszont mindig kell teszt, mert a régi bővítmények elhasalhatnak rajta.
Mit kell karbantartani a tartalmon és a keresőoptimalizáláson?
A technikai karbantartás megőrzi az oldalt, a tartalmi karbantartás pedig azt, hogy érdemes legyen megtalálni. Ez a rész marad el a leggyakrabban.
- Elavult tények: nyitvatartás, elérhetőség, munkatársak, szolgáltatáslista, jogszabályi hivatkozások.
- Hibás linkek: a belső linkek elromlanak átnevezéskor, a külső linkek pedig egyszerűen megszűnnek.
- 404-es oldalak: ha egy régi, linkelt aloldal megszűnt, átirányítás kell rá, nem hibaoldal.
- Régi cikkek: a több éve írt, de még forgalmat hozó tartalmak frissítése jellemzően hatékonyabb, mint egy teljesen új cikk megírása.
- Indexelés: a Search Console jelentéseiben látszik, ha oldalak esnek ki az indexből vagy ha a webhelytérkép hibás.
- Strukturált adat: a Schema.org szerinti jelölés (szervezet, szolgáltatás, GYIK, cikk) érvényessége frissítések után is ellenőrizendő.
Szakmai feltételezés: a tartalmi frissítés hatása általában lassabban jelentkezik, mint a technikai hibák javításáé, és önmagában semmilyen helyezést nem garantál, de a folyamatos elavulás jó eséllyel rontja a láthatóságot.
Mit tegyél másképp az AI-keresők és a válaszmotorok miatt?
A karbantartás alapfeladatai nem változtak, két dolog viszont felértékelődött: az információ pontossága és a botforgalom kezelése.
Hivatalosan igazolt: az AI-szolgáltatók (például az OpenAI) dokumentálják a saját feltérképező robotjaikat, és a robots.txt fájlon keresztül lehet szabályozni, mihez férnek hozzá. Ez tudatos döntés kérdése: a kizárás csökkenti a szerverterhelést, de a hivatkozás esélyét is.
Saját tapasztalat: az AI-robotok forgalma egyes oldalaknál érzékelhetően megnövelte a szerverterhelést, ami gyenge tárhelyen lassulásként jelentkezik. Ezért a naplófájlok időnkénti átnézése ma a karbantartás része.
A tartalmi oldalon az számít, hogy az oldalad egyértelmű, ellentmondásmentes és dátumozott legyen. Ha ugyanaz az adat két aloldalon máshogy szerepel, azzal a felhasználót és a gépi értelmezést is összezavarod. Szakmai feltételezés: a következetes, karbantartott adatokkal rendelkező oldalak nagyobb eséllyel kerülnek be pontosan az AI-válaszokba, de erre garancia nincs, és a válaszok összetétele változékony.
Mi történik, ha évekig elmarad a karbantartás?
Az elmaradt karbantartás nem azonnal büntet, hanem összegyűlik. A tipikus végkifejlet négyféle.
Az első a törés: a tárhely frissíti a PHP-t, és a régi bővítmény miatt fehér képernyő fogadja a látogatót. A második a feltörés: egy ismert, régóta javított hiba miatt idegen kód kerül az oldalra, spam aloldalakkal vagy átirányításokkal, amit a Google is jelezhet. A harmadik a lassú romlás: nem áll le semmi, csak egyre lassabb az oldal, egyre több űrlap tűnik el, és senki nem tudja, mióta. A negyedik pedig szervezési: a hozzáférések elvesznek, a domain valakinek a régi címére van regisztrálva, és a helyreállítás nem technikai, hanem adminisztratív problémává válik.
Ezek közül a felfrissítés utólag mindig több munka, mint a folyamatos kis lépés, mert egyszerre több év változását kell áthidalni.
Milyen ellenőrzőlistával nézheted át magad az oldaladat?
Ha most szeretnéd felmérni, hol áll az oldalad, ez a lista fél óra alatt végigmegy:
- Van legalább két, egymástól független mentésed, és tudod, hol van?
- Visszaállítottál már mentésből az elmúlt egy évben?
- Hány frissítés vár a WordPress adminfelületén, és van köztük biztonsági?
- Hány admin jogosultságú felhasználó van, és mindegyiket ismered?
- Van olyan bővítmény, amit két éve nem frissített a fejlesztője?
- Milyen PHP-verzión fut az oldal, és az még támogatott?
- Megérkezik az űrlap levele, ha most kitöltöd?
- Betölt-e a kezdőlap mobilon néhány másodpercen belül?
- Mutat-e hibát a Search Console indexelési vagy biztonsági jelentése?
- Van olyan adat az oldalon (nyitvatartás, elérhetőség, szolgáltatás), ami már nem igaz?
Ha a listából három vagy több ponton bizonytalan a válasz, az oldal karbantartása nem folyamat, hanem szerencse kérdése. Ez javítható, de tudatos döntést kér arról, ki és milyen ritmusban nézi át.
Források és további olvasnivalók
- WordPress.org hivatalos dokumentáció (WordPress Documentation, Developer Resources)
- WordPress Release és Security kiadási bejegyzések
- Google Search Central dokumentáció (indexelés, webhelytérkép, biztonsági problémák jelentése)
- Google Search Console súgó
- Schema.org strukturált adat szótár
- W3C webes szabványok és akadálymentességi irányelvek (WCAG)
- PHP.net támogatott verziók (Supported Versions) oldal
- OpenAI hivatalos dokumentáció a feltérképező robotokról
- WP-CLI hivatalos parancsdokumentáció
- A WordPress nem kész termék, hanem folyamatosan frissülő rendszer: a core, a sablon és a bővítmények külön ütemben változnak.
- A mentés csak akkor mentés, ha külső helyen van, és ha már legalább egyszer sikeresen visszaállítottad.
- A frissítés kockázatát nem a gyakoriság csökkenti, hanem a sorrend, a staging és a frissítés utáni ellenőrzés.
- Az adatbázis és a képek hízása évek alatt észrevétlenül lassítja az oldalt, ezért ezekre külön ritmus kell.
- A tartalmi karbantartás (elavult adatok, 404-ek, belső linkek) ma legalább annyira számít, mint a technikai.
Gyakori kérdések
Milyen gyakran kell frissíteni egy WordPress oldalt?
A biztonsági frissítéseket érdemes néhány napon belül feltenni, az általános frissítéseket pedig havi rendszerességgel, ellenőrzött sorrendben. A ritkább frissítés nem csökkenti a kockázatot, csak elhalasztja és megnöveli, mert egyszerre több verziónyi változást kell áthidalni.
Elég, ha a tárhelyszolgáltató ment helyettem?
Önmagában nem. A szolgáltatói mentés hasznos alapvédelem, de általában korlátozott ideig áll rendelkezésre, és ugyanabban a rendszerben van, ahol az oldal fut. Érdemes legalább egy független, külső helyen tárolt mentés is, és legalább egyszer ki kell próbálni a visszaállítást.
Mi történik, ha egy frissítés után elromlik az oldal?
Ilyenkor a legutóbb frissített bővítmény kikapcsolása a első lépés, majd a hibanapló átnézése. Ha a hiba miatt az adminfelület sem elérhető, a bővítmény mappájának átnevezésével FTP-n vagy fájlkezelőn keresztül is ki lehet kapcsolni. Ha ez sem segít, a friss mentésből való visszaállítás a biztos út.
Muszáj karbantartani egy egyszerű bemutatkozó oldalt is?
Igen, csak kevesebb munkával. Egy statikus tartalmú bemutatkozó oldalnál is frissül a WordPress, a sablon és a bővítmények, lejár az SSL-tanúsítvány és a domain, és elavulhatnak az adatok. A ritmus lehet lazább, de a mentés, a frissítés és az évenkénti tartalmi átnézés ott sem hagyható ki.
Hány bővítmény a sok egy WordPress oldalon?
Nem a szám a döntő, hanem a minőség és a karbantartottság. Egy elhanyagolt, két éve nem frissített bővítmény nagyobb kockázat, mint tíz aktívan fejlesztett. Érdemes évente átnézni, melyikre van valóban szükség, és a feleslegeseket nem csak kikapcsolni, hanem törölni is.
Számít a karbantartás a Google-találatok szempontjából?
Közvetlenül nem helyezési tényező a karbantartás mint tevékenység, de a következményei igen: a lassulás, a hibás oldalak, a nem elérhető tartalom és a biztonsági problémák mind ronthatják a láthatóságot. A karbantartás tehát nem javít fel egy gyenge oldalt, de megelőzheti egy jól működő oldal romlását.
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.