WordPress dünyanın en yaygın kullanılan içerik yönetim sistemi olsa da, bir eklenti güncellemesi, bir tema çakışması ya da sunucudaki kaynak yetersizliği yüzünden sitenizin aniden bembeyaz bir ekrana dönmesi ya da "hata" yazan bir sayfayla karşılamanız hiç nadir değildir. İyi haber şu: bu durumların büyük kısmı panik gerektirmez. Doğru sırayla ilerlendiğinde WordPress hatalarının çoğu 10-15 dakika içinde teşhis edilip çözülebilir; asıl kaybedilen zaman genellikle "hangi katmanda arayacağımı bilmiyorum" belirsizliğinden kaynaklanır.
Bu rehberde WordPress kullanıcılarının en sık karşılaştığı hataları — Beyaz Ölüm Ekranı (WSOD), "Veritabanı Bağlantısında Hata Oluştu" mesajı, 500 Internal Server Error, 502/504 Gateway hataları, kalıcı bağlantı (permalink) 404 sorunları ve PHP bellek limiti aşımını — neden oluştuğunu ve nasıl teşhis edip düzelteceğinizi adım adım anlatıyoruz. Ayrıca wp-config.php üzerinden hata ayıklamayı açmayı, eklenti/tema devre dışı bırakma yöntemlerini, .htaccess yenilemeyi ve WordPress'in kendi kurtarma modunu nasıl kullanacağınızı göreceksiniz.
Beyaz Ölüm Ekranı (White Screen of Death - WSOD)#
Adının verdiği korkutucu izlenime rağmen beyaz ölüm ekranı aslında en "sessiz" WordPress hatasıdır: hiçbir hata mesajı, hiçbir açıklama yok — sadece bembeyaz bir sayfa. Bunun sebebi, PHP'nin bir hata fırlatması ama sunucu ayarları gereği bu hatanın ekrana değil sadece log dosyasına yazılmasıdır.
En Sık Nedenleri#
- Uyumsuz veya hatalı kodlu bir eklenti güncellemesi
- Tema fonksiyonlarında (
functions.php) sözdizimi hatası - PHP bellek (memory) limitinin aşılması
- Çakışan iki eklentinin aynı fonksiyonu/hook'u farklı şekillerde kullanması
Çözüm Adımları#
İlk yapmanız gereken şey hatayı görünür kılmaktır. wp-config.php dosyasını FTP/SFTP ya da hosting kontrol panelinizin Dosya Yöneticisi ile açıp aşağıdaki satırı /* That's all, stop editing! */ satırından önce ekleyin:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Bu ayarla hatalar ekrana basılmaz (canlı sitede WP_DEBUG_DISPLAY her zaman false kalmalı) ama wp-content/debug.log dosyasına satır satır yazılır. Dosyayı açtığınızda genellikle şöyle bir satır görürsünüz:
PHP Fatal error: Uncaught Error: Call to undefined function xyz() in /home/kullanici/public_html/wp-content/plugins/ornek-eklenti/eklenti.php:45
Bu satır size doğrudan suçlu eklentiyi ve dosya/satır numarasını verir. Sorun bir eklentideyse, o eklentinin klasörünü FTP üzerinden wp-content/plugins/ dizininin dışına taşıyıp (ya da adını değiştirip) yeniden deneyin — WordPress tanımadığı bir klasör adını otomatik olarak devre dışı bırakır. Sorun temadaysa, wp-content/themes/ altında varsayılan bir temaya (twentytwentyfour gibi) geçici olarak dönebilirsiniz.
İşiniz bittiğinde WP_DEBUG satırlarını mutlaka false yapın ya da tamamen silin; canlı ortamda açık bırakmak hem performansı hem güvenliği olumsuz etkiler.
"Veritabanı Bağlantısında Hata Oluştu"#
Bu mesaj WordPress'in wp-config.php içindeki bilgilerle MySQL sunucusuna bağlanamadığı anlamına gelir. Site içeriği değil, veritabanı erişimi sorunludur.
Kontrol Listesi#
- Kimlik bilgilerini doğrulayın.
wp-config.phpiçindekiDB_NAME,DB_USER,DB_PASSWORDveDB_HOSTdeğerlerinin hosting kontrol panelindeki veritabanı bilgileriyle birebir eşleştiğinden emin olun. - Veritabanı sunucusunun ayakta olup olmadığını kontrol edin. Paylaşımlı hostinglerde
DB_HOSTgeneldelocalhost'tur, ancak bazı sağlayıcılar farklı bir host adresi (örneğinmysql.saglayici.com) kullanabilir. - Veritabanı kullanıcısının yetkilerini kontrol edin. Kullanıcı, ilgili veritabanına
ALL PRIVILEGESile atanmış olmalıdır. - Tabloların bozulup bozulmadığını kontrol edin. phpMyAdmin üzerinden veritabanına girip ilgili tabloları seçin, "Onar" (Repair) işlemini çalıştırın:
REPAIR TABLE wp_options, wp_posts, wp_postmeta, wp_users;
Not: bu komut klasik olarak MyISAM tabloları için tasarlanmıştır; modern WordPress kurulumlarında tablolar genelde InnoDB motorunu kullanır ve InnoDB kendi bütünlük kontrolünü zaten otomatik yapar — bu durumda REPAIR TABLE çoğunlukla no-op döner ve bozulma InnoDB'de nadiren yaşanır. Yine de zarar vermez, bir deneme olarak çalıştırabilirsiniz; asıl bozulma MyISAM tablolarında (bazı eski eklentiler hâlâ bu motoru kullanır) ya da beklenmedik sunucu kapanmalarının hemen ardından görülür.
Eğer phpMyAdmin'e erişemiyorsanız ve MySQL sunucusu aşırı yük altındaysa (özellikle trafik artışında paylaşımlı hostinglerde görülür), kaynakların yetersiz kaldığı bir durumla karşı karşıyasınız demektir. Gerçek bir kaynak sıkıntısı varsa kalıcı çözüm, veritabanı için ayrılmış kaynağa sahip bir WordPress hosting paketine ya da tam kontrol istiyorsanız bir VDS çözümüne geçmek olabilir.
500 Internal Server Error#
500 hatası WordPress'e özgü değildir — sunucunun isteği işlerken beklenmedik bir durumla karşılaştığını ama sebebi tam olarak belirtmediğini söyler. En yaygın üç kaynağı şunlardır:
1. Bozuk .htaccess Dosyası#
.htaccess içindeki tek bir yazım hatası bile Apache'nin tüm siteyi 500 ile çökertmesine yeter. Dosyayı FTP ile indirip yedekleyin, sonra silin ya da yeniden adlandırın (.htaccess.bak), siteyi kontrol edin. Site açıldıysa, WordPress panelinden Ayarlar > Kalıcı Bağlantılar sayfasına girip herhangi bir değişiklik yapmadan Değişiklikleri Kaydet butonuna basın — WordPress dosyayı sıfırdan, doğru içerikle yeniden oluşturacaktır. Varsayılan içerik şuna benzer:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
2. PHP Bellek Limiti Aşımı#
Bazı işlemler (büyük bir eklenti kurulumu, resim işleme, çoklu güncelleme) PHP'nin ayrılan bellek sınırını aşabilir. wp-config.php'ye şu satırı ekleyerek WordPress'in kullanabileceği bellek miktarını artırabilirsiniz:
define('WP_MEMORY_LIMIT', '256M');
Bu, yalnızca WordPress'in isteğidir; asıl sınırı sunucudaki PHP yapılandırması belirler. Paylaşımlı hostinglerde bu genellikle php.ini ya da kontrol panelindeki "PHP Ayarları" bölümünden, VDS/özel sunucularda ise doğrudan sunucu düzeyinde değiştirilir.
3. Bozuk Çekirdek Dosyaları#
WordPress çekirdeğinin bir kısmı bozulmuş ya da eksik kalmış olabilir (yarım kalan bir güncelleme sonrası sık görülür). WordPress.org'dan aynı sürümün ZIP dosyasını indirip içindeki wp-admin ve wp-includes klasörlerini (kullanıcı dosyalarınızın olduğu wp-content'e dokunmadan) sunucudaki karşılıklarının üzerine yazarak çekirdeği onarabilirsiniz.
502 Bad Gateway ve 504 Gateway Timeout#
Bu iki hata birbirine benzese de farklı anlamlar taşır: 502, sunucunun yukarı akış (upstream — genelde PHP-FPM süreci) bileşeninden geçersiz bir yanıt aldığını; 504 ise o bileşenin belirlenen sürede hiç yanıt vermediğini gösterir. İkisi de genellikle sunucu tarafında yaşanan bir tıkanıklığa işaret eder:
- PHP-FPM süreç sayısı yetersiz kalmış olabilir — yoğun trafikte istekler kuyruğa girer ve zaman aşımına uğrar.
- Ağır bir sorgu ya da sonsuz döngüye giren bir eklenti PHP sürecini kilitleyip diğer isteklerin işlenmesini engelleyebilir.
- Nginx/Apache ile PHP-FPM arasındaki zaman aşımı (timeout) değerleri çok düşük ayarlanmış olabilir.
Sunucu günlüklerine (Apache için error_log, Nginx için error.log) bakarak hangi isteğin zaman aşımına uğradığını görebilirsiniz; genelde aynı URL veya aynı eklenti tekrar tekrar günlüğe düşer. Bu hatalar düzenli olarak, özellikle trafik arttığında tekrarlanıyorsa, bu genellikle paylaşımlı hostingin kaynak sınırlarına dayandığınızın işaretidir — bir eklentiyi optimize etmek geçici rahatlatır ama trafik büyümeye devam ettikçe sorun geri gelir. Bu noktada kaynakları izole eden bir sanal sunucu çözümüne geçmek, aynı sorunu tekrar tekrar yaşamak yerine kalıcı bir çözüm sunar.
Kalıcı Bağlantı (Permalink) 404 Hatası#
Siteniz açılıyor ama tek tek yazı veya sayfalara girdiğinizde 404 alıyorsanız, sorun genellikle sunucunun URL yeniden yazma (rewrite) kurallarının WordPress'in kalıcı bağlantı yapısıyla senkron olmamasıdır. Bu durum çoğunlukla bir sunucu geçişinden (site taşıma) veya .htaccess dosyasının silinmesinden sonra ortaya çıkar.
Çözüm:
- WordPress panelinden Ayarlar > Kalıcı Bağlantılar sayfasına gidin.
- Herhangi bir yapı seçeneğini değiştirmeden Değişiklikleri Kaydet'e tıklayın. Bu,
.htaccessdosyasını (Apache) yeniden yazdırır. - Eğer sunucunuz Nginx kullanıyorsa
.htaccessişe yaramaz; bunun yerine sunucu bloğunda şuna benzer birtry_filesyönergesi olmalıdır:
location / {
try_files $uri $uri/ /index.php?$args;
}
- Sorun devam ediyorsa dosya izinlerini kontrol edin —
.htaccessdosyasının Apache tarafından yazılabilir olması gerekir (genelde644).
Sunucu tarafındaki yeniden yazma kurallarının mantığını daha detaylı öğrenmek isterseniz .htaccess ile yönlendirme yazımıza göz atabilirsiniz.
Eklenti ve Tema Çakışmalarını Teşhis Etme#
Hata mesajı net bir suçlu göstermiyorsa, sistematik bir eleme yöntemi en hızlı yoldur.
Yönetici Paneline Erişebiliyorsanız#
- Eklentiler sayfasına gidin, tümünü seçip Devre Dışı Bırak'ı uygulayın.
- Site normale döndüyse, eklentileri teker teker tekrar aktif edip her birinden sonra siteyi kontrol edin. Hatanın geri geldiği an, suçlu eklentiyi bulmuş olursunuz.
- Aynı mantığı temada da uygulayın: Görünüm > Temalar'dan varsayılan bir WordPress temasına geçin.
Yönetici Paneline Erişemiyorsanız (FTP ile)#
Eklentileri wp-content/plugins/ klasöründen toplu olarak devre dışı bırakmak için tüm klasörün adını değiştirmeniz yeterlidir:
mv wp-content/plugins wp-content/plugins-disabled
mkdir wp-content/plugins
WordPress artık hiçbir eklentiyi tanımayacak ve hepsini devre dışı olarak işaretleyecektir. Site açıldıysa, orijinal klasörü geri adlandırıp eklentileri alt klasör isimlerini tek tek değiştirerek (ornek-eklenti → ornek-eklenti-disabled) hangisinin soruna yol açtığını bulabilirsiniz.
WordPress Kurtarma Modu#
WordPress 5.2 ve sonrasında gelen Kurtarma Modu (Recovery Mode) özelliği, bir eklenti veya temanın siteyi çökertmesi durumunda size otomatik bir e-posta gönderir. Bu e-postadaki bağlantıya tıkladığınızda, sorunlu eklenti/tema devre dışı bırakılmış şekilde yönetici paneline giriş yapabilirsiniz — dosyalara hiç dokunmadan.
Bu özelliğin çalışabilmesi için wp-config.php'de e-posta gönderiminin aktif olması ve sitenin WP_DEBUG_DISPLAY değerinin false olması gerekir (aksi halde WordPress hatayı doğrudan ekrana basar ve kurtarma modu tetiklenmez). E-postayı almadıysanız spam klasörünü kontrol edin; sunucunuzun e-posta gönderim yapılandırması sorunluysa bu e-postalar hiç ulaşmayabilir.
Önleyici Tedbirler#
Hataların çoğu, düzenli bakım alışkanlıklarıyla baştan engellenebilir:
- Güncellemeden önce yedek alın. Eklenti, tema veya çekirdek güncellemesi öncesi tam bir yedek almak, sorun çıktığında geri dönüşü dakikalar içine indirir. Otomatik yedekleme çözümleri bu süreci elle uğraşmadan garanti altına alır.
- Aşamalı güncelleme yapın. Tüm eklentileri aynı anda değil, teker teker güncelleyip her adımdan sonra siteyi kontrol edin.
- Bir hazırlık (staging) ortamı kullanın. Değişiklikleri önce canlı olmayan bir kopyada test etmek, WSOD gibi sürprizleri ziyaretçiler görmeden yakalamanızı sağlar.
- Güvenlik katmanlarını ihmal etmeyin. Kötü amaçlı trafik veya saldırı denemeleri de kaynak tükenmesine bağlı 500/502 hatalarını tetikleyebilir; bir WAF ve DDoS koruması bu riski azaltır.
- Sertifikaları ve yönlendirmeleri düzenli kontrol edin. Karışık içerik (mixed content) uyarıları veya süresi dolan bir SSL sertifikası bazen "site açılmıyor" şikâyeti olarak WordPress hatasıyla karıştırılır; SSL yapılandırmanızın güncel ve otomatik yenilenir durumda olduğundan emin olun.
- Sunucu kaynaklarını izleyin. Disk alanı dolması ya da CPU/RAM kullanımının sürekli tavan yapması da 500/502 hatalarının sessiz sebeplerindendir; hosting kontrol panelinizdeki kaynak kullanım grafiklerini ara sıra kontrol etmek, sorun büyümeden fark etmenizi sağlar.
- Kendiniz uğraşmak istemiyorsanız düzenli güncelleme, yedekleme ve izleme işini devralan bir WordPress bakım hizmetinden yararlanabilirsiniz.
Temel WordPress kurulum adımlarını ve güvenlik sertleştirmesini daha derinlemesine öğrenmek isterseniz WordPress kurulumu ve WordPress güvenliği yazılarımıza göz atabilirsiniz.
Sıkça Sorulan Sorular#
Beyaz ekran gördüğümde ilk ne yapmalıyım?#
Öncelikle wp-config.php dosyasında WP_DEBUG ve WP_DEBUG_LOG değerlerini true yapıp wp-content/debug.log dosyasını inceleyin. Bu log genellikle sorunun hangi eklenti veya dosyadan kaynaklandığını doğrudan gösterir.
"Veritabanına bağlanırken hata oluştu" mesajı veri kaybı anlamına mı gelir?#
Hayır, bu mesaj çoğunlukla wp-config.php içindeki bağlantı bilgilerinin yanlış olduğunu veya veritabanı sunucusunun geçici olarak erişilemez durumda olduğunu gösterir; verileriniz genelde yerinde durur. Bilgileri doğrulayıp tabloları onardıktan sonra site normalde geri döner.
500 hatası aldığımda önce hangi dosyayı kontrol etmeliyim?#
.htaccess dosyasını. Bu dosyayı geçici olarak yeniden adlandırıp siteyi kontrol etmek, en yaygın 500 hatası nedenini birkaç saniyede eler.
Eklentileri tek tek devre dışı bırakmak yerine hepsini aynı anda kapatabilir miyim?#
Evet, hem yönetici panelinden toplu seçimle hem de FTP üzerinden plugins klasörünü yeniden adlandırarak tüm eklentileri aynı anda devre dışı bırakabilirsiniz. Sonrasında hangisinin soruna yol açtığını bulmak için teker teker geri açmanız gerekir.
Kurtarma modu e-postası neden gelmiyor?#
Sunucunun e-posta gönderim yapılandırması sorunlu olabilir ya da e-posta spam klasörüne düşmüş olabilir. Ayrıca WP_DEBUG_DISPLAY açık bırakılmışsa WordPress hatayı doğrudan ekrana bastığından kurtarma modu e-postası hiç tetiklenmeyebilir.
PHP bellek limitini artırmak her sorunu çözer mi?#
Hayır. WP_MEMORY_LIMIT yalnızca WordPress'in isteyebileceği üst sınırı belirler; asıl sınırı sunucudaki PHP yapılandırması koyar. Sorun tekrar ediyorsa kaynak yetersizliği kalıcı hale gelmiş demektir ve daha güçlü bir hosting/sunucu planına geçmek gerekebilir.
Bu hataların çoğu doğru teşhisle hızlıca çözülse de, tekrarlayan kaynak sıkıntıları genellikle altyapının büyümesi gerektiğinin işaretidir; ihtiyacınıza uygun bir WordPress hosting veya hosting planını incelemek isteyebilirsiniz.