Fehér képernyő a WordPress oldalon (WSOD) – 8 ok, 8 megoldás

Frissítve: 2026. október · Írta: Busai Gábor, 15+ év WordPress-tapasztalat

A fehér képernyő a WordPress legidegesítőbb hibája, mert nem mond semmit. Nincs hibaüzenet, nincs kód, nincs nyom – csak egy üres lap. Pedig pont ez az üresség az első használható információ: elárulja, hogy a PHP már a kimenet legelején elhasalt.

Ebben az útmutatóban végigvesszük, hogyan szűkítsd le két perc alatt a hibát, és mi a nyolc leggyakoribb ok a memóriakorláttól a félbemaradt frissítésig.

Fehér képernyő vagy „kritikus hiba”? Nem ugyanaz

A WordPress 5.2 óta van beépített hibakezelő, ami végzetes hibánál kiírja a „Kritikus hiba történt a webhelyén” üzenetet. Ha ezt látod, szerencsés vagy: a WordPress még futott annyira, hogy megírja.

A teljesen üres lap ennél korábbi összeomlást jelent. Három tipikus esete van:

• A hiba még a hibakezelő betöltése előtt történt – például a wp-config.php-ban vagy egy must-use bővítményben.
• Maga a hibakezelő bukott el.
• Nem is PHP hiba: a HTML megjött, de egy CSS vagy JS gond miatt nem látszik semmi.

Ez a harmadik eset az, amit a legtöbben kihagynak – és pont ez a leggyorsabban javítható. Ezért kezdjük a szűkítéssel.

1. lépés: pontosan mi fehér?

Ez a kérdés egymaga felezi a lehetséges okokat.

Tipp: nyisd meg az oldalt privát ablakban vagy másik böngészőben is. Ha ott működik, akkor nem a szerverrel van baj, hanem a böngésződ gyorsítótárával vagy a bejelentkezett állapotoddal.

2. lépés: PHP hiba vagy megjelenítési gond?

Erre két gyors teszt van, mindkettő tíz másodperc.

Nézd meg az oldal forrását

Jobb klikk → Oldal forrásának megjelenítése (vagy Ctrl+U).

• Teljesen üres a forrás → PHP hiba. A szerver semmit nem küldött.
• Van forrás, de félbevágva – például a <head> közepén megszakad → PHP hiba, de már futás közben. Az utolsó sor sokszor elárulja, melyik bővítmény vagy sablonfájl járt éppen.
• Teljes a forrás, látszik a tartalom is → nem PHP hiba. A HTML megvan, csak nem jelenik meg: CSS vagy JS a hibás.

Nézd meg a státuszkódot

F12 → Network fül → töltsd újra az oldalt, és nézd meg a legfelső kérés státuszát:

• 200 és üres válasz → PHP végzetes hiba elrejtett hibaüzenettel. Ez a klasszikus WSOD.
• 500 → szerveroldali hiba; erről külön írtam a 500-as belső szerverhiba cikkben.
• 200 és teljes HTML → megjelenítési gond. A Console fülön keresd a piros hibákat.

3. lépés: kapcsold be a hibanaplót

Ha PHP hiba van, innentől nem kell találgatni. FTP-n vagy a tárhely fájlkezelőjén nyisd meg a wp-config.php-t, és a „stop editing” sor fölé illeszd be:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Töltsd újra az oldalt, majd nyisd meg a /wp-content/debug.log fájlt, és görgess a legaljára. A PHP Fatal error kezdetű sor végén ott a fájl és a sor száma – vagyis a bűnös. A naplóolvasás részleteit itt írtam le: Hol van a WordPress hibanapló, és hogyan olvasd?

Ha a napló is üres, kapcsold ki ideiglenesen magát a hibakezelőt – ilyenkor beszédesebb lesz:

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

A nyolc leggyakoribb ok és a javítása

1) Bővítményütközés

A leggyakoribb, és szinte mindig frissítés után jelentkezik.

Ha be tudsz lépni: kapcsold ki a naplóban megnevezett bővítményt.

Ha nem tudsz belépni: FTP-n nevezd át a /wp-content/plugins/ mappát plugins-KI-re. Ezzel az összes bővítmény kikapcsol. Ha az oldal életre kel, nevezd vissza, és egyesével kapcsold be őket az adminban, amíg a hiba vissza nem tér.

Nyolc bővítménynél ez három lépésben megvan, ha felezéssel csinálod: kapcsold be a felét, nézd meg, aztán a hibás felét felezd tovább.

2) Sablonhiba

Tipikus, ha egyedi kódot tettél a functions.php-be – főleg internetről másolt snippetet –, vagy ha a sablon régi, és nem bírja az új PHP-verziót.

Javítás: nevezd át FTP-n az aktív sablon mappáját. A WordPress ilyenkor automatikusan visszaáll egy alapértelmezett sablonra – ha van ilyen a szerveren. Ezért érdemes mindig ott hagyni egy Twenty-* sablont telepítve, akkor is, ha nem használod.

Ha tudod, hogy a functions.php-be írtál utoljára: nyisd meg, és vedd ki a legutóbb beszúrt blokkot.

3) Elfogyott a memória

A naplóban Allowed memory size of … exhausted szerepel. Gyakran nem ad hibaüzenetet, csak elhallgat – innen a fehér lap.

Javítás a wp-config.php-ban:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Ha ez nem hat, a szerver php.ini vagy .user.ini fájljában, illetve a tárhely PHP-beállításaiban kell emelni a memory_limit értéket.

Figyelem: ha az emelés után is elfogy, akkor nem a korlát a baj. Valami elszabadult – végtelen ciklus, rossz lekérdezés, memóriaszivárgás –, és az emelés csak késlelteti az összeomlást.

4) Sérült .htaccess

Ritkábban ad teljesen fehér lapot (inkább 500-as hibát), de előfordul. Nevezd át a gyökérben lévő .htaccess fájlt htaccess-old-ra, és töltsd újra az oldalt. Ha megjavult, lépj be, majd Beállítások → Közvetlen hivatkozások → Változtatások mentése: ez újragenerálja a fájlt.

5) Cache és CDN: a fehér oldal „beragad”

Ez a leggyakrabban kihagyott ok. Megjavítod a hibát, de a gyorsítótár vagy a Cloudflare továbbra is a fehér verziót szolgálja ki – te meg keresed tovább a hibát, ami már nincs.

Sorrend javítás után: WordPress cache-bővítmény ürítése → CDN/Cloudflare cache purge → böngésző kemény újratöltés (Ctrl+Shift+R) → privát ablakos ellenőrzés.

Fordított irányban is igaz: ha a cache-bővítmény tömörítése (minify, combine) rossz CSS-t vagy JS-t gyárt, attól is kiürülhet a látvány. Ilyenkor a tömörítés kikapcsolása az első teszt.

6) Megjelenítési gond: megvan a HTML, de nem látszik

Ha a forrásban ott a tartalom, a hiba a CSS-ben vagy a JS-ben van. Nézd meg a Console fülön:

• 404-es CSS vagy JS fájl → hibás elérési út, jellemzően költöztetés vagy HTTPS-váltás után.
• Mixed content blokkolás → a HTTPS-oldal HTTP-forrást próbál betölteni, a böngésző leállítja.
• JS hiba a legelején → egy hibás szkript megállítja a többit is, és ha a sablon JS-ből építi a felületet, üres marad.

7) Sérült vagy hiányzó core fájl

A naplóban require_once(): Failed opening required szerepel, a /wp-includes/ vagy /wp-admin/ mappából. Megszakadt frissítés vagy hibás feltöltés után fordul elő.

Javítás: töltsd le a hu.wordpress.org oldalról a saját verziódat, csomagold ki, és FTP-n írd felül a wp-admin és wp-includes mappákat, valamint a gyökérben lévő fájlokat. A wp-content mappához és a wp-config.php-hoz ne nyúlj.

8) Félbemaradt frissítés

Ha a frissítés timeout vagy memóriahiány miatt megszakadt, ottmarad a gyökérben egy .maintenance fájl, és félig frissült core. A fájl törlése után ellenőrizd, hogy a frissítés valóban befejeződött-e – ha nem, futtasd újra az adminból, vagy töltsd fel kézzel a core fájlokat.

Ha a hiba konkrétan egy WordPress-frissítés után jelent meg, erről külön van egy cikk: WordPress 7.0 / 7.1 frissítés után nem működik az oldalad?

Speciális eset: költöztetés vagy HTTPS-váltás után

Ha az oldal a tárhelyváltás, domainváltás vagy SSL-bekapcsolás után lett fehér, a fenti nyolc ok helyett először ezeket nézd:

• Rossz adatbázis-adatok a wp-config.php-ban. Új szerveren más a DB_HOST, más a felhasználónév. Ez általában „Hiba az adatbázis-kapcsolatban” üzenetet ad, de ha a hibakezelő is elhasal, fehér lap lesz belőle.
• A régi domain maradt az adatbázisban. A wp_options tábla siteurl és home értéke még a régi címre mutat, ezért a böngésző oda próbál átmenni. Ideiglenes javítás a wp-config.php-ban:

  define( 'WP_HOME', 'https://azujdomain.hu' );
  define( 'WP_SITEURL', 'https://azujdomain.hu' );

• Szerializált adatok törtek el egy rossz keresés-csere miatt. Ha az adatbázisban sima SQL REPLACE-szel cserélted le a domaint, a szerializált mezők hossza elromlott, és a PHP nem tudja visszafejteni őket. Erre való a WP-CLI search-replace parancsa vagy a Better Search Replace bővítmény – ezek kezelik a szerializálást.
• Más a PHP-verzió az új szerveren. Ez a leggyakoribb meglepetés költöztetés után: a régi helyen PHP 7.4 futott, az újon 8.3, és a sablon nem bírja.
• Hiányzó fájlok. Az FTP-s átmásolás gyakran kihagy rejtett fájlokat – például a .htaccess-t –, mert a kliens alapból nem mutatja őket.

Ha a költöztetés még előtted áll, a weboldal- és e-mail-költöztetés pont ezeknek a buktatóknak az elkerüléséről szól.

Speciális eset: csak az admin fehér

Ilyenkor a nyilvános oldal működik, tehát a sablon és a core rendben van. A gyanúsítottak:

1. Adminfelületet módosító bővítmény – kapcsold ki őket FTP-n, mappaátnevezéssel.
2. Memóriakorlát: az admin többet eszik, mint a nyilvános oldal. Gyakran pont itt derül ki, hogy kevés a memória.
3. Sérült wp-admin fájlok – írd felül a core-ból.

Van egy gyorsítás: próbáld meg közvetlenül a /wp-admin/options-general.php címet. Ha az betölt, de a vezérlőpult nem, akkor egy vezérlőpult-widgetet adó bővítmény a gond.

Speciális eset: csak a blokkszerkesztő fehér

Ez JavaScript-probléma, nem PHP. Legtöbbször egy régi Block API-t használó blokk, vagy egy ütköző szkript. Két gyors teszt:

• Nézd meg a Console fülön a piros hibát – a fájl útvonala megnevezi a bővítményt.
• Tedd be ideiglenesen a wp-config.php-ba: define( 'SCRIPT_DEBUG', true ); – így a tömörítetlen fájlok töltenek be, és olvasható hibaüzenetet kapsz.

Fontos: ettől a látogatók semmit nem látnak. Bosszantó, de nem vészhelyzet – ne ess pánikba, és ne állj vissza mentésből emiatt.

Hogyan előzd meg

1. Mentés frissítés előtt – nem havonta, hanem közvetlenül előtte.
2. Hagyj egy alap sablont telepítve. Ez hibaelhárításkor egy kattintásos kizárás.
3. Csoportokban frissíts, ne mind a húsz bővítményt egyszerre.
4. Legyen elég memória. 2026-ban egy komolyabb WooCommerce oldalhoz 256–512 MB a realitás, nem 128.
5. Ismerd a cache-ürítés sorrendjét – a fenti négy lépés megspórol néhány órát életedből.
6. Legyen saját mentésed, ne csak a tárhelyé: Miért fontos a havi karbantartás és a saját biztonsági mentés?

Ha ez több figyelmet igényel, mint amennyit erre szánni akarsz, erre való a havi WordPress karbantartás.

Gyakori kérdések

Kapcsolódó olvasnivaló: „Kritikus hiba történt a webhelyén” · Hol van a WordPress hibanapló? · WordPress 7.x frissítés után hiba