Bu WordPress hata çözümleri rehberi, sitedeki WordPress yazılarının merkezi. Amacı basit: bir WordPress sitesinde ters giden bir şey olduğunda, hangi yazıyı hangi sırayla okumanız gerektiğini tek yerden göstermek. Aşağıdaki bölümler bir arıza tespit akışı gibi ilerliyor — önce siteyi ayağa kaldıran müdahaleler, sonra hız, güvenlik, SEO ve geliştirici tarafı.
Önce Teşhis: 3 Dakikalık Kontrol
Hataya körlemesine müdahale etmek, çoğu zaman ikinci bir hata üretir. Sıralama şu olmalı: hata mesajını görün, sunucu günlüğünü okuyun, sonra değiştirin.
- Hata görünüyor mu?
wp-config.phpiçindeWP_DEBUGveWP_DEBUG_LOGaçık değilse ekranda yalnızca genel bir mesaj görürsünüz. wp-config.php ayarları yazısında bunun güvenli yapılışı var. - Sunucu ne diyor? Hosting panelindeki error log, çoğu 500 ve beyaz sayfa vakasını tek satırda çözer.
- Son değişiklik neydi? Eklenti güncellemesi, tema güncellemesi veya PHP sürümü değişikliği — üçü de en sık tetikleyicilerdir. Eklenti çakışması tespiti bu adımı sistematik hale getirir.
- Geri dönüş planınız var mı? Müdahaleden önce yedek: staging site kurulumu ile denemeleri canlı sitenin dışında yapabilirsiniz.
Site Hiç Açılmıyor: Kritik Hatalar
Bu grup, ziyaretçinin siteyi hiç göremediği durumlar. Sıra önemli: önce hatanın hangi katmandan geldiğini (PHP, sunucu, veritabanı, SSL) ayırın.
- Beyaz sayfa (WSOD) — genellikle PHP fatal error; hata günlüğü olmadan çözülmez.
- Memory limit hatası — bellek tükenmesi; limit, eklenti/kod tüketimi ve büyük veri birlikte incelenir.
- 500 Internal Server Error — sunucu tarafında genel çökme; .htaccess ve PHP sürümü ilk bakılacak yerler.
- 503 Service Unavailable — bakım kilidi veya PHP-FPM havuzunun dolması.
- Dosya izinleri — 403 ve yükleme hatalarının çoğunun asıl sebebi.
- SSL handshake failed — sertifika zinciri veya TLS sürümü uyuşmazlığı.
- 404 hatası — kalıcı bağlantı yapısı bozulduğunda tüm iç sayfalar birden kaybolur.
Site Açılıyor ama Yavaş
Yavaşlık tek bir sebeple açıklanmaz. Ölçmeden müdahale etmeyin: önce hangi metriğin kötü olduğunu (LCP mi, INP mi, sunucu yanıt süresi mi) belirleyin, sonra o katmana dokunun.
- Core Web Vitals ve INP — 2026 itibarıyla etkileşim gecikmesi en sık düşülen metrik; sebebi çoğunlukla JavaScript ve şişkin DOM.
- Genel hız optimizasyonu — önbellek, görsel formatı, kritik CSS.
- Admin paneli yavaşsa — ziyaretçiyle aynı kaynakları tüketebilir; olası nedenlerden biri veritabanı şişkinliğinin ilk belirtisidir.
- Veritabanı optimizasyonu ve revizyon temizliği —
wp_postmetavewp_optionstablolarındaki birikim. - Ortam kütüphanesi yavaşsa — binlerce görselde thumbnail üretiminin maliyeti.
- Bulanık görseller ve srcset — yanlış boyut seçimi hem görüntü hem bant genişliği sorunudur.
- WP-Cron — trafiği yüksek sitelerde isteklerle kontrol edilen ve zamanı gelen işleri çalıştıran cron ciddi yük üretir.
Güvenlik ve Giriş Tarafı
WordPress güvenliğinin büyük kısmı eklenti değil, yapılandırma işidir. Aşağıdaki sıra, saldırı yüzeyini en hızlı daraltan sıradır.
- Güvenlik sertleştirme kontrol listesi — tek yazıda toplu kontrol.
- wp-config.php güvenliği — anahtarlar, dosya düzenlemenin kapatılması, tablo ön eki.
- Güvenli giriş ayarları ve giriş adresini değiştirme — brute-force trafiğini kesmenin en ucuz yolu.
- Malware taraması — enfeksiyon sonrası temizliğin doğru sırası.
- Nonce, sanitize ve escape — kendi eklentinizi yazıyorsanız güvenlik burada başlar.
İndeksleme ve Teknik SEO
Bir WordPress sitesinde SEO sorunlarının çoğu içerikten değil, varsayılan ayarlardan gelir: gereksiz arşivlerin dizine girmesi, site haritasının üretilmemesi, taşıma sonrası kalan eski adresler.
- Kategori ve etiket indekslemesi — tek yazılık arşivleri özgün içerik, gezinme yararı ve arama amacıyla değerlendirin; otomatik noindex kuralı yoktur.
- XML site haritası ayarları — robots.txt’te tanımlı adres gerçekten üretiliyor mu, mutlaka açıp kontrol edin.
- robots.txt düzenleme — yanlış bir
Disallowsatırı tüm siteyi taramadan çıkarabilir. - 404 hatalarının kalıcı çözümü — yayında kalan kırık iç bağlantılar tarama bütçesini yer.
Taşıma, Staging ve Güncelleme
- Staging site kurulumu — canlıda deneme yapmayı bırakmanın tek yolu.
- Site taşıma sonrası hatalar — serileştirilmiş veri, sabit adresler ve karışık içerik uyarıları.
- Tema güncellemesi öncesi kontroller ve child theme — özelleştirmeleri güncellemede kaybetmemek için.
- Multisite — birden fazla siteyi tek kurulumda yönetmenin maliyeti ve sınırları.
- Mail gönderme sorunu — taşıma sonrası en sık gözden kaçan ve en geç fark edilen arıza.
Geliştirici Tarafı: Blok, API ve Otomasyon
Site sahibi tarafında işler oturduktan sonra WordPress bir uygulama platformu gibi kullanılabilir. Bu bölümdeki yazılar kod yazanlar için.
- REST API nedir ve özel endpoint yazımı
- Block theme ile tasarım ve Gutenberg’i verimli kullanma
- Block Bindings API, Interactivity API — dinamik blok üretiminin güncel yolu.
- Abilities API ve Connectors API — eklentilere yetenek tanımlama ve harici servis bağlama.
- WordPress 7.0 AI Client API ve 7.0 ile site sahipleri için değişenler
- WP-CLI komutları — 40 sitelik bir portföyü panel açmadan yönetmek.
Belirtiye Göre Nereden Başlanır?
Aşağıdaki tablo, sitede gördüğünüz belirtiyi en olası sebebe bağlar. Amaç kesin teşhis koymak değil, ilk bakılacak yeri daraltmak — bir WordPress arızasında kaybedilen zamanın çoğu yanlış katmanda aramakla geçer.
| Belirti | İlk bakılacak yer | Sık atlanan ayrıntı |
|---|---|---|
| Tamamen boş beyaz sayfa | PHP fatal error, hata günlüğü | Hata günlüğü kapalıysa ekranda hiçbir ipucu görünmez |
| Ana sayfa açılıyor, iç sayfalar 404 | Kalıcı bağlantı ayarları | Ayarları kaydetmek çoğu zaman tek başına yeterlidir |
| Yönetim paneli yavaş, site normal | Veritabanı ve otomatik yüklenen seçenekler | wp_options tablosundaki autoload verisi |
| Görsel yüklenmiyor, 403 alıyor | Dosya ve klasör izinleri | Sunucu taşındıysa sahiplik (owner) da değişmiş olabilir |
| Formlar çalışıyor ama e-posta gelmiyor | SMTP yapılandırması | PHP mail() çoğu paylaşımlı sunucuda sessizce engellenir |
| Güncellemeden sonra tasarım bozuldu | Tema özelleştirmeleri | Child theme kullanılmadıysa değişiklikler üzerine yazılır |
| Google eski adresleri gösteriyor | Yönlendirmeler ve site haritası | Site haritası adresi robots.txt’te yazıp gerçekte 404 verebilir |
Müdahale Etmeden Önce Üç Kural
1. Tek seferde tek değişiklik. Aynı anda PHP sürümünü yükseltip iki eklenti kapatırsanız, site düzeldiğinde hangisinin işe yaradığını bilemezsiniz — aynı arıza üç ay sonra tekrar eder.
2. Yedek almadan dosya düzenlemeyin. .htaccess, wp-config.php ve tema dosyaları bir karakterlik hatayla siteyi tamamen kapatır. Düzenlemeden önce dosyanın bir kopyasını web kökü dışında, erişimi sınırlı yedek alanında saklamak gerekir; sunulan .bak dosyası sırları açabilir.
3. Belirtiyi değil sebebi düzeltin. Bellek limitini sürekli yükseltmek, bellek tüketen eklentiyi bulmanın yerine geçmez. Aynı şekilde 404’leri tek tek yönlendirmek, bozuk kalıcı bağlantı yapısını onarmaz.
Bu Rehberi Nasıl Kullanmalı?
Akut bir sorun varsa yukarıdan aşağı değil, ikinci bölümden başlayın: siteyi ayağa kaldırın, sonra hız ve güvenlik bölümlerine dönün. Planlı bakım yapıyorsanız sıra tersine döner — önce staging kurun, sonra güncelleme ve sertleştirme adımlarını uygulayın. Sayfa, yeni yazılar eklendikçe güncelleniyor; bir konuda yazı bulamazsanız yorum bırakın, listeye ekleyeyim.
Resmî kaynak: WordPress sorun giderme dokümantasyonu
Kaynaklar ve İleri Okuma
Resmî dokümantasyon
Sitedeki ilgili rehberler
- Robots.txt ile AI Botlarını Yönetme Rehberi (2026 Güncel)
- Yapılandırılmış Veri Nedir? WordPress’te Şema Nasıl Eklenir?
- WordPress AI Engine Eklentisi: Kurulum ve 7 Kullanım
Canlı sitede log gerekirse WP_DEBUG_DISPLAY=false ve PHP display_errors kapalı kalmalıdır; log dosyası web’den erişilmemeli, inceleme bitince geçici debug ayarı kapatılmalıdır. 403 her zaman dosya izni, 404 her zaman permalink ve memory hatası yalnız düşük limit değildir; WAF, rota, sahiplik ve kodu ayırın. Giriş adresi değiştirmek MFA/yama/rate limit yerine geçmez. Hub bağlantıları teşhis seçenekleridir, her belirtilen nedenin kesin sonucu değildir.
