Çoklu WordPress (Multisite) için doğru hosting seçimi
Çoklu WordPress (multisite) için VDS/VPS, disk, RAM, cache ve yedekleme gereksinimlerini net örneklerle karşılaştırın.
Çoklu WordPress kurulumu (WordPress Multisite), tek bir WordPress çekirdeği üzerinden birden fazla siteyi yönetmeyi sağlar. Ancak “tek panelde çok site” fikri, kaynak planlamasını doğru yapmazsanız performans kaybı ve yönetim karmaşası yaratır. Bu rehberde, Multisite için hangi hosting modelinin ne zaman doğru olduğuna; CPU/RAM disk, cache (sayfa önbelleği), veritabanı (MySQL/MariaDB) ve yedekleme (backup) gibi somut başlıklara göre karar vermeyi öğreneceksiniz.
Hedefimiz şu: Okuduktan sonra, sitenizin sayısı ve trafiğine göre net bir hosting senaryosu belirlemek ve gereksiz masraftan kaçınmak. Aşağıdaki öneriler, WordPress Multisite’ın tipik ihtiyaçlarını merkeze alır; ayrıca VDS/VPS ile paylaşımlı hosting arasındaki farkları da net şekilde ayırır.
Multisite, “hosting aynı ama farklı” mı?
Multisite’de her alt site (site) ayrı içerikler taşır; ama bazı bileşenler paylaşılır. Tipik olarak: - WordPress kodu ve admin paneli çoğu işlemde ortak kullanılır. - Her alt site kendi veritabanı tablolarında/alanlarında veri tutar (kurulum tipine göre). - Eklentiler, tema ve ayarlar tek havuzdan yönetildiği için, eklenti sayısı ve cron/paket güncellemeleri performansı etkiler.
Bu yüzden Multisite, “tek site hostinginde olduğu gibi aynı hesapla” yaklaşımıyla yönetilemez. Özellikle şu alanlar kritik olur: - Veritabanı (sorgu yükü, yavaş sorgular, tablo büyümesi) - Disk I/O (özellikle loglar, cache dosyaları, medya kullanımı) - CPU (PHP worker sayısı, yoğun sayfa üretimi) - Cache katmanları (sayfa önbelleği + nesne önbelleği) - Yedekleme (tek tek site değil tüm ağ için tutarlılık)
Multisite için en sık performans darboğazları
1) Veritabanında (MySQL/MariaDB) yavaş sorgular ve büyüyen tablolar. 2) PHP tarafında paralel istekleri karşılayacak worker kapasitesi olmaması. 3) Disk I/O gecikmesi (özellikle paylaşımlı disklerde). 4) Cache’in düzgün çalışmaması (page cache kapalı, object cache yok, CDN kullanılmıyor). 5) WP-Cron’un gecikmesi (cron işlerinin aynı anda yük bindirmesi).
Hosting modeli seçimi: Paylaşımlı hosting vs VPS/VDS
Aşağıdaki tablo, Multisite için pratik seçim çerçevesi sunar. Burada “ideal” değil, “risk/uygunluk” perspektifini kullanıyoruz.
| Senaryo | Önerilen model | Neden | Kırılma noktası |
|---|---|---|---|
| 1-5 alt site, düşük trafik, basit eklentiler | Paylaşımlı (kontrollü plan) | Yönetim kolaylığı | CPU sınırı ve disk I/O düşük kalır, cache ayarları kısıtlı olabilir |
| 6-20 alt site, orta trafik, WooCommerce/karma eklentiler yok | VPS | Kaynak sınırları daha net, kontrol artar | Veritabanı yükü artınca RAM/CPU yetmez |
| 20+ alt site, yüksek trafik veya yoğun medya | VDS | Yüksek kontrol: PHP worker, veritabanı parametreleri, cache | Yanlış spec ve yedekleme stratejisi maliyet/riski artırır |
| Çoklu admin kullanımı + sık güncelleme + özel güvenlik ihtiyaçları | VDS | İzolasyon ve ayar esnekliği | Yetersiz izleme (monitoring) erken tespit engeller |
Ne zaman VDS şart olur?
Multisite’de şu koşullarda VDS/VPS’e geçmek gerekir: - Alt site sayısı büyüdükçe veritabanı ve admin işlemleri artıyorsa. - Sayfa önbelleği ve nesne önbelleği (OPcache/Memcached/Redis) yönetimi gerektiriyorsa. - Paylaşımlı hostingte sabit RAM/CPU garantisi yoksa. - Yedekleme ve tutarlılık ihtiyacı (tüm ağ snapshot mantığı) kritik hale geldiyse.
Paylaşımlı hosting bazı durumlarda çalışır; ancak Multisite’da büyüme hızına göre “ilk yıl idare eder” yaklaşımı çoğu ekipte maliyeti yukarı iter. Çünkü geçiş sonrası veri taşımaları ve cache ayarları tekrar kurulabilir.
Gereksinimleri netleştirin: CPU, RAM, disk, veritabanı
Multisite için spec (özellik) verirken tek bir “şu kadar gerekir” yoktur. Doğru yaklaşım, veritabanı yükü + PHP üretim yükü + medya/dosya I/O toplamını hedeflemektir.
Aşağıdaki değerler, karar verme amaçlı pratik aralıklardır (ölçek büyüdükçe üst band). Kesin rakam yerine aralık kullanıyoruz; çünkü trafik modeli (ziyaretçi/ sayfa görüntüleme/ eş zamanlı istek) belirleyicidir.
Başlangıç senaryosu (6-15 alt site, orta trafik)
- CPU: 4 vCore
- RAM: 8-16 GB
- Disk: 150-300 GB SSD (medya büyümesini hesaba kat)
- Veritabanı: MySQL/MariaDB + uygun indexing
- Cache: sayfa cache + OPcache + (tercihen) Redis
- CDN: statik içerik ve görseller için önerilir
Büyüme senaryosu (15-40 alt site, yüksek trafik)
- CPU: 8-16 vCore
- RAM: 16-32 GB
- Disk: 300-800 GB SSD
- Veritabanı: daha sık izleme + yavaş sorgu analizi
- Cache: Redis + sayfa önbelleği + doğru invalidation
- İç ağ planı: admin istekleri ve cron işleri için zamanlama
Büyük senaryo (40+ alt site veya çok yoğun medya)
- CPU: 16+ vCore
- RAM: 32 GB+
- Disk: 800 GB+ (yedekleme alanı dahil planlanmalı)
- Dosya/medya: gerekirse harici storage veya ayrı disk tasarımı
- Yük dağıtımı: gerekirse reverse proxy ve daha gelişmiş cache
Cache ve performans: Multisite’te hangi katmanlar şart?
Multisite’te hız konusu sadece sayfa cache değil. En sık kullanılan ve etkisi yüksek katmanlar: - OPcache (PHP bytecode cache): PHP derleme maliyetini düşürür. - Object cache (Redis/Memcached): WordPress sorgularını ve geçici verileri hızlandırır. - Page cache (reverse proxy veya WordPress cache): Tam sayfa üretimini azaltır. - CDN: statik içerikleri (CSS/JS/görsel) merkezden uzaklaştırır.
Cache seçerken dikkat edilecek 4 teknik kontrol
1) Cache invalidation doğru mu? (Bir alt sitede içerik güncellenince sadece ilgili sayfalar güncelleniyor mu?) 2) Yönetici/oturum (logged-in) trafiği cache’i bozuyor mu? 3) Cron ve planlı işlemler aynı anda mı çalışıyor? (Toplu invalidation patlaması yaratır.) 4) Çoklu domain/subdomain yönetimi doğru mu? (Multisite mapping karışıklıkları cache anahtarlarını etkiler.)
Veritabanı stratejisi: Multisite maliyetinin ana kaynağı
Multisite’te veritabanı en hızlı büyüyen bileşendir. Bu yüzden hostingte sadece “kaç GB RAM” değil, veritabanı tarafında şu ayarlar önemlidir: - Max bağlantı (max_connections) ve sorgu zaman aşımı - İndeksleme (index) ve yavaş sorgu tespiti - Otomatik bakım (optimize/analyze, tablo istatistikleri)
Yavaş sorguları yakalamak için net yöntem
- WordPress’te eklenti bazlı sorgu yükü çıkarın (özellikle her sayfa yükünde yapılan sorgular).
- Veritabanı metriklerini düzenli izleyin: slow query log.
- Her alt siteyi ayrı ayrı ölçün: bazı siteler daha ağır eklenti setine sahip olur.
Bu adımlar yapılmadan sadece daha büyük server almak çoğu zaman “problemi maskeleme” olur.
Yedekleme (backup) ve geri dönüş: Multisite’te tek tuşla olmaz
Multisite ağında yedekleme, tek site yedeğine göre daha önemlidir. Çünkü bir alt siteyi geri almak yetmeyebilir; ağ tutarlılığı korunmalıdır.
Minimum yedekleme standardı
- Dosya sistemi yedeği:
wp-content(tema, eklentiler, upload), varsa özel eklenti klasörleri - Veritabanı yedeği: tüm ağın tabloları
- Ağ düzeyi restore planı: “geri dönüş” test edilsin
Hosting sağlayıcıdan istenecek net özellikler
- Yedeklerin ne sıklıkta alındığı (ör. saatlik/günlük)
- Yedeklerin kaç gün saklandığı
- Yedeklerin harici depoya alınıp alınmadığı (aynı sunucuda kalmamalı)
- Restore süresi (pratikte kaç dakikada/kaç saatte)
Aşağıdaki tablo, bir sağlayıcıyı eleyip seçmek için kullanabileceğiniz ölçütleri özetler:
| Kontrol sorusu | Beklenen cevap |
|---|---|
| Yedekler otomatik mi? | Evet, ağ bazında |
| Saklama süresi kaç gün? | Minimum 7 gün (tercihen daha uzun) |
| Yedekler şifreli mi? | Evet |
| Restore test imkanı var mı? | En azından dokümantasyon/teknik destek |
| Yedekler harici lokasyonda mı? | Evet (aynı disk arızasında kurtarma garantisi artar) |
Güvenlik ve izolasyon: Multisite’te tek zayıflık tüm ağı etkiler
Multisite’da eklenti yönetimi merkezi olduğundan güvenlik zafiyetleri daha geniş alana yayılabilir. Bu nedenle hosting seçiminde şu başlıklar net olmalı: - Güncellenebilir OS ve çekirdek (kernel güncellemeleri) - Firewall (ör. UFW/iptables yönetimi) - Fail2ban veya benzeri koruma - SSH erişiminde anahtar tabanlı giriş - Yönetim paneli erişimi için kısıtlar (IP allowlist)
Eklenti kaynaklı riskleri azaltma
- Gereksiz eklentileri kaldırın.
- En çok kullanılan eklentilerin update durumunu izleyin.
- Her alt siteye aynı eklentileri körlemesine dağıtmayın; ihtiyaca göre site bazlı etkinleştirme yapın.
Ölçeklenebilirlik: Trafik artınca hangi değişiklikler gerekir?
Multisite’te ölçek büyüdüğünde genelde şu sırayla iyileştirmeler yapılır: 1) Cache katmanları güçlendirilir (redis + page cache). 2) Veritabanı optimize edilir (yavaş sorgular, indeksler). 3) PHP-FPM worker/limit ayarları düzenlenir. 4) Sunucu spec yükseltilir (RAM/CPU). 5) Gerekirse CDN ve yük dağıtım altyapısı eklenir.
Hosting sağlayıcıyı seçerken şu “operasyonel” sorulara net cevap bulun: - Sağlayıcı RAM/CPU ölçeklemesini (resize) nasıl yapıyor? - Disk genişletme pratik mi? - Taşıma (migration) için destek sağlıyor mu?
Çoklu WordPress için Net öneri: “adım adım karar” planı
Aşağıdaki karar akışı, doğru hosting modelini daha hızlı seçmenizi sağlar:
1) Alt site sayısı ve rolü
- 1-5: paylaşımlı plan ile başlanabilir; fakat cache ve yedek sınırlamalarını kontrol edin.
- 6-20: VPS/VDS’ye geçiş daha rasyonel olur.
- 20+: VDS önceliklidir.
2) Trafik ve sayfa türleri
- Sadece kurumsal sayfalar: cache ile daha az kaynak yeter.
- WooCommerce/çok dinamik içerik: daha fazla PHP/DB kapasitesi gerekir.
3) Cache stratejisi kurulabiliyor mu?
- Redis ve OPcache ayarlanabiliyorsa VDS/VPS avantaj sağlar.
- Sağlayıcı “cache ayarı”na izin vermiyorsa, Multisite performansı tıkanabilir.
4) Yedekleme ve restore planı var mı?
- Restore test etme imkanı olmayan sistemde büyüme risklidir.
Sonuç: İlk kurulumu doğru yapın, büyürken masrafı kontrol edin
Çoklu WordPress (multisite) için hosting seçimi, yalnızca “kaç site var” sorusuyla bitmez; veritabanı büyümesi, cache katmanlarının kurulabilirliği ve yedekleme/restore disiplinine göre belirlenir. İlk adım olarak alt site sayınızı, ortalama aylık sayfa görüntüleme hedefinizi ve eklenti/tema yükünüzü netleştirin. Sonra VDS/VPS tarafında Redis + OPcache + sayfa cache kurulumuna izin veren, yedekleri ağ bazında saklayan ve restore süresi hakkında somut bilgi sunan bir yapı seçin. Bu planı uygularsanız hem performans darboğazlarına daha erken yakalanır hem de gereksiz geçiş maliyeti yaşamazsınız.
Hosting karşılaştırması yapmaya hazır mısın?
100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.
Hosting Karşılaştır →İlgili Yazılar
Bulut sunucuda saatlik fiyat: Gerçek maliyeti nasıl hesaplanır
Saatlik fiyat sadece başlangıçtır. Bulut sunucuda CPU/RAM, depolama, egress ve yedekleme maliyetlerini adım adım hesaplayın.
WordPress’te HTTP/2 ve HTTP/3 desteği nasıl açılır?
WordPress’te HTTP/2 ve HTTP/3’ü adım adım etkinleştirin. Nginx/Apache ayarları, Cloudflare kullanımı ve test yöntemleriyle net kontrol rehberi.
Core Web Vitals ve hosting: LCP, CLS, INP’yi hızlandırma
LCP, CLS ve INP’nin hosting ile nasıl etkilendiğini öğrenin. Ölçüm araçlarını, sunucu ayarlarını ve somut kontrol listesini görün.
Node.js VDS Yapılandırması: Performans, güvenlik ve yedekleme
Node.js uygulaması için VDS kurulumunda Nginx, PM2, TLS, cache, log ve yedekleme planını net bir yapı ile öğrenin.
