WordPress Sorun Giderme için Sağlık Kontrolü Nasıl Yapılır (2025 Rehberi)

Bir WordPress sağlık kontrolü, sitenizin PHP sürümünü, veritabanı bütünlüğünü, aktif eklentileri, tema uyumluluğunu, sunucu ortamını ve güvenlik durumunu — WordPress yönetici panelinden veya özel araçlar aracılığıyla — sistematik olarak değerlendiren bir tanılama sürecidir. Bu kontrolü düzenli olarak çalıştırmak zincirleme hataları önler, sıralama sırasında performans darboğazlarını önceden tespit eder ve güvenlik açıklarını ihlale dönüşmeden ortaya çıkarır.

Yerleşik Site Health aracı (WordPress 5.2’de tanıtıldı), deneyimli geliştiricilerin herhangi bir sorun giderme iş akışında ilk başvuru noktası olarak kullandığı otomatik bir durum raporu ve ham hata ayıklama bilgisi paneli sunar. Health Check & Troubleshooting eklentisiyle birlikte, canlı siteye dokunmadan yalıtılmış bir oturumda üretim sorunlarını yeniden oluşturabilirsiniz — bu özellik, WordPress hata ayıklamasındaki en büyük riski ortadan kaldırır: siz araştırırken gerçek ziyaretçiler için her şeyi bozmak.

WordPress Sağlık Kontrollerinin Çoğu Kılavuzun Kabul Ettiğinden Daha Fazla Önem Taşımasının Nedeni

Çoğu eğitim, Site Health’i bir kez işaretlenecek bir kontrol listesi olarak ele alır. Pratikte ise bu, sürekli bir operasyonel sinyaldir. Google’ın Core Web Vitals’ı yavaş veya kararsız siteleri doğrudan cezalandırır. Bilinen bir CVE’ye sahip tek bir güncel olmayan eklenti, kamuya açıklanmasından saatler içinde sitenin tamamen ele geçirilmesiyle sonuçlanabilir. Sunucunuz ile bir eklentinin minimum gereksinimi arasındaki PHP sürümü uyumsuzlukları, ölümcül bir hata vermeden çok önce performansı sessizce düşürür.

İyi yapılandırılmış bir VPS Hosting ortamında çalışmak, PHP sürümleri, sunucu düzeyinde önbellekleme ve güvenlik sertleştirmesi üzerinde doğrudan kontrol sağlar — paylaşımlı ortamların sağlayamadığı bir kontrol. Aşağıda açıklanan sağlık kontrolü iş akışı, SSH erişiminizin veya sunucu düzeyindeki ayarları değiştirebilen bir kontrol panelinizin olduğunu varsayar; bu, herhangi bir üretim WordPress dağıtımı için doğru temel çizgidir.

Adım 1: Yerleşik WordPress Site Health Aracına Erişin

WordPress yönetici panelinizde Araçlar > Site Health bölümüne gidin. WordPress hemen otomatik kontrolleri çalıştırmaya başlayacak ve Durum sekmesini önem derecesine göre kategorize edilmiş sonuçlarla dolduracaktır.

Bu adım için herhangi bir eklenti gerekmez. Site Health, temel bir işlevdir ve sonuçları sunucu tarafında oluşturulur; yani gerçek çalışma zamanı ortamını yansıtır — simüle edilmiş bir ortamı değil.

Site Health’in arka planda gerçekte neyi kontrol ettiği:

• PHP sürümü, bellek sınırı ve maksimum yürütme süresi
• Aktif WordPress sürümü ile en son kararlı sürüm karşılaştırması
• REST API’nin erişilebilir olup olmadığı ve geçerli yanıtlar döndürüp döndürmediği
• Zamanlanmış cron görevi yürütme (wp-cron) durumu
• HTTPS zorunluluğu ve SSL sertifikası geçerliliği
• debug.log dosyasının genel erişime açık bir konumda bulunup bulunmadığı
• Geri döngü isteği kapasitesi (arka plan güncellemeleri ve eklenti kurulumları için gereklidir)
• Veritabanı sunucusu sürümü ve WordPress minimum gereksinimlerini karşılayıp karşılamadığı
• Hassas yollar için dosya ve dizin izinleri

Adım 2: Site Health Durum Raporunu Doğru Yorumlayın

Durum sayfası bulguları üç katmana ayırır. Her katmanın gerçekte ne anlama geldiğini — ve ne anlama gelmediğini — anlamak hem rehaveti hem de gereksiz paniği önler.

Acil dikkat gerektiren kritik sorunlar:

• Güncel olmayan PHP sürümü — PHP 7.4, Kasım 2022’de kullanım ömrünü tamamladı. Bunu çalıştırmak güvenlik yaması almadığınız anlamına gelir. WordPress 6.x resmi olarak PHP 8.1 veya 8.2’yi önerir.
• Hâlâ yüklü olan etkin olmayan eklentiler — Etkin olmayan eklentiler dosya sistemi tarafından hâlâ okunabilir ve istismar edilebilir kod içerebilir. Yalnızca devre dışı bırakmayın, silin.
• REST API engellendi — Birçok modern eklenti, blok düzenleyici (Gutenberg) ve WooCommerce, REST API kullanılabilirliğine bağlıdır. Engellenen bir REST API, izlenmesi son derece güç sessiz hatalara yol açar.
• Geri döngü isteği başarısızlığı — WordPress kendisine geri döngü HTTP isteği yapamıyorsa, otomatik arka plan güncellemeleri ve zamanlanmış görevler sessizce başarısız olur.
• Canlı sitede etkin WP_DEBUG — Hata ayıklama modu, hassas yapılandırma verilerini ve yığın izlerini debug.log dosyasına yazar. Bu dosya, sunucu düzeyinde erişim kısıtlamaları olmadan wp-content/ içindeyse herkese açık olarak okunabilir.

Sıkça gözden kaçan bir uç durum: Site Health, herhangi bir nesne önbelleği algılandığında — dosya tabanlı bir önbellek dahil — nesne önbellekleme için “İyi” durumu bildirir. Yüksek trafikli sitelerde dosya tabanlı nesne önbellekleme, I/O yükünü azaltmak yerine artırabilir. Doğru çözüm, Site Health’in sağlayamayacağı sunucu düzeyinde yapılandırma gerektiren bir Redis veya Memcached arka ucudur.

Adım 3: Hata Ayıklama Bilgisi Panelini Çıkarın ve Kullanın

Site Health sayfasındaki Bilgi sekmesine tıklayın. Bu panel, ham ortam verilerini ortaya koyduğu için sorun gidermede Durum sekmesinden tartışmasız daha değerlidir.

Temel bölümler ve nelere dikkat edilmesi gerektiği:

• WordPress — Aktif temayı, çoklu sitenin etkin olup olmadığını ve WP_DEBUG‘nin aktif olup olmadığını doğrular.
• Dizinler ve Boyutlar — wp-content/uploads/‘nin disk I/O veya yedekleme süreçlerini zorlayan bir boyuta ulaşıp ulaşmadığını ortaya koyar.
• Aktif Eklentiler — Her aktif eklentiyi sürümüyle birlikte listeler. Bilinen CVE’ler için WordPress Güvenlik Açığı Veritabanı’na (wpscan.com) karşı çapraz referans verin.
• Sunucu — PHP sürümünü, PHP bellek sınırını, maksimum yükleme boyutunu, maksimum yürütme süresini ve mod_rewrite veya eşdeğer URL yeniden yazmanın aktif olup olmadığını gösterir.
• Veritabanı — MySQL veya MariaDB sürümünü ve veritabanı karakter setini doğrular. utf8mb4 tam emoji ve çok dilli destek için gereklidir; utf8 (3 bayt) belirli karakterleri sessizce keser.
• Zorunlu Kullanım Eklentileri — Çoğunlukla göz ardı edilir. MU eklentileri diğer tüm eklentilerden önce yüklenir ve yönetici arayüzünden devre dışı bırakılamaz. Bir hosting sağlayıcısı bir MU eklentisi enjekte ettiyse (yönetilen hostingde yaygındır), burada görünür.

“Site bilgilerini panoya kopyala” düğmesinin pratik kullanımı:

Bir destek talebi açarken veya geliştirici forumuna yazı gönderirken bu çıktıyı doğrudan yapıştırın. Temel ortam sorularının gidip gelmesini ortadan kaldırır ve deneyimli mühendislerin yapılandırma anormalliklerini hemen fark etmesini sağlar — örneğin WooCommerce minimum 128M gerektirirken memory_limit‘nin 40M olması veya büyük bir içe aktarma işlemi 300 gerektirirken max_execution_time‘nin 30 saniye olması.

Adım 4: Güvenli Mod Hata Ayıklaması için Health Check & Troubleshooting Eklentisini Kullanın

Health Check & Troubleshooting eklentisi (WordPress eklenti deposundan ücretsiz olarak edinilebilir), oturum yalıtımlı güvenli mod sağlar. Bu, canlı bir üretim sitesinde eklenti ve tema çakışmalarını tanılamak için doğru yöntemdir.

Oturum yalıtımının teknik olarak nasıl çalıştığı:

Eklenti, WordPress’in her istekte okuduğu bir tarayıcı çerezi ayarlar. Çerez mevcut olduğunda, WordPress yalnızca varsayılan temayı yükler ve tüm zorunlu olmayan eklentileri devre dışı bırakır — ancak *yalnızca bu çerezi taşıyan tarayıcı oturumu için*. Diğer tüm ziyaretçiler siteyi önceki haliyle tam olarak deneyimler. Bu bir hazırlık ortamı değildir; WordPress önyükleme düzeyinde uygulanan bir çalışma zamanı filtresidir.

Kurulum ve etkinleştirme:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

Veya Eklentiler > Yeni Ekle bölümüne gidin, “Health Check & Troubleshooting” ifadesini arayın ve Şimdi Yükle‘ye, ardından Etkinleştir‘e tıklayın.

Sorun giderme oturumu çalıştırma:

1. Araçlar > Site Health bölümüne gidin ve Sorun Giderme sekmesine tıklayın.
2. Sorun Giderme Modunu Etkinleştir‘e tıklayın. Oturumunuz artık tüm eklentiler devre dışı ve varsayılan tema etkin olarak çalışır (WordPress 6.5+ itibarıyla Twenty Twenty-Four).
3. Sorunu yeniden oluşturun. Sorun ortadan kalktıysa, bir eklenti veya tema sorumludur.
4. Sorun Giderme sekmesinin eklenti listesini kullanarak eklentileri tek tek yeniden etkinleştirin. Her birini etkinleştirdikten sonra etkilenen sayfayı yeniden yükleyin ve test edin.
5. Sorun yeniden ortaya çıktığında, en son etkinleştirdiğiniz eklenti çakışma kaynağıdır.
6. Tam üretim ortamını geri yüklemek için Sorun Giderme Modunu Devre Dışı Bırak‘a tıklayın.

Uç durumlar ve tuzaklar:

• Sorun güvenli modda bile devam ediyorsa (eklenti yok, varsayılan tema), sorun sunucu veya WordPress çekirdek düzeyindedir — bir eklenti çakışması değil. Ardından php_error.log ve WordPress hata ayıklama günlüğünü kontrol edin.
• MU eklentileri güvenli mod tarafından devre dışı bırakılmaz. Bir MU eklentisinden şüpheleniyorsanız, SFTP veya SSH aracılığıyla wp-content/mu-plugins/ içinde manuel olarak yeniden adlandırmanız gerekir.
• Sorun giderme çerezi tarayıcıya özgüdür. Mobil cihazda test ediyorsanız, sorun giderme modunu o tarayıcı oturumunda ayrıca etkinleştirmeniz gerekir.

Adım 5: Eklenti ve Tema Çakışmalarını Tanımlayın ve Çözün

Eklenti çakışmaları, farklı çözüm stratejileri gerektiren iki kategoriye ayrılır:

Tür 1: Doğrudan PHP çakışmaları — İki eklenti aynı işlevi veya sınıfı tanımlamaya çalışır. Bu hemen ölümcül bir hataya yol açar. Hata günlüğü Cannot redeclare function veya Cannot redeclare class içerecektir.

Tür 2: Sessiz davranışsal çakışmalar — İki eklenti aynı WordPress eylemine veya filtresine bağlanır ve hata vermeden beklenmedik çıktı veya veri bozulmasına neden olur. Bunların tanılanması çok daha zordur ve metodolojik birer birer yalıtım gerektirir.

Çözüm iş akışı:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

Bir eklenti onaylı çakışma kaynağı olduğunda:

1. Çakışmayı ele alan son güncelleme için eklentinin değişiklik günlüğünü kontrol edin.
2. Aynı çakışmaya ilişkin raporlar için wordpress.org’daki eklenti destek forumunu arayın.
3. Düzeltme mevcut değilse, eşdeğer işlevselliğe sahip alternatif bir eklenti belirleyin.
4. Eklenti iş açısından kritik öneme sahipse, hata ayıklama günlüğünüzdeki belirli hatayla birlikte eklenti yazarıyla iletişime geçin — PHP sürümünüzü, WordPress sürümünüzü ve çakışan eklentinin adını ve sürümünü ekleyin.

Adım 6: PHP ve Veritabanı Sunucusu Sürümlerini Güncelleyin

Bu, hem performans hem de güvenlik açısından en yüksek etkiye sahip tek bakım eylemidir. PHP 8.1 ve 8.2, JIT derlemesi ve geliştirilmiş OPcache davranışı sayesinde tipik WordPress iş yükleri için %20–30 daha hızlı yürütme gösteren ölçülebilir verim iyileştirmeleriyle PHP 7.4’ün önüne geçer.

WordPress için PHP sürümü uyumluluk matrisi:

cPanel aracılığıyla PHP güncelleme (cPanel ile VPS ortamları için):

1. WHM’e (root erişimi) veya cPanel’e (MultiPHP Manager etkinse kullanıcı düzeyi) giriş yapın.
2. Yazılım bölümünde MultiPHP Manager‘a gidin.
3. Etki alanınızı seçin ve açılır menüden hedef PHP sürümünü seçin.
4. Uygula‘ya tıklayın.

Komut satırı aracılığıyla PHP güncelleme (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Kritik yükseltme öncesi adım: Üretimde PHP sürümünü değiştirmeden önce, temanızı ve her aktif eklentinizi yeni sürüme karşı test edin. Hazırlık ortamında WP-CLI kullanın:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Veritabanı sürümü değerlendirmeleri:

WordPress, MySQL 5.7+ veya MariaDB 10.3+ gerektirir. MariaDB 10.6 ve 10.11 (LTS) mevcut önerilen sürümlerdir. Eski bir veritabanı sunucusu sürümü çalıştırmak, hem güvenlik açığına hem de büyük gönderi tablolarına veya WooCommerce sipariş hacimlerine sahip siteleri etkileyen eksik sorgu iyileştirici geliştirmelerine yol açar.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

Herhangi bir tablo motor olarak MyISAM gösteriyorsa, daha iyi kilitlenme kurtarma ve eşzamanlı yazma performansı için InnoDB‘e dönüştürün:

ALTER TABLE wp_options ENGINE=InnoDB;

Adım 7: Site Performansını Ölçün ve Optimize Edin

Site Health, ön uç performansını ölçmez — bunun için harici araçlar gerekir. Tamamlayıcı araçlar olarak Google PageSpeed Insights (gerçek dünya koşullarında Core Web Vitals’ı ölçer), GTmetrix (şelale analizi) ve WebPageTest‘i (çok konumlu, gelişmiş yapılandırma) kullanın.

Katmana göre performans optimizasyonu:

Sunucu katmanı:

• PHP bayt kodu önbellekleme için OPcache’i etkinleştirin. Düzgün yapılandırılmış bir VPS’de bu tek başına PHP yürütme süresini %40–60 oranında azaltır.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Kalıcı nesne önbellekleme için Redis kullanın. redis-server paketini ve Redis Object Cache WordPress eklentisini yükleyin, ardından wp-config.php‘e ekleyin:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Uygulama katmanı:

• Görsel optimizasyonu — JPEG/PNG geri dönüşleriyle WebP formatını kullanın. Imagify veya ShortPixel eklentileri, .htaccess yeniden yazma kuralları aracılığıyla toplu dönüştürme ve otomatik WebP dağıtımını yönetir.
• Geç yükleme — WordPress 5.5+, görüntülere otomatik olarak loading="lazy" ekler, ancak temanız tarafından geçersiz kılınmadığını doğrulayın.
• Veritabanı optimizasyonu — Yüksek değişim tablolarında (wp_options, wp_postmeta) aylık olarak OPTIMIZE TABLE çalıştırın. WP-Optimize eklentisi bunu otomatikleştirir.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Önbellekleme eklentileri — Redis arka ucuyla W3 Total Cache veya WP Rocket (premium) en yetenekli iki seçenektir. İki önbellekleme eklentisini aynı anda çalıştırmaktan kaçının — çakışacaklardır.

CDN entegrasyonu:

Bir CDN, statik varlık dağıtımını üstlenir ve coğrafi olarak dağılmış ziyaretçiler için TTFB’yi azaltır. Cloudflare’in ücretsiz katmanı, çoğu site için yeterli CDN işlevselliği sağlar. Medya ağırlıklı siteler için BunnyCDN, dolar başına daha iyi performans sunar. CDN’nizi statik varlıkları agresif biçimde önbelleğe alacak şekilde yapılandırın, ancak WordPress yönetici panelini (/wp-admin/) ve dinamik uç noktaları hariç tutun.

Adım 8: Güvenliği Sertleştirin ve Güvenlik Açığı İzleme Rutini Oluşturun

Güvenlik, tek seferlik bir yapılandırma değil — süregelen bir operasyonel uygulamadır. Site Health aracı bazı güvenlik sorunlarını ortaya çıkarır, ancak güvenlik açığı taraması yapmaz.

Katmanlı güvenlik yaklaşımı:

Sunucu düzeyinde (VPS veya özel sunucu erişimi gerektirir):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

Uygulama düzeyinde:

• Wordfence Security — Web Uygulama Güvenlik Duvarı (WAF), kötü amaçlı yazılım tarayıcısı ve gerçek zamanlı tehdit istihbarat akışı sağlar. Ücretsiz katman çoğu site için yeterlidir; premium katman gerçek zamanlı güvenlik duvarı kural güncellemeleri ekler.
• Giriş denemelerini sınırlama — Limit Login Attempts Reloaded eklentisi veya Wordfence’in yerleşik kaba kuvvet koruması. 3–5 başarısız denemeden sonra kilitleme ayarlayın.
• İki faktörlü kimlik doğrulama — WP 2FA veya Google Authenticator eklentilerini kullanarak tüm yönetici hesapları için 2FA’yı zorunlu kılın.
• SSL/HTTPS zorunluluğu — Her WordPress sitesi HTTPS üzerinden çalışmalıdır. Bir SSL sertifikası edinin ve yükleyin; ihtiyacınız varsa, hosting sağlayıcınızdan SSL Sertifikaları almak en kolay yoldur. Uygulama düzeyinde HTTPS’yi zorlamak için wp-config.php‘e aşağıdakileri ekleyin:

define('FORCE_SSL_ADMIN', true);

Ve .htaccess‘de:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Otomatik güvenlik açığı izleme:

Kullandığınız eklentiler için WPScan Güvenlik Açığı Veritabanı e-posta uyarılarına abone olun. WPScan CLI aracı, yüklü herhangi bir eklenti için yeni bir CVE yayımlandığında sizi uyarmak üzere bir cron göreviyle entegre edilebilir:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Güvenlik kontrolü olarak veritabanı yedekleri:

Temiz ve güncel bir yedek, bir ihlalden sonra en güvenilir kurtarma mekanizmanızdır. Günlük yedeklemeleri sunucu dışı bir konuma (S3 uyumlu nesne depolama, uzak SFTP) otomatikleştirin. UpdraftPlus eklentisi bunu güvenilir biçimde yönetir. Geri yükleme prosedürlerini üç ayda bir doğrulayın — hiç test etmediğiniz bir yedek, yedek değildir.

WordPress Sağlık Kontrolü: Karar Matrisi ve Temel Çıkarımlar

Site Health’in raporladıklarına göre doğru eylemi belirlemek için bu matrisi kullanın:

Süregelen WordPress sağlığı için operasyonel kontrol listesi:

• Site Health durum incelemesini aylık olarak çalıştırın; Kritik bulguları olay olarak değerlendirin.
• PHP’yi desteklenen bir sürümde tutun (minimum 8.1; 8.2 veya 8.3 tercih edilir).
• Etkin olmayan eklentileri ve temaları silin — yalnızca devre dışı bırakmayın.
• Günlük 500’den fazla ziyaretçisi olan her sitede Redis nesne önbelleklemesini etkinleştirin.
• Doğrulanmış geri yükleme testiyle günlük sunucu dışı veritabanı yedeklemelerini otomatikleştirin.
• Yığınınızdaki her eklenti ve tema için güvenlik açığı uyarılarına abone olun.
• HTTPS’yi site genelinde zorunlu kılın ve wp-config.php‘de FORCE_SSL_ADMIN‘i ayarlayın.
• Toplu güncellemeler ve veritabanı işlemleri için WP-CLI kullanın — daha hızlı ve betik yazılabilir.
• Bir Dedicated Server veya VPS’de, wp-cron‘e güvenmek yerine sunucu tarafı cron görevi yapılandırın — wp-cron yalnızca bir ziyaretçi siteye girdiğinde tetiklenir ve bu da düşük trafikli sitelerde güvenilmez hale getirir.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

Bir WordPress dağıtımı için hosting ortamlarını değerlendiriyorsanız, VPS Kontrol Panelleri, bu kılavuzda açıklanan her optimizasyon ve sertleştirme önlemini uygulamak için gerekli sunucu düzeyinde erişimi sağlar — PHP sürüm yönetimi, Redis yapılandırması, sunucu tarafı cron ve güvenlik duvarı kurallarının tümü, paylaşımlı ortamların sağlayamadığı root veya sudo erişimi gerektirir.

SSS

Site Health Durum sekmesi ile Bilgi sekmesi arasındaki fark nedir?

Durum sekmesi otomatik kontroller çalıştırır ve bulguları önem derecesine göre kategorize eder (İyi, Önerilen, Kritik). Bilgi sekmesi, herhangi bir geçti/kaldı değerlendirmesi olmaksızın ham ortam verilerini — PHP yapılandırması, sürümleriyle birlikte aktif eklentiler, veritabanı ayrıntıları ve dizin boyutları — görüntüler. Bilgi sekmesi öncelikle manuel tanılama ve destek mühendisleriyle paylaşım için kullanılır.

Sorun Giderme Modunu etkinleştirmek canlı ziyaretçileri etkiler mi?

Hayır. Sorun Giderme Modu, güvenli mod ortamını yalnızca oturumunuza uygulamak için bir tarayıcı çerezi kullanır. Çerezi olmayan ziyaretçiler siteyi normal şekilde deneyimler. Tek istisna, bir eklentideki ölümcül hatanın sunucu sürecini çöktürmesi durumudur — bu durumda, oturumunuzdaki eklentinin etkinleştirme durumundan bağımsız olarak tüm ziyaretçiler etkilenir.

2025’te WordPress için hangi PHP sürümünü kullanmalıyım?

PHP 8.2, 2025’te üretim WordPress siteleri için önerilen sürümdür. Güvenlik yamaları ile aktif olarak bakımı yapılmakta, 8.0 ve 8.1’e kıyasla ölçülebilir performans iyileştirmeleri sunmakta ve tüm büyük WordPress eklentileri tarafından desteklenmektedir. PHP 8.3 kararlıdır ve yeni dağıtımlar için uygundur, ancak mevcut bir siteyi yükseltmeden önce eklenti uyumluluğunu doğrulayın.

Site Health sitem açıkça yavaşken neden “İyi” durumu bildiriyor?

Site Health, yapılandırmayı ve güvenlik durumunu kontrol eder — En Büyük İçerikli Boyama (LCP) veya İlk Bayta Kadar Geçen Süre (TTFB) gibi ön uç performans metriklerini ölçmez. Bir site tüm Site Health kontrollerini geçebilir ve yine de optimize edilmemiş görseller, önbellekleme katmanı eksikliği, yavaş bir veritabanı veya coğrafi olarak uzak bir sunucu nedeniyle Core Web Vitals’ta düşük puan alabilir. Performans ölçümü için Google PageSpeed Insights veya WebPageTest kullanın.

WordPress Site Health’teki geri döngü isteği başarısızlığını nasıl düzeltirim?

Geri döngü başarısızlığı, WordPress’in sunucudan kendi URL’sine HTTP isteği yapamadığı anlamına gelir. Yaygın nedenler şunlardır: web sunucusu sürecinden giden bağlantıları engelleyen bir güvenlik duvarı, etki alanını yanlış yönlendiren bir hosts dosyası girişi, geri döngü isteğindeki SSL sertifikası hatası veya isteği engelleyen bir güvenlik eklentisi. Güvenlik eklentinizi geçici olarak devre dışı bırakarak ve Site Health’i yeniden çalıştırarak başlayın. Bu sorunu çözerse, güvenlik eklentisinin güvenlik duvarı ayarlarında sunucunun kendi IP adresini beyaz listeye ekleyin.