WordPress Multisite VPS: Domain Mapping, SSL ve Performans

WordPress Multisite için VPS Ne Zaman Uygundur?

WordPress Multisite, ilişkili sitelerin tek kurulum, ortak yazılım sürümleri ve merkezi yönetim altında çalışmasını sağlar. Ajans, içerik ağı veya çok markalı bir yapı için bakım yükünü azaltabilir; ancak her sitenin aynı güncelleme ve güven modelini kabul etmesi gerekir. Birbirine güvenmeyen kiracıları yalnızca farklı alan adları ve veritabanı tablolarıyla güvenli biçimde ayırdığınızı varsaymayın.

Ağda çekirdek, eklentiler, temalar ve kullanıcı hesapları paylaşılır; sitelerin içerik tabloları, ayarları ve yükleme konumları ayrıdır. Kullanıcıların site rolleri farklı olabilir; site yöneticiliği ağ yöneticiliği vermez. Paylaşımlı hosting gerekli kontrolleri ve ölçülen kapasiteyi sağlıyorsa uygun olabilir. VPS gereksinimi site sayısından değil, kaynak, yönetim yetkisi ve izolasyon ihtiyacından doğar.

Bu rehber VPS seçimi, ağ kurulumu, domain mapping, HTTPS ve performans ayarlarını birlikte ele alır. DNS, sertifika ve uygulama yönlendirmesinin doğrulanması; kişisel yanıtların ortak önbellekten çıkarılması; her sitenin zamanlanmış işleri ve geri yükleme süreci de kurulumun parçasıdır. Örnekler kapasite veya kesintisizlik garantisi değildir; sağlayıcının yönetim kapsamını ayrıca doğrulayın.

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

VPS seçimi, WordPress Multisite projesinin kapasitesini ve büyüme olanaklarını etkiler. Yanlış seçilmiş CPU/RAM kombinasyonu, yetersiz disk IOPS ya da dar bant genişliği, büyüyen ağınızda performans sorunlarına dönüşebilir.

CPU ve RAM Planlaması

CPU ve RAM ihtiyacını sitelerin toplam istek yükü, eşzamanlı PHP işlemleri, veritabanı sorguları ve arka plan işleri üzerinden ölçün. Şu kapasite sınıfları yalnızca karşılaştırılabilecek varsayımsal seçeneklerdir; belirli sayıda siteyi taşıyacakları sonucunu vermez:

• 2 vCPU ve 4 GB RAM: küçük bir pilot iş yükü için ölçüm yapılabilecek örnek bir sınıf.
• 4 vCPU ve 8 GB RAM: daha fazla eşzamanlı iş için değerlendirilebilecek başka bir sınıf; mağaza kapasitesi ayrıca test edilmelidir.
• 8 vCPU ve 16 GB RAM ve üzeri: daha büyük kaynak seçeneği; yavaş sorgu, yanlış önbellek veya dış hizmet sınırını kendiliğinden çözmez.

Ö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

Depolama ihtiyacı site sayısına ek olarak medya büyümesi, sorgular, loglar ve yedekleme trafiğine bağlıdır. Seçimde:

• SSD/NVMe etiketinden önce gerçek iş yükündeki gecikme, IOPS, aktarım ve plan sınırlarını karşılaştırın; NVMe tek başına sabit bir performans garantisi değildir.
• Mevcut medya ve veritabanına beklenen büyüme, geçici dosyalar ve çalışma payını ekleyin.
• Dosya sistemi snapshot’ının uygulama tutarlı veya bağımsız yedek olduğunu varsaymayın. Veritabanı ve dosyaları uyumlu biçimde yedekleyip bağımsız bir kopyadan geri yüklemeyi test edin.

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:

• Aylık trafik kotasının yanında port hızı, paylaşılan kapasite ve aşım ücretlerini kontrol edin.
• Hedef kullanıcı bölgelerinden gecikme ve uygulama yanıtlarını ölçün.
• CDN ile yeniden kullanılabilir genel içeriği dağıtmayı değerlendirin; önbellek kaçırmaları ve kişiselleştirilmiş istekler için origin kapasitesini koruyun.

VPS Üzerinde WordPress Multisite Kurulumunun Temelleri

Başlangıçta desteklenen PHP ve veritabanı sürümleriyle çalışan, geçerli HTTPS sertifikasına sahip tek siteli bir WordPress kurulumu olduğunu varsayıyoruz. Kurulum parolalarını HTTP üzerinden göndermeyin. Dönüşümden önce dosyaları, veritabanını ve yapılandırmayı yedekleyin; geri dönüşü doğrulayın, kalıcı bağlantıları test edin ve etkin eklentileri ağ kurulumu sırasında devre dışı bırakın. Yeniden etkinleştirmeden önce Multisite uyumluluklarını kontrol edin.

Alt Alan Adı mı, Alt Dizin mi?

Ağ Kurulumu, uygun koşullarda alt alan adı veya alt dizin yapısı sunar; mevcut kurulum seçimleri sınırlayabilir. Resmî rehbere göre URL’de yol bulunan kurulumlarda alt alan adı seçeneği kısıtlıdır; bir aydan eski mevcut kurulumlarda alt dizin seçeneği kalıcı bağlantılar nedeniyle sunulmayabilir. Kurulu sürümün ekranını ve güncel gereksinimlerini esas alın; seçenekleri zorlayarak açmadan önce URL etkisini ve geri dönüşü planlayın.

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

Her iki ağ türündeki alt siteler de ayrı alan adlarına eşlenebilir. Domain mapping üçüncü bir kurulum türü değildir. Alt alan adı yapısı, bağımsız alan adlarına wildcard sertifika kapsamı veya otomatik SEO/önbellek avantajı sağlamaz. Yapıyı marka, içerik, kullanıcı ve işletim ihtiyaçlarıyla seçin; uyumsuz sürümler veya bağımsız güven sınırları gerekiyorsa ayrı kurulumları değerlendirin.

wp-config.php için Multisite Ayarları

Aşağıdaki sabiti wp-config.php içinde “That’s all, stop editing!” satırının üstüne, bu işaret yoksa ilk require/include yüklemesinden önce eklemek Ağ Kurulumu menüsünü açar. Tek başına ağı etkinleştirmez:

define( 'WP_ALLOW_MULTISITE', true );

Araçlar > Ağ Kurulumu ekranından uygun ağ türünü seçip kurulumu başlatın. Ekran kurulumunuza özgü ek sabitler üretir. Aşağıdaki kesit, example.com kökünde alt alan adı ağı için yalnızca bir gösterimdir; kendi ekranınızın değerlerini kullanın:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Sabitleri eklemenin yanında sunucuya uygun yönlendirmeleri de hazırlayın. Apache’de ekranın verdiği .htaccess kurallarını uygun yapılandırmada uygulayın. Bağımsız Nginx’te WordPress sunucu yapılandırmasını oluşturup uygulamaz; yönetici ağ türüne ve kurulum geçmişine uygun kuralları ayrıca düzenler. Yeniden giriş yaptıktan sonra Ağ Yönetimi, site oluşturma, kalıcı bağlantı, medya ve eklenti işlevlerini doğrulayın.

Nginx Sanal Host (Sunucu Bloğu) Örneği

Aşağıdaki örnek, WordPress’in URL kökünde bulunduğu güncel alt alan adı ağı için HTTP uygulama yönlendirmesini gösterir; alt dizin ağına doğrudan uygulanmaz. example.com ve yollar yer tutucudur. Gerçek PHP-FPM soketini, paketinizin fastcgi_params dosyasını ve dosya izinlerini doğrulayın. Bu blok tek başına TLS, bilinmeyen host politikası veya tüm sertleştirmeyi içermez; yönetim erişimini açmadan önce HTTPS ve erişim kontrolleri hazırlanmalıdır:

server {
    listen 80;
    server_name example.com *.example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    location ^~ /.well-known/acme-challenge/ {
        default_type text/plain;
        try_files $uri =404;
    }

    location ~ /\. {
        deny all;
    }

    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }

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

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/wordpress-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Wildcard server_name, DNS kaydı veya sertifika oluşturmaz; yalnızca eşleşen hostları bu uygulamaya yönlendirir. Alt dizin ağının ek yeniden yazma kurallarını resmî WordPress Nginx rehberinden kurulum türünüze göre uyarlayın. Upload-PHP engeli genel PHP eşleşmesinden önce olmalıdır; özel yükleme yolları varsa kapsamı genişletin. ACME istisnasını yalnızca doğrulama dosyaları için kullanın. Bilinmeyen hostları ayrı varsayılan politikayla reddedin. Tam yapılandırmada nginx -t kontrolünün ardından test ortamında medya, yönetim, kalıcı bağlantılar ve engellenmesi gereken yolları doğrulayın; sözdizimi kontrolü uygulamanın çalıştığını kanıtlamaz.

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.example.net, site1.example.com olarak oluşturulmuş alt siteye eşlenebilir.
• brand.example.org, portal.example.com alt sitesinin ayrı alan adı olabilir.

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

Önce her alan adı için sahiplik veya yönetim yetkisini ve ağdaki doğru siteye atandığını doğrulayın. DNS’in sunucuya çözülmesi tek başına alan adı ekleme yetkisi sayılmaz. Temel kayıt planı:

• example.com için gerçek IPv4 adresine A kaydı; AAAA yalnızca IPv6 yönlendirme, dinleyici, güvenlik duvarı ve TLS/uygulama yolu doğrulandıktan sonra.
• Alt alan adı ağında sabit siteler için tekil kayıtlar kullanılabilir. Talep üzerine alt site açılıyorsa uygun wildcard kayıtlarını planlayın; ana alan adı kaydı ayrıca gerekir.
• Her eşlenen alan adı ve kullanılan www adı için ilgili kayıtları hazırlayın; CNAME bir alan adını hedefler, IP adresini değil.
• Mevcut hizmet taşınıyorsa MX/TXT kayıtlarını koruyun, TTL değişimini eski önbellek süresini hesaba katarak önceden planlayın ve son veri eşitlemesini DNS geçişiyle koordine edin.

DNS kayıtları konusunda emin değilseniz, önce DNS kayıtları A’dan Z’ye rehberimize göz atmanızı öneririz. Yanlış ya da eksik A/AAAA/CNAME kayıtları domain mapping sırasında erişim sorunlarına yol açabilir.

WordPress Tarafı: Site Ekleme ve Alan Adı Atama

Ağ Yönetimi’nden başlangıç adresiyle bir alt site oluşturup çalıştığını doğrulayın; örneğin site1.example.com. Ardından ayrı alan adını doğru kurulum dizinine yönlendirin ve geçerli sertifikasını hazırlayın. www kullanılıyorsa yönlendirme ve sertifika kapsamına onu da ekleyin.

Yeni alan adının DNS, sunucu yönlendirmesi ve HTTPS yolu hazır olduğunda Ağ Yönetimi > Siteler > Düzenle ekranındaki Site Adresi alanını değiştirin:

• Örneğin https://site1.example.com adresinden https://site1.example.net adresine geçin.
• Doğru sitenin açıldığını, oturum çerezlerini, yönetim girişini ve döngüsüz kanonik yönlendirmeleri test edin.
• Eski host HTTPS üzerinden yeni adrese yönlendiriyorsa TLS bağlantısının kurulabilmesi için eski adın sertifikasını ve gerekli yönlendirmesini koruyun.

WordPress 4.5 ve sonrasında domain mapping çekirdek özelliğidir; ayrı eşleme eklentisi genel bir zorunluluk değildir. Ancak çekirdek yalnızca site atamasını yönetir. DNS, sanal hostlar, sertifikalar, gerekiyorsa güvenilir proxy üzerinden HTTPS algısı ve URL/çerez davranışı ayrıca doğru yapılandırılmalıdır.

Web Sunucusu Tarafı: Nginx server_name Ayarı

Eşlenen adları ilgili Nginx uygulama bloğuna ekleyin. Bu kesit yalnızca host listesini gösterir; yorum satırıyla belirtilen uygulama kuralları olmadan tam yapılandırma değildir:

server {
    listen 80;
    server_name example.com *.example.com site1.example.net brand.example.org;
    # Ortak uygulama kurallari burada gosterilmemistir.
}

İlgili hostlar aynı WordPress kurulumunu kullanabilir. Farklı sertifikalar için aşağıdaki gibi uygun TLS sanal hostları ve SNI seçimi gerekir; tek blokta çok ad yazmak sertifika dosyaları arasında otomatik seçim sağlamaz. Uygulama kurallarını ve erişim sınırlarını her etkin blokta tutarlı uygulayın.

SSL Stratejisi: Multisite’te Sertifikaları Yönetmek

Sertifika planını alan adı eşlemesinden önce hazırlayın. Yeni HTTPS URL’sine geçmek için o adın aktif uç noktada geçerli sertifikayla çalışması gerekir. Ağın ana adı, alt siteler, eşlenen alan adları ve yönlendiren eski hostlar ayrı ayrı envanterde yer almalıdır.

Tek Domain, Subdomain ve Wildcard SSL

Alt alan adı ağında wildcard SSL sertifikası kullanılabilir; kapsamını doğru ayırın:

• example.com ve kullanılıyorsa www.example.com sertifikanın kapsadığı adlar arasında bulunmalıdır; biri diğerini otomatik kapsamaz.
• *.example.com, shop.example.com gibi tek etiketli adları kapsar; example.com, deep.shop.example.com veya site1.example.net kapsam dışındadır.
• Ana ad ve wildcard aynı uygun sertifikada listelenebilir veya ayrı sertifikalar kullanılabilir; her durumda doğru sertifikanın sunulduğunu doğrulayın.

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ı?

site1.example.net ve brand.example.org gibi ayrı alan adları için şu seçenekleri karşılaştırın:

• SAN sertifikası: gerekli adlar tek sertifikada listelenir; CA sınırları, alan adı yetkisi ve ortak yenilemenin etkisi değerlendirilir.
• Ayrı DV sertifikaları: her ad grubu için bağımsız yenileme ve dağıtım kurulabilir. Aynı IP’de doğru sertifika seçimi, uygun TLS sanal hostları ve SNI yapılandırmasına bağlıdır.

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: 80. porttaki ACME doğrulama yolunun doğru yanıtı vermesi gerekir. Yayımlanan adresleri, proxy/CDN davranışını ve birden fazla uç noktayı kontrol edin. Wildcard sertifika vermez.
• DNS-01: doğrulama adında TXT kaydıyla alan adı kontrolünü kanıtlar. Let’s Encrypt wildcard sertifikaları için DNS-01 kullanılır. Her kiracı alanında yetkili API erişimi veya uygun doğrulama delegasyonu gerekir; tek seferlik manuel TXT kaydı otomatik yenileme değildir.
• DNS/API kimlik bilgilerini dar yetkiyle koruyun. Yenilemeye ek olarak sertifikanın aktif sunucuya dağıtımını, gerekiyorsa yeniden yüklemeyi ve başarısızlık uyarılarını test edin.

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

Aşağıdaki SNI kesiti Nginx 1.25.1 ve sonrasında HTTP/2 modülü bulunan bir kurulumun sözdizimini gösterir. Her alan adı kendi sertifikasına sahip olabilir. Yollar ve adlar örnektir; ortak uygulama kuralları burada gösterilmemiştir:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # Ortak WordPress uygulama kurallari burada gosterilmemistir.
}

server {
    listen 443 ssl;
    http2 on;
    server_name site1.example.net;
    ssl_certificate /etc/letsencrypt/live/site1.example.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.example.net/privkey.pem;
    # Ortak WordPress uygulama kurallari burada gosterilmemistir.
}

İki blok aynı WordPress kökünü ve gerekli uygulama/erişim kurallarını kullanmalıdır. Nginx, sertifika seçiminin yanında HTTP yönlendirmesi, PHP aktarımı ve erişim politikasını da uygular. Sertifika zinciri, ana makine kapsamı, HTTP→HTTPS yönlendirmesi, karma içerik ve giriş çerezlerini test edin. Veritabanındaki URL değişikliklerini yedek alarak, site kapsamını belirleyerek ve serileştirilmiş veriyi koruyan bir araçla deneyin; tüm ağa körlemesine arama/değiştirme uygulamayın.

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 ayarlarını çalışan PHP süreçlerinin bellek kullanımı, eşzamanlı iş, CPU ve veritabanı kapasitesiyle birlikte seçin. Belirli bir vCPU/RAM kombinasyonu tek başına doğru havuz değerlerini belirlemez:

• static, dynamic veya ondemand modunu iş yüküne göre seçin; dynamic kullanıyorsanız başlangıç, boşta ve en çok süreç sayılarını birlikte ayarlayın.
• pm.max_children sınırını yalnızca toplam RAM’i ortalama sürece bölerek belirlemeyin; veritabanı, cache, diğer işlemler ve güvenli çalışma payına yer bırakın.
• OPcache bellek ve dosya kapasitesini gerçek betik seti, önbellek isabeti ve yeniden başlama göstergeleriyle izleyin. Ortak kod, ilgili PHP çalışma ortamında yeniden kullanılabilir; her runtime’ın sınırlarını kontrol edin.
• Zaman damgası denetimi kapalıysa dağıtım ve geri dönüşte kodun görünmesi için açık invalidasyon veya uygun yeniden başlatma gerekir.

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

Kalıcı nesne önbelleği, uygun iş yükünde tekrar eden veritabanı işlemlerini azaltabilir. WordPress’in varsayılan nesne önbelleği tek isteğin ömrüyle sınırlıdır; Redis/Memcached gibi kalıcı bir arka uç için uyumlu entegrasyon gerekir. Nesne önbelleği kurmak uygulama oturumlarını otomatik taşımaz ve siparişler için kalıcı kayıt deposu oluşturmaz.

• Bakımı süren, Multisite uyumlu bir drop-in/eklenti seçin; kurulumlar ve siteler arasında anahtar ayrımını ve bilinçli paylaşılan global grupları doğrulayın.
• WP_CACHE_KEY_SALT gibi ayarlar entegrasyona bağlıdır; tek bir global prefix’in tüm site ayrımını sağladığını varsaymayın.
• Arka uca erişimi sınırlandırın; farklı key önekleri tüm cache’i okuyabilen kullanıcıya karşı güvenlik izolasyonu sağlamaz.
• Bellek, TTL, tahliye, invalidasyon ve arka uç arızasında uygulama davranışını ölçün; cache isabeti kadar doğruluğu da test edin.

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

Tam sayfa önbelleği, aynı genel yanıtı paylaşabilen isteklerde PHP yükünü azaltabilir. Oturum açılmamış olması tek başına yanıtın kişisel olmadığı anlamına gelmez. Nginx FastCGI cache, uygun ters proxy veya uygulama entegrasyonu kullanırken:

• Cache anahtarında güvenilir host, yol ve temsili etkileyen sorgu, şema, dil veya para birimi gibi girdileri değerlendirin; host+yol her uygulama için yeterli değildir.
• Giriş, yönetim, hesap, sepet, ödeme ve diğer kişiselleştirilmiş yanıtları ortak sayfa önbelleğinden çıkarın; ilgili çerezleri ve private/no-store davranışını koruyun.
• Farklı siteleri ve kullanıcıları birlikte test edin. İçerik güncellemesi, invalidasyon, soğuk cache ve hata yanıtlarının davranışını kontrol edin.
• CDN kullanılıyorsa aynı gizlilik ve site ayrımı koşullarını o katmana da uygulayın.

1–5 saniyelik mikroönbellek yalnızca güvenle paylaşılabilen genel yanıtlar için örnek bir yaklaşımdır. Kısa süre, özel içeriği güvenli hale getirmez; kullanıcı panellerini, sepetleri ve kişisel sayfaları ortak mikroönbelleğe almayın. Nginx mikroönbellekleme rehberi ayrıntı sağlar; anahtar, çerez ve geçersizleştirme kurallarını uygulamanızda doğrulayın.

Veritabanı Optimizasyonu

Multisite, site içerikleri için wp_2_posts ve wp_3_options gibi tablolar kullanır; önekler kuruluma bağlıdır. Kullanıcı ve ağ tabloları paylaşılabilir. Tek siteyi geri yüklemek veya taşımak bu ortak veriyi dikkate almalıdır:

• Gereksiz bileşenleri bağımlılık ve veri ihtiyacını kontrol ederek kaldırın; sorgu planlarını, bağlantı sayılarını ve kilit beklemelerini inceleyin.
• Slow query log’u uygun süre, maliyet ve erişim sınırlarıyla kullanın; hassas sorgu verilerini herkese açık bırakmayın.
• Options kayıtlarının kaynağını ve kullanımını doğrulayın. Uzun veya autoload edilmiş diye rastgele silmeyin; serileştirilmiş veri yapısını koruyun.
• InnoDB belleğini diğer servislerle birlikte bütçeleyin. MySQL 8’de eski query_cache ayarları kaldırılmıştır; MariaDB’deki query cache ayrı, sürüm/derleme ve iş yüküne bağlı bir özelliktir.

ProxySQL ile MySQL okuma/yazma ayrımı rehberi daha büyük ağlar için değerlendirme çerçevesi sunar. Replika eklemek uygulamanın okumalarını otomatik taşımaz veya otomatik failover sağlamaz. Replikasyon gecikmesi, yazıdan sonra okuma tutarlılığı, bağlantılar ve arıza geçişini ayrıca tasarlayın; bu katmanları ölçülmüş bir ihtiyaç olmadan eklemeyin.

Her Sitenin Zamanlanmış İşlerini Çalıştırmak

WP-Cron sürekli çalışan bir zamanlayıcı değildir; ziyaretçi istekleri zamanı gelen işleri tetikleme fırsatı oluşturur. Her istekte tüm işler çalışmaz. Sistem zamanlayıcısı trafiğe bağımlılığı azaltabilir, ancak Multisite’te her alt sitenin iş kuyruğu ayrı ele alınmalıdır:

1. Aktif siteleri ve işlerin son teslim sürelerini envantere alın. Yalnızca ana sitenin wp-cron.php adresini çağırmak tüm alt sitelerin işlerini kapsamaz.
2. Her site bağlamında uygun çağrıyı veya kurulu sürümün desteklediği WP-CLI yöntemini yapılandırın. Doğru uygulama kullanıcısı, PHP ortamı ve yolu kullanın; ağ seçeneğinin tüm kararlı sürümlerde bulunduğunu varsaymayın.
3. Çakışan çalışmaları, uzun süren işleri, başarısızlıkları ve yeni eklenen siteleri izleyin. Sürecin başlaması yerine işlerin tamamlandığını doğrulayın.
4. Yerine geçen zamanlayıcı bütün siteler için doğrulandıktan sonra DISABLE_WP_CRON ayarıyla ziyaretçi isteğinden tetiklemeyi kapatın. Çalışma sıklığını gerçek iş gereksinimleriyle belirleyin.

WP-Cron ve sistem cron kurulumu rehberi geçişi anlatır. Multisite’te site kapsamını ayrıca uyarlayın; mağaza eklentilerinin kendi iş kuyrukları varsa onların gereksinimlerini de kontrol edin. Zamanlayıcının varlığı, e-postanın gönderildiği veya ödeme arka plan işinin tamamlandığı anlamına gelmez.

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: anahtar erişimini ve kurtarma yolunu test etmeden eski yöntemi kapatmayın. Desteklenen güçlü kimlik doğrulama ve ağ kısıtlamalarını değerlendirin.
• Güvenlik duvarı: IPv4 ve IPv6’da yalnızca gereken portları açın; veritabanı/cache erişimini sınırlandırın ve proxy kaynaklarını doğru tanımlayın.
• Güncellemeler: desteklenen OS, PHP, web sunucusu ve veritabanı sürümlerini kullanın; acil güvenlik yamalarını rutin pencereye kadar ertelemeyin.
• Yönetim, izleme, yedek ve olay müdahalesinde kimin sorumlu olduğunu; ağ düzeyi DDoS korumasını sağlayıcıyla ayrıca netleştirin.

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

Ağ yönetimi yetkisini sınırlayın; site yöneticilerini gereksiz yere super admin yapmayın. Güçlü benzersiz parolalar, desteklenen 2FA ve güvenli kurtarma erişimi kullanın. Dosya izinlerini sahiplik ve PHP çalışma kullanıcısıyla birlikte seçin. XML-RPC veya wp-admin kısıtlamaları getirirken yayın araçları, gerekli AJAX/API uçları ve yönetim işlerini test edin.

Ek uygulama kontrolleri:

• DISALLOW_FILE_EDIT, paneldeki tema/eklenti düzenleyicisini kapatır; tüm dosya yazmalarını veya açıklardan yararlanılmasını engellemez.
• Uploads dizinlerindeki çalıştırılabilir dosya politikasını hem izinler hem web sunucusu düzeyinde doğrulayın; özel yolları unutmayın.
• Giriş denemelerini uygun oran sınırlama ve kimlik doğrulamayla koruyun; proxy arkasında doğru istemci IP’sinin kullanıldığını kontrol edin.
• Çekirdek, tema, eklenti, mu-plugin ve drop-in güncellemelerini takip edin; ortak bileşen değişikliğinin birden fazla siteye etkisini test edin.

WordPress güvenlik sertleştirme rehberi ilgili kontrolleri açıklar. Multisite yetkilerini ve ortak yazılım sınırlarını ayrıca değerlendirin. Mağazalar için ödeme mimarisi, hassas veri kapsamı ve geçerli yükümlülükler ayrı incelenmelidir; VPS, HTTPS veya bu ayarlar tek başına PCI DSS uyumluluğu kanıtı değildir.

Loglama ve İzleme

Bir sitedeki gecikmeyi yalnızca o sitenin eklentisine bağlamayın. Uygulama ölçümlerini ortak kaynak ve bağımlılık metrikleriyle ilişkilendirin:

• CPU, bellek baskısı, disk gecikmesi ve ağ sınırlarının yanında p95/p99 yanıt süresi, hata oranı, veritabanı bağlantıları, cache isabeti ve geciken işleri izleyin.
• Gerekli web/PHP-FPM loglarını erişimi sınırlı bir yerde saklayın; saklama süresi ve disk kullanımını yönetin.
• Üretimde hata ayrıntılarını ziyaretçiye göstermeyin. Gerekli tanılama loglarını kontrollü süreyle açın ve web’den indirilemediğini doğrulayın.
• Alarmların gerçek sorumluya ulaştığını ve yanıt sürecinin çalıştığını test edin.

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.

Örnek Ajans Senaryosu ve Kurtarma Planı

Varsayımsal bir ajansın 10–15 ilişkili kurumsal sitesi yönettiğini ve portföyüne yeni siteler eklediğini düşünelim. Bunlar DCHost’ta ölçülmüş müşteri sonuçları değildir. Ayrı kurulumlar şu işleri çoğaltabilir:

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

Bu farklılıklar merkezi yönetime geçme gerekçesi olabilir; ancak sitelerin ayrı kalmasını gerektiren sürüm, sahiplik veya güvenlik ihtiyaçlarını önce değerlendirin.

Multisite’in uygun bulunduğu bu örnekte, test edilecek mimari şöyle olabilir:

• Ölçümlerle boyutlandırılmış bir VPS; 4 vCPU ve 8 GB RAM yalnızca denenebilecek bir örnektir, site sayısı kapasite garantisi değildir.
• Yetkisi doğrulanmış alan adlarıyla eşlenen, uyumlu yazılım sürümlerini paylaşan siteler.
• Gerekli ana/wildcard veya ayrı sertifikaları kapsayan otomatik yenileme, dağıtım ve uyarılar.
• Doğrulanmış site anahtarlarıyla nesne cache’i ve kişisel yanıtları dışlayan sayfa cache’i; kazançlar testle ölçülür.
• Her siteyi kapsayan zamanlayıcı ve bağımsız kopyadan doğrulanmış geri yükleme süreci.

Yeni site eklemek; DNS, domain yetkisi, sertifika, cache, kullanıcı rolü ve zamanlanmış işleri de kapsamalıdır. Dikey büyütmenin yeniden başlatma, depolama ve ücret koşullarını sağlayıcıyla doğrulayın. Yatay büyümede oturum, yüklemeler, cache, veritabanı, dağıtım ve arıza toleransı ayrıca tasarlanır.

Yedek, Taşıma ve Tek Siteyi Geri Yükleme

Tüm ağın veritabanını, medya ve özel kodunu, gerekli yapılandırma ve erişim bilgilerini tutarlı biçimde yedekleyin. Bağımsız offsite kopya ve erişim ayrımı sağlayın. Sıklık ve saklama süresini kabul edilebilir veri kaybı ve geri dönüş süresiyle seçin; günlük yedek aktif mağazalar için yetersiz olabilir. Kısıtlı ortamda tam ağ ve tek site geri yüklemelerini ayrı ayrı deneyin; bir alt siteyi kurtarmak için canlı ağın tüm veritabanını eski kopyayla ezmeyin.

Mevcut bağımsız siteleri birleştirirken içerik dışa aktarımı tüm eklenti ayarlarını, kullanıcıları veya siparişleri taşımaz. Multisite uyumlu bir yöntemle tablo/kimlik eşlemesini, medyayı ve serileştirilmiş URL verisini kontrol edin. Pilot geçiş yapın; gerçek ödeme, e-posta ve webhook yan etkilerini testte engelleyin. Son yazmaların korunmasını, veri eşitlemesini, DNS önbellek çakışmasını, yönlendirmeleri ve geri dönüşü planlayın.

WordPress Multisite için Uygulanabilir Kontrol Listesi

Önce sitelerin ortak yazılım ve yönetim modeline uygunluğunu değerlendirin. Ölçülmüş kapasite ve desteklenen bir HTTPS kurulumuyla başlayın; Ağ Kurulumu’nun özel ayarlarını ve doğru sunucu kurallarını uygulayın. Domain mapping öncesinde DNS, alan adı yetkisi ve sertifikaları doğrulayın. Önbellekte site ve kullanıcı ayrımını, her sitenin işlerini ve yedekten geri dönüşü test edin.

DCHost veya başka bir sağlayıcıdan hizmet isterken kaynak, yönetim erişimi, sertifika otomasyonu ve bakım ihtiyaçlarını somutlaştırın. Bir VPS planının uygulama taşıma, güvenlik incelemesi veya sürekli yönetim içerdiğini varsaymayın; görevleri ve ücretleri ayrıca doğrulayın.

Multisite’i ilgili siteler için kontrollü bir pilotla değerlendirin. Ortak güncelleme ve güven sınırları uygun değilse ayrı kurulum veya daha güçlü izolasyon seçin. Amaç yalnızca tek panelde toplamak değil; sorumluları belli, alan adları ve verileri doğru eşlenen, ölçülen ve geri yüklenebilen bir yapı kurmaktır.