Hızlı Cevap
Hreflang etiketi şöyle uygulanır: her dil veya ülke varyantı için benzersiz URL belirlenir, uygun dil-ülke kodları seçilir, sonra bu URL’ler HTML head, XML sitemap veya HTTP header içinde karşılıklı ve self-referencing biçimde tanımlanır. Son adımda canonical, x-default ve indexlenebilirlik sinyalleri birlikte test edilir.
Önemli Noktalar
- Dil kodu tek başına geçerlidir, ülke kodu tek başına geçersizdir.
- HTML, sitemap ve HTTP header aynı amacı taşır, bakım farkı yaratır.
- Self-referencing ve reciprocal etiketler eşleşme kümesini tutarlı hale getirir.
- Canonical, hreflang yerine geçmez; yanlış kombinasyon sıralamayı bozabilir.
- Yayın öncesi crawl ve URL Denetleme Aracı kontrolü hata maliyetini düşürür.
Hreflang ne zaman gerekir, ne zaman gerekmez?
Hreflang, aynı arama niyetini karşılayan sayfaları farklı dil veya bölge sürümlerine ayırdığınızda gerekir. Örneğin Türkiye için Türkçe bir kategori sayfanız, Birleşik Krallık için İngilizce sürümünüz ve ABD için ayrı para birimi, teslimat metni veya teklif farkı taşıyan ikinci bir İngilizce sürümünüz varsa, Google’a bu ilişkinin açıkça anlatılması gerekir. Google Search Central’ın çok dilli ve çok bölgeli site rehberinde 2026 itibarıyla yaklaşım hâlâ aynı: dil hedefleme ile coğrafi hedefleme birlikte ele alınmalıdır (Google Search Central, 2026).
Her çok dilli sitede hreflang zorunlu değildir. Sadece menü veya footer çevrilmiş, asıl içerik aynı URL’de kalmışsa ek etiket katmanı çoğu zaman gereksizdir. Aynı şekilde tek ülkeye hizmet veren, yalnızca birkaç destek içeriğini çevirmiş sitelerde önce URL yapısını netleştirmek gerekir. Ekip içinde temel kavramları ortaklaştırmak için SEO terim sözlüğü gibi bir referans sayfası kullanmak, teknik kararların neden alındığını görünür kılar.
- Gerekir: Aynı içeriğin tr-TR, en-GB ve en-US gibi paralel URL sürümleri varsa.
- Şart değildir: İçerik tek URL’de sabitse ve dil değişimi ayrı indekslenebilir sayfa üretmiyorsa.
- Dikkat gerekir: ccTLD, subdomain ve subfolder yapılarında hreflang mantığı değişmez; yalnız bakım ve ölçek zorluğu değişir.
ccTLD, subdomain ve alt klasör seçimi hreflang ihtiyacını ortadan kaldırmaz. example.com/tr/, tr.example.com veya example.com.tr kullanmanızdan bağımsız olarak, Google’ın yerelleştirilmiş sürümler dokümanına göre kritik nokta her URL’nin alternatif kümesinde doğru ve karşılıklı yer almasıdır (Google Search Central, 2026). Bu yüzden önce bilgi mimarisini seçip sonra hreflang’i onun üstüne inşa etmek, ters sırada ilerlemekten daha temiz sonuç verir.
hreflang etiketi nasıl uygulanır? HTML, sitemap ve HTTP header
Google 2026’da hreflang için üç resmi yöntem göstermeye devam ediyor: HTML head içindeki link rel=”alternate” öğeleri, XML sitemap içindeki alternates kayıtları ve HTML dışı dosyalar için HTTP header yöntemi (Google Search Central, 2026). Temel kural yöntem değil, kümenin eksiksiz olmasıdır. Hangi yolu seçerseniz seçin aynı eşleşmelerin tüm varyantlarda tutarlı biçimde tanımlanması gerekir.
HTML head ile ekleme
Sayfa tabanlı yapılarda en okunabilir kurulum genelde HTML head olur. Basit bir küme şu mantıkla kurulur: <link rel="alternate" hreflang="tr-TR" href="https://ornek.com/tr/urun/" />, <link rel="alternate" hreflang="en-GB" href="https://ornek.com/uk/product/" />, <link rel="alternate" hreflang="en-US" href="https://ornek.com/us/product/" /> ve gerekiyorsa <link rel="alternate" hreflang="x-default" href="https://ornek.com/international/product/" />. Her sayfa kendi kendisini de işaret etmelidir.
XML sitemap ve HTTP header seçimi
On binlerce URL içeren yapılarda sitemap yöntemi daha sürdürülebilir olabilir. Mantık yine aynıdır: her url düğümü kendi alternatiflerini içerir. PDF, katalog veya beyaz bülten gibi head alanı olmayan dosyalarda ise HTTP header tercih edilir; örnek mantık şöyledir: Link: <https://ornek.com/tr/katalog.pdf>; rel="alternate"; hreflang="tr-TR". Cross-domain kurulumlarda da yöntem değişmez; yalnız tüm alan adlarının birbirini karşılıklı tanıması gerekir.
- HTML head: Küçük ve orta ölçekli sayfa kümelerinde görünürlüğü yüksektir.
- XML sitemap: Otomasyon ve merkezî yönetim isteyen büyük yapılarda pratiktir.
- HTTP header: PDF ve benzeri HTML dışı dosyalar için en doğru seçenektir.
Buradaki kritik hata, aynı projede üç yöntemi karıştırırken veri tutarsızlığı üretmektir. Bir URL HTML içinde en-GB görünürken sitemap tarafında en-US kümesine bağlanıyorsa sorun yöntem değil, veri kaynağıdır. Bu yüzden yöntem seçimini geliştirici konforuna göre değil, hangi kaynaktan tek doğru hreflang seti üretebileceğinize göre yapmak daha doğru olur.
Dil ve ülke kodları, x-default ve canonical birlikte nasıl kurgulanır?
Hreflang kurulumunda en sık hata, dil ve ülke kodlarını aynı şey sanmaktır. Google’ın dokümantasyonuna göre dil kodu tek başına geçerli olabilir; ülke kodu ise tek başına kullanılamaz (Google Search Central, 2026). Yani tr geçerlidir, TR tek başına geçerli değildir. en-GB ve en-US gibi kombinasyonlar ise aynı dilin farklı ülke sürümlerini anlatmak için kullanılır.
x-default, uygun dil veya bölge eşleşmesi olmayan kullanıcılar için varsayılan açılış sayfasını tanımlar. Google’ın x-default açıklaması özellikle uluslararası giriş sayfalarında bu etiketi önerir. Eğer kullanıcıyı dil seçiciye veya global ürün listelemesine götüren bir sayfanız varsa, o URL’yi x-default olarak işaretlemek mantıklıdır. Burada amaç Google’a “bu sayfa belirli bir ülke sürümünden çok, fallback kapısıdır” sinyali vermektir.
Canonical ile hreflang aynı işi yapmaz. Canonical tercih edilen kopyayı söyler; hreflang ise eşdeğer varyantlar arasındaki dil ve bölge ilişkisini anlatır. Yerelleştirilmiş sayfaların çoğunda doğru yaklaşım, her varyantın kendi canonical etiketini kendisine vermesi ve ardından tüm alternatiflerin hreflang kümesinde karşılıklı bağlanmasıdır. tr-TR sayfasını canonical ile en-US sayfasına bağlayıp aynı anda hreflang ile ayrı varyant gibi göstermek, Google’a çelişkili sinyal göndermek anlamına gelir.
- Self-referencing hreflang: Her URL kendi hreflang kaydında yer almalıdır.
- Reciprocal ilişki: tr-TR, en-GB’yi görüyorsa en-GB de tr-TR’yi görmelidir.
- Canonical uyumu: Yerelleştirilmiş URL’ler genelde kendine canonical vermeli, birbirini bastırmamalıdır.
Adım Adım Hreflang Kurulumu ve Doğrulama
Uygulamada en az sorun çıkaran akış, önce URL eşleşmesini netleştirip sonra etiket üretmektir. Tersine ilerlediğinizde geliştirici tarafı etiketi doğru yazar, ama yanlış URL çiftini bağlamış olursunuz. Aşağıdaki akış hem yeni kurulumda hem mevcut hataları düzeltirken işe yarar.
- URL varyantlarını çıkarın: Önce hangi sayfanın hangi dil veya bölge eşdeğerine karşılık geldiğini tablo halinde yazın. Kategori, ürün, blog ve destek sayfalarını ayrı kümeler olarak ele almak hataları azaltır.
- Dil ve ülke kodlarını doğrulayın: Sadece dil gereken yerlerde ülke kodu eklemeyin. Aynı İngilizce içeriğin ülkeye göre fiyat, stok, teslimat veya metin farkı varsa bölge kombinasyonu kullanın.
- Uygulama yöntemini seçin: Sayfalar için HTML head veya sitemap, dosyalar için HTTP header seçin. Aynı kümenin farklı kaynaklarda çelişmemesine özellikle dikkat edin.
- Canonical ve reciprocal uyumunu kontrol edin: Her URL kendini işaret etmeli, tüm varyantlar birbirini karşılıklı görmelidir. Redirect, noindex ve yanlış canonical sinyalleri varsa önce onları çözün.
- Crawler ve Search Console ile test edin: Canlıya almadan önce kaynak kodunu, canlıya aldıktan sonra ise tarama, dizin ve yanlış dil sürümü görünürlüğünü birlikte kontrol edin.
Bu akış özellikle çok bölgeli e-ticaret sitelerinde faydalıdır; çünkü sorun çoğu zaman etiket sözdiziminden değil, veri üretim mantığından çıkar. Eğer ürün feed’i, sitemap üreticisi ve tema katmanı ayrı yerlerden yönetiliyorsa hreflang hataları yinelenir. Tek doğru eşleşme tablosu oluşturmak bu nedenle bütün sürecin temelidir.
3 varyantta test ettik: hangi hreflang kurulumu hata üretti?
Bu rehberi hazırlarken aynı içeriğin tr-TR, en-GB ve en-US sürümlerini üç ayrı kurulum mantığıyla karşılaştırdık: yalnız HTML head, yalnız XML sitemap ve kasıtlı olarak reciprocal ilişkisi eksik bırakılmış hatalı bir set. Toplamda 3 varyant ve 3 uygulama yolu üzerinden 9 eşleşmeyi kontrol ettiğimizde en temiz sonuç, tek kaynaktan üretilen tutarlı kümede çıktı. Sözdizimi doğru olsa bile veri kaynağı bölündüğünde sorun başlıyor.
HTML head kullanan temiz set, kaynak kodunda okunması en kolay model oldu. XML sitemap kullanan set, ölçek açısından daha derli toplu ilerledi; ancak tek bir URL yanlış ülke sürümüne bağlandığında hatayı fark etmek daha uzun sürdü. Hatalı reciprocal sette ise en belirgin kırılma, tr-TR sayfasının en-US sürümünü işaretleyip en-US sayfasının geri bağlantı vermemesi oldu. Bu senaryoda crawler uyarıları erken geldi; Google tarafında ise yanlış eşleşme ihtimali arttı.
En problemli kombinasyon, canonical çakışmasıyla birlikte gelen hreflang hatasıydı. Örneğin en-GB sayfası kendine canonical vermek yerine en-US sayfasını işaretlediğinde, hreflang teoride doğru olsa bile pratikte boşa düşüyor. Redirect zinciri, 3xx hedefleri, noindex URL’lere işaret eden alternates ve yanlış ülke kodu kullanımı da aynı kümede tekrarlandı. Buradaki temel ders net: canonical mı, hreflang mi, redirect mi sorusunun cevabı senaryoya göre değişir; ama çelişen sinyallerin aynı anda açık kalması her zaman zarar verir.
- Hızlı tespit edilen hata: Eksik reciprocal ilişki.
- En sessiz ama maliyetli hata: Canonical ile hreflang çakışması.
- En sık operasyonel hata: 3xx, 4xx veya noindex hedefe işaret eden alternatif URL.
| Senaryo | Tercih edilen sinyal | Neden |
|---|---|---|
| Aynı içeriğin dil varyantları | hreflang | Kullanıcıyı doğru dil sürümüne yönlendiren ilişkiyi açıklar. |
| Aynı dilin farklı ülke sürümleri | hreflang + gerekirse x-default | Dil aynı kalsa da bölgesel hedeflemeyi netleştirir. |
| HTML dışı dosyalar ve PDF'ler | HTTP header | Head etiketi kullanılamayan dosyalarda uygulanabilir yöntemdir. |
| Cross-domain yerelleştirilmiş sayfalar | hreflang | Farklı alan adlarındaki eşdeğer URL'leri birbirine bağlar. |
| Otomatik dil yönlendirmesi yapılan açılış sayfaları | x-default + sınırlı yönlendirme | Fallback sayfası tanımlar, bot erişimini korur. |
| Noindex veya canonical çakışması olan varyantlar | Önce teknik çakışmayı düzelt | Çelişen sinyaller varken hreflang etkisi zayıflar. |
Hreflang hataları nasıl test edilir ve düzeltilir?
Doğrulama sırasını karıştırmamak gerekir. Önce sayfanın canlı kaynak kodunda veya response header’ında hreflang’in gerçekten üretildiğini kontrol edin. Ardından XML sitemap kullanıyorsanız aynı URL kümesinin orada da tutarlı olduğunu teyit edin. Sonraki adımda bir crawler ile bütün alternates ilişkisini topluca tarayın. En sonda Search Console ve URL Denetleme Aracı üzerinden yanlış dil sürümünün dizine girip girmediğine, canonical tercihlerine ve erişim durumuna bakın.
En yaygın sorunlar nettir: noindex hedefe işaret etme, 4xx veya 5xx sayfaları alternates kümesine sokma, x-default’u gerçek bir dil sürümü yerine rastgele kampanya sayfasına bağlama ve locale-adaptive yönlendirmeyi aşırı agresif kurma. Google, locale-adaptive sayfalar rehberinde 2026’da da botların her zaman kullanıcıyla aynı deneyimi yaşamayacağını açıkça vurgular; bu nedenle otomatik yönlendirme katmanı, keşfi engellemeyecek kadar hafif olmalıdır (Google Search Central, 2026).
Düzenli site audit kontrolü burada iş yükünü ciddi biçimde azaltır. Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer benzer denetim ve raporlama ihtiyaçlarını farklı açılardan karşılar; SEOYEN ise bu süreci Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek ile tek platform içinde toparlamasıyla Türkiye pazarı için daha pratik bir iş akışı sunar. Özellikle ajans içi teknik QA’da ekiplerin aynı uyarıları aynı dilde yorumlaması hız kazandırır.
Kurulumdan sonra periyodik izleme de gerekir. Yeni açılan ülke klasörleri, kampanya landing page’leri ve ürün varyantları çoğu zaman hreflang kümesinin dışına düşer. Bu yüzden teknik ekipler için operasyonel erişim ve satın alma planını değerlendirirken paket seçenekleri sayfasına bakıp hangi raporlama derinliğinin iş akışınıza uyduğunu görmek mantıklıdır. Burada kritik olan fiyat değil, her yeni URL kümesinin düzenli QA döngüsüne girmesidir.
Yayın öncesi QA checklist’i ve WordPress, Next.js, Shopify notları
WordPress tarafında en büyük risk, bir eklentinin head içine hreflang basarken başka bir SEO eklentisinin ayrı bir canonical mantığı üretmesidir. Next.js projelerinde risk daha çok render akışındadır; head verisi sunucu tarafında mı, istemci tarafında mı üretiliyor sorusu önemlidir. Shopify’da ise tema katmanı ile pazar yapılandırması arasında sınır olduğu için, her lokal mağaza veya domain eşleşmesinin gerçekten indekslenebilir ayrı URL üretip üretmediği doğrulanmalıdır.
- Canlıya almadan önce: Her URL 200 dönüyor mu, self-canonical doğru mu, hreflang kümesi tam mı?
- Canlıya aldıktan sonra: Yanlış dil sürümü dizine giriyor mu, x-default doğru fallback’i veriyor mu?
- Sürekli izleme: Yeni sayfalar, yönlendirmeler ve sitemap güncellemeleri hreflang setini bozuyor mu?
Google’ın locale-adaptive sayfalar rehberi, botları IP veya tarayıcı dili üzerinden sert biçimde başka URL’ye atmanın taramayı zorlaştırabileceğini açıkça söyler. Bu nedenle özellikle açılış sayfalarında tam otomatik yönlendirme yerine seçilebilir dil veya ülke deneyimi ve doğru x-default kullanımı daha güvenlidir. İsterseniz bu bölümde ekip içi eğitim için Google Search Central’ın resmi YouTube anlatımını da ek kaynak olarak değerlendirebilirsiniz.
Yayın sonrası kontrolü sadece indeksleme ile sınırlamayın. Yanlış dil sürümünün sıralanması, marka sorgularında farklı ülke sayfasının görünmesi ve yeni klasörlerin görünürlük kaybetmesi ancak düzenli takipte fark edilir. Bu noktada sıralama takibi raporu ile ülke bazlı görünürlüğü ayrı izlemek, hreflang kurulumunun gerçekten çalışıp çalışmadığını anlamanın en net yollarından biridir.
Kaynaklar
Sıkça Sorulan Sorular
Hreflang, aynı veya büyük ölçüde eşdeğer içeriğin farklı dil ve bölge sürümlerini arama motorlarına bildiren uluslararası SEO sinyalidir. Temel amacı, kullanıcının sorgusuna en uygun URL'yi dil ve ülke bağlamında eşleştirmektir. Örneğin Türkçe Türkiye sürümü ile İngilizce Birleşik Krallık sürümü ayrı URL'lerdeyse, hreflang bu ilişkiyi tanımlar. Bu etiket bir sıralama hilesi değil, doğru sayfanın doğru kullanıcıya gösterilmesini kolaylaştıran teknik bir açıklama katmanıdır.
Hreflang üç yerde uygulanabilir: HTML head içine, XML sitemap içine veya HTML dışı dosyalar için HTTP header üzerinden. Sayfa tabanlı projelerde HTML head ya da sitemap en yaygın tercihtir. PDF gibi dosyalarda ise HTTP header daha uygundur. Burada önemli olan yöntemin kendisi değil, hangi yöntemi seçerseniz seçin tüm dil ve bölge varyantlarını eksiksiz ve karşılıklı biçimde tanımlamanızdır. Aynı URL kümesinin farklı kaynaklarda çelişmemesi de kritik bir kalite kontrol adımıdır.
Hayır, aynı şey değildir. Canonical etiketi hangi URL'nin tercih edilen kopya olduğunu söyler. hreflang ise eşdeğer sayfaların farklı dil veya bölge varyantları olduğunu belirtir. Yerelleştirilmiş sayfalarda en doğru kurulum genelde her varyantın kendine canonical vermesi ve bütün eşdeğer URL'lerin hreflang kümesinde karşılıklı bağlanmasıdır. Bir sayfayı canonical ile başka ülke sürümüne bastırıp sonra hreflang ile ayrı varyant gibi göstermek çelişkili sinyal üretir ve görünürlük sorunlarına yol açabilir.
x-default, uygun dil veya bölge eşleşmesi bulunmadığında kullanıcının göreceği varsayılan sayfayı tanımlar. Bu genelde global giriş sayfası, dil seçici veya ülke seçici görevi gören URL'dir. x-default özellikle uluslararası açılış sayfalarında yararlıdır. çünkü Google'a bu URL'nin belirli bir dil sürümünden çok fallback deneyimi sunduğunu anlatır. Ancak x-default'u rastgele kampanya sayfalarına bağlamak doğru değildir. En iyi kullanım, diğer varyantlara geçiş kapısı olan nötr bir sayfayı işaretlemektir.
Seçim, içerik tipine ve bakım modeline göre yapılmalıdır. Az sayıda sayfa ve görünür yönetim ihtiyacında HTML head rahat okunur. Büyük ölçekli yapılarda merkezi otomasyon sunan XML sitemap daha sürdürülebilir olabilir. PDF ve benzeri dosyalarda ise HTTP header gerekir. Teknik olarak üç yöntem de geçerlidir. asıl karar, tek doğru veri kaynağını hangi katmanda daha güvenilir üretebildiğinizle ilgilidir. Aynı kümenin farklı yerlerde farklı görünmesi, yöntem seçiminin kendisinden daha büyük problemdir.
En iyi uygulama olarak evet, karşılıklı işaretleme gerekir. Bir sayfa başka bir dil veya ülke sürümünü alternatif olarak gösteriyorsa, karşı sayfanın da geri dönüp bu ilişkiyi tanıması beklenir. Bu reciprocal yapı eksik olduğunda arama motorunun eşleşme kümesini güvenle okuması zorlaşabilir. Pratikte eksik karşılıklı etiketleme, özellikle büyük sitelerde yanlış sürümün görünmesine veya bazı URL'lerin alternatif küme dışında kalmasına yol açabilir. Bu yüzden self-reference ve reciprocal kontrolü birlikte yapılmalıdır.
Dil kodları standart biçimde yazılır ve tek başına kullanılabilir. örneğin tr veya en gibi. Ülke kodu opsiyoneldir, fakat kullanıldığında doğru dil ile eşleştirilmelidir. en-GB ve en-US gibi. Sadece ülke kodu yazmak geçerli değildir. Kod seçimi yaparken içerik farkını düşünmek gerekir: dil aynı ama fiyat, teslimat, stok, teklif veya hukuki metin farklıysa bölge kombinasyonu mantıklıdır. Kodların yanlış yazılması, sözdizimi doğru görünse bile hreflang kümesinin etkisini boşa çıkarabilir.
En iyi yöntem katmanlı kontroldür. Önce kaynak kodunda veya response header'ında hreflang gerçekten üretiliyor mu bakılır. Sonra XML sitemap kullanılıyorsa aynı URL kümesinin orada da tutarlı olup olmadığı doğrulanır. Ardından bir crawler ile reciprocal ilişki, 3xx hedefler, noindex sayfalar ve yanlış ülke kodları taranır. Son aşamada Search Console ve URL Denetleme Aracı üzerinden canonical tercihi, erişilebilirlik ve yanlış dil sürümünün dizine girip girmediği kontrol edilir. Düzenli tekrar, tek seferlik kontrolden daha değerlidir.