Hreflang etiketini sisteme dahil etmenin üç farklı yolu vardır: sayfanın HTML <head> bölümüne yerleştirilen <link rel="alternate"> etiketleri, XML sitemap dosyasına eklenen özel bloklar ve sunucu tarafından HTTP yanıt başlıklarıyla iletilen bildirimler. Google her üç yöntemi de tanır ve işler. Ama "tanımak" ile "en verimli sonucu vermek" aynı şey değildir; her yöntemin doğal çalıştığı ölçek, hata üretme biçimi ve operasyonel maliyeti birbirinden belirgin biçimde ayrışır.
Bu üç yolun bir arada var olması teknik bir lüks değil, pratik bir zorunluluktan kaynaklanır. HTML head yöntemi standart bir web sayfası için en doğal seçenektir. Ama PDF belgeler veya sunucu tarafından üretilen dosyalar için HTML etiketi koymak mümkün değildir; bu noktada HTTP başlıkları devreye girer. Büyük sitelerde ise binlerce URL'ye tek tek etiket eklemek operasyonel olarak sürdürülemez hâle gelir; sitemap yöntemi bu yükü merkezileştirir.
Hangisi daha mantıklı sorusu çoğu durumda yanlış çerçevelenmiş bir sorudur. Üç yöntem birbirinin rakibi değildir; hangi içerik türünde, hangi ölçekte ve hangi altyapıyla çalıştığınız sorusunun yanıtı, yöntem seçimini büyük ölçüde belirler. Bu üç değişkeni gözardı eden bir tercih, teknik olarak geçerli ama operasyonel olarak sorunlu bir yapı üretir.
Üç yöntem arasındaki yapısal fark
Hreflang bildirimi özünde basit bir taleptir: bu URL'nin hangi dil ve bölge için olduğunu ve diğer URL'lerin aynı içeriğin hangi dil sürümlerini temsil ettiğini Google'a iletmek. Bu talebi taşıyan üç farklı kanal birbiriyle aynı sonucu üretmek için tasarlanmıştır, ama çalışma mekanizmaları birbirinden yapısal olarak ayrışır.
HTML head yöntemi en doğrudan olanıdır. Etiket sayfanın içinde yaşar; Googlebot sayfayı taradığında hreflang bildirimini içerikle birlikte alır. Herhangi bir ek altyapıya, ayrı bir tarama adımına ya da harici dosyaya gerek yoktur. Sayfa oradaysa etiket de oradadır.
XML sitemap yöntemi bu bildirimi sayfadan koparır ve merkezi bir dosyaya taşır. Sayfa tarandığında hreflang bilgisi içeriğin yanında bulunmaz; Google sitemap üzerinden bu bilgiyi bağımsız olarak alır. Bu ayrım bir avantaj gibi görünür — merkezi yönetim, tek noktadan güncelleme. Ama aynı zamanda bir bağlam kopukluğu getirir: sayfa ile sitemap arasındaki senkronizasyon bozulabilir ve bu sessiz bir hata olarak uzun süre fark edilmeyebilir.
HTTP header yöntemi tamamen farklı bir kanalda çalışır. Bildirim ne sayfanın içinde ne de ayrı bir dosyadadır; sunucunun HTTP yanıt başlığında Link başlığı aracılığıyla iletilir. Bu yöntem belirli bir ihtiyaç için tasarlanmıştır ve bu ihtiyacın dışında neredeyse tercih edilmez. Üç yöntem arasında en dar kullanım alanına sahip olandır.
HTML head yönteminin ölçek sınırı
Küçük ve orta ölçekli sitelerde HTML head yöntemi açık ara en temiz seçenektir. Etiket sayfa içinde bulunduğu için Googlebot taramayı tamamladığında hreflang bildirimini de almış olur; ek bir tarama adımı gerekmez, ayrı bir dosya yönetilmez. Doğrulama basittir: kaynak kodu açılır, etiketler orada ya değildir.
Ölçek büyüdükçe bu basitlik dezavantaja dönüşür. 5 dil sürümüyle çalışan 500 sayfalık bir e-ticaret sitesinde her sayfanın <head> bölümünde 5 hreflang etiketi bulunması gerekir — toplamda 2.500 etiket. Bu etiketlerin tek tek doğru kurulmuş olması, sayfalar güncellendiğinde senkronize tutulması ve karşılıklı referansların eksiksiz kalması ciddi bir dikkat gerektirir. CMS'in bu etiketleri otomatik üretip üretmediği belirleyicidir; üretmiyorsa manuel yönetim kaçınılmazdır.
20 dil sürümüyle çalışan bir sitede her sayfa <head> bölümünde 20 hreflang etiketi taşır. Sayısal olarak önemsiz görünebilir — birkaç satır HTML'dir. Ama her gün milyonlarca sayfa dönen büyük platformlarda bu yük birikir ve sayfa boyutunu artırır. Daha kritik bir sınır ise JavaScript üzerinden yüklenen etiketlerde ortaya çıkar: dinamik olarak enjekte edilen hreflang etiketlerini Googlebot her zaman işleyemez. Statik HTML'de yerleştirilen etiketler bu riski taşımaz; JavaScript bağımlılığı olan uygulamalar taşır.
XML sitemap yöntemi: merkezi yönetimin bedeli
XML sitemap yöntemi büyük ölçekli siteler için doğal bir çözüm gibi görünür — ve belli bir noktaya kadar öyledir. Binlerce URL'nin hreflang kümelerini tek bir dosyada yönetmek, her sayfaya ayrı ayrı dokunmak yerine merkezi bir güncelleme yapmak anlamına gelir. Yeni bir dil sürümü eklendiğinde veya URL yapısı yenilendiğinde sitemap dosyasını güncellemek, sayfaların tek tek değiştirilmesinden çok daha verimlidir.
Bu merkezi yönetim avantajı beraberinde ciddi bir senkronizasyon riski getirir. Sitemap'teki hreflang bildirimleri ile sayfalardaki içerik birbirinden bağımsız güncellenir. Bir sayfa kaldırıldığında sitemap güncellenmezse Google, olmayan bir sayfayı hreflang kümesinde görmeye devam eder. Yeni bir dil sürümü eklendiğinde önce sayfaların mı yoksa sitemap'in mi güncelleneceği önemlidir; aralarındaki zaman farkı geçici ama ölçülebilir bir tutarsızlık yaratır. Uluslararası sitemap hazırlamanın operasyonel boyutuna bakıldığında bu senkronizasyon gerekliliği sıklıkla gözden kaçan bir yük olarak öne çıkar.
Sitemap yönteminin az bilinen bir kısıtı Google'ın sitemap'i işleme sıklığıdır. Sitemap her gün güncelleniyor olsa bile Googlebot onu aynı sıklıkta işlemez. Bir hreflang değişikliği sitemap'e yazıldıktan günler veya haftalar sonra Google tarafından algılanabilir. HTML head yönteminde ise değişiklik sayfa içinde yaşadığı için Googlebot o sayfayı bir sonraki tarayışında güncellemeyi görür — sitemap'in işlenme döngüsünü beklemeye gerek yoktur. Aciliyet gerektiren değişikliklerde bu gecikme fark yaratır.
Pratik bir eşik de belirtmek gerekir: sitemap dosyasının boyutu 50 MB'ı ve URL sayısı 50.000'i aşmamalıdır. Çok dilli büyük kataloglarda her URL için tüm dil alternatiflerinin listelenmesi bu sınıra hızla ulaşabilir. Bu durumda sitemap birden fazla dosyaya bölünmeli ve sitemap index dosyası üzerinden yönetilmelidir.
HTTP header yöntemi ne zaman zorunlu olur?
HTTP header yöntemi neredeyse yalnızca bir senaryo için anlam taşır: HTML olmayan içerikler. PDF dosyalarının birden fazla dil sürümü varsa bu dosyalara HTML etiketi yerleştirmek mümkün değildir. Sitemap yöntemi burada işe yarar; ama sunucu HTTP yanıt başlıklarında Link: <url>; rel="alternate"; hreflang="x" bildirimi yapmak da geçerli bir alternatiftir. İkisi arasındaki tercih çoğunlukla altyapı kolaylığına göre şekillenir.
Standart HTML sayfaları için HTTP header yöntemini tercih etmek teknik olarak mümkündür ama hiçbir avantajı yoktur. Sunucu yapılandırmasına müdahale gerekmektedir; Apache veya Nginx'te her URL grubu için özel Link başlığı tanımlamak, CMS entegrasyonunun dışında elle yönetilen bir katman oluşturur. Bu operasyonel karmaşıklık, HTML head veya sitemap yönteminin sağladığıyla tamamen aynı sonucu üretir. Ekstra yük karşılıksız kalır.
HTTP header yönteminin hata üretme biçimi de kendine özgüdür. Bir sorun olduğunda başlığı görmek için HTTP isteğini yakalamak gerekir — kaynak koduna bakmak veya sitemap'i açmak yeterli değildir. Bu görünmezlik, hreflang hatalarını tespit etmeyi zorlaştırır. Özellikle farklı kişiler farklı yöntemlerle çalışıyorsa başlık tabanlı bildirimler kolayca gözden kaçar ve aylarca sessiz hata olarak devam eder.
Yöntemler karıştırıldığında ne olur?
Aynı sitede birden fazla yöntem bir arada kullanılabilir; bu teknik olarak geçerlidir. Google bunları birbirini dışlayan seçenekler değil, birbirini tamamlayabilecek kaynaklar olarak değerlendirir. PDF'ler HTTP header veya sitemap üzerinden, HTML sayfalar ise head yöntemiyle yönetilebilir. Bu kombinasyon makul bir yaklaşımdır.
Asıl sorun, aynı URL için farklı yöntemlerden gelen bildirimlerin çelişmesidir. HTML head bir URL kümesi tanımlarken sitemap farklı bir küme tanımlarsa Google hangi bilgiye güveneceğini bilemez. Pratikte algoritmik bir karar verilir ama bu karar öngörülebilir değildir. Hreflang testlerinde bu çakışma senaryosu sıkça gün yüzüne çıkar: kaynak kod temiz görünür, sitemap doğru görünür — ama ikisi aynı şeyi söylemiyor.
En yaygın karışım senaryosu şudur: site başlangıçta HTML head yöntemiyle kurulur, büyüdükçe sitemap yönetimine geçilir, ama eski sayfaların bir kısmındaki head etiketleri güncellenmeden kalır. Yeni sayfalar yalnızca sitemap üzerinden, eski sayfalar ise hem head hem sitemap üzerinden bildirim yapar — ve ikisi farklı kümeler tanımlıyorsa çatışma oluşur. Teknik SEO denetimlerinde bu tür kalıntı tutarsızlıklar düzenli biçimde karşılaşılan bir anti-pattern'dir. Search Console'da uyarı çıkmaz; sorun ancak hreflang kümesi URL bazında incelendiğinde görülür.
Yöntem seçimi için pratik çerçeve
Üç soruya verilen yanıt büyük ölçüde yöntem seçimini belirler.
Birincisi, içerik türü nedir? HTML sayfalardan oluşan bir sitede hem HTML head hem sitemap kullanılabilir; içerik türü kısıt oluşturmaz. HTML olmayan dosyalar varsa HTTP header veya sitemap zorunludur; bu durumda seçim kalmaz.
İkincisi, site ölçeği ne? Birkaç yüz sayfaya kadar HTML head yöntemi yönetilebilirdir ve daha temiz hata takibine olanak tanır. CMS otomatik üretim sağlıyorsa bu sınır binli rakamlara çekilebilir. Büyük kataloglarda — on binlerce URL, beşten fazla dil — sitemap yöntemi operasyonel yükü anlamlı biçimde azaltır. Ama sitemap seçilirse bir senkronizasyon protokolü de kurulmalıdır: sayfa kaldırıldığında sitemap ne zaman güncellenir, yeni dil sürümü eklendiğinde hangi sırayla işlem yapılır?
Üçüncüsü, doğrulama kapasitesi nedir? HTML head yöntemi daha kolay doğrulanır; hatalar daha hızlı yakalanır. Sitemap yöntemi daha uzun güncelleme döngüleri gerektirir ve hataların fark edilmesi gecikebilir. Ekip bu süreci yönetecek kapasiteye sahip değilse, daha küçük ölçekte HTML head yönteminde kalmak daha az hata üretir. Doğrulama kolaylığı, büyük görünen bir sistem avantajını pratikte geçersiz kılabilir.
Üç yöntem arasındaki seçim çoğu durumda "hangisi daha iyi" sorusuna değil, "hangi koşulda hangisi daha az sorun üretir" sorusuna verilen yanıta dayanır. HTML head yöntemi şeffaf ve doğrudan; sitemap yöntemi ölçeklenebilir ama senkronizasyon disiplini gerektiriyor; HTTP header yöntemi ise yalnızca HTML dışı içerikler için anlamlı. Her üçünü de geçerli kılan farklı bir bağlam vardır.
Yöntemleri karıştırmaktan kaçınmak büyük sitelerde her zaman mümkün olmayabilir. Ama karışım bilinçsizce oluştuğunda — geçiş dönemlerinde, platform değişikliklerinde, farklı ekip üyelerinin farklı yaklaşımlar benimsemesiyle — sonuç çelişen bildirimler olur. Hangi yöntemi seçtiğinizden çok, seçilen yöntemin tutarlı biçimde uygulanıp uygulanmadığı daha belirleyicidir.