Çok Dilli Site Nasıl Kurulur? Yapı, Dil ve Akış Kararları

Çok dilli site kurulum sürecini temsil eden editoryal blog görseli

Bir ekip yeni pazarlara açılmaya karar verdiğinde genellikle aynı anda üç ayrı soru masaya gelir: Hangi diller eklenecek, içerikler nasıl çevrilecek, alan yapısı nasıl kurulacak?

Soruların hepsi doğru ama sıralama çoğu zaman terstir.

Çeviriye erkenden başlamak cazip görünür; oysa bilgi mimarisi kararı netleşmeden yazılan her içerik sonradan yeniden düzenlenebilir. Sağlam kurulum, yayın öncesinde verilen birkaç açık karara dayanır: varsayılan dil ne olacak, her dil için aynı içerik seti zorunlu mu, kullanıcı dili nasıl değiştirecek, içerik eşleştirme nasıl tutulacak, teknik ekip hangi URL sistemini yönetecek? Tek doğru yok. Fakat belirsiz bırakılan her alan maliyeti büyütür.

Çok dilli SEO mantığı oturmadan site kurulumu yapmak, duvarı boyayıp odaların yerini sonra değiştirmeye benzer. Görsel olarak tamamlanmış hissi verir; kullanım başladığında sorunlar görünür hale gelir.

Projeye başlamadan önce karar matrisi kurulur

İlk aşamada yapılacak en değerli iş, dil ve pazar matrisini oluşturmaktır.

Her satır bir hedef dil veya bölgeyi, her sütun ise kritik karar alanlarını içermelidir: URL kalıbı, içerik kapsamı, sorumlu ekip, öncelikli sayfalar, yerelleştirme ihtiyacı, teknik notlar. Matris olmadan ekipler aynı şeyi farklı isimlerle konuşur. İçerik ekibi İngilizce sürüm der, geliştirici /en/ klasörünü düşünür, SEO ekibi ise İngiltere ile küresel İngilizceyi ayırmayı planlar.

Hepsi kısmen haklıdır.

Ama aynı tabloda buluşmadıklarında site kurulum süreci dağılır.

  • Hangi diller ilk fazda açılacak?
  • Her dilde hangi sayfa tipleri zorunlu olacak?
  • Hangi sayfalar bire bir eşleşecek, hangileri pazara göre değişecek?
  • Varsayılan giriş noktası nasıl davranacak?
  • Yerel yasal metinler ve destek içerikleri hangi düzeyde uyarlanacak?

Kısa bir toplantıyla geçiştirilen bu bölüm, ileride haftalar kazandırır.

Proje yönetimini teknik ayrıntı değil, karar netliği hızlandırır.

Bilgi mimarisi: kök yapı mı, alt dizin mi, alt domain mi?

En görünür karar URL mimarisidir.

Pek çok proje için dil bazlı alt dizinler yönetilebilir bir başlangıç sunar. Tek alan altında kalmak analitik, bağlantı gücü ve bakım açısından sadelik sağlar. Yine de bu, her senaryoda tek seçenek olduğu anlamına gelmez.

Ekipler ayrı pazarlarda bağımsız yayın yapıyorsa, sunucu ve kurumsal yapı ayrı işliyorsa alt alan adı yaklaşımı da makul olabilir. Bazı markalar ülke alan adlarını tercih eder; bu ise daha yüksek operasyon disiplini ister. Burada önemli olan "hangi yöntem SEO'da sihirli" sorusu değil, hangi yöntemin kurum içi çalışma biçimiyle uyumlu olduğudur.

Alt dizin ile alt domain karşılaştırması yalnız teknik skor meselesi değildir.

Mimari karar verildiğinde klasör düzeni, medya yolu, kategori yapısı ve iç link kalıpları da kolaylaşır. Tam tersi durumda? Ekip her yeni dilde aynı tartışmayı yeniden yaşar. Bir noktadan sonra bu tekrar, gerçek üretimden daha fazla zaman tüketir.

Dil seçici, varsayılan sayfa ve fallback akışı nasıl çalışmalı?

Kullanıcı siteye ilk geldiğinde hangi sürümü görecek?

Dil seçimi yaptıktan sonra hangi URL'ye gidecek? Eşleşen içerik o dilde henüz yoksa ne olacak? Çok dilli sitelerde kullanıcı akışını bozan sorunların çoğu bu üç soruya önceden cevap verilmemesinden doğar.

Sağlıklı yaklaşımda kullanıcıya açık seçenek sunulur. Zorunlu yönlendirme, özellikle IP veya tarayıcı dili üzerinden yapıldığında, hem kullanıcı kontrolünü kısıtlar hem tarama davranışını zorlaştırabilir. Daha dengeli yöntem; öneri sunmak, ama seçimi kullanıcıya bırakmaktır.

İlgili içerik başka dilde henüz hazır değilse bunu gizlemek yerine açıkça belirtmek daha dürüst bir deneyim üretir.

Fallback mantığı da net olmalıdır. Her eksik sayfada ana sayfaya dönmek yerine ilgili kategori ya da en yakın eşdeğer sayfaya geçmek daha faydalıdır. Kullanıcı, neden yönlendirildiğini anlarsa rahatsızlık azalır. Aksi halde dil seçici bir yardım alanı olmaktan çıkar, kırık bir koridora döner.

Şablon, navigasyon, form ve medya yerelleştirmesi

Çok dilli site yalnızca metin çevrilerek kurulmaz.

Menü isimleri, form alanları, hata mesajları, buton etiketleri, dosya isimleri, alt metinler ve hatta örnek ekran görüntüleri yerelleştirme kapsamına girer. Bir sayfanın gövde içeriği çevrilmiş olsa bile "Submit" yazan düğme, Türkçe form içindeki İngilizce hata mesajı ya da yerel olmayan bir ölçü birimi güveni kırar.

Şablon envanteri çıkarmak işe yarar. Hangi bileşenler her dilde değişecek, hangileri sabit kalacak, hangileri pazara göre uyarlanacak? İçerik ekipleri genellikle blog metnine odaklanır; oysa kullanıcı kararını çoğu zaman mikro metinlerde verir.

Kargo bilgisi, fiyat birimi, teslimat süresi, çağrı düğmesi… küçük alanlar, büyük etki.

Yerelleştirme ile çeviri farkı tam burada görünür hale gelir. Bir sayfanın dili çevrilmiş olabilir; deneyimi hâlâ yerel olmayabilir.

Teknik kurulum: meta, hreflang, sitemap ve iç bağlantılar

Site iskeleti hazır olduğunda teknik katman devreye alınır.

Her dil sürümünün kendi canonical etiketi bulunmalı, alternatif sürümler hreflang ilişkisi ile birbirine bağlanmalıdır. Sitemap üzerinden yönetim tercih ediliyorsa burada da eşleşmeler tutarlı tutulmalıdır.

Meta başlıklar ve açıklamalar her dil için ayrı yazılmalıdır. Tek kalıp şablonu çeviri aracından geçirip tüm sürümlere dağıtmak kısa sürede görünürlüğü bulanıklaştırır.

İç bağlantılar da aynı şekilde önemlidir. Örneğin Almanca blog yazısından İngilizce ürün sayfasına rastgele geçişler vermek, site yapısının mantığını zayıflatır.

Teknik kurulumun amacı daha fazla etiket eklemek değildir; her dil sürümünün kimliğini açık hale getirmektir. Kimlik net olduğunda tarama davranışı da raporlama kalitesi de daha düzenli olur.

Yayına almadan önce son test turu nasıl yapılır?

Çok dilli siteler genellikle yayına çıkana kadar düzgün görünür.

İlk gerçek hata, kullanıcı ya da bot siteyi dolaşmaya başlayınca fark edilir. Yayın öncesi kontrol turu yalnızca görsel kontrolle sınırlı kalmamalıdır.

  1. Her dil sürümünün erişilebilir ve kendi URL'sinde açıldığını doğrulayın.
  2. Dil seçicinin karşılık gelen sayfalara geçtiğini test edin.
  3. Canonical ve hreflang ilişkilerinin örnek kümelerde tutarlı çalıştığını kontrol edin.
  4. Başlık, açıklama, menü, form ve breadcrumb alanlarının gerçekten çevrildiğini gözden geçirin.
  5. Boş kalan sürümler için fallback davranışını kullanıcı tarafında deneyin.

Bu test turu, proje yayına çıkmadan önce yapılan son teknik iş değil; bakım kültürünün ilk provasıdır.

Çok dilli siteler bir kez kurulup bitmez. Her yeni içerik, her yeni kategori, her yeni pazar kararı bu düzenin içinden geçer. İskelet başta temizse büyüme daha sakin ilerler.

Rollout sırası nasıl belirlenir?

Çok dilli sitelerde tüm dilleri aynı gün açmak her zaman en akıllı tercih değildir.

Ekip yeni yapıyı ilk kez deniyorsa, önce sınırlı içerik seti ve az sayıda dil ile pilot yayın yapmak daha güvenli olabilir. Böylece dil seçici, hreflang, yönlendirme ve içerik eşleştirme mantığı gerçek kullanıcı davranışıyla daha erken test edilir.

Rollout sırası belirlenirken üç başlık birlikte düşünülmelidir: ticari öncelik, teknik hazırlık ve içerik hazır olma düzeyi. Yüksek potansiyelli bir pazarda içerik eksikse erken açılış markaya zarar verebilir. Daha küçük ama iyi hazırlanmış bir sürüm ise sistemin güvenli test alanına dönüşebilir.

  1. Önce en olgun içerik kümesini açın.
  2. Ardından aynı şablon mantığıyla ikinci dili devreye alın.
  3. İlk geri bildirimler geldikten sonra daha karmaşık pazarları ekleyin.

Bu sıralama, teknik ekibin yükünü de dengeler. Aynı gün açılan çok sayıda sürümde küçük hataların kaynağını bulmak zorlaşır. Kontrollü rollout ise her adımda neyin işe yaradığını daha görünür kılar.

Canlıya geçiş günü için küçük kontrol seti

Yayın günü yaklaşınca ekipler genellikle görsel son rötuşlara odaklanır.

Oysa çok dilli yapıda asıl kırılgan alanlar arka plandadır. URL eşleşmesi, dil geçişi, yönlendirme davranışı, boş kalan sürümler ve meta alanları bu gün özel kontrol ister. Özellikle tek tek test edilmemiş fallback akışları en sık unutulan noktalardandır.

Pratik bir kontrol seti şunları içerir: her dilde ana sayfa ve en az üç içerik sayfası açılır, seçiciden karşı sürüme geçilir, doğrudan URL erişimi test edilir, canonical ve alternatif sürümler örneklenir, menü ile breadcrumb alanları gözden geçirilir.

Bunlar küçük görünür, ama canlıya çıkış sonrası büyük zaman kaybını önler.

İyi bir açılış günü, kusursuz hissettiren gün değil; risklerin çoğunun önden görülüp sınıflandırıldığı gündür. Çok dilli siteler de en çok bu hazırlık kültüründen beslenir.