Hreflang kurulumu tamamlandığında bir belirsizlik başlıyor: doğru çalışıp çalışmadığını bilmek için neye bakmak gerekiyor? Eklenti "hreflang aktif" diyor, sitemap'te etiketler görünüyor, kaynak kodda satırlar mevcut. Ama bunların hepsi varlık kanıtı; doğruluk kanıtı değil. Etiket doğru URL'lere mi işaret ediyor? Karşılıklı referanslar tam mı? Canonical ile çatışma var mı? Bu soruların yanıtlarını kuruluму yapan araç değil, bağımsız bir test süreci veriyor.
Hreflang hatalarını tespit etmek reaktif bir süreç — bir sorun olduğunu fark ettikten sonra başlıyor. Test ise proaktif: kurulum bitmeden veya büyük bir değişiklik yapılmadan önce sistemi doğrulama amacıyla çalıştırılan süreç. İki yaklaşım birbirini tamamlıyor; test döngüsü hata tespitinin yerini almıyor ama hataların birikmeden önce yakalanmasını sağlıyor.
Aşağıdaki süreç küçük siteler için de büyük kataloglar için de uygulanabilir. Ölçek değiştikçe araç kullanımı yoğunlaşıyor; ama temel adımların mantığı aynı kalıyor.
Kaynak kod ve DOM karşılaştırması
İlk test adımı en basiti ve en sık atlanıyor: sayfanın kaynak kodunu değil, tarayıcının render ettiği DOM'u incelemek. Fark önemli. Kaynak kod sunucunun gönderdiği ham HTML. DOM ise JavaScript dahil tüm eklentilerin ve sayfa oluşturucuların çalıştırılmasından sonra oluşan yapı.
Bazı platformlar hreflang'ı JavaScript aracılığıyla DOM'a enjekte ediyor. Kaynak kodda hreflang satırları yok; ama tarayıcıda sayfa tam yüklendikten sonra <head>'e ekleniyor. Google JavaScript'i çalıştırıyor ve DOM'u indexliyor — ama bu işlem kaynak koda kıyasla daha gecikmeli ve daha az güvenilir. Test ederken her ikisini de görmek, hangi yöntemle üretildiğini anlamak için gerekli.
Kaynak kodu görmek için tarayıcıda "Sayfa kaynağını görüntüle" (Ctrl+U / Cmd+U) kullanılıyor. DOM'u görmek için geliştirici araçlarını açıp <head> bölümünü incelemek gerekiyor. İkisi arasında hreflang satırları farklıysa veya kaynak kodda hiç yokken DOM'da beliriyorsa, JavaScript tabanlı enjeksiyon var demek. Bu durumda Google'ın bu etiketleri her zaman güvenilir biçimde işleyip işlemediğini ayrıca değerlendirmek gerekiyor.
Temsili URL seçimi ve set doğrulaması
Büyük bir kataloğu baştan sona test etmek mümkün değil; ama her sayfayı test etmek de gerekmiyor. Temsili URL seçimi, az sayıda sayfayla tüm yapının sağlığını anlamayı sağlıyor.
Temsili URL seti şu biçimde kurulabiliyor: her dil sürümünden birer ana sayfa, birer kategori sayfası ve birer ürün sayfası seçin. Mağazanızda üç dil varsa bu dokuz URL demek. Bu URL'lerin her birinde hreflang setini incelemek, sistemin genel davranışını gösteriyor. Eğer bu dokuz URL'de tutarlı ve doğru bir set görüyorsanız, büyük olasılıkla diğer sayfalar da doğru yapılandırılmış. Tutarsızlık varsa kök neden genellikle şablon veya eklenti katmanında — yani tüm sayfaları etkileyen bir sorun.
Her URL'de kontrol edilmesi gereken üç şey var. Birincisi, set içindeki tüm dil sürümleri mevcut mu — bir dil eksik bırakılmış mı? İkincisi, her URL doğru sayfaya işaret ediyor mu — hreflang="de" değeri gerçekten Almanca sayfaya mı gidiyor, yoksa yanlış eşleşme var mı? Üçüncüsü, kendi self-referansı doğru mu — sayfa kendi URL'sini doğru dil koduyla işaret ediyor mu?
Bu kontrol elle yapılabilir; ama birkaç URL'den fazlası için bir tarayıcı aracı kullanmak çok daha verimli. Screaming Frog'un hreflang denetim modülü seçilen URL'lerin tüm etiket değerlerini tablo olarak çıkarıyor ve karşılıklı referans uyumsuzluklarını işaretliyor. Küçük sitelerde ücretsiz sürümün 500 URL sınırı çoğunlukla yeterli.
Canlı test ile simüle edilmiş tarama farkı
Google Search Console'daki "URL İnceleme" aracı bir sayfanın Google'ın gözünden nasıl göründüğünü canlı olarak test etmeyi sağlıyor. Bu araç hreflang etiketlerini doğrudan listelemese de sayfanın indexlenip indexlenmediğini, canonical değerini ve tarama durumunu gösteriyor. Daha önemlisi, JavaScript render edildikten sonraki sayfa görünümünü veriyor; dolayısıyla JavaScript tabanlı hreflang enjeksiyonunun çalışıp çalışmadığını dolaylı olarak kontrol etmek için kullanılabiliyor.
Simüle edilmiş tarama için kullanılan yöntem ise Googlebot'un User-Agent'ını taklit eden araçlar veya tarayıcı eklentileri. Bu araçlar sayfayı Googlebot gibi istiyor ve dönen yanıtı gösteriyor. HTTP header tabanlı hreflang kullanıyorsanız — XML sitemap ya da <head> yerine sunucu yanıtında — bu yöntem özellikle değerli çünkü header değerlerini görmek için başka bir yol yok.
İki yöntemin birbirini tamamladığı nokta şu: canlı test güncel durumu gösteriyor ama tarihsel veri vermiyor. Simüle edilmiş tarama yapılandırmayı test ediyor ama Google'ın gerçekte ne gördüğünü tam olarak yansıtmıyor. Search Console'daki uluslararası hedefleme raporunu bu testlerle birlikte okumak en kapsamlı tablo sunuyor.
Test sonuçlarını yorumlama
Test araçlarının çıktısını okumak bazen test yapmaktan daha zor. Bazı sonuçlar net: eksik dil sürümü, yanlış URL, dönüş etiketi yok. Bazıları ise daha nüanslı.
Yaygın bir yorum hatası şu: Search Console hreflang raporu temiz göründüğünde her şeyin yolunda olduğu varsayılıyor. Hreflang hatalarının büyük bölümü bu raporda görünmüyor. Rapor yalnızca belirli hata tiplerini yakalıyor; sessiz hataları değil. Temiz rapor, aktif doğrulama sonucu değil yalnızca bilinen hata yokluğu anlamına geliyor.
Başka bir yorum tuzağı: tarayıcıda kaynak kodda hreflang görülüyor ve "kurulum tamam" sonucuna varılıyor. Ama o sayfanın canonical'ı başka bir URL'ye işaret ediyorsa, hreflang etiketleri büyük ölçüde işlevsiz. Canonical etiketin hreflang ile ilişkisi test sürecinde her zaman birlikte değerlendirilmeli.
Bir testin "geçer" sayılması için minimum eşik şunlar: tüm dil sürümleri sette mevcut, her URL doğru sayfaya işaret ediyor, karşılıklı referanslar tam, canonical kendini gösteriyor, etiketler <head>'de yer alıyor. Bu beş koşul sağlandığında kurulumun teknik temeli sağlam. İçerik eşleşmesi ve arama niyeti uyumu ayrı bir değerlendirme konusu.
Yayın öncesi ve sonrası kontrol protokolü
Test tek seferlik değil döngüsel. Çok dilli bir site için yayın öncesi ve yayın sonrası olmak üzere iki ayrı protokol kurmak, hataların birikmesini önlüyor.
Yayın öncesi protokol şunları kapsıyor: yeni dil sürümü veya büyük yapısal değişiklik öncesinde temsili URL setiyle tam doğrulama, canonical-hreflang çatışması kontrolü, sitemap'te yeni URL'lerin eklendiğinin teyidi ve tarayıcı render testinin geçilmesi. Bu kontrol listesi her büyük değişiklikten önce çalıştırılıyor; küçük içerik eklemelerinde değil.
Yayın sonrası protokol farklı bir ritimde işliyor. İlk hafta: Search Console'da yeni URL'lerin indexlenme durumunu takip et, hreflang hata raporunu kontrol et. İlk ay: hedef dil sorgularında sıralama değişimlerini izle, beklenmedik bir düşüş varsa hreflang setini yeniden doğrula. Üç ay: tüm dil sürümlerini kapsayan kapsamlı bir tarayıcı denetimi çalıştır.
Bu protokolün değeri birikimli. Tek bir büyük sorun yaşandıktan sonra tepki vermek yerine, küçük sapmaları erken aşamada yakalamak toplam düzeltme maliyetini düşürüyor. Özellikle içerik eklenip kaldırılan, eklentiler güncellenen ve katalog büyüyen mağazalarda bu döngü olmadan yapı zamanla bozulmaya başlıyor.
Teknik SEO denetim listesini bu protokole entegre etmek, hreflang testini genel teknik sağlık kontrolüyle aynı ritme bağlıyor. Hreflang'a özgü kontroller ayrı bir kategori olarak listeye eklendiğinde, ne zaman ve ne bakılacağı belirsizlikten çıkıp sistematik bir sürece dönüşüyor.
Hreflang testi, kurulumun doğruluğunu onaylayan son adım değil; yapının sağlığını sürekli izleyen bir döngü. Site büyüdükçe, değiştikçe ve yeni pazarlar eklendikçe bu döngünün çalışmaya devam etmesi gerekiyor.
Başlamak için büyük bir altyapı gerekmiyор. Birkaç temsili URL'nin kaynak kodu ve DOM'u, bir karşılıklı referans kontrolü ve Search Console raporu — bunlar küçük bir mağaza için yeterli başlangıç noktası. Ölçek büyüdükçe araçlar ve otomasyon devreye giriyor; ama temelin mantığı aynı kalıyor: kurulumun bitmesi ile doğru çalıştığının bilinmesi aynı şey değil.