Arama Yap Mesaj Gönder
Biz Sizi Arayalım
+90
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Almanya (German)Almanya (German) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

Türk Lirası $ US Dollar Euro
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Almanya (German)Almanya (German) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

Türk Lirası $ US Dollar Euro

Bize Ulaşın

Konum Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
WordPress beyaz ekran teşhisi

WordPress beyaz ekranını HTTP yanıtı ve PHP loguyla kaynağına kadar izleyin

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.

root@eka:~/diagnostics
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 status
STATUS200, 500 veya yönlendirme
BYTESYanıt gövdesi gerçekten boş mu?
SCOPETüm site, wp-admin veya tek URL
LOG TIMEİstekle aynı zaman aralığı
01
Konuya özel çerçeve

Beyaz ekranı kritik hata, cache görüntüsü ve frontend hatasından ayırın

Tarayı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.

Kapsam testi

Tüm site mi, yalnız bir bölüm mü?

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.

Yanıt testi

HTTP durumu ve gövde boyutu

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.

Sunucu kanıtı

WordPress ve PHP logları

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.

02
Terminal ve doğrulama

Tarayıcı görüntüsüne değil, gerçek HTTP çıktısına ve log zamanına bakın

01

Başlık ve gövdeyi ayrı kaydedin

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.html
02

Kapsamı URL bazında karşılaştırın

Ana 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"
done
03

Güvenli debug kaydını etkinleştirin

Ziyaretç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);
04

Son değişiklikleri ve aktif bileşenleri çıkarın

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 -80
03
Uygulama sırası

Beyaz ekranı kapsamdan kök nedene doğru daraltın

01

Dosya ve veritabanı yedeğini eşleştirin

Onarı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.

02

Beyaz ekranın kapsamını belirleyin

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.

03

HTTP durumunu ve gövdeyi kanıt olarak saklayın

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.

04

İstekle aynı zaman aralığındaki logu bulun

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.

05

Logdaki bileşeni hedefli izole edin

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.

06

Cache, opcode ve CDN katmanını temizleyip karşılaştırı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.

07

İşlev ve yeni log kaydını doğrulayı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.

04
Hata sözlüğü

Beyaz veya boş çıktının farklı teknik karşılıklarını ayırın

HTTP 500 + boş gövde

Genellikle PHP fatal hatası, web sunucusu kuralı, izin veya upstream çökmesidir. PHP-FPM/Apache/Nginx logu ve aynı isteğin zaman damgası önceliklidir.

HTTP 200 + sıfır veya çok küçük gövde

Kod çıktı vermeden erken `exit/die` çalıştırmış, output buffer temizlenmiş, özel endpoint yanlış dönmüş veya cache boş yanıt saklamış olabilir.

HTML var ama ekran beyaz

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.

Yalnız wp-admin beyaz

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.

Riskler

Kaçınılması gereken uygulamalar

  • HTTP durumunu ölçmeden sorunu yalnız tarayıcı görünümüne göre yorumlamak
  • Yedek almadan tema veya eklenti klasörlerini silmek ya da yeniden adlandırmak
  • Canlı sitede PHP display_errors açıp dosya yollarını ziyaretçilere göstermek
  • CDN/cache temizlenmeden uygulama düzeltmesini başarısız sanmak veya tersine cache çıktısını gerçek çözüm sanmak
  • Tüm eklentileri aynı anda kapatıp hangi bileşenin hatalı olduğunu kaybetmek
Kontrol listesi

İşlem tamamlanmadan kanıtlayın

  • Ana sayfa, wp-admin, giriş ve REST için durum kodları kaydedildi
  • Yanıt gövdesi boyutu ve ilk HTML içeriği incelendi
  • Aynı zaman damgasındaki WordPress ve PHP/web server logları karşılaştırıldı
  • Hatalı bileşen kanıta göre hedefli biçimde izole edildi
  • Origin, cache/CDN ve gizli pencere sonuçları birbiriyle eşleşiyor
  • Giriş, form, AJAX/REST, cron ve e-posta işlevleri tekrar test edildi
05
Sık sorulan sorular

WordPress beyaz ekranı hakkında net cevaplar

WordPress beyaz ekranının en sık nedeni nedir?

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.

Beyaz ekran varken WP-CLI çalışır mı?

Ç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.

debug.log boşsa hata yok mudur?

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.

Eklenti klasörünü yeniden adlandırmak beyaz ekranı çözer mi?

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.

HTTP 200 dönüyorsa site sağlıklı mıdır?

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.

06
İç SEO konu kümesi

Bu rehberden sonra doğru konuya devam edin

07
Teknik kaynaklar

Resmî dokümantasyonla doğrulayın

EKA SUNUCU TEKNİK BİLGİ MERKEZİ

Kararınızı tahminle değil, teknik kanıtla verin.

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.

İletişime Geç
Top