WordPress hataları, can sıkıcı olmanın ötesinde sitenizi tamamen erişilemez hale getirebilir. Beyaz ekran, bağlantı hatası ya da güncelleme sonrası çöken bir tema… Her birinin çözümü aslında düşündüğünüzden daha basit. Bu yazıda, en sık karşılaşılan WordPress hatalarını adım adım nasıl çözeceğinizi, öncesinde hangi önlemleri almanız gerektiğini ve sık yapılan yanlışları anlatacağım.
Sorunu çözümlerken panik yapmamak işin yarısı. Çoğu hata, birkaç kontrollü adımla giderilebilir. Hadi başlayalım.
Hata Çözümünden Önce: Yedek ve Test Ortamı
Doğrudan canlı sitede işlem yapmak risklidir. Düzeltmeye çalışırken daha büyük sorunlar yaratabilirsiniz. Bu yüzden ilk adım, güncel bir yedek aldığınızdan emin olmak.
Yedekleme için UpdraftPlus gibi eklentiler işinizi görür. Alternatif olarak hosting panelinizden (cPanel, Plesk) manuel yedek alabilirsiniz. Yedek dosyalarınızda hem veritabanı hem de wp-content klasörü bulunmalı.
Mümkünse bir staging (test) ortamı kurun. Birçok hosting firması bunu tek tıkla sunar. Test ortamında yapacağınız değişiklikler canlı siteyi etkilemez; çözümü doğruladıktan sonra aynı adımları canlı siteye uygularsınız. Yedek olmadan ve test etmeden ilerlemek, en sık yapılan hatadır.
Beyaz Ekran Hatası (WP_DEBUG ile Teşhis)
Siteniz bomboş bir sayfa gösteriyorsa, buna “Beyaz Ekran Hatası” denir. PHP belleği dolduğunda, uyumsuz bir eklentide veya tema dosyalarında hata olduğunda ortaya çıkar. Önce hatayı görünür kılmalısınız.
FTP ile sitenize bağlanın ve kök dizindeki wp-config.php dosyasını açın. Şu satırı bulun:
define( 'WP_DEBUG', false );
Bu satırı şu şekilde değiştirin:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Bu ayar, hataları ekrana basmaz ama /wp-content/debug.log dosyasına kaydeder. Dosyayı açıp baktığınızda, hatanın hangi eklenti veya tema dosyasında olduğunu görebilirsiniz. Çoğu zaman “Fatal error: Allowed memory size…” şeklinde bir mesaj görürsünüz. Bu durumda bellek sınırını artırmak gerekir.
Aynı wp-config.php dosyasına şu satırı ekleyin:
define( 'WP_MEMORY_LIMIT', '256M' );
Eğer hata bir eklentiyle ilgiliyse, eklenti klasörünün adını FTP’den geçici olarak değiştirerek eklentiyi devre dışı bırakın. Site tekrar açılırsa sorun o eklentidedir. Eklentinin alternatifini araştırın veya güncel bir sürümünü bekleyin. Sorun tema dosyalarındaysa, ftp ile varsayılan bir temaya (mesela Twenty Twenty-Three) geçiş yapmak için diğer temaların klasör adlarını geçici olarak değiştirebilirsiniz.
Veritabanı Bağlantı Hatası
“Error establishing a database connection” hatası, WordPress’in veritabanına erişemediği anlamına gelir. Bunun birkaç yaygın nedeni var.
İlk kontrol: wp-config.php dosyasındaki veritabanı bilgileri. Aşağıdaki satırların doğruluğunu teyit edin:
- DB_NAME – Veritabanı adı
- DB_USER – Veritabanı kullanıcı adı
- DB_PASSWORD – Şifre
- DB_HOST – Genellikle “localhost” olur, ancak bazı hostinglerde farklı bir adres yazılabilir.
Bilgiler doğruysa, hosting panelinizden veritabanı sunucusunun çalıştığını kontrol edin. Sunucu yoğunluğu veya bakım çalışmaları bu hataya sebep olabilir. Veritabanınızın boyutu da kota sınırını aşmış olabilir; phpMyAdmin’den bakıp gereksiz tabloları (spam yorumlar, eski revizyonlar gibi) temizleyin.
Bir diğer neden, veritabanı kullanıcısının yetkilerinin kısıtlanmış olmasıdır. Hosting panelinizden kullanıcıyı ilgili veritabanına yeniden atayıp tüm yetkileri verin.
Güncelleme Sırasında Bakım Modunda Takılı Kalma
WordPress güncellemesi yarım kaldığında site “Briefly unavailable for scheduled maintenance. Check back in a minute.” mesajıyla kilitlenir. Temel neden, kök dizinde .maintenance adlı geçici bir dosyanın silinmemiş olmasıdır.
Çözüm son derece basit: FTP ile ana dizine gidin, .maintenance dosyasını bulun ve silin. Dosya gizli olabileceği için FTP istemcinizde gizli dosyaları gösterme ayarını açmayı unutmayın. Dosyayı sildikten sonra site normale döner. Eğer güncelleme tamamlanmadıysa, WordPress yönetim paneline giriş yapıp güncellemeyi manuel olarak yeniden başlatabilirsiniz.
Karışık İçerik ve Bozuk Karakter Sorunu
Sitenizde anlamsız karakterler, Türkçe karakterlerin bozulması (örneğin “İş” yerine “İş” gibi) görüyorsanız, karakter kodlamasıyla ilgili bir uyumsuzluk var demektir. Bu genellikle veritabanı taşıma veya yanlış içe aktarma sonrası oluşur.
wp-config.php dosyasında şu iki satırın olduğuna emin olun:
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );
Bu ayarlar zaten varsa ve sorun devam ediyorsa, veritabanı tablolarınızın karakter setini phpMyAdmin’den kontrol edin. Tüm tabloları “utf8mb4_unicode_ci” olarak değiştirin. Bunu yapmadan önce mutlaka yedek alın. Ayrıca wp-config.php içinde bulunan $table_prefix değişkenini de kontrol edin; taşıma sırasında yanlış ön ek yazılmış olabilir.
Eklenti ve Tema Uyuşmazlıklarını Elden Geçirme
Belirli bir hatanın hangi eklentiden kaynaklandığını bulmak için sorun giderme modu kullanın. Health Check & Troubleshooting eklentisini yükleyin. Bu eklenti, sadece sizin oturumunuzda tüm eklentileri devre dışı bırakıp varsayılan temaya geçerek siteyi etkilemeden test yapmanızı sağlar. Ardından eklentileri tek tek aktif ederek hatayı yeniden oluşturanı tespit edebilirsiniz.
Eğer hostinginizde bu eklentiyi kuramıyorsanız, manuel olarak şöyle ilerleyin:
- FTP ile /wp-content/plugins/ dizinine girin.
- Tüm eklenti klasörlerini plugins-deaktif gibi bir yedeğe taşıyın.
- Siteyi kontrol edin. Düzeldiyse sorun eklentilerdedir.
- Eklentileri sırayla geri taşıyıp her seferinde siteyi yeniden kontrol edin.
Aynı mantık temalar için de geçerli; /wp-content/themes/ içindeki aktif tema dışındaki temaları geçici olarak kaldırıp varsayılan temaya geçebilirsiniz.
Yavaş Site Performansına Pratik Müdahaleler
WordPress hataları denince akla hep kırık sayfalar gelir; ama aşırı yavaşlık da kullanıcı deneyimini ve SEO’yu baltalar. Performans sorunlarını sıkıştırılmamış görseller, kalitesiz hosting, önbelleksiz site ve ağır eklentiler tetikler.
Aşağıdaki tabloda en yaygın nedenleri ve hızlı çözümleri görebilirsiniz:
| Neden | Belirti | Çözüm |
|---|---|---|
| Sıkıştırılmamış görseller | Sayfa boyutu büyük, yükleme süresi uzun | Smush veya ShortPixel ile toplu optimize edin |
| Önbellek yok | Her ziyarette sunucu yeniden sayfa oluşturur | WP Rocket ya da W3 Total Cache kurup yapılandırın |
| Ağır eklentiler | Sunucu yanıt süresi (TTFB) yüksek | Query Monitor ile yavaş sorguları bulup gereksiz eklentileri kaldırın |
| Harici betikler | Yazı tipi, reklam, analitik betikleri sayfayı bloke eder | Ertelenmiş yükleme veya async özelliği ekleyin |
| PHP sürümü eski | Hosting panelinde desteklenmeyen sürüm görünür | Hostingden en az PHP 8.0’a geçiş yapın |
Önbellek eklentisini kurduktan sonra mobil ve masaüstü skorlarınızı PageSpeed Insights ile ölçün. 70’in altındaysa görselleri WebP formatına dönüştürmeyi ve kritik CSS’i satır içi eklemeyi deneyin. Bu işlemler için WP Rocket’ın ilgili sekmeleri yeterince açıklayıcıdır.
WordPress’i Manuel Olarak Güncellemek
Otomatik güncelleme başarısız olduğunda veya güncelleme sonrası sitede sorun çıktığında, manuel güncelleme en temiz çözümdür. Panik yapmayın; sadece birkaç klasörü değiştireceksiniz.
İşte adımlar:
- Yedek alın. Hem dosyaları hem veritabanını.
- WordPress.org’dan en son Türkçe sürümü indirin.
- Zip dosyasını açın ve wp-content klasörünü, wp-config.php ve .htaccess dosyalarını silin. Bunları sunucudaki sürümlerle değiştirmek istemezsiniz.
- Kalan tüm dosya ve klasörleri FTP ile sunucuya yükleyin, üzerine yazın.
- Yükleme bittiğinde /wp-admin/upgrade.php adresine gidin. Veritabanı güncellemesi varsa WordPress sizi yönlendirecektir.
Bu yöntem, özellikle hacklenme şüphesinde çekirdek dosyaları temizlemek için de kullanılır. Sadece wp-content’e dokunmamaya dikkat edin; temalarınız, eklentileriniz ve medya dosyalarınız oradadır.
İzin Hataları ve .htaccess Kaynaklı Sorunlar
WordPress yükleme yaparken “Unable to create directory” hatası alıyorsanız dosya izinleri yanlıştır. Standart izinler şöyledir:
- Klasörler için 755
- Dosyalar için 644
- wp-config.php için 440 veya 400 (güvenlik için daha kısıtlı)
Bu değerleri FTP’den değiştirebilirsiniz. Özellikle wp-content/uploads ve içindeki klasörler 755 olmalı ki WordPress içine dosya yazabilsin.
Bir diğer sık hata, 404 sayfası veya “Internal Server Error” şeklinde çıkar ve genellikle bozuk bir .htaccess dosyasından kaynaklanır. Çözüm için FTP’den .htaccess dosyasını bilgisayarınıza yedekleyip sunucudan silin. Ardından WordPress yönetim panelinden “Ayarlar > Kalıcı Bağlantılar” sayfasına girip hiçbir şeyi değiştirmeden “Değişiklikleri Kaydet” butonuna basın. WordPress yeni bir .htaccess dosyası oluşturacaktır. Sorun çözülmezse hosting destek ekibiyle iletişime geçmekte fayda var.
Hata Ayıklarken Kaçınmanız Gerekenler
Deneyimli kullanıcılar bile aceleyle hata yapabilir. Şu üç şeyi aklınızda tutun:
Önce suçlu aramayın. Bir hata oluştuğunda ilk refleks hosting firmasını suçlamak oluyor. Oysa çoğu WordPress hatası eklenti çakışması veya güncelleme eksikliğinden kaynaklanır. Hosting desteğine yazmadan önce bu yazıdaki adımlarla temel kontrolleri yapın.
Canlı sitede deneme yanılma yapmayın. “Bir dakikacık denerim, olmazsa geri alırım” diyerek yapılan küçük bir değişiklik, siteyi saatlerce kapalı tutabilir. Test ortamı kullanmak ya da en kötü ihtimalle gece yarısı düşük trafik saatinde işlem yapmak daha güvenlidir.
Sadece bir çözüme takılıp kalmayın. WordPress hataları birden fazla şekilde çözülebilir. Beyaz ekran hatasını bellek sınırını yükselterek çözemezseniz, eklentileri kontrol edin. O da olmazsa temayı varsayılana çevirin. Esnek olun.
Sitenizi Gelecekteki Hatalara Karşı Nasıl Korursunuz?
Her hatayı sıfırlayamazsınız ama riski ciddi ölçüde azaltabilirsiniz. İşte somut bir liste:
- Eklenti ve tema sayınızı minimumda tutun. Kullanmadığınız her eklentiyi silin, sadece devre dışı bırakmak yetmez.
- Otomatik yedekleme ayarlayın. UpdraftPlus ile haftalık yedekleri otomatiğe bağlayın ve yedekleri Google Drive gibi harici bir alana gönderin.
- WordPress, tema ve eklentileri güncel tutun. Güncellemeleri ertelemek bilinen açıklardan yararlanılmasına yol açar. Mümkünse küçük güncellemeler için otomatik güncellemeyi açın.
- İyi bir hosting seçin. PHP bellek limiti yüksek, güncel PHP ve MySQL sunan bir hosting, hataların yarısını kendiliğinden önler.
- Bir güvenlik eklentisi kurun. Wordfence veya Sucuri gibi bir eklenti, dosya bütünlüğünü izler ve kötü amaçlı değişiklikleri haber verir.
Bunları rutin haline getirdiğinizde, WordPress hatalarıyla karşılaşma sıklığınız gözle görülür şekilde azalacaktır.
Son olarak, her hata öğreticidir. Bir defa çözdüğünüz sorun, bir dahaki sefere sizi saatlerce uğraştırmaz. Yeter ki sakin kalın ve adım adım ilerleyin. Unutmayın, çoğu WordPress hatası sandığınızdan daha basit bir çözüme sahiptir.
Beyaz ekran hatası tam bir kabus.
WP_DEBUG açınca sitede performans düşüşü oluyor mu?
Ben debug.log dosyasını ilk kez duydum, çok işime yarayacak.
Canlı sitede wp-config.php ile oynarken dikkatli olmak lazım, yanlış bir karakter her şeyi bozabilir.
Geçen hafta eklenti güncellemesi sonrası beyaz ekran aldım. wp-config’te WP_DEBUG’u aktif etsem de hatayı çözemedim, meğer bellek limiti dolmuş. Hosting’den arttırmak gerekti, keşke makalede bellek kontrolü de detaylandırılsaydı.
Ben yedeği manuel almaktansa eklentiyle almayı tercih ederim.
Staging ortamı her hostingde yok, alternatif olarak localhost’ta denemek aynı işi görür mü? Bir de debug.log silinmezse zamanla şişer mi?
UpdraftPlus yedekleme için gerçekten birebir.
Makalede FTP ile wp-config.php düzenlemesi anlatılmış ama güvenlik eklentileri dosyayı kilitleyebiliyor, değişiklik yapamadığım oldu. Bu durumda nasıl bir yol izlemeliyiz? Ayrıca debug.log dosyası herkese açık olmaz mı, güvenlik riski oluşturur mu?
Test ortamı kurmak ilk başta zaman kaybı gibi geliyor ama yapınca rahat ediyorsun.
Yedek almadan canlı siteye müdahale etmek çok riskli.
Bir keresinde beyaz ekran hatasını çözmek için tüm eklentileri FTP’den kapatmak zorunda kalmıştım. Makalede anlatılan WP_DEBUG yöntemi daha akıllıca ama her hata debug.log’a düşmüyor, özellikle kritik PHP hatalarında.
Sadece wp-content klasörünü yedeklemek yeterli değil, veritabanı da şart.
WP_DEBUG_DISPLAY false yapmak iyi fikir ama bazen hata yine de ekrana yansıyabiliyor, özellikle tema functions.php’sinde bir sorun varsa. Sadece debug.log’a güvenmek yerine sunucu hata kayıtlarını da kontrol etmek gerekmez mi?
Adım adım anlatım süper olmuş.