WordPress Multisite mi, Ayrı Kurulumlar mı?

WordPress Multisite mi, ayrı kurulumlar mı? Çok dilli veya çok markalı bir yapı kurarken yanıt, sitelerin ne kadar ortak çalışacağına bağlıdır. Multisite ortak kodun ve güncellemelerin yönetimini birleştirir; ayrı kurulumlar sürüm, erişim ve taşıma kararlarını site bazında ayırmayı kolaylaştırır. Domain yapısı, SEO, ekip yetkileri ve geri yükleme gereksinimleri birlikte değerlendirilmelidir. Mevcut sitelerde mimari değişikliği, URL eşleştirmesi ve test edilmiş bir geçiş planı gerektirebilir.

Ajanslar, kurumsal gruplar, franchise ağları ve global markalar için bu karar, merkezi yönetim ile site bağımsızlığı arasındaki dengeyi belirler. Bu rehberde, ikisinin de artı/eksi taraflarını teknik, operasyonel ve SEO boyutuyla netleştireceğiz; son bölümde de pratik bir karar matrisiyle sizin senaryonuza uygun yolu bulmanıza yardımcı olacağız.

WordPress’te çoklu site ihtiyacını doğru tanımlamak

Önce soruyu doğru sormak gerekiyor: Siz gerçekten kaç farklı iş hedefine hizmet eden, kaç farklı hedef kitleye konuşan ve kaç farklı marka/dil kombinasyonuna sahip olacaksınız?

• Tek marka, çok dil: ornek.com/tr, ornek.com/en, ornek.com/de gibi; içerik büyük ölçüde aynı, dil ve yerelleştirme ihtiyaçları farklı.
• Çok marka, benzer ürün/hizmet: grup1.com, grup2.com; yönetim aynı ekipte ama markalar farklı.
• Franchise veya bayilik ağı: sehir1.ornek.com, sehir2.ornek.com; temel şablon aynı, içerik kısmen yerelleşmiş.
• Ajans / freelancer portföyü: 20+ tamamen farklı müşteri sitesi, farklı domain, farklı tasarım ve eklentiler.

Her senaryoda Multisite ve ayrı kurulumlar bambaşka sonuçlar doğurur. Ayrıca domain mimariniz (ccTLD, alt alan, alt dizin) de bu kararla iç içe geçer. Bu konuda daha önce hazırladığımız çok dilli kurumsal siteler için domain ve hosting mimarisi rehberini mutlaka gözden geçirmenizi öneririm; burada ise özellikle WordPress katmanına odaklanacağız.

WordPress Multisite mimarisi nedir, nasıl çalışır?

WordPress Multisite, tek WordPress kurulumu içinde birden fazla site çalıştırır. Ortak kod tabanı ve ağ genelindeki kullanıcı hesapları paylaşılır; her sitenin içerik ve ayarları ayrı tutulur. Network Admin (Ağ Yönetimi), Super Admin yetkili kullanıcıların ağ bileşenlerini yönettiği alandır. Her sitenin ayrıca kendi yönetim paneli vardır. Bir ağ hesabı oluşturmak kullanıcıyı otomatik olarak bütün sitelere üye yapmaz; site üyeliği ve roller site bazında belirlenir. Bu mantıksal ayrım, işletim sistemi seviyesinde izolasyon anlamına gelmez.

Tek çekirdek, çok site mantığı

Multisite etkinleştirildiğinde:

• Ortak wp-config.php ve WordPress kod tabanı kullanılır.
• Standart wp_ önekli ağda ana sitenin içerik tabloları wp_posts, wp_options; site ID’si 2 olan ek sitenin tabloları wp_2_posts, wp_2_options biçimindedir.
• Super Admin, Ağ Yönetimi üzerinden siteleri, kullanıcıları ve ortak bileşenleri yönetir. Site yöneticilerinin yetkileri kendi siteleriyle sınırlıdır.
• Eklenti kurulumu ağ düzeyinde yönetilir. Ağda etkinleştirilen eklenti bütün sitelerde çalışır; site yöneticisi bunu yalnız kendi sitesinde devre dışı bırakamaz. Ağda etkin olmayan uygun eklentilerin site bazında etkinleştirilmesi, eklenti uyumuna, kullanıcının yetkilerine ve ağın Eklentiler menüsü iznine bağlıdır.

Merkezi güncelleme, paylaşılan kodu bütün ağ için değiştirir; farklı site senaryolarında önceden test gerekir. Tema kurmak, temayı otomatik olarak bütün sitelerde kullanılabilir veya etkin yapmaz. Super Admin temayı ağ genelinde ya da belirli bir site için kullanıma açar; site yöneticisi izin verilen temalar arasından etkin temayı seçer. Eklentinin ağda etkin olması da bütün ayarlarının veya verilerinin ortak tutulduğu anlamına gelmez; bu davranış eklentiye bağlıdır. Ayrıntılar için WordPress Ağ Yönetimi belgesine bakın.

Domain mapping, alt alan ve alt dizin seçenekleri

Multisite kurarken üç temel adresleme seçeneğiniz vardır:

• Alt dizin: ornek.com/tr, ornek.com/en
• Alt alan: tr.ornek.com, en.ornek.com
• Farklı domain (domain mapping): ornek.com, ornek.de, markab.com

Bu seçeneklerin işletim ve içerik yönetimi farklarını subdomain mi alt dizin mi rehberimizde bulabilirsiniz. Bir URL biçimi kendiliğinden daha iyi sıralama sağlamaz. Domain mapping için DNS kaydı, web sunucusunda alan adı eşleştirmesi ve her hostname’i kapsayan geçerli TLS sertifikası gerekir. HTTP/2 veya HTTP/3 ve HSTS, Multisite kurmanın zorunlu koşulları değildir; kendi gereksinimlerine göre yapılandırılır.

Bu kısımda özellikle WordPress Multisite için VPS hosting, domain mapping ve SSL ayarları yazımızdaki teknik adımlar Multisite kurmak isteyenler için iyi bir yol haritası sunuyor.

Veritabanı ve dosya yapısı

Standart WordPress Multisite kurulumu ortak bir veritabanı kullanır. Siteye özel tabloların yanında ağın ortak tabloları da bulunur. Varsayılan yeni ağ ve örnek wp_ öneki için:

• Ana site (standart ağda ID 1) wp_posts gibi öneklendirilmiş tabloları kullanır; ek site ID 2 için örnek wp_2_posts olur. Gerçek tablo öneki yapılandırmaya bağlıdır.
• Varsayılan ana site medyası wp-content/uploads, ek site ID 2 medyası wp-content/uploads/sites/2 altındadır. Yıl/ay klasörleri, özel yükleme ayarları, eski ağlar ve haricî medya depolama bu yolları değiştirebilir.
• wp_users ve wp_usermeta gibi kullanıcı tabloları paylaşılır. Aynı hesap bir sitede editör, diğerinde abone olabilir ya da diğer sitenin üyesi olmayabilir. Ağ tabloları ve bazı eklenti tabloları da ortaktır.

Site ve içerik sayısı arttıkça toplam veritabanı boyutu ve sorgu yükü büyüyebilir. Özellikle yüksek trafikli ağlarda MySQL/MariaDB optimizasyonu, indeksleme ve önbellekleme ihtiyaçları ölçülen iş yüküne göre değerlendirilmelidir. Sunucu tarafındaki seçenekler için PHP-FPM, OPcache, Redis ve MySQL optimizasyon pratikleri rehberinden yararlanabilirsiniz; ayarlar ağın iş yüküne göre değerlendirilmelidir.

Ayrı WordPress kurulumları yaklaşımı

Ayrı kurulum yaklaşımında her site kendi WordPress uygulamasına, yapılandırmasına ve güncelleme yaşam döngüsüne sahiptir:

• Her kurulum ayrı veritabanı kullanabilir. WordPress’in belgelediği diğer seçenek, aynı veritabanında her kurulumun wp-config.php dosyasında farklı $table_prefix değerleri kullanmaktır. Farklı önekler erişim izolasyonu sağlamaz.
• Dosyalar, tema ve eklenti sürümleri site özelinde yönetilebilir; bunun güvenlik sınırı olması için kullanıcı ve dosya izinleri de ayrılmalıdır.
• Güncelleme, yedekleme ve güvenlik politikaları site bazında uygulanır; merkezi araçlarla ortak bir süreç yürütülebilir.

Bu yaklaşım özellikle ajanslar, freelancer’lar ve birbirinden bağımsız projeler için site bazında yönetim sağlar. Güvenlik avantajı ise dosya erişimi, veritabanı yetkileri ve çalışma ortamlarının nasıl ayrıldığına bağlıdır.

Ayrı kurulumlarda izolasyonun artıları ve sınırları

Ayrı kurulumlar, izolasyon için daha fazla esneklik sağlar; ancak aynı sistem kullanıcısını, erişim yetkilerini veya kaynak havuzunu paylaşan siteler tam olarak yalıtılmış değildir:

• Bir sitedeki eklenti hatasının doğrudan diğer kurulumları etkileme riski azalır; ancak paylaşılan sunucu kaynaklarının tükenmesi diğer siteleri de yavaşlatabilir.
• Ayrı kurulum, SEO risklerinin ayrılması için tek başına yeterli bir ölçüt değildir; domain yapısı, içerik ve siteler arası bağlantılar ayrıca değerlendirilmelidir.
• Dosya erişimi, sistem kullanıcıları ve kimlik bilgileri ayrıldığında bir güvenlik olayının etkisini sınırlamak daha kolay olabilir.
• Her projeye özel tema/eklenti kombinasyonu seçebilirsiniz; farklı PHP sürümleri kullanmak ise hosting ortamının site bazında sürüm seçimini desteklemesine bağlıdır.

Özellikle yüksek riskli veya deneysel projeleri diğer kritik markalarınızdan ayrı tutmak istiyorsanız, ayrı kurulumlar çoğu zaman daha mantıklıdır. Örneğin, kritik kurumsal site ile deneysel kampanya/landing sitelerini farklı VPS’lere ayırmak, çalışma ortamlarını ayırmak için değerlendirilebilecek bir tasarım seçeneğidir.

Yönetim ve bakım maliyeti

Dezavantaj tarafında ise şunlar öne çıkar:

• Güncelleme yükü: 10 ayrı sitede WordPress, tema ve eklenti güncellemeleri her kurulum için uygulanır; merkezi yönetim ve otomasyon, tekrarlanan işlemleri azaltabilir.
• Monitoring ve yedekleme karmaşıklığı: Her site için ayrı yedek politikası ve izleme kurgulamak gerekebilir.
• Standart dışı yapıların artması: Farklı zamanlarda kurulmuş siteler, zamanla tamamen farklı eklenti/tasarım dünyalarına savrulabilir.

Bu nedenle, benzer WordPress yığınları üzerindeki sitelerde bakım yükü arttığında Multisite veya ayrı kurulumlar için merkezi yönetim ve otomasyon değerlendirmek anlamlı hale gelir. Site sayısı tek başına Multisite’e geçiş eşiği değildir. Ajanslara özel 20+ WordPress sitesini tek altyapıda yönetme rehberimiz bu açıdan okunmaya değer.

Çok dilli siteler için mimari seçenekler

Tek marka, çok dil senaryosunda seçeneklerden ikisi şunlardır: Aynı markanın farklı dillerini tek WordPress sitesinde bir çeviri eklentisiyle mi yöneteceğim, yoksa Multisite ile her dil için ayrı site mi açacağım?

Tek kurulum + çeviri eklentisi yaklaşımı

Tek bir WordPress sitesinde çeviri eklentisiyle birden fazla dili yönetebilirsiniz. Eklentiler aynı veri modelini kullanmaz; içerik ilişkileri, dizeler, URL seçenekleri ve Multisite uyumu seçilen ürüne göre kontrol edilmelidir:

• Örneğin WPML’de yazı çevirileri ayrı WordPress yazı kayıtları olarak bulunabilir; çeviri ilişkileri ve dil bilgisi icl_translations tablosunda tutulur. Arayüz dizeleri ve çevirileri için icl_strings ve icl_string_translations gibi ek tablolar vardır. Gerçek adlara sitenin tablo öneki eklenir; bütün veriler wp_posts içinde değildir.
• Menü, widget, URL ve dil seçici desteğini kullandığınız eklenti, tema ve sürüm üzerinde doğrulayın.
• Otomatik hreflang üretimi varsa bile karşılıklı eşleşmeleri, dil kodlarını ve her dildeki son URL’leri kontrol edin. Veri modeli örneği WPML’nin tablo belgesine dayanır; diğer eklentilere genellenmez.

Bu yaklaşımın artıları:

• Tek site, tek veritabanı, tek tema/eklenti seti.
• Dil geçişinin akıcılığı, eşdeğer içerikler arasında doğru bağlantılar kurulmasına ve dil seçicinin tasarımına bağlıdır.
• Ortak içerik bileşenlerinin güncellenmesi tek sitede koordine edilebilir; yerel ve hukuki metinlerin her dilde uygunluğu ayrıca gözden geçirilmelidir.

Eksileri ise şunlardır:

• İçerik ve çeviri sayısı arttıkça veritabanı büyüyebilir; performans, sorgulara, indekslere ve kullanılan eklentinin veri modeline bağlıdır.
• Çok farklı içerik stratejileri olan ülkeler (örnek: blog konuları, ürün kategorileri, kampanyalar tamamen farklı) için esneklik kısıtlı kalabilir.

Multisite ile dil bazlı siteler

Bir seçenek, Multisite içinde her dil veya ülke için ayrı site açmaktır: örneğin tr.ornek.com ve en.ornek.com. Her birinin içerik, menü ve site ayarları ayrılır; kod ve ağ yönetimi ortak kalır. Multisite kendi başına çeviri sistemi değildir. Site dilini seçmek, sayfaların çeviri ilişkilerini veya dil seçiciyi oluşturmaz. Ayrıca WPML gibi uyumlu bir eklentiyle her alt sitenin kendi içinde çok dilli olması da mümkündür; desteklenen URL kombinasyonlarını eklenti belgesinden kontrol edin. Bunlar farklı modellerdir.

Artıları:

• Dil veya ülke siteleri kendi içerik takvimini, başlıklarını ve ilgili SEO ayarlarını yönetebilir; ortak domain, kod ve kaynak bağımlılıkları devam eder.
• Uyumlu eklentiler ve izinler çerçevesinde pazara özgü ödeme sistemi veya entegrasyon kullanılabilir. Ağda etkin eklentiler ve ortak sürüm gereksinimleri esnekliği sınırlar.
• Yerel ekiplere yalnız ilgili sitenin içerik yetkileri verilebilir; Super Admin erişimi ayrı tutulur.

Eksileri:

• Çeviri ilişkilerini kurmak ve kaynak içerik değiştiğinde diğer sürümleri güncellemek için ek iş akışı veya uygun araç gerekir.
• Hreflang kümeleri yalnız eşdeğer sayfaları içermeli; her sayfa kendisini ve diğer dil/bölge sürümlerini tam URL ile karşılıklı göstermelidir. x-default isteğe bağlıdır; kullanılırsa ilgili kümenin uygun varsayılan sayfasını göstermelidir.
• Ortak kullanıcı hesapları, farklı eşlenmiş domain’ler arasında otomatik tek oturum açma garantisi vermez. Oturum ve çerez davranışını test edin; gerekiyorsa ayrıca kimlik federasyonu tasarlayın.

hreflang yapısını doğru kurmak, özellikle uluslararası SEO’da hayati öneme sahip. Bu konuda hazırladığımız hreflang’i doğru kurmanın sırları rehberini, ister Multisite ister tek kurulum kullanın, mutlaka okumanızı tavsiye ederim.

Çok markalı ve franchise yapılar için mimari kararlar

Çok markalı yapılarda iş artık sadece dilden çıkıp, farklı marka kimliklerini ve bazen farklı iş modellerini aynı altyapıda yönetme meselesine dönüşür.

Marka grupları: Aynı ekip, farklı markalar

Aynı teknik ekiple yönetilen bir marka grubunu düşünelim:

• 5–10 farklı marka sitesi (her biri farklı domain).
• Benzer tasarım bileşenleri ve içerik tipleri.
• Ortak teknik ekip, ortak hosting bütçesi.

Bu örnekte WordPress Multisite, ortak bileşenlerin yönetimini kolaylaştırabilir:

• Ortak bir ana tema ve bileşen kütüphanesi, markaya özgü alt temalarla kullanılabilir; ortak tema güncellemeleri tüm bağımlı sitelerde test edilmelidir.
• Güncelleme, erişim ve yedek politikaları ağ düzeyinde standartlaştırılabilir; siteye özel ihtiyaçlar ayrıca izlenir.
• Ağ Yönetimi yeni site oluşturmayı destekler. Hazır içerik, tema ayarı ve entegrasyonları klonlamak ise ek araç veya otomasyon gerektirir; yerleşik site ekleme işlemi tam site klonu değildir.

Ortak kod veya geniş yetkili bir hesabın ele geçirilmesi birden fazla markayı etkileyebilir. Bağımlılık envanteri, kısıtlı Super Admin erişimi ve geri yükleme testi gerekir. VPS ya da dedicated sunucu değerlendirmesinde ölçülen trafik ve kaynak ihtiyacını esas alın; ürünü seçmek tek başına siteleri birbirinden yalıtmaz.

Franchise ve bayilik ağları

Franchise yapılarında tipik model şudur:

• Merkez marka şablonu belirler.
• Her bayinin kendine ait alt alanı veya alt dizini vardır.
• Bayiler sınırlı içerik girişi yapar; ana çerçeve merkezden kontrol edilir.

Multisite, ortak şablona ve merkezi yönetime ihtiyaç duyan böyle bir yapı için değerlendirilebilir:

• Merkez, tema ve ortak eklenti sürümlerini yönetebilir.
• Bayilere yalnız gerekli içerik yetkileri verilir; hangi alanların değiştirilebileceği rol, tema ve eklenti tasarımıyla sınırlandırılır.
• Yeni bayi sitesi oluşturulabilir; hazır bir site şablonunu çoğaltmak için uyumlu klonlama aracı veya doğrulanmış otomasyon gerekir.

Her bayi farklı domain kullanıyorsa DNS, domain mapping ve sertifika yenilemesini de yönetin. Merkezî bir VPS veya dedicated sunucu değerlendirilirken eşzamanlı trafik, yedekleme süresi ve tek sunucu arızasının kapsamı hesaplanmalıdır. Bayi sayısı tek başına yeterli kaynak ölçüsü değildir.

SEO perspektifinden WordPress Multisite ve ayrı kurulumlar

SEO tarafı kararı büyük ölçüde netleştiren alanlardan biri. İki yaklaşım da doğru kurgulandığında başarıya engel değil; ama hata yaparsanız bedeli ağır olabiliyor.

Domain stratejisi, ccTLD ve hreflang

Önce domain katmanını netleştirmek gerekiyor. ccTLD (.de, .fr), alt alan (de.ornek.com) ve alt dizin (ornek.com/de) seçimleri için .com mu ccTLD mi? uluslararası SEO rehberimizde ayrıntılı kriterler vermiştik. Özetle:

• Ülkeye özgü marka algısı için ccTLD değerlendirilebilir; kayıt koşulları ve işletim maliyeti ayrıca incelenir. Domain uzantısı hukuki veya vergisel uyumu sağlamaz.
• Alt dizinler tek hostname altında içerik ve bağlantı yönetimini kolaylaştırabilir; otomatik otorite veya sıralama avantajı vaat etmez.
• Alt alanlar farklı yönlendirme ve barındırma seçenekleri sunar. URL tercihiyle WordPress kurulum tercihini ayrı değerlendirin.

Multisite’yi hem ccTLD’lerle (domain mapping) hem alt alan/alt dizin yapılarıyla birlikte kullanabilirsiniz. SEO açısından kritik olan şey, hreflang’lerin ve canonical’ların doğru kurulması ve içerik tutarlılığının sağlanmasıdır. Hatalı veya karşılıksız hreflang etiketleri yok sayılabilir ve amaçlanan dil/bölge eşleşmesini sağlayamayabilir. Bu, tek başına bir kopya içerik cezası anlamına gelmez.

Crawl bütçesi, link otoritesi ve dahili linkleme

Tarama bütçesi, özellikle çok sayıda URL’si olan ve sık değişen sitelerde değerlendirilir. WordPress alt sitesi sayısı tek başına ölçüt değildir. Google’ın tarama bütçesi rehberi de bu ayrımı yapar. Büyük URL kümelerinde:

• Gereksiz filtre, etiket, kategori ve yinelenen URL’leri inceleyin; kullanıcıya faydalı sayfaları sırf sayıyı azaltmak için kaldırmayın.
• Önemli sayfalara taranabilir ve bağlama uygun dahili bağlantılar verin. Dil seçiciler kullanıcıyı ilgili eşdeğer sayfaya götürmelidir.
• Site haritalarını, canonical ve hreflang çıktılarını doğrulayın. Ortak tema tek başına her sitenin ayarlarının doğru olduğu anlamına gelmez.

Ayrı WordPress kurulumu oluşturmak kendiliğinden ayrı tarama bütçesi kazandırmaz. URL’ler, sunucu yanıtları, içerik ve bağlantılar birlikte önem taşır. XML site haritaları keşfi destekler; keşfin veya dizine eklenmenin zorunlu tek yolu değildir. robots.txt kuralları aynı protokol, host ve port için kökteki dosyadan uygulanır: https://ornek.com/robots.txt, aynı host altındaki /tr/ ve /en/ yollarını kapsar. /en/robots.txt bağımsız tarama politikası oluşturmaz. Farklı subdomain veya domain için kendi kök dosyası kontrol edilir; WordPress’in sanal dosya filtresi bu kapsamı değiştirmez.

Spam politikaları ve SEO risk yönetimi

WordPress kurulum sınırı, Google’ın spam politikaları veya manuel işlem kapsamı için güvenilir bir sınır değildir. Sıralama düşüşü de her zaman manuel işlem anlamına gelmez.

• Ağ veya ayrı kurulum fark etmeksizin bütün sitelerde özgün, yararlı içerik ve doğal bağlantı uygulamaları gerekir. İçerik ve bağlantı spam’ini başka domaine taşımak geçerli bir risk çözümü değildir.
• Farklı domain’ler veya sunucular belirli işletim sınırları sağlayabilir; sıralama ya da manuel işlem izolasyonu garanti etmez.
• Kullanıcıların içerik veya alt site oluşturabildiği yapılarda yetki, moderasyon ve kötüye kullanım denetimi tasarlayın. Google spam politikaları bu mimarilerin tamamına uygulanır.

Kritik marka ile deneysel uygulamaları ayırma kararı; erişim, veri ve kullanılabilirlik gereksinimlerine dayanmalıdır. SEO denetimi ise her sitede içerik kalitesi, taranabilirlik ve politika uyumunu kapsamalıdır; başka kurulum veya domain kullanmak bunun yerini almaz.

Hosting ve altyapı boyutu: Hangi mimari ne ister?

WordPress mimarisi kadar CPU, RAM, disk I/O, ağ ve işletim sorumluluğu da önemlidir. Her sitenin tepe trafiğini, önbelleğe alınamayan isteklerini ve kurtarma hedeflerini ölçerek hosting planını oluşturun.

Multisite için kaynak planlama

Multisite ortak kod ve veritabanı katmanlarını paylaşır; PHP-FPM havuzu veya uygulama düğümü sayısı dağıtım tasarımına bağlıdır. Ortak kaynakların dolması birden fazla siteyi etkileyebileceği için:

• CPU tarafında yüksek eşzamanlı işlem sayısını kaldırabilecek vCPU veya fiziksel çekirdeklere ihtiyaç duyarsınız.
• RAM planlarken, PHP-FPM child süreçleri + veritabanı buffer’ları + cache servisleri (Redis/Memcached) birlikte düşünülmelidir.
• Disk gecikmesi ve I/O sınırlarını ölçün. NVMe SSD uygun iş yüklerinde yardımcı olabilir; sorgu, ağ veya uygulama darboğazını tek başına çözmez.

Güncel Core Web Vitals ölçütleri LCP, INP ve CLS’dir. TTFB, sunucu yanıtını değerlendirmede yararlıdır ancak Core Web Vital değildir. VPS, NVMe depolama veya dedicated sunucu tek başına iyi sonuç garantilemez; önbellek isabeti, PHP/DB yükü ve kullanıcı tarafındaki ölçümler birlikte değerlendirilmelidir. Core Web Vitals ve hosting rehberi ölçüm ve altyapı ilişkisini ayrıntılandırır. Önbellek anahtarlarının siteyi ve gerektiğinde dili ayırt ettiğini, oturum ve sepet gibi kişiselleştirilmiş yanıtların yanlış paylaşılmadığını doğrulayın.

Ayrı kurulumlar için kaynak ve izolasyon

Ayrı kurulumlarda erişim ve kaynak ayrımını şu şekilde planlayabilirsiniz:

• Aynı sunucuda ayrı sistem kullanıcıları, dosya izinleri, veritabanı yetkileri ve uygun PHP-FPM havuzlarıyla erişimi ayırabilirsiniz; kaynak ve sunucu arızası ortak kalabilir.
• Kritik siteleri ayrı VPS veya sunuculara taşımak bağımlılıkları azaltabilir. Yönetim hesapları, ağ, yedekleme, veritabanı ve diğer ortak servisleri de incelemeden tam izolasyon varsaymayın.

Ayrı kurulumlar, ölçülen ihtiyaca göre tek bir siteyi farklı kaynağa taşımanızı kolaylaştırır. Başlangıçta ortak sunucu kullanılabilir; trafik veya kurtarma gereksinimi değiştiğinde bazı siteler ayrılabilir. Bütçeyi yalnız sunucu fiyatıyla değil, bakım, izleme, lisanslar ve geri yükleme süresiyle birlikte karşılaştırın.

Yedekleme, felaket kurtarma ve güvenlik

Yedekleme tarafında fark oldukça net:

• Multisite yedeği; ağ veritabanı, kod ve bağımlılıklar, yapılandırma ve gerekli medya dâhil kurtarılacak sistemi kapsamalıdır. Haricî medya kullanılıyorsa onun da yedeği gerekir. Tam veritabanını geri yüklemek diğer sitelerdeki yeni verileri de etkiler. Tek site kurtarma aracı, ortak kullanıcıları, rollerini ve ağ/eklenti tablolarını doğru ele almalıdır.
• Ayrı kurulumlarda site bazında geri yükleme daha kolay planlanabilir. Aynı veritabanını farklı öneklerle paylaşan kurulumlarda tüm veritabanını geri yüklemek diğer siteleri etkiler; seçilen yedek kapsamı doğrulanmalıdır.

Güvenlik açısından da benzer bir tablo var:

• Multisite’te ortak kod ve yetkili hesaplar nedeniyle etki alanı genişleyebilir. Düzenli yamalama, en az yetki, dosya izinleri ve uygun WAF kuralları katmanlar sağlar; güvenlik garantisi vermez.
• Ayrı kurulumların saldırı etkisini sınırlandırması, sistem kullanıcısı, dosya erişimi, kimlik bilgileri ve kaynak sınırlarının gerçekten ayrılmasına bağlıdır. Merkezi yönetim hesabı ele geçirilirse çok sayıda kurulum etkilenebilir.

Yedekleri bağımsız kopyalarla tutun; saklama sıklığını kabul edilebilir veri kaybı ve kurtarma süresine göre belirleyin. Düzenli geri yükleme denemesi yapın. Staging ortamında canlı ödeme, e-posta ve webhook yan etkilerini sınırlandırıp erişimi koruyun. Blue-Green gibi dağıtım yöntemleri hazırlığı ayırabilir; ortak veritabanı değişikliklerini veya geri dönüşü kendiliğinden risksiz hâle getirmez.

Karar matrisi: Hangi durumda hangi yolu seçmelisiniz?

Tüm bu teoriyi pratik bir karara dönüştürmek için aşağıdaki soruları kendinize sormanızı öneririm. Basitleştirerek bir karar matrisi çıkaralım:

1. Tek marka mı, çok marka mı?

• Tek marka, çok dil: Ortak içerik akışı için tek site ve çeviri eklentisini; yerel editoryal ayrım için Multisite veya ayrı kurulumları karşılaştırın.
• Çok marka, aynı ekip: Ortak sürüm döngüsü kabul ediliyorsa Multisite ve domain mapping yararlı olabilir.
• Ajans, farklı müşteriler: Ayrı kurulumlar erişim, sürüm ve taşıma kararlarını ayırmayı kolaylaştırır; güvenlik için altyapı ayrımı da gerekir.

2. Ülkeler arası fark ne kadar büyük?

• İçerik stratejisi, ürün/hizmet seti ve yasal gereksinimler ülkeden ülkeye çok farklıysa: Her ülke için ayrı site (Multisite veya ayrı kurulum) mantıklı.
• Farklar daha çok dil seviyesinde ise: Tek kurulum + çeviri veya Multisite’de daha hafif ayrışma yeterli olabilir.

3. Risk iştahınız ve güvenlik öncelikleriniz nedir?

• Bir arızanın diğer markalara etkisini sınırlamak gerekiyorsa ayrı kurulumlarla birlikte çalışma ortamı, erişim ve ortak servis bağımlılıklarını da ayırın.
• Merkezi yönetim öncelikliyse Multisite’i değerlendirin; ağ güncellemelerinin kapsamını, uyumluluk testlerini ve kurtarma planını ekibin taşıyabildiğini doğrulayın.

4. Ekip yapınız ve operasyonel kapasiteniz nasıl?

• Küçük ekipte ortak yığın yönetim işlerini azaltabilir; ancak Multisite uzmanlığı ve tek site geri yükleme karmaşıklığı hesaba katılmalıdır. Küçük ekip otomatik olarak Multisite anlamına gelmez.
• Ayrı kurulumlarda merkezi izleme, yedekleme ve Git/Ansible/CI/CD gibi otomasyonlarla tekrarlanan işleri azaltabilirsiniz. Araç seçimi mevcut ekip yetkinliğine bağlıdır.

5. Büyüme planınız ne kadar agresif?

• Yeni dil ve markalar eklenecekse ortak bileşenleri, lisansları ve site oluşturma süreçlerini standartlaştırın.
• Bir markanın satılması, farklı ajansa devredilmesi veya bağımsız sürüm döngüsü ihtimali varsa ayrılma maliyetini önceden değerlendirin. Site sayısı tek başına mimari eşik değildir.

Örnek senaryolar ve seçim gerekçeleri

Aşağıdaki senaryolar karar vermeyi kolaylaştıran varsayımsal örneklerdir; müşteri vaka çalışması veya performans sonucu değildir.

Senaryo 1: Tek marka, 5 dil, güçlü SEO hedefleri

Global bir B2B SaaS şirketi düşünün: ornek.com/tr, /en, /de, /fr, /es. Ekip küçük, ürün ve içerik stratejisi büyük ölçüde ortak; yerel örnekler ve bazı yasal metinler farklı. Bu durumda:

• Tek site, alt dizinler ve uyumlu bir çeviri eklentisi içerik ilişkilerini yönetmek için başlangıç adayıdır; yerel süreçler bağımsızlaşırsa diğer modeller değerlendirilir.
• Hreflang, canonical ve dil seçici eşleşmelerini gerçek sayfalar üzerinde doğrulayın.
• Hosting’i beş dil olduğu için değil, eşzamanlı istek, sorgu yükü ve medya ihtiyacına göre seçin. Redis veya PHP-FPM ayarlarını ölçüm ve uyumluluk testine göre uygulayın.

Senaryo 2: Grup şirketi, 6 marka, aynı dijital ekip

Otomotiv sektöründe faaliyet gösteren bir grup düşünün: kurumsal site, ikinci el platformu, filo kiralama, yedek parça, insan kaynakları ve kurumsal sosyal sorumluluk siteleri var. Teknik ekip ortak, içerik ekipleri kısmen ayrışmış.

• Ortak sürüm döngüsü uygunsa Multisite ve her marka için domain mapping değerlendirilebilir.
• Ortak tasarım sistemi ve blok kütüphanesi tekrar eden geliştirmeyi azaltabilir; markaya özel değişikliklerin bakımını da planlayın.
• VPS veya dedicated kaynaklarını tepe yük ve kurtarma hedeflerine göre belirleyin. Farklı güvenlik veya bağımsızlık gereksinimleri olan markalar için ayrı kurulum seçeneğini koruyun.

Senaryo 3: Ajans, 25 müşteri, karışık trafik seviyeleri

Bazı müşteri siteleri aylık birkaç bin ziyaretçi alırken, bazıları televizyon kampanyasıyla on binleri görüyor. Ajans tarafında temel bir teknik ekip var ama herkese yetmiyor.

• Yüksek trafik veya daha sıkı kurtarma hedefi olan projeleri ölçümlere göre ayrı çalışma ortamına taşıyabilirsiniz; sabit sayıda müşteriyi ayırma kuralı yoktur.
• Ayrı kurulumları ortak envanter, güncelleme, yedekleme ve izleme süreçleriyle yönetin. Benzer yığınlı, aynı yönetim sınırındaki bir alt grup için Multisite ayrıca değerlendirilebilir.
• Standart kurulum şablonları otomasyonla çoğaltılabilir; her müşteri için kimlik bilgileri, lisanslar, domain ayarları ve erişim yetkilerini ayrı üretin ve test edin.

Sonuç ve sonraki adımlar

Kararı ortak kod ve süreç ihtiyacı ile bağımsız erişim, sürüm ve kurtarma ihtiyacı arasındaki denge belirler. Multisite ortak yönetimi kolaylaştırabilir; ayrı kurulumlar site bazında değişiklik ve taşıma esnekliği sağlar. İkisinin de SEO, performans ve güvenliği URL, içerik, uygulama ve altyapı ayarlarının kalitesine bağlıdır.

İş ve SEO gereksinimlerini yazın; karar matrisinden iki veya üç seçenek çıkarıp pilotta test edin. Hosting seçeneklerini DCHost ekibiyle değerlendirirken ölçülen kaynak ihtiyacını, yönetim yetkilerini, yedek kapsamını ve kurtarma hedeflerini paylaşın. Hizmet özellikleri ve işletim sorumluluğunu seçilen ürün için ayrıca doğrulayın.

Mevcut bir ağı taşırken içerik ihracını tam site klonu saymayın: medya dosyaları, kullanıcı/rol eşlemeleri, eklenti tabloları, yapılandırma ve serileştirilmiş URL verileri de ele alınmalıdır. URL değişirse eski sayfayı eşdeğer yeni sayfaya doğrudan 301 ile yönlendirin; aynı kalan URL için taşıma yönlendirmesi gerekmez. Canonical, hreflang, dahili bağlantı ve site haritalarını güncelleyin; formlar, oturumlar ve geri yüklemeyi test edin. Alan adı değişikliği planlama rehberi ile HTTP’den HTTPS’e geçiş ve 301 rehberi ek kontrol noktaları sunar. Geçiş sırasında sıralama dalgalanması olabilir; sıfır SEO kaybı veya anlık geri dönüş garantisi verilemez.