WordPress Multisite, tek bir WordPress kurulumunda birden fazla siteyi ağ olarak yönetme özelliğidir. Ortak çekirdek, tema ve eklenti altyapısını paylaşan kurum, okul veya bölgesel yayın ağlarında işe yarayabilir. Buna karşılık her sitenin tamamen bağımsız sunucu, güvenlik politikası veya ödeme sistemi istemesi durumunda yönetimi zorlaştırabilir. Bu rehber, Multisite’ın çalışma biçimini, alt alan adı ve alt dizin seçeneklerini, ağ yöneticisi rolünü, kurulum hazırlığını, SEO ve veri yönetimini, ayrıca ne zaman ayrı WordPress kurulumunun daha uygun olduğunu açıklar.
WordPress Multisite nedir?
Multisite, tek WordPress kod tabanı üzerinde bir ağ ve ona bağlı siteler oluşturur. Her alt site kendi yazılarını, sayfalarını, menülerini ve birçok ayarını yönetir. Kullanıcı hesapları ve çekirdek güncellemeleri ise ağ düzeyinde ele alınır. Bir sitenin alan adı veya tasarımı diğerinden farklı olabilir; yine de altyapının önemli bölümü ortaktır. “Tek panelde çok site” ifadesi doğrudur ama her işlemin tek yerde yapılacağı anlamına gelmez. Ağ paneli ile alt sitenin yönetim paneli farklı görevler taşır.
Örneğin bir üniversitenin fakülte siteleri aynı tema ailesini ve güncelleme politikasını paylaşabilir. Her fakültenin kendi editörleri içerik yayımlar, ağ yöneticisi ise hangi tema ve eklentilerin kullanılabileceğini belirler. Buna karşılık birbirinden bağımsız müşterilerin farklı hosting, veri saklama ve özel eklenti ihtiyaçları varsa tek ağ ciddi bağımlılık yaratabilir. Doğru tercih, site sayısından çok yönetim, güvenlik ve geri yükleme gereksinimine bağlıdır.
Tek site kurulumundan farkı
Normal WordPress kurulumu bir site için çekirdek, tema, eklenti ve veritabanı düzeni sağlar. Multisite’da çekirdek kurulum ortak kalırken alt sitelerin içerik tabloları ayrılır. Her site ayrı yazı ve ayarlara sahip olsa da sunucu kaynakları, ağ yöneticisi ve bazı sistem tabloları paylaşılır. Bu, güncelleme verimliliği sağlayabilir; bir ağ çapındaki hata ise birden fazla siteye dokunabilir. Bir alt siteyi başka sunucuya taşıma veya yalnızca o siteyi belirli tarihe geri döndürme işlemi tek siteye göre daha karmaşıktır.
Hangi projelerde uygundur?
Merkezi BT ekibi olan, benzer tema ve eklentileri kullanan bir kurum ağı güçlü adaydır. Çok dilli içerik için ayrı siteler de kurulabilir; ancak çeviri iş akışı ve dil bağlantıları kendiliğinden oluşmaz. Franchise veya bölge sitelerinde ortak tasarım standardı yararlı olabilir. Test ve eğitim amaçlı kısa ömürlü site ağları da mümkündür. Uygunluk için şu soruyu sorun: Sitelerin yaşam döngüsü, güncelleme penceresi, güvenlik seviyesi ve sahipliği gerçekten ortak mı? Yanıt hayırsa ayrı kurulumları değerlendirin.
Alt alan adı mı, alt dizin mi?
Alt alan adı yapısında siteler site1.ornek.com gibi adresler alır. Alt dizin yapısında ornek.com/site1/ biçimi kullanılır. Her iki yapı da WordPress ağında farklı siteleri temsil eder. Seçim, DNS ve sertifika yönetimi, mevcut URL yapısı, marka gereksinimi ve hosting desteğine bağlıdır. WordPress’in ağ hazırlık belgesi, alt alan adı için DNS ve web sunucusu eşlemesini ayrıntılandırır. Gerekirse wildcard alt alan adı yapılandırması gerekir; hosting planınızın bunu desteklediğini doğrulayın.
Alt dizin ağında mevcut sitenin kalıcı bağlantı düzeni etkilenebilir. WordPress belgeleri, eski kurulumlarda alt dizin seçeneğinin kısıtlanabileceğini ve ana sitede /blog/ yolunun devreye girebileceğini belirtir. Bu tür ayrıntıları kurulum sihirbazının kendi uyarılarıyla birlikte okuyun. Yalnızca “SEO için biri kesin daha iyi” genellemesine dayanmayın. Arama motoru açısından her sitenin kaliteli, erişilebilir ve doğru canonical ile sunulması daha temel konudur. URL yapısını sonradan değiştirmek yönlendirme ve bağlantı kaybı riski yaratır.
Farklı alan adları kullanılabilir mi?
Bir ağdaki alt site özel bir alan adına bağlanabilir, ancak DNS, web sunucusu yönlendirmesi ve TLS sertifikası doğru yapılandırılmalıdır. Sadece WordPress paneline alan adını yazmak her zaman yeterli değildir. Çerez ve giriş akışı, yönlendirmeler, canonical URL, site haritası ve e-posta alan adı ayarları da test edilmelidir. Özellikle CDN veya güvenlik duvarı önünde her alan adının doğru siteye geldiğini doğrulayın. Alan adı eşlemeyi yayına almadan önce geçici test adresinden kalıcı adrese 301 yönlendirme planını hazırlayın.
Kurulumdan önce yedek ve staging
Mevcut WordPress’i ağa dönüştürmek yapısal bir değişikliktir. Tam dosya ve veritabanı yedeği alın; geri yükleme işlemini bildiğinizden emin olun. Bir staging ortamında URL ve sunucu kurallarını önce deneyin. Etkin eklentilerin Multisite uyumunu araştırın. Ödeme, üyelik, çok dilli içerik, önbellek, arama ve SEO eklentilerinin ağ davranışları farklı olabilir. Site trafiği ve büyüme beklentisini düşünün; tek sunucuda birden fazla sitenin kapasite hesabı ayrı yapılmalıdır.
Alan adı yapısını belirlemeden kuruluma başlamayın. Alt alan adı için wildcard DNS ve sertifika ihtiyacını, alt dizin için mevcut permalink etkisini öğrenin. Hosting sağlayıcınızın Multisite desteğini ve yönetim panelindeki kısıtları sorun. Geri dönüşte eski tek siteye hangi yedekten döneceğinizi yazın; ağ kurulumundan sonra yeni içerikler oluşursa eski yedeğe dönmek onları kaybettirebilir. Bu nedenle geçiş anı, içerik dondurma penceresi ve ekip sorumluluğu planlanmalıdır.
Ağ kurulumunun genel adımları
WordPress’in resmî “Create A Network” akışı, uygun kurulumda ağ özelliğini etkinleştirme, yönetim panelindeki ağ kurulumu ekranında yapı seçme ve verilen yapılandırma satırlarını ilgili dosyalara ekleme aşamalarından oluşur. Dosya düzenleme erişimi ve sunucu bilgisi gerekir. Belgedeki örnek kodu kendi alan adınıza uyarlamadan kopyalamayın; ekranın o kuruluma ürettiği kuralları esas alın. Yapılandırma dosyalarında bir karakter hatası site erişimini kesebilir. Canlı yerine staging’de denemek ve mevcut dosyaların kopyasını saklamak önemlidir.
Kurulum sonrasında yeniden giriş gerekebilir. Ağ Yönetimi menüsünü, ana siteyi ve ilk alt siteyi kontrol edin. Önce düşük riskli test sitesi açıp tema, medya, kalıcı bağlantı, e-posta ve kullanıcı daveti akışlarını deneyin. Yapı doğru çalışmadan çok sayıda alt site oluşturmayın. Kullandığınız web sunucusu Apache, Nginx veya yönetilen hosting olabilir; yönlendirme kuralları aynı dosyada tutulmayabilir. Sunucu türünü bilmeden internette rastlanan .htaccess örneğini körlemesine uygulamayın.
Super Admin ve site yöneticisi farkı
Ağ yöneticisi (Super Admin) ağ genelinde site, kullanıcı, tema, eklenti ve ayarları yönetebilir. Alt sitenin yöneticisi kendi sitesinde içerik ve izin verilmiş ayarlarla çalışır; ağ çapında eklenti kurulumu veya çekirdek güncelleme yetkisi aynı değildir. WordPress’in rol belgeleri bu yetkileri ayrı tanımlar. Bir site editörüne ağ yöneticisi vermek gereksiz geniş erişim yaratır. Ağ yöneticisi sayısını sınırlayın, hesaplarda güçlü doğrulama kullanın ve hangi işlemin ağ, hangisinin site düzeyinde olduğunu ekip yönergelerinde belirtin.
Kullanıcılar ağ içinde birden fazla siteye farklı rollerle bağlanabilir. Bu, herkesin tüm alt siteleri düzenleyebildiği anlamına gelmez. Yeni kullanıcı daveti, üyelik kaydı ve siteye rol atama süreçlerini test edin. Paylaşılan kullanıcı tabanı iş akışını kolaylaştırabilir; bir hesabın ele geçirilmesi birden fazla siteye erişimi etkileyebileceğinden kimlik güvenliği önem kazanır. Yetki denetimini yeni site açılışında ve personel ayrıldığında tekrarlayın.
Tema ve eklenti yönetimi
Ağ yöneticisi temaları ve eklentileri kurar. Bir tema ağ genelinde kullanılabilir kılınabilir veya belirli siteye açılabilir. Eklenti ağ genelinde etkinleştirilebilir; bazı eklentiler site düzeyinde etkinleştirmeye izin verir. Her eklentinin Multisite uyumu ve veri saklama davranışı farklıdır. Ağ çapında etkinleştirme tüm siteleri aynı anda etkileyebilir; önce test ağında deneyin. Alt tema kullanılıyorsa ana tema ile alt tema güncellemelerini birlikte planlayın. Büyük ağlarda eklenti sayısını düşük tutmak bakım ve güvenlik açısından yararlıdır.
Medya ve depolama sınırları
Alt siteler medya dosyalarını kendi içeriklerinde kullanır, ancak sunucunun toplam disk alanı ortaktır. Ağ ayarlarında dosya türü veya yükleme boyutu kısıtları uygulanabilir. Sadece sitelerin sayısını saymak kapasite tahmini vermez; bir video ağı ile metin ağı aynı depolamayı tüketmez. Düzenli yedek boyutunu, görsel boyutlarını ve CDN davranışını ölçün. Bir sitenin aşırı medya yüklemesi diğer sitelerin disk sınırına yaklaşmasına neden olabilir. Medya taşırken alt site bağlamını korumak gerekir.
Yedek ve tek site geri yükleme
Tüm ağın dosya ve veritabanı yedeğini almak temel adımdır, ancak bir alt siteyi tek başına geri döndürme ihtiyacı daha zor olabilir. Veritabanında ağ tabloları, ortak kullanıcılar ve siteye özgü tablolar bulunur. Bir sitenin verilerini eski sürüme döndürürken aynı dönemde başka sitelerde oluşan yazı veya kullanıcıları ezmemek gerekir. Yedek sağlayıcınızın Multisite için site bazında geri yükleme sunup sunmadığını öğrenin. Bir test ağına geri yükleme yaparak prosedürü doğrulayın; yalnızca yedek dosyasının varlığı yeterli kanıt değildir.
Her alt site için sahiplik, kritik sayfalar, medya ve entegrasyon envanteri tutun. Ağ genelindeki bir güncellemeden önce tam yedek alın. Yoğun işlem alan bir mağazada geri yükleme anındaki sipariş verisini nasıl koruyacağınızı ayrıca planlayın. Yedek saklama süresi, şifreleme ve erişim yetkisi ağdaki en hassas sitenin ihtiyacına göre değerlendirilmelidir. Tek siteli bir yedek eklentisinin ağın tümünü doğru aldığı varsayılmamalıdır.
Performans ve kaynak paylaşımı
Bir ağ tek kod tabanı kullansa da her alt sitenin sayfa görüntülenmesi, yönetim işlemleri ve zamanlanmış görevleri sunucu kaynaklarını tüketir. Trafik zirvesi olan bir site diğer siteleri dolaylı yavaşlatabilir. Önbellek anahtarlarının siteye göre ayrılması gerekir; yanlış yapılandırma farklı sitelerin içeriğini karıştırabilir. Nesne önbelleği, CDN ve veritabanı yükünü ağ ölçeğinde ölçün. “Multisite her zaman daha hızlıdır” doğru değildir. Tek merkezden güncelleme kolaylığı performans garantisi sağlamaz.
SEO açısından Multisite
Her alt site kendi içerik amacı, başlığı, canonical adresi ve site haritasıyla değerlendirilmelidir. Alt alan adı veya alt dizin seçimi tek başına sıralama vaadi değildir. Yinelenen içerik oluşturan bölgesel sitelerde kullanıcıya özgü değer sunun; aynı metni yalnızca şehir adı değiştirerek çoğaltmayın. Farklı dil sitelerinde dil bağlantıları ve yerelleştirme akışını ayrıca planlayın. Özel alan adı eşlemesinde doğru HTTPS ve canonical çıktısını doğrulayın. Ağ genelinde yanlış bir SEO eklenti ayarı birden çok siteyi etkileyebilir, bu yüzden her alt siteyi canlıda örneklemle test edin.
Güvenlik ve izolasyon sınırı
Alt siteler ayrı içerik alanı sunsa da aynı WordPress kurulumunu paylaşır. Bir ağ yöneticisi hesabının ele geçirilmesi geniş etki yaratır. Her siteyi tamamen bağımsız güvenlik sınırı gibi görmek yanlıştır. Çekirdek, tema ve eklentileri güncel tutun; ağ yöneticileri için çok faktörlü doğrulama ve sınırlı yetki kullanın. Farklı müşteri verilerinin hukuki ve operasyonel ayrımı gerekiyorsa ayrı kurulum veya altyapı daha uygun olabilir. Ağdaki bir eklentinin her siteye hangi veri erişimini sağladığını inceleyin.
Multisite yerine ayrı kurulum ne zaman?
Farklı ekipler bağımsız güncelleme takvimi istiyorsa, siteler farklı PHP veya eklenti sürümlerine bağımlıysa, müşteriler kendi sunucu erişimini istiyorsa veya bir sitenin arızasının diğerlerine hiç etki etmemesi gerekiyorsa ayrı kurulum daha esnek olabilir. Bir mağaza ile basit blogu aynı ağa almak teknik olarak mümkün olsa da ödeme, yedek ve performans gereksinimleri uyuşmayabilir. Ayrıca bir alt siteyi ileride satmak veya başka hosting’e taşımak planlanıyorsa ayrıştırma maliyetini şimdiden düşünün. Multisite, barındırma maliyetini otomatik azaltan sihirli araç değildir.
Yayına alma için kısa kontrol
Her alt sitenin ana sayfası ve birkaç iç sayfası doğru alan adında açılıyor mu? HTTPS sertifikası tüm adları kapsıyor mu? Editör yalnızca kendi sitesini yönetebiliyor mu? Ağ yöneticisi tema ve eklenti güncellemelerini görebiliyor mu? E-posta daveti, parola sıfırlama ve form bildirimi doğru adresten çıkıyor mu? Önbellek başka sitenin sayfasını göstermiyor mu? Site haritaları, canonical URL’ler ve varsa dil işaretleri doğru mu? Yanıtları yazılı bir teslim listesinde tutun.
Bir sorun çıktığında yalnızca etkilenen alt siteyi değil ortak katmanları da inceleyin. DNS ve TLS sorunu belirli alan adını; ağ eklentisi sorunu bütün siteleri etkileyebilir. Günlükleri site kimliği ve saatle eşleştirin. Kullanıcıya görünen hata, ağ yapılandırması, veritabanı veya tek sitenin teması kaynaklı olabilir. Kaynağı ayırmadan tüm ağın ayarlarını değiştirmek teşhisi zorlaştırır.
Örnek karar: üç bölge sitesi
Bir kuruluş üç bölge için ayrı haber ve etkinlik sayfası açacak. Tasarım, eklentiler, güvenlik ekibi ve güncelleme saati ortak. Editörler yalnızca kendi bölgesine yazacak. Bu durumda Multisite yönetim yükünü azaltabilir. Önce alan adı düzeni seçilir, her sitenin içerik sorumlusu belirlenir ve rol matrisi hazırlanır. Staging ağında yeni site açma, kullanıcı daveti, tema etkinleştirme, medya yükleme ve site haritası test edilir. Canlıya geçişten sonra her bölgenin canonical adresi ve doğru siteye gelen DNS kaydı kontrol edilir.
İleride bir bölge kendi ödeme sistemi ve bağımsız sunucu isterse aynı ağ kısıtlayıcı hâle gelebilir. Bu olasılık yüksekse başlangıçta ayrı kurulumlar daha iyi olabilir. Karar toplantısında yalnızca “kaç tıkla site açılıyor?” sorusunu sormayın. Kimin yedek aldığı, kimin güvenlik güncellemesi yaptığı, tek sitenin nasıl geri döndürüleceği ve ağ genelindeki kesintinin kimleri etkileyeceği de yazılmalıdır.
Sık sorulan sorular
Multisite ile siteler aynı içeriği mi paylaşır?
Hayır. Alt sitelerin yazıları ve birçok ayarı ayrıdır. Ortak olan çekirdek, ağ yönetimi ve kullanıcı altyapısı gibi katmanlardır. İçerik paylaşımı isteniyorsa ayrı iş akışı veya eklenti gerekir.
Her alt sitenin ayrı alan adı olabilir mi?
Evet, uygun alan adı eşleme, DNS, sunucu ve TLS yapılandırmasıyla mümkündür. Giriş, yönlendirme ve canonical davranışı canlıda test edilmelidir.
Bir sitedeki yönetici tüm ağı yönetir mi?
Hayır. Site yöneticisi kendi sitesinin izin verilen işlemlerini yapar. Ağ genelindeki işlemler Super Admin yetkisi gerektirir.
Multisite kurulumu geri alınabilir mi?
Teorik olarak siteyi ayırma veya eski yedeğe dönme yolları vardır, ancak tek bir düğmeyle risksiz geri alma beklemeyin. Yeni içerik ve kullanıcıların taşınması ayrıca planlanmalıdır.
Sonuç
WordPress Multisite, yönetimi merkezileştirmek isteyen ve ortak teknik kuralları paylaşan site gruplarına uygundur. Kararın ana ekseni URL biçimi değil, yetki, güncelleme, yedek, performans ve izolasyon ihtiyacıdır. Önce test ağında kritik akışları deneyin; sonra canlıdaki her alt sitenin bağımsız içerik ve SEO çıktısını doğrulayın.
Kaynaklar ve ileri okuma
