TTFB Nedir? Bir kullanıcı sitenize girmek için adresi yazdığında, tarayıcı sunucuya bir istek gönderir. Sunucunun bu isteği alıp, veritabanını tarayıp, ilk veri baytını ziyaretçinin tarayıcısına ulaştırdığı o ilk ana kadar geçen süreye TTFB denir. İdeal bir TTFB süresi 200 milisaniyenin (ms) altında olmalıdır.

TTFB Neden Yüksek Çıkar? Eğer sitenizin TTFB süresi 500ms ve üzerindeyse, resimlerinizi ne kadar küçültürseniz küçültün siteniz Google gözünde “yavaş” kabul edilir. Yüksek TTFB’nin üç ana nedeni vardır:

1. Yoğun ve optimize edilmemiş veritabanı sorguları.

2. İşletim sistemi ve arka planda çalışan hantal kontrol panellerinin işlemciyi yorması.

3. Sunucu işlemcisinin ve eski PHP sürümlerinin (bu konuda PHP 8.5’in performansa etkisini incelediğimiz yazımıza bakabilirsiniz) zayıf kalması.

TTFB Nasıl Düşürülür? Yazılımsal önbellekleme (Cache) TTFB’yi düşürmekte yardımcı olsa da kalıcı ve kesin çözüm güçlü bir altyapı mimarisinden geçer.

• Disk Okuma Hızı: Veritabanı sorgularının kuyrukta beklememesi için standart SSD’ler yerine saniyede 7GB/s’ye ulaşan Gen4 NVMe diskler kullanılmalıdır.

• İşlemci Gücü: Gelen isteklerin anında işlenip baytların saniyeler içinde yola çıkması için Ryzen 9 gibi yüksek tek çekirdek performanslı işlemciler gereklidir.

• Hafif Mimari: Sunucuyu yormayan KeyHelp paneli sayesinde arka plan servisleri minimumda tutularak kaynaklar sadece sitenize ayrılmalıdır.

Sitenizin SEO sıralamasını korumak ve organik trafiğinizi artırmak için yüksek TTFB sürelerine katlanmak zorunda değilsiniz. Yeni nesil SaviorHost sunucu altyapısıyla test edin ve aradaki performans farkını saniyeler içinde görün.

Bir web sitesi sahibinin karşılaşabileceği en sinir bozucu durumlardan biri, anlık trafik arttığında veya bir sipariş geldiğinde sitenin aniden çökmesi ve ekranda o meşhur “508 Resource Limit Is Reached” veya “CPU Quota Exceeded” hatasının belirmesidir.

Bu hata, paylaşımlı hosting ortamlarında CloudLinux (LVE Manager) veya benzeri sistemlerin, sitenizin diğer siteleri yavaşlatmasını engellemek için sizin fişinizi çekmesi anlamına gelir. Peki, WordPress neden bu kadar çok CPU tüketir ve bu darboğazı kod seviyesinde nasıl çözersiniz?

Kör uçuşu bırakıp, sorunu bir sistem yöneticisi (SysAdmin) gibi adım adım çözelim.

Adım 1: Darboğazı Teşhis Edin (Kör Uçuşuna Son)

CPU’nuzu neyin sömürdüğünü bilmeden eklenti silmek veya değiştirmek vakit kaybıdır. İlk olarak sorunun kaynağını bulmalısınız:

• Erişim Logları (Access Logs): Sunucu panelinizden (KeyHelp, cPanel vb.) erişim günlüklerini açın. Aynı saniye içinde yüzlerce kez xmlrpc.php veya wp-login.php dosyasına istek geliyorsa, sorun kodlarınızda değil, bir Brute Force (Kaba Kuvvet) saldırısındadır.

• Query Monitor Eklentisi: Sitenize geliştirici olarak giriş yapın ve Query Monitor eklentisini kurun. Hangi eklentinin veritabanına kaç saniye süren sorgular (Slow Queries) gönderdiğini milisaniyesine kadar tespit edin.

Adım 2: Heartbeat API ve admin-ajax.php Krizini Durdurun

WordPress, tarayıcı ile sunucu arasında sürekli bir iletişim kurmak için Heartbeat API’yi kullanır. Özellikle e-ticaret (WooCommerce) sitelerinde sepete ürün ekleme veya varyasyon seçme gibi işlemler admin-ajax.php üzerinden yürütülür. Anlık 50 kişinin sitede gezindiğini ve her saniye sunucuya bir AJAX isteği yolladığını düşünün. Düşük kapasiteli işlemciler bu kuyruğu eritemez ve CPU %100’e vurur.

Çözüm: Heartbeat API’nin frekansını düşürün veya gereksiz yerlerde tamamen kapatın. Temanızın functions.php dosyasına şu kodu ekleyerek Heartbeat’i sadece yazma ekranlarıyla sınırlandırabilirsiniz:

add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
    global $pagenow;
    if ( $pagenow != 'post.php' && $pagenow != 'post-new.php' ) {
        wp_deregister_script('heartbeat');
    }
}

Adım 3: wp-cron.php‘yi Sunucu Tarafına Taşıyın

WordPress’in zamanlanmış görevleri (yazı yayımlama, yedek alma, e-posta gönderme) wp-cron.php üzerinden çalışır. Ancak WordPress, gerçek bir Cron sistemine sahip değildir; her ziyaretçi siteye girdiğinde bu dosya tetiklenir. Yüksek trafikli bir sitede her tıklamada wp-cron.php‘nin çalışması işlemcinizi felç eder.

Çözüm: WordPress’in sanal cron’unu kapatıp, gerçek sunucu cron’una geçin.

1. wp-config.php dosyanıza şu satırı ekleyerek sanal cron’u kapatın: define('DISABLE_WP_CRON', true);

2. Hosting panelinizin “Zamanlanmış Görevler” (Cron Jobs) bölümüne giderek şu komutu ekleyin (her 15 dakikada bir çalışacak şekilde): wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Adım 4: Zombi Botları ve xmlrpc.php‘yi Engelleyin

xmlrpc.php, WordPress’in dış uygulamalarla (örneğin mobil uygulama) iletişim kurmasını sağlar. Ancak günümüzde hackerların DDoS saldırıları ve şifre denemeleri için en çok kullandığı arka kapıdır. Sunucunuz bu istekleri yanıtlamaya çalışırken CPU limitini doldurur.

Çözüm: Eğer WordPress mobil uygulamasını veya Jetpack gibi dış servisleri kullanmıyorsanız, .htaccess dosyanıza şu kodu ekleyerek bu dosyaya erişimi kökten kapatın:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Adım 5: Acı Gerçek: Sorun Yazılımda Değil, Donanımınızda Olabilir

Yukarıdaki tüm optimizasyonları yaptınız, eklentilerinizi azalttınız, Redis Object Cache kurup veritabanı sorgularını RAM’e aldınız ama hala CPU sınırına takılıyorsanız… Artık yazılımın sınırlarına geldiniz demektir.

Sektördeki birçok standart hosting firması, sunucularında çok çekirdekli ancak tek çekirdek performansı (IPC) çok zayıf olan eski nesil Intel Xeon işlemciler kullanır. Dahası, tek bir sunucuya yüzlerce site doldurarak size sadece “kağıt üzerinde” kaynak ayırırlar. Ağır bir WooCommerce veya Elementor tabanlı siteniz varsa, bu işlemciler PHP kuyruklarını (Workers) eritemez.

SaviorHost ile “Limitlere” Veda Edin

Biz SaviorHost olarak, CPU darboğazını eklentilerle saklamaya çalışmıyoruz; saf donanım gücüyle eziyoruz.

• AMD Ryzen™ 9 7900 İşlemci Gücü: Saat döngüsü başına işlem (IPC) gücü inanılmaz yüksek olan Ryzen 9 mimarisi sayesinde, ağır PHP betikleri ve dinamik veritabanı sorguları milisaniyeler içinde işlenir. CPU şişmez, sıraya girmez.

• Ultra Hafif KeyHelp Mimarisi: Arka planda RAM ve işlemcinizi sömüren hantal kontrol panelleri (cPanel vb.) yerine, donanımın %99’unu doğrudan web sitenize tahsis eden Alman harikası KeyHelp mimarisini kullanıyoruz.

• Cömert PHP Worker Sayısı: E-ticaret sitelerinizin “admin-ajax” kuyruklarında boğulmaması için paketlerimizde rakiplerin sunmadığı düzeyde 50 PHP Worker limiti sunuyoruz.

Eğer CPU limitleriyle savaşmaktan, sitenizi sürekli optimize etmeye çalışıp yine de 508 hatası almaktan yorulduysanız; yeni nesil Yüksek Performanslı Linux Hosting veya WordPress Hosting altyapımıza geçiş yapın.

Donanım limitlerini düşünmeyi bırakın, sadece projenizi büyütmeye odaklanın. Farkı 15 Gün Koşulsuz İade Garantisi ile sıfır riskle test edebilirsiniz!

Son yıllarda PHP 8 serisi ile (özellikle JIT – Just In Time Compiler mimarisiyle) gelen devrim niteliğindeki yenilikler, PHP 8.5 ile çok daha kusursuz bir hale geldi. Peki, eski bir sürümden güncel sürümlere geçmek sitenize ne kazandırır?

1. CPU ve Bellek (RAM) Optimizasyonu Güncel PHP sürümleri, kodu makine diline çevirirken çok daha agresif optimizasyonlar yapar. Aynı işlemi yapmak için %30’a varan oranda daha az RAM kullanır ve CPU’yu çok daha az meşgul eder. Bu, anlık trafik artışlarında (hit dalgalanmalarında) sunucunuzun çökmesini engeller.

2. Daha Hızlı Kod İşleme (Execution Time) Özellikle WooCommerce ödeme adımlarında yavaşlık yaşayan sitelerde veya ağır Laravel projelerinde, güncel sürümler sorguları çok daha kısa sürede işler. Bu hız artışı, ziyaretçi deneyimini doğrudan iyileştirir.

3. Üst Düzey Güvenlik Eski PHP sürümleri yeni keşfedilen güvenlik açıklarına karşı yama almaz. Sitenizi güncel bir PHP sürümünde barındırmak, veritabanı sızıntılarına karşı en güçlü ilk savunma hattıdır.

Panel Hantallığına Takılmayın Sektördeki birçok hosting firması, kullandıkları kontrol panellerinin (CWP vb.) hantallığı ve güncelleme almaması nedeniyle müşterilerini eski PHP sürümlerine mahkum bırakabiliyor. SaviorHost altyapısındaki Linux web hosting paketlerimizde kullandığımız Alman harikası KeyHelp kontrol paneli, güncel PHP sürümlerini anında ve stabil bir şekilde destekler.

AMD Ryzen™ 9 işlemcilerimizin sağladığı devasa gücü, en güncel PHP mimarisiyle birleştirerek yazılımlarınızın sınırlarını zorlayabilirsiniz.

Peki, ana sayfada harikalar yaratan bu önbellek (cache) eklentilerine ödeme adımında ne oluyor?

Bypass Cache (Önbelleğin Devre Dışı Kalması) Önbellek eklentileri, web sitenizin statik bir kopyasını (HTML halini) oluşturup ziyaretçiye sunar. Böylece sunucu yorulmaz. Ancak bir müşteri sepete ürün eklediğinde, sisteme giriş yaptığında veya stok düşüleceği zaman sistemin “dinamik” çalışması gerekir. Eklenti burada aradan çekilir ve tüm yük doğrudan sunucunuzun çıplak donanımına biner. Bu durum doğrudan sunucu yanıt sürenizi, yani TTFB (İlk Bayt Süresi) değerinizi aniden yükseltir.

Asıl Darboğaz Nerede Başlıyor? Önbellek aradan çekildiği o kritik saniyelerde sitenizin hızı tamamen iki şeye bağlıdır:

1. PHP Yorumlama Hızı: PHP işçilerinin o anki hesaplamayı ne kadar hızlı yapabildiği.

2. Disk I/O (Okuma/Yazma): MariaDB veya MySQL veritabanının diske sipariş verisini ne kadar sürede yazabildiği.

Eğer sunucunuzda eski nesil Xeon işlemciler ve standart SSD diskler kullanılıyorsa, müşteri o sepet sayfasında bekler ve genellikle sepeti terk eder (Cart Abandonment).

Çözüm: Saf Donanım Gücü Dinamik sayfaların yavaşlığını eklentilerle çözemezsiniz. SaviorHost olarak e-ticaret altyapılarında sıfır gecikme (zero-latency) prensibiyle çalışıyoruz. Dinamik sorguların anında işlenmesi için tek çekirdek performansı tavan yapan AMD Ryzen™ 9 7900 işlemciler kullanıyoruz.

Ayrıca sunucuyu yoran hantal kontrol panelleri yerine ultra hafif KeyHelp mimarisiyle donanım gücünün %100’ünü doğrudan e-ticaret sitenize aktaran yüksek performanslı WordPress hosting paketlerimizle sepet terk edilme oranlarınızı minimuma indiriyoruz.

Sepette müşteri kaybetmek istemiyorsanız, önbelleğin arkasına saklanmayan gerçek donanım gücüyle tanışın.

Eğer sitenizin altyapısı için bir arayışındaysanız, sunucu kaynaklarınızı hantal bir panele mi yoksa doğrudan ziyaretçilerinize mi harcamak istediğinize karar vermelisiniz. Bu yazımızda, sektörün tekelini kıran Alman mühendisliği harikası Keyhelp ile yılların yorgunu cPanel‘i teknik bir masaya yatırıyoruz.

cPanel Neden Artık Bir “Kaynak Canavarı”?

cPanel, on yılı aşkın süredir sektöre yön veren, özellik bakımından oldukça zengin bir sistemdir. Ancak bu “her şeyi yapabilme” takıntısı, beraberinde devasa bir hantallığı da getirdi.

• Arka Plan Yükü: cPanel, sadece arka planda çalışır durumda kalabilmek (idle state) için ciddi bir RAM ve CPU döngüsü tüketir. Sitenize henüz tek bir ziyaretçi bile girmeden sunucunuzun kaynaklarının bir kısmı panele feda edilir.

• Lisans Maliyetleri: Sürekli artan lisans ücretleri, hosting firmalarının donanım kalitesinden kısıp lisans parasını ödemesine veya bu maliyeti doğrudan müşteriye yansıtmasına neden olur.

Keyhelp: Performans Odaklı Alman Minimalizmi

Keyhelp, gücünü sadeliğinden ve mükemmel kod optimizasyonundan alan yeni nesil bir sunucu yönetim panelidir. Sadece ihtiyaç duyulan servisleri en verimli şekilde çalıştıracak bir mimariyle tasarlanmıştır.

• Ultra Düşük Kaynak Tüketimi: Keyhelp, sunucu belleğinde (RAM) ve işlemcide (CPU) yok denecek kadar az yer kaplar. Bu sayede sunucunuzun saf gücü panele değil; veri tabanı sorgularınıza, e-ticaret sitenizin ödeme adımlarına ve anlık trafik dalgalanmalarına ayrılır.

• Modern ve Temiz Arayüz: Geliştiriciler ve son kullanıcılar için karmaşadan uzak, sadece birkaç tıklamayla SSL kurulumu, e-posta yönetimi ve FTP erişimi sağlayan sezgisel bir yapı sunar.

Teknik Karşılaştırma Matrisi

Aşağıdaki tablo, iki panel arasındaki temel felsefe farkını net bir şekilde özetlemektedir:

AMD Ryzen 9 7900 ve Keyhelp Sinerjisi

Bir kontrol panelinin hafif olması tek başına yeterli değildir; altındaki donanımın da bu hafifliği uçuşa çevirecek kadar güçlü olması gerekir. Tam bu noktada devreye Saviorhost‘un tavizsiz donanım mimarisi giriyor.

Almanya Contabo veri merkezinin sarsılmaz altyapısında konumlandırdığımız sunucularımız, çoklu işlem parçacığı (multi-threading) konusunda sektörün zirvesinde yer alan AMD Ryzen 9 7900 işlemcilerle çalışır.

• Linux Hosting paketlerimizde Keyhelp’in sıfıra yakın kaynak tüketimi, Ryzen 9’un ham işlemci gücüyle birleştiğinde; özel yazılımlarınız ve ajans projeleriniz için darboğazsız (bottleneck-free) bir deneyim yaşatır.

• Eğer ağır eklentiler kullanan bir blog veya e-ticaret siteniz varsa, veritabanı sorgularının en hızlı şekilde işlenmesi hayati önem taşır. Keyhelp ile optimize edilmiş WordPress Hosting paketlerimiz, panelin aradan çekilip tüm sunucu gücünün sitenize akmasını sağlayarak sayfa açılış sürelerinizi milisaniyelere düşürür.

Sonuç: Kaynaklarınızı Ziyaretçilerinize Saklayın

2026 yılının rekabetçi web ekosisteminde, Google algoritmaları sitenizi milisaniyelerle yargılarken sunucu kaynaklarınızı hantal kontrol panellerine kurban edemezsiniz. %99 uptime oranı, Alman veri merkezi stabilitesi ve Ryzen 9 işlemcilerin gücüyle desteklenen gerçek bir hızlı hosting deneyimi arıyorsanız, cPanel’in alışkanlık tuzağından çıkıp Keyhelp’in modern mimarisiyle tanışmanın tam zamanı.

Aşağıdaki rehber, en hızlı geri dönüş için önce teşhis, ardından kalıcı çözüm adımlarını sunar. Geliştirici olmanıza gerek yok—adımları sırayla uygulamanız yeterli.

1) İlk Teşhis: Hatanın Gerçek Yüzünü Görün (Debug Mode)

500’ün “neden”ini görmek için Debug Mode’u açın. Yönetim paneline erişebiliyorsanız Gelişmiş Parametreler → Performans → Hata Ayıklama Modu (Debug Mode) bölümünden aktif edin; erişemiyorsanız config/defines.inc.php dosyasında _PS_MODE_DEV_ değerini true yapın. İşiniz bitince mutlaka kapatın. (Resmi yardım merkezi ve topluluk kılavuzları bunu önerir.) help-center.prestashop.com+1

Neyi beklemelisiniz?
Beyaz sayfa yerine ayrıntılı PHP/Symfony hata yığını göreceksiniz. Satır ve dosya adı, sorunun modül/tema/çekirdek kaynaklı olup olmadığını açık eder.

2) En Sık Nedenler ve Hızlı Çözümler

A) Tema/Modül Çatışmaları (Güncelleme Sonrası)

• Belirti: 500, BO/FO’da aniden çökme.

• Çözüm: Son kurduğunuz modülü FTP ile /modules/ altında geçici olarak yeniden adlandırın (devre dışı kalır). Ardından önbelleği temizleyip sayfayı yenileyin. PrestaShop’un genel 500 hata kılavuzu modül kaynaklı çöküşleri özel olarak vurgular. help-center.prestashop.com

B) PHP Sürümü / Eklenti Uyumsuzluğu

• Belirti: Hata yığında Deprecated, Fatal error: Uncaught TypeError vb.

• Çözüm: Kullanılan PrestaShop sürümünün PHP uyumluluğunu kontrol edin. PrestaShop 8 için öneri PHP 8.1’dir; sistem gereksinimleri resmi dökümantasyonda detaylıdır. Ayrıca intl gibi eklentilerin yüklü olduğundan emin olun. PrestaShop

C) Dosya/klasör izinleri hatalı (permissions)

• Belirti: Log dizinine yazılamıyor, cache temizlenmiyor → 500.

• Çözüm: Tipik olarak dosyalar 644, klasörler 755 olmalı; özellikle var/cache ve var/logs (veya /var/log) yazılabilir olmalı. Toplulukta izin/ownership kaynaklı 500’ler sıkça görülür. prestashop.com

D) Bozulmuş .htaccess veya URL Yeniden Yazımı (mod_rewrite)

• Belirti: Friendly URL açıkken 500/404, yönlendirme döngüsü.

• Çözüm: .htaccess dosyasını yeniden üretin ve sunucuda URL rewrite’ın aktif olduğundan emin olun. PrestaShop 8 kullanıcı kılavuzu Friendly URL’lerin URL rewriting gerektirdiğini özellikle belirtir. docs.prestashop-project.org

E) Önbellek/Smarty Bozulmaları

• Belirti: Sayfalar açılmıyor ya da eski halini gösteriyor.

• Çözüm: BO’dan Performans → Önbellek temizle; erişemiyorsanız var/cache/prod ve var/cache/dev içeriğini silin (dizini değil, içeriği). Barındırma sağlayıcı rehberleri manuel temizlemeyi adım adım gösterir. SiteGround

3) Adım Adım “Hızlı Kurtarma” Akışı (How-To)

1. Debug Mode’u açın ve ekranda görünen gerçek hatayı not alın. (Sebebi netleştirir.) help-center.prestashop.com

2. Son değişikliği geri alın: Yeni modül/tema/sürüm güncellemesi yaptıysanız kapatın veya geri sarın. help-center.prestashop.com

3. Önbelleği temizleyin: BO → Performans’tan; erişemiyorsanız var/cache/prod/* ve var/cache/dev/* klasörlerinin içeriğini silin. SiteGround

4. .htaccess’i yeniden oluşturun: BO → Mağaza Parametreleri → Trafik & SEO → Friendly URL’yi kapatıp kaydedin, sonra tekrar açıp kaydedin (yeniden yazım aktif olmalı). docs.prestashop-project.org

5. PHP sürümü ve eklentileri doğrulayın: PrestaShop 8 için öneri PHP 8.1; intl, mbstring, gd, curl, zip gibi yaygın eklentileri kontrol edin (eksikler 500’e yol açabilir). PrestaShop

6. İzin/ownership’i düzeltin: Özellikle var/ altındaki yazılabilir dizinler (cache/log) için kullanıcı ve izinleri kontrol edin. (Topluluk çözümleri sıkça buna işaret eder.) prestashop.com

7. Kalıcı sorunlarda log’lara bakın: Yönetim → Gelişmiş Parametreler → Günlükler (Logs) ve sunucudaki var/log dosyaları ipucu verir. (Resmi 1.7 kılavuzu log sayfasını açıklar.) docs.prestashop-project.org

İpucu: Yerel/uzak sunucunuzun uyumluluğunu topluca test etmek için PrestaShop’un resmi PhpPsInfo aracını çalıştırabilirsiniz (gereksinim kontrolü). GitHub

4) Örnek Senaryo ve Çözüm (Kopyala–Yapıştır)

Belirti: Tema güncellemesi sonrası tüm sayfalarda 500.

Çözüm Planı:

5) Kalıcı Sağlamlık: “Bir daha yaşanmaması” için 6 öneri

1. Sürüm uyum tablosuna göre güncelleyin: PHP/PrestaShop uyumunu kontrol etmeden sürüm yükseltmeyin. PrestaShop

2. Staging ortamı kullanın: Modül/tema güncellemelerini önce test mağazasında deneyin.

3. Düzenli yedek alın: Dosya + veritabanı.

4. İzin politikası: Dosyalar 644, klasörler 755; var/ altı yazılabilir. prestashop.com

5. Önbellek stratejisi: Büyük değişikliklerden sonra cache temizliği rutine bağlansın. SiteGround

6. Güncel intl/ICU ve gerekli eklentiler: Yerelleştirme ve tarih/sayı biçimleri için kritik. PrestaShop

SSS (Kısa)

500 hatası neden olur?
En çok modül/tema uyumsuzluğu, PHP sürüm/eklenti uyumsuzluğu, bozuk .htaccess, yanlış izinler ve bozuk cache yüzünden. Resmi yardım merkezi bu başlıkları kapsıyor. help-center.prestashop.com

Önbelleği elle nasıl temizlerim?
Yönetim yoksa var/cache/prod/* ve var/cache/dev/* içeriğini silin; ardından siteyi yenileyin. SiteGround

Friendly URL açıkken 500/404 alıyorum, ne yapmalıyım?
URL yeniden yazımı (mod_rewrite) aktif mi kontrol edin; Friendly URL’yi kapat–kaydet–aç–kaydet yaparak .htaccess’i yeniden oluşturun. docs.prestashop-project.org

Hangi PHP sürümünü kullanmalıyım?
PrestaShop 8 için öneri PHP 8.1’dir (güncel resmi dökümantasyona göre). PrestaShop

Spam trafiği; credential stuffing, carding, scraping, brute force, form spam, API kötüye kullanımı gibi farklı otomasyon davranışlarından oluşur. OWASP’ın Automated Threats to Web Applications (OAT) sınıflandırması, hangi uç noktalar için hangi saldırıların tipik olduğuna dair ortak bir dil sağlar; savunmayı tek bir CAPTCHA’ya indirgemek yerine tehdit odaklı düşünmeyi kolaylaştırır. owasp.org+1

Ana savunma katmanları (özet strateji)

1. WAF + kural setleri: ModSecurity ile OWASP Core Rule Set (CRS) başlangıç bariyeri sağlar; SQLi/XSS gibi klasik istismarlara ek olarak brute force ve hız sınırlamaya yardımcı kurallar içerir. owasp.org+1

2. Oran sınırlama (rate limit) / bağlantı kotası: Nginx’in limit_req ve limit_conn modülleri IP ya da özel anahtarlar (örn. IP+username) üzerinden istek hızını düşürür; leaky-bucket algoritması kullanır. nginx.org+1

3. Risk skorlu doğrulama: Cloudflare Turnstile gibi “sessiz” tarayıcı sinyali tabanlı çözümler; düşük güven hâlinde hafif challenge göstererek sürtünmeyi azaltır. Google reCAPTCHA (Enterprise), OAT kategorilerine göre akış bazlı öneriler sunar. Cloudflare Docs+2Cloudflare Docs+2

4. Honeypot/decoy taktikleri: Görünmeyen form alanları, sahte endpoint’ler ve (Cloudflare tarafında) AI Labyrinth gibi “yönlendirip oyalayan” çözümlemeler, robots.txt’ye uymayan yeni nesil tarayıcılara karşı etkili bir ek katmandır. The Cloudflare Blog

5. Scraper ekosistemi ve robots.txt gerçekliği: 2024–2025’te yayıncılar ve altyapı sağlayıcıları, robots.txt’yi yok sayan ve kimliğini gizleyen AI tarayıcılarına karşı (örn. varsayılan engelleme, “Pay Per Crawl” gibi) daha agresif önlemler duyurdu; robots.txt tek başına yeterli değil. The Verge+2Reuters+2

6. Ölçüm temizliği: Başarıyı ölçmek için GA4’te internal ve developer trafiğini filtrele; aksi hâlde bot azaltma etkisini göremezsin. Google Yardım

7. API’lere özel sıkılaştırma: 2024’te web saldırıları %33 artarken API’ler birincil hedef hâline geldi; rate limit + kimlik doğrulama + davranışsal sinyaller şart. vmblog.com+1

Uygulanabilir kontrol listesi (Hızlı başlangıç)

• Kritik uçları çıkar: /login, /signup, ödeme/form akışları, /search, ürün beslemeleri ve API uçları; her birini OAT kategorisiyle eşleştir. owasp.org

• WAF/CRS’i aç ve tuning yap: Hatalı pozitifleri azaltmak için istisna kuralları tanımla. CRS Project

• Oran sınırla: Nginx ile IP ve akışa özgü anahtarlarla rate limiting uygula. nginx.org

• Riskli akışlarda challenge: Turnstile/reCAPTCHA’yı login, kayıt ve ödeme gibi yüksek riskli akışlarda puan/karar mekanizmasıyla devreye al. Cloudflare Docs+1

• Honeypot/decoy ekle: Form honeypot’ları + (Cloudflare kullanıyorsan) AI Labyrinth. The Cloudflare Blog

• Scraper yönetimi: ASN/ülke/UA sinyalleriyle kurallar, hız limitleri, JSON/Feed uçlarına Accept/Referer hijyeni.

• Ölçüm temizliği: GA4 iç/developer trafiğini dışla. Google Yardım

• Sürekli gözlem: 429/5xx oranları, çerezsiz istek patlamaları, belirli ASN/ülkelerden ani sıçramalar için alarmlar kur.

• Trendleri izle: Akamai’nin yıllık/çeyreklik SOTI raporları API/bot eğilimlerini takip için iyi bir referans. Akamai

Uygulama Taslağı (kopyala–uyarla)

A) Nginx: Oran sınırlama ve basit işaretler

Login akışı için IP + kullanıcı adı birleşik anahtar:

Nginx’in limit_req modülü leaky-bucket yöntemiyle çalışır; anahtar seçiminde IP’nin NAT arkasında paylaşılıyor olabileceğini unutma. nginx.org+1

Form spam için honeypot + hız limiti:

Sık kazınan uçlar (search/feed/sitemap) için dar boğaz:

B) Cloudflare: Turnstile + WAF mantığı + AI Labyrinth

Turnstile entegrasyonu (özet):

Sunucuda (ör. Node) doğrularken token’ı /siteverify ile kontrol et; puan düşükse ek doğrulama iste. Turnstile, Cloudflare CDN’i kullanmasan bile gömülebilir; önce sessiz sinyaller toplar, gerekirse hafif bir challenge gösterir. Cloudflare Docs+1

AI Labyrinth (decoy sayfalarla oyalama): robots.txt’ye uymayan/bilinen AI tarayıcılarına karşı botu “labirente” sokarak kaynaklarını tüketen yeni savunma; Cloudflare üzerinde ücretsiz/opt-in sunuluyor. The Cloudflare Blog

Güncel bağlam: Cloudflare 2025’te AI crawler’ları varsayılan engelleme ve Pay Per Crawl seçeneklerini duyurdu; robots.txt’yi yok sayan botlara karşı altyapı seviyesinde kontrol sağlıyor. The Verge+1

C) AWS WAF: Bot Control + yönetilen kurallar

• AWS WAF Bot Control: Bilinen bot kategorilerini (iyi/kötü) ayıran yönetilen kurallar; özel kurallarla birleştirilebilir. docs.aws.amazon.com+1

Örnek (IP başına /login rate limit + Bot Control):

D) Google reCAPTCHA (Enterprise): OAT uyumlu mimari

Google’ın OAT tehditlerine göre en iyi uygulamalar kılavuzu, kart dolandırıcılığı, credential stuffing vb. senaryolarda puan tabanlı karar akışları ve “ek doğrulama” önerir. Uygulamada, skor/bağlama göre “izin ver / MFA iste / insan doğrulaması iste / reddet” kuralı tanımla. Google Cloud+1

E) GA4: İç/developer trafiğini dışla (ölçüm temizliği)

• Internal traffic: IP’leri “Define internal traffic” ile tanımla, ardından Data Filters’ta Exclude olarak aktif et. Google Yardım

• (İpucu) GA4, iç trafikten gelen vuruşlara tt=internal işareti koyar; validasyonu kolaylaştırır. selnekovic.com

F) İzleme & alarm fikirleri

• 429/5xx oranı ve endpoint başına z-skor sapmaları.

• Cookie-less istek oranı, ASN/ülke bazlı patlamalar.

• Decoy/honeypot isabetleri metriki (AI Labyrinth/honeypot sayfalarına giriş).

• API saldırı trendleri için Akamai’nin SOTI raporlarını periyodik takip. vmblog.com

Neden robots.txt tek başına yetmiyor?

Son 1 yılda; kimliğini gizleyen, robots.txt’yi görmezden gelen ya da UA/başlık taklidi yapan AI tarayıcılarına dair çok sayıda bulgu paylaşıldı. Bu yüzden altyapı seviyesinde engelleme (WAF/ASN/UA/Rate limit/Decoy) gereklidir. arstechnica.com+1

Kullanıcı deneyimi: “kademeli sürtünme” prensibi

• Herkese CAPTCHA göstermek yerine, risk skorlu ve kademeli zorlaştırma kullanın: düşük riskli akışlarda sürtünme yok; risk yükseldikçe MFA / challenge / manuel inceleme. Turnstile ve reCAPTCHA bu modeli destekler. Cloudflare Docs+1

Ek: Somut “kural seti” taslağı (özet)

1. Nginx: /login için IP+username anahtarıyla limit_req; form uçlarına honeypot + saatlik limit; “sıcak” scraping uçlarına 1 r/s sınırı. nginx.org

2. Cloudflare: Turnstile’ı yalnızca login/signup/ödeme gibi riskli akışlara yerleştir; AI Labyrinth’i aç; bilinen AI UA’ları ve “şüpheli oran” için WAF’ta Managed Challenge uygula. Cloudflare Docs+1

3. AWS WAF: Önde Allowlist → Bot Control → Common Rule Set → akışa özel rate limit. docs.aws.amazon.com

4. GA4: Internal/Developer filtreleri Active; bot benzeri oturumlar için ayrı segment oluştur. Google Yardım

5. Sürekli iyileştirme: Hatalı pozitif vakalarını toplayıp istisnalar yaz; eşikleri haftalık gözden geçir.

6. Trend takibi: API saldırıları ve scraper davranışlarına dair Akamai SOTI raporlarını takip et. Akamai

İlk Teşhis: Günlükleri (Log) ve Servis Durumunu Kontrol Edin

1. Plesk arayüzü erişilemiyorsa, sunucuya SSH ile bağlanın ve MariaDB/MySQL durumuna bakın:

   systemctl status mariadb
journalctl -u mariadb -n 200 --no-pager


   (Windows’ta Olay Görüntüleyici ve Plesk SQL Server servisini kontrol edin.) support.plesk.com

2. Geçmiş boot loglarını inceleyin (özellikle beklenmedik yeniden başlatma sonrası):

   journalctl --boot=-1 -n 5000


   (Forumda doğrulanan pratik bir yaklaşım.) Plesk Forum

3. Disk doluluk:

   df -h
du -sh /var/lib/mysql/* | sort -h


   Diskin dolması, MySQL’in başlamasını engeller ve 500 hatasına yol açar. Plesk Forum

Hızlı Onarım: Plesk Repair Utility (Önerilen)

Çalıştırın:

Bu komut Plesk veritabanı tutarlılığını denetler, gerekirse otomatik yedek (dump) alır ve onarım dener. Linux/Windows’ta kullanılabilir. Ek seçenek gerekmez. docs.plesk.com+2plesk.com+2

Not – Geçici 500 Hatası: plesk repair installation gibi geniş onarım çalışırken Plesk kısa süre erişilemez ve 500 hatası görülebilir; bu, bilinen bir Repair Kit davranışı/bug’ıdır ve işlem bitince kaybolur. support.plesk.com

Senaryo A: SQLSTATE[HY000][2002] Connection refused

Belirti:

Neden: MariaDB/MySQL servisinin down olması veya başlayamaması.
Çözüm:

1. Servisi başlatın/yeniden başlatın:

   systemctl restart mariadb
systemctl status mariadb


2. Loglardaki temel sebebi giderin (ör. yapılandırma, port çakışması, izinler).

3. Ardından plesk repair db çalıştırın.
   Kaynak ve aynı hatanın resmi analizi: support.plesk.com

Senaryo B: SQLSTATE[HY000][2002] No such file or directory

Belirti:

Neden: MySQL socket dosyası yok/yanlış yol, servis kapalı veya disk taşması sonucunda soket oluşmuyor.
Çözüm:

1. Servisi yeniden başlatın; /etc/my.cnf içindeki socket yolunu ve /var/lib/mysql/mysql.sock varlığını doğrulayın.

2. Disk doluysa alan açın (bkz. Senaryo D).

3. Gerekirse /tmp izinlerini ve AppArmor/SELinux kısıtlarını kontrol edin.
   Doğrulama: Plesk Forum+1

Senaryo C: Plesk SQL Server Error 1053 (Windows) / Port Çakışması

Belirti: 1053; Event Viewer’da “Bind on TCP/IP port 3306… already in use”.
Neden: Plesk SQL Server servis yapılandırması hatalı ya da 3306 portunu başka bir mysqld kullanıyor.
Çözüm:

1. Hizmetin “Path to executable” ayarını doğru my.ini bilgisiyle güncelleyin.

2. Port çakışması varsa bağlanan diğer MySQL örneğini kapatın/portu değiştirin.
   Kaynak: support.plesk.com

Senaryo D: Disk Dolu (No space left on device)

Belirti: MySQL başlatılamıyor; günlüklerde “No space left on device”.
Çözüm:

1. df -h ile dolu diskleri tespit edin, gereksiz log/backupları temizleyin.

2. MariaDB’yi yeniden başlatın, ardından plesk repair db.
   Resmi Plesk çözüm makalesi: Plesk Forum

Senaryo E: Bozulmuş Plesk Sistem Veritabanları (psa vb.)

Belirti: psa tabloları “crashed”/tutarsız; Plesk arayüzü 500 veriyor.
Çözüm (önce yedek alın):

1. Repair Utility:

   plesk repair db


2. Gerekirse günlük yedekten geri yükleme (Plesk’in otomatik dump’ları):
   Plesk günlük/pre-upgrade dump’tan psa’yı geri yükleme adımları resmi rehberde anlatılır. (Örnek komutlar ve değiştirme notları rehberde mevcut.) plesk.com

3. Alternatif CLI restore notları (ilerseviye): dump’tan apsc/psa geri yükleme pratikleri. (Topluluk deneyimi; dikkatle uygulayın.) The WP Guru

Uyarı: Manuel mysqlcheck --repair veya innodb_force_recovery gibi adımlar verinizi riske sokabilir; önce resmi repair ve resmi geri yükleme yollarını deneyin. docs.plesk.com+1

Senaryo F: Geçici — Repair Çalışırken Plesk İnaccessible

Belirti: plesk repair installation sırasında panel 500 hatası döner.
Çözüm: İşlem tamamlanınca düzelir; bilinen bir davranış/bug kaydı mevcuttur. support.plesk.com

Senaryo G: Eksik/Silinmiş Dosya veya Antivirüs Karantinası (Windows)

Belirti: “500 Internal Server Error – Failed opening required …”
Çözüm: Eksik dosyayı aynı sürüm çalışan bir Plesk’ten geri getirin; antivirüse %plesk_dir% için istisna ekleyin. support.plesk.com

Adım Adım Standart Düzeltme Akışı (Önerilen Playbook)

1. Servisleri kontrol et: systemctl status mariadb → hata varsa log oku. support.plesk.com

2. Disk alanı: df -h → doluysa temizle. Plesk Forum

3. Repair Utility çalıştır: plesk repair db (Linux/Windows). docs.plesk.com+1

4. Socket/Port doğrula: mysql.sock yolu ve 3306 çakışması. (Windows’ta hizmet yapılandırması.) support.plesk.com+1

5. Hâlâ sorun var mı? Plesk sistem DB’lerini dump’tan geri yükle (örn. psa). plesk.com

6. Geçici 500 mi? Repair esnasında oluştuysa görmezden gelebilirsiniz; işlem bitince panel geri gelir. support.plesk.com

SSS

Bu hata neden “genel” gözüküyor?
“500 Plesk\Exception\Database” şemsiye bir hatadır; somut sebep loglarda çıkar. Plesk Forum

Plesk’te veritabanını GUI’den de onarabilir miyim?
Evet; “Websites & Domains → Databases → Check and Repair”. (Sürümünüze göre görünüm değişebilir.) lets-rebuild.com

Repair sırasında 500 görürsem?
Bu beklenen bir davranış olabilir; repair bitince panel geri gelir (EXTPLESK-3451). support.plesk.com

İleri Düzey Notlar ve İpuçları

• Komutları üretimde uygulamadan önce snapshot/backup alın.

• Plesk Repair Utility, tutarsızlık bulursa otomatik dump alıp onarım dener; bu nedenle ilk başvuru aracınız olmalı. docs.plesk.com

• Hata No such file or directory ise socket yolunu ve /tmp izinlerini kontrol edin; Connection refused ise servis gerçekten çalışmıyor demektir. support.plesk.com+1

🛒 E-Ticaret Site Kurulumunda Hangi Sistem Tercih Edilmeli? (2025 Kılavuzu)

📌 2025’e güncel karşılaştırma: PrestaShop, WooCommerce, Shopify, Adobe Commerce (Magento), OpenCart, BigCommerce, Wix. Teknik ama sade; karar vermeyi kolaylaştıran bir rehber.

🎯 1) Neden altyapı seçimi kritik?

E-ticarette başarı; Toplam Sahip Olma Maliyeti (TCO) 💸, performans 🚀, SEO 🔍, entegrasyonlar (ödeme/kargo/pazaryeri) 🔗,
ölçeklenebilirlik 📈 ve güvenlik 🛡️ ile doğrudan ilişkilidir.
SaaS (Shopify, BigCommerce, Wix) hızlı başlatır; açık kaynak (PrestaShop, WooCommerce, Magento, OpenCart) tam kontrol ve esneklik sunar.

⚡ 2) Hızlı tablo: hangi senaryoda hangi sistem?

🧪 3) Değerlendirme kriterleri

• 💸 TCO: Lisans/SaaS + barındırma + geliştirme + bakım + eklentiler.
• 🚀 Performans: PHP/Symfony sürümü, OPcache/Redis, CDN, tema mimarisi.
• 🔍 SEO: Temiz URL, yapılandırılmış veri, hız, kategori/ürün hiyerarşisi.
• 🔗 Özelleştirme/Entegrasyon: API’ler, modül/uygulama mağazaları, ERP-PIM-kargo-pazaryeri.
• 🛡️ Güvenlik & Güncelleme: Düzenli sürüm/yama takibi.

🧩 4) Platform incelemeleri

⭐ PrestaShop (önerilen)

Neden öne çıkar? Modern PHP/Symfony tabanı, Hummingbird tema, yeni Admin API ve geniş modül/tema ekosistemiyle
performans + geliştirilebilirlik dengesi sunar. Çoklu dil/mağaza, AB uygun vergi/teslimat, tam veri sahipliği ile KOBİ-orta ölçek için idealdir.

• 🧱 Mimari: Modüler hook sistemi; override/extension kalıpları.
• 🔌 API: Webservice + Admin API ile ERP/PIM/kargo/BI entegrasyonları.
• 📈 Ölçekleme: Nginx + PHP-FPM, OPcache/Redis, CDN, akıllı önbellek/sorgu optimizasyonu.

📰 WooCommerce (WordPress eklentisi)

WordPress’in içerik gücü + geniş eklenti ekosistemi ile doğal bir seçimdir. Büyük kataloglarda ölçekleme için eklenti disiplinine dikkat gerekir.

🛍️ Shopify

Hızlı lansman, yönetilen hosting/güvenlik ve güçlü App Store sunar. İleri özelleştirmelerde platform sınırları ve ek maliyet kalemleri değerlendirilmeli.

🏢 Adobe Commerce (Magento)

Kurumsal/karmaşık projelerde API-first ve zengin yerleşik özelliklerle güçlüdür; uzmanlık ve bakım maliyeti yüksektir, güvenlik yamaları yakından izlenmelidir.

🧰 OpenCart

Hafif çekirdek ve basit yönetim ile küçük/basit projelerde hızlı ilerleme sağlar; ileri özellikler için genellikle eklenti gerekir.

🏷️ BigCommerce

Headless, Multi-Storefront ve B2B Edition kabiliyetleri ile çok markalı/B2B senaryolara uygundur.

🧩 Wix eCommerce

Sürükle-bırak kolaylığıyla mikro/küçük işletmeler için idealdir; karmaşık operasyonlarda sınırlarına takılabilirsiniz.

🗺️ 5) 2025 için seçim rehberi (adım adım)

1. 📚 Katalog & Trafik: Orta-büyük + çoklu ülke/dil → PrestaShop veya (bütçe/ekip varsa) Adobe Commerce. Küçük-orta + içerik ağırlıklı → WooCommerce. MVP/hızlı → Shopify / BigCommerce / Wix.
2. 🔌 Özelleştirme & Entegrasyon: ERP/PIM/kargo/BI ile derin entegrasyon → PrestaShop (Admin API/Webservice) veya BigCommerce headless.
3. 💸 TCO & Sahiplik: Tam sahiplik → PrestaShop / WooCommerce / OpenCart. Yönetilen altyapı → Shopify / BigCommerce / Wix.
4. 🛡️ Güvenlik & Güncelleme: Açık kaynakta düzenli sürüm/yama takibi şart; özellikle Adobe Commerce bültenlerini izleyin.

🏗️ 6) Örnek mimariler

• PrestaShop (önerilen KOBİ): Nginx + PHP-FPM (güncel PHP), OPcache/Redis, CDN, Hummingbird tema; ödeme/kargo modülleri; ERP/PIM için Admin API/Webservice.
• WooCommerce (içerik ağırlıklı): WordPress + WooCommerce, nesne önbelleği, blok tabanlı ürün sayfası, kargo/ödeme eklentileri.
• Shopify (hızlı lansman): Tema editörü + App Store; kargo/ödeme uygulamaları; gerekiyorsa Hydrogen/Headless.
• BigCommerce (B2B/headless): BigCommerce çekirdeği + Next.js/React ön yüz; Multi-Storefront; B2B portal.

✅ 7) Sonuç ve öneri

Genel öneri: 2025 itibarıyla PrestaShop, modern teknoloji yığını, yeni Admin API’si, performans odaklı tema mimarisi ve esnek modüler yapısıyla
KOBİ-orta ölçekli markalar için en dengeli çözüm görünümünde. Doğru barındırma ile hız ve kararlılık belirgin şekilde iyileşir. 🚀

Hemen başla: PrestaShop’u optimize barındırma ile kurun →
saviorhost.com/prestashop-hosting ⚡

📚 Kaynaklar (resmî dokümantasyon & ürün sayfaları)

• PrestaShop: prestashop.com — devdocs.prestashop-project.org
• WooCommerce: woocommerce.com — github.com/woocommerce/woocommerce
• Shopify & Editions: shopify.com — shopify.com/editions
• Adobe Commerce (Magento): business.adobe.com — experienceleague.adobe.com
• OpenCart: opencart.com — docs.opencart.com
• BigCommerce: bigcommerce.com — developer.bigcommerce.com
• Wix eCommerce: wix.com/ecommerce — support.wix.com

Bölüm 1: Sorunun Kök Nedenleri (Teknik Analiz)

Yüksek CPU kullanımının ardındaki mekanizmaları daha detaylı inceleyelim.

1. Verimsiz Veritabanı Sorguları: CPU’nun En Büyük Düşmanı

Detay: Bir WordPress sayfası yüklendiğinde, arka planda onlarca SQL sorgusu çalışır. Bu sorgular, yazıları, yorumları, ayarları, eklenti verilerini veritabanından çeker. Sorun, bu sorguların “verimsiz” olmasıyla başlar.

• Döngü İçindeki Sorgular (Queries in Loops): Bir eklenti veya tema, sayfanızdaki her bir yazı için ayrı ayrı veritabanına sorgu gönderiyorsa (örneğin, her yazı için özel bir meta bilgisi çekmek), bu durum CPU üzerinde katlanarak artan bir yük yaratır. 20 yazının olduğu bir sayfada bu, 1 yerine 20+ sorgu anlamına gelebilir.
• JOIN ve Karmaşık Sorgular: Özellikle “İlişkili Yazılar” (Related Posts) gibi özellikler sunan eklentiler, birden fazla tabloyu birleştiren (JOIN) ve metin analizi yapan karmaşık sorgular kullanır. Bu sorgular, basit bir veri çekme işlemine göre CPU’yu çok daha fazla meşgul eder.
• Optimize Edilmemiş Meta Sorguları: wp_postmeta ve wp_usermeta tablolarında arama yapmak, doğru “indekslenmemişse” son derece yavaş olabilir. WordPress bu konuda esnektir ancak bu esneklik, kötü kodlanmış bir eklentinin tüm veritabanını taramasına neden olabilir.

Doğrulama: Bu durumu teşhis etmek için Query Monitor eklentisi en iyi araçtır. Sitenizin her sayfasında çalışan tüm SQL sorgularını, ne kadar sürdüklerini ve hangi eklenti/tema tarafından tetiklendiklerini size gösterir. Eğer bir eklentinin 0.5 saniyeden uzun süren sorgular yaptığını görürseniz, suçluyu buldunuz demektir.

2. WordPress Heartbeat API: Sessiz CPU Tüketicisi

Detay: WordPress yönetici paneline girdiğinizde, tarayıcınız ile sunucunuz arasında düzenli bir iletişim kurulur. Bu iletişim, “Heartbeat API” aracılığıyla gerçekleşir. Her 15-60 saniyede bir, sunucuya küçük AJAX istekleri gönderilir. Bu ne işe yarar?

• Yazı yazarken otomatik taslak kaydı yapar.
• Başka bir yazarın aynı yazıyı düzenleyip düzenlemediğini kontrol eder.
• Panodaki eklenti bildirimlerini günceller.

Sorun: Yönetici panelinde birden fazla sekme açık olduğunda veya birden fazla editör aynı anda çalıştığında, bu küçük istekler birleşerek sunucuya sürekli bir “ping” seli gönderir. Her ping, admin-ajax.php dosyasını çalıştırır ve bu da bir PHP sürecini tetikleyerek CPU kullanır. Bu durum, “admin-ajax.php yüksek CPU kullanımı” sorununun temel nedenidir.

Doğrulama: Hosting firmanızın kaynak kullanım raporlarında admin-ajax.php dosyasının sürekli en üst sıralarda olduğunu görüyorsanız, Heartbeat API’nin kontrolsüz çalıştığına emin olabilirsiniz.

3. WP-Cron: Ziyaretçi Tetiklemeli Zaman Bombası

Detay: WP-Cron, gerçek bir “cron job” (sunucunun belirli zamanlarda otomatik çalıştırdığı görev) değildir. Bu bir “pseudo-cron” yani sahte cron’dur. Çalışması için sitenize bir ziyaretçinin gelmesi gerekir. Ziyaretçi geldiğinde WP-Cron tetiklenir ve “Zamanı gelmiş bir görev var mı?” diye kontrol eder.

Sorun: Yüksek trafikli bir sitede, saniyede onlarca ziyaretçi gelebilir. Bu, WP-Cron’un saniyede onlarca kez tetiklenmesi demektir. Eğer zamanlanmış ağır bir görev varsa (örneğin, büyük bir yedekleme eklentisinin veritabanını taraması), birden fazla süreç aynı anda bu görevi çalıştırmaya çalışabilir. Bu “yarış durumu” (race condition), CPU’yu anında %100’e kilitleyebilir.

Doğrulama: Sunucu erişim loglarınızı (access.log) incelediğinizde, wp-cron.php dosyasına yapılan isteklerin (POST requests) çok sık olduğunu görürseniz, bu durumun sitenizi olumsuz etkilediği doğrulanmış olur.

4. Şişirilmiş wp_options Tablosu ve “Autoloaded Data”

Detay: WordPress’teki wp_options tablosu, sitenizin tüm ayarlarını, eklenti konfigürasyonlarını ve geçici verileri (transients) tutar. Bu tablodaki bazı veriler “autoload” (otomatik yükleme) olarak işaretlenir. Bu, WordPress’in her sayfa yüklemesinde bu verileri otomatik olarak belleğe yüklemesi anlamına gelir.

Sorun: Kullandığınız ve daha sonra sildiğiniz eklentiler, geride yüzlerce gereksiz satır bırakabilir. Zamanla, otomatik yüklenen veri miktarı 1 MB’ı aşıp 5-10 MB’lara çıkabilir. Her bir ziyaretçi için bu kadar büyük verinin sürekli belleğe yüklenmesi, hem bellek (RAM) hem de CPU kullanımını artırır.

Doğrulama: phpMyAdmin gibi bir veritabanı yönetim aracından aşağıdaki SQL sorgusunu çalıştırarak otomatik yüklenen verinin boyutunu görebilirsiniz:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 FROM wp_options WHERE autoload = 'yes';

Eğer sonuç 1-2 MB’ın üzerindeyse, bu tabloda optimizasyon yapmanız gerektiği doğrulanır.

Bölüm 2: Kapsamlı ve Uygulamalı Çözüm Stratejileri

Artık sorunun teknik kökenlerini bildiğimize göre, her birini hedef alan çözümlere geçebiliriz.

1. Önbellekleme (Caching) Masterclass: Sadece Kurmak Yetmez

Önbellekleme, CPU kullanımını düşürmenin en etkili yoludur. Mekanizmayı daha iyi anlayalım:

• Sayfa Önbellekleme (Page Caching): Bu en temel ve en etkili türdür. Ziyaretçiye sunulan dinamik PHP sayfasının tamamen statik bir HTML kopyasını oluşturur. Sunucu, PHP’yi çalıştırmak ve veritabanı sorguları yapmak yerine, bu hazır HTML dosyasını doğrudan sunar. Bu, CPU kullanımını %80-90 oranında azaltabilir.
  • Araçlar: WP Rocket (premium, en kolayı), LiteSpeed Cache (LiteSpeed sunucularda en iyisi), W3 Total Cache (gelişmiş, çok ayar gerektirir).
• Nesne Önbellekleme (Object Caching): Bu daha ileri bir tekniktir. Sık kullanılan ve tekrar tekrar çalıştırılan veritabanı sorgularının sonuçlarını, disk yerine doğrudan sunucunun belleğinde (RAM) tutar. Redis veya Memcached gibi teknolojilerle çalışır. Bir sorgunun sonucu bellekte varsa, WordPress veritabanına hiç gitmez. Bu, özellikle karmaşık sorgular yapan siteler ve WooCommerce gibi dinamik platformlar için CPU ve veritabanı yükünü ciddi anlamda azaltır.
  • Uygulama: Hosting firmanızın Redis veya Memcached desteği sunması gerekir. Ardından, ilgili eklenti (örn. “Redis Object Cache”) ile WordPress’e entegre edilir.
• Veritabanı Önbellekleme: W3 Total Cache gibi eklentiler, sorgu sonuçlarını diskte saklayarak bir tür nesne önbellekleme simülasyonu yapar, ancak Redis/Memcached kadar etkili değildir.

2. Gerçek Cron Job Kurulumu (Adım Adım)

WP-Cron’un yarattığı CPU artışlarını tamamen ortadan kaldırmak için:

1. WP-Cron’u Devre Dışı Bırakın: Sitenizin kök dizinindeki wp-config.php dosyasını açın ve /* That's all, stop editing! */ satırından önce şu kodu ekleyin:
   PHP

   define('DISABLE_WP_CRON', true);
   

2. Sunucudan Cron Job Ayarlayın: Hosting panelinize (cPanel, Plesk vb.) girin ve “Cron Jobs” bölümünü bulun.
3. Yeni Bir Cron Job Oluşturun: Belirli aralıklarla (örneğin saatte iki kez, yani her 30 dakikada bir) çalışacak şekilde ayarlayın. Çalıştırılacak komut alanına şunu yazın (siteniz.com’u kendi alan adınızla değiştirin):
   Bash

   wget -q -O - https://siteniz.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
   

   Bu komut, sunucunuzun kendisinin, belirlediğiniz aralıklarla wp-cron.php dosyasını tetiklemesini sağlar. Bu sayede zamanlanmış görevleriniz ziyaretçi trafiğinden bağımsız, düzenli ve kontrollü bir şekilde çalışır.

3. Heartbeat API’yi Kontrol Altına Almak

Bu API’yi tamamen kapatmak bazı işlevleri bozabilir. En iyi çözüm, çalışma aralığını uzatmaktır.

• Eklenti ile Çözüm: Heartbeat Control by WP Rocket gibi bir eklenti kurun. Bu eklenti, Heartbeat API’nin yönetici panelinde, site ön yüzünde ve yazı düzenleyicide hangi sıklıkla çalışacağını (örneğin 15 saniye yerine 120 saniyeye çıkarmak) veya tamamen devre dışı bırakılacağını ayarlamanıza olanak tanır. Genellikle aralığı 60-120 saniyeye çıkarmak çoğu site için güvenli ve etkilidir.

4. Gelişmiş Veritabanı Optimizasyonu

• wp_options Temizliği: “Advanced Database Cleaner” gibi eklentiler, wp_options tablonuzdaki “yetim” kalmış (artık bir eklentiye ait olmayan) satırları bulmanıza yardımcı olur.
• Autoload Verilerini Yönetin: Aynı eklentilerle veya SELECT option_name, LENGTH(option_value) FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC; sorgusuyla en büyük autoload verilerini tespit edip, gereksiz olanları (autoload='no' olarak) değiştirebilirsiniz. Uyarı: Bu ileri düzey bir işlemdir ve sitenizi bozabilir. Ne yaptığınızdan emin değilseniz bir uzmana danışın.
• Veritabanı Tablolarını Optimize Edin: phpMyAdmin üzerinden tüm tabloları seçip “Onar” (Repair) ve “Optimize Et” (Optimize) komutlarını çalıştırmak, tablo verimliliğini artırabilir. WP-Optimize eklentisi bunu sizin için otomatik yapar.

5. Hosting ve Altyapısal İyileştirmeler

• PHP Sürümünün Önemi: PHP 7.4’ten PHP 8.1’e geçmek, aynı donanımda saniyede işlenebilen istek sayısını neredeyse iki katına çıkarabilir. Çünkü PHP 8.x sürümleri, JIT (Just-In-Time) compiler gibi verimliliği artıran devrimsel teknolojiler içerir. Bu, CPU’nun aynı işi daha az “düşünerek” yapmasını sağlar. Hosting panelinizden tek tıkla PHP sürümünüzü yükseltebilirsiniz.
• Doğru Hosting Seçimi: Paylaşımlı hosting, bir apartman dairesi gibidir; komşunuzun (aynı sunucudaki başka bir site) yarattığı gürültü (yüksek CPU kullanımı) sizi de etkiler. VPS (Virtual Private Server) ise size özel kaynaklar (garantili CPU çekirdeği ve RAM) sunan bir dubleks daire gibidir. Siteniz iş yapıyor ve düzenli trafik alıyorsa, bu yatırım kaçınılmazdır.

Sonuç ve Eylem Planı

Yüksek CPU kullanımı, tek bir butona basarak çözülecek bir sorun değil, bir dizi optimizasyon ve doğru altyapı seçiminin sonucudur.

1. Acil Durum (İlk 1 Saat): Bir önbellekleme eklentisi (WP Rocket veya LiteSpeed Cache) kurup temel ayarlarını yapın. Bu, kanamayı durdurmak gibidir.
2. Teşhis (İlk Gün): Query Monitor kurarak yavaş sorguları ve sorunlu eklentileri tespit edin. Heartbeat Control ile AJAX isteklerini yavaşlatın.
3. Kalıcı İyileştirme (İlk Hafta): WP-Cron’u devre dışı bırakıp gerçek cron job kurun. Veritabanınızı WP-Optimize ile temizleyin. PHP sürümünüzü güncelleyin.
4. Geleceğe Yatırım (İlk Ay): Eğer sorunlar devam ediyorsa, trafiğiniz ve ihtiyaçlarınız mevcut hosting paketinizi aşmış demektir. VPS’e geçişi ve Redis gibi bir nesne önbellekleme sistemini planlayın.

Bu detaylı ve doğrulanmış adımları izleyerek, sunucunuzun “beynini” rahatlatabilir, sitenizi hızlandırabilir ve ziyaretçilerinize kesintisiz bir deneyim sunabilirsiniz.