Çok Dilli Sitelerde Dil Seçici SEO Etkisi ve Doğru Kurulum

Çok dilli sitelerde dil seçici SEO etkisi gerçekten nerede oluşur?

Çok dilli sitelerde dil seçici SEO etkisi, butonun veya dropdown bileşeninin kendisinde değil; onun bağlandığı URL mimarisinde, linklerin keşfedilebilir olup olmamasında ve hreflang ilişkisinin doğru kurulup kurulmadığında oluşur. Google Search Central, çok dilli sürümler için ayrı URL ve açık işaretleme kullanılmasını önerir; bu da meselenin tasarım değil teknik kurgu problemi olduğunu gösterir (Google Search Central, 2025-12-10).

Pratikte üç yaygın model görürüz: header içindeki dil dropdown’ı, ayrı bir x-default seçim ekranı ve otomatik yönlendirme. İlk iki model, kullanıcıya ve botlara alternatif sürümlere açık erişim bıraktığı sürece genelde yönetilebilir yapıdadır. Sorun en çok, dil seçicinin görünen arayüzde var olup HTML içinde link üretmemesi ya da kullanıcıyı doğrudan başka URL’ye zorlamasıyla başlar.

Başarıyı ölçmek için yalnızca sıralamaya bakmak eksik kalır. Doğru metrik seti şunlardır: ilgili dil URL’sinin indekslenmesi, arama sonucunda doğru sürümün gösterilmesi, kullanıcıların yanlış dilde açılan sayfadan geri dönmemesi ve tarama bütçesinin aynı içeriğin yanlış varyasyonlarında boşa harcanmaması. Yani dil seçici, SEO’ya ancak bu teknik ve davranışsal katmanlar üzerinden dokunur.

• Header dropdown: HTML linkleri doğruysa esnek ve kullanıcı dostudur.
• x-default seçim sayfası: Uluslararası giriş URL’si için daha kontrollü sinyal verir.
• Otomatik yönlendirme: Keşif, paylaşılabilirlik ve bot erişimi tarafında en dikkatli uygulanması gereken modeldir.

Alt klasör, alt alan adı ve x-default kararı nasıl verilir?

2026’da hâlâ en güvenli yaklaşım, her dil veya ülke sürümünü ayrı ve indekslenebilir URL’de sunmaktır. Google’ın yerelleştirilmiş sayfa rehberi, tüm varyasyonların birbirini açıkça işaretlemesini ve gerektiğinde x-default kullanılmasını öneriyor (Google Search Central, 2025-12-22). Bu nedenle dil seçici tasarımını konuşmadan önce önce şu kararı verin: /tr/, /en/, /de/ gibi alt klasör mü; en.example.com gibi alt alan adı mı; yoksa ülke odaklı ccTLD mi?

Küçük ve orta ölçekli ekiplerde alt klasör modeli çoğu zaman operasyonel olarak en temiz başlangıçtır. Aynı host üzerinde kalırsınız, teknik bakım azalır, içerik ekipleri tek CMS akışında çalışır. Alt alan adı veya ccTLD ise ayrı ekip, ayrı sunucu, ayrı hukuk veya ayrı marka yapılanması olduğunda anlamlıdır. Burada kritik nokta, “hangisi teoride daha güçlü” sorusundan çok, hangi yapının uzun süre tutarlı biçimde sürdürülebileceğidir.

x-default kararı da aynı mantıkla verilir. Eğer example.com gibi bir giriş URL’niz kullanıcıyı dil seçmeye davet eden nötr bir sayfaysa, x-default’i bu URL’ye vermek mantıklıdır. Eğer ayrı seçim ekranı yok ve ana URL zaten belirli bir dile hizmet ediyorsa, x-default’i zorla kullanmak yerine dil kümelerini sade tutmak daha doğrudur. x-default, “her sayfada bulunması gereken zorunlu etiket” değil; varsayılan giriş mantığını açıklayan bir sinyaldir.

Bir diğer kritik konu, aynı çeviriyi farklı ülke sürümlerine kopyalayıp yalnızca para birimini değiştirmekle yetinmemektir. en-GB ile en-US aynı dili paylaşsa da arama niyeti, teslimat bilgisi, yasal metinler ve ticari terimler farklılaşabilir. Bu yüzden slug ve içerik farkını veriyle desteklemek gerekir; burada bir anahtar kelime aracı ile yerel sorgu kalıplarını görmek, dil seçici kararını da daha doğru URL yapısına bağlar.

• Alt klasör: düşük bakım, hızlı yayın, çoğu ekip için pratik başlangıç.
• Alt alan adı: ekip ve altyapı ayrışıyorsa mantıklı.
• ccTLD: güçlü ülke sinyali verir ama maliyet ve bakım yükü yükselir.

Otomatik yönlendirme ve JavaScript dil seçici ne zaman risklidir?

Google Search Central, kullanıcıyı tahmini dile göre otomatik olarak başka sürüme göndermemeyi açık biçimde önerir. Sebep basit: botlar ve kullanıcılar tüm varyasyonlara erişemeyebilir, ayrıca Googlebot çoğu istekte Accept-Language başlığı olmadan tarama yapabilir (Google Search Central, 2025-12-10). Bu yüzden IP veya tarayıcı dili sinyalini “zorunlu redirect” değil, “öneri katmanı” olarak kullanmak daha güvenlidir.

Locale-adaptive sayfalar özellikle dikkat ister. Google’ın bu konuya ayrılmış dokümanı, aynı URL’nin kullanıcının konumuna veya diline göre farklı içerik göstermesinin ek tarama ve yorumlama riski taşıdığını söylüyor (Google Search Central, 2025-12-10). Tek URL üzerinde dil değiştiren yapılar, paylaşılabilirlik ve hata ayıklama açısından da zordur; bir kullanıcıya doğru görünen deneyim, bot için eksik varyasyon keşfine dönüşebilir.

JavaScript dil seçici ise tek başına kötü değildir; sorun, yalnızca click event ile çalışan ve kaynak HTML’de erişilebilir link üretmeyen yapılarda çıkar. Kullanıcı dropdown’a tıklayınca sayfa değişiyor olabilir; fakat bot ilk HTML’de /en/ veya /de/ linklerini görmüyorsa keşif tamamen render sürecine kalır. Özellikle zayıf iç linkleme, SPA benzeri kurgu veya geç yüklenen menüler olduğunda bu gecikme, dil sürümlerinin yetim kalmasına neden olabilir.

Dil seçici sayfasında noindex, canonical ve yönlendirme kararı da birlikte düşünülmelidir. Ayrı bir seçim ekranı gerçekten yalnızca geçiş amacı taşıyorsa, ana dil sayfalarını canonical hedef yapmadan noindex vermek mantıklı olabilir. Buna karşılık seçim ekranı x-default görevi de görüyorsa, onu görünmez hâle getirmek yerine kullanıcı ve bot için erişilebilir bir giriş sayfası olarak tasarlamak daha sağlıklıdır. Buradaki hata, tek bir kuralı bütün mimarilere kopyalamaktır.

• Riskli: IP tabanlı zorunlu yönlendirme, tek URL’de dil değiştirme, sadece JS event’i.
• Daha güvenli: ayrı URL, HTML içinde açık link, yönlendirme yerine öneri banner’ı.
• Kontrol noktası: kaynak HTML’de dil sürümlerine giden linkler gerçekten var mı?

8 haftalık saha karşılaştırması: header dropdown, x-default sayfa ve otomatik yönlendirme

Son çok dilli geçiş projelerinde aynı bilgi mimarisi üzerinde izlediğimiz örneklerde en stabil sonuç, x-default seçim sayfası + ayrı dil URL’leri kombinasyonunda geldi. Bu modelde indeks kümesi daha öngörülebilir kaldı, yanlış ülke sürümünün sonuçlarda görünmesi daha az tekrarlandı ve QA süreci ekipler arasında daha kolay paylaşıldı. Header dropdown da iyi çalıştı; fakat bu model, sitewide linklerin ve hreflang setinin eksiksiz kurulmasına daha fazla bağımlıydı.

Otomatik yönlendirme tarafında ise tipik sorun sıralama kaybından önce teşhis zorluğu oluyor. Search Console’da URL doğru görünebilir, fakat kullanıcı farklı ülkeden geldiğinde paylaşılan link başka sürüme düşer; ekip de sorunu geç fark eder. Özellikle çok dilli e-ticaret sitelerinde dil ile para birimi aynı mantıkta kurgulanmadığında, kullanıcı hem yanlış içerik tonu hem yanlış ticari bağlamla karşılaşır. Bu da SEO ve dönüşüm tarafında ayrı ayrı sürtünme üretir.

Bizim sahada tekrar gördüğümüz pratik sonuç şu: dil seçicinin kendisi nadiren ana problem olur; asıl problem, seçicinin arkasında tek URL’ye yığılmış içerik, eksik return tag, kararsız canonical ve yetersiz iç linkleme olmasıdır. Bu nedenle performansı izlerken yalnızca organik tıklamayı değil, ülke bazlı doğru açılış URL’sini, indeks kapsamasını ve geçiş oranını birlikte okumak gerekir. Bu okumayı düzenli sıralama takibi verisiyle eşlemek, hangi modelin görünürlükte daha az sürtünme yarattığını daha net gösterir.

• Header dropdown: doğru link ve hreflang varsa iyi çalışır.
• x-default sayfa: uluslararası giriş mantığında en temiz kontrol alanını sunar.
• Otomatik yönlendirme: tanı koyması zor, yanlış sürüm gösterimini artırmaya açık yapıdadır.

Kurulum sonrası QA checklist: Search Console, log analizi ve site audit

Kurulum bittiğinde işin zor kısmı başlar: doğrulama. İlk kontrol, hreflang kümelerinin karşılıklı kurulup kurulmadığıdır. Google rehberi, tüm varyasyonların birbirini işaretlemesini ve gerektiğinde x-default ile tamamlanmasını öneriyor; Screaming Frog ise audit sırasında missing return links, non-canonical hreflang ve noindex dönüş sayfalarının özellikle ayrıştırılması gerektiğini gösteriyor (Google Search Central, 2025-12-22; Screaming Frog, 2026).

İkinci adım, Search Console URL Denetleme üzerinden örnek URL’leri tek tek görmek olmalı. Doğru canonical seçilmiş mi, render edilmiş HTML içinde alternate işaretleri duruyor mu, Google seçtiğiniz dili gerçekten bu sayfa için anlıyor mu? Üçüncü adım ise log analizi: Googlebot hangi ülke ve dil klasörlerini ne sıklıkta tarıyor, bot gereksiz redirect zincirine mi giriyor, bazı dil sürümleri hiç ziyaret almıyor mu? Bu sorular, yalnızca crawl çıktısına bakarak değil ham istek davranışına bakarak yanıtlanır.

Düzenli teknik ekip akışında bu kontrollerin tek panelde toplanması önemlidir. Ahrefs veya SEMrush gibi global araçlar görünürlük tarafında faydalı olabilir; SEOYEN ise site audit, sıralama takibi, Türkçe arayüz ve yerel destek avantajını aynı operasyon akışında birleştirerek Türkiye ekipleri için daha pratik bir çalışma zemini sunar. Güncel plan yapısını görmek isteyen ekipler için paket detayları sayfası yeterlidir; önemli olan, QA sürecinin araçlar arasında dağılmadan sürdürülebilmesidir.

• Hreflang setlerinde self reference ve return tag kontrolü yapın.
• Canonical işaretlerinin her dil sürümünde kendi URL’sine döndüğünü doğrulayın.
• XML sitemap içinde tüm indekslenebilir dil URL’lerini ayrı ayrı listeleyin.
• Rendered HTML ve kaynak HTML’de dil linklerinin erişilebilir olduğunu kontrol edin.
• Log analizinde botun redirect, 404 ve yetim dil URL’lerine düşüp düşmediğine bakın.

Adım Adım Çok dilli sitede SEO dostu dil seçici kurma

Kurulumu sıfırdan yaparken en iyi sonuç, arayüz kararını en sona bırakıp önce bilgi mimarisini netleştirmekle gelir. Aşağıdaki akış, hem küçük işletmeler hem çok dilli büyüyen ekipler için gereksiz karmaşayı azaltır.

1. Dil ve ülke varyasyonlarını haritalayın. Her sürümün gerçekten farklı bir arama niyeti taşıyıp taşımadığını belirleyin. tr-TR, en-US ve en-GB gibi ayrımlar yalnızca çeviri farkı değil; teslimat, ödeme, mevzuat ve kelime seçimi farkı da taşıyorsa ayrı URL açın.
2. Ayrı indekslenebilir URL yapısını seçin. Alt klasör, alt alan adı veya ccTLD kararını ekip yapısı, CMS sınırları ve bakım kapasitesine göre verin. Burada mükemmel teoriden çok sürdürülebilir operasyon önemlidir.
3. hreflang ve x-default kümelerini kurun. Her sürüm karşılıklı işaretlenmeli, canonical ile çelişmemeli ve varsayılan giriş mantığı varsa x-default ile desteklenmelidir. Eksik ya da tek yönlü kurulum en sık görülen hata sınıfıdır.
4. Crawl edilebilir dil seçici bağlantıları ekleyin. Header, footer veya seçim ekranındaki linkler gerçek URL’lere gitmeli. Sadece script çalışınca görünen geçişler yerine, botun HTML’de görebildiği bağlantılar kullanın.
5. Otomatik yönlendirmeleri sınırlandırın. IP veya tarayıcı dili sinyali kullanılabilir; fakat bunu zorunlu redirect yerine öneri katmanı olarak tasarlayın. Kullanıcıya ve botlara tüm sürümlere erişim bırakın.
6. Search Console ve site audit ile doğrulayın. Yayın sonrası birkaç örnek URL’ye bakmak yetmez. URL Denetleme, rendered HTML kontrolü, log analizi ve düzenli tarama birlikte yürütülmelidir.

Sıkça Sorulan Sorular