WordPress Beyaz Ekranı; On Dakikada Teşhis ve Çözüm

WordPress Beyaz Ekranı; Site Hiçbir Hata Göstermediğinde

Siteyi açarsın ve sadece beyaz bir ekran görürsün. Ne 500 hata mesajı, ne hata metni, ne de başka bir şey. Tarayıcı "Bağlantı kuruldu" der ve sonra hiçbir şey olmaz. İşte bu, her site yöneticisinin kalp atışını hızlandıran andır, özellikle site bir e-ticaret sitesiyse ve yoğun trafik saatindeyse.

WordPress beyaz ekranı (WSOD), PHP'nin çalıştığı ancak herhangi bir çıktı üretilmeden önce ölümcül bir hatanın meydana geldiği anlamına gelir. Hataların ekranda gösterilmesi devre dışıdır, bu yüzden sadece boş bir sayfa görürsün. İyi haber şu ki, vakaların %90'ında sorun yeni kurulmuş bir eklenti veya temadan kaynaklanır. Kötü haber ise, onu bulmak için doğru araçları etkinleştirmen gerektiğidir.

İlk Adım: wp-config.php Üzerinden WP_DEBUG'i Etkinleştirme

WordPress kurulumunun kök dizinindeki wp-config.php dosyasına erişim sağla. Bunu FTP, hosting dosya yöneticisi veya SSH üzerinden yapabilirsin. Dosyayı aç ve WP_DEBUG içeren satırı ara. Eğer yoksa, şu üç satırı tam olarak /* That's all, stop editing! Happy publishing. */ ifadesinin hemen öncesine ekle:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Üçüncü satırı bilerek false yaptım. Neden mi? Çünkü WP_DEBUG_DISPLAY etkin olduğunda, hatalar ekranda gösterilir ve sitenin HTML yapısını bozabilir. Biz hataları ekranda değil, günlük dosyasında istiyoruz.

Şimdi dosyayı kaydet ve siteyi tekrar aç. Hâlâ beyazsa, wp-content/debug.log dosyasına git. Bu dosyanın artık oluşturulmuş olması gerekir. Oluşturulmadıysa, hata WordPress çalıştırılmadan önce meydana geliyor demektir ve sorun başka bir yerdedir.

Burada Hata Yapıyorlar

Birçok kişi wp-config.php dosyasını Notepad gibi bir Windows düzenleyicisiyle açar ve dosyayı yanlış kodlamayla kaydeder. Sonuç mu? "headers already sent" hatası veya başka bir beyaz ekran. UTF-8 BOM'suz kodlamayı koruyan bir düzenleyici kullan. Notepad++ veya VS Code güvenli seçeneklerdir. Dosyayı kaydettikten sonra site tamamen çalışmaz hale geldiyse, muhtemelen dosya kodlaması bozulmuştur.

Hata Günlüğünü Okuma; Neye Bakmalıyız

debug.log dosyasını aç. Dosyanın sonundaki en son hatayı ara. Tipik bir hata şuna benzer:

[12-Nov-2025 14:32:11 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_current_user() in /home/user/public_html/wp-content/plugins/some-plugin/functions.php:15

Bu hatanın üç önemli bölümünü ayır: hata türü (Fatal error), mesaj (Call to undefined function) ve suçlu dosyanın yolu (plugins/some-plugin/functions.php). Dosya yolu, sana suçlunun kim olduğunu söyleyen şeydir.

Yol wp-content/plugins/ dizinini gösteriyorsa, sorun eklentidendir. wp-content/themes/ dizinini gösteriyorsa, tema suçludur. WordPress çekirdek dosyalarını gösteriyorsa, muhtemelen çekirdek dosyalar bozulmuştur veya sunucudaki PHP sürümüyle uyumsuzdur.

Yönetim Paneline Erişmeden Eklentiyi Devre Dışı Bırakma

Sayfa beyaz olduğunda, WordPress yönetim paneline de erişilemez. Bu yüzden dışarıdan girmen gerekir. En basit yol: FTP veya dosya yöneticisi üzerinden wp-content/plugins/ klasörüne git ve şüphelendiğin eklentinin klasör adını değiştir. Örneğin, woocommerce klasörünü woocommerce-disabled olarak değiştir. WordPress, bir eklentiyi beklenen yolda bulamadığında onu devre dışı bırakır.

Hangi eklentinin suçlu olduğunu bilmiyorsan, plugins klasörünün tamamını plugins-disabled olarak yeniden adlandır. Bu, tüm eklentileri devre dışı bırakır. Siteyi aç. Eğer yüklendiyse, sorun eklentilerden birindedir. Şimdi klasörü orijinal adına geri getir ve klasör adını değiştirerek eklentileri tek tek devre dışı bırakıp etkinleştirerek suçluyu bul.

Bu yöntem kaba ama işe yarar. WordPress, eklentilerin etkinlik ayarlarını dosyalarda değil, veritabanındaki wp_options tablosunda tutar. Bu yüzden klasör adını değiştirmek, WordPress'i eklentiyi "kayıp" olarak varsaymaya ve onu devre dışı bırakmaya zorlar.

İkinci Yol: phpMyAdmin Üzerinden Devre Dışı Bırakma

FTP erişimin yoksa ama phpMyAdmin'in varsa, oradan girebilirsin. wp_options tablosuna git ve option_name değeri active_plugins olan satırı ara. Bu satırın değeri, etkin eklentilerin serileştirilmiş bir dizisidir. Değeri şu ifadeyle değiştir:

a:0:{}

Bu, "boş dizi" anlamına gelir. Tüm eklentiler devre dışı bırakılır. ServerNet'in dokümantasyon ve bilgi tabanına aşina değilsen, bu işlemi dikkatli yap. Herhangi bir değişiklikten önce veritabanının yedeğini al. phpMyAdmin ile çalışma hakkında eksiksiz rehberi bu makalede oku.

Suçlu Her Zaman Eklenti Değildir; PHP Belleğini Kontrol Et

Bir diğer yaygın senaryo: Allowed memory size of 134217728 bytes exhausted hatası. Bu, betiğin izin verilen sınırdan daha fazla belleğe ihtiyaç duyduğu anlamına gelir. WordPress'in varsayılan sınırı, 134217728 bayta eşit olan 128M'dir. WooCommerce veya sayfa oluşturucular kullanan ağır siteler için bu miktar yeterli değildir.

Bellek sınırını artırmak için wp-config.php dosyasına şu satırı ekle:

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

Bu işe yaramazsa, sorun sunucunun PHP ayarlarındadır. php.ini dosyasındaki memory_limit değerini kontrol et. Linux hosting'de genellikle bu değeri yönetim panelinden değiştirebilirsin.

Önemli bir not: Belleği sonsuza kadar artırmak bir çözüm değildir. Basit bir sayfayı çalıştırmak için 512M belleğe ihtiyaç duyan bir sitenin başka bir yerde sorunu var demektir. Genellikle ağır bir eklenti veya optimize edilmemiş bir veritabanı sorgusu suçludur. Siteyi ayağa kaldırmak için belleği artır, ancak sonra sorunun kökenini ara.

Hiçbiri İşe Yaramadığında; 500 Hatası ve Sunucu Günlüğü

Tüm bu işlemlerden sonra sayfa hâlâ beyazsa, sunucu günlüğünü devreye sok. Paylaşımlı hostinglerde, error_log dosyası genellikle public_html kök dizininde bulunur. Sanal sunucularda, yapılandırmaya bağlı olarak şu komutu kullanabilirsin:

tail -f /var/log/apache2/error.log

Veya nginx ve PHP-FPM kullanıyorsan:

tail -f /var/log/nginx/error.log /var/log/php8.1-fpm.log

Bu günlükler, PHP'nin göremediği hataları gösterir: dosya erişim sorunları, timeout kaynaklı hatalar veya opcache ile ilgili sorunlar. Yaygın bir hata, dosyaların sahibinin PHP'yi çalıştıran kullanıcıyla aynı olmaması ve Permission denied hatası almandır.

Önceki Duruma Geri Dönme; Son Çare

Site birkaç saat önce çalışıyorsa ve şimdi beyazsa ve hiçbir değişiklik yapmadıysan, saldırı veya otomatik güncelleme ihtimali vardır. Bu durumda en iyisi, son yedekten geri yüklemektir. Yedeğin yoksa, bu dersi sonsuza kadar öğrenirsin: Yedek almak felaketten sonra değil, her değişiklikten önce yapılır.

Bu olayın tekrarlanmasını önlemek için, site erişilemez olduğunda sana haber verecek bir uptime izleme eklentisi kur. Site uptime izleme pratik rehberini oku ve basit bir uyarı ayarla. Kurulum için on dakika harcamak, uykusuz bir gecenin önüne geçer.

Sıkça Sorulan Sorular

WordPress beyaz ekranım neden 500 hatası vermiyor?

Çünkü sunucudaki PHP ayarları, hata gösterimini devre dışı bırakacak şekilde yapılandırılmıştır. WordPress hatayı görür ancak gösteremez, bu yüzden tarayıcıya boş bir sayfa iletir. WP_DEBUG ve WP_DEBUG_LOG etkinleştirmek bu hatayı debug.log dosyasına kaydeder.

Yönetim paneline erişmeden eklentileri nasıl devre dışı bırakırım?

FTP veya hosting dosya yöneticisi üzerinden wp-content/plugins/ içindeki eklenti klasörünün adını değiştir. WordPress, yolunda olmayan bir eklentiyi devre dışı varsayar. Tüm eklentileri devre dışı bırakmak için plugins klasörünün tamamının adını değiştir.

debug.log dosyası nerede ve nasıl bulurum?

WP_DEBUG_LOG etkinleştirildikten sonra, debug.log dosyası wp-content klasöründe oluşturulur. Oluşturulmadıysa, wp-content klasörünün yazılabilir olduğundan emin ol. Genellikle izinlerinin 755 veya 775 olması gerekir.

WordPress güncellemesi beyaz ekrana neden olabilir mi?

Evet. Bir eklenti yeni WordPress sürümüyle uyumsuzsa, otomatik güncelleme siteyi çalışmaz hale getirebilir. Bu durumda, önce tüm eklentileri devre dışı bırak ve ardından uyumsuz eklentiyi bulmak için tek tek etkinleştir. Site yönetilen WordPress hosting'deyse, genellikle hızlı geri yükleme araçlarına sahipsin.