WordPress Site Sağlığı Raporu Nasıl Okunur?

WordPress Site Sağlığı raporu nasıl okunur?

WordPress yönetim panelinde Araçlar > Site Sağlığı ekranını açtığınızda gördüğünüz renkler, sitenizin tek bir puanla ölçülen genel notu değildir. PHP sürümünden HTTPS yapılandırmasına, REST API erişiminden zamanlanmış görevlere kadar farklı kontrollerin sonuçları burada toplanır.

Kırmızı, turuncu ve yeşil işaretler ilk bakışta gereğinden fazla telaş yaratabiliyor. Destek ekibindeyken bir müşteri, “Site sağlığım yüzde 82, Google bizi cezalandıracak mı?” diye sormuştu. WordPress Site Sağlığı bir SEO puanı değildir. Hosting performansına karar vermek için de tek başına yeterli sayılmaz.

Şöyle anlatayım: Bu ekranı bir arıza panosu gibi düşünün. Hangi konunun incelenmesi gerektiğini gösterir; her uyarının etkisini ise sitenizin yapısına bakarak değerlendirmeniz gerekir.

Site Sağlığı ekranında hangi bölümler var?

WordPress, Site Sağlığı bölümünü iki ana sekmede sunar:

• Durum: WordPress’in otomatik kontrollerini, kritik sorunları ve önerilen iyileştirmeleri gösterir.
• Bilgi: Sunucu, WordPress, tema, eklenti, veritabanı ve dosya sistemi hakkında daha teknik ayrıntılar sunar.

Durum sekmesi günlük kullanımda daha anlaşılırdır. Bilgi sekmesi ise destek bileti açarken, taşıma planlarken veya bir geliştiriciyle çalışırken ciddi zaman kazandırır. Buradaki ayrıntıları kopyalayıp paylaşabilirsiniz; yine de alan adı, dosya yolu, sunucu adı ve e-posta adresi gibi bilgileri göndermeden önce kontrol edin.

Kritik sorunlar

Kırmızı işaretli bir kontrol genellikle güvenlik, güncelleme, HTTPS veya sitenin temel işlevleriyle ilgilidir. Burada “site şu anda kesin bozuk” anlamı aramayın. Daha doğru sorular şunlardır: Bu durum saldırı yüzeyini artırıyor mu? Güncellemeleri engelliyor mu? Ziyaretçinin temel işlemlerini bozuyor mu?

WordPress sürümünün güncel olmaması, destek dışı bir PHP sürümünün kullanılması veya HTTPS’in düzgün çalışmaması gerçekten önceliklidir. Bir eklentinin güncelleme sunucusuna bağlanamaması ise WordPress.org tarafındaki geçici bir ağ probleminden kaynaklanıyorsa aynı ağırlıkta değerlendirilmemelidir.

Önerilen iyileştirmeler

Turuncu veya sarı uyarılar çoğu zaman sitenin çalışmasını hemen durdurmaz. Kalıcı nesne önbelleğinin bulunmaması, otomatik güncellemelerin sınırlı olması ya da bazı yapılandırma tercihlerinin önerilmemesi bu alanda görülebilir.

“Uyarıyı kaldırmak” ile “sorunu çözmek” aynı şey değildir. Kalıcı nesne önbelleği önerisi gördüğünüzde rastgele bir cache eklentisi kurup raporu yeşile çevirmeye çalışmayın. Sunucunuz Redis veya Memcached sunuyor mu, mevcut sayfa önbelleğiyle çakışır mı, WooCommerce oturumlarını etkiler mi; önce bunlara bakın.

Başarılı testler

Yeşil kontroller iyi bir işarettir, fakat kusursuzluk belgesi değildir. WordPress’in HTTPS’i, güncelleme bağlantısını ve bazı temel yapılandırmaları olumlu test etmesi, gerçek kullanıcı deneyiminin de iyi olduğu anlamına gelmez.

Bir sayfanın TTFB değeri yüksek olabilir, veritabanı sorguları yavaş çalışabilir veya ödeme adımı JavaScript hatası verebilir. Site Sağlığı bunların hepsini ölçmez. Performans için sunucu logları, tarayıcı geliştirici araçları, gerçek kullanıcı ölçümleri ve gerektiğinde mtr gibi araçlar gerekir.

Kırmızı uyarıyı görür görmez eklenti kurmayın

Site Sağlığı raporundaki her bildirim aynı aciliyete sahip değil. Ben destek akışımda uyarıları dört soruyla sınıflandırıyorum:

1. Bu sorun ziyaretçinin siteyi kullanmasını engelliyor mu?
2. Güvenlik veya veri kaybı riski oluşturuyor mu?
3. Güncelleme, yedekleme ya da zamanlanmış görevleri etkiliyor mu?
4. Sorun sürekli mi, yoksa geçici bir bağlantı hatası mı?

“REST API beklenmeyen bir yanıt döndürdü” uyarısı buna iyi bir örnektir. Gutenberg editörü, bazı bloklar, WooCommerce işlemleri ve harici entegrasyonlar REST API’ye ihtiyaç duyabilir. Fakat yalnızca Site Sağlığı testinin başarısız olması, bütün REST isteklerinin çalışmadığını kanıtlamaz.

Önce tarayıcı geliştirici araçlarında ilgili isteğin HTTP durum koduna bakın. Ardından güvenlik eklentisinin engelleme kaydını, web sunucusu loglarını ve varsa CDN veya WAF kurallarını inceleyin. Uyarıyı yalnızca gizleyen bir eklenti çözüm değildir.

En sık görülen kontrolleri tek tek okuyalım

WordPress, tema ve eklentiler güncel mi?

Site Sağlığı güncel olmayan bileşenleri gösterdiğinde ilk iş yedek almaktır. Üretim sitelerinde “hepsini güncelle” düğmesine basmadan önce PHP sürümü, tema uyumluluğu, özel kodlar ve WooCommerce sürümü kontrol edilmelidir.

Ben güncelleme öncesinde en azından veritabanı dışa aktarımını alırım. WP-CLI kullandığım bir sunucuda temel kontrol şu şekilde:

wp core version
wp plugin list --update=available
wp theme list --update=available
wp db export /var/backups/site-before-update.sql

İlk üç komut bekleyen güncellemeleri ve sürümleri gösterir; son komut veritabanını SQL dosyasına aktarır. Dosyanın gerçekten oluştuğunu ve geri döndürülebilir olduğunu ayrıca kontrol edin. Aynı diskte duran, hiç denenmemiş bir SQL dosyasına tek başına yedek demek beni hâlâ huzursuz ediyor.

Bir taşıma sırasında müşterinin “yedeğimiz var” dediği klasörü açtığımda dosyaların bulunduğunu, fakat kullanılabilir bir veritabanı çıktısının olmadığını görmüştüm. Geri dönüş gerektiğinde klasör boş değildi; yine de işe yaramıyordu. O günden beri yedeği yalnızca oluşturulmuş dosya olarak değil, geri yüklenebilen bir kopya olarak değerlendiriyorum.

PHP sürümü ve bellek sınırı

PHP sürümü hem güvenlik hem de uygulama uyumluluğu açısından önemlidir. Daha yeni bir sürüme geçmeden önce tema ve eklentilerin destek durumunu kontrol edin. Bir sitenin PHP 8.3 ile çalışabilmesi, eski bir eklentinin sessizce bozulmayacağı anlamına gelmez.

WP_MEMORY_LIMIT veya memory_limit uyarısı görüyorsanız değeri rastgele yükseltmeyin. Daha fazla bellek, hatalı bir sorgunun veya gereksiz döngünün nedenini ortadan kaldırmaz. Bir destek biletinde yalnızca memory_limit artırılması istenmişti; inceleyince rapor eklentisinin WHERE koşulu olmadan büyük bir tabloyu taradığını bulmuştum. Belleği artırmak siteyi kısa süre rahatlatırdı, asıl problemi değil.

HTTPS ve güvenli bağlantı

HTTPS uyarısı varsa sertifikanın geçerli olup olmadığını, alan adının doğru sertifikaya yönlenip yönlenmediğini ve HTTP’den HTTPS’e yönlendirmenin düzgün çalışıp çalışmadığını inceleyin. CDN, reverse proxy veya load balancer kullanılıyorsa WordPress’in dışarıdan HTTPS gördüğünden emin olun.

wp-config.php içinde sabitlenmiş eski bir siteurl veya home adresi, yanlış yönlendirme döngülerine neden olabilir. Bu değerleri değiştirmeden önce veritabanı yedeği alın. WordPress’in URL değerlerini görmek için:

wp option get home
wp option get siteurl

Çıktıda https:// bulunması tek başına yeterli değildir. Sayfa kaynaklarında veya tarayıcının ağ sekmesinde HTTP kaynakları kalmışsa karma içerik devam edebilir.

REST API ve loopback istekleri

Loopback isteği, sitenin kendisine HTTP üzerinden ulaşarak WordPress’in arka plandaki işlerini çalıştırabildiğini test eder. Zamanlanmış görevler, bazı bakım işlemleri ve eklentilerin arka plan çağrıları bundan etkilenebilir.

Başarısızlığın yaygın nedenleri arasında güvenlik eklentisinin sunucunun kendi isteklerini engellemesi, hatalı DNS, SSL doğrulama problemi, PHP fatal error, düşük zaman aşımı ve reverse proxy yapılandırması bulunur. Sunucuda ilk baktığım yerlerden biri PHP-FPM ve web sunucusu loglarıdır. Siteye dışarıdan HTTP isteği göndermek için şu kontrolü kullanabilirsiniz:

curl -I https://example.com/wp-json/

Burada 200 veya bazı yapılandırmalarda 3xx görmek tek başına her şeyi kanıtlamaz; fakat 403, 404, 500 ve 502 kodları araştırma yönünü daraltır. Gerçek alan adınızı kullanın ve üretim sisteminde arka arkaya yoğun test yapmayın.

REST API bağlantı sorunlarında WordPress Veritabanı Bağlantı Hatası: 5 Çözüm başlığındaki veritabanı ve uygulama logu kontrolleri de işinize yarayabilir. REST isteği veritabanına ulaşamıyorsa raporda görünen hata yalnızca ağ katmanına bakılarak çözülemez.

Zamanlanmış görevler ve WP-Cron

WP-Cron, klasik sistem cron’u gibi sabit aralıklarla çalışan bir servis değildir. Genellikle siteye gelen bir istek sırasında tetiklenir. Trafiği düşük sitelerde görevler gecikebilir; yoğun sitelerde ise gereğinden fazla cron çağrısı oluşabilir.

Bekleyen görevleri WP-CLI ile listeleyebilirsiniz:

wp cron event list --fields=hook,time_gmt,interval

Bu komut hook adını, bir sonraki çalışma zamanını ve varsa aralığı gösterir. Daha geniş çıktı gerektiğinde alan filtresini kaldırmanız yeterli:

wp cron event list

Çıktıda aynı hook’un çok sayıda birikmesi, görevin çalışamadığını veya bir eklentinin sürekli yeni görev oluşturduğunu düşündürür. Bir görevi silmeden önce hangi eklentinin oluşturduğunu bulun. Rastgele cron temizliği, WooCommerce e-postalarını veya sipariş işlemlerini bozabilir.

Kalıcı nesne önbelleği

Site Sağlığı, kalıcı nesne önbelleği bulunmadığında bunu öneri olarak gösterebilir. Redis gibi bir sistem, veritabanından tekrar tekrar okunacak seçenekleri ve sorgu sonuçlarını bellekte tutabilir. Bu yapı sayfa önbelleğiyle aynı işi yapmaz.

Kalıcı önbellek yok diye site mutlaka yavaştır denemez. Küçük ve düşük trafikli bir sitenin asıl darboğazı büyük bir görsel, kötü yazılmış bir eklenti veya yavaş bir harici API olabilir. WooCommerce sepet ve kullanıcı oturumlarında cache kuralları dikkatle hazırlanmalıdır.

Bilgi sekmesi destek biletini kısaltır

Destek ekibine yalnızca “Site sağlığında hata var” yazmak yerine Bilgi sekmesindeki ilgili bölümü paylaşmanız teşhisi hızlandırır. WordPress sürümü, PHP sürümü, sunucu yazılımı, veritabanı sürümü, aktif tema, eklentiler ve dosya sistemi bilgisi burada görünür.

Şifre, API anahtarı veya veritabanı parolası bu ekranda normalde açık şekilde bulunmamalıdır; yine de dışarı aktardığınız metni gözden geçirin. Gereksiz tüm bilgileri göndermek yerine hatayla ilişkili bölümleri paylaşmak daha güvenlidir.

WordPress ve PHP sürümünü terminalden de kontrol edebilirsiniz:

wp core version
php -v

Bu çıktılar yalnızca sürümü gösterir. Sunucuda birden fazla PHP sürümü varsa komut satırındaki php -v ile web sitesinin kullandığı PHP sürümü farklı olabilir. Bu ayrım özellikle paylaşımlı hosting ortamlarında kolayca gözden kaçar.

Site Sağlığı raporu ile performans raporu aynı şey değil

Site Sağlığı; yapılandırma, güvenlik ve WordPress’in temel çalışma koşulları hakkında sinyal verir. Sayfa yükleme süresini, gerçek ziyaretçilerin bağlantı kalitesini veya Google arama trafiğini bütün ayrıntılarıyla ölçmez.

Bir site sağlıklı görünüp yavaş olabilir. Ana sayfadaki ürün sorgusu 4 saniye sürüyorsa WordPress’in HTTPS, REST API ve güncelleme testleri başarılı çıksa bile ziyaretçi beklemek zorunda kalır.

Arama görünürlüğünü değerlendirmek için Google Search Console Performans Raporu Nasıl Okunur? başlığındaki tıklama, gösterim, sorgu ve sayfa ayrımlarına bakmak gerekir. Site Sağlığı’ndaki yeşil işaret, organik trafiğin iyi olduğunu söylemez; iki ekran farklı sorulara cevap verir.

Hosting kaynaklı bir şüphe varsa CPU, RAM, disk I/O, PHP-FPM yoğunluğu ve web sunucusu loglarını ayrıca inceleyin. Kendi lab ortamımda bile “site yavaş” demeden önce mtr, web sunucusu erişim logu ve veritabanı sorgu süresini ayrı ayrı kontrol ederim. Tek bir renkli uyarıya bakarak altyapıyı suçlamak teşhisi genellikle uzatır.

Uyarı görüldüğünde uygulanacak güvenli sıra

1. Mesajın tamamını okuyun. Kırmızı başlık kadar açıklama ve önerilen eylem de önemlidir.
2. Değişiklikten önce yedek alın. PHP, tema, eklenti veya HTTPS yapılandırmasına dokunuyorsanız geri dönüş yolunuz olsun.
3. Staging ortamında doğrulayın. Üretim sitesinde eklenti kapatıp açarak rastgele denemeler yapmayın.
4. Loglara bakın. 500 hatası, REST problemi ve loopback başarısızlığı çoğu zaman loglarda daha açık görünür.
5. Tek değişiklik yapın. Aynı anda beş eklentiyi kapatırsanız hangisinin sorunu düzelttiğini anlayamazsınız.
6. Uyarıyı tekrar test edin. Düzeltme sonrası Site Sağlığı ekranını yenileyin; ardından sitenin gerçek iş akışını da deneyin.

Geri dönüş planı burada özellikle önemlidir. Yedekleme konusunda daha önce boş bir klasörün “yedek” sanıldığını gördüm; taşıma sırasında geri dönmek gerektiğinde dosya vardı ama kullanılabilir bir veritabanı yoktu. Bu yüzden güncelleme öncesinde yalnızca dosya ve veritabanı çıktısını değil, mümkünse küçük bir geri yükleme provasını da planlarım.

WordPress Site Sağlığı raporu ne zaman ciddiye alınmalı?

Güvenlik güncellemesi yapılamıyorsa, PHP sürümü destek dışıysa, HTTPS yanlışsa, loopback ve REST API hataları sitenin iş akışını etkiliyorsa veya cron görevleri birikiyorsa beklemeyin. Bunlar raporun rengi değişsin diye değil, sitenin çalışma koşulları bozulabileceği için önceliklidir.

Yalnızca kalıcı nesne önbelleği önerisi veya otomatik güncelleme tercihi görüyorsanız önce sitenizin ihtiyaçlarını değerlendirin. Her öneriyi uygulamak zorunda değilsiniz; fakat neden uygulamadığınızı bilmeniz gerekir.

Benim pratik kontrolüm şu: Site Sağlığı ekranını açarım, kırmızı maddeleri önem sırasına dizerim, Bilgi sekmesinden teknik bağlamı çıkarırım, sonra log ve gerçek kullanıcı akışıyla karşılaştırırım. Yeşil ekranı görünce işi bitmiş saymam. Sepete ürün ekleme, iletişim formu, yönetici girişi ve e-posta gönderimi de çalışıyor mu; asıl cevap oradadır.

Sık Sorulan Sorular

WordPress Site Sağlığı raporundaki kırmızı uyarı siteyi kapatır mı?

Her kırmızı uyarı sitenin hemen kapanacağı anlamına gelmez. Güvenlik, HTTPS, PHP uyumluluğu, REST API veya güncelleme sorunları temel işlevleri etkileyebileceği için açıklamayı ve logları gecikmeden incelemek gerekir.

WordPress Site Sağlığı puanı SEO sıralamasını etkiler mi?

Site Sağlığı ekranındaki renk veya genel durum, Google’da kullanılan doğrudan bir sıralama puanı değildir. Yine de bozuk HTTPS, yavaş sunucu, erişilemeyen sayfalar veya çalışmayan kullanıcı akışları SEO’yu ve dönüşümleri dolaylı olarak etkileyebilir.

REST API hatası nasıl düzeltilir?

Önce /wp-json/ adresinin HTTP durum kodunu, güvenlik eklentisi kayıtlarını, web sunucusu loglarını ve SSL yapılandırmasını kontrol edin. 403, 500 veya 502 gibi kodun kaynağı bulunmadan eklenti kapatıp açmak kalıcı çözüm sağlamaz.

Site Sağlığı raporu ne sıklıkla kontrol edilmeli?

Güncelleme, PHP sürümü değişikliği, taşıma veya güvenlik yapılandırması sonrasında mutlaka kontrol edin. Normal sitelerde ayda bir bakmak ve kritik bildirimleri e-posta ya da izleme sistemi üzerinden takip etmek pratik bir düzendir.