Hreflang hatalarının tehlikeli yanı sessizliklerinde. Yanlış yapılandırılmış bir hreflang seti çoğunlukla site hatasına yol açmıyor, 404 döndürmüyor, kullanıcının önüne doğrudan çıkmıyor. Sayfa yüklenmeye devam ediyor, içerik görünüyor, her şey normal. Ama arama motoru tarafında o dil sinyali ya görmezden geliniyor ya da yanlış yorumlanıyor. Sonuç haftalarca, bazen aylarca fark edilmeden süren görünürlük kaybı oluyor.
Search Console hreflang hatalarını kısmen raporluyor — ama yalnızca kısmen. Bazı hata tipleri hiçbir uyarı üretmiyor; teknik olarak geçerli görünen ama pratikte işlevsiz olan setler platformun radar altında kalıyor. Bu yüzden Search Console raporunu temiz görmek "hreflang doğru çalışıyor" anlamına gelmiyor. Doğrulama birden fazla katmanda yapılmak zorunda.
Hreflang'ın temel mantığını ve uluslararası SEO'daki yaygın teknik hataları ele alan yazılarda genel çerçeve kurulmuştu. Buradaki tartışma daha odaklı: hangi hata tipleri var, hangisi nasıl tespit edilir ve her biri için düzeltme yolu ne.
Search Console'un gösterdiği ve göstermediği
Google Search Console'daki uluslararası hedefleme raporu hreflang hataları için birincil başvuru noktası. "Hreflang" sekmesi altında listelenen sorunlar üç ana başlıkta toplanıyor: dil kodu geçersiz, dönüş etiketi eksik ve URL erişilemiyor.
Dil kodu hatası görece kolay fark ediliyor ve düzeltmesi net: hreflang="de-DE" yerine hreflang="de_DE" gibi tire yerine alt çizgi kullanmak, ya da ISO 639-1 standardında olmayan bir dil kodu yazmak — hreflang="turkish" gibi — bu hata kategorisine giriyor. Search Console bunları listeler.
Dönüş etiketi eksikliği de raporlanıyor: A sayfası B'yi işaret ediyor ama B sayfası A'ya karşılıklı referans vermiyor. Search Console bu durumu çoğunlukla yakalıyor. Ama büyük kataloglarda bu hatanın hangi sayfa çiftlerinde oluştuğunu bulmak, raporun kendisinden daha çok manuel araştırma gerektiriyor.
Search Console'un sessiz kaldığı durumlar ise daha kritik. Teknik olarak geçerli ama semantik olarak yanlış setler — örneğin doğru dil kodları kullanılmış ama yanlış URL'ler eşleştirilmiş — hiçbir uyarı üretmiyor. /en/product-a/ ile /de/product-b/'nin birbirini işaret etmesi, iki farklı ürünün yanlışlıkla dil sürümleri olarak bağlanması anlamına geliyor. Google etiketleri teknik olarak işliyor; ama bu bağlantının yanlış olduğunu söylemiyor. Yanlış URL eşleştirmesini tespit etmek Search Console'un değil, içerik denetiminin işi.
Karşılıklı referans hatası: en yaygın sessiz hata
Hreflang etiketinin karşılıklı referans zorunluluğu teoride basit: her URL, setindeki diğer tüm URL'leri işaret etmeli. Pratikte bu zorunluluk büyük sitelerde kolayca bozuluyor. Yeni bir dil ekleniyor ama eski sayfaların hreflang setleri güncellenmeden bırakılıyor. Bir sayfa silinip yeniden oluşturuluyor ama yeni URL'nin karşılıklı referans aldığı diğer sayfalar güncellenmeden geçiliyor. Tema güncellemesi hreflang şablonunu bozuyor ve bir dil sürümü setten düşüyor.
Tek yönlü bağlantı Google tarafından genellikle görmezden gelinir. Yani A, B'yi işaret ediyor ama B, A'yı işaret etmiyorsa Google bu ikiliyi geçerli bir hreflang seti olarak değerlendirmiyor. İki sayfanın da karşılıklı referans verdiği durumlarda set geçerli sayılıyor. Tek yönlü kalındığında ne A ne de B hedeflenen dil için güçlü bir sinyal üretiyor.
Bunu tespit etmenin en güvenilir yolu birkaç temsili URL'de kaynak kod denetimi. A sayfasının kaynak kodundaki tüm hreflang URL'lerini listeleyin, ardından her birini açıp orada da A sayfasına referans olup olmadığını kontrol edin. Bu süreci otomatize etmek için tarayıcı araçlarından yararlanılabiliyor; Screaming Frog veya benzeri SEO tarayıcıları hreflang karşılıklı referans kontrolünü toplu biçimde yapabiliyor. Büyük kataloglarda bu otomasyon olmadan denetim mümkün değil.
Karşılıklı referans hatasını düzeltmek, hatanın kaynağını bulmayı gerektiriyor. Eklenti mi yanlış üretiyor, tema şablonu mu eksik, sitemap bazlı hreflang kullanılıyorsa sitemap dosyası mı güncellenmemiş? Kaynağı bulmadan tek tek düzeltmek geçici çözüm üretiyor; bir sonraki içerik güncellemesinde hata yeniden oluşuyor.
Canonical ile hreflang çatışması
Bir sayfanın canonical etiketi başka bir URL'ye işaret ediyorsa, Google o sayfayı canonical'ı işaret eden URL üzerinden değerlendiriyor. Bu durumda sayfanın kendi hreflang etiketleri büyük ölçüde görmezden geliniyor — çünkü sayfa kendisini "asıl URL" olarak kabul etmiyor.
Bu çatışma çeşitli biçimlerde ortaya çıkıyor. Sayfalı URL'ler (?page=2) birinci sayfayı canonical gösteriyor ama hreflang etiketleri de bulunuyor. Filtrelenmiş URL'ler ana kategori sayfasını canonical gösteriyor ama hreflang seti içeriyor. A/B test sürümleri ya da kişiselleştirilmiş URL'ler orijinal sayfayı canonical gösteriyor ama hreflang taşıyor.
Canonical etiketin çok dilli yapıdaki yönetiminde temel kural şu: her dil sürümünün kendi canonical'ı kendisi olmalı — başka bir dil sürümünü değil, başka bir URL versiyonunu değil, kendisini. Bu kuraldan sapıldığı her noktada hreflang seti işlevsizleşme riski taşıyor.
Canonical-hreflang çatışmasını tespit etmek için bir sayfanın hem canonical hem hreflang değerlerini aynı anda görmek gerekiyor. Kaynak kod incelemesinde canonical'ı önce kontrol edin; eğer canonical sayfanın kendisini göstermiyorsa, o sayfadaki hreflang etiketlerinin işlevini yitirdiğini varsayın. Screaming Frog veya benzeri araçlar her iki alanı aynı anda raporlayabiliyor ve çatışan URL'leri filtrelemeyi kolaylaştırıyor.
Otomatik üretimin yakalamadığı edge case'ler
Platform tabanlı hreflang üretimi — eklenti, tema veya CMS katmanı — standart senaryolar için yeterli. Ama yapı standart dışına çıktığında otomatik üretim kör noktalar bırakıyor.
Birinci kör nokta çevrilmemiş içerikler. Bazı eklentiler çeviri henüz yapılmamış bir sayfa için kaynak dil URL'sini hedef dil hreflang değeri olarak kullanabiliyor. Bu durumda Almanya aramaları için hedeflenen hreflang değeri bir Almanca sayfa yerine İngilizce sayfayı gösteriyor. Google etiket syntaxını geçerli buluyor; ama sinyal yanlış yönlü. Çözüm: çevrilmemiş sayfalar için o dil sürümünün hreflang setine dahil edilmemesi.
İkinci kör nokta yönlendirmeler. Bir URL başka bir URL'ye yönlendiriliyorsa, yönlendirilen URL'nin hreflang setine alınması sorun yaratıyor. Google yönlendirilen URL'yi izliyor ve hedef URL'yi buluyor; ama hreflang setinde yönlendirilen URL listelenmişse set tutarsız hale geliyor. Özellikle büyük site geçişlerinde veya URL yapısı değiştirilen mağazalarda bu durum sık görülüyor. Hreflang setlerinin her zaman nihai (yönlendirilmemiş) URL'leri işaret ettiğini doğrulamak gerekiyor.
Üçüncü kör nokta x-default değerinin yanlış atanması. x-default etiketinin hangi URL'ye işaret etmesi gerektiği mağazadan mağazaya değişiyor. Eklenti bu değeri genellikle varsayılan dile atıyor; ama mağazanın birincil pazarı varsayılan dil değilse bu atama yanlış. x-default'u Search Console raporu yakalamıyor; elle kontrol edilmesi gerekiyor.
Dördüncü kör nokta hreflang etiketlerinin <head> yerine <body>'de yer alması. Sayfa oluşturucular veya özel JavaScript şablonları bazen hreflang'ı DOM'a geç enjekte ediyor. Google bu etiketleri <body>'de de okuyabiliyor ama güvenilirliği <head>'e kıyasla daha düşük. Bir sayfanın kaynak koduna değil, tarayıcının render ettiği DOM'a baktığında farklı bir sonuç görüyorsan, etiketin konumu sorun yaratıyor olabilir.
Büyük kataloglarda sistematik hata takibi
Yüzlerce veya binlerce URL'ye sahip bir mağazada hreflang denetimini süreklileştirmek, tek seferlik manuel kontrol yerine döngüsel bir süreç gerektiriyor. Her içerik güncellemesinde, her eklenti değişikliğinde ve her tema güncellemesinde hreflang çıktısı yeniden kontrol edilmesi gereken bir değişken.
Pratik bir izleme döngüsü üç katmandan oluşuyor. İlk katman periyodik Search Console kontrolü — aylık veya iki haftada bir hreflang hata raporuna bakılması. Bu rapor sessiz hataları yakalamıyor ama bilinen hata tiplerini temiz tutuyor. İkinci katman örneklem bazlı manuel denetim — her büyük değişiklikten sonra birkaç temsili sayfanın kaynak kodu ve DOM'unun elle incelenmesi. Üçüncü katman araç destekli tarama — Screaming Frog veya benzeri bir tarayıcıyla tüm URL'lerin hreflang karşılıklı referansının düzenli aralıklarla kontrol edilmesi.
Bu döngünün ne sıklıkta çalıştırılacağı katalog büyüklüğüne ve değişim hızına bağlı. Ayda birkaç kez içerik eklenen bir mağaza için aylık tarama yeterli olabilir. Her gün yüzlerce ürün eklenen bir mağaza için haftalık otomatik kontrol daha uygun. Teknik SEO denetim listesi bu döngünün neyi, hangi sıklıkta kontrol edeceğini yapılandırmak için başlangıç noktası sağlıyor.
Hata bulunduğunda düzeltme önceliği de sistematik olmalı. Tüm dil sürümlerini etkileyen yapısal hatalar — eklenti ya da tema katmanındaki sorunlar — tek sayfa hatalarından önce çözülüyor. Tek sayfalık hatalar ise trafik ve dönüşüm değeri yüksek sayfalardan başlayarak ele alınıyor. Bu önceliklendirme, hata listesini yönetilebilir parçalara bölerken en kritik sinyallerin düzeltilmesini hızlandırıyor.
Hreflang hata yönetimi tek seferlik bir temizlik değil, süregelen bir dikkat gerektiriyor. Site büyüdükçe, içerik eklenip kaldırıldıkça ve platform güncellemeleri yapıldıkça yeni hatalar oluşuyor. Bunu "sorun çıkınca bak" yaklaşımıyla yönetmek, genellikle hataların fark edilmeden haftalarca birikmesi anlamına geliyor.
En değerli alışkanlık yapısal değişikliklerden önce hreflang çıktısını doğrulamak. Yeni bir eklenti, tema güncellemesi veya URL yapısı değişikliği, beklenmedik hreflang davranışlarının en yaygın tetikleyicisi. Değişiklikten sonra birkaç sayfayı elle kontrol etmek, sorunları erken aşamada yakalamayı sağlıyor.