WordPress Beyaz Sayfa Hatası: Nedenleri ve Adım Adım Çözümü

  • Konuyu Başlatan Konuyu Başlatan Admin
  • Başlangıç tarihi Başlangıç tarihi

Admin

Webmaster
Admin
Kurumsal+
Puan 18
Çözümler 0
Katılım
3 Kas 2025
Mesajlar
99
Tepkime puanı
0

WordPress Beyaz Sayfa Hatası: Nedenleri ve Adım Adım Çözümü​

WordPress sitenizi açtığınızda içerik yerine tamamen boş bir ekran görüyorsanız, ilk yapılacak iş rastgele ayar değiştirmek değildir. Önce sorunun hangi sayfalarda ortaya çıktığını ve hata başlamadan önce neyin değiştiğini belirlemek gerekir.
“White Screen of Death” veya kısaca WSOD olarak bilinen beyaz ekran, tek bir hatanın adı değildir. PHP ya da veritabanı hataları bu şekilde görünebilir; tema ve eklenti uyumsuzlukları da olası nedenler arasındadır. Bu yüzden her boş sayfayı bellek yetersizliği olarak değerlendirmek doğru olmaz.
Bu rehberde, yönetim paneline erişemediğiniz durumlar dâhil, sorunu kontrollü biçimde incelemek için kullanabileceğiniz adımları bulabilirsiniz.

İlk Kontrol: Sorun Nerede ve Ne Zaman Başladı?​

İşlem yapmadan önce birkaç soruya cevap verin:
  • Ana sayfa ve diğer sayfalar da boş mu?
  • /wp-admin/ üzerinden yönetim paneli açılıyor mu?
  • Sorun bütün ziyaretçilerde mi görülüyor?
  • Son işlem bir eklenti, tema veya PHP sürümü değişikliği miydi?
  • Güncelleme tamamlandı mı, yarıda mı kaldı?
Örneğin sorun bir kod düzenlemesinin hemen ardından başladıysa, önce o değişikliği incelemek daha anlamlıdır. Yalnızca tek bir sayfanın etkilenmesi ise o sayfada kullanılan şablon veya işlevlere odaklanmayı gerektirebilir.
Mümkünse mevcut dosyaların ve veritabanının yedeğini alın. En azından değiştireceğiniz dosyaların bir kopyasını saklayın. Her seferinde tek değişiklik yapıp sonucu kontrol edin; böylece hangi müdahalenin etkili olduğunu anlayabilirsiniz.

Gerçekten boş yanıt mı, görüntüleme sorunu mu?​

Tarayıcının geliştirici araçlarından ana sayfa isteğinin durumunu ve yanıt içeriğini inceleyin. Sunucudan HTML geliyor fakat ekranda görünmüyorsa, JavaScript veya sayfa görünümüyle ilgili bir sorun da araştırılmalıdır.
WordPress’in resmî dokümanlarında tarayıcı araçlarıyla JavaScript hatalarının incelenmesi ayrı bir sorun giderme yöntemi olarak açıklanır.
Farklı tarayıcıyla kontrol etmek faydalıdır. Ancak önbelleği temizlemek, sunucudaki bir PHP hatasını tek başına düzeltmez.

1. Hata Kayıtlarını İnceleyin​

Hosting panelindeki PHP ve web sunucusu hata kayıtlarıyla başlayın. Sorunun oluştuğu saati not edip ilgili kayıtları arayın.
WordPress hata ayıklaması için wp-config.php dosyasındaki mevcut tanımları düzenleyebilirsiniz:
Kod:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Aynı sabitleri ikinci kez eklemeyin. Tanımları, dosyadaki “That’s all, stop editing” yorumundan ve WordPress’in yüklenmesinden önce yerleştirin. true ve false değerlerini tırnak içine almayın.
Bu yapılandırmada WordPress kayıtları genellikle wp-content/debug.log dosyasına yazar. Hatayı yeniden oluşturup günlüğün son satırlarını kontrol edin. Hata ayıklamasını mümkünse test ortamında, canlı sitede gerekiyorsa kısa süreli kullanın.
Önemli: Hataların ekranda gösterilmemesi, günlük dosyasının özel olduğu anlamına gelmez. Dosya web üzerinden erişilebilir olabilir. Günlüğü web kökü dışında tutmak veya HTTP erişimini sunucu seviyesinde engellemek gerekir.
Kayıt oluşmuyorsa dosya izinleri, günlük ayarları veya WordPress başlamadan önce gerçekleşen bir hata araştırılmalıdır. Hosting tarafındaki PHP günlüğünü de inceleyin.

Hata mesajları nasıl yorumlanır?​

Kayıt veya belirtiAraştırılacak konu
Allowed memory size ... exhaustedİşlemin bellek tüketimi ve etkin PHP limiti
Call to undefined functionEksik dosya, bağımlılık veya sürüm uyumsuzluğu
Parse error / Syntax errorPHP kodundaki yazım hatası
Tema klasörünü gösteren hata yoluTema, child theme veya ilgili özel kod
Güncelleme sonrasında başlayan sorunGüncellemenin tamamlanıp tamamlanmadığı
HTTP 500 yanıtıPHP hatası, sunucu ayarı veya diğer sunucu sorunları

Dosya yolu önemli bir ipucudur; fakat hatada adı geçen bileşen tek başına kesin suçlu sayılmaz. Başka bir eklentiyle etkileşim veya eksik bağımlılık da incelenmelidir.

2. Kurtarma Modu E-postasını Kontrol Edin​

WordPress, bazı kritik PHP hatalarında yönetici adresine kurtarma bağlantısı gönderebilir. Gelen kutusuyla birlikte spam klasörünü de kontrol edin.
Kurtarma Modu, sorunlu tema veya eklentiyi ilgili oturum için duraklatarak yönetim paneline erişmenize yardımcı olabilir. Bu erişim, sitenin bütün ziyaretçiler için düzeldiği anlamına gelmez; sorunun ayrıca giderilmesi gerekir.
Her hata için kurtarma e-postası gelmesi garanti değildir. Hata oluşma aşaması veya e-posta teslimi buna engel olabilir. Bağlantıyı da başkalarıyla paylaşmayın.

3. Eklentileri Kontrollü Şekilde Test Edin​

Hata kaydı veya son değişiklik belirli bir eklentiyi işaret ediyorsa, önce o bileşeni devre dışı bırakın.
Panele girebiliyorsanız Eklentiler ekranını kullanabilirsiniz. Erişemiyorsanız dosya yöneticisi veya SFTP üzerinden ilgili klasörün adını geçici olarak değiştirmek mümkündür.
Örneğin:
wp-content/plugins/ornek-eklenti
Geçici ad:
wp-content/plugins/ornek-eklenti-test
Ardından etkilenen sayfayı tekrar kontrol edin.

Hangi eklentiden kaynaklandığı belli değilse​

Normal eklentileri topluca test etmek için:
  1. wp-content/plugins klasörünü geçici olarak plugins.hold şeklinde yeniden adlandırın.
  2. Yönetim panelindeki eklenti sayfasını açmayı deneyin.
  3. WordPress’in eksik eklentileri devre dışı bırakmasının ardından klasör adını tekrar plugins yapın.
  4. Eklentileri tek tek etkinleştirip her aşamada kontrol edin.
Bu yöntem WordPress’in resmî sorun giderme belgesinde açıklanır. Klasörün adını geri vermeden önce devre dışı bırakma adımının gerçekleşmesi önemlidir.
Eklentiler kapalıyken ödeme, form veya üyelik işlevleri çalışmayabilir. Testi kısa tutun ve mümkünse site kopyasında uygulayın.
Ayrıca bu işlem mu-plugins içindeki zorunlu eklentileri kapatmaz. Bunlar normal eklentilerden farklı şekilde yüklenir.
Site açılırsa silme işlemine hemen geçmeyin. Sorunlu bileşenin sürümünü, bağımlılıklarını ve uyumluluğunu inceleyin.

4. Temayı ve Son Kod Değişikliklerini Kontrol Edin​

Sorun tema güncellemesi veya functions.php düzenlemesi sonrasında başladıysa önce ilgili değişikliği geri alın.
Panele erişebiliyorsanız, kurulu ve WordPress sürümünüzle uyumlu bir resmî temayı geçici olarak etkinleştirin. Ardından aynı sayfayı kontrol edin.
Aktif tema klasörünü yeniden adlandırmanın her durumda otomatik geçiş sağlayacağını varsaymayın. WordPress’in geri dönüş yapabilmesi için uygun varsayılan temanın mevcut olması ve tema doğrulama sürecinin çalışabilmesi gerekir.
Yönetim paneline erişilemiyorsa, WP-CLI bulunan ortamlarda kurulu başka bir tema komut satırından etkinleştirilebilir. Bu işlem mevcut sitenin görünümünü değiştireceği için doğru tema klasörünün seçilmesi gerekir.
Child theme kullanıyorsanız hem child theme’i hem de ihtiyaç duyduğu ana temayı inceleyin.

5. Bellek Limitini Yalnızca Gerekliyse Düzenleyin​

Günlükte Allowed memory size ... exhausted mesajı varsa, işlem PHP’nin izin verdiği belleği aşmıştır.
PHP’nin memory_limit ayarı, bir betiğin ayırabileceği belleği sınırlar. Bu değer sunucunun toplam RAM’iyle aynı şey değildir.
WordPress tarafında örnek olarak şu tanımlar kullanılabilir:
Kod:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');
Mevcut tanımlar varsa onları düzenleyin. Bu değerler bütün siteler için zorunlu minimum değildir; ihtiyaç ve hosting sınırlarına göre belirlenmelidir.
WP_MEMORY_LIMIT genel işlemlerle, WP_MAX_MEMORY_LIMIT ise yönetim gibi daha fazla bellek isteyebilen işlemlerle ilişkilidir. Tanımlar, hostingin izin vermediği bir artışı zorla uygulayamaz.
Etkin PHP limitini doğrulayın. Limit yükselince hata kaybolsa bile anormal bellek tüketiminin nedenini araştırın. Sorunlu bir sorgu veya döngü, daha yüksek limiti de tüketebilir.

6. .htaccess Dosyasını Sunucu Türüne Göre İnceleyin​

.htaccess, bu dosyayı işleyen Apache gibi ortamlarda önemlidir. Nginx ise .htaccess kurallarını kullanmaz; ilgili yapılandırma başka yerde yönetilir.
Özellikle yakın zamanda bu dosyaya bir kural eklediyseniz:
  1. Mevcut dosyanın kopyasını alın.
  2. Önce son eklenen kuralı inceleyin.
  3. Gerekirse kısa süreli test için dosyayı yeniden adlandırın.
  4. Sonuca göre hatalı kuralı düzeltin veya dosyayı geri getirin.
Dosya; yönlendirme ve erişim koruması gibi özel kurallar içerebilir. Bu nedenle tamamını kaldırıp unutmayın. .htaccess dosyasının etkisi sunucu yapılandırmasına da bağlıdır.
Panel açılıyorsa Ayarlar → Kalıcı Bağlantılar üzerinden kaydetmek WordPress yönlendirme kurallarını yenilemeye yardımcı olabilir. Özel kurallarınızın ayrıca korunması gerekir.

7. Eksik veya Bozulmuş Çekirdek Dosyalarını Kontrol Edin​

Yarım kalmış güncelleme veya başarısız aktarım şüphesi varsa çekirdek dosyalarını inceleyin. Dosya yenileme işleminden önce tam yedek alın.
Teknik erişiminiz ve WP-CLI kurulumunuz varsa şu kontrol kullanılabilir:
wp core verify-checksums
Komut, çekirdek dosyalarını resmî sağlama toplamlarıyla karşılaştırır. Tema ve eklentilerin tamamı için kapsamlı güvenlik taraması yapmaz.
Dosyaları yeniden yüklemek gerekiyorsa sürümün tutarlı olduğundan emin olun. Aynı sürümü onarmak ile daha yeni sürüme geçmek ayrı işlemlerdir.
Manuel yenilemede yalnızca wp-admin ve wp-includes değil, kök dizindeki çekirdek dosyaları da değerlendirilmelidir. wp-content, wp-config.php ve özel dosyalar gelişigüzel silinmemelidir. WordPress’in resmî manuel güncelleme yönergesi bu ayrımları açıklar.

8. Hosting Desteğine Hangi Bilgileri Vermelisiniz?​

Önceki kontroller sonuç vermediyse sağlayıcıdan sunucu kayıtlarını incelemesini isteyin. “Site beyaz ekran veriyor” ifadesinin yanında şu bilgileri paylaşın:
  • Etkilenen adresler
  • Sorunun görüldüğü tarih, saat ve saat dilimi
  • Son yapılan değişiklik
  • Kullanılan WordPress ve PHP sürümü
  • Gizli bilgiler çıkarılmış hata kaydı
  • Denediğiniz işlemler ve sonuçları
Destekten PHP-FPM hataları, bellek nedeniyle sonlandırılan süreçler, disk alanı, izinler ve hesap kaynak sınırları gibi konuların kontrolünü isteyebilirsiniz.
Yeni hosting paketine geçmeyi veya kaynak yükseltmeyi, neden belirlenmeden kalıcı çözüm saymayın.

Sorun Çözüldükten Sonra Yapılacak Kontroller​

Ana sayfanın açılmasıyla yetinmeyin. Yönetici girişi, iletişim formu, arama, üyelik ve varsa ödeme akışını test edin.
Ardından:
  • Hata ayıklamayı kapatın.
  • Günlükleri güvenli şekilde kaldırın veya arşivleyin.
  • Gerekli önbellekleri temizleyin.
  • Geçici klasör adlarını kontrol edin.
  • Yapılan değişikliği ve çözümü kaydedin.
  • Yeni yedeğin başarıyla alındığını doğrulayın.
Birden fazla ayar aynı anda değiştirildiyse hangilerinin gerekli olduğunu yeniden değerlendirin.

Sıkça Sorulan Sorular​

Beyaz ekran, sitenin içeriğinin silindiği anlamına mı gelir?​

Tek başına böyle bir anlam taşımaz. Sayfa oluşturulamıyor olabilir. Dosya ve veritabanı durumunu ayrıca kontrol etmek gerekir.

Yönetim paneli açılıyor ama site boşsa nereden başlamalıyım?​

Son değişiklikleri ve hata kayıtlarını inceleyin. Tema, sayfa şablonu ve yalnızca ön yüzde çalışan bileşenlere odaklanın.

debug.log oluşmuyorsa ne yapmalıyım?​

Tanımları, dosya izinlerini ve günlük yolunu kontrol edin. Hostingin PHP kayıtlarına da bakın; hata WordPress günlük sistemi başlamadan önce oluşmuş olabilir.

Eklentileri kapatınca site açılırsa sorun kesin olarak tek eklenti midir?​

Eklenti katmanının sorunla ilişkili olduğunu gösterir. Tek bir bileşen, eklentiler arası etkileşim veya kaynak tüketimi araştırılmalıdır.

Belleği 512 MB yapmak her beyaz ekranı çözer mi?​

Hayır. Sözdizimi hatası, eksik dosya veya uyumsuzluk daha fazla bellekle düzelmez. Limiti hata kaydına göre değerlendirin.

Yedekten dönmek en hızlı çözüm mü?​

Temiz ve çalışan bir yedek yardımcı olabilir. Ancak geri dönüş tarihinden sonraki içerikler ve siparişler kaybolabilir. Veri kaybını ve sorunun tekrar etme ihtimalini birlikte değerlendirin.
 

Benzer Konular

3 konu
Geri
Üst