Çoklu WordPress (Multisite) İçin Hosting Rehberi: Doğru Plan

Çoklu WordPress sitelerini tek kurulum altında yönetmenizi sağlayan WordPress Multisite, doğru kurulumla ciddi operasyonel avantaj getirir. Yanlış kaynak planı ve yetersiz önbellek (cache) ise yalnızca “yavaş açılıyor” problemini değil; bakım penceresi, yedekleme süreci ve büyüme limitlerini de etkiler. Bu rehberde, Multisite mimarisini referans alarak hangi hosting türünün ne zaman uygun olduğunu, hangi metriklere bakmanız gerektiğini ve pratik bir ölçekleme planını öğreneceksiniz.

Multisite’nin hosting gereksinimini belirleyen 4 değişken

Multisite’te tek bir WordPress çekirdeği ve paylaşılan bazı bileşenler olsa da, siteler arası yük dağılımı eşit olmaz. Aşağıdaki dört değişken, doğru hosting seçiminde belirleyicidir.

1) Site sayısı ve aynı anda gelen trafik (concurrent)

• Az sayıda site + düşük eşzaman: İnce tuning ile VPS (Virtual Private Server) veya yönetilen WordPress çözümleri yeterli olabilir.
• Çok site + eşzamanlı ziyaretçi: Uygun önbellek katmanları ve yeterli CPU kaynakları gerekir.

Özellikle Multisite’te panel işlemleri (ayarlar, tema güncellemeleri, eklenti senkronizasyonları) dönem dönem tepe yapabilir.

2) İçerik türü: Görsel/indirilebilir dosya oranı

Paylaşılan medya kütüphanesi ve dosya işlemleri disk I/O (girdi/çıktı) ihtiyacını artırır. Yüksek görsel yoğunluğunda: - Hızlı disk (çoğunlukla SSD/NVMe) şart olur. - PHP-FPM süreç sayısı (process) ve opcache ayarları belirleyici hale gelir.

3) Veritabanı yoğunluğu (MySQL/MariaDB) ve bakım sıklığı

Multisite’in “ayarlar tabloları”, blog/site tabloları ve kullanıcı ilişkileri veritabanını büyütür. Aşağıdakiler DB yükünü artırır: - Çok sayıda eklenti (özellikle arama, istatistik, form) - Sürekli otomatik gönderim/cron işleri - Sık tema/güncelleme çalıştırmaları

4) Önbellekleme mimarisi

Multisite’te her site için sayfa önbelleği ayrıştırılabilir. Net sonuç için şu katmanlar birlikte düşünülür: - Sunucu tarafı: Nginx/Apache cache, PHP opcache - Uygulama tarafı: page cache (ör. Redis tabanlı), object cache - CDN tarafı: statik içerik (CSS/JS/görseller)

Hosting türleri: Multisite için doğru eşleşme

Multisite için “tek doğru” yoktur; ancak şu eşleşmeler pratikte daha net çalışır.

1) Paylaşımlı hosting (shared) ne zaman uyar?

Aşağıdaki şartlar sağlanıyorsa paylaşımlı hosting denenebilir: - Multisite kuruluma izin veriliyor - Kaynak limitleri (CPU/RAM) net ve yükseltme yolu var - Günlük/haftalık yedekleme ve restore süreci tanımlı - Kullanıcı tarafından cache katmanı ve PHP sürümü yönetilebiliyor

Bu koşullar genellikle sağlanmadığı için Multisite’te çoğu senaryoda paylaşımlı hosting “sınırda kalır”. Belirti işaretleri şunlardır: - Trafik dalgalanmasında panel/tema sayfaları yavaşlıyor - DB performansı “peak” saatlerde düşüyor - Eklenti eklemek veya cron işleri nedeniyle zaman aşımı yaşanıyor

2) VPS/VDS: Multisite’te en kontrollü başlangıç

Kontrolü artırmak için çoğu ekip VPS veya VDS ile başlar. Avantajları: - Kaynak ataması net (CPU/RAM) - Dosya sistemi ve cache/cron ayarlarını uygulama şansınız olur - Yedekleme stratejisini standardize edebilirsiniz

Uygunluk senaryoları: - 5–50 arası site, orta düzey trafik - Çoklu eklenti kullanımı - Cron ile düzenli iş akışları (otomatik içerik, senkronizasyon, entegrasyon)

3) Dedicated (ayrık sunucu): Ölçek ve stabilite için

Dedicated sunucu, Multisite için şu durumlarda netleşir: - Eşzamanlı trafik sürekli yüksek - Birden fazla ekip aynı anda bakım yapıyor ve SLA beklentisi var - DB ve cache katmanları için ayrıştırılmış performans hedefleniyor

4) Yönetilen WordPress hosting: Operasyon yükünü azaltır

Multisite “operasyon” açısından zor olabilir. Yönetilen çözümler: - Staging (test ortamı), otomatik güncelleme pencereleri - Hazır cache/CDN entegrasyonları - Yedekleme ve tek tık restore süreçleri

sağlayabiliyorsa ekip zamanını kısaltır. Ancak mutlaka şunu doğrulayın: Multisite için kaynak limitleri ve log erişimi sınırları.

Kaynak planı: Multisite için pratik CPU/RAM/disk hedefleri

Aşağıdaki tablo “başlangıç noktası” gibi düşünülmelidir. NetKıyas’ta farklı sağlayıcılarda planlar, isimleri aynı olsa bile performans profili değişebilir; bu yüzden hedefleri metriklerle doğrulayın.

Hangi ölçümle “yeter” dediğinizi belirleyin?

Aşağıdaki üç gösterge, Multisite’te doğru karar vermeyi hızlandırır: - DB bağlantı süresi (özellikle wp-admin ve arama/arama benzeri isteklerde) - PHP-FPM boşta çalışan process sayısı ve request latency - Disk I/O bekleme süresi (yüksek görsel/medya ve log birikiminde artar)

Önbellek ve hız katmanları: Multisite’te en büyük kazançlar

Hosting seçerken yalnızca “kaç GB RAM var?” sorusuna odaklanmayın. Multisite performansını asıl belirleyen katmanlar:

H3: Sayfa cache (page cache) ve Redis object cache

• Page cache, anonim ziyaretçi trafiğinde en büyük farkı yaratır.
• Redis (veya benzer in-memory cache) object cache, WordPress’in sık kullandığı verileri hızlandırır.

Multisite’te her site farklı domain/subdomain kullandığından cache anahtarlarının doğru çalışması önemlidir. Bu yüzden sağlayıcının desteklediği cache sürümü ve ayar kontrolü kritiktir.

H3: CDN kullanımı ve statik içerik dağıtımı

Görsel ve statik dosyalar için CDN, origin sunucunun yükünü ciddi azaltır. Multisite’te site sayısı arttıkça toplam statik dosya talebi büyür.

Net kural: CDN’siz kurulumda origin sunucuda bant genişliği daha çabuk dolar ve DB/CPU üzerindeki dolaylı yük artar.

H3: PHP sürümü ve opcache

WordPress sürümünüz ile uyumlu PHP sürümünü kullanmak gerekir. Ayrıca opcache aktif olmalı ve yeterli hafızaya sahip olmalıdır.

Yedekleme (backup) ve restore testi: Multisite’in sigortası

Multisite’te sadece dosyaları değil, veritabanını ve site eşlemelerini (blog/site ilişkileri) birlikte düşünmeniz gerekir.

H3: Hangi yedekleme stratejisi gerekir?

• Dosya sistemi yedeği (uploads, config, tema/eklenti)
• Veritabanı yedeği (MySQL/MariaDB)
• Yedeklerin test edilmesi (restore denemesi)

Özellikle Multisite’te “yedek var ama restore edemiyoruz” riski gerçek bir maliyete dönüşür.

H3: Restore testini nasıl ölçün?

1. Son yedekten staging ortamına restore edin.
2. En az 3 siteyi açıp yönetici paneline giriş sürelerini ölçün.
3. Eklentiler ve cron işlerini kontrol edin.
4. Veritabanı büyümesini ve “tablo kilitlenmesi” belirtilerini izleyin.

Bir sağlayıcı seçerken “restore süresi kaç dakika?” sorusunu net olarak sorun. Basitçe “yedek alıyoruz” demek yeterli değildir.

İzleme ve loglar: Multisite’te arızayı hızla teşhis edin

Çoklu site kurulumlarında tek bir hata yüzünden tüm ağ etkilenebilir. Bu yüzden izleme şarttır.

İzlemeniz gereken temel metrikler

• CPU yükü ve load average
• RAM kullanımı (swap oranı dahil)
• DB performansı (slow query log)
• Disk alanı ve disk I/O
• 4xx/5xx oranı ve hata logları

Sağlayıcı, temel metrikleri panellerinde gösteriyor olmalı; ayrıca kritik log erişimi engellenmemelidir. Multisite’te bir eklenti hatası bazen sadece belirli siteye özgü olur. Log olmadan siteyi tek tek elemek zaman kaybettirir.

Ölçekleme planı: Ne zaman büyümelisiniz?

Aşağıdaki senaryolar “şimdi kapasite artırın” sinyalidir.

1) Panel yavaşlıyor, sayfa ise nispeten iyi

• Genelde DB tarafı ve admin işlemleri yük altındadır.
• Object cache ve DB tuning yetersiz kalmıştır.

2) Cron işleri zaman aşımına uğruyor

• CPU ve disk I/O yetersiz olabilir.
• Cron job’ların saat dağılımı sorunludur.

3) Trafik dalgasında hata oranı artıyor

• Page cache/CDN eksikliği veya origin kaynak limiti olabilir.
• Nginx/Apache worker ayarları ve PHP-FPM limitleri etkiler.

Net aksiyon: Önce cache/CDN optimizasyonu yapın, sonra gerekli olursa RAM/CPU yükseltin. Yalnızca “RAM ekleyelim” yaklaşımı, page cache ve object cache yoksa gecikmeyi tam çözmeyebilir.

WordPress Multisite için kontrol listesi (hosting seçmeden önce)

Satın alma öncesi şu maddeleri tek tek doğrulayın:

• Multisite kurulumu destekleniyor mu? (subdomain/domain tabanlı senaryolar dahil)
• PHP sürümü ve uzantılar (ör. gerekli olanlar) uyumlu mu?
• Redis (veya eşdeğer object cache) kullanılabiliyor mu?
• Page cache ve CDN entegrasyonu mümkün mü?
• Yedekleme sıklığı ve saklama süresi nedir? Restore testi yapılabiliyor mu?
• Disk tipi SSD/NVMe mi? Disk I/O limitleri var mı?
• Sunucu lokasyonu Türkiye trafiği için optimize mi?
• Log ve metrik erişimi hangi seviyede?

Sonuç: Multisite için doğru adım, kontrollü başlangıç ve doğrulanmış yedek

Multisite’te en iyi sonuç, “hosting türünü” yalnızca fiyatla değil; CPU/RAM hedefleri, cache katmanları ve yedekleme-restore testleriyle birlikte seçtiğinizde gelir. Önce Multisite ölçeğinizi (site sayısı + eşzamanlı trafik), sonra DB/CPU ihtiyacını ve cache mimarisini netleştirin. Aksiyon olarak: kısa bir stres testi planlayın, yedekten staging restore ederek süreyi ölçün ve ardından seçtiğiniz planı gerçek yük altında doğrulayın. Eğer bu adımları tamamladıktan sonra dahi panel veya DB tarafında tıkanma görüyorsanız bir üst kaynak seviyesine geçin.