Blog'a Dön
Teknik SEO

Çok Dilli GEO: hreflang ve Uluslararası Görünürlük

29 Ağustos 2026
Next GEO Agency
Çok Dilli GEO: hreflang ve Uluslararası Görünürlük

Bir kliniğin sitesinde sağ üstte TR/EN düğmesi duruyor. Tıklıyorsunuz: sayfa yenilenmiyor, adres çubuğunda tek bir karakter bile değişmiyor, metinler yerinde İngilizceye dönüyor. Site iki dilli görünüyor. Search Console'da ise tek dil var. ChatGPT'ye İngilizce sorulduğunda o klinik hiçbir yanıtta geçmiyor.

Burada bir çeviri sorunu yok. İngilizce metinler yazılmış, düzgün, yerinde duruyor. Sorun şu: o metinlerin bir adresi yok. Arama motoru da yapay zeka asistanı da bir sayfayı URL ile tanır, URL ile indeksler, URL ile alıntılar. Adresi olmayan içerik, klasörde var ama dizinde yok demektir.

Bu ayrımı bir cümleye sığdırmak gerekirse: iki dilde içerik üretmek ile iki dilde görünür olmak aynı iş değildir. İkincisi teknik bir kurulumdur ve atlanırsa üretilen bütün ikinci dil içeriği pratikte hiç yazılmamış gibi davranılır. Dürüst olmak gerekirse bu yazıyı yayınladığımız sitenin kendisi de şu an bu durumda: TR ve EN aynı adreste yaşıyor, dil tercihi tarayıcıda saklanıyor ve bu, kendi yapılacaklar listemizde açık bir madde olarak duruyor.

Tek URL'de iki dil tutmanın somut bedeli

Dil seçimi istemci tarafında — localStorage, çerez ya da JavaScript ile — tutuluyorsa, siteyi ziyaret eden her otomatik istemci sayfanın varsayılan sürümünü görür. Tarayıcı düğmeye basınca dili değiştirir; tarayıcı olmayan hiçbir şey basmaz.

Bunun sonuçları soyut değil, tek tek sayılabilir:

  • Sitemap'e koyacak adres yoktur. İkinci dilin URL'i olmadığı için sitemap tek dilde kalır. Gönderilen URL sayısı ile gerçekte var olan içerik miktarı arasındaki fark burada kaybolur.
  • hreflang kurulamaz. hreflang iki URL arasında kurulan bir bağdır. İkinci URL yoksa bağın öteki ucu da yoktur.
  • İkinci dil hiç otorite biriktirmez. Paylaşılan her bağlantı, gelen her dış link tek adrese gider. İngilizce sayfanız için ayrı bir link profili hiç oluşmaz.
  • Modelin alıntılayacağı bir hedef yoktur. Yapay zeka yanıtlarındaki kaynak listesi bir URL listesidir. Alıntılanmak istiyorsanız alıntılanabilecek bir adres vermek zorundasınız.
  • Ölçüm kapalıdır. Search Console'da hangi dilin hangi sorguda çıktığını göremezsiniz, çünkü motorun gözünde tek bir sayfa vardır.

Sunucu tarafında çalışan bir dil anahtarı — yani adresi gerçekten değiştiren bir kurulum — bu maddelerin tamamını tek hamlede çözer. Mesele çeviri bütçesi değil, adresleme kararıdır.

Ayrı URL yapısı: üç seçenek ve taşıma maliyeti

Üç yaygın yapı var ve seçim, çoğu zaman sanıldığından daha az teknik, daha çok organizasyoneldir.

YapıÖrnekNe zaman doğruDikkat
Alt dizinsite.com/en/Küçük ve orta ölçekli sitelerin büyük çoğunluğuTek altyapı, tek yönetim; ana alan adının biriktirdiği güven paylaşılır
Alt alan adıen.site.comİkinci dil ayrı bir sistemde ya da ayrı bir ekipte yaşıyorsaArama motorları için ayrı bir yerleşim gibi davranabilir; otorite otomatik aktarılmaz
Ayrı alan adısite.deÜlkeye özel tüzel varlık, ayrı marka ya da hukuki zorunluluk varsaEn pahalı seçenek: her domain kendi otoritesini sıfırdan kurar

Küçük bir işletme için pratik cevap genellikle alt dizindir. Kurulumu en ucuz olan, tek bir alan adının biriktirdiği güveni bölmeyen ve geri dönmesi en kolay olan seçenek budur. Altyapı tarafında nelerin hazır olması gerektiğini KOBİ web sitesi için GEO uyumlu altyapı rehberimizde ayrıntılı ele almıştık.

Bir ayrımı baştan netleştirin: dil mi hedefliyorsunuz, ülke mi? /en/ bir dili işaret eder, /en-gb/ dil ve ülkeyi birlikte işaret eder. Ülke kırılımına gerçekten ihtiyacınız yoksa açmayın; her yeni kırılım, bakımı ve güncellenmesi gereken yeni bir sayfa kümesi demektir.

Taşıma maliyeti kalemi de gözden kaçmasın. Var olan bir yapıyı değiştiriyorsanız eski adreslerden yenilerine kalıcı yönlendirme kurmanız, iç bağlantıları güncellemeniz ve sitemap'i yeniden üretmeniz gerekir. Yönlendirmeyi atlarsanız daha önce indekslenmiş adresler kırılır; kazanmak için yaptığınız değişiklik elinizdekini kaybettirir.

hreflang nasıl kurulur, nerede kırılır

hreflang, "bu sayfanın şu dildeki karşılığı şurada" diyen bir işarettir. Üç yerden verilebilir: sayfanın <head> bölümü, XML sitemap ya da HTTP başlığı. HTML sayfalar için <head> en yaygın ve en kolay denetlenen yoldur.

<link rel="alternate" hreflang="tr" href="https://site.com/hizmetler/" />
<link rel="alternate" hreflang="en" href="https://site.com/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/" />

Kurulumun üç şartı var:

Karşılıklılık. Türkçe sayfa İngilizceyi gösteriyorsa, İngilizce sayfa da Türkçeyi göstermek zorundadır. Tek yönlü bağ genellikle tümüyle yok sayılır — yani etiket dosyada durur ama hiçbir işe yaramaz. Bu, en sık karşılaşılan sessiz hatadır.

Kendini de listeleme. Her sayfa, kendi dilindeki kendisini de hreflang listesine yazar. Üç dilli bir sayfa kümesinde her sayfada üç satır bulunur, iki değil.

x-default. Tanımlı dillerden hiçbirine uymayan bir kullanıcı geldiğinde nereye gitsin? Cevabı buraya yazarsınız: ya bir dil seçim sayfası ya da ana pazarınızın sayfası. Zorunlu değildir ama boş bırakırsanız kararı tamamen motora bırakmış olursunuz.

canonical ile ilişkisi ayrı bir başlık hak ediyor, çünkü buradaki hata ölümcül. hreflang, canonical'ı ezmez. Her dil sürümü kendi kendisini canonical göstermelidir. /en/services/ sayfasının canonical'ı Türkçe sayfayı işaret ediyorsa, siz motora "bu sayfayı indeksleme, aslı şurada" demiş olursunuz. İngilizce sürüm bu durumda hiç indekslenmez ve kimse nedenini anlamaz.

Kalan sık hatalar kısa liste halinde: dil kodunu yanlış biçimde yazmak (tr_TR değil, tr-TR), ülke kodunu dil kodu sanmak, göreli adres vermek (mutlak URL şart), yönlendirme yapan ya da 404 dönen bir adrese işaret etmek, noindex taşıyan bir sayfayı alternatif olarak göstermek.

Çeviri ile yerelleştirme aynı iş değil

Metni başka bir dile çevirmek, o dildeki kullanıcının sorusuna cevap vermekle aynı şey değildir. Aradaki farkı beş kalemde görebilirsiniz:

  • Para birimi ve fiyat gösterimi. Sayıyı çevirmek yetmez; o pazarda fiyatın vergiyle mi vergisiz mi yazıldığı, hangi para biriminin beklendiği, ondalık ayracın ne olduğu değişir.
  • Mevzuat ve uyum dili. KVKK'ya yapılan bir atıf İngilizce sayfada karşılığını bulmaz; oradaki okuyucu GDPR bekler. Yanlış mevzuata atıf, güveni metnin geri kalanından hızlı tüketir.
  • Örnekler ve vakalar. Yerel bir şehir, yerel bir sektör ya da yerel bir kurum üzerinden anlatılan örnek, çevrildiğinde bağlamını kaybeder.
  • İletişim bilgisi. Telefon formatı, saat dilimi, çalışma saatleri, tercih edilen kanal. Bir pazarda WhatsApp normalken diğerinde e-posta beklenir.
  • Sosyal kanıt. Türkçe yorumlar İngilizce sayfada ikna etmez. O dilde yazılmış, o pazardan gelen referans gerekir.

Makine çevirisinin yetmediği yer tam olarak burasıdır — ve dilbilgisi değil, niyet. İnsanlar farklı dillerde farklı soru sorar. Aynı hizmet için Türkçe arama fiyat ve konum etrafında dönerken, yurt dışından gelen arama süreç, konaklama ve garanti etrafında döner. Metni çevirmek soruyu çevirmez. Bu farkın hizmet ihracatındaki karşılığını sağlık turizminde GEO yazımızda somut sayfa yapılarıyla ele almıştık.

Makine çevirisi bir başlangıç taslağı olarak kullanılabilir. Yayına giden sürümün o dili konuşan biri tarafından gözden geçirilmesi, özellikle terminoloji ve iddia cümleleri için gerekir.

Modeller Türkçe soruda neden İngilizce kaynağa kayıyor

Bu bir gözlem; ölçülmüş bir oran vermiyoruz, çünkü elimizde böyle bir ölçüm yok. Ancak teknik ve niş konularda Türkçe sorulan sorulara verilen yanıtların kaynak listesinde sık sık İngilizce sayfalar görünüyor. Cevap Türkçe geliyor, dayanağı İngilizce oluyor.

Nedeni şaşırtıcı değil: bu konularda İngilizce kaynak hacmi çok daha büyük, çok daha eski ve birbirine daha sıkı bağlı. Türkçe tarafta bir kavramın net tanımını veren, kendi başına ayakta duran sayfa sayısı görece az. Model, elindeki en iyi dayanağı seçer; dil eşleşmesi ikinci sıradadır.

Bunun operasyonel karşılığı bir fırsattır. Rekabetin ince olduğu yer, nitelikli Türkçe içeriktir. Kavramı Türkçe tanımlayan, terimin İngilizce karşılığını da parantez içinde veren, kendi başına alıntılanabilir bir paragrafla açan bir sayfa, aynı konudaki onuncu İngilizce sayfadan daha kolay öne çıkar. Terimin iki dildeki karşılığını aynı sayfada vermek ayrıca varlık eşleşmesine yardım eder: model "generative engine optimization" ile "üretken arama motoru optimizasyonu" ifadelerini aynı şeye bağlayabilir.

Bu yaklaşımın konu bazında nasıl kurgulanacağını semantik içerik stratejisi ve konu kümesi yazımızda anlattık.

Sınırını da yazalım: bu eğilim konuya, motora ve sorunun ne kadar yerel olduğuna göre değişir. Yerel hizmet sorgularında tablo tersine dönebilir. Kendi konunuzda ne olduğunu görmek için elle birkaç soru sormak, herhangi bir tahminden daha güvenilirdir.

Hangi sayfalar çevrilmeye değer

Hepsi değmez. Karar ölçütü tek bir soruya indirgenebilir: o dilde gelen bir talebi karşılayabiliyor musunuz? Cevap hayırsa çeviri, cevaplayamayacağınız aramalar üretir.

Öncelik sırası şöyle işler:

  1. Ana sayfa ve tek bir çekirdek hizmet sayfası. İkinci dilin ilk sınavı budur.
  2. İletişim ve teklif sayfası. Talep gelecekse ineceği yer burasıdır; çevrilmemiş bir form bütün zinciri keser.
  3. En çok soru alan üç hizmet. Hangileri olduğunu tahmin etmeyin; gelen e-posta ve mesajlara bakın.
  4. Süreç ve fiyatlandırma mantığını anlatan sayfa. Yurt dışından gelen talebin en çok takıldığı yer belirsizliktir.
  5. Blog — en sonda ve seçerek. Tamamını değil, o pazarın gerçekten sorduğu üç beş konuyu.

Çevrilmemesi gerekenler de var: yerel mevzuata özel yazılar, yerel etkinlik ve haber duyuruları, yalnızca Türkiye'de geçerli kampanyalar, şehir bazlı yerel hizmet sayfaları. Bunları çevirmek ikinci dilde alakasız bir yığın oluşturur.

Bir uyarı: yarım çeviri en kötü seçenektir. Menüsü İngilizce, içeriği Türkçe açılan bir sayfa hem kullanıcıyı hem de motoru yanıltır. Beş sayfayı eksiksiz çevirmek, elli sayfayı yarım çevirmekten iyidir. Ürün sayfalarında bunun nasıl çalıştığını e-ticaret için GEO yazımızda ayrıntılandırdık.

İki dilde tek işletme: varlık tutarlılığı

Çok dilli sitelerde en sinsi hata, aynı işletmenin iki ayrı varlık gibi görünmesidir. Bu, hiçbir hata mesajı vermez; sadece iki zayıf profil oluşur, bir güçlü profil yerine.

Dikkat edilecek noktalar:

  • Yasal ad çevrilmez. "Yıldız Diş Kliniği" İngilizce sayfada "Yildiz Dental Clinic" olarak yazılırsa ortada iki isim vardır. Doğru yol, yasal adı sabit tutup açıklayıcı kısmı parantezle vermektir.
  • Şema kimliği ortak olmalı. Organization şemasında her iki dil sürümü aynı @id değerini kullanmalıdır. Bu, iki sayfanın aynı varlığı anlattığını açıkça söyler.
  • sameAs listesi aynı olmalı. Sosyal profiller, harita kaydı, sektör dizinleri — her iki dilde aynı bağlantılar.
  • Adres ve telefon aynı biçimde. Uluslararası formatta yazın ve iki dilde birebir aynı tutun.
  • Kuruluş yılı, logo, vergi bilgisi gibi sabit veriler iki sürümde çelişmemeli.

Bu katmanın kurulumu ve şema tarafı, sunduğumuz GEO çözümlerinin standart parçasıdır.

Küçük bir siteyle uygulama sırası

On sayfalık bir site için makul bir yol haritası:

  1. Kararı verin: ikinci dilde gerçekten iş yapıyor musunuz? Hayırsa buraya kadar.
  2. Alt dizin seçin (/en/) ve sunucu tarafında çalışan bir yapı kurun.
  3. Beş sayfayla başlayın: ana sayfa, bir hizmet, iletişim, hakkımızda, süreç.
  4. Her sayfaya kalıcı URL ve kendini gösteren canonical verin.
  5. hreflang bağlarını karşılıklı kurun, x-default ekleyin.
  6. Sitemap'i yeniden üretin; iki dilin tüm adresleri içinde olsun.
  7. Dil düğmesini gerçek bağlantıya çevirin — hedefi aynı sayfanın karşılığı olsun, ana sayfa değil.
  8. Otomatik dil yönlendirmesi kurmayın. IP ya da tarayıcı diline göre zorunlu yönlendirme, tarayıcıları tek sürüme hapseder ve diğerini görünmez yapar. Öneride bulunun, zorlamayın.
  9. Şema @id'sini ortaklaştırın.
  10. 60-90 gün ölçün: Search Console'da dil kırılımı, birkaç asistanda elle sorulan sorular. Sonra genişletin.

Bu adımlar görünürlüğü garanti etmez. Yaptıkları şey daha temel: ikinci dildeki içeriğinizin görünme ihtimalinin önündeki yapısal engeli kaldırmak. İçeriğin kendisi iyi değilse ayrı URL de hreflang de bir işe yaramaz — ama içerik iyiyken bu kurulum yoksa, iyi olduğunu kimse öğrenemez.

Sıkça Sorulan Sorular

İki dili aynı URL'de tutmak arama görünürlüğü açısından gerçekten sorun mu?

Evet, ve sorun teknik olarak nettir. Arama motorları ve yapay zeka asistanları bir içeriği URL üzerinden tanır, indeksler ve alıntılar. Dil seçimi tarayıcıda saklanıyor ve adres değişmiyorsa, otomatik istemciler her ziyarette yalnızca varsayılan dili görür. Bu durumda ikinci dil için sitemap'e girecek adres, hreflang ile bağlanacak hedef ve yanıtlarda gösterilecek bir kaynak bağlantısı oluşmaz. İçerik yazılmıştır ama dizin dışındadır.

Alt dizin mi, alt alan adı mı, ayrı alan adı mı seçmeliyim?

Küçük ve orta ölçekli siteler için pratik cevap genellikle alt dizindir; örneğin site.com/en/ biçiminde. Tek altyapıyla yönetilir, ana alan adının biriktirdiği güveni bölmez ve geri alınması en kolay seçenektir. Alt alan adı, ikinci dil ayrı bir sistemde veya ayrı bir ekipte yaşıyorsa anlamlıdır. Ayrı alan adı ise ülkeye özel tüzel varlık, ayrı marka veya hukuki zorunluluk gibi gerekçeler varsa tercih edilir ve her yeni alan adı kendi otoritesini sıfırdan kurmak zorunda olduğu için en pahalı seçenektir.

hreflang etiketlerini ekledim ama hiçbir şey değişmedi, neden?

En sık üç nedenden biri geçerlidir. Birincisi karşılıklılık eksikliğidir: Türkçe sayfa İngilizceyi gösteriyor ama İngilizce sayfa Türkçeyi göstermiyorsa bağ genellikle tümüyle yok sayılır. İkincisi canonical çakışmasıdır: İngilizce sayfanın canonical etiketi Türkçe sayfayı işaret ediyorsa, motora o sayfayı indekslememesini söylemiş olursunuz. Üçüncüsü hedef adresin geçersiz olmasıdır; yönlendirme yapan, 404 dönen veya noindex taşıyan bir adres alternatif olarak kabul edilmez. Ayrıca adreslerin mutlak yazılması ve dil kodlarının tire ile ayrılması gerekir.

Sayfaları makine çevirisiyle çevirmek zararlı mı?

Doğrudan zararlı değildir, ancak tek başına yeterli olmadığı yerler bellidir. Makine çevirisi dilbilgisini taşır, niyeti taşımaz: insanlar farklı dillerde aynı hizmet için farklı sorular sorar, farklı bilgileri önemser ve farklı kanıt bekler. Para birimi, mevzuat atıfları, iletişim biçimi, örnekler ve sosyal kanıt çeviriyle değil yerelleştirmeyle çözülür. Pratik yaklaşım, makine çevirisini taslak olarak kullanıp yayına giden sürümü o dili konuşan biriyle gözden geçirmek, özellikle terminoloji ve iddia içeren cümleleri elden geçirmektir.

Sitenin tamamını ikinci dile çevirmek şart mı?

Şart değildir ve çoğu durumda doğru da değildir. Karar ölçütü şudur: o dilde gelen bir talebi gerçekten karşılayabiliyor musunuz? Karşılayamayacağınız alanları çevirmek cevaplanamayan aramalar üretir. Makul sıra ana sayfa, tek bir çekirdek hizmet sayfası, iletişim ve teklif sayfası, en çok soru alan birkaç hizmet ve süreç bilgisidir; blog en sonda ve seçilerek gelir. Yerel mevzuat yazıları, yerel kampanyalar ve şehir bazlı sayfalar genellikle çevrilmemelidir. En kötü seçenek yarım çeviridir: beş sayfayı eksiksiz çevirmek, elli sayfayı yarım çevirmekten daha iyi sonuç verir.