WordPress Multisite için VPS Hosting: Domain Mapping, SSL ve Performans Ayarları

WordPress Multisite için VPS Hosting Neden Kritik?

Bir ajans, içerik ağı ya da çok markalı bir yapıyı yönetiyorsanız, onlarca ayrı WordPress kurulumunu tek tek güncellemek, yedeklemek ve güvenliğini sağlamak bir noktadan sonra sürdürülemez hale geliyor. Tam bu noktada WordPress Multisite ve doğru kurgulanmış bir VPS hosting altyapısı devreye giriyor.

Multisite, tek bir WordPress çekirdeği üzerinden onlarca hatta yüzlerce siteyi yönetmenizi sağlıyor. Eklentileri, temaları, çekirdek güncellemelerini merkezi olarak yönetiyor; kullanıcıları ağ düzeyinde atayabiliyor ve bakım süreçlerini ciddi şekilde sadeleştiriyorsunuz. Ancak bu mimariyi paylaşımlı hosting üzerinde zorlamaya başladığınızda, CPU sınırları, bellek limitleri, I/O sorunları ve güvenlik kısıtları çok hızlı karşınıza çıkıyor.

İyi tasarlanmış bir VPS üzerinde WordPress Multisite kurduğunuzda ise kaynakları kendiniz kontrol eder, PHP-FPM, veritabanı ve önbellek katmanlarını ince ayarlarla optimize eder ve her site için domain mapping, otomatik SSL ve yüksek performans sağlayabilirsiniz. Bu yazıda, DCHost ekibi olarak sahada gördüğümüz iyi/kötü örneklerden süzülmüş bir rehberle, Multisite’i VPS üzerinde nasıl doğru kuracağınızı; domain mapping, SSL ve performans ayarlarını adım adım nasıl planlamanız gerektiğini anlatıyoruz.

Multisite Mimarisi için Doğru VPS Seçimi

Başarılı bir WordPress Multisite projesi, daha ilk adımda yani VPS seçimi aşamasında kazanılıyor ya da kaybediliyor. Yanlış seçilmiş CPU/RAM kombinasyonu, yetersiz disk IOPS ya da dar bant genişliği, büyüyen ağınızda kalıcı performans sorunlarına dönüşebiliyor.

CPU ve RAM Planlaması

Multisite’te tüm siteler tek bir uygulama havuzunu paylaştığı için, CPU ve RAM tüketimi “toplam yük” üzerinden değerlendirilmelidir. Genel bir başlangıç rehberi olarak:

• 2 vCPU + 4 GB RAM: Küçük ajanslar, 5–10 düşük trafikli site
• 4 vCPU + 8 GB RAM: 20–30 kurumsal içerik sitesi, hafif WooCommerce mağazaları
• 8 vCPU + 16 GB RAM ve üzeri: Çok kiracılı SaaS benzeri yapılar, yüksek trafikli yayın ağları

Özellikle yoğun eklenti kullanan sitelerde (sayfa oluşturucular, WooCommerce, membership eklentileri vb.) RAM kullanımınızı ciddiye alın. PHP-FPM havuz ayarlarınızla birleştiğinde, beklediğinizden daha fazla bellek tüketimi görebilirsiniz. Bu tarafı detaylı anlamak için WordPress için sunucu tarafı optimizasyon rehberimizi mutlaka gözden geçirmenizi öneririz.

Depolama: SSD/NVMe ve IOPS

Multisite ağında çok sayıda site, medya dosyası ve veritabanı sorgusu anlamına gelir. Bu da depolama katmanına ciddi yük bindirir. Bu yüzden:

• SSD veya NVMe depolama tercih edin; özellikle NVMe, yüksek IOPS sayesinde yoğun veritabanı trafiğinde ciddi fark yaratır.
• Disk kapasitesini hesaplarken sadece şu anki medya boyutunu değil, 1–2 yıllık büyümeyi de hesaba katın.
• Dosya sistemi seviyesinde düzenli yedek ve snapshot almayı unutmayın.

NVMe’nin performans tarafındaki gerçek etkilerini daha iyi anlamak için NVMe VPS hosting rehberimize göz atabilirsiniz.

Ağ ve Bant Genişliği

Özellikle çok dilli, çok bölgeli ya da medya ağırlıklı multisite projelerinde bant genişliği ve network kalitesi kritik hale gelir. VPS seçerken:

• Yeterli aylık trafik kotası olan bir plan tercih edin.
• Düşük gecikme süreleri ve kararlı bir omurga sağlayan veri merkezlerini seçin.
• Gerektiğinde CDN entegrasyonu ile statik içeriği kenara itebileceğiniz bir mimari planlayın.

VPS Üzerinde WordPress Multisite Kurulumunun Temelleri

Doğru VPS’i seçtiniz, sırada WordPress Multisite’i ayağa kaldırmak var. Burada varsayımımız, halihazırda çalışan tek siteli bir WordPress’iniz olduğu ve bunu Multisite’e dönüştüreceğiniz yönünde olacak.

Alt Alan Adı mı, Alt Dizin mi?

Kurulum sırasında WordPress sizden alt alan adı (subdomain) ya da alt dizin (subdirectory) tabanlı bir ağ seçmenizi ister.

• Alt alan adı: site1.ornek.com, blog.ornek.com
• Alt dizin: ornek.com/site1, ornek.com/blog

Uzun vadede her siteye ayrı domain bağlamak (domain mapping) istiyorsanız, çoğu senaryoda her ikisi de kullanılabilir. Ancak subdomain tabanlı kurulum, wildcard SSL ve bazı cache yapılandırmaları açısından daha esnek bir zemin sunar.

wp-config.php için Multisite Ayarları

Önce mevcut WordPress sitenizde aşağıdaki sabiti ekleyerek Multisite özelliğini aktif ediyorsunuz:

define( 'WP_ALLOW_MULTISITE', true );

Ardından yönetim panelinden Ağ Kurulumu ekranına gidip ağınızı oluşturduktan sonra, WordPress size aşağıdakine benzer ek satırlar verecektir:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'ornek.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Bu satırları wp-config.php dosyanıza eklediğinizde, Multisite ağınız temel olarak çalışır hale gelir.

Apache veya Nginx Sanal Host (VirtualHost) Örneği

VPS üzerinde genellikle Nginx veya Apache ile çalışacaksınız. Basit bir Nginx sunucu bloğu şöyle olabilir:

server {
    listen 80;
    server_name ornek.com *.ornek.com;

    root /var/www/ornek.com/public;

    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Burada dikkat edilmesi gereken nokta, server_name satırında hem ana domaini hem de *.ornek.com wildcard’ını tanımlamış olmamız. Bu, subdomain tabanlı Multisite için kritik bir detaydır.

Domain Mapping: Farklı Alan Adlarını Aynı Ağa Bağlamak

WordPress Multisite’in en güçlü yanlarından biri, tek bir ağ altında tamamen farklı alan adları kullanabilmenizdir. Örneğin:

• site1.com → site1.ornek.com’un üzerine “haritalanır”
• marka-portal.net → portal.ornek.com’u işaret eder

DNS Tarafı: A/AAAA, CNAME ve Wildcard Kayıtları

Önce DNS’i doğru kurgulamalısınız. Temel senaryo:

• ornek.com için VPS IP’sine bakan bir A (ve tercihen AAAA) kaydı
• *.ornek.com için de aynı IP’ye bakan wildcard A/AAAA kaydı
• Haritalayacağınız her domain (ör. site1.com) için yine VPS’nize bakan A/AAAA kayıtları

DNS kayıtları konusunda emin değilseniz, önce DNS kayıtları A’dan Z’ye rehberimize göz atmanızı öneririz. Domain mapping sırasında yapılan hataların büyük kısmı, yanlış ya da eksik A/AAAA/CNAME kayıtlarından kaynaklanıyor.

WordPress Tarafı: Site Ekleme ve Alan Adı Atama

Multisite ağ yönetiminde yeni bir site eklediğinizde WordPress sizden bir Site Adı (path veya subdomain) ister. Örneğin subdomain tabanlı ağda site1 girerseniz, WordPress bu siteyi site1.ornek.com olarak tanımlar.

Daha sonra Ağ Yönetimi > Siteler > site1 > Düzenle ekranına gelip Site Adresi (URL) alanını şu şekilde güncelleyebilirsiniz:

• http://site1.com yerine https://site1.com (SSL sonrası)

Yeni WordPress sürümlerinde ekstra bir domain mapping eklentisine ihtiyaç duymadan, çekirdeğin kendisi bu haritalamayı yönetebiliyor. Önemli olan, hem DNS hem de web sunucusu tarafının bu domaini tanıyor olması.

Web Sunucusu Tarafı: ServerName ve ServerAlias

Nginx örneğinden devam edelim. Varsayılan sunucu bloğunuza haritaladığınız domainleri de eklemeniz gerekir:

server {
    listen 80;
    server_name ornek.com *.ornek.com site1.com marka-portal.net;
    ...
}

Böylece Nginx’e “Bu domainlere gelen tüm istekleri bu vhost üzerinden karşıla” demiş olursunuz. SNI tabanlı SSL yapılandırmasıyla birleştiğinde, her domain için ayrı sertifika da kullanabilirsiniz (bir sonraki bölümde).

SSL Stratejisi: Multisite’te Sertifikaları Yönetmek

Domain mapping yaptığınız anda bir sonraki kritik soru gelir: “SSL’i nasıl yöneteceğim?” Tek bir domain ve birkaç subdomain ile sınırlı kalmayacaksanız, planı baştan doğru çizmek şart.

Tek Domain, Subdomain ve Wildcard SSL

Eğer ağınızdaki siteler büyük oranda subdomain kullanıyorsa (site1.ornek.com, portal.ornek.com vb.), en pratik çözüm çoğu zaman bir wildcard SSL sertifikası kullanmaktır:

• ornek.com için ayrı bir sertifika
• *.ornek.com için wildcard sertifika

Let’s Encrypt ile wildcard sertifika almak için DNS-01 challenge kullanmanız gerekir. Bu süreci otomatikleştirmek için hazırlanmış rehberimizi adım adım takip edebilirsiniz: Let’s Encrypt wildcard SSL otomasyonu.

Her Site İçin Ayrı Domain: SAN mı, Tek Tek Sertifika mı?

Eğer her siteyi tamamen farklı domainlerle yayınlıyorsanız (site1.com, marka-portal.net vb.), iki temel yaklaşımınız var:

• SAN (Subject Alternative Name) sertifikalar: Bir sertifika içinde birden fazla domain barındırabilirsiniz.
• Her domain için ayrı bir DV sertifika almak: SNI desteği sayesinde Nginx/Apache aynı IP üzerinden birden fazla sertifikayı sorunsuz sunabilir.

Let’s Encrypt oran limitlerine takılmadan çok alan adına sertifika yönetmek için, çok alan adında SSL ve SAN/wildcard stratejileri yazımızı incelemenizde fayda var.

HTTP-01 vs DNS-01: Hangi ACME Challenge Ne Zaman?

Multisite ağlarında özellikle domain mapping senaryolarında, SSL otomasyonunda hangi challenge türünü kullanacağınız önemli hale gelir:

• HTTP-01: Domaininizin 80. portuna gelen istekle doğrulama yapar. Basit ama bazen proxy/CDN arkasında zor olabilir.
• DNS-01: DNS üzerinde TXT kaydı oluşturarak doğrulama yapar. Wildcard sertifikalar için zorunludur ve çok kiracılı ortamlarda genelde daha esnektir.

Bu challenge türlerinin artı/eksi yönlerini detaylı anlattığımız ACME challenge türleri rehberimize göz atmanız, uzun vadeli bir SSL stratejisi kurarken çok işinize yarar.

Nginx’te SNI Tabanlı Çoklu Domain SSL Örneği

Farklı domainler için farklı sertifikalar kullandığınız bir senaryoda, Nginx’te yapı şu şekilde olabilir:

server {
    listen 443 ssl http2;
    server_name ornek.com;

    ssl_certificate /etc/letsencrypt/live/ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ornek.com/privkey.pem;
    ...
}

server {
    listen 443 ssl http2;
    server_name site1.com;

    ssl_certificate /etc/letsencrypt/live/site1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.com/privkey.pem;
    ...
}

Her iki sunucu bloğu da aynı WordPress kurulum dizinine işaret edebilir. WordPress hangi domainin hangi siteye ait olduğunu kendi içinde halleder; Nginx ise sadece doğru sertifikayı sunmakla yükümlüdür.

Performans Ayarları: Multisite Ağı Nasıl Hafif Tutulur?

Multisite mimarisi, tek çekirdek üzerinde çok sayıda siteyi barındırdığı için performans sorunları da zincirleme etki yaratır. Bir eklentinin yaptığı ağır sorgu, aslında tüm ağınızı yavaşlatabilir. Bu yüzden VPS tarafındaki ayarları ciddiyetle yapmak gerekir.

PHP-FPM ve OPcache Ayarları

PHP-FPM havuz ayarlarınızı Multisite yüküne göre yapılandırmalısınız. Örneğin 4 vCPU ve 8 GB RAM’li bir VPS’te:

• pm = dynamic kullanarak minimum, maksimum ve idledaki child süreç sayılarını belirleyin.
• pm.max_children değerini RAM ve her PHP sürecinin ortalama tüketimine göre hesaplayın.
• OPcache için yeterli bellek (opcache.memory_consumption) ve script cache limiti (opcache.max_accelerated_files) tanımlayın.

PHP 8.x’e geçiş ve OPcache optimizasyonu konusunda detaylı bir yol haritasına ihtiyacınız varsa, PHP 8.x yükseltme kontrol listemiz iyi bir başlangıç noktasıdır.

Nesne Önbelleği: Redis veya Memcached

Multisite ağlarında en çok fark yaratan katmanlardan biri kalıcı nesne önbelleğidir. Özellikle kullanıcı oturumu, sorgu sonuçları ve ayarlar gibi sık kullanılan verilerin Redis/Memcached üzerinde tutulması, CPU ve veritabanı yükünü ciddi oranda düşürür.

• Redis için ayrı bir sistem servisi kurup, WordPress’i global prefix ve her site için farklı blog_id ile kullanacak şekilde yapılandırın.
• wp-config.php içinde cache key’lerini etkileyecek sabitleri (ör. WP_CACHE_KEY_SALT) dikkatli yönetin.

Hangi önbellek motorunu seçeceğiniz konusunda kararsızsanız, WordPress ve WooCommerce için Redis mi Memcached mi? yazımızda bu konuyu derinlemesine ele aldık.

Tam Sayfa Önbellekleme ve Mikro Önbellek

Statik sayfalar, blog yazıları ve yoğun okunma alanlarında tam sayfa önbellek kullanmak Multisite performansını uçurur. Nginx FastCGI cache, HTTP reverse proxy’ler ya da uygulama içi cache eklentileriyle:

• Anonim kullanıcılar için HTML çıktısını dakikalarca, hatta saatlerce saklayabilir,
• Giriş yapmış kullanıcılar, sepeti olan ziyaretçiler gibi dinamik oturumları cache dışı bırakabilirsiniz.

Özellikle Nginx mikro önbellekleme, yoğun anlık trafikte (kampanya, sosyal medya patlaması vb.) WordPress/PHP katmanını korumanın en efektif yollarından biridir. Bu konuyu detaylı anlattığımız Nginx mikro önbellekleme rehberimize mutlaka göz atın.

Veritabanı Optimizasyonu

Multisite ağında tüm siteler aynı veritabanını paylaşsa da, her sitenin tabloları ayrı prefix ile oluşturulur (wp_2_posts, wp_3_options gibi). Bu nedenle:

• Gereksiz eklentilerden kaçının; her eklenti birçok tablo ve sorgu ekleyebilir.
• Düzenli olarak slow query log incelemesi yapın.
• wp_options tablolarını şişiren autoload edilen kayıtları tespit edip temizleyin.

Daha ileri seviyede, çok büyük ağlarda veritabanını okuma/yazma ayrımı ve query cache katmanları ile ölçeklemek de mümkün; bunun için ProxySQL ile MySQL read/write split rehberimiz size fikir verebilir.

wp-cron Yerine Gerçek Cron Kullanımı

Varsayılan WordPress cron mekanizması (wp-cron.php), her sayfa isteğinde tetiklenen bir pseudo-cron’dur ve Multisite’te ciddi performans sorunlarına yol açabilir. Çözüm:

1. wp-config.php içinde DISABLE_WP_CRON sabitiyle wp-cron’u devre dışı bırakmak,
2. VPS üzerinde gerçek bir cron job tanımlayarak wp-cron.php’yi belirli aralıklarla tetiklemek.

Bu geçişi adım adım, ekran görüntüleri ve komut örnekleriyle anlattığımız WordPress’te wp-cron devre dışı bırakma ve gerçek cron job kurulumu yazımız, Multisite ağınız için de birebir uygulanabilir.

Güvenlik ve İzleme: Tek Sorunla Tüm Ağı Riske Atmamak

Multisite’in bir avantajı tek çekirdek olmasıysa, güvenlik tarafında en büyük riski de yine budur: Bir zafiyet, tüm ağı etkileyebilir. Bu nedenle VPS seviyesinden WordPress katmanına kadar güvenliği katmanlı düşünmek şart.

VPS Seviyesinde Güvenlik

• SSH güvenliği: Parola ile girişleri kapatın, anahtar tabanlı kimlik doğrulama kullanın, mümkünse FIDO2 anahtarları ve SSH CA gibi gelişmiş yöntemlere bakın.
• Güvenlik duvarı: Yalnızca gerekli portları açın (80/443/22 gibi). Gereksiz servisleri kapatın.
• Güncellemeler: İşletim sistemi ve paket güncellemelerini düzenli takip edin.

Bu konuda pratik ve uygulanabilir bir yol haritası için VPS sunucu güvenliği rehberimizi mutlaka okumanızı öneririz.

WordPress Katmanında Sertleştirme

Multisite ağınızda kullanmadığınız dosya düzenleme özelliklerini kapatmak, doğru dosya izinleri atamak, XML-RPC’yi kısıtlamak veya devre dışı bırakmak, giriş sayfasını korumak gibi klasik ama etkili önlemler hâlâ çok işe yarar.

Biz DCHost’ta, yeni Multisite kurulumlarında genellikle şu adımları öneriyoruz:

• wp-config.php içinde DISALLOW_FILE_EDIT ile tema/eklenti düzenlemeyi kapatmak,
• wp-content/uploads izinlerini doğru şekilde sınırlamak,
• Nginx/Apache üzerinden wp-login.php ve xmlrpc.php için rate limiting uygulamak.

Tüm bu başlıkları bir kontrol listesi halinde toparladığımız WordPress güvenlik sertleştirme rehberi, Multisite için de birebir geçerlidir.

Loglama ve İzleme

Multisite’te bir site yavaşladığında, sebep bazen sadece o sitenin eklentisi değil, tüm ağın CPU veya I/O yüküdür. Bunu fark etmenin tek yolu, doğru loglama ve izlemedir:

• VPS seviyesinde CPU, RAM, disk ve network metriklerini takip edin.
• PHP-FPM ve Nginx/Apache loglarını merkezi bir yerde toplayın.
• WordPress hata loglarını açık tutun ve düzenli inceleyin.

Daha ileri seviyede Prometheus + Grafana gibi çözümlerle metrik izleme kurmak, büyüyen Multisite ağları için büyük konfor sağlar; bunun temellerini VPS izleme ve alarm kurulumu rehberimizde anlattık.

DCHost Üzerinde Örnek Bir Multisite Senaryosu

Sahadan çok gördüğümüz bir senaryo üzerinden gidelim: 10–15 kurumsal sitesi olan, her yıl portföyüne 5–10 yeni site ekleyen bir dijital ajans düşünün. Başta her müşteriye ayrı paylaşımlı hosting hesabı açıyor; birkaç yıl sonra:

• Onlarca farklı panel,
• Farklı PHP sürümleri,
• Takibi zor güncellemeler,
• Dağınık yedekler

yüzünden operasyon yönetilemez hale geliyor.

Bu ajansla birlikte DCHost üzerinde aşağıdaki mimariyi kurduğumuzda iş ciddi anlamda sadeleşti:

• 4 vCPU, 8 GB RAM, NVMe diskli bir VPS üzerinde tek bir WordPress Multisite,
• Tüm müşteri siteleri bu ağın altında, her biri kendi domainiyle domain mapping yapılarak yayında,
• Let’s Encrypt tabanlı otomatik SSL yenileme; wildcard + tekil sertifika karması,
• Redis kalıcı nesne önbelleği ve Nginx FastCGI cache ile ciddi performans artışı,
• Gerçek cron job’lar ve merkezi yedekleme politikası.

Sonuç olarak ajans, onlarca siteyi tek panelden yönetebilir hale geldi; yeni müşteri eklemek bir “site oluştur” sihirbazına dönüştü. VPS kaynakları yetmediğinde ise bir üst plana geçmek, tek seferde tüm ağı ölçeklemek anlamına geldi.

Sonuç: Multisite + VPS Kombinasyonunu Sağlam Bir Yol Haritasına Oturtmak

WordPress Multisite, doğru kullanıldığında ajanslar, içerik ağları ve çok markalı yapılarda inanılmaz bir kaldıraç etkisi yaratıyor. Ancak bu gücü gerçekten hissetmek için, altyapıyı da aynı ciddiyetle tasarlamak şart: Doğru VPS kaynakları, tutarlı bir domain mapping ve SSL stratejisi, iyi ayarlanmış PHP-FPM/OPcache ve önbellek katmanı ile desteklenmeyen Multisite kurulumları, kısa sürede yönetilmesi zor bir yük haline geliyor.

Biz DCHost ekibi olarak, müşterilerimizin Multisite projelerinde önce mimariyi beraber tartışmayı, sonra uygun VPS planını ve güvenlik/performans ayarlarını beraber şekillendirmeyi tercih ediyoruz. Mevcut sitelerinizi tek tek taşımak, domain mapping kurgusunu planlamak, SSL otomasyonunu doğru challenge türleriyle yapılandırmak ve yedek/izleme stratejilerini oturtmak için bu yazıdaki adımları bir kontrol listesi gibi kullanabilirsiniz.

Eğer elinizde dağınık bir WordPress site yığını varsa ve “Bunu tek elde, güvenli ve hızlı bir VPS üzerinde nasıl toplarım?” diye düşünüyorsanız, bir Multisite denemek için tam zamanı. DCHost VPS paketlerine göz atabilir, aklınızdaki senaryoyu bizimle paylaşarak birlikte en uygun Multisite mimarisini kurgulayabilirsiniz.