WordPress Site Sağlığı Uyarıları Ne Anlama Geliyor

WordPress yönetim paneline girdiğinizde ekranın üstünde kırmızı bir kutu görüyorsunuz: "Sitenizde çözülmesi gereken kritik sorunlar var." Araçlar > Site Sağlığı ekranına tıkladığınızda karşınıza uzun bir liste çıkıyor; bir kısmı "kritik sorun", bir kısmı "önerilen iyileştirme" başlığı altında. WordPress site sağlığı uyarıları gören hemen herkesin ilk tepkisi aynı oluyor: panik. Oysa bu ekranın en büyük tasarım sorunu, gerçekten sitenizi çökertecek bir eksikle sadece "olsa iyi olurdu" seviyesindeki bir öneriyi aynı kırmızı renkte göstermesi.

Bu yazıda o listeyi madde madde açıyoruz. Her uyarının ne anlama geldiğini, kaynağının sizde mi yoksa hosting sunucusunda mı olduğunu, gerçekten acil olup olmadığını ve nasıl çözüleceğini tek tek yazacağız. Yıllardır müşteri sitelerinde gördüğüm en yaygın durum şu: kullanıcı "kritik sorun" yazısını görüp saatlerce eklenti kurcalıyor, oysa uyarının kaynağı sunucudaki eksik bir PHP modülü ve çözümü destek talebine yazılacak tek bir cümle. Aşağıdaki tablo ve bölümler tam olarak bu ayrımı yapmanız için var.

Site Sağlığı Ekranı Nedir, Puanı Nasıl Hesaplanır#

Site Sağlığı, WordPress'in kendi içinde çalıştırdığı bir tanılama testleri koleksiyonudur. Araçlar > Site Sağlığı yolundan ulaşırsınız ve iki sekmesi vardır: Durum ve Bilgi.

Durum sekmesi testleri çalıştırır ve sonuçları üç grupta toplar:

• Kritik sorunlar — WordPress'in "bu ciddi" dediği maddeler.
• Önerilen iyileştirmeler — çalışmayı engellemeyen, iyileştirme öneren maddeler.
• Geçen testler — sorun bulunmayan kontroller (varsayılan olarak katlanmış gelir).

Bir dönem ekranın üstünde yüzdelik bir puan gösteriliyordu. Kullanıcılar bu yüzdeyi %100 yapmaya çalışıp gereksiz eklenti kurmaya başlayınca WordPress bu göstergeyi kaldırdı; bugün çoğu kurulumda sadece "İyi" veya "İyileştirme gerekiyor" şeklinde bir durum ifadesi görürsünüz. Bu değişikliğin nedeni önemli: puanı yükseltmek bir hedef değildir. Bazı maddeler sizin kurulum tercihinizden kaynaklanır ve hiçbir zaman yeşile dönmez, dönmesi de gerekmez.

Kritik sorunlar bölümü, testin status değeri critical dönen sonuçlarını gösterir. Bu etiketi WordPress çekirdeği ya da bir eklenti belirler. Yani "kritik" kelimesi sitenizin gerçek durumundan değil, testi yazan kişinin verdiği önem derecesinden gelir. Aynı test bazı ortamlarda hatalı pozitif üretebilir — özellikle döngüsel istek ve REST API testleri, güvenlik duvarı olan sunucularda site tamamen sağlıklıyken bile hata verebilir.

Uyarıları Önem ve Sorumluluk Sırasına Koyma#

Ekrandaki her maddeyi iki soruyla değerlendirin: kim çözebilir ve çözülmezse ne olur. Aşağıdaki tablo, sık karşılaşılan uyarıları bu iki eksene göre sıralıyor.

Bu tabloyu şöyle okuyun: en üstteki iki satır bugün çözülmeli, ortadakiler bu hafta içinde, en alttakiler ise "zamanı gelince". Kırmızı kutunun kendisi bu sıralamayı yapmaz, siz yapacaksınız.

Sunucu Kaynaklı Uyarılar: Kendiniz Çözemezsiniz#

Bu grubun ortak özelliği, çözümün WordPress panelinin dışında olmasıdır. Eklenti kurarak, tema değiştirerek veya ayar kurcalayarak bu maddeleri yeşile döndüremezsiniz.

Bir veya daha fazla önerilen modül eksik#

WordPress, PHP'nin belirli eklentilerini "önerilen" listesinde tutar: imagick, intl, zip, gd, curl, exif, mbstring, dom, openssl, sodium gibi. Uyarı genelde bunlardan birini işaret eder.

Hangisinin gerçekten önemli olduğu değişir:

• imagick eksik: Görsel yükleme çalışır ama küçük resim kalitesi düşer ve bazı formatlar işlenmez. Fotoğraf ağırlıklı bir sitede ciddidir.
• intl eksik: Çoğu site fark etmez; bazı çok dilli eklentiler tarih ve sıralama işlemlerinde hata verir.
• zip eksik: Eklenti/tema kurulumu ve yedekleme eklentileri bozulur. Bu gerçekten acildir.
• curl eksik: Dış bağlantı gerektiren her şey, ödeme altyapıları dahil, çöker.

Paylaşımlı hosting kullanıyorsanız cPanel > Select PHP Version (bazı kurulumlarda MultiPHP INI Editor yanındaki eklenti sekmesi) ekranından bu modülleri kendiniz işaretleyebilirsiniz. Modül listede yoksa sunucuda derlenmemiş demektir; destek talebi açmanız gerekir. Kendi sunucunuz varsa doğrudan kurarsınız:

# Ubuntu/Debian, PHP 8.2 örneği
sudo apt install php8.2-imagick php8.2-intl php8.2-zip php8.2-gd
sudo systemctl restart php8.2-fpm

# Yüklü modülleri doğrulama
php -m | grep -E 'imagick|intl|zip|gd|curl'

PHP sürümünüz güncel değil#

Bu uyarı hem güvenlik hem performans anlamına gelir. Ömrü dolmuş bir PHP sürümü artık güvenlik yaması almaz; ayrıca yeni sürümler ölçülebilir biçimde daha hızlıdır. Paylaşımlı hostingde bu ayar sizde: cPanel > Select PHP Version ekranından sürümü yükseltirsiniz. Ama körlemesine yükseltmeyin — eski bir tema veya eklenti yeni PHP'de ölümcül hata verebilir. Doğru sıra şudur:

1. Tam yedek alın (dosyalar + veritabanı).
2. Varsa bir kopya ortamda deneyin; wordpress-staging-ortami yazısı bu kopyayı nasıl kuracağınızı anlatıyor.
3. Sürümü bir basamak yükseltin, siteyi gezin, ödeme ve form akışlarını test edin.
4. Hata alırsanız geri dönün ve önce eklentiyi güncelleyin.

Yükseltme sonrası site beyaz ekrana düşerse panik yapmayın; wordpress-beyaz-ekran-hatasi yazısındaki adımlarla eski sürüme dönüp sorunlu bileşeni bulabilirsiniz.

Kalıcı nesne önbelleği kullanmalısınız#

Bu bir öneri, kritik sorun değil. WordPress her sayfa isteğinde veritabanına sorduğu bazı verileri bellekte tutabilir; bunun için Redis ya da Memcached gibi bir servis gerekir. Küçük bir kurumsal sitede fark hissedilmez. Ancak WooCommerce, üyelik sistemi veya çok sayıda özel alan kullanan sitelerde yönetim paneli belirgin şekilde hızlanır. Sunucuda Redis yoksa eklenti kurmak işe yaramaz; önce servisin hosting tarafında açılması gerekir. Kurulum tarafını redis-object-cache-wordpress yazısında adım adım anlattık.

SQL sunucusu güncel değil#

MySQL/MariaDB sürümünüzün WordPress'in önerdiği eşiğin altında olduğunu söyler. Sitenizi bozmaz, ancak eski sürümler bazı karakter setlerinde ve JSON sorgularında kısıtlıdır. Bu tamamen hosting tarafında bir işlemdir; sunucu genelini etkilediği için istek üzerine planlı yapılır.

Bağlantı Uyarıları: REST API, Loopback ve Zamanlanmış Görevler#

Bu üç test aynı kökten gelir: WordPress'in kendi kendine HTTP isteği atabilmesi gerekir.

"REST API beklenmeyen bir sonuç yaşadı" uyarısında WordPress /wp-json/ adresine istek atar ve JSON bekler. Beklenen yerine HTML ya da hata gelirse bu mesaj çıkar. En sık nedenleri: bir güvenlik eklentisinin REST API'yi kapatması, sunucudaki ModSecurity kuralının isteği engellemesi, yanlış kurulmuş bir yönlendirme veya .htaccess bozukluğu. Teşhis için tarayıcıda doğrudan adresi açın:

curl -I https://alanadiniz.com/wp-json/
curl -s https://alanadiniz.com/wp-json/ | head -c 200

200 OK ve JSON çıktısı geliyorsa test hatalı pozitiftir. 401, 403 ya da HTML dönüyorsa gerçek bir engel var demektir. REST API'nin ne işe yaradığını ve nerede kullanıldığını wordpress-rest-api yazısında bulabilirsiniz.

"Sitenizde döngüsel istek sorunu var" ise sunucunun kendi alan adına bağlanamadığını söyler. Genellikle sunucu üzerinde DNS'in alan adını dış IP'ye çözmesi ama güvenlik duvarının kendi IP'sine dönen isteği kapatması yüzünden olur. Sonucu şudur: eklenti güncelleme ekranı, tema düzenleyicinin hata yakalaması ve zamanlanmış görevler düzgün çalışmaz.

"Zamanlanmış bir olay geç çalışıyor" uyarısı WordPress'in sanal cron'unun tetiklenmediğini gösterir. WP-Cron ziyaretçi trafiğine bağlıdır; sitenize kimse girmezse görev çalışmaz. Doğru çözüm sanal cron'u kapatıp sunucu cron'una bağlamaktır:

// wp-config.php içine, "That's all" satırından önce
define( 'DISABLE_WP_CRON', true );

# cPanel > Cron Jobs veya sunucuda crontab -e
*/5 * * * * /usr/bin/php /home/kullanici/public_html/wp-cron.php >/dev/null 2>&1

Bu üç uyarı bir arada çıkıyorsa ve site dışarıya istek atamıyorsa, aynı kök neden zaman aşımı hatalarına da yol açar; curl-error-28-hatasi-wordpress yazısı bu tabloyu ayrıntılı işliyor.

WordPress Kaynaklı Uyarılar: Bunlar Sizde#

Etkin olmayan eklenti ve temalar#

WordPress kurulu ama pasif eklentileri güvenlik riski sayar, çünkü pasif bir eklentinin dosyaları hâlâ sunucudadır ve güncellenmediği için bilinen bir açık taşıyabilir. Saldırgan eklentiyi etkinleştirmek zorunda değildir; doğrudan dosyaya istek atar. Kullanmadığınız her eklentiyi ve temayı silin, devre dışı bırakmakla yetinmeyin. Yalnızca bir yedek tema bırakın.

Güncel olmayan WordPress sürümü#

Ana sürüm güncellemesi her zaman aynı gün yapılmalı demiyorum; ama güvenlik yaması sürümleri (üçüncü basamak) beklemeye gelmez. Güncelleme öncesi yedek almayı alışkanlık edinin. Güncelleme sonrası site açılmıyorsa wordpress-guncelleme-sonrasi-site-bozuldu yazısındaki geri alma adımları işinizi görür.

Hata ayıklama modu etkin#

Canlı sitede WP_DEBUG açık kalmışsa PHP hataları ziyaretçiye görünür; hata mesajları dosya yolunuzu, veritabanı tablo önekinizi ve eklenti sürümlerinizi açık eder. Doğru yapılandırma, hataları ekrana basmadan dosyaya yazmaktır:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Bu ayarla hatalar wp-content/debug.log dosyasına düşer. Sorun çözüldüğünde WP_DEBUG değerini false yapıp log dosyasını silin.

Arka plan güncellemeleri düzgün çalışmıyor#

Genellikle dosya sahipliği ve izin sorunudur. FTP ile yüklenen dosyalar web sunucusu kullanıcısına ait olmadığında WordPress yazma yetkisi bulamaz ve güncelleme ekranında FTP bilgisi ister. Doğru izin şeması dizinler için 755, dosyalar için 644'tür; ayrıntısı wordpress-dosya-izinleri yazısında.

Arama Motoru Görünürlüğü Uyarısı: Listedeki En Kritik Madde#

Site Sağlığı listesindeki en pahalı uyarı budur: "Sitenizin arama motorlarında görünürlüğü kapalı." WordPress kurulumu sırasında ya da geliştirme aşamasında Ayarlar > Okuma altındaki "Arama motorlarının bu siteyi dizine eklemesini engelle" kutusu işaretlenmiş ve yayına alırken kaldırılması unutulmuştur.

Bu kutu iki şey yapar: WordPress'in ürettiği robots.txt çıktısını tüm botlara kapatır ve sayfaların <head> bölümüne noindex etiketi koyar. Sonuç, sitenizin arama sonuçlarında hiç görünmemesidir — ve ekranda kırmızı bir hata çıkmadığı için aylarca fark edilmeyebilir. Kutuyu kaldırdıktan sonra kaynak koda bakıp noindex etiketinin gerçekten gittiğini doğrulayın. Sitenin Google'da hiç görünmemesinin bu ve diğer nedenlerini wordpress-sitem-googleda-cikmiyor yazısında tek tek eledik.

Bilgi Sekmesini Destek Talebinde Nasıl Kullanırsınız#

Site Sağlığı'nın ikinci sekmesi olan Bilgi, çoğu kullanıcının hiç açmadığı ama destek ekibinin en çok işine yarayan yerdir. Burada WordPress sürümü, etkin tema, tüm eklentiler ve sürümleri, sunucu bilgileri (PHP sürümü, bellek sınırı, max_execution_time, post_max_size), veritabanı sürümü, medya işleme kütüphaneleri ve dosya sistemi izinleri tek ekranda listelenir.

Sağ üstteki "Site sağlığı bilgisini panoya kopyala" düğmesi bu raporun tamamını metin olarak kopyalar. Destek talebi açarken "sitem açılmıyor" yazmak yerine bu raporu yapıştırırsanız çözüm süresi ciddi biçimde kısalır; ekip PHP sürümünü, bellek sınırını ve eklenti listesini sormak zorunda kalmaz. Bu rapor içinde parola veya API anahtarı yer almaz, ancak eklenti listenizi açık ettiği için herkese açık forumlarda paylaşırken dikkatli olun.

Puanı Yükseltmek İçin Sıralı Eylem Planı#

Aşağıdaki sırayı takip ederseniz listenin çoğu bir saat içinde temizlenir:

1. Ayarlar > Okuma altındaki arama motoru engelleme kutusunu kontrol edin.
2. Sitenin HTTPS ile açıldığını ve http:// adresinin https:// adresine yönlendiğini doğrulayın.
3. WordPress, tema ve eklentileri güncelleyin — önce yedek alarak.
4. Kullanmadığınız tüm eklenti ve temaları silin.
5. wp-config.php içinde WP_DEBUG değerinin canlıda kapalı olduğundan emin olun.
6. PHP sürümünü paneldeki güncel sürüme çıkarın, siteyi baştan sona test edin.
7. Eksik PHP modüllerini panelden işaretleyin; listede yoksa destek talebi açın.
8. WP-Cron'u sunucu cron'una bağlayın.
9. Kalan "önerilen iyileştirme" maddelerini ihtiyaç varsa ele alın; yoksa öylece bırakın.

Dokuzuncu madde en önemlisidir: listeyi tamamen boşaltmak hedef değildir. Bazı öneriler sizin site tipiniz için anlamsızdır. Aylık bakım planı kurmak isterseniz wordpress-guncelleme-yonetimi yazısındaki takvim mantığı iyi bir başlangıçtır.

Sıkça Sorulan Sorular#

Site sağlığı kritik sorun uyarısı sitemi kapatır mı#

Hayır, Site Sağlığı ekranı sadece bir rapordur ve hiçbir maddesi tek başına sitenizi kapatmaz. "Kritik" etiketi, testi yazan geliştiricinin verdiği önem derecesidir; sitenin gerçek durumunu ölçmez. Örneğin eksik bir PHP modülü uyarısı aylarca sorunsuz çalışan bir sitede de görünebilir. Yine de listeyi görmezden gelmek doğru değildir, çünkü içindeki bazı maddeler (HTTPS eksikliği, arama motoru engeli, güncel olmayan sürüm) gerçek ve ölçülebilir zarar verir.

Site sağlığı puanı düşük çıkıyor nasıl yükseltirim#

Puanı yükseltmenin doğru yolu maddeleri önem sırasına koyup gerçek olanları çözmek, sahte pozitifleri ise bilinçli olarak bırakmaktır. Güncellemeleri yapın, pasif eklenti ve temaları silin, PHP sürümünü yükseltin, hata ayıklama modunu kapatın. Nesne önbelleği gibi öneriler sunucu tarafında ilgili servis yoksa kapanmaz ve bunun için eklenti kurmak faydadan çok zarar getirir. WordPress'in yüzdelik puanı kaldırmasının sebebi tam olarak bu takıntıydı; hedefiniz yeşil ekran değil, çalışan ve güvenli bir site olsun.

REST API uyarısı çıkıyor ama sitem çalışıyor ne yapmalıyım#

Önce testin hatalı pozitif olup olmadığını doğrulayın: tarayıcıda https://alanadiniz.com/wp-json/ adresini açın. JSON çıktısı geliyorsa REST API çalışıyordur ve uyarı, WordPress'in kendi kendine attığı isteğin sunucu güvenlik duvarında engellenmesinden kaynaklanıyordur. JSON yerine hata veya boş sayfa geliyorsa gerçek bir sorun vardır; önce güvenlik eklentilerini geçici olarak devre dışı bırakıp tekrar deneyin. Sorun devam ederse sunucudaki ModSecurity kuralları veya .htaccess yönlendirmeleri incelenmelidir; bu aşamada hosting desteğine yazmak en hızlı yoldur.

Eksik PHP modülü uyarısını kendim çözebilir miyim#

Paylaşımlı hostingde çoğu zaman evet, cPanel üzerindeki PHP sürüm seçme ekranından modülü işaretleyerek açabilirsiniz. Modül listede hiç görünmüyorsa sunucuda o modül derlenmemiş demektir ve panelden açmanız mümkün değildir; hosting desteğine talep açmanız gerekir. Kendi VDS'inizde ise paket yöneticisiyle kurup PHP-FPM servisini yeniden başlatmanız yeterlidir. Modülü kurduktan sonra Site Sağlığı ekranını yenilemeyi ve php -m çıktısıyla doğrulamayı unutmayın.

Kalıcı nesne önbelleği önerisini görmezden gelebilir miyim#

Evet, küçük ve orta ölçekli çoğu site için bu öneri güvenle atlanabilir. Nesne önbelleği, veritabanına çok sayıda tekrar eden sorgu atan sitelerde işe yarar: WooCommerce mağazaları, üyelik siteleri, çok yazarlı büyük bloglar. Statik içerikli kurumsal bir sitede ölçülebilir bir kazanç sağlamaz. Ayrıca sunucuda Redis veya Memcached servisi kurulu değilse ilgili eklentiyi kurmak hiçbir şey yapmaz, sadece bir eklenti daha eklemiş olursunuz.

Zamanlanmış olay geç çalışıyor uyarısı neden çıkıyor#

Bu uyarı WordPress'in sanal cron sisteminin tetiklenmediğini gösterir ve en yaygın nedeni düşük trafiktir. WP-Cron gerçek bir zamanlayıcı değildir; sayfa isteği geldiğinde çalışır, dolayısıyla siteye kimse girmezse zamanlanmış görevler birikir. Yedekleme, zamanlanmış yazı yayını ve e-posta gönderimi bu yüzden gecikir. Kalıcı çözüm DISABLE_WP_CRON tanımını ekleyip sunucu üzerinde beş dakikalık gerçek bir cron görevi kurmaktır.

Sitem HTTPS kullanmıyor uyarısı için ne yapmalıyım#

Bu listedeki en acil maddelerden biridir ve mutlaka çözülmelidir. Önce hosting panelinizden ücretsiz bir sertifika kurun; çoğu cPanel kurulumunda otomatik sertifika özelliği zaten açıktır ve alan adı doğru yönlendiğinde kendiliğinden çalışır. Sertifika kurulduktan sonra WordPress Ayarlar > Genel altındaki iki adresi https:// olarak güncelleyin ve http adresinden https adresine kalıcı yönlendirme ekleyin. Son adım karışık içerik kontrolüdür: sayfa kaynağında http:// ile başlayan görsel ve betik bağlantısı kalmışsa tarayıcı kilit simgesini göstermez.

Site sağlığı bilgisini destek ekibiyle paylaşmak güvenli mi#

Genel olarak güvenlidir, çünkü rapor parola, API anahtarı veya veritabanı şifresi içermez. Raporda sunucu yolu, PHP ayarları, eklenti ve tema listesi ile sürümleri yer alır. Hosting desteğine gönderirken sorun yoktur ve teşhisi ciddi biçimde hızlandırır. Ancak herkese açık forumlarda paylaşırken dikkatli olun: eklenti sürüm listesi, sitenizde hangi bilinen açığın bulunabileceğini bir saldırgana doğrudan söyler.

Kapanış#

Site Sağlığı ekranı kötü bir araç değil; sadece hepsini aynı renge boyadığı için yanlış anlaşılıyor. Doğru okuma yöntemi şu: önce arama motoru görünürlüğü ve HTTPS maddelerine bakın, sonra güncellemeler ve pasif eklentileri temizleyin, ardından PHP sürümü ve modüllerini düzeltin, en son da önbellek gibi öneri niteliğindeki maddeleri değerlendirin. Listede kalan birkaç madde, sitenizin sağlıksız olduğu anlamına gelmez; sadece o önerinin sizin kurulumunuz için anlamlı olmadığını gösterir.

Bu ekranın yarısı hosting tarafında çözülen maddelerden oluşuyor: eksik PHP modülleri, veritabanı sürümü, nesne önbelleği servisi, döngüsel istek engelleri. Bu maddelerin sizden hiç talep gelmeden hazır geldiği bir ortamda çalışmak istiyorsanız WordPress hosting paketleri bu bileşenleri kurulu şekilde sunar. Güncelleme, yedek ve uyumluluk kontrolünü düzenli olarak birinin üstlenmesini istiyorsanız WordPress bakım hizmeti tam olarak bu takvimi yürütür. Kendi sunucunuzda çalışıyor ve PHP modülü, cron, Redis gibi konularda destek arıyorsanız sunucu yönetimi hizmetimiz bu işleri devralır; sitenizi yeni bir ortama taşımanız gerekiyorsa site taşıma sayfasındaki süreç kesintisiz geçişi anlatıyor.