Çoklu WordPress (Multisite) için hosting seçimi: net rehber

Çoklu WordPress siteleri tek bir kurulum altında çalıştığında (WordPress Multisite), tek siteye göre ihtiyaç profili değişir: aynı anda daha fazla trafik, daha büyük veritabanı yükü, daha sık içerik üretimi ve daha dikkatli yedekleme gerekir. Bu rehberde Multisite için doğru hosting modelini seçmeyi; VPS/VDS, depolama (NVMe/SATA), cache, CDN, PHP-FPM ayarları, yedek (backup) ve ölçek planını net kontrol listeleriyle anlatacağız. Böylece “aynı parayla daha iyi performans” ve “beklenmedik çökme yaşamadan yönetim” hedefini somut adımlara dönüştüreceksiniz.

Multisite’in hostingte yarattığı gerçek yük

WordPress Multisite’te tek WordPress kodu ve tek veritabanı mantığı vardır; ancak site sayısı arttıkça istek hacmi ve veritabanı/önbellek davranışı da büyür.

Performans nerede zorlanır?

• PHP iş yükü: Her site için front-end ve admin istekleri ayrı akışlar doğurur. WP-Cron, toplu güncellemeler ve eklenti görevleri çoğalır.
• Veritabanı (MySQL/MariaDB): Yeni içerik, revizyonlar, kullanıcı/role tabloları, indexler ve multisite tabloları büyüdükçe sorgular ağırlaşır.
• Disk I/O: Loglama, otomatik güncellemeler, tema/eklenti dosyaları ve cache yazma işlemleri disk performansını etkiler.
• Cache alanı: Object cache (APCu/Redis) yoksa her istek aynı hesaplamaları tekrarlar; gecikme artar.

Multisite için “tek site gibi” düşünmek neden yanlıştır?

Paylaşımlı hostingde kaynak paylaşımı (CPU/RAM) çok daha hızlı “tam dolu” hale gelir. Özellikle bir eklenti (ör. görsel optimizasyonu, istatistik, forms, SEO) tüm ağda çalışıyorsa, tek site senaryosundan daha fazla yük üretir.

Hosting modeli karşılaştırması: Shared mi VPS/VDS mi?

Multisite’de karar çoğunlukla kaynak garantisi ve yönetilebilirlik etrafında şekillenir. Aşağıdaki tablo, NetKıyas yaklaşımına uygun biçimde seçim kriterlerini netleştirir.

Net ölçüt: minimum başlangıç kaynakları

Kesin tek bir değer yok; ancak “Multisite’i sorunsuz çalıştırma” hedefinde başlangıç bandı genellikle şöyledir: - RAM: En az 4 GB (10+ site için 8 GB bandı daha güvenlidir) - CPU: En az 2 vCPU (eklenti yoğunluğu varsa 4 vCPU) - Storage: NVMe SSD (en az) — çünkü cache ve log yazımı gecikmeyi etkiler - MySQL/MariaDB: Disk ve RAM ile birlikte düşünün; “küçük disk + çok sorgu” hızlı tıkanma yaratır

Depolama ve ağ gecikmesi: Multisite’te fark yaratanlar

NVMe SSD vs SATA SSD: Multisite’te nerede hissedilir?

NVMe SSD genelde şu alanlarda avantaj sağlar: - Cache write (sayfa önbelleği, OPcache/Redis dışındaki dosya cache) - Büyük dosya okuma/arama (loglar, tema/eklenti dosyaları) - MySQL temp dosyaları (özellikle sıralama/join içeren sorgularda)

Net karar: Multisite’de site sayısı ve eklenti sayısı büyüdükçe “disk gecikmesi” daha belirgin hale gelir. Bu yüzden NVMe SSD tercihi, özellikle VDS/VPS seçiminde öncelik listesinde ilk sıralarda olmalı.

Türkiye’den erişim için veri merkezine dair net beklenti

Sunucunun Türkiye’ye uzaklığı sadece hız testinde değil; TTFB (ilk yanıt süresi) ve paket kaybı üzerinden yönetim ekranlarını da etkiler. Admin paneli sık kullanılıyorsa (yazarlar, editörler, içerik yayıncılığı), gecikme farkı daha çok hissedilir.

Net öneri: İstanbul/Ankara kullanıcı kitlesi ağırlıksa Türkiye içi veya yakın erişim sağlayan lokasyon + CDN ile hibrit kurulum hedefleyin.

Cache katmanları: Multisite için gerçek “performans anahtarı”

Multisite’te cache sadece sayfa önbelleği değildir. Katman katman düşünün.

1) Sayfa cache (Page Cache)

• Eklenti tabanlı (ör. LiteSpeed Cache benzeri) veya sunucu tabanlı seçenekler
• Multisite’te yanlış cache kuralı, yönetim sayfalarını bozabilir. Kural testini şart koşun.

2) Object cache (APCu/Redis)

Object cache, her istekte tekrar çalışan PHP hesaplamalarını azaltır. - Tek sunucuda APCu bazı kurulumlarda yeterli olabilir - Çoklu site ve daha yüksek trafik seviyelerinde Redis genellikle daha stabil sonuç verir

Net karar: Multisite’te eklenti sayısı arttıkça Redis yönünde ilerlemek daha doğru olur. Çünkü object cache’in büyümesi ve daha tutarlı performans ihtiyacı doğar.

3) OPcache

PHP OPcache, PHP bytecode tekrarını azaltır. Hosting panelinde “OPcache açık mı, ayarları var mı?” sorusu net bir kriterdir.

Yedekleme (backup) planı: Multisite’te “yanlış yedek” riski

Tek tek site yerine ağ düzeyinde yedek almalısınız. Çünkü: - Multisite tablolarında site kayıtları birlikte saklanır - Güncelleme/eklenti değişikliği tüm ağı etkileyebilir

Net 3-2-1 kuralı nasıl uygulanır?

• 3 kopya: en az 3 ayrı veri kopyası
• 2 farklı ortam: ör. sunucu + harici bulut
• 1 kopya: ofline/erişimi kesik (ransomware riskine karşı)

Yedek kapsamı kontrol listesi

• Veritabanı yedeği (MySQL dump veya native snapshot)
• WordPress dosyaları (wp-content, muhtemel custom muameleler)
• Ayar dosyaları (multisite için wp-config dahil)
• Otomatik doğrulama: Yedeğin gerçekten geri yüklenebilir olması

Dosyaları şifreleme (en net pratik)

• Yedek dosyalarını buluta atsanız bile taşınmadan önce şifreleme yapın
• Anahtar yönetimini kural altına alın (anahtar sunucuda açık düz metin olmamalı)

Güvenlik: Multisite’te saldırı yüzeyi nasıl büyür?

Multisite, tek WordPress’e göre daha fazla giriş noktası ve daha karmaşık yetkilendirme içerir. Bu yüzden güvenliği sistematik kurun.

Minimum güvenlik bileşenleri

• WAF / Rate limiting: Bruteforce ve aşırı istek saldırılarını sınırlayın
• Erişim kısıtı: wp-login ve wp-admin için ek doğrulama (ör. IP kısıtı veya ek katman)
• Dosya izinleri (file permissions): Yanlış izinler hem güvenlik hem performans riskidir
• XML-RPC kapatma veya sınırlama: Saldırıların hedef aldığı alanlardan biridir
• Kullanıcı rol yönetimi: Network Admin yetkilerini sınırlayın

Ölçek planı: Site sayısı artınca ne zaman değişiklik yapmalısınız?

“Ne zaman VPS’ten VDS’ye geçilir?” sorusunun net cevabı performans göstergeleridir.

Geçişi gerektiren net sinyaller

• PHP-FPM worker’ları doluyor, “queue” artıyor
• MySQL’de yavaş sorgular çoğalıyor, index çalışmıyor
• Cache oranı düşüyor (CDN + sayfa cache efektif değil)
• Sunucu CPU kullanımı sürekli yüksek ve artış dalgalı yükle baş edemiyor

Basit bir karar akışı

• Önce cache ve object cache’i güçlendirin
• Redis ve page cache’i doğru kurun, OPcache ayarını netleştirin
• Sorgu/indeks sorunlarını giderin
• Disk I/O yetersizse NVMe kapasitesini artırın
• Hâlâ sınır aşılıyorsa VDS’e geçin

Satın alma öncesi “soracağınız” net sorular

NetKıyas’ta karşılaştırma yaparken şu maddeler hedeflenmeli: - Sunucu sanallaştırma tipi: Kaynak izolasyonu ne kadar gerçek? - CPU/RAM limitleri: Burst var mı, yok mu? - Storage tipi: NVMe SSD mi, SATA SSD mi? - Network: Türkiye’den giden paket kaybı ve bant genişliği sınırı var mı? - Kontrol paneli: Hangi panel var? (Hestia/DirectAdmin/cPanel benzeri) Yönetim erişimi pratik mi? - PHP sürümü ve modüller: OPcache/Redis desteği var mı? - Yedek: Otomatik mi, manuel mi? Geri dönüş süresi (restore) biliniyor mu? - Dizin/izin yönetimi: wp-config ve wp-content üzerinde standart süreçle değişiklik yapılabiliyor mu?

Örnek net başlangıç konfigürasyonu (genel şablon)

• VDS/VPS: 4 vCPU / 8 GB RAM bandı (10+ siteye hazırlık için)
• Storage: NVMe SSD
• Cache: Redis (object cache) + sayfa cache
• Cron: WP-Cron kontrolü (sunucu cron ile tetik)
• CDN: Türkiye odaklı performans için
• Yedek: Ağ düzeyinde otomatik + şifreli dış kopya

Sonuç: Multisite’te doğru hosting kararı nasıl verilir?

Multisite için en kritik nokta, tek site mantığıyla hareket etmemektir. İlk adımda VDS/VPS tarafında kaynak izolasyonu, NVMe SSD, Redis gibi object cache ve ağ düzeyinde şifreli yedekleme kurun. Ardından performansı cache oranı, PHP-FPM yoğunluğu ve MySQL sorgu davranışlarıyla ölçün; bu sinyaller “sabit kapasite” ihtiyacını gösterdiğinde VDS ölçeğine geçin. Bugün seçim yapacaksanız, kontrol panelinizin Redis/OPcache desteği, otomatik yedek ve restore kolaylığı gibi maddeleri yazılı hale getirin ve karşılaştırmayı bu ölçütlerle tamamlayın.