WordPress weboldal monitorozása lépésről lépésre

Miért tűnik el sok WordPress oldal csendben

A WordPress kényelmes, viszont sok mozgó alkatrésze van: a PHP futtatókörnyezet, az adatbázis, a témák és a plugin-ek, a wp-cron, az SSL tanúsítvány, a cache réteg és sokszor még egy CDN is. Ha bármelyik megakad, a látogató fehér képernyőt, "Error establishing database connection" üzenetet, vagy egyszerűen lassan betöltődő oldalt lát. Te pedig csak akkor szerzel róla tudomást, amikor egy ügyfél ír, hogy nem éri el az oldalt.

Ebben a tutorialban végigmegyünk azon, hogy mit érdemes pontosan figyelni egy WordPress oldalon, és hogyan állítod be ezeket az uptimes.hu admin felületén. A végén lesz egy ajánlott monitor portfólió, amit néhány perc alatt összeraksz az ingyenes csomaggal is.

Mit érdemes monitorozni egy WordPress oldalon?

Egy átlagos WP oldal négy ponton bukik el a leggyakrabban:

1. A nyilvános frontend nem tölt be (PHP hiba, lejárt SSL, leállt szerver).
2. A wp-admin elérhetetlen, így a kollégád vagy te sem tudsz beavatkozni.
3. A REST API hiányzik (pl. egy security plugin véletlenül letiltotta a /wp-json/ végpontot), amitől a frontend-szerkesztő és sok integráció eldől.
4. Az adatbázis kapcsolat megszakad, ekkor a tipikus "Error establishing database connection" oldal jelenik meg, ami status code szempontjából gyakran 200-as marad.

Mindegyikre külön monitort érdemes csinálni, mert máshogy ellenőrződnek és máshogy kell rájuk reagálni.

1. Alap HTTPS elérhetőség beállítása

Ez az alap uptime check, ami percenként megpróbálja megnyitni az oldalad és nézi, hogy 200-as választ kap-e.

Lépések:

1. Lépj be az admin felületre, Monitors menü, + Új monitor gomb.
2. Az első lépésnél válaszd a HTTP(S) csempét (zöld lakat ikon).
3. A második lépésnél töltsd ki:

A 200, 301, 302 triplettre azért van szükség, mert egy friss telepítésnél gyakran a www és nem-www változatok közül az egyik átirányít a másikra. Ha csak a 200-at engednénk, és véletlenül a www nélküli verziót adod meg, akkor minden ellenőrzés DOWN-ot adna. A redirect target ettől függetlenül még jól betölthet.

A Response keyword mezőt itt érdemes feltölteni egy állandó szöveggel, ami biztosan ott van az oldalad HTML-jében:

<meta name="generator" content="WordPress

vagy ha eltávolítottad a generator metát biztonsági okokból:

<title>Az oldalad címe

Ez a keyword check megfogja azt az esetet, amikor a szerver 200-at ad vissza, de valójában egy "Error establishing database connection" vagy egy üres fehér oldal érkezik. Részletesebben erről a 4. pontban.

2. wp-admin és bejelentkezés figyelése

A /wp-admin/ egy másik kritikus végpont. Ha ez nem érhető el, akkor sem te, sem a kollégád nem tud belépni, plugin-t frissíteni, vagy gyorsjavítást tenni. A frontend ettől még működhet, ezért külön monitor kell.

Új monitor, ugyanúgy HTTP(S):

A Follow redirects itt kifejezetten kikapcsolva legyen. Ha be van kapcsolva, akkor az admin átirányít a /wp-login.php-ra, és onnan kapsz 200-at, de te a redirect tényét akarod ellenőrizni. Egy egészséges WP-nél kijelentkezve a /wp-admin/ szinte mindig 302-vel válaszol (átirányítás a login oldalra).

Ha az admin URL-edet biztonsági okokból átnevezted (pl. WPS Hide Login plugin), akkor a saját egyedi URL-edet add meg, és a választ ennek megfelelően állítsd be.

Login oldal külön monitor (opcionális, de ajánlott)

Ha brute force védelmet használsz (Wordfence, Limit Login Attempts), akkor érdemes egy külön monitort a wp-login.php oldalra is. Itt a 200-as választ várod, és keyword check-ként a loginform vagy user_login szöveget kereshetjük:

Expected status codes: 200
Response keyword: id="loginform"

Ha a security plugin véletlenül zárolja a login oldalt vagy hibásan kapcsolja be a captcha-t és tönkremegy a HTML, akkor ezt azonnal észreveszed.

3. WordPress REST API egészségellenőrzése

A /wp-json/wp/v2/ végpont egy JSON választ ad vissza a WP REST API-jának listájáról. A gyakorlatban két dolgot teszteltek vele:

• Maga az API él (vannak security plugin-ek, amik letiltják).
• A WP fel tud épülni egy normál request alatt (nem mindig nyilvánvaló a HTML frontendből).

Új monitor:

A "namespaces" kulcs minden élő WP REST API válaszban szerepel, mert ez listázza a regisztrált namespace-eket (wp/v2, oembed/1.0 stb.). Ha ez hiányzik, akkor vagy le van tiltva az API, vagy a válasz csonka, vagy egy biztonsági plugin egy 200-as hibalapot szolgál ki.

Starter csomagtól: konkrét JSON mező ellenőrzés

Ha Starter vagy fölötte csomagod van, akkor a kulcsszó keresés helyett pontosabb JSON field check-et tudsz használni. Készíts egy saját egészségellenőrző végpontot a témád functions.php-ban:

add_action('rest_api_init', function () {
    register_rest_route('uptimes/v1', '/health', [
        'methods' => 'GET',
        'permission_callback' => '__return_true',
        'callback' => function () {
            global $wpdb;
            $db_ok = (bool) $wpdb->get_var('SELECT 1');
            return [
                'status' => $db_ok ? 'ok' : 'error',
                'db'     => $db_ok ? 'up' : 'down',
                'time'   => current_time('c'),
            ];
        },
    ]);
});

Aztán a monitorban:

• URL: https://az-oldalad.hu/wp-json/uptimes/v1/health
• JSON field check 1: status = ok
• JSON field check 2: db = up

Így ha az adatbázis nem érhető el, akkor azonnal DOWN állapotot kapsz, anélkül hogy 500-asra kellene számítanod.

4. "Error establishing database connection" detektálása

Ez a WordPress klasszikus hibája: a PHP fut, az Apache vagy Nginx él, a szerver 200-at ad vissza, csak épp a WP nem tudott kapcsolódni a MySQL-hez. A látogató a böngészőben egy ronda hibaüzenetet lát, de minden uptime check csak a 200-as kódra figyel, és boldogan jelez UP-ot.

A megoldás a Response keyword mező. Két stratégia közül választhatsz:

1. Pozitív keyword (ajánlott): keress egy szöveget, ami csak akkor van a válaszban, ha a WP rendesen lefutott. Ez lehet a navigációs menü egy elem, az oldal címe, vagy a footer copyright sora:

Response keyword: © 2026 Cégnév

Ha bármelyik kritikus hiba megtörténik (DB down, white screen, plugin fatal error), ez a szöveg eltűnik a válaszból, és a monitor DOWN-ot jelez.

2. Több monitor lefedés: ha nem akarsz nyelvfüggő szöveget használni (pl. mert többnyelvű az oldalad), akkor inkább a 3. pontban bemutatott /wp-json/uptimes/v1/health saját végpontot használd. Ez nyelvtől független, és pontosan azt ellenőrzi, hogy a DB él-e.

Mire nem jó a keyword check

Ne állíts be keyword-ot olyan szövegre, ami csak bejelentkezett felhasználónak látszik (pl. admin bar), vagy ami csak főoldalon van, de a monitor egy aloldalra mutat. A keyword keresés a teljes válasz body-jában fut, kis-nagybetű érzékenyen.

5. SSL tanúsítvány automatikus figyelése

Erről jó hír: nem kell külön monitort beállítanod. Az uptimes.hu minden HTTPS monitor mellé automatikusan figyeli a tanúsítvány lejáratát, és a monitor detail oldalon kijelzi a hátralévő napokat.

Az értesítés alapból:

• 30 nappal a lejárat előtt
• 14 nappal a lejárat előtt
• 7 nappal a lejárat előtt
• 1 nappal a lejárat előtt

WP-nél a Let's Encrypt tanúsítvány 90 napos, így a 30 napos figyelmeztetés bőven időt ad a megújításra. Ha Cloudflare-en vagy más CDN-en keresztül szolgálod ki az SSL-t, akkor a tanúsítvány a CDN-nél él, ezért a lejárat figyelése a CDN cert-jét fogja nézni, nem az origin szerveredét.

6. Értesítések beállítása (Slack, Discord, email)

Mindegyik monitornál tudsz több értesítési csatornát választni. A legtöbb csapatnál a következő szétosztás működik a legjobban:

• Email (alap): a fiók email címedre megy, marad a "log" funkció.
• Slack vagy Discord: ide jönnek az aktív incidensek, hogy a csapat lássa.
• Webhook: ha van saját on-call rendszered (PagerDuty, Opsgenie, vagy Telegram bot), oda is push-olhatod.

Új csatorna létrehozásához a monitor szerkesztőben kattints a + Create new channel linkre. A mentés után visszadob az aktuális monitor szerkesztésére, és kiválaszthatod az újonnan létrehozott csatornát.

Egy gyakorlati tipp: ne küldd ugyanarra a csatornára a WP főoldal és a WP wp-admin riasztást. Ha a frontend megy és csak az admin esett ki, az nem ugyanaz a sürgősség. Csinálj két csatornát: #alerts-customer-facing és #alerts-internal.

WordPress monitorozás: gyakori hibák és megoldások

Cloudflare bot védelem és false-DOWN

Ha Cloudflare alatt van az oldalad és bekapcsoltad a "Bot Fight Mode" vagy "Under Attack Mode" módot, a Cloudflare 403-as vagy 503-as challenge oldalt szolgálhat ki a monitor kérésekre. Két megoldás van:

1. Vedd fel a 403-at az expected status codes-ba. Ha a Cloudflare challenge oldalt mindig kiszolgálja és a tényleges WP-d alatta jól megy, akkor a 403-as válasz tulajdonképpen "az oldal él" jelentésű.
2. Whitelist-eld az uptimes ellenőrző IP tartományokat a Cloudflare-ben. Ez a tisztább megoldás, mert a monitor a valódi WP választ fogja vizsgálni, nem a Cloudflare oldalát.

W3 Total Cache és stale cache

Ha agresszív page cache plugin-t használsz (W3 Total Cache, WP Rocket, LiteSpeed Cache), akkor a monitor mindig a cache-elt oldalt kapja meg. Ez egyrészt jó (gyors, alacsony szerverterhelés), másrészt veszélyes: ha a cache-ben benne ragad egy hibás oldal, a monitor azt fogja UP-nak jelezni órákon át.

Megoldás: állíts be egy query paramétert vagy egyedi cookie-t a monitor kérésére, ami megkerüli a cache-t. Például https://az-oldalad.hu/?nocache=monitor, és a cache plugin-ben add hozzá a nocache paramétert a "Never cache" listához.

Karbantartási mód (503)

A WP wp_maintenance üzemmódja 503-as választ ad. Ha tudatos karbantartás közben nem akarsz riasztást kapni, akkor kétféle taktika közül választhatsz:

• Kapcsold ki a monitort az Active mező off-ba állításával a karbantartás idejére.
• Vedd fel a 503-at az expected status codes-ba, de ez veszélyes, mert valódi szerver overload esetén sem fog jelezni.

A jobb választás az "Active off" karbantartás idejére, főleg ha rövid (5-30 perc).

Hosszú admin endpoint timeout

A WP admin oldalain (különösen a "Plugins" vagy "Updates" oldal) sokszor 10-15 másodperc is, mire betölt. Ha admin oldalra monitort raksz és a default 10 másodperc timeout-ot hagyod, akkor folyamatosan false-DOWN riasztásokat kapsz. Ilyenkor emeld 25-30 mp-re a timeout-ot, vagy inkább csak a /wp-admin/ redirect-et figyeld (ami azonnali válasz), ne a teljes admin dashboard betöltését.

Ajánlott monitor portfólió WordPress oldalhoz

Egy átlagos WP oldalra ennyi monitor elég ahhoz, hogy minden kritikus probléma 1-5 percen belül kiderüljön:

A 4. és 5. opcionális, de webshopnál mindkettő nagyon ajánlott. Az SSL lejáratot az 1. monitor mellé automatikusan figyeli a rendszer, külön nem kell beállítani.

Mennyi időbe telik mindezt beállítani?

Az első monitor 2-3 perc, a többi még 1-1 perc, ha már nyitva van a fülön. A /wp-json/uptimes/v1/health saját végpont 10 sor PHP a functions.php-ban, vagy egy mini MU-plugin-be is bedobható. Az értesítések (Slack, Discord) első alkalommal 5 perc, utána már minden új monitorhoz egy kattintás.

Egy fél óra alatt teljes WordPress monitor portfóliót össze tudsz rakni, ami:

• Frontend kiesést 1 percen belül észlel
• Adatbázis hibát 1 percen belül észlel (a keyword vagy JSON check miatt)
• wp-admin elérhetetlenséget 5 percen belül észlel
• SSL lejáratot 30 nappal előre jelez
• A megfelelő Slack csatornára küldi a riasztást

Próbáld ki ingyen

Az ingyenes csomaggal 5 monitort tudsz futtatni 5 perces intervallumon, ami pont elég egy WordPress oldal teljes lefedéséhez. SSL figyelés, email értesítés, 7 napos history az ingyenes csomagban is benne van.

Regisztrálj ingyen, és állítsd be az első WordPress monitort 5 perc alatt. Bankkártya nem kell, az ingyenes csomagra most rögtön léphetsz, és ha később több monitorra vagy gyorsabb intervallumra van szükséged, a Starter csomag az első incidenstől kezdve megéri.