Bir WooCommerce mağazası kurdunuz, en iyi temayı aldınız, resimleri optimize ettiniz ve en popüler önbellek (Cache) eklentisini kurdunuz. Sitenizin anasayfası saniyeler içinde açılıyor. Ancak bir müşteri ürünü sepete eklediğinde veya ödeme sayfasına (Checkout) geçtiğinde sistem adeta kilitleniyor, saniyelerce yükleniyor ikonu dönüyor. Neden?

Çünkü statik sayfa önbellekleme (Page Caching), e-ticaret sitelerinde işe yaramaz.

Sepet, ödeme ve hesabım sayfaları her müşteri için benzersizdir (dinamiktir) ve önbelleğe alınamaz. Müşteri sepete tıkladığı an, sunucunuz veritabanına (MariaDB/MySQL) canlı bir sorgu atar. Eğer veritabanınız şişmişse ve sunucunuzun I/O (Okuma/Yazma) hızı yetersizse, o müşteri ödeme yapmaktan vazgeçip sitenizi terk eder.

SaviorHost mühendislik ekibi olarak, WooCommerce altyapısını yavaşlatan veritabanı krizlerini ve bu darboğazları sunucu seviyesinde nasıl aşacağınızı teknik detaylarıyla inceliyoruz.

1. Sessiz Katil: wp_options Tablosu ve Autoload Krizleri

WordPress mimarisinde temanızın, eklentilerinizin ve WordPress çekirdeğinin tüm ayarları wp_options tablosunda tutulur. Bu tablodaki en tehlikeli sütun ise autoload (otomatik yükle) sütunudur.

Eğer bir ayarın autoload değeri ‘yes’ ise, sitenizin herhangi bir sayfası yüklendiğinde WordPress bu veriyi veritabanından çeker. Kötü kodlanmış eklentiler (özellikle eski sayfa yapıcılar ve istatistik eklentileri) sildikten sonra bile verilerini burada bırakır. Zamanla bu tablo megabaytlarca şişer. Her sayfa açılışında sunucunuz boş yere 5-10 MB veriyi RAM’e kopyalamaya çalışır ve işlemciyi boğar.

Autoload Boyutunuzu Nasıl Ölçersiniz?

İdeal bir WordPress sitesinde autoload edilen veri boyutu 800 KB ile 1.5 MB arasında olmalıdır. Bunu kontrol etmek için phpMyAdmin’e girin, veritabanınızı seçin ve şu SQL sorgusunu çalıştırın:

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

Eğer sonuç 2 MB’ın üzerindeyse (bazı e-ticaret sitelerinde 15-20 MB’a kadar çıkar), siteniz her tıklamada veritabanı altında eziliyor demektir.

Suçluyu Bulmak ve Temizlemek

Hangi eklentinin veya temanın bu tabloyu şişirdiğini bulmak için şu sorguyu çalıştırın:

SELECT option_name, length(option_value) AS option_value_length 
FROM wp_options 
WHERE autoload='yes' 
ORDER BY option_value_length DESC LIMIT 20;

Karşınıza çıkan listede, yıllar önce sildiğiniz bir eklentiye ait (_transient_ içermeyen) devasa satırlar görüyorsanız, bunları silerek (veya autoload değerini ‘no’ yaparak) TTFB (İlk Bayt Süresi) değerinizi anında yarı yarıya düşürebilirsiniz.

2. WooCommerce Transients (Geçici Veriler) Çöplüğü

WooCommerce, müşterilerin sepet verilerini, kargo hesaplamalarını ve API yanıtlarını hızlandırmak için veritabanında “Transients” (Geçici Veriler) oluşturur. Ancak yoğun trafiği olan sitelerde zamanı dolan (Expired) bu veriler veritabanından otomatik olarak silinmeyebilir. wp_options tablosunun içinde on binlerce _transient_wc_ satırı birikir.

Kesin Çözüm: Eğer sunucunuzda SSH (Terminal) erişiminiz ve WP-CLI kuruluysa, tek bir komutla tüm bu geçici çöpü silebilirsiniz: wp transient delete --all

Eğer terminal erişiminiz yoksa, WooCommerce > Durum > Araçlar sekmesine giderek “WooCommerce geçici verilerini (transient) temizle” butonunu kullanabilirsiniz. Bu işlemi haftada bir kez yapmak, veritabanı şişmesini önleyecektir.

3. Gerçek Performans Mimarı: Redis Object Cache

Sayfa önbelleklemenin (HTML Caching) dinamik sayfalarda (Sepet/Ödeme) işe yaramadığını söylemiştik. İşte burada devreye Nesne Önbellekleme (Object Caching) girer.

Redis, veritabanına yapılan karmaşık MySQL sorgularını alır ve bunları sunucunun ultra hızlı belleğinde (RAM) tutar. Müşteri sepete tıkladığında, sunucu hantal sabit diske gidip MySQL tablolarını aramak yerine, sonucu saniyenin binde biri hızında RAM’den (Redis üzerinden) çeker.

WooCommerce’de Redis Nasıl Aktif Edilir?

1. Öncelikle hosting firmanızın sunucuda Redis servisini desteklediğinden ve PHP-Redis eklentisinin açık olduğundan emin olun (SaviorHost altyapısında bu standart olarak aktiftir).

2. WordPress panelinizden “Redis Object Cache” eklentisini (Till Krüss tarafından geliştirilen) kurun.

3. Eklentiyi etkinleştirmeden önce wp-config.php dosyanıza şu güvenlik ve performans satırlarını ekleyin:

   PHP

   define('WP_CACHE', true);
   define('WP_REDIS_PREFIX', 'siteadi_'); 
   define('WP_REDIS_MAXTTL', 86400);
   

4. Eklenti paneline gidip “Enable Object Cache” butonuna tıklayın.

Eğer Redis doğru yapılandırıldıysa, WooCommerce wp-admin panelinizdeki hızlanmayı ve ödeme sayfasındaki gecikmenin tamamen ortadan kalktığını saniyeler içinde hissedeceksiniz.

4. Donanımın Sınırları: Neden Sadece Optimizasyon Yetmez?

Yukarıdaki tüm veritabanı temizliğini yaptınız, Redis’i kurdunuz, eklentilerinizi optimize ettiniz. Ancak kampanya dönemlerinde veya anlık ziyaretçi sayınız 100’ü geçtiğinde siteniz hala kasılıyor veya 508 Resource Limit hatası mı veriyor?

Çünkü yazılım, donanımın izin verdiği yere kadar koşabilir.

Sektördeki standart hosting firmaları, maliyetleri düşürmek için hala yavaş dönüşlü SATA SSD’ler ve eski nesil Intel işlemciler kullanır. Redis ne kadar hızlı olursa olsun, RAM’in işlemciyle (CPU) iletişim kurma hızı yetersizse veritabanınız yine de tıkanır.

SaviorHost ile Darboğazı Donanımla Aşın

Biz SaviorHost olarak, WooCommerce sitelerinin ne kadar fazla I/O (Giriş/Çıkış) operasyonuna ihtiyaç duyduğunu biliyoruz. Bu yüzden altyapımızı e-ticaret siteleri için özel bir mühendislikle tasarladık:

• Gen4 NVMe Diskler (7GB/s Okuma/Yazma): Standart SSD’lerin 15 katı hıza sahip Gen4 NVMe disklerimiz sayesinde, veritabanı okuma ve yazma işlemlerindeki gecikmeleri (I/O Wait) tamamen ortadan kaldırıyoruz.

• AMD Ryzen™ 9 7900 DDR5 Altyapısı: İşlemcinin tek çekirdek performansının (IPC) yüksek olması, dinamik PHP sorgularının anında işlenmesini sağlar.

• Arka Planda Yük Yaratmayan KeyHelp: Ağır kontrol panellerinin RAM sömürmesini engelliyor, tüm belleği Redis’e ve sitenizin veritabanı sorgularına ayırıyoruz.

Sitenizin yavaşlığı nedeniyle sepeti terk eden müşterilerinize veda edin. E-ticaret operasyonunuzu Premium Linux Web Hosting paketlerimize taşıyın, 15 Gün İade Garantisi ile gerçek bir sunucunun WooCommerce’i nasıl uçurduğunu kendiniz deneyimleyin.

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!

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ı.

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.

İlk 5 Dakikalık Teşhis

1. Hata kayıtları: cPanel: Metrics → Errors; Plesk: alan adında Logs; CWP: HTTPD/Nginx, PHP, AutoSSL ve servis log’ları.
2. DNS kontrolü: A/AAAA, MX, TXT (SPF/DKIM/DMARC)
3. SSL/AutoSSL: Let’s Encrypt’i yenile; 80/TCP erişilebilir olmalı (HTTP-01 doğrulaması).
4. PHP limitleri: upload_max_filesize + post_max_size + max_execution_time
5. Mail teslimi: SPF/DKIM/DMARC + rDNS(PTR)

DNS / Alan Adı Hataları

Belirti: Site bazı bölgelerde açılıyor/hiç açılmıyor, e-postalar gelmiyor.

Panel yolları: cPanel: Domains → Zone Editor; Plesk: Websites & Domains → DNS Settings; CWP: DNS Functions.

dig +short example.com A
dig +short example.com AAAA
dig +short example.com MX
dig +short NS example.com

Not: NS değişiminde TTL/propagasyon 24–48 saat sürebilir.

SSL/TLS (HTTPS) ve AutoSSL

Belirti: “Not secure”, “expired”, “hostname mismatch”, LE başarısız.
Kritik: Let’s Encrypt HTTP-01 yalnızca 80/TCP’ten doğrular.

• cPanel/WHM: AutoSSL (sağlayıcı: Let’s Encrypt)
• Plesk: Let’s Encrypt / SSL It! (site + mail + Plesk arayüzü)
• CWP: Loglar → /var/log/cwp/autossl.log, /root/.acme.sh/acme.sh.log

Öneri: HTTP→HTTPS yönlendirmesi kalsın; fakat .well-known/acme-challenge dosyalarına 80’den erişim bozulmasın.

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Web Sunucusu & Uygulama Hataları (500/502/503/504)

İzlenecek yol: cPanel Errors → ip

Kime göre? Yeni–orta seviye kullanıcı, WordPress ağırlıklı, paylaşımlı hosting kullananlar.
Amaç: Hızlı uygulanan, hatayı çözen, arama niyeti yüksek konularla organik trafik toplamak.

🔍 Neden paylaşımlı hostta güvenlik kritik?

Aynı fiziksel sunucuda birçok site bir aradadır. İzolasyon zafiyetleri, log dosyaları üzerinden bilgi sızdırma (log snooping) ve log zehirleme (log poisoning) gibi saldırı yüzeyleri doğurabilir. Bu yüzden temel korumalar + doğru yapılandırma şarttır. arXiv+1

1) 🧱 ModSecurity (WAF) açık mı? (cPanel → Security → ModSecurity)

Ne sağlar? HTTP isteklerini imza/kurallarla filtreleyip yaygın web saldırılarını kırpar. cPanel’de her domain için aç/kapat yapılabilir; erişemiyorsan sağlayıcından etkinleştirmesini iste. Kurallar için en yaygın set OWASP Core Rule Set (CRS)’tir. cPanel & WHM Documentation+1

İpucu: WAF bazen yanlış pozitif üretebilir. Gerekirse alan adına özel kural istisnası veya geçici kapatma ile test edebilirsin (kalıcı kapatma önerilmez). cPanel & WHM Documentation

2) 🔒 HTTPS zorunlu + (mümkünse) HSTS

Trafiği şifreleyen HTTPS hem güvenlik hem de SEO tarafında onaylı bir sinyaldir. Sertifikan yoksa kur; varsa HTTP→HTTPS yönlendirmesini zorunlu kıl ve HSTS değerlendir. Google for Developers

3) 🧰 Dosya/klasör izinlerini düzelt (WordPress)

Genel pratik:

• Dosyalar: 644

• Klasörler: 755
  Bu kombinasyon, çoğu WordPress kurulumunda güvenli/çalışır denge sunar. Ayrıntılı izin rehberi için resmi geliştirici dokümantasyonuna bak. WordPress Developer Resources

4) 🧾 .htaccess ile hızlı korumalar

a) Dizin listelemeyi kapat

Bu, klasör içeriğinin listelenmesini durdurur; uygulanabilirliği AllowOverride ayarına bağlıdır. Apache HTTP Server

b) Hassas dosyaları web’den gizle

Apache 2.4’te Require all denied ile eşleşen dosyalar doğrudan sunulmaz. (Yine AllowOverride önemli.) Apache HTTP Server

Not: .htaccess her ortamda her direktifi çalıştırmayabilir; sunucu yapılandırması belirleyicidir. (Apache, .htaccess’in nasıl ve ne zaman kullanılması gerektiğini resmi kılavuzda anlatır.) Apache HTTP Server

5) 🔐 SFTP/SSH kullan; FTP’yi bırak

FTP veriyi ve parolaları şifrelemeden taşır. SFTP/SSH ile güvenli kanaldan aktarım yap. WordPress güvenlik kılavuzları da SSH/SFTP’yi önerir. WordPress Developer Resources+1

6) 🧩 PHP tarafında “sınırlandırma” (mümkün olan yerde)

• open_basedir: PHP’nin erişebileceği dizinleri sınırlar (siteler arası dolaşmayı önlemeye yardım eder). Etkinleştirme şekli hosting ortamına göre değişir. php.net

• disable_functions: exec, shell_exec, system gibi riskli fonksiyonları devre dışı bırakır (destek/etki PHP sürümü ve handler’a bağlıdır). php.net

cPanel’de nereden bakarım? MultiPHP INI Editor üzerinden alan adına tanımlı, panelin izin verdiği yönergeleri düzenleyebilirsin. (Bazı direktifler paylaşımlı hostta kilitli olabilir.) cPanel & WHM Documentation

7) 💾 Yedeklemeyi otomatiğe bağla + geri yüklemeyi test et

cPanel Backup Wizard ile tam veya kısmi yedek alabilir, ihtiyaçta geri yükleyebilirsin. Gerçekten işe yarayıp yaramadığını en az bir kez küçük bir geri yükleme testiyle doğrula. cPanel & WHM Documentation

8) 🚀 CDN ekle (temel hız + saldırı yüzeyi azaltma)

CDN; içeriği kullanıcıya yakın POP’lardan ileterek performans ve erişilebilirlik kazandırır; çoğu CDN aynı zamanda temel DDoS/WAF katmanı da sunar. Başlangıç planları genelde yeterlidir. (Seçim marka bağımsız.) (Genel ilkedir; ürün isimleri değişebilir.)

9) 🧹 Eklenti/tema hijyeni (WordPress)

• Sadece güvenilir kaynaklardan tema/eklenti.

• Güncellemeleri geciktirme (major öncesinde mutlaka yedek).

• Kullanmadıklarını sil (pasif bırakma).
  Bu tavsiyeler WordPress güvenlik kılavuzlarında temel başlıklardır. WordPress Developer Resources

10) 👀 İzleme ve log bilinci

Erişim/hatâ loglarını düzenli kontrol et (403, 404 patlamaları, sıra dışı POST istekleri). Paylaşımlı hostta log izolasyonu yoksa risk büyür; sağlayıcından her alan adının loglarının ayrıldığını teyit et. arXiv

✅ 30 Dakikalık Hızlı Kontrol Listesi

1. ModSecurity: cPanel → Security → ModSecurity → On. (Her domaini kontrol et.) cPanel & WHM Documentation

2. HTTPS: Sertifika kurulu mu? HTTP→HTTPS yönlendirme aktif mi? (SEO + güvenlik) Google for Developers

3. .htaccess:

   • Options -Indexes ekle. Apache HTTP Server

   • FilesMatch ile .env/.ini/.log vb. engelle. Apache HTTP Server

4. İzinler: Dosyalar 644, klasörler 755 mi? (WordPress resmî kaynak) WordPress Developer Resources

5. SFTP: FTP yerine SFTP/SSH kullan. wordfence.com

6. PHP sınırları: (Varsa) open_basedir ve disable_functions durumunu incele. php.net+1

7. Yedek: cPanel Backup Wizard ile kısmi yedek al; küçük bir geri yükleme testi yap. cPanel & WHM Documentation

🧪 Sık karşılaşılan mini sorunlar & hızlı çözümler

“Dizinlerim listeleniyor, herkes görüyor!”
.htaccess dosyana Options -Indexes ekle; sonuç görmüyorsan sunucuda AllowOverride kısıtlı olabilir (destekle kontrol et). Apache HTTP Server

“WAF kapatınca hızlanır mıyım?”
Genelde kapatma; ModSecurity + OWASP CRS yaygın saldırıları daha başta kırpar. Hata yaşıyorsan kural istisnası veya domain bazlı ince ayar yap. cPanel & WHM Documentation+1

“FTP güvenli mi?”
Hayır, parolalar şifresiz gider. SFTP/SSH kullan. wordfence.com

📎 Kod şablonları (kopyala–yapıştır)

.htaccess – Dizin listelemeyi kapat + hassas dosyaları engelle

(Apache 2.4 söz dizimi; AllowOverride = All değilse çalışmayabilir.) Apache HTTP Server

wp-content/uploads için örnek izinler

• Klasörler: 755

• Dosyalar: 644 WordPress Developer Resources

📚 Kaynaklar (Güvenilir dokümantasyon)

• cPanel – ModSecurity (kullanıcı arayüzü & WHM kurulumu notları) cPanel & WHM Documentation

• OWASP Core Rule Set (CRS) – proje sayfası owasp.org

• Google – “HTTPS bir sıralama sinyali” duyurusu (resmî) Google for Developers

• WordPress Developer – Dosya izinleri WordPress Developer Resources

• cPanel – Backup Wizard cPanel & WHM Documentation

• WordPress Hardening (SSH/SFTP önerileri dahil) WordPress Developer Resources

• Apache – .htaccess ve yapılandırma bölümleri Apache HTTP Server+1

• Akademik – Paylaşımlı hosting’te log saldırıları (snooping/poisoning) arXiv+1

1. Eklentiyle taşıma (Migrate Guru, All-in-One WP Migration, Duplicator)

2. Manuel + WP-CLI (tam kontrol, seri veriler için güvenli URL güncelleme)

3. Özel senaryolar (WooCommerce, sıfır kesinti, DNS/SEO ayrıntıları)

0) Preflight: Taşıma Öncesi Yapılacaklar (Kontrol Listesi)

• Tam yedek (dosyalar + veritabanı).

• Sürüm uyumluluğu: Yeni hostun PHP ve DB sürümleriyle tema/eklenti sürümlerini denkleştir.

• DNS planı: Değişiklikten 24–48 saat önce A/AAAA kaydının TTL’ini 300 sn (5 dk) civarına indir; değişiklik sonrası tekrar yükselt. Bu, kayıtların daha hızlı güncellenmesine yardım eder. docs.rackspace.com+1

• Önbellek/CDN notları: Cloudflare/benzeri CDNi geçici devre dışı bırakmayı ve yeni origin IP’yi doğrulamayı planla. (TTL mantığı için bkz.) Cloudflare Docs

• Staging ve bakım modu: Düşük trafik saatinde geçiş yap; mümkünse staging’de prova et.

• E-posta sürekliliği: Alan adı/Sunucu değişiminde MX, SPF, DKIM kayıtlarını not alıp yeni DNS’e taşı.

• SEO hazırlığı: Eski→yeni URL eşlemelerini (301) çıkar; GSC “Change of Address” için yetkileri hazırla. Google for Developers+1

1) Yöntem A — Eklentiyle Kolay Taşıma

A.1) Migrate Guru (büyük sitelerde güçlü)

• Artıları: Seri veriyi doğru işler, otomatik arama-değiştirme yapar; çok büyük sitelerde ara sunucu kullanarak sunucunu yormaz. 5.000+ host uyumluluğu. WordPress.org+1

• Kısa akış: Eski sitede eklentiyi kur → “Yeni host bilgileri” → tek tıkla taşı → raporu izle.

• Not: Birçok yönetilen host (ör. Kinsta) için resmi adım adım yönergeler mevcuttur. Kinsta®

A.2) All-in-One WP Migration

• Artıları: Çok yaygın; “.wpress” arşivini dışa aktar → yeni sitede içe aktar. WordPress.org+1

• Not: Ücretsiz sürümde dosya boyutu sınırı olabilir; büyük sitelerde uzantı gerekebilir. (Resmi kullanım notlarına bak.) help.servmask.com

A.3) Duplicator

• Artıları: “Arşiv + installer.php” ile sihirbazlı kurulum; multisite desteği Pro lisansla. Duplicator+1

• Kısa akış: Paket oluştur → archive.zip + installer.php’yi yeni sunucuya yükle → kurulum sihirbazını çalıştır.

Eklenti yöntemlerinden sonra mutlaka: Kalıcı bağlantıları yeniden kaydet, cache/CDN’i temizle; görseller-CSS-JS ve formları test et.

2) Yöntem B — Manuel + WP-CLI (ileri seviye, temiz kontrol)

B.1) Dosyaları taşı

/wp-content/ (temalar, eklentiler, uploads) kritik. SCP/rsync veya panel dosya yöneticisi ile aktar.

B.2) Veritabanını aktar

(WP-CLI resmi komutları.) WordPress Developer Resources

B.3) wp-config.php

DB_NAME, DB_USER, DB_PASSWORD, DB_HOST değerlerini yeni DB’ye göre güncelle.

B.4) URL’leri seri veriyi bozmadan güncelle

wp search-replace, seri alanları güvenle günceller; manuel SQL REPLACE yerine önerilir. (VIP dokümanları da bu yaklaşımı destekler.) WordPress Developer Resources+1

B.5) Kalıcı bağlantılar ve test

• Ayarlar → Kalıcı Bağlantılar → Kaydet

• DNS’i değiştirmeden test: Bilgisayarındaki hosts dosyasına yeni sunucu IP’sini ekleyerek trafiği etkilemeden gözden geçir. (Windows/macOS/Linux adım adım kılavuzlar için bkz.) docs.hypernode.com+1

3) WooCommerce (dinamik veri) taşıma notları

• Sipariş/üye verisi sürekli değişir; taşıma sırasında veri kaybını önlemek için bakım modu veya kısa bir donma penceresi planlayın. BlogVault

• Test ve delta senkronu: Canlı sipariş akışın varsa staging → prod arasında “son farkı” alma planı yap ya da taşıma penceresinde ödemeyi kapat. (Çeşitli rehberler delta yönetimi ve müşteri/sipariş aktarımı detaylarını anlatır.) Simon Gondeck+1

• HPOS / yeni sipariş tablosu kullanıyorsan uyumluluğu test et. WordPress Web Development

• WooCommerce’e özel adımlar (host dosyasıyla önden test, 301’ler, DNS ve SEO): pratik rehberler mevcut. Duplicator

4) Sıfır/Kritik Düzeyde Kesinti için Stratejiler

• Blue-Green yaklaşımı: Eski (blue) ve yeni (green) ortamlardan birini canlı tutup trafiği yavaşça yenisine al; tersine çevirmesi kolaydır. (Genel kavram ve pratik rehberler) sitebox.io+1

• DNS tarafı: TTL’i önceden düşürmek, geçiş anında etkilerin hızlı görünmesine yardım eder. docs.rackspace.com+1

5) DNS Geçişi (Adım Adım)

1. TTL düşük mü? (24–48 saat önce 300 sn’ye çek.) docs.rackspace.com

2. A/AAAA kaydını yeni IP’ye güncelle; gerekiyorsa CDN’de yeni origin’i tanımla.

3. Yayılımı farklı ağlardan kontrol et. TTL; değişikliklerin kullanıcıya yansıma hızını belirler. Cloudflare Docs

4. SSL/TLS sertifikasını yeni sunucuda etkinleştir (Let’s Encrypt vb.).

5. E-posta (MX) ve diğer DNS kayıtlarını doğrula.

6) SEO Kaybı Yaşamamak için: 301 & Google Search Console

• Kalıcı 301 yönlendirmeleri ile tüm eski URL’leri karşılıklarına yönlendir. (Eklentiyle veya .htaccess üzerinden yapabilirsin.) Hostinger+1

• Site taşıma (URL değişimi) en iyi uygulamalarını uygula; Google’ın resmi “Site Moves” dokümanını izle. Google for Developers

• Google Search Console → Change of Address aracıyla alan adını taşıdığını Google’a bildir. Google Destek

• Yeni sitemap gönder; tarama hatalarını (404) ve yönlendirme zincirlerini kontrol et.

7) Sorun Giderme Hızlı Tablosu

8) Örnek “Komut Satırı” Akışı (Kopyala-Yapıştır)

(Komut söz dizimi WP-CLI’nin resmi belgelerine dayanır.)