Hreflang genellikle bir satırlık teknik etiket gibi değerlendirilir. Arkasında daha geniş bir mantık var aslında: eşdeğer sayfaların birbirini doğru işaretlemesi, kendi dillerinde erişilebilir olması ve çelişkili yönlendirme üretmemesi. Küçük görünür. Etkisi büyüktür.
Çok dilli ya da çok bölgeli yapı kuran ekipler bu işaretlemeyi çoğu zaman sorun çıkınca hatırlar. Yayın öncesi plan içinde düşünülürse daha az hata üretir. Tek başına çalışmaz çünkü; URL yapısı, canonical mantığı ve içerik eşleştirmesiyle birlikte işlev kazanır.
Eğer henüz temel yapı net değilse önce site kurulum mantığını ve URL düzenini netleştirmek daha doğru olur. Bu işaretleme sonradan serpiştirilen bir etiket değil, kurguya eklenen ilişki katmanıdır.
Hreflang neyi çözer, neyi çözmez?
Temel görevi benzer ya da eşdeğer içeriklerin farklı dil ve bölge alternatifleri arasındaki ilişkiyi göstermektir. İspanyolca arayan kullanıcı İspanyolca içeriği görür, Almanca arayan Almanca içeriği. Çok bölgeli yapılarda aynı dilin farklı ülke versiyonlarını da ayırabilir.
Zayıf içerik kalitesini iyileştirmez ama. Yanlış canonical seçimini tek başına düzeltmez. Aynı URL içinde gizlenen dilleri taranabilir hale getirmez. Bozuk mimariyi tedavi eden sihirli düğme değildir kısacası. Sık atlanan bir nokta; sonra da tüm sorun bu işaretlemeye yüklenir.
Bir içeriğin hangi kullanıcıya uygun olduğunu anlatmak için kullanılır. İndeksleme için değil. İndekslenmeyen, yönlendirmeyle boğulan veya iç link almayan URL'lerde bu ilişkinin etkisi sınırlı kalır.
Dil ve bölge kodları nasıl seçilir?
Değerler dil kodu ve gerektiğinde bölge kodu ile kurulur. Dil kodu genellikle tek başına yeterlidir. Bölge kodu? Aynı dilin farklı ülkelerde ayrı versiyonları varsa devreye girer. En kritik konu dili ülke ile karıştırmamaktır. İngilizce tek bir ülkeye ait değildir; İspanyolca da öyle.
Küresel İngilizce için en, Amerika odaklı versiyon için en-US, Birleşik Krallık için en-GB kullanılır mesela. Ülke farkı kullanıcı deneyimini değiştirmiyorsa gereksiz bölgesel ayrım yapmak yapıyı şişirir. Gerçekten ayrı versiyonlar varsa bu katmanı eklemek gerekir.
<link rel="alternate" hreflang="tr" href="https://ornek.com/tr/sayfa">
<link rel="alternate" hreflang="en" href="https://ornek.com/en/page">
<link rel="alternate" hreflang="x-default" href="https://ornek.com/">Etiket örneği kısa görünür. Asıl iş içerik eşleşmesini doğru kurmaktır. Yanlış eşleşme kod hatasından daha pahalıya mal olur.
HTML, sitemap ve header yöntemleri
İşaretleme HTML içinde, XML sitemap üzerinde ya da HTTP header üzerinden yapılabilir. Çoğu web sitesi için HTML veya sitemap yeterlidir. Birden fazla yöntemi aynı anda kullanmak zorunlu değildir; kullanılıyorsa hepsinin aynı veri kümesini taşıması gerekir. Bakım zorlaşır yoksa.
Küçük ve orta ölçekli sitelerde HTML içi kullanım daha görünürdür. Geliştirici ekip kaynak kodda ne olduğunu anında görür. Geniş hacimli içeriklerde sitemap üzerinden merkezi yönetim daha rahat olabilir. Binlerce sayfalık yapılarda eşleşmeler tablo halinde tutulup sitemap'e aktarılabilir özellikle.
Hangi yöntem seçilirse seçilsin temel ilke değişmez: Her versiyon diğer ilgili versiyonları ve kendisini listelemelidir. Eksik ya da tek yönlü ilişki kurulduğunda sinyal zayıflar.
Karşılıklı referans ve x-default neden önemlidir?
Kümedeki içerikler karşılıklı olarak birbirini işaretlemelidir. Türkçe içerik İngilizce versiyonu gösteriyorsa İngilizce versiyon da Türkçeyi göstermelidir. Bu iki yönlü yapı kümeyi güvenilir hale getirir. Bir tarafta ilişki varken diğer tarafta yoksa işaretleme eksik sayılır.
x-default ise çoğu zaman kullanışlı bir fallback çözümüdür. Dil seçici ana sayfa, küresel giriş noktası ya da kullanıcıya tercih sunan nötr bir sayfa varsa bu etiket değerli olur. Her projede zorunlu değildir. Dil kapısı veya genel versiyon varsa işleri netleştirir.
Dikkat edilmesi gereken nokta? x-default etiketini gelişigüzel herhangi bir dile bağlamamaktır. Bu değer belirli bir dil versiyonunu değil, varsayılan yönlendirme noktasını temsil eder.
En sık yapılan hreflang hataları
- Yanlış dil veya ülke kodu kullanmak
- Eşdeğer olmayan içerikleri birbirine bağlamak
- Karşılıklı referansı eksik bırakmak
- Canonical etiketini başka dile yöneltmek
- Yalnızca ana sayfalarda kullanıp derin içerikleri boş bırakmak
- İçerik henüz hazır değilken tüm versiyonlara toplu etiket eklemek
- Zorunlu yönlendirmeler yüzünden botun alternatif URL'lere erişmesini engellemek
En yaygın olanı içerik eşleşme hatasıdır. Türkçe ürün A'yı İngilizce ürün B'ye bağlamak teknik olarak etiket üretir, ama ilişki kurmaz. Doğruluk veri kalitesiyle ölçülür; etiket sayısıyla değil.
Kurulumdan sonra nasıl doğrulanır?
Kurulduktan sonra iş bitmez. İlk kontrol URL kümelerini elle örnekleyerek yapılmalıdır. Bir Türkçe içeriği açın, kaynak kodunda kendi kendisini ve alternatif versiyonları doğru listeliyor mu bakın. Ardından İngilizce ya da Almanca versiyona gidin, aynı kümenin orada da tutarlı olup olmadığını doğrulayın.
İkinci kontrol katmanı içerik eşleşmesidir. Başlıklar, breadcrumb zinciri, ürün kodları, kategori hiyerarşisi gerçekten karşılık geliyor mu? Teknik olarak eşlenmiş ama içerik düzeyinde farklı amaçlara hizmet eden yapılar kümeyi kirletir. Kalite kontrol yalnızca geliştirici işi değildir bu nedenle; editoryal taraf da dahil olmalıdır.
Site içi dil geçişlerini ve yönlendirme mantığını test etmek gerekir en son. Kullanıcı doğru versiyona erişebiliyorsa, bot alternatif URL'leri görebiliyorsa ve canonical ilişkileri çelişmiyorsa görevini iyi yapar. Teknik denetim listesi ile bu kontrolleri düzenli tekrar etmek, etiketleri bir kez yazıp unutma alışkanlığını kırar.
Tek satırlık hata neden tüm kümeyi bozabilir?
Kurulumda küçük görünen bir yanlışın etkisi bazen beklenenden büyüktür. Tek bir içerik değil, içerik kümeleri birlikte çalışır burada. Bir URL yanlış eşleştiğinde yalnız kendisi değil, bağlı olduğu alternatif versiyonler de bulanık sinyal üretmeye başlar. Hatası lokal değil, çoğu zaman kümeseldir.
Toplu üretim yapan sistemlerde bu risk artar özellikle. Yanlış dil kodu, kopyalanmış şablon satırı ya da eski bir URL deseninin tüm içeriklere uygulanması yüzlerce ilişkide aynı sorunu doğurabilir. Denetim geliştirici işini bitirdiğinde kenara bırakılacak bir madde değildir bu nedenle; düzenli örnekleme isteyen bakım katmanıdır.
Güvenilir yaklaşım veri kaynağını sade tutmaktır. İçerik eşleşme tablosu nerede tutuluyor, hangi ekip güncelliyor, yeni içerik açılınca alternatifi ne zaman ekleniyor? Bu sorular açık değilse mantık kısa sürede kontrolsüz büyür.
Hreflang bakımını kim üstlenmeli?
Teknik olarak etiketleri geliştirici ekliyor olabilir. Doğru eşleşmeyi çoğu zaman editoryal veya SEO ekibi bilir ama. Sahiplik tek kişide değil, net süreçte tanımlanmalıdır. Editör içerik karşılığını belirler, SEO uzmanı yapının tutarlılığını doğrular, geliştirici ise bunu sistematik biçimde uygular. İşin yalnız bir tarafı güçlü olursa hata riski artar.
Düzenli bakım için küçük bir denetim çevrimi yeterlidir: yeni içerik açıldı mı, karşı versiyonu var mı, kümeye işlendi mi, canonical çakışıyor mu, dil seçiciden gerçekten erişiliyor mu? Bu beş soruluk kontrol bile büyük ölçekli hataları erken yakalar.
Kod satırı değil, ilişki yönetimidir sonuçta. Kod yalnız görünür kısmıdır. Asıl kalite arka plandaki eşleşme disiplininden gelir.