WordPress Beyaz Ekran: Site Bomboş Açılıyorsa Ne Yapmalı?

WordPress beyaz ekran hatası, yani kullanıcıların "beyaz ölüm ekranı" dediği durum, bu sistemin en sinir bozucu arızasıdır. Çünkü hiçbir şey söylemez. Adresi yazarsınız, sayfa yüklenir, tarayıcı yükleme çubuğunu tamamlar ve karşınızda bembeyaz bir sayfa durur. Ne hata kodu vardır, ne satır numarası, ne de nereye bakacağınıza dair bir ipucu. Çoğu zaman /wp-admin de aynı şekilde bomboş açılır, yani panele girip bir şeyleri kapatma imkânınız da yoktur.

İnternetteki Türkçe rehberlerin neredeyse tamamı buradan doğrudan çözüm listesine atlar: eklentileri kapat, temayı değiştir, belleği artır. Bu adımlar yanlış değildir ama sıralaması baştan hatalıdır, çünkü beyaz ekran aslında bir PHP hata mesajının gizlenmiş hâlidir. Sunucu ölümcül bir hata üretmiş, PHP display_errors kapalı olduğu için mesajı ekrana basmamış, geriye boş bir yanıt kalmıştır. Bu yazıda önce o gizlenen mesajı görünür kılmayı anlatıyorum — ki bu iş genelde tek satırlık bir değişiklikle biter ve size hatanın hangi dosyanın kaçıncı satırında olduğunu doğrudan söyler. Ardından panele hiç giremediğiniz durumda FTP üzerinden nasıl ilerleyeceğinizi, bellek ve eklenti kaynaklı nedenleri ve kalıcı çözümü sırayla ele alıyorum. Deneme yanılma yerine teşhis yapacaksınız.

Beyaz Ekran Aslında Nedir#

Beyaz ekran, sunucunun boş bir yanıt gövdesi döndürmesidir. PHP ölümcül bir hatayla (fatal error) durmuş, o ana kadar hiçbir HTML üretilmemiş ve hata mesajı da bastırılmıştır. Yani ekranda gördüğünüz beyazlık bir "durum" değil, bir mesajın yokluğudur.

Bu ayrımı görmenin en hızlı yolu HTTP durum koduna bakmaktır. Tarayıcının geliştirici araçlarında Ağ sekmesini açıp sayfayı yenileyin ya da komut satırından bakın:

curl -sI https://siteniz.com/

Gördüğünüz koda göre teşhis dallanır:

Bu tablo tek başına saatler kazandırır. 500 alıyorsanız kesinlikle bir PHP hatası vardır ve log dosyası size onu söyleyecektir. 200 alıp boş sayfa görüyorsanız hata farklıdır: genellikle functions.php sonundaki fazladan bir kapanış etiketi, bir yeniden yönlendirme kesintisi ya da exit çağıran bir eklenti söz konusudur.

Bir de gerçekten "beyaz ekran" olmayan bir durum vardır: sayfa kaynağına baktığınızda HTML var ama görsel olarak boş görünüyorsa, sorun PHP'de değil CSS'tedir. Tarayıcıda sağ tık → Sayfa Kaynağını Görüntüle yapın. Kaynak tamamen boşsa PHP tarafındasınız; HTML doluysa stil dosyası yüklenmiyor demektir ve bu tamamen ayrı bir konudur.

Gizlenen Hatayı Görünür Kılma: WP_DEBUG#

Beyaz ekranı çözmenin doğru ilk adımı, WordPress'in hata ayıklama modunu açmaktır. Bu, gizlenen PHP mesajını geri getirir ve deneme yanılmayı tamamen ortadan kaldırır.

FTP veya dosya yöneticisi ile sitenin kök dizinindeki wp-config.php dosyasını açın. İçinde şu satırı bulun:

define( 'WP_DEBUG', false );

Bu satırı silin ve yerine şunları koyun:

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

Bu dört satırın her biri bilinçli bir tercihtir:

• WP_DEBUG hata raporlamayı açar.
• WP_DEBUG_LOG hataları dosyaya yazar: wp-content/debug.log.
• WP_DEBUG_DISPLAY false olduğu için hatalar ziyaretçilerin ekranına basılmaz — canlı sitede bu çok önemlidir, çünkü hata mesajları dosya yollarını ve bazen veritabanı bilgilerini sızdırabilir.
• @ini_set satırı, sunucu ayarı ne olursa olsun ekrana basmayı kapatır.

⚠️ Bu satırları wp-config.php dosyasının /* That's all, stop editing! */ yorumundan önce eklemelisiniz. Sonrasına yazarsanız WordPress zaten yüklenmiş olur ve tanımlar hiçbir işe yaramaz.

Şimdi siteyi bir kez yenileyin, ardından wp-content/debug.log dosyasını açın. Tipik bir çıktı şuna benzer:

[11-Aug-2026 09:14:02 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product()
in /home/hesap/public_html/wp-content/themes/magaza/functions.php:214
Stack trace:
#0 /home/hesap/public_html/wp-includes/class-wp-hook.php(324): magaza_urun_kutusu()
#1 ...

Bu üç satır her şeyi söyler: hata functions.php dosyasının 214. satırındadır, sebep tanımsız bir WooCommerce fonksiyonunun çağrılmasıdır — yani WooCommerce devre dışı bırakılmış ama tema hâlâ onu çağırıyordur. Çözüm artık tahmin değil, doğrudan müdahaledir.

Log dosyası oluşmuyorsa wp-content klasörünün yazılabilir olduğundan emin olun; klasör izinleri 755, dosya izinleri 644 olmalıdır. Bu değerler tutmuyorsa WordPress dosyayı oluşturamaz ve siz de hâlâ hiçbir şey göremezsiniz.

Sunucu Hata Loglarını Okuma#

debug.log oluşmuyorsa ya da hata WordPress yüklenmeden önce meydana geliyorsa (örneğin wp-config.php içindeki bir sözdizimi hatası), sunucunun kendi hata loguna bakmanız gerekir.

Paylaşımlı hostingde cPanel → Ölçümler → Hata Kayıtları ekranı son satırları gösterir. Ayrıca hesabınızın kök dizininde ya da public_html altında error_log adlı bir dosya oluşmuş olabilir. Ayrıntılar için cPanel hata kayıtları yazısına bakabilirsiniz.

SSH erişiminiz varsa doğrudan okuyun:

tail -n 50 ~/public_html/error_log
tail -n 50 /var/log/php-fpm/www-error.log
tail -n 50 /var/log/nginx/error.log

Sık karşılaşılan satırlar ve anlamları:

Son satırı görüyorsanız beyaz ekranınız aslında bir veritabanı sorunudur; çözümü WordPress veritabanı bağlantı hatası yazısında ayrıca ele alınıyor. Bellek satırı için ise bir sonraki bölüme geçin.

Bellek Limiti Kaynaklı Beyaz Ekran#

Bellek yetersizliği beyaz ekranın en yaygın tek sebebidir ve logda çok net bir imza bırakır:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)

Buradaki sayı bayt cinsindendir; 268435456 bayt tam olarak 256 MB'dir. WordPress varsayılan olarak 40 MB civarında bir limitle çalışır ama sayfa oluşturucular, WooCommerce ve görsel işleme eklentileri bunu kolayca aşar.

Limiti artırmanın üç yolu vardır; sırayla deneyin.

1. wp-config.php üzerinden — en kolay ve çoğu durumda yeterli olan yol:

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

WP_MEMORY_LIMIT ön yüz için, WP_MAX_MEMORY_LIMIT yönetim paneli ve toplu işlemler için geçerlidir.

2. php.ini veya cPanel'in PHP Seçenekleri ekranından — hosting sağlayıcınız izin veriyorsa:

memory_limit = 256M
max_execution_time = 120
max_input_vars = 3000

3. .htaccess üzerinden — yalnızca Apache ve mod_php kullanılan kurulumlarda çalışır:

php_value memory_limit 256M

⚠️ Üçüncü yöntem LiteSpeed ya da PHP-FPM kullanan sunucularda çalışmaz; hatta bazı yapılandırmalarda 500 hatası üretir. Beyaz ekranı çözmeye çalışırken yeni bir 500 aldıysanız, ilk şüpheli eklediğiniz bu satırdır.

Limiti artırmak semptomu geçirir ama sebebi çözmez. Normal bir WordPress sitesi 256 MB'ı düzenli olarak tüketiyorsa bir yerde sorun vardır: sonsuz döngüye giren bir kanca, her sayfada tüm ürünleri belleğe yükleyen bir sorgu ya da devasa görselleri işlemeye çalışan bir eklenti. Değeri artırdıktan sonra hangi eklentinin belleği yediğini bulmak için bir sonraki bölümdeki eleme yöntemini uygulayın. Değeri sınırsıza yakın büyütmek (-1 gibi) ise çözüm değil, sunucuyu tüketen bir betiğe açık çek vermektir.

Panele Giremiyorsanız: FTP ile Eklenti Elemesi#

/wp-admin de beyaz açılıyorsa eklentileri panelden kapatamazsınız. Bu durumda dosya sistemi üzerinden aynı işi yapabilirsiniz — WordPress, klasörü bulunmayan bir eklentiyi otomatik olarak devre dışı bırakır.

1. FTP istemcisiyle veya hosting panelinin dosya yöneticisiyle bağlanın.
2. wp-content/plugins klasörüne gidin.
3. Klasörün adını plugins-eski olarak değiştirin.
4. Siteyi yenileyin.

Site açıldıysa sebep kesin olarak eklentilerdedir. Şimdi hangisi olduğunu bulun:

5. Klasörün adını tekrar plugins yapın. Tüm eklentiler devre dışı kalmış olacak.
6. Panele girin (artık girebiliyor olmalısınız).
7. Eklentileri teker teker aktifleştirin ve her birinden sonra siteyi yenileyin.
8. Beyaz ekran hangi eklentiyi aktifleştirdiğinizde geri gelirse suçlu odur.

Eğer panele hâlâ giremiyorsanız, eklentileri tek tek elemek için klasörleri birer birer yeniden adlandırabilirsiniz:

cd ~/public_html/wp-content/plugins
mv sorunlu-eklenti sorunlu-eklenti-kapali

SSH erişiminiz varsa WP-CLI çok daha hızlıdır ve panele hiç ihtiyaç duymaz:

wp plugin list --status=active
wp plugin deactivate --all
wp plugin activate eklenti-adi

Bu üç komut sırasıyla aktif eklentileri listeler, hepsini kapatır ve tek tek geri açmanızı sağlar. Eklentilerin birbiriyle çakışma mantığını anlamak isterseniz WordPress eklenti çakışması yazısı da işinize yarar.

Tema Kaynaklı Beyaz Ekranı Ayıklama#

Eklentileri tamamen kapattığınız hâlde beyaz ekran duruyorsa sıradaki şüpheli temadır. Aynı mantıkla ilerlersiniz: temanın klasörünü yeniden adlandırırsanız WordPress varsayılan temaya (twentytwentyfour gibi) düşer.

cd ~/public_html/wp-content/themes
mv aktif-tema aktif-tema-kapali

⚠️ Bu adımdan önce dizinde en az bir varsayılan tema bulunduğundan emin olun. Hiç tema kalmazsa WordPress yine hata verir ve teşhisi karıştırırsınız.

Site varsayılan temayla açılıyorsa sorun temanızdadır. Sebep neredeyse her zaman functions.php dosyasıdır ve dört klasik hata vardır:

1. Dosyanın sonunda fazladan kapanış etiketi ve boşluk. ?> etiketinden sonra bir boşluk veya boş satır kalırsa PHP bunu çıktı olarak gönderir, header'lar bozulur ve sayfa boş kalır. Modern PHP'de functions.php dosyasını kapanış etiketi olmadan bitirmek doğru davranıştır — son satırdaki ?> işaretini tamamen silin.

2. Kod parçacığı yapıştırırken bozulan tırnaklar. İnternetten kopyalanan kodlardaki tipografik tırnaklar (" yerine “) PHP tarafından anlaşılmaz ve sözdizimi hatası üretir. Logda syntax error, unexpected satırı bunu ele verir.

3. Aynı fonksiyonun iki kez tanımlanması. Ana temadaki bir fonksiyonu child temaya kopyalarken if ( ! function_exists( ... ) ) kontrolünü atlamak Cannot redeclare function hatası verir.

4. Tema güncellemesi sonrası uyumsuzluk. Tema yeni bir PHP sürümü gerektiriyor ya da güncelleme yarım kalmış olabilir.

Değişiklikleri doğrudan canlı temada yapmak yerine bir child tema kullanmak bu riskin büyük kısmını ortadan kaldırır: güncelleme sizin kodunuzu ezmez ve sorun çıktığında yalnızca child temayı devre dışı bırakmanız yeterli olur.

Beyaz Ekranın Diğer Sebepleri#

Eklenti, tema ve bellek en yaygın üç sebeptir ama liste bununla bitmez. Yukarıdakiler eledikten sonra bakılacak yerler:

Bozuk .htaccess dosyası. Yönlendirme kuralları bozulduğunda beyaz ekran veya 500 hatası alırsınız. Dosyayı .htaccess-eski olarak yeniden adlandırıp siteyi deneyin. Açılıyorsa panelden Ayarlar → Kalıcı Bağlantılar ekranına girip hiçbir şey değiştirmeden Kaydet'e basın; WordPress dosyayı temiz biçimde yeniden yazar. Bu adımdan sonra yazı sayfalarınız 404 vermeye başlarsa WordPress yazılar 404 veriyor yazısındaki kurallar devreye girer.

PHP sürüm uyumsuzluğu. Hosting panelinden PHP sürümünü yükselttiğinizde eski bir eklenti veya tema artık kaldırılmış bir fonksiyonu çağırıyor olabilir. Logda Call to undefined function ya da Deprecated satırlarını göreceksiniz. Geçici çözüm önceki sürüme dönmek, kalıcı çözüm ilgili bileşeni güncellemek ya da değiştirmektir.

Bozuk çekirdek dosyaları. Yarım kalan bir güncelleme veya kötü amaçlı yazılım temizliği çekirdek dosyalarını bozmuş olabilir. Çözüm, wp-admin ve wp-includes klasörlerini temiz bir WordPress arşivindeki karşılıklarıyla değiştirmektir. wp-content ve wp-config.php dosyalarına dokunmayın — içerikleriniz ve ayarlarınız oradadır.

Yarım kalan güncellemeden kalan .maintenance dosyası. Kök dizinde bu isimde bir dosya varsa WordPress kendini bakım modunda sanır. Silmeniz yeterlidir.

Kaynak limiti. Paylaşımlı hostingde hesabınız CPU veya bellek limitini aştığında sayfalar boş dönebilir. Panelin kaynak kullanımı grafiklerinde ani sıçrama görüyorsanız sebep budur; bu durumda kod hatası aramak boşunadır, site o an paketine sığmamaktadır.

Kötü amaçlı yazılım. Enjekte edilen kod bazen sayfayı tamamen boş bırakır. Yeni oluşturulmuş, alışılmadık adlara sahip PHP dosyalarını arayın:

find ~/public_html -name "*.php" -mtime -7 -ls

Bu komut son yedi günde değişmiş tüm PHP dosyalarını listeler; siz bir güncelleme yapmadıysanız çıkan liste doğrudan şüphelilerdir.

Beyaz Ekranı Bir Daha Yaşamamak İçin#

Bu arızanın büyük kısmı önlenebilir; hepsi de aynı ilkeye dayanır: canlı sitede deneme yapmayın.

1. Staging ortamı kullanın. Güncellemeleri ve kod değişikliklerini önce kopya bir ortamda deneyin. Birçok hosting paneli tek tıkla staging kopyası oluşturur ve değişiklik doğrulandıktan sonra canlıya aktarmanızı sağlar.
2. Otomatik yedek alın ve geri dönüşü test edin. Yedeğiniz varsa beyaz ekran bir felaket değil, on dakikalık bir iştir. Hiç geri yüklemediğiniz bir yedek, yedek sayılmaz.
3. Kodu child temaya yazın. Ana temaya yazılan her satır bir sonraki güncellemede kaybolur ya da çakışır.
4. Eklenti sayısını disiplinli tutun. Aynı işi yapan iki eklenti çoğu zaman çakışır ve bellek tüketimini ikiye katlar.
5. PHP sürümünü bilinçli yükseltin. Önce staging'de deneyin, uyumsuz bileşenleri tespit edin, sonra canlıya alın.
6. WP_DEBUG_LOG satırını hazır tutun. Canlıda WP_DEBUG kapalı kalsın ama satırlar dosyada dursun; sorun çıktığında false değerini true yapmak saniyeler alır.
7. Site sağlığını izleyin. Panelin Araçlar → Site Sağlığı ekranı, ölümcül hataya dönüşmeden önce uyarıları gösterir.

Sorun çözüldükten sonra WP_DEBUG satırını mutlaka false yapın ve wp-content/debug.log dosyasını silin. Bu dosya web üzerinden erişilebilir olduğunda dosya yollarınızı ve bazen sorgu içeriklerinizi dışarıya açar; bırakmak gerekiyorsa erişimini kapatın:

<Files "debug.log">
    Require all denied
</Files>

Sıkça Sorulan Sorular#

WordPress beyaz ekranın en yaygın sebebi nedir#

En yaygın sebep, bir eklenti veya temanın ürettiği PHP ölümcül hatasıdır; ikinci sırada PHP bellek limitinin dolması gelir. Her iki durumda da sunucu ölümcül hatayla durur, mesaj gizlendiği için ekran boş kalır. Bu yüzden ilk adım eklenti kapatmak değil, wp-config.php içinde WP_DEBUG ve WP_DEBUG_LOG tanımlarını açıp wp-content/debug.log dosyasını okumaktır. Log size hangi dosyanın kaçıncı satırında ne olduğunu doğrudan söyler.

Panele giremiyorum, eklentileri nasıl kapatabilirim#

FTP veya hosting panelinin dosya yöneticisiyle bağlanıp wp-content/plugins klasörünün adını plugins-eski olarak değiştirin. WordPress klasörünü bulamadığı eklentileri otomatik olarak devre dışı bırakır ve panel açılır. Ardından klasör adını geri alıp eklentileri panelden tek tek aktifleştirerek sorunluyu bulabilirsiniz. SSH erişiminiz varsa wp plugin deactivate --all komutu aynı işi tek satırda yapar.

WP_DEBUG açmak canlı sitede güvenli mi#

Doğru yapılandırılırsa güvenlidir. WP_DEBUG değerini true, WP_DEBUG_DISPLAY değerini ise false yapmalısınız; böylece hatalar ziyaretçilerin ekranına basılmaz, yalnızca wp-content/debug.log dosyasına yazılır. WP_DEBUG_DISPLAY açık bırakılırsa dosya yolları, eklenti isimleri ve bazen sorgu içerikleri herkese görünür hâle gelir. Sorun çözüldükten sonra tanımı false yapmayı ve log dosyasını silmeyi unutmayın.

Beyaz ekran ile 500 hatası arasındaki fark ne#

Aslında çoğu zaman ikisi aynı olayın iki farklı görünümüdür: 500 hatasında sunucu hata sayfası döndürür, beyaz ekranda ise hiçbir gövde döndürmez. curl -sI https://siteniz.com/ komutuyla gerçek durum kodunu görebilirsiniz. 500 alıyorsanız kesinlikle bir PHP ölümcül hatası vardır ve log dosyasında karşılığı bulunur. 200 alıp boş sayfa görüyorsanız betik hatasız bitmiş ama hiç çıktı üretmemiştir; bu genellikle functions.php sonundaki fazladan boşluk ya da bir eklentinin erken exit çağırması anlamına gelir.

Bellek limitini artırmak sorunu kalıcı çözer mi#

Hayır, çoğu zaman yalnızca semptomu erteler. Normal bir WordPress sitesi 256 MB belleği düzenli olarak tüketmemelidir; tüketiyorsa arkada döngüye giren bir kanca, kontrolsüz bir veritabanı sorgusu veya çok büyük görselleri işlemeye çalışan bir eklenti vardır. Limiti geçici olarak artırıp siteyi ayağa kaldırmak doğrudur, ancak ardından hangi bileşenin belleği tükettiğini eklenti elemesiyle bulmalısınız. Aksi hâlde birkaç hafta içinde yeni limit de dolar.

functions.php dosyasına kod ekledikten sonra site kapandı, ne yapmalıyım#

FTP ile bağlanıp wp-content/themes/tema-adi/functions.php dosyasını açın ve eklediğiniz kodu silin. Kod yerine dosyanın sonundaki ?> etiketinden sonra kalmış bir boşluk da aynı sonucu doğurabilir; bu durumda kapanış etiketini tamamen kaldırın. İnternetten kopyaladığınız kodlarda tipografik tırnak karakterleri sıkça soruna yol açar, düz tırnak kullandığınızdan emin olun. Bu tür değişiklikleri ana temada değil child temada yapmak, sorun çıktığında yalnızca child temayı devre dışı bırakmanızı sağlar.

Beyaz ekran sadece yönetim panelinde çıkıyorsa sebep ne olabilir#

Ön yüz açılıp yalnızca /wp-admin boş geliyorsa, şüpheli listenin başında yönetim tarafında çalışan eklentiler ve bellek limiti vardır. Panel, ön yüze göre çok daha fazla bellek tüketir ve WP_MAX_MEMORY_LIMIT değeri düşükse yalnızca orada hata verir. Ayrıca yarım kalan bir güncellemeden kalan .maintenance dosyası ya da bozuk bir wp-admin çekirdek dosyası da aynı tabloyu üretir. Önce bellek tanımını yükseltin, sonuç alamazsanız wp-admin klasörünü temiz bir WordPress arşivinden yenileyin.

Sorun çözüldükten sonra debug.log dosyasını silmeli miyim#

Evet, mutlaka silin veya web erişimini kapatın. wp-content/debug.log dosyası varsayılan olarak tarayıcıdan doğrudan okunabilir ve içinde sunucu dosya yolları, eklenti isimleri, bazen sorgu parçaları bulunur. Bu bilgiler saldırganın işini kolaylaştırır. Log tutmaya devam etmek istiyorsanız dosyayı .htaccess kuralıyla erişime kapatın ve düzenli olarak boyutunu kontrol edin, çünkü sürekli uyarı üreten bir kurulumda hızla büyür.

Kapanış#

WordPress beyaz ekran hatasında yapılacak ilk iş eklenti kapatmak değil, gizlenen mesajı geri getirmektir. WP_DEBUG ve WP_DEBUG_LOG tanımlarını açıp wp-content/debug.log dosyasını okuduğunuzda, saatler sürebilecek bir deneme yanılma süreci çoğu zaman tek satırlık bir hata mesajına iner: hangi dosya, kaçıncı satır, hangi fonksiyon. Log oluşmuyorsa sunucunun kendi hata kaydına bakar, oradan da bir şey çıkmazsa sırayla eklenti, tema, .htaccess ve bellek elemesini uygularsınız. Panele hiç giremediğiniz durumda FTP üzerinden plugins klasörünü yeniden adlandırmak, sizi her zaman yönetim paneline geri sokan güvenilir bir çıkış yoludur.

Bu tür arızalarla tek başınıza uğraşmak istemiyorsanız, güncelleme, yedek ve hata takibini üstlenen bir WordPress bakım hizmeti işi devralır. Staging ortamı, otomatik yedek ve yeterli PHP bellek limiti hazır gelen bir WordPress hosting paketi de bu sorunların büyük kısmını baştan engeller. Yedeklerinizi siteyle aynı sunucuda değil ayrı bir kopyada tutmak isterseniz yedekleme hizmeti bu işi üstlenir; beyaz ekranın on dakikada kapanan bir sorun olmasının tek şartı zaten çalışan bir yedektir.