Çoklu WordPress Sitesi (Multisite) için Hosting Rehberi

Çoklu WordPress sitesi (WordPress Multisite) tek bir WordPress kurulumunda birden fazla siteyi yönetmenizi sağlar; ancak kaynak ihtiyacı ve operasyon yükü tek siteye göre belirgin şekilde artar. Yanlış hosting seçimi, aynı anda yükselen trafiğe dayanamayacağınız bir mimariye yol açabilir. Bu rehberde Multisite için VPS/VDS, depolama, cache (Redis/APCu), eklenti yükü, yedekleme ve güvenlik başlıklarında net bir kontrol planı bulacaksınız.

Aşağıdaki bölüm ve tablolar, “hangi senaryoda hangi altyapı tipi” sorusunu somutlaştırır; ardından da performans ve sürdürülebilirlik için uygulanabilir ayarları listeler.

Multisite neyi büyütür? (Tek site değil, tek havuz)

WordPress Multisite, her alt siteyi (site) ayrı ayrı oluşturur; fakat altyapı düzeyinde tek bir çekirdek WordPress ve çoğu zaman aynı veritabanı mantığıyla çalışır. Bu yüzden aşağıdaki maliyetler çoğalır:

• Veritabanı (MySQL/MariaDB) yükü: Her site eklenti ayarları, içerik sorguları, kullanıcı/rol tabloları ve cron işleriniz için ek okuma-yazma üretir.
• Cache ihtiyacı: Page cache tek başına her şeyi çözmez; özellikle oturum (session) ve dinamik sayfalar için doğru cache stratejisi gerekir.
• Eklenti ve tema çeşitliliği: Multisite’de farklı site farklı eklenti kullanıyorsa, backend yükü artar. Tüm eklentilerin tüm sitelerde aktif olduğu varsayımı doğru değildir; ancak aynı ortamda hizmet verildiği için toplam yük yine büyür.
• İçerik ve medya depolama: Her site ayrı medya kullanıyorsa disk IOPS ve depolama performansı belirleyici olur.
• Yedekleme süresi ve veri boyutu: Tek site yedeği kolaydır; Multisite’de hem veritabanı hem medya aynı anda korunmalıdır.

Bu büyümenin sonucu şudur: Multisite için “tek sitelik WordPress hosting” yerine ölçeklenebilir bir mimari planlamak gerekir.

Doğru hosting tipini seçme: VDS mi VPS mi? (Net karar matrisi)

Multisite’de hosting tipi seçimi, beklenen ziyaretçi trafiği değil; eşzamanlı istek (concurrency), eklenti sayısı ve veritabanı performansı ile bağlantılıdır. Net bir karar için aşağıdaki matrisi kullanın.

Hosting tipleri ne zaman mantıklı?

• Paylaşımlı hosting: Düşük trafik, sınırlı eklenti ve basit medya kullanımı. WordPress Multisite için çoğu senaryoda yetersiz kaynak politikaları görülür.
• VPS: Daha sınırlı ölçek; tek bir sunucuda kaynak paylaşımı yoktur, fakat üst limitler hızlı dolar. Küçük/orta ölçekte doğru ayarla kullanılabilir.
• VDS (Dedicated mantığına yakın VPS): Kaynak garantisi ve izolasyon daha güçlü olabilir. Çok sayıda alt site, daha yüksek eklenti çeşitliliği ve daha sık güncelleme/işlem yapan yapılar için daha güvenli seçimdir.
• Dedicated sunucu: Eklenti, cache, cron ve özellikle yüksek eşzamanlı okuma-yazma ile veritabanı baskısı çok yükseliyorsa tercih edilir.

Aşağıdaki tablo “senaryo → önerilen altyapı tipi” yaklaşımını özetler.

Not: Trafik aralığı “yaklaşık” kullanılmalıdır. Net belirleyici, sunucuda aynı anda oluşan yüktür. Eşzamanlı istek yükseldiğinde paylaşımlı hostingde darboğaz daha erken oluşur.

Kaynak planlama: CPU/RAM/Diski Multisite’ye göre sayın

Multisite hosting seçerken yalnızca “kaç GB RAM” bakmak yetmez. PHP-FPM, veritabanı bağlantıları, cache ve disk gecikmesi birlikte değerlendirilmelidir.

Net kaynak hedefleri (başlangıç değerleri)

Aşağıdaki değerleri minimum başlangıç noktası olarak alın. Daha sonra gerçek metriklerle revize edin.

1) 5-20 site (orta ölçek)

• CPU: 4-6 çekirdek sınıfı
• RAM: 8-16 GB
• Disk: SSD/NVMe, en az 100-300 GB (medya büyümesine göre)
• Veritabanı: MariaDB/MySQL için bağlantı limitleri ve indeksler düzenlenmiş olmalı

2) 20+ site (büyük ölçek)

• CPU: 8 çekirdek ve üzeri
• RAM: 16-32 GB
• Disk: NVMe + yüksek IOPS
• Ek: Redis (object cache) + iyi tasarlanmış cron

Neden RAM ve disk IOPS kritik?

• WordPress Multisite’de admin işlemleri ve farklı site içerikleri aynı anda sorgulanabilir.
• Medya dosyaları (resim/video) hem okuma hem yedekleme süresini etkiler.
• Yüksek disk gecikmesi, görsel yükleme ve veritabanı operasyonlarını zincir gibi etkiler.

Cache ve performans: Object cache, sayfa cache ve PHP ayarı

Multisite’de performans problemi genellikle “site sayısı arttı” diye değil, cache kapsamı ve dinamik içerik nedeniyle büyür.

Cache katmanları (net hedef)

1. Page cache (sayfa önbelleği): Statik sayfalarda hızlı yanıt.
2. Object cache (APCu/Redis): WordPress içi sorguların ve seçeneklerin tekrar tekrar hesaplanmasını azaltır.
3. OPcache: PHP derleme çıktısını saklar.
4. CDN (opsiyonel ama etkili): Resim/JavaScript/CSS yükünü origin sunucudan alır.

Redis/APCu ne zaman gerekir?

• Sadece hafif yük ve tek sunucuda sınırlı trafik varsa APCu yeterli olabilir.
• Multisite’de çok site ve çok istek varsa Redis daha iyi sonuç verir; ayrıca cache invalidation (geçersiz kılma) stratejisi daha kontrollü uygulanır.

Net karar: Multisite’de “site sayısı 10+” seviyesine gelindiğinde Redis (object cache) genellikle somut fark yaratır.

PHP-FPM ve MySQL ayarlarında kontrol listesi

• PHP-FPM worker sayısı sunucu çekirdeğiyle uyumlu olmalı.
• MySQL bağlantı havuzu (max_connections) kontrol edilmeli.
• Slow query log açılmalı ve indeks eksikleri yakalanmalı.
• Cron işlerinin aynı zaman diliminde çakışması engellenmeli.

Yedekleme ve geri dönüş: Multisite yedeği nasıl planlanır?

Multisite’de yedekleme, “dosyaları kopyala” seviyesinde kalmamalı; geri dönüş testi yapılmalıdır.

Net yedek bileşenleri

• Veritabanı (backup DB): WordPress Multisite’de ana veri burada.
• Medya dosyaları (uploads): Her site için ayrı klasör mantığı olabilir; yine de tek havuzda saklanır.
• Wp-config + özel ayarlar: DB host/user, table prefix, güvenlik ayarları.
• Eklenti/tema dosyaları: Güncelleme sonrası uyumluluk.

Yedekleme sıklığı (örnek plan)

• İçerik sık güncelleniyorsa: günlük DB yedeği + 1-2 saat aralıklı medya incremental stratejisi
• Düşük güncelleme varsa: gün aşırı DB + haftalık medya

Gerçek ölçüm: Yedeğin tamamlanma süresi, trafiğin yoğun olmadığı saatlerle çakışmalıdır.

Geri dönüş testi (en sık atlanan nokta)

Yedek almanın tek başına değeri yoktur. En azından staging benzeri bir ortamda: - Yedek restore edilsin, - 2-3 alt site uçtan uca açılış test edilsin, - admin panelde kullanıcı/tema yönetimi kontrol edilsin.

Güvenlik: Multisite’de risk “site sayısı” ile artar

Multisite, saldırı yüzeyini artırır; çünkü bir alt site kompromize olursa tüm kurulum etkilenebilir.

Uygulanması gereken net güvenlik önlemleri

• WAF / DDoS koruması: Web isteklerini katman katman filtrelemek.
• Fail2ban veya benzeri brute-force engelleyici: Admin girişlerinde kilitleme.
• Admin erişimi için ek doğrulama: (örn. IP kısıtlama, 2FA)
• Düzenli WordPress + eklenti güncellemesi: Gecikme risk üretir.
• Dosya izinleri (permissions) ve gereksiz dosyaların kaldırılması

Modüler güvenlik kurgusu

• Tüm alt sitelerin aynı admin yetkileriyle yönetilmesi yerine rol bazlı (role-based) yetkilendirme yapın.
• Çok site yöneten ekiplerde kullanıcı bazlı aktivite loglarını inceleyin.

Multisite’te alt site büyütme stratejisi: Kaynakları boşa harcamayın

Multisite’te site sayısı arttıkça “boşta çalışan eklentiler” ciddi maliyet olur.

Net optimizasyon adımları

• Kullanılmayan eklentileri site bazında devre dışı bırakın.
• Aynı işi yapan eklentileri üst üste bindirmeyin (ör. 3 ayrı cache eklentisi).
• Görsel optimizasyonu: WebP/AVIF dönüşümü ve boyut kırpma.
• Arka plan işleri (cron): Zamanlama çakışmasını önleyin.

Net kontrol planı: Hosting seçmeden önce 12 soru

Aşağıdaki sorulara net cevap verin; ardından hostingte aranan özellikleri belirleyin.

1. Multisite kaç alt site içerecek? (şu an + 12 ay sonrası)
2. Eklenti sayısı ve türü nedir? (cache, SEO, security, ecommerce)
3. Medya hacmi toplam kaç GB ve aylık büyüme oranı nedir?
4. Ortalama trafiğin yanı sıra tepe (peak) istek değeriniz var mı?
5. Veri tabanı büyümesi bekliyor musunuz? (özellikle yorum, log, sipariş)
6. Object cache için Redis kullanma planınız var mı?
7. Cron işleri kaç dakikada bir çalışıyor?
8. Yedekleme hedefiniz: Geri dönüş süresi (RTO) ve veri kaybı (RPO) ne olmalı?
9. WAF ve DDoS koruması sunucunun içinde mi yoksa ayrı katmanda mı?
10. Sağlayıcı size root erişim veriyor mu (uygulama düzeyinde optimizasyon için kritik olabilir)?
11. Güncelleme/ bakım sırasında SLA nasıl?
12. Ölçekleme: CPU/RAM/disk büyütme süreci pratik mi?

Sonuç: Multisite’te “tek site gibi” hosting seçmeyin

Çoklu WordPress sitesi için doğru hosting, yalnızca “kendi siteniz açılıyor” seviyesinde değil; veritabanı yükü, cache katmanı, medya IOPS ve yedekleme geri dönüş süresi birlikte ele alınarak seçilir. Eğer Multisite 10+ alt siteye yaklaşıyorsa, VDS/VPS + Redis object cache + düzenli DB/medya yedeği kombinasyonu somut şekilde daha güvenilir olur.

Aksiyon önerisi: Önce 12 soruya net cevap verin, ardından minimum kaynak planınızı (CPU/RAM/SSD) belirleyin. Son aşamada, seçtiğiniz hostingde Redis/APCu planı, fail2ban/WAF kapsamı ve yedek geri dönüş testi için sağlayıcının sunduğu imkanları kontrol edin. Böylece Multisite büyürken performans çöküşü ve geri dönüşsüz yedek riskini minimize etmiş olursunuz.