WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür?

WordPress beyaz sayfa hatası (WSOD – White Screen of Death), sitenin hem ön yüzünü hem de yönetici panelini boş bir beyaz sayfaya dönüştüren, panik yaratan ancak çoğu zaman 5-10 dakikada çözülebilen klasik bir hatadır. Bu rehber, hatayı teşhis etmekten geri dönüş planına kadar uçtan uca ele alır; staging ortamı olmayan küçük sitelerden yüksek trafikli kurumsal WP’lere kadar aynı temel adımları izler.

Bu yazıdaki adımlar wp-config.php, .htaccess, wp-content/ ve PHP hata loglarını düzenleme yetkisi olan, en az 2 kez WSOD yaşamış ve çözmüş bir geliştiricinin deneyiminden derlenmiştir.

WordPress beyaz sayfa hatası: PHP Hatası ve Hata Ayıklama

Beyaz sayfa hatasının %70’i PHP seviyesinde bir ölümcül hatadan (fatal error) kaynaklanır. PHP, varsayılan olarak kritik hataları tarayıcıya yazdırmaz, sadece boş sayfa döner. Bu nedenle ilk adım her zaman hata raporlamayı açmaktır.

wp-config.php dosyasını FTP veya hosting dosya yöneticisi ile açın ve /* That's all, stop editing! Happy publishing. */ satırının hemen üstüne şu 3 satırı ekleyin:

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

Bu 3 sabit sırasıyla: hata raporlamayı açar, hataları /wp-content/debug.log dosyasına yazar, ekranda göstermez (kullanıcıların hata mesajı görmesini engeller). Tarayıcıyı yenilediğinizde hâlâ beyaz sayfa görüyorsanız ama debug.log dosyası içerik kazandıysa, sorunun köküne ulaşmışsınız demektir.

Log dosyasında sıklıkla karşılaşılan 4 tip hata vardır:

• Out of memory (Bellek yetersiz). Allowed memory size of 134217728 bytes exhausted mesajı görünür. Çözüm: wp-config.php‘ye define('WP_MEMORY_LIMIT', '256M'); satırı ekleyin veya hosting sağlayıcınızdan PHP bellek limitini artırmasını isteyin.
• Undefined function (Tanımsız fonksiyon). Bir eklenti veya tema, mevcut olmayan bir PHP fonksiyonunu çağırıyor demektir. Genellikle eklenti PHP sürümü uyumsuzluğu veya eklentinin tam yüklenmemiş olmasından kaynaklanır.
• Parse error (Sözdizimi hatası). functions.php veya bir eklenti dosyasında PHP kodlama hatası var demektir. Sıklıkla manuel kod düzenlemesi sonrası, eksik noktalı virgül veya yanlış kapanan süslü parantez nedeniyle oluşur.
• Cannot redeclare (Yeniden bildirim). Aynı fonksiyon iki kez tanımlanmaya çalışılıyor. Genellikle iki eklentinin aynı kütüphaneyi farklı isimle yüklemesinden kaynaklanır; birinin devre dışı bırakılması çözüm olabilir.

Debug.log dosyasını okumak için SSH erişiminiz varsa tail -f wp-content/debug.log komutu, dosya yöneticiniz varsa dosyayı doğrudan açabilirsiniz. Hata mesajındaki dosya yolu ve satır numarası, sorunun hangi dosyada olduğunu doğrudan gösterir.

Eklenti ve Tema Çakışma Kontrolü

Eğer debug.log dosyasında wp-content/plugins/ veya wp-content/themes/ ile başlayan bir hata varsa, sorun bir eklenti veya temadadır. Çakışma kaynağını izole etmek için tüm eklentileri geçici olarak devre dışı bırakın.

Ancak WP-Admin’e erişemiyorsanız, eklentileri dosya sistemi üzerinden devre dışı bırakmanız gerekir. FTP veya dosya yöneticisi ile /wp-content/ klasörüne gidin ve plugins klasörünün adını plugins_disabled olarak değiştirin. Bu, WP’nin tüm eklentileri tek seferde devre dışı bırakmasını sağlar. Site normale döndüyse sorun bir eklentidedir; eski haline getirip plugins klasörünün içine girerek eklentileri teker teker devre dışı bırakarak hangisinin suçlu olduğunu bulun.

Eklenti çakışması olmadığını tespit ettiyseniz, sıra temadadır. Aynı yöntemle wp-content/themes/ klasörüne gidin ve aktif temanın klasör adını değiştirin. WP otomatik olarak son çalışan temaya (örn. Twenty Twenty-Four) geri döner. Site normale döndüyse sorun temanızdır; tema dosyalarını son güncellemeden önceki yedeğe döndürmeniz veya tema sağlayıcınızla iletişime geçmeniz gerekir.

Çakışma bulma sürecinde sıklıkla yapılan 3 hatadan kaçının:

1. Tüm eklentileri aynı anda geri açmayın. Sorunu bulamazsınız. Her seferinde bir eklenti açıp site kontrol edin.
2. Cache eklentilerini son sıraya bırakın. WP Super Cache, W3 Total Cache gibi önbellek eklentileri pasif olsa bile disk üzerinde eski HTML dosyaları bırakabilir. Test sırasında wp-content/cache/ klasörünü de temizleyin.
3. Staging ortamı kullanmadan production’da deneme yapmayın. Eğer hosting sağlayıcınız staging desteği sunuyorsa, sorunu orada çözüp hazır çözümü canlıya uygulayın.

WP_DEBUG ve .htaccess Çözümleri

Wp Debug Htaccess Cozumleri

Bazı WSOD vakaları PHP hatasından değil, web sunucusu tarafında oluşur. Apache .htaccess dosyası bozulmuş, nginx rewrite kuralları çakışıyor veya PHP-FPM havuzu tükenmiş olabilir. Bu durumda wp-config.php hata raporlaması hiçbir şey göstermez çünkü hata PHP’ye ulaşmadan web sunucusu tarafından döndürülür.

Apache kullanıyorsanız .htaccess dosyasını geçici olarak yeniden adlandırın (örn. .htaccess.bak) ve siteye erişmeyi deneyin. WP, kök dizinde .htaccess bulamazsa otomatik olarak yeni bir tane oluşturur. Site normale döndüyse eski .htaccess dosyanızdaki kuralların bir kısmı bozuk demektir. WP’nin oluşturduğu yeni dosyayı temel alarak, eski dosyanızdaki özel kuralları (SSL yönlendirmesi, www -> www dışı yönlendirmesi, gzip, expires headers) teker teker geri ekleyin ve her ekleme sonrası site kontrolü yapın.

PHP sürüm uyumsuzluğu da sıklıkla gözden kaçar. WP 7.0, PHP 8.1+ gerektirir; eski sürümlerde ise PHP 7.4+ yeterlidir. Eğer yakın zamanda PHP sürümü güncellendiyseniz ve hemen ardından beyaz sayfa hatası aldıysanız, sorun PHP sürümü olabilir. Hosting kontrol panelinden (cPanel, Plesk veya özel panel) PHP sürümünü önceki kararlı sürüme (örn. 8.2’den 8.1’e) geri alıp test edin.

Son olarak, geri dönüş planı her zaman hazır olmalıdır. Her WP yükseltmesi, tema güncellemesi veya büyük eklenti değişikliği öncesinde:

• Veritabanını wp-cli ile veya phpMyAdmin üzerinden dışa aktarın.
• /wp-content/ klasörünün tam yedeğini alın (upload dizini büyük olabilir, sadece uploads/ ve themes/ da yeterli olabilir).
• wp-content/debug.log dosyasının temiz olduğundan emin olun; mevcut hatalar yeni hatalarla karışır.
• Yedekten geri dönüş süresini test edin. Yedek aldığınız sisteme gerçekten güvenebilmek için, staging’de bir kez geri yükleme testi yapın.

WordPress beyaz sayfa hatası için pratik kontrol listesi

WordPress beyaz sayfa hatası konusunda uygulamaya geçmeden önce mevcut yedeği doğrulayın, değişikliği küçük adımlarla test edin ve sonucu canlı sitede tekrar kontrol edin. Benzer konular için WordPress eklenti çakışması ve WordPress admin paneli yavaşlığı rehberlerine de bakabilirsiniz. Resmi kaynak olarak WordPress hata ayıklama dokümantasyonu sayfasını incelemek faydalı olur.

Sonuç

WordPress beyaz sayfa hatası, ilk bakışta çözümsüz görünür ancak sistematik bir yaklaşımla 10 dakika içinde kaynağına ulaşılabilir. Önce debug.log’u açın, sonra eklentileri, sonra temayı, sonra .htaccess’i test edin. Her adımda bir değişiklik yapıp siteye erişmeyi deneyin; sorunu izole etmenin en hızlı yolu budur. Geri dönüş planınız yoksa büyük değişiklik yapmayın; staging ortamı yoksa en azından bakım moduna alarak kullanıcıların boş sayfa görmesini engelleyin.

WordPress Beyaz Sayfa İçin Pratik Özet Tablosu

Aşağıdaki tablo, WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür konusunda hızlı karar vermeniz için temel kontrolleri özetler. Önce belirtiyi bulun, ardından önerilen aksiyonu uygulayın.

WordPress Beyaz Sayfa İçin Ek SEO ve Bakım Notları

WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür konusu yalnızca tek seferlik bir ayar gibi düşünülmemelidir. WordPress, Laravel, WooCommerce veya özel PHP projelerinde yapılan her teknik değişiklik zaman içinde yeni eklenti sürümleri, tema güncellemeleri ve hosting yapılandırmalarıyla yeniden etkilenebilir.

Bu nedenle uygulama sonrasında kısa bir takip planı oluşturmak önemlidir. İlk gün temel fonksiyonları test edin. İlk hafta hata kayıtlarını ve kullanıcı geri bildirimlerini izleyin. İlk ay sonunda ise Search Console performansı, indeks durumu ve organik trafik değişimini karşılaştırın.

Eğer değişiklikten sonra sorun tekrar ediyorsa, aynı işlemi defalarca uygulamak yerine kök nedeni arayın. Sunucu logları, eklenti çakışmaları, PHP sürümü, veritabanı bağlantısı ve cache katmanı birlikte değerlendirilmelidir. Böylece geçici çözüm yerine kalıcı bir bakım rutini oluşturabilirsiniz.

SSS: WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür

WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür için ilk kontrol ne olmalı?
Önce sorunun kapsamını belirleyin. Sadece tek sayfada mı, tüm sitede mi, yoksa belirli kullanıcı veya cihazlarda mı göründüğünü kontrol edin.

Bu işlem SEO performansını etkiler mi?
Evet, teknik sorunlar kullanıcı deneyimini ve tarama kalitesini etkileyebilir. Bu nedenle değişiklikten sonra Search Console verilerini takip etmek gerekir.

Canlı sitede işlem yapmadan önce yedek almak gerekir mi?
Kesinlikle gerekir. Dosya ve veritabanı yedeği olmadan yapılan canlı değişiklikler, küçük bir hatada geri dönüşü zorlaştırabilir.

Değişiklikten sonra cache temizlemek şart mı?
Çoğu durumda evet. WordPress cache eklentisi, CDN ve tarayıcı cache’i eski çıktıyı göstermeye devam edebilir.

Sorun devam ederse nasıl ilerlemeliyim?
Son yapılan değişikliği geri alın, hata loglarını kontrol edin ve eklenti/tema çakışmasını izole edin. Gerekirse küçük adımlarla yeniden test edin.