Performans

WordPress Beyaz Ekran Hatası (WSoD): Nedenleri ve Adım Adım Çözüm Rehberi

19 Nisan 2026 No comments yet
WordPress beyaz ekran hatası (WSoD) kapak görseli

Bir kahve molasından döndünüz. Tarayıcıyı açıp sitenizi yenilediniz. Ama sitenizin olması gereken yerde bembeyaz, bomboş bir sayfa var, ne başlık, ne menü, ne içerik, hatta bir hata mesajı bile yok. Sadece rahatsız edici bir sessizlik. Bu tabloyu ilk kez gören çok insan için kabus gibidir ve genelde tek bir adla anılır: WordPress beyaz ekran hatası (WSoD – White Screen of Death).

İyi haber şu: Görünüşünün aksine bu hata neredeyse her zaman geri döndürülebilir. Veritabanınız yerindedir, içeriğiniz yerindedir, tasarımınız yerindedir. Sorun çoğu zaman PHP tarafında yaşanan tek bir ölümcül hatadan ibarettir ve doğru yerden bakarsanız birkaç dakika içinde kaynağını bulursunuz.

Bu rehberde beyaz ekran hatasıyla karşılaştığınız ilk 5 dakikada ne yapacağınızı, hangi araçlarla kaynağı tespit edeceğinizi, hangi eklentinin ya da temanın suçlu olduğunu nasıl anlayacağınızı ve aynı sorunun tekrar etmesini nasıl engelleyeceğinizi anlatacağım. Konu, WordPress’in günlük bakımıyla da ilgili olduğu için yer yer uzun vadeli önlemlere de değineceğim.

İçindekiler

Beyaz Ekran Hatası Nedir?

Beyaz Ekran Hatası, literatürde White Screen of Death (WSoD) olarak geçer. Ziyaretçi sitenize geldiğinde, tarayıcı boş bir pencere çizer; HTTP tarafında dönen kod 200 da olabilir 500 de, ama kullanıcının gördüğü tek şey masmavi yerine masbeyaz bir hiçliktir.

Teknik olarak neredeyse her durumda arka planda bir PHP ölümcül hatası (fatal error) gerçekleşmiştir. WordPress çıktıyı oluşturmadan önce çağrılan bir fonksiyon patlamış, çıktı tamponu (output buffer) temizlenmiş ve sunucu istemciye boş bir gövde göndermiştir. Tarayıcı o boşluğu beyaz bir arka planla doldurur, WSoD’nin o meşhur “görsel sessizliği” buradan gelir.

Burada anlaşılması gereken en önemli şey şudur: WSoD bir belirtidir, bir hastalık değil. “Beyaz ekran geldi” demek, “kafam ağrıyor” demeye benzer. Aynı belirtinin ardında onlarca farklı sebep olabilir. O yüzden tedaviye geçmeden önce teşhis etmek zorundayız.

WSoD’nin En Sık Görülen 8 Nedeni

Kaynak tespiti, çözümün yarısıdır. Aşağıda size en sık rastladığım nedenleri sıkılık sırasına göre listeledim. Sitenizde son 24 saatte hangi değişiklik yapıldıysa, muhtemelen suçlu o listede.

1. Eklenti Çakışması veya Bozuk Güncelleme

Vakaların yaklaşık yarısı buradan çıkar. WordPress eklentileri birbiriyle iletişim kurar; biri bir diğerinin beklediği bir fonksiyonu kaldırırsa ya da yeni bir sürüm PHP tarafından desteklenmeyen bir sözdizimi kullanırsa, beyaz ekran kaçınılmaz olur. En sık yaşadığım çakışmalar: cache eklentisi ile güvenlik eklentisi, optimizasyon eklentisi ile sayfa oluşturucu (Elementor, Divi, Beaver Builder), WooCommerce ile kargo/ödeme eklentileri.

2. Tema Sorunu

Yeni bir tema kurduktan ya da mevcut temayı güncelledikten sonra site beyaz kaldıysa, şüpheli konu temadır. Özellikle çocuk temalarda (child theme) yanlış bir kancayı (hook) referans etmek, ana temanın olmayan bir işlevini çağırmak ya da functions.php‘de küçük bir sözdizimi hatası, tüm siteyi anında yere serer.

3. PHP Bellek Sınırı (Memory Limit)

WordPress varsayılan olarak 40MB civarında bellek kullanır. Ağır bir eklenti seti, büyük bir WooCommerce kataloğu, bir yedekleme işlemi ya da yoğun trafik bu limiti aşabilir. Limit aşıldığında PHP “Allowed memory size exhausted” hatası verir ve çoğu zaman ekrana hiçbir şey basmaz.

4. Bozuk WordPress Çekirdek Dosyaları

Yarıda kesilen bir yükseltme, başarısız dosya transferi ya da kötü amaçlı bir müdahale wp-admin veya wp-includes klasörlerindeki kritik dosyaları bozabilir. Çekirdek eksikse WordPress ne admin panele ne önyüze sağlıklı bir cevap döndürebilir.

5. PHP Sürüm Uyumsuzluğu

WordPress 6.x için resmi olarak önerilen PHP sürümü 8.1 veya 8.2’dir. Barındırıcınız hâlâ PHP 7.4 sunuyorsa ya da eklentilerinizden biri PHP 8.2’de kaldırılmış bir işlevi kullanıyorsa, belirli sayfalarda ya da tüm sitede WSoD başlar.

6. Veritabanı Bağlantı Sorunu

wp-config.php‘deki MySQL bilgileri yanlış, veritabanı sunucusu çalışmıyor ya da eş zamanlı bağlantı sınırı aşılmış, bu üç durumdan biri sitenizi beyaz ekrana (veya klasik “Error establishing a database connection” mesajına) düşürür.

7. .htaccess Bozukluğu

Özellikle Apache sunucularda bozuk bir .htaccess kuralı tüm siteyi erişilemez kılar. Güvenlik eklentilerinin, cache eklentilerinin ve bazı barındırıcı otomasyonlarının bu dosyaya yazdığını unutmayın; kural satırlarından biri çakıştığında WSoD gelir.

8. Kötü Amaçlı Yazılım / Hack

Zararlı kod yerleştirilmiş bir eklenti, tema ya da çekirdek dosyası yürütüldüğünde ölümcül hata fırlatabilir. Eğer son dönemde şüpheli bir girişim yaşadıysanız, konuya daha geniş bir açıdan bakmak gerekebilir. Bu senaryoda WordPress sitem hacklendi rehberimize de bir göz atın.

Hızlı Tanı: Sorun Gerçekten WSoD mu?

Dalmadan önce 30 saniye düşünelim. Aşağıdaki senaryolar ilk bakışta “beyaz ekran” gibi görünür ama tedavileri birbirinden farklıdır:

  • Tamamen beyaz ve hiçbir hata mesajı yok: Klasik WSoD. PHP hata ayıklama kapalı.
  • Beyaz ekranda “HTTP 500” yazısı: 500 Internal Server Error. Aynı ailede ama ipucu daha net.
  • “Error establishing a database connection” mesajı: Veritabanı bağlantı sorunu, WSoD’ye dalmadan önce DB’yi kontrol edin.
  • “There has been a critical error on this website”: WordPress 5.2+ sürümlerinde WSoD’nin “insanileştirilmiş” versiyonudur. Altındaki hata aynıdır.
  • Admin paneli açılıyor ama önyüz beyaz: Genellikle tema veya ön yüzde çalışan bir eklenti.
  • Önyüz açılıyor ama admin paneli beyaz: Yalnızca admin tarafında etkinleşen bir eklenti.

Sorunun hangi tarafta (yönetici mi, önyüz mü) yaşandığını bilmek, hangi adıma öncelik vereceğinizi doğrudan belirler. Bu yüzden tanıyı atlayıp çözüme koşmak genelde zaman kaybına yol açar.

Adım 1: Hata Ayıklamayı Açın (WP_DEBUG)

Bir şeyi düzeltmenin ilk kuralı: onu görmek. WordPress’in hata ayıklama modunu açarak perdenin ardında gerçekten ne olduğunu görelim.

FTP, SFTP ya da hosting panelindeki dosya yöneticisi üzerinden wp-config.php dosyanızı açın. “That’s all, stop editing! Happy publishing.” satırının üzerine şu üç satırı ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
wp-config.php dosyasında WP_DEBUG ve WP_DEBUG_LOG tanımları
wp-config.php içine üç satır ekleyerek hataları debug.log dosyasına yazdırın; ekrana bastırmayın.

Kaydedin ve siteyi yenileyin. Artık hatalar ekrana basılmayacak (güvenlik için önemli) ama /wp-content/debug.log dosyasına yazılacak. Bu dosyayı açtığınızda hatanın tam olarak hangi dosyanın kaçıncı satırında oluştuğunu göreceksiniz.

Örnek çıktı:

PHP Fatal error: Uncaught Error: Call to undefined function WC() in
/home/user/public_html/wp-content/plugins/wc-extension/main.php on line 47

Bu tek satırda aradığımız her şey var: hatanın türü (Call to undefined function), sorunlu dosya ve satır numarası. Kaynağı aslında bu aşamada çoğu zaman tespit etmiş oluyoruz. Kalan adımlar, problemi güvenli şekilde izole edip düzeltmek üzerine.

“Neden WP_DEBUG_DISPLAY‘ı false‘a çeviriyoruz?” Çünkü PHP hatalarını ziyaretçilere göstermek ciddi bir güvenlik riskidir. Hata mesajları sunucu dosya yollarını, hatta bazen veritabanı kullanıcı adlarını ifşa edebilir. Log’a yazıp ekranda saklamak en temiz yoldur.

Adım 2: Tüm Eklentileri Hızlıca Devre Dışı Bırakın

Admin paneline giremiyorsanız, FTP ile eklentileri toplu olarak devre dışı bırakabilirsiniz. İşlem çok basit:

  1. FTP/SFTP ile sitenize bağlanın.
  2. /wp-content/plugins/ klasörünün adını plugins-off (ya da aklınıza gelen herhangi bir şey) olarak değiştirin.
  3. Siteyi yeniden yükleyin.

WordPress bu durumda eklentileri bulamaz ve hepsini “aktif değil” sayar. Site açılıyorsa sorun bir eklentide. Şimdi kritik adım: klasörün adını geri alın (plugins). Ardından içindeki her eklenti klasörünü tek tek yeniden adlandırarak devre dışı bırakın. Her adımda siteyi yenileyin. Hangi eklentiyi devre dışı bıraktığınızda site açılıyorsa, suçlu odur.

Daha hızlı bir yol: Adım 1’de açtığınız debug.log‘da eklenti adı zaten görünüyorsa, doğrudan o klasörü devre dışı bırakın. İkili arama yapmanıza gerek yok.

Sorunlu eklentiyi bulduktan sonra üç seçeneğiniz var: alternatifine geçmek, bir önceki sürüme dönmek ya da eklenti geliştiricisine sorunu bildirip güncelleme beklemek. Hangi seçenek olursa olsun, o eklentinin en son çalıştığı versiyonu bir yere not etmek iyi bir alışkanlıktır.

Adım 3: Varsayılan Bir Temaya Geçin

Sorun eklentide değilse, sıra temaya geldi. Aynı mantıkla /wp-content/themes/ klasörüne gidin ve aktif temanızın klasör adını değiştirin. WordPress otomatik olarak hazır bulunan varsayılan bir temaya (Twenty Twenty-Four, Twenty Twenty-Five vb.) düşecektir.

Hiçbir varsayılan tema kurulu değilse, tr.wordpress.org/themes adresinden Twenty Twenty-Four’ü indirip FTP ile themes klasörüne atın. WordPress bu temayı görür görmez otomatik olarak aktifleştirir.

Site varsayılan temada açılıyorsa, suçlu kendi temanızdır. Özellikle şu yerlere bakın:

  • functions.php‘de en son eklediğiniz kod bloğu (yorum satırına alıp test edin).
  • Çocuk temada referans verilen, ana temada silinmiş işlevler.
  • Tema güncellemesi sonrası değişen dosya yapısı.
  • Özel olarak geliştirilmiş bir temaysa, geliştiricinin son commit’i.

İpucu: functions.php‘ye kod eklerken en sona değil, kapama etiketinden (?>) hemen önce eklemeyi ve bir önceki halini yedeklemeyi alışkanlık haline getirin. Bir satırlık sözdizimi hatası, bir haftalık iş üretirken zamanınızı birkaç saat geri yemeye yeter.

Adım 4: Bellek Limitini Artırın

Debug log’una baktığınızda “Allowed memory size of 41943040 bytes exhausted” gibi bir mesajla karşılaşıyorsanız, sorun bellektedir. wp-config.php dosyanıza şu iki satırı ekleyin:

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

İlk satır önyüz için, ikincisi admin paneli (özellikle içerik düzenleyici ve medya yükleme) için geçerlidir. Paylaşımlı hostinglerde bu değer hosting seviyesinde dayatılıyor olabilir; bu durumda değerler sembolik kalır.

Apache kullanıyorsanız kök dizindeki .htaccess‘e şu satırı da ekleyebilirsiniz:

php_value memory_limit 256M

Ya da php.ini düzenleme izniniz varsa doğrudan memory_limit = 256M satırını güncelleyin. Bunların hiçbirine erişiminiz yoksa hosting destek ekibine yazıp PHP bellek sınırının yükseltilmesini isteyin; saygın barındırıcılar bu talebi genelde aynı gün içinde karşılar.

Bellek sınırı konusu yalnızca WSoD’yi değil, site performansını da doğrudan etkiler. Daha geniş bir bakış için Core Web Vitals rehberimize göz atabilirsiniz, özellikle LCP ve FID puanları düşükse, çoğunlukla kökeninde benzer kaynak kısıtları yatar.

Adım 5: WordPress Çekirdeğini Yenileyin

Log dosyasında hatanın WordPress çekirdek dosyalarında oluştuğu görünüyorsa (özellikle wp-includes veya wp-admin altındaki dosyalar), çekirdeği sıfırlamanız gerekir. Endişelenmeyin, doğru yaparsanız içerik kaybı riski yoktur.

  1. tr.wordpress.org/download adresinden son sürümü indirin.
  2. ZIP arşivini açın.
  3. FTP yoluyla wp-admin ve wp-includes klasörlerini sunucudaki karşılıklarının üzerine yazın.
  4. Kök dizindeki index.php, wp-login.php, wp-load.php gibi PHP dosyalarını da yenileyin.
  5. Asla wp-content klasörüne ve wp-config.php dosyasına dokunmayın, içeriğiniz, ayarlarınız ve veritabanı bağlantınız oradadır.

Bu adım, güncelleme sırasında yarıda kalmış ya da bozulmuş çekirdek dosyaların büyük çoğunluğunu onarır. Çekirdek yenilendiğinde debug.log’da bu tür hataların kaybolduğunu göreceksiniz.

Adım 6: .htaccess Dosyasını Yenileyin

Bozuk bir .htaccess kuralı, eklentilerin ya da manuel düzenlemelerin artıklarıyla dolmuş olabilir. Kök dizindeki .htaccess dosyasının tamamını temizleyin ve yerine standart WordPress kurallarını yazın:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Kaydedin ve siteyi yenileyin. Güvenlik eklentileri ya da cache eklentileri kendi kurallarını sonradan yeniden yazacaktır; o kurallar gerçekten gerekiyorsa hemen geri ekleyebilirsiniz, ama büyük olasılıkla yıllar içinde birikmiş ve artık hiçbirinin ne iş yaptığını hatırlamadığınız onlarca satırdan kurtulmuş olursunuz.

Adım 7: PHP Sürümünü Kontrol Edin

Hosting paneline (cPanel, Plesk, DirectAdmin, hPanel, Cloudways dashboard vb.) girip PHP sürümünüzü kontrol edin. WordPress 6.x için önerilen aralık PHP 8.1 – 8.2’dir.

  • PHP 7.4 veya daha eski: Mutlaka güncelleyin. Artık resmi destek almıyor, güvenlik açısından risk.
  • PHP 8.3 veya 8.4: Çok yeni olduğu için bazı eklentiler ve temalar henüz tam uyumlu olmayabilir. 8.1 veya 8.2’ye düşürmek sorununuzu çözebilir.
  • PHP 8.1 – 8.2: WordPress ve çoğu popüler eklenti için tatlı nokta.

PHP sürüm değiştirme menüsünden seçim yaptıktan sonra değişikliğin etkili olması birkaç saniye sürer. Ardından siteyi yenileyin. PHP kaynaklı bir WSoD varsa çoğu zaman bu adımda çözülür.

Adım 8: Sunucu Hata Kayıtları

WordPress’in hiç haberi olmayan hatalar da vardır, çünkü sorun WordPress çalışmaya başlamadan önce oluşmuştur. Bu tür hatalar için sunucu hata log’una bakmalısınız.

Barındırıcınıza göre yeri değişir:

  • cPanel: Metrics → Errors veya File Manager’da error_log dosyası.
  • Plesk: Domains → Logs.
  • VPS/Sunucu (Apache): /var/log/apache2/error.log ya da /var/log/httpd/error_log.
  • VPS/Sunucu (Nginx): /var/log/nginx/error.log.
  • Cloudways / LiteSpeed: Hosting paneli içinden “Error Logs” menüsü.

Bu log’larda PHP-FPM çökmesi, disk doluluğu, maksimum işlem sayısı limiti, SSL sertifikası hatası gibi konular görülebilir. Özellikle “too many connections” veya “disk quota exceeded” gibi satırlar gördüyseniz, soruna teknik olarak değil ticari olarak yaklaşmanız gerekir: hosting paketiniz büyümüş sitenize yetmiyor demektir.

Sunucu seçimi bu noktada kritiktir. Doğru paketle başlamak bu tür problemleri aylarca geciktirebilir; daha geniş bir değerlendirme için WordPress için en uygun hosting seçimi rehberimize bakabilirsiniz.

İleri Düzey: Recovery Mode (WordPress 5.2+)

WordPress 5.2 sürümünden itibaren “ölümcül hata koruma modu” diye bir özellik var. Bir eklenti ya da temada fatal error oluştuğunda, WordPress olayı yakalar, ziyaretçilere “There has been a critical error on this website” yazar ve site yöneticisinin e-posta adresine özel bir giriş linki gönderir.

Bu bağlantıya tıkladığınızda WordPress sizi Recovery Mode‘a sokar:

  • Admin paneli hatalara rağmen çalışır hale gelir.
  • Hatalı eklenti veya tema otomatik olarak işaretlenir.
  • Devre dışı bırakabilir, güncelleyebilir, silebilirsiniz.
  • İşlem bitince normal moda dönersiniz.

E-posta gelmiyorsa iki olası neden var: birincisi, Ayarlar → Genel’deki yönetici e-postası güncel değildir; ikincisi, sitenizin SMTP gönderimi düzgün çalışmıyordur. WP Mail SMTP gibi bir eklenti ile mail yapılandırmasını düzgün kurmak, Recovery Mode’u da çalışır hale getirir.

Sık Rastlanan Özel Durumlar

Güncelleme Sonrası Beyaz Ekran

WordPress güncellemesi yarıda kesildiğinde kök dizinde .maintenance adlı bir dosya takılı kalabilir. Bu dosyayı silin, site normale döner. Daha uzun süredir açıksa güncelleme yarıda kalmış demektir; Adım 5’teki çekirdek yenileme işlemini yapın.

Elementor Kaydetmiyor / Tasarımcı Beyaz Kalıyor

Elementor’un en sık şikayeti budur ve neredeyse her zaman bellek sınırından ya da PHP max_input_vars değerinden kaynaklanır. wp-config.php‘ye define( 'WP_MEMORY_LIMIT', '256M' ); ekleyin, ardından .htaccess veya php.ini‘de max_input_vars = 3000 değerini ayarlayın.

WooCommerce Güncellemesi Sonrası Beyaz Ekran

WooCommerce güncellendiğinde temanız eski WooCommerce şablonlarını override ediyorsa (/themes/xxx/woocommerce/ klasörü), bu şablonlar uyumsuz kalır. Geçici olarak o klasörü yeniden adlandırın, WooCommerce kendi güncel şablonlarını devreye alır, site açılır. Ardından şablonları yeni sürüme göre manuel güncelleyin.

Admin Paneli Açılıyor, Önyüz Beyaz

Neredeyse her zaman ön yüz eklentisi ya da tema suçludur. Önce temayı varsayılana çevirin. Çözülmezse sırasıyla cache, CDN, optimizasyon eklentilerini devre dışı bırakın.

Önyüz Açılıyor, Admin Paneli Beyaz

Suçlu, admin tarafında çalışan bir eklentidir. FTP ile /wp-content/plugins/ içindeki klasörleri tek tek devre dışı bırakın. Genelde form eklentileri, SEO eklentileri ya da özel yapılmış admin paneli eklentileri suçlu çıkar.

“There has been a critical error” Yazısı Geliyor

Bu, modern WordPress’in WSoD versiyonudur. Teknik olarak aynı olay. Yönetici mail kutunuza gelen recovery linkine bakın; bulamıyorsanız yukarıdaki sekiz adımı sırayla uygulayın.

Kalıcı Önleyici Tedbirler

WordPress beyaz ekran hatasından korunmak için önleyici tedbir listesi
Beyaz ekran riskini düşüren yedi maddelik kontrol listesi.

Tek seferlik çözüm güzeldir ama ikinci kez aynı sorunla uğraşmamak daha da güzeldir. Uzun vadede WSoD ile ömür boyu tanışmamak için şu alışkanlıkları yerleştirmek fark yaratır:

  1. Otomatik yedekleme: UpdraftPlus, BlogVault, Solid Backups gibi araçlar her güncellemeden önce yedek alır. Bir şeyler ters giderse 10 dakikada eski duruma dönersiniz.
  2. Staging ortamı: Canlı sitede asla güncelleme yapmayın. Klon bir ortamda güncelleyin, test edin, sonra canlıya taşıyın. Çoğu saygın hosting bu özelliği ücretsiz sunar.
  3. Eklenti diyeti: Gerçekten kullanmadığınız her eklentiyi silin. “İhtiyacım olur belki” diye bekletilen eklentiler hem güvenlik yüzeyini büyütür hem de çakışma olasılığını artırır.
  4. Tutarlı bellek sınırı: Yeni kurulumlarda bile WP_MEMORY_LIMIT değerini başlangıçta 256M’e sabitleyin. İleride kendinize teşekkür edeceksiniz.
  5. PHP / MySQL takibi: Yeni kritik sürümler çıktığında haberdar olmak için barındırıcınızın duyuru listesine kaydolun. Aniden zorunlu PHP yükseltmesi geldiğinde hazırlıksız yakalanmamak çok önemli.
  6. Uptime izleme: UptimeRobot, Better Uptime, StatusCake gibi servisler sitenizi her dakika kontrol eder. WSoD oluştuğu anda telefonunuza bildirim düşer, ziyaretçilerden önce siz haberdar olursunuz.
  7. Düzenli bakım: Her ay sitenin güncel olup olmadığını, kullanılmayan eklentilerin temizlenip temizlenmediğini, yedeğin çalıştığını kontrol eden bir rutin kurun. Ya da bu işi profesyonel bir ekibe bırakın.

Bakım Yükünü Üzerinizden Almak

Yukarıdaki adımların çoğu teknik bilgi gerektirir ve üretimdeki bir sitede yanlış bir komut ciddi zaman kaybına yol açabilir. WPNeta WordPress Bakım Paketi, bu tür sorunların büyük kısmını daha oluşmadan yakalar: haftalık yedekler, PHP ve eklenti uyumluluk kontrolleri, güvenlik taramaları, 7/24 uptime izleme ve bir sorun çıktığında ekibimizin anında müdahale etmesi ile sitenize gözetmen bir ekip kazandırır. Beyaz ekran yerine beyaz plaj fotoğrafı çekmek için güzel bir bahane.

Sonuç

WordPress beyaz ekran hatası ilk bakışta “sitem çöktü” izlenimi verse de, neredeyse her zaman geri döndürülebilir bir problemdir. Sırasıyla hata ayıklamayı açmak, eklenti ve temayı test etmek, bellek limitini yükseltmek ve çekirdeği yenilemek, karşılaşılan vakaların büyük çoğunluğunu çözer. Önemli olan sonraki adımı panik içinde değil, metodik olarak atmaktır.

Bir tavsiye olarak şunu bırakayım: debug.log‘u okumadan hiçbir müdahale yapmayın. Kaynak belli olmadan yapılan deneme-yanılma işlemleri çoğu zaman sorunu çözmek yerine yeni sorunlar çıkarır. Beş dakika log okuyup 10 dakikada çözmek, iki saat sürüklenip üç yeni sorun yaratmaktan çok daha iyidir.

Sıkça Sorulan Sorular

WordPress beyaz ekran hatası verilerimi siler mi?

Hayır. WSoD’nin kendisi veri kaybına yol açmaz; site geçici olarak görüntülenemez hale gelir, veritabanı ve dosyalar yerinde kalır. Yine de müdahale etmeden önce tam bir yedek almak altın kuraldır, özellikle çekirdek yenileme ya da .htaccess düzenleme gibi adımlara geçmeden önce.

Admin paneline giremiyorum, nasıl devam edebilirim?

FTP ya da hosting panelinin dosya yöneticisi üzerinden /wp-content/plugins/ klasörünün adını değiştirin. WordPress eklentileri bulamaz, hepsini devre dışı sayar ve büyük olasılıkla admin paneli açılır. Sonra klasör adını geri alıp eklentileri tek tek etkinleştirerek suçluyu bulabilirsiniz.

WP_DEBUG’ı canlı sitede açık bırakmak güvenli mi?

WP_DEBUG_DISPLAY = false olarak açık bırakırsanız ziyaretçiler hatayı görmez, sadece log’a yazılır. Yine de uzun süre canlıda tutmamanızı öneririm; sorun çözüldükten sonra üç satırı da kapatın. Debug modu küçük bir performans maliyeti de getirir.

Tüm eklentileri devre dışı bıraktım ama site hâlâ beyaz. Şimdi ne yapmalıyım?

Sırada tema ve sunucu seviyesi kontrol geliyor. Önce temayı varsayılana çevirin (Adım 3). O da çözmezse PHP sürümü (Adım 7), bellek limiti (Adım 4), .htaccess (Adım 6) ve sunucu error log’una (Adım 8) bakın. Her durumda debug.log‘u mutlaka kontrol edin.

“Recovery Mode” e-postası bana neden gelmedi?

İki olası sebep var: WordPress’e kayıtlı yönetici e-postası güncel değildir (Ayarlar → Genel’den kontrol edin) ya da sitenizin e-posta gönderimi (SMTP) çalışmıyordur. WP Mail SMTP gibi bir eklentiyle e-posta yapılandırmasını düzgün yapın. Çoğu hostingte varsayılan mail() işlevi Gmail, Outlook gibi sağlayıcılar tarafından spam kabul edilip teslim edilmez.

Beyaz ekran yerine “There has been a critical error on this website” yazıyor. Farkı ne?

WordPress 5.2 ile gelen daha insani bir karşılama mesajıdır. Teknik olarak aynı olay, aynı çözüm yolları. WordPress artık hatayı yakalayıp bir maske gösterebiliyor. Yine aynı adımları izleyin; yönetici e-postanıza gelen recovery link’ine bakın.

Aynı sorunla ayda birden fazla kez karşılaşıyorum. Neyi yanlış yapıyorum?

Büyük olasılıkla birkaç uyumsuz eklenti, güncel olmayan bir tema, düşük bellek limiti ve eski bir PHP sürümünün karışımını yaşıyorsunuz. Eklenti envanterinizi gözden geçirin, gereksizleri silin, kalanları düzenli güncelleyin. Uzun vadede sürekli bakım altında tutulan bir site, WSoD ile çok daha az karşılaşır.

Beyaz ekran sonrası Google sıralamamda kayıp yaşar mıyım?

Site kısa süreli (birkaç saat) erişilemez kalırsa Google bunu geçici bir durum olarak değerlendirir ve sıralamayı bozmaz. 24 saati geçen kesintilerde ise Search Console üzerinden manuel yeniden tarama talebi gönderin. Ekstra tedbir olarak, sitenin özellikle kritik sayfaları için “site:” sorgusu yaparak dizin durumunu düzenli kontrol edin.

Paylaşımlı hosting mi kullanıyorum, VPS mi? Hangisinde WSoD daha sık görülür?

İstatistiksel olarak paylaşımlı hostinglerde daha sık. Bunun nedeni düşük bellek sınırları, paylaşılan kaynak havuzu ve komşu sitelerin aşırı kullanımıdır. Yüksek trafikli ya da kritik siteler için yönetilen WordPress hosting ya da VPS neredeyse her zaman daha stabildir.

Related posts