Çok Dilli Kurumsal Site Mimarisi: Alt Dizin, Alt Alan Adı veya ccTLD

Çok dilli bir kurumsal web sitesinde ilk karar çeviri eklentisi değil, URL yapısıdır. Bu karar SEO sinyallerini, altyapıyı, içerik iş akışını ve yıllar sonraki taşıma maliyetini birlikte belirler; sonradan değiştirmek tüm URL’leri değiştirmek demektir. Aşağıda alt dizin, alt alan adı ve ccTLD seçeneklerini, WordPress’teki uygulama modellerini ve çeviri iş akışını bir mimari karar olarak ele alıyoruz. Yeni dil eklemeye hazırlanan ya da mevcut çok dilli yapısını sadeleştirmek isteyen teknik ekipler için.

Dil ile bölge hedeflemesinin farkı

“İngilizce site” ile “Almanya sitesi” aynı ihtiyaç değildir. Dil hedeflemesinde içerik o dili konuşan herkes içindir; fiyat, mevzuat, iletişim bilgisi ve hizmet kapsamı değişmez. Bölge hedeflemesinde ise aynı dil farklı ülkelerde farklı içerikle sunulur: para birimi, yasal metinler, telefon numarası, teslimat koşulları veya ürün yelpazesi değişir.

Bu ayrım doğrudan hreflang değerlerine yansır. Yalnız dil hedefleniyorsa en, bölge de hedefleniyorsa en-GB veya de-AT gibi dil–bölge kodları kullanılır. Bölge kodu tek başına kullanılamaz; her zaman bir dil koduyla birlikte yazılır. Kurumsal hizmet sitelerinin çoğunda ihtiyaç dil hedeflemesidir. Gereksiz bölge varyantı açmak, birbirinin kopyası sayfa grupları ve fazladan bakım yükü üretir.

Karar için tek soru yeter: aynı dildeki iki ülke sürümünde içerik gerçekten farklı olacak mı? Cevap hayırsa tek dil sürümü yeterlidir.

URL yapısı seçenekleri karşılaştırması

Google’ın çok bölgeli ve çok dilli siteler rehberi bu seçenekleri tarafsız biçimde listeler. Seçim teknikten çok işletim ve organizasyon kararıdır.

Yapı	Örnek	Güçlü yanı	Sınırlaması
Alt dizin	ornek.com/en/	Tek alan adı, tek altyapı, ortak otorite	Ülke sinyali zayıf; tek sunucu konumu
Alt alan adı	en.ornek.com	Ayrı barındırma ve yayın mümkün	Ayrı DNS, sertifika, izleme
ccTLD	ornek.de	Güçlü ülke sinyali, yerel algı	Alan adı ve otorite her ülkede ayrı
URL parametresi	ornek.com/?lang=en	Kurulumu kolay	Önerilmez; ayrıştırma ve önbellek sorunları

Tabloya ek olarak tartılması gereken boyutlar:

• Organizasyon: Diller aynı ekip tarafından mı yönetilecek, yoksa ülke ofisleri kendi içeriğini mi yayınlayacak?
• Altyapı: Tüm diller aynı sunucu ve CDN arkasında mı çalışacak? CDN kullanıldığında sunucunun fiziksel konumunun bölge hedeflemesine etkisi zaten sınırlıdır.
• Analitik ve izleme: ccTLD’lerin her biri Search Console’da ayrı mülk ister; alt alan adları bir alan adı mülkü altında toplanabilir ama dil bazında ayrı raporlama için URL önekli mülkler de açılır. ccTLD’ler analitikte alan adları arası ölçüm yapılandırması gerektirir.
• Gelecekteki taşıma: Yapıyı sonradan değiştirmek tüm URL’leri değiştirir. Bu, kapsamlı bir yönlendirme projesidir.

Tek ekip tarafından yönetilen kurumsal web sitelerinde alt dizin çoğu zaman en dengeli seçenektir: tek sertifika, tek DNS kaydı, tek izleme noktası. Ülke bazında ayrı tüzel kişilik, ayrı ürün yelpazesi ve yerel pazarlama ekibi varsa ccTLD değerlendirilebilir. Alt alan adı, dil sürümlerinin teknik olarak ayrışması gerektiğinde (farklı platform, farklı yayın döngüsü) anlamlıdır.

WordPress’te çok dilli kurgu seçenekleri

URL yapısı belirlendikten sonra CMS tarafında üç ana model vardır:

Model	Nasıl çalışır	Uygun olduğu durum
Tek site + çeviri eklentisi	Çeviriler aynı veritabanında, içerikler birbirine bağlı	Aynı yapı, aynı ekip, az–orta içerik
Multisite, dil başına bir site	Her dil ayrı alt site; eşleme eklenti veya özel kodla	Dillerin yapısı ve yetkileri ayrışıyor
Headless CMS	İçerik API’den, ön yüz yerelleştirmeyi yönetir	Çok kanallı içerik, özel ön yüz

Tek site modelinde çeviri eklentisi (Polylang, WPML gibi) her içeriğin hangi dilde olduğunu ve hangi içerikle eşleştiğini tutar; menü, widget ve tema metinleri için ayrı çeviri arayüzleri sunar. Avantajı tek yönetim paneli ve otomatik hreflang üretimidir. Sınırlaması, eklentinin tüm siteye nüfuz etmesi; sayfa oluşturucu, önbellek ve özel sorgularla uyum sorunlarının eklenti güncellemelerine bağlı kalmasıdır. Sahada en sık karşılaştığımız tablo: eklenti güncellemesinden sonra bir dilin menüsü boş geliyor ya da önbellek eklentisi iki dili aynı önbellek anahtarına yazıyor.

Multisite modelinde her dil kendi seçeneklerine, menüsüne ve kullanıcı yetkisine sahiptir; dil ekipleri birbirinin içeriğini bozamaz. Buna karşılık sayfalar arası eşleme kendiliğinden gelmez: hreflang için hangi sayfanın hangi sitedeki hangi sayfaya karşılık geldiği ayrıca tutulmalıdır. Tema, sayfa oluşturucu şablonları ve global stiller de alt siteler arasında otomatik paylaşılmaz. Senkronizasyon için bilinçli bir yöntem kurulmazsa diller görsel olarak birbirinden uzaklaşır.

Headless model, içeriğin web dışındaki kanallara da gittiği veya ön yüzün özel bir uygulama olduğu projelerde düşünülür. Genel değerlendirmesi headless CMS nedir ve ne zaman tercih edilir yazısında.

Çeviri iş akışı ve içerik eşleme

Çok dilli sitede zamanla bozulan şey altyapıdan çok içerik eşitliğidir: kaynak dilde güncellenen sayfanın çevirisi eski kalır, yeni sayfa bir dilde yayınlanıp diğerlerinde unutulur. İki yıl sonra İngilizce sürüm başka bir şirketi anlatıyordur. Bunu önlemek için içerik eşlemesini bir veri olarak yönetin.

• Kaynak dil kuralı: Her içeriğin bir kaynak dili olur, çeviriler kaynaktan türetilir. Çapraz düzenleme (İngilizceden Almancaya, oradan Türkçeye) yapılmaz.
• Durum takibi: Kaynak içerik değiştiğinde çeviriler “güncelleme gerekli” durumuna düşmelidir.
• Terim sözlüğü: Hizmet adları, ürün terimleri ve marka ifadeleri için dil başına onaylı karşılıklar tutulur; makine çevirisi kullanılıyorsa bu sözlük çeviri motoruna da verilir.
• Yerelleştirilmiş slug: URL’ler hedef dilde olmalıdır; /en/hizmetler/ gibi karma yapılar kullanıcıya ve arama motoruna tutarsız sinyal verir.
• Eksik çeviri politikası: Çevirisi olmayan sayfanın o dilde nasıl davranacağı önceden belirlenir.

Eşleme doğru tutulduğunda her sayfa, kendisi dahil tüm dil karşılıklarını listeleyen hreflang bağlantılarını üretebilir:

<link rel="alternate" hreflang="tr" href="https://www.ornek.com/hizmetler/ag-kurulumu/" />
<link rel="alternate" hreflang="en" href="https://www.ornek.com/en/services/network-installation/" />
<link rel="alternate" hreflang="de" href="https://www.ornek.com/de/leistungen/netzwerkinstallation/" />
<link rel="alternate" hreflang="x-default" href="https://www.ornek.com/hizmetler/ag-kurulumu/" />

Bu bağlantılar karşılıklı olmalıdır: A sayfası B’yi gösteriyorsa B de A’yı göstermeli. Tek yönlü hreflang yok sayılır. Her sürümün canonical’ı kendisini göstermeli, başka bir dil sürümünü değil; Türkçe sayfaya canonical verilen İngilizce sürüm dizinden düşer. Etiketin doğrulanması ve sık görülen hataları hreflang uygulaması: sık hatalar ve doğrulama yazısında ayrıntılı ele alınıyor.

Otomatik dil yönlendirmesinin riskleri

Ziyaretçiyi IP adresine veya tarayıcının Accept-Language başlığına göre otomatik olarak bir dil sürümüne göndermek cazip görünür. Üç ciddi yan etkisi vardır.

1. Tarama sorunu: Arama motoru tarayıcıları genellikle Accept-Language başlığı göndermez ve çoğunlukla belirli ülkelerdeki IP’lerden tarar. Zorunlu yönlendirme, bazı dil sürümlerinin hiç taranmamasına yol açabilir. Google bu nedenle algılanan dile göre otomatik yönlendirme yerine kullanıcıya bağlantı sunmayı önerir.
2. Kullanıcı kontrolü: Yurt dışındaki Türk bir kullanıcı veya İngilizce tarayıcı kullanan bir mühendis istemediği sürüme zorlanır ve geri dönemez.
3. Önbellek uyumsuzluğu: Aynı URL’nin başlığa göre farklı yanıt vermesi, yanıtta Vary: Accept-Language başlığını ve CDN önbellek anahtarının bu başlığı içermesini gerektirir; bu da önbellek isabet oranını düşürür. Aksi halde bir kullanıcının dil yönlendirmesi diğerlerine önbellekten sunulur.

Dil seçici de dikkat ister. Bayrak dil değildir; dil adını kendi dilinde gösterin (Deutsch, English). Seçici her sayfada mevcut sayfanın karşılığına gitmeli, dilin ana sayfasına değil. Karşılığı olmayan sayfalarda dilin ana sayfasına gidildiği kullanıcıya açıkça belli olmalı.

Çok dilli site karar kontrol listesi

• Hedefleme türü netleşti: yalnız dil mi, dil ve bölge mi?
• URL yapısı organizasyon, altyapı ve analitik açısından değerlendirildi ve yazılı karara bağlandı.
• CMS modeli seçildi; eşleme verisinin nerede tutulacağı belli.
• Her dil için slug, menü ve kategori adları yerelleştirildi.
• Kaynak dil kuralı, terim sözlüğü ve çeviri onay adımı tanımlandı.
• Eksik çeviri politikası belirlendi.
• hreflang karşılıklı, canonical her sürümde kendine işaret ediyor; x-default kararı verildi.
• Otomatik zorunlu yönlendirme yok; dil seçici sayfa karşılığına gidiyor.
• Sitemap’te tüm dil sürümleri yer alıyor; Search Console mülkleri yapıya göre açıldı.
• Form, e-posta bildirimleri, yasal metinler ve yapılandırılmış veri her dilde ayrı kontrol edildi.

Listenin son maddesi en sık atlananıdır: İngilizce sayfadaki iletişim formu Türkçe onay e-postası gönderir, kimse fark etmez. Yeni dil eklemek veya mevcut yapıyı değiştirmek URL değişikliği içeriyorsa geçişi web sitesi taşırken SEO kaybını önleme adımlarıyla planlayın. Mimari kararın ve uygulamanın birlikte ele alınması gereken projelerde çok dilli ve çok bölgeli web siteleri çalışmasına bu kontrol listesiyle başlıyoruz.

Sık sorulan sorular

Çok dilli sitede alt dizin mi alt alan adı mı daha iyi?

Tek ekip tarafından yönetilen, aynı altyapıda çalışan kurumsal sitelerde alt dizin genellikle en düşük işletim maliyetini sunar ve alan adının mevcut otoritesini paylaşır. Diller ayrı ekipler, ayrı altyapı veya ayrı yayın takvimiyle yönetilecekse alt alan adı daha uygun olabilir.

ccTLD kullanmak yerel SEO için şart mı?

Şart değil. ccTLD güçlü bir ülke sinyali verir ama her ülke için ayrı alan adı, sertifika, DNS ve otorite yönetimi gerektirir. Hedefleme hreflang ve yerelleştirilmiş içerikle de yapılabilir; ccTLD daha çok ülke bazında ayrı tüzel yapı ve operasyon olduğunda anlamlıdır.

Ziyaretçiyi tarayıcı diline göre otomatik yönlendirmek doğru mu?

Zorunlu otomatik yönlendirme önerilmez. Arama motoru tarayıcıları dil sürümlerine erişemeyebilir, kullanıcı da istediği sürümde kalamaz. Daha güvenli yol, uygun dili öneren kapatılabilir bir bilgi çubuğu ve her sayfada görünür bir dil seçicidir.

Çevirisi olmayan sayfalar ne yapılmalı?

Yazılı bir politika gerekir: sayfa o dilde hiç yayınlanmaz ve dil seçici ilgili dilin ana sayfasına yönlendirir ya da sayfa yalnız çevirisi tamamlandığında yayına alınır. Kaynak dildeki metni çeviri yerine yayınlamak kullanıcı deneyimini ve hreflang tutarlılığını bozar.