Çok Dilli Web Siteleri İçin Hosting ve SEO Mimarisi

Çok dilli mimariyi en başta doğru kurmak neden bu kadar önemli?

Bir ekiple yeni ülkelere açılma planı yaptığınız toplantıyı düşünün. Pazarlama ekibi “Almanya’ya açılıyoruz, siteyi Almanca yapmamız lazım” diyor, satış ekibi Fransa ve Orta Doğu’yu da ekliyor. Teknik tarafta ise sorular başlıyor: “Tek WordPress mi kuracağız, her dil için ayrı site mi açacağız, WPML mi, Polylang mı, yoksa Multisite mi? Ayrı domain alınca SEO bölünür mü, hosting maliyeti ne olur?”

Çok dilli web sitesi kurarken bu soruların hepsi doğrudan SEO performansınızı, barındırma maliyetinizi ve yönetilebilirliği etkiliyor. Yanlış mimariyle yola çıktığınızda, bir süre sonra eklenti çatışmaları, karışan URL’ler, düzgün çalışmayan hreflang etiketleri ve büyüdükçe taşınması zor bir hosting yapısıyla uğraşmanız kaçınılmaz oluyor. DCHost olarak sahada en çok gördüğümüz sorunlar tam da bu yanlış ilk kararlardan kaynaklanıyor.

Bu yazıda, özellikle WordPress ekosisteminde yaygın olan dört yaklaşımı hem hosting hem de SEO mimarisi açısından masaya yatıracağız: WPML, Polylang, WordPress Multisite ve her dil için ayrı domain/kurulum. Amacımız, takımınızın büyüklüğü, hedef pazar sayısı, içerik stratejiniz ve bütçenize göre hangi yaklaşımın daha anlamlı olduğuna net bir çerçeve çizmek.

Önce zemin: Domain ve URL mimarisi (ccTLD, alt alan adı, alt dizin)

WPML mi, Polylang mı sorusuna geçmeden önce, Google’ın dili ve lokasyonu nasıl anladığını netleştirmek gerekiyor. Çünkü seçeceğiniz eklenti veya mimari, büyük oranda URL stratejinize uyumlu olmak zorunda.

Temel üç seçenek

• Ayrı ülke uzantıları (ccTLD): ornek.de, ornek.fr, ornek.com.tr
• Alt alan adı: de.ornek.com, fr.ornek.com
• Alt dizin: ornek.com/de/, ornek.com/fr/

Bu konuya özel olarak hazırladığımız “.com mu ccTLD mi? Uluslararası SEO için doğru domain mimarisi” rehberinde her bir yapının avantaj ve dezavantajlarını detaylı anlattık. Burada kısaca özetleyelim:

• ccTLD: Yerel güven ve ülke hedefleme açısından çok güçlüdür, fakat her domain için ayrı otorite inşa etmeniz gerekir.
• Alt alan adı: Teknik olarak esnektir, ama Google çoğu durumda ayrı site gibi görür; link gücü daha zayıf paylaşılır.
• Alt dizin: Tüm diller tek domain otoritesini paylaşır, SEO açısından genellikle en dengeli seçenek kabul edilir.

URL mimarinizi seçerken mutlaka hreflang etiketlerini doğru kurma rehberimizdeki yönergeleri de gözden geçirmenizi öneririm. Çünkü hreflang, çok dilli mimarinin nerede ise yarısı kadar kritik.

Hosting tarafına etkisi

• ccTLD ve ayrı domain: Genellikle her domain için ayrı SSL, ayrı DNS ve çoğu zaman ayrı hosting hesabı/kurulumu anlamına gelir.
• Alt alan adı: Aynı host üzerinde domain mapping ile yönetilebilir; özellikle Multisite senaryolarında pratik olur.
• Alt dizin: Tek WordPress kurulumu ve tek hosting kaynağıyla yönetilir; bakım maliyeti düşer.

DCHost tarafında çok dilli kurumsal yapılarda en çok gördüğümüz senaryo; ana alan adında alt dizin kullanıp (ornek.com/de/, ornek.com/fr/) domain stratejisini daha sonra pazar büyüdüğünde ccTLD ile zenginleştirmek. Bunun mantıksal çerçevesini “Çok dilli kurumsal siteler için domain ve hosting mimarisi” yazımızda detaylı bir şekilde anlattık.

WordPress tarafında dört temel çok dilli yaklaşım

URL mimarisini genel hatlarıyla netleştirdikten sonra, WordPress dünyasında pratikte kullanılan dört ana yaklaşımı karşılaştıralım:

• WPML ile tek kurulum – çok dil
• Polylang ile tek kurulum – çok dil
• WordPress Multisite ile her dil için ayrı site
• Her dil için tamamen ayrı WordPress kurulumu ve bazen ayrı domain

1. WPML: Tek veritabanı, güçlü çeviri kontrolü

WPML, piyasadaki en bilinen çok dilli WordPress eklentilerinden biri. Tüm diller tek WordPress kurulumunda tutulur, çeviriler yazı/ürün bazında ilişkilendirilir. URL tarafında genellikle:

• Alt dizin (site.com/de/)
• Aynı domain içinde parametre
• Veya her dil için ayrı domain mapping

gibi seçenekleri destekler.

WPML’in SEO ve içerik tarafı artıları

• Tüm diller aynı domain otoritesini paylaşır (özellikle alt dizin kullanımında).
• Hreflang etiketlerini otomatik üretebilir; SEO tarafında ciddi zaman kazandırır.
• Çeviri yönetimi ve çevirmen rol dağılımı için gelişmiş arayüz sunar.
• WooCommerce ile sık kullanılan bir kombinasyon olduğundan dokümantasyon ve çözüm sayısı fazladır.

Hosting ve performans tarafı eksileri

• Tüm diller tek veritabanında olduğundan, özellikle büyük kataloglu WooCommerce sitelerinde veritabanı sorguları ağırlaşabilir.
• Her eklenen dil, özellikle kategori/ürün sayısı fazlaysa CPU, RAM ve veritabanı I/O tüketimini artırır.
• Paylaşımlı hostingte limitlere çabuk takılabilirsiniz; genellikle güçlü bir VPS veya üst seviye WordPress hosting daha sağlıklıdır.

Büyük kataloglu mağazalarda bu etkiyi somut olarak görmek için WooCommerce ve büyük WordPress siteleri için disk ve IOPS planlama rehberimize de mutlaka göz atın.

Ne zaman mantıklı?

• 2–5 dil arası, ürün/adet olarak orta seviyede WooCommerce mağazaları
• Kurumsal siteler, bloglar ve içerik portalları
• Tek ekip tarafından yönetilen, çeviri süreci kontrollü ilerleyen projeler

2. Polylang: Daha hafif, daha esnek (ama biraz daha manuel)

Polylang, WPML’e göre daha hafif bir yapı sunar ve çoğu senaryoda performans açısından daha az yük bindirir. Yine tek WordPress kurulumunda çoklu dil yönetimi sağlar; fakat bazı gelişmiş çeviri iş akışlarını manuel kurmanız gerekebilir.

SEO ve kullanım avantajları

• Temel çok dilli ihtiyaçlarda (blog, kurumsal site) performans/özellik dengesi iyidir.
• Gereksiz özelliklerle şişmediği için sayfa oluşturucular ve bazı cache eklentileriyle daha uyumlu davranabilir.
• Alt dizin, alt alan adı ve domain mapping senaryolarını destekler.

Hosting ve bakım tarafı notlar

• Tek kurulum ve tek veritabanı olduğu için bakım süreci görece basittir.
• Eklenti çatışmalarına WPML’e göre bir miktar daha az rastlansa da; staging ortamında test etmek yine şarttır.
• Çok büyük katalog veya yoğun trafik için, tıpkı WPML’de olduğu gibi güçlü bir VPS veya dedicated yapı tercih edilmelidir.

Ne zaman mantıklı?

• Önceliği performans olan, nispeten sade kurumsal ve içerik siteleri
• 3–4 dilde içerik üreten, fakat karmaşık çeviri iş akışına ihtiyacı olmayan ekipler

3. WordPress Multisite: Her dil ayrı site, tek çekirdek

WordPress Multisite, tek WordPress çekirdeği üzerinde birden fazla site çalıştırmanızı sağlayan bir mimari. Çok dilli senaryoda en sık kullanılan yaklaşım; her dil için ayrı bir site açmak (tr.ornek.com, de.ornek.com gibi) veya her siteyi ayrı domainle eşlemek.

Bu yapıyı özellikle “WordPress Multisite mi ayrı kurulumlar mı?” makalemizde detaylı karşılaştırmıştık. Çok dilli ve çok markalı projelerde Multisite, doğru kurulduğunda güçlü bir seçenek.

SEO ve mimari avantajları

• Her dil sitesinin kendi ayarları, menüleri, widget’ları ve hatta tema varyasyonları olabilir.
• Tek çekirdek üzerinden eklenti ve tema güncellemeleri merkezi yönetilir.
• Her dil için farklı domain (ccTLD) atamak istediğinizde domain mapping ile esnek bir yapı kurabilirsiniz.

Hosting ve kaynak kullanımı

• Tüm siteler aynı dosya sistemi ve veritabanı üzerinde çalışır, fakat tablo seviyesinde ayrışır.
• Yoğun trafikli dil versiyonları, aynı VPS üzerindeki diğer dil sitelerinin kaynaklarını etkileyebilir.
• Doğru planlanmış bir VPS veya dedicated sunucu üzerinde Multisite, onlarca siteyi yönetmek için verimli bir çözümdür.

Multisite senaryosunda domain mapping, SSL ve performans ayarlarını daha teknik seviyede anlatan rehberimiz olan “WordPress Multisite için VPS hosting rehberi”ni de mutlaka inceleyin.

Ne zaman mantıklı?

• Her dilde farklı ekiplerin çalıştığı, hatta tasarımın bile değiştiği kurumsal yapılar
• Çok markalı, aynı altyapıyı paylaşan; fakat marka/dil bazlı ayrışması gereken projeler
• Ajansların onlarca müşteri veya dil sitesini tek panelden yönetmek istedikleri durumlar

4. Her dil için ayrı WordPress ve ayrı domain

En klasik ve en “ayrık” yaklaşım: Her dil ve ülke için tamamen ayrı bir WordPress kurulumu, çoğu zaman ayrı domain ve bazen ayrı hosting hesabı.

SEO ve yönetim etkileri

• Her domain için sıfırdan otorite ve backlink inşa etmeniz gerekir.
• hreflang, canonical ve yönlendirme operasyonu çok daha dikkatli yönetilmelidir.
• İçerik ve tasarım özgürlüğü maksimum; ancak tutarlılık ve bakım yükü aynı oranda artar.

Hosting tarafında artı/eksi

• Her siteyi farklı sunuculara dağıtarak performans ve ülke bazlı gecikme süresini optimize edebilirsiniz.
• Ancak her kurulum için ayrı yedekleme, güncelleme, güvenlik ve izleme süreçleri gerekir.
• Çok sayıda küçük siteyi tek VPS üzerinde birden fazla WordPress sitesi barındırma rehberimizde anlattığımız gibi merkezi bir VPS’te toplamak, operasyonel anlamda daha mantıklı olabilir.

Ne zaman mantıklı?

• Her ülke ofisinin bağımsız hareket ettiği, bütçe ve SEO stratejilerinin tamamen farklı olduğu global yapılar
• Yerel ajanslarla çalışan, ülke bazlı tam özgürlük isteyen büyük kurumlar

SEO perspektifinden karşılaştırma

Tek domain (WPML/Polylang) vs çok domain (Multisite / ayrı kurulumlar)

SEO tarafında en kritik soru: “Tüm dilleri tek domain altında mı toplamalıyım, yoksa her dil/ülke için ayrı domain mi kullanmalıyım?”

• Tek domain, alt dizinler (WPML/Polylang): Link gücü ve domain otoritesi birleşir. İçerik üretimi düzenliyse, yeni dil açarken çok daha hızlı sonuç alırsınız.
• Çok domain (Multisite + mapping veya ayrı kurulumlar): Yerel marka algısı ve ccTLD avantajı yüksektir; ancak her alan adı için uzun vadeli SEO yatırımı gerekir.

Bu kararı verirken, alan adı stratejisi ve uluslararası SEO rehberimizdeki senaryoları kendi iş modelinizle eşleştirmek iyi bir başlangıç noktasıdır.

hreflang, canonical ve teknik sinyaller

Hangi yapıyı seçerseniz seçin, Google’a doğru sinyal vermezseniz, dil/ülke hedeflemesi dağılır. Dikkat edilmesi gerekenler:

• Tüm dil versiyonları arasında hreflang etiketleri eksiksiz ve çift yönlü tanımlanmalı.
• Sayfalar arası canonical etiketler doğru ayarlanmalı; yanlış canonical, çeviri sayfalarını indeks dışı bırakabilir.
• 301 yönlendirmeler, özellikle domain veya URL yapısı değişikliklerinde titizlikle planlanmalı.
• Her dil için ayrı XML sitemap veya hreflang içeren birleşik sitemap kullanılması indekslemeyi hızlandırır.

Bu başlıkların teknik detaylarını hreflang ve uluslararası SEO rehberimizde adım adım anlattık; çok dilli mimarinizi tasarlarken o yazıyı bir tür kontrol listesi gibi kullanabilirsiniz.

Hosting ve performans: Mimariniz büyüdükçe ne olur?

Çok dilli sitelerde en büyük hatalardan biri, sadece ilk lansman anını düşünerek küçük bir hosting paketi seçmek. Oysa dil sayısı, içerik hacmi ve trafik arttıkça mimarinin davranışı ciddi biçimde değişir.

Tek kurulum (WPML/Polylang) büyüdükçe

• Veritabanı tablolari (özellikle wp_posts ve wp_postmeta) hızla şişer.
• Özellikle WooCommerce’de sorgu süreleri uzar, TTFB artar.
• PHP-FPM işlem havuzunun doğru ayarlanmaması durumunda CPU tavan yapar.

Bunu önlemek için:

• Erken aşamada VPS’e geçiş planlanmalı.
• OPcache, Redis/Memcached object cache ve tam sayfa önbellek (Nginx FastCGI, LiteSpeed Cache vb.) devreye alınmalı.
• Veritabanı bakım ve indeksleme stratejisi kurulmalı; bu konuda WordPress veritabanı optimizasyon rehberimizden yararlanabilirsiniz.

Multisite veya çoklu kurulum büyüdükçe

• Her yeni dil, yeni site demek; site sayısı arttıkça PHP process sayısı da artar.
• Disk kullanımında tema/eklenti tekrarları oluşur (ayrı kurulumlarda). Multisite’ta bu biraz daha kontrollüdür.
• Yedekleme süreleri ve geri yükleme senaryoları karmaşıklaşır.

DCHost tarafında çok dilli Multisite veya çoklu kurulum projelerinde genellikle şu mimariyi öneriyoruz:

• En az 2–4 vCPU, 8–16 GB RAM’li bir VPS
• NVMe disk üzerinde ayrı sites-enabled ve yedekleme politikaları
• Veritabanının ayrı bir sunucuya taşınması gerektiği eşiği önceden belirlemek

Bu tip ölçeklenme kararlarını planlarken, “WordPress blog, WooCommerce ve SaaS için kaç CPU, ne kadar RAM?” rehberimiz pratik bir referans sunuyor.

Senaryolara göre hangi yaklaşımı seçmeli?

Senaryo 1: 2–3 dilli kurumsal web sitesi

• Hedef pazar: Türkiye + 1–2 Avrupa ülkesi
• Önümüzdeki 2 yılda dil sayısının çok artması beklenmiyor

Öneri: Alt dizin yapısı (ornek.com/en/, ornek.com/de/) + WPML veya Polylang. Tek kurulum, daha düşük bakım maliyeti ve birleşik domain otoritesi ile hızlı sonuç.

Senaryo 2: 3–5 dilli WooCommerce mağazası

• Ürün sayısı yüksek, varyasyonlar çok
• Sepet ve ödeme adımlarında hız kritik

Öneri: Eğer ekip küçük ve tek merkezden yönetim isteniyorsa, güçlü bir VPS üzerinde WPML veya Polylang ile tek kurulum; ancak katalog aşırı büyüyorsa veya her ülkenin fiyatlandırma/vergilendirme politikası çok farklıysa, Multisite veya ülke bazlı ayrı kurulumlar da değerlendirilebilir.

Özellikle sepet ve ödeme sayfalarında önbellek ve CDN ayarları çok hassas olduğundan, WooCommerce için CDN ve önbellek rehberimizdeki tavsiyeleri mutlaka uygulayın.

Senaryo 3: Global içerik portalı veya blog ağı

• İçerik üretimi yüksek, editör sayısı fazla
• Her dilde farklı kategori yapıları olabilir

Öneri: WordPress Multisite güçlü bir aday. Her dili ayrı site olarak yönetir, fakat tek çekirdekten eklenti ve güncellemeleri kontrol edersiniz. Çok dilli içerik portallarında, aynı içerik farklı dillerde yayınlandığında hreflang yönetimini manuel veya özel eklentilerle kurmak gerekir.

Senaryo 4: Her ülke ofisinin bağımsız hareket ettiği global şirket

• Her ülke kendi ajansıyla çalışıyor, tasarım ve içerik stratejisi tamamen bağımsız
• Yerel kampanyalar, kampanya sayfaları ve entegrasyonlar çok farklı

Öneri: Her ülke için ayrı WordPress kurulumu ve çoğu zaman ccTLD kullanımı (ornek.de, ornek.fr). Burada merkezi bir DCHost VPS kümesi üzerinde her ülke sitesi için ayrı hesaplar açmak, hem güvenlik hem de kaynak yönetimi açısından sağlıklı bir yöntem.

DCHost tarafında pratik mimari önerileri

Küçük/orta ölçekli çok dilli WordPress

• Tek WordPress kurulumu (WPML/Polylang)
• Alt dizin yapısı ile tüm dilleri tek domain altında toplama
• HTTP/2/HTTP/3, OPcache, Redis ve CDN ile hızlandırılmış bir DCHost VPS

Ajanslar ve çok siteli yapılar

• WordPress Multisite üzerinde her dil/ülke için ayrı site
• Domain mapping ile ccTLD veya alt alan adı atamaları
• Merkezi yedekleme, loglama ve izleme stratejisi

Büyük kurumsal ve e-ticaret projeleri

• Uygulama ve veritabanı sunucusunun ayrıldığı, gerektiğinde cache sunucusunun da devreye girdiği çok katmanlı mimari
• Dil/ülke bazlı ayrı kurulumlar, ama tek DCHost altyapısı ve ağ topolojisi
• Anycast DNS, CDN ve bölgesel veri merkezi tercihleriyle düşük gecikme süresi

Uygulama öncesi kontrol listesi

Çok dilli mimariyi canlıya almadan önce şu sorulara net cevap vermenizi öneririm:

1. Önümüzdeki 2–3 yılda kaç dil/ülke hedefliyorsunuz?
2. Her dildeki içerik tamamen aynı mı, yoksa ülkeye göre ciddi farklar olacak mı?
3. Yerel ekipler bağımsız hareket edecek mi, yoksa tek merkezden mi yönetilecek?
4. Hangi URL mimarisini seçtiniz: ccTLD, alt alan adı, alt dizin?
5. hreflang, canonical ve sitemap stratejinizi yazılı bir doküman haline getirdiniz mi?
6. Mevcut hosting paketi; CPU, RAM ve disk tarafında büyümeyi kaldıracak mı?

Bu sorulara net cevap verebiliyorsanız, WPML, Polylang, Multisite veya ayrı kurulumlar arasındaki seçiminiz çok daha bilinçli ve uzun ömürlü olacaktır.

Sonuç: Doğru mimari, doğru sunucu ve net SEO sinyalleri

Çok dilli web sitelerinde “en iyi çözüm” diye tek bir cevap yok. Küçük bir kurumsal site için mükemmel olan WPML/Polylang mimarisi, 8–10 ülkeye yayılmış, her ofisin bağımsız çalıştığı bir yapı için kabusa dönüşebilir. Benzer şekilde, her ülke için ayrı WordPress kurmak küçük bir ekip için gereksiz yere ağır ve maliyetli bir tercih olabilir.

Önemli olan; domain stratejiniz, ekip yapınız, içerik hacminiz ve büyüme planınız ile hosting ve SEO mimarisinin uyumlu olması. DCHost olarak biz, çok dilli projelerde önce bu sorulara birlikte cevap verip, ardından WPML/Polylang, Multisite veya çoklu kurulum alternatiflerini teknik ve operasyonel olarak tartıyoruz.

Eğer siz de yeni bir ülkeye açılma sürecindeyseniz veya mevcut çok dilli yapınızı yeniden kurgulamayı düşünüyorsanız, altyapınızı büyüme planınıza göre beraber tasarlayabiliriz. Mevcut sitenizin mimarisini ve kaynak kullanımını birlikte analiz edip, hem SEO sinyalleri hem de hosting tarafında uzun vadeli, sürdürülebilir bir yol haritası çıkaralım.