Beyaz ekran tek bir hata değildir. Sunucu 500 döndürüyor olabilir, 200 yanıt içinde sıfır bayt veya yarım HTML üretebilir, ekran yalnız wp-admin’de görülebilir ya da cache/CDN eski boş çıktıyı sunabilir. İlk adım eklenti kapatmak değil, kapsamı ve gerçek HTTP yanıtını ölçmektir.
curl -sS -D /tmp/headers.txt -o /tmp/body.html https://example.com/
sed -n '1,20p' /tmp/headers.txt
wc -c /tmp/body.html
tail -n 120 wp-content/debug.log
wp plugin status
wp theme statusTarayıcı yalnız boş bir görünüm gösterebilir; ancak kaynak kodda HTML bulunabilir veya JavaScript/CSS görünürlüğü kapatmış olabilir. `curl` ile durum kodu, başlıklar ve gövde boyutu ölçüldüğünde sunucunun gerçekten boş yanıt üretip üretmediği anlaşılır. Ardından WordPress debug.log ile PHP-FPM, Apache, Nginx veya LiteSpeed logları aynı zaman damgasında karşılaştırılır.
Ana sayfa, tekil yazı, wp-login.php, wp-admin ve REST API ayrı ayrı denenir. Yalnız bir şablon veya endpoint bozuksa tüm eklentileri kapatmak gereksizdir.
500 hata, 200 sıfır bayt, 200 kısa gövde veya yönlendirme döngüsü farklı kök nedenlere gider. Başlıklar ve gerçek gövde kaydedilmelidir.
WordPress başlamadan hata oluşursa debug.log boş kalabilir. Bu durumda PHP-FPM pool, Apache error_log, Nginx error.log veya LiteSpeed stderr kayıtları belirleyicidir.
Bu ölçüm durum kodunu, Content-Type değerini, yönlendirmeyi ve yanıtın gerçekten boş olup olmadığını gösterir. Testi CDN üzerinden ve origin IP/hosts eşlemesiyle karşılaştırmak cache farkını ortaya çıkarabilir.
curl -sS -D /tmp/wp-headers.txt -o /tmp/wp-body.html https://example.com/
sed -n '1,25p' /tmp/wp-headers.txt
wc -c /tmp/wp-body.html
head -c 300 /tmp/wp-body.htmlAna sayfa, giriş, yönetim ve REST yanıtları farklı çalışıyorsa sorun tema şablonu, yönetim eklentisi veya rewrite katmanında olabilir. Her isteğin durum kodu tek tabloda görülmelidir.
for u in / /wp-login.php /wp-admin/ /wp-json/; do
curl -sS -o /dev/null -w "$u %{http_code} %{size_download}\n" "https://example.com$u"
doneZiyaretçiye hata göstermeden WordPress logunu açın. Ardından beyaz ekranı bir kez yeniden üretip logun son satırlarını okuyun. Dosya yazılmıyorsa wp-content izni ve PHP error log kontrol edilir.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Sorun bir deployment, eklenti/tema güncellemesi, PHP sürüm değişimi veya cache kuralından sonra başladıysa zaman çizelgesi teşhisi hızlandırır.
wp core version
php -v
wp plugin list --status=active --fields=name,status,version,update
wp theme list --status=active --fields=name,status,version,update
find wp-content -type f -mmin -180 | head -80Onarım öncesi wp-content, wp-config.php ve veritabanını aynı zaman damgalı set olarak alın. Canlı sipariş veya form verisi varsa işlem penceresini ayrıca planlayın.
Gizli pencere ve farklı ağ ile ana sayfa, tek içerik, wp-login.php, wp-admin ve wp-json yanıtlarını karşılaştırın. Yalnız bir kullanıcı veya cihazda görülüyorsa tarayıcı/cache katmanı da araştırılmalıdır.
500 ile 200 boş yanıtı aynı kabul etmeyin. `Content-Type`, `Content-Length`, redirect zinciri, gövde boyutu ve ilk HTML baytları olay kaydına eklenmelidir.
Beyaz ekranı yeniden üretip hemen ardından debug.log ve PHP/web server loglarını okuyun. `Fatal error`, `Uncaught`, `memory`, `permission denied` ve `upstream sent` gibi kayıtları bağlamıyla inceleyin.
Hata yolu belirli eklenti veya temayı gösteriyorsa yalnız onu devre dışı bırakın ya da son çalışan sürüme dönün. Log yoksa `--skip-plugins --skip-themes` ile WP-CLI erişimini ve kontrollü eklenti/tema karşılaştırmasını kullanın.
Uygulama düzeldikten sonra eski boş yanıt object cache, page cache, OPcache veya CDN’de kalabilir. Katmanları sırayla temizleyip origin ve genel URL sonuçlarını yeniden karşılaştırın.
Ana sayfa dışında giriş, yönetim, form, AJAX/REST, cron, e-posta ve varsa ödeme akışı test edilmelidir. Aynı zaman aralığında yeni fatal veya warning fırtınası oluşmadığını kontrol edin.
Genellikle PHP fatal hatası, web sunucusu kuralı, izin veya upstream çökmesidir. PHP-FPM/Apache/Nginx logu ve aynı isteğin zaman damgası önceliklidir.
Kod çıktı vermeden erken `exit/die` çalıştırmış, output buffer temizlenmiş, özel endpoint yanlış dönmüş veya cache boş yanıt saklamış olabilir.
CSS görünürlüğü, tam ekran overlay, JavaScript hatası, yüklenmeyen font/tema veya tarayıcı eklentisi olabilir. Kaynak kod ve DevTools Console/Network ayrı incelenmelidir.
Yönetim tarafında çalışan eklenti hook’u, kullanıcı rolüne bağlı kod, admin AJAX veya yönetim belleği farklı olabilir. Frontend’in çalışması tüm WordPress’in sağlıklı olduğunu göstermez.
Sıklıkla eklenti/tema kaynaklı PHP fatal hatası veya bellek tükenmesi görülür; ancak 200 boş yanıt, cache, izin, web sunucusu veya frontend CSS/JavaScript sorunu da olabilir. Durum kodu ve log olmadan tek neden söylenemez.
Çoğu durumda çalışabilir. WordPress yüklenirken aynı fatal hata oluşursa `--skip-plugins` ve `--skip-themes` seçenekleriyle bazı komutlar çalıştırılabilir; mu-plugins yine yüklenebilir ve ayrıca kontrol edilmelidir.
Hayır. WordPress başlamadan fatal hata olabilir, log yazma izni olmayabilir veya PHP farklı log hedefi kullanabilir. PHP-FPM, Apache, Nginx/LiteSpeed ve hosting paneli logları kontrol edilmelidir.
Sorun bir eklentiyse erişimi geri getirebilir; ancak bütün eklentileri devre dışı bırakır ve kök nedeni tek başına kanıtlamaz. Önce logdaki dosya yoluna göre yalnız ilgili eklentiyi hedeflemek daha doğrudur.
Hayır. 200 yanıt sıfır bayt, eksik HTML veya uygulama hata sayfası içerebilir. Gövde boyutu, içerik, kritik işlevler ve loglar ayrıca kontrol edilmelidir.
Kurulum, sunucu, script ve teknik destek ihtiyaçlarınız için Eka Yazılım ve Bilişim Sistemleri ile iletişime geçebilirsiniz.