Uluslararası sitelerde hreflang hataları nasıl bulunur, düzeltilir?

Hreflang hataları nasıl bulunur: önce doğru denetim kapsamını kurun

Hreflang, sıralama artıran sihirli bir etiket değil; aynı veya çok benzer içeriğin farklı dil ya da bölge sürümlerini arama motoruna doğru eşleştirme sinyalidir. Bu yüzden ilk soru “etiket var mı” değil, “gerçekten hreflang gerektiren bir yapı var mı” olmalıdır. Tek dilde yayın yapan, yalnız para birimi veya lojistik farkı sunan birçok sitede gereksiz hreflang kullanımı, çözümden çok yeni hata üretir. Özellikle uluslararası e-ticaret, SaaS dokümantasyonu ve çok pazarlı içerik sitelerinde gereklidir.

İkinci adım, yapının çok dilli mi yoksa çok bölgeli mi olduğunu netleştirmektir. İngilizce içerik hem ABD hem Birleşik Krallık için ayrıysa en-US ve en-GB düzeyinde çalışırsınız; yalnız Türkçe ve İngilizce sürüm varsa çoğu zaman tr ve en yeterlidir. Denetime başlamadan önce URL envanteri, her varyantın canonical hedefi, indexlenebilirlik durumu ve gerekirse x-default sayfası tek listede toplanmalıdır. Kavramları aynı dilden konuşmak için kısa bir SEO terimleri sözlüğü bakışı faydalıdır. MDN’nin hreflang referansı 2 Haziran 2025’te güncellendi; ancak SEO uygulamasında birincil yorum kaynağı yine Google’dır.

• Envanteri çıkarın: Her dil ve bölge varyantını tek tabloda toplayın.
• Kümeyi netleştirin: Hangi URL hangi eşdeğer sayfalarla eşleşiyor belirleyin.
• x-default kararını verin: Dil seçici veya genel fallback sayfa varsa baştan işaretleyin.
• Gereksiz kullanımı ayıklayın: Aynı dilde tek sürüm varsa hreflang eklemeyin.

Search Console, URL Inspection ve crawl ile hata tespiti

Hreflang hatası avında en büyük kayıp, yalnız tek araca bakmaktır. Doğru akış, aynı URL kümesini rendered HTML, XML sitemap ve HTTP header seviyesinde çapraz kontrol etmektir. Çünkü bazı hatalar kaynak kodunda görünür, bazıları render sonrası ortaya çıkar, bazıları ise yalnız PDF gibi non-HTML dosyalarda header üzerinden yakalanır. Sitemap içinde doğru görünen bir anotasyonun sayfa kaynağında eksik olması ya da JavaScript sonrası head içine hiç yazılmaması sık rastlanan bir çelişkidir.

Burada Google Search Console URL Inspection dokümanı kritik bir teşhis noktası sunar: URL’nin dizinde olup olmadığı, kullanıcı tarafından belirtilen canonical ile Google-selected canonical’ın örtüşüp örtüşmediği ve canlı testte sayfanın erişilebilirliği aynı ekranda okunabilir. Özellikle hreflang kümesi doğru görünse bile Google başka bir canonical seçiyorsa, problem çoğu zaman yanlış hedef URL, zayıf self-reference veya canonical çakışmasıdır. Search Console size sinyal verir; asıl nedeni bulmak için crawl verisi gerekir.

• Rendered HTML kontrolü: Tarayıcıda oluşan son head çıktısında tüm varyantları arayın.
• Sitemap kontrolü: Aynı URL kümesinde eksik varyant, yanlış hedef ve 3xx bağlantıları ayıklayın.
• Header kontrolü: PDF, feed veya non-HTML dosyalarda Link header anotasyonlarını doğrulayın.
• Canonical okuması: User-declared ve Google-selected canonical ayrımını not edin.

Operasyonda bu işi elle sürdürmek zor olduğunda, aynı kümeyi düzenli taramak için bir site sağlığı denetimi katmanı pratik olur. Önemli olan araç adı değil, aynı URL grubunu her taramada aynı mantıkla ölçmektir; aksi halde hreflang hataları dağınık raporlara bölünür ve kök neden geç görünür.

Dil-bölge kodu, return tag ve yanlış URL hatalarını düzeltme

En yaygın teknik hata, kodların biçimini yanlış kurmaktır. Google’ın Localized Versions of your Pages belgesine göre hreflang etiketlerinde dil kodu temel sinyaldir; bölge kodu ise gerektiğinde eklenir. Bu mantık, ISO 3166 ülke kodları ve RFC 5646 sözdizimiyle uyumludur. Doğru örnekler en-GB, en-US ve tr-TR olabilir; yalnız ülke kodu kullanmak, örneğin yalnızca GB veya TR yazmak geçerli değildir. Bölgeyi abartılı ayrıntıyla eklemek de gerekmez; içerik gerçekten ülkeye göre ayrışmıyorsa en tek başına daha temizdir.

• Yanlış: hreflang=’TR’ yalnız ülke kodudur ve geçersizdir.
• Doğru: hreflang=’tr-TR’ dil ve bölgeyi birlikte tanımlar.
• Yanlış: 3xx veren ya da kanonikle başka sayfaya giden URL’yi hedef göstermek.
• Doğru: 200 dönen, indexlenebilir, kendine canonical veren eşdeğer URL’yi işaret etmek.

Eksik self-reference ve missing return tags ikinci büyük hata sınıfıdır. A sayfası B’yi işaret ediyorsa, B’nin de A’yı işaret etmesi gerekir; her varyant ayrıca kendisini de listelemelidir. Uygulamada sık bozulan yer, yeni locale açıldığında yalnız o locale’nin eklenmesi ve eski sayfaların head ya da sitemap kayıtlarının güncellenmemesidir. Bu durumda küme asimetrik kalır ve Google anotasyonların bir bölümünü yok sayabilir.

Düzeltme tarafında en güvenli yöntem, tek tek sayfa düzeltmek yerine merkezi URL envanterini güncellemektir. Önce canlı kalan 200 URL’leri filtreleyin, sonra her satırda self-reference, karşılıklı dönüş etiketi, doğru dil-bölge kodu ve aynı içerik eşdeğeri mantığını doğrulayın. Eğer hedef URL 301 veriyorsa, noindex ise ya da canonical başka varyanta gidiyorsa hreflang etiketi doğru görünse bile küme teknik olarak kusurludur.

Canonical, x-default ve yönlendirme çakışmalarını çözme

2026’da hâlâ en yıpratıcı hata, hreflang ile canonical’ı ayrı sistemler gibi yönetmektir. Google’ın 27 Mart 2026 tarihli canonical URL dokümanı, hreflang kullanılan sayfalarda canonical’ın mümkün olduğunca aynı dildeki eşdeğer sürüme işaret etmesi gerektiğini vurgular. İngiltere sayfasını ABD sayfasına canonical’lamak, sonra da hreflang ile en-GB demek çelişkidir. Pratikte Google önce güçlü canonical sinyallerini takip eder; bu nedenle yanlış canonical, doğru hreflang kümesini etkisiz bırakabilir.

x-default, her kullanıcıyı otomatik yönlendirmek için değil, eşleşmeyen dil-bölge istekleri ve dil seçici sayfalar için güvenli fallback üretmek için kullanılır. Google’ın Managing Multi-Regional and Multilingual Sites belgesi de Accept-Language tabanlı agresif yönlendirmelerin keşif ve kullanım sorunları yaratabileceğini açıkça anlatır. Kullanıcı sayfaya ulaştıktan sonra dil önerisi sunmak güvenlidir; botu ya da kullanıcıyı geri dönemez biçimde başka locale’ye zorlamak çoğu zaman yeni canonical ve tarama problemleri doğurur.

• Shopify: Tema ya da uygulama, head içine iki farklı hreflang seti yazabilir; yinelenen etiketleri kaldırın.
• WordPress: Çok dilli eklenti ile SEO eklentisi ayrı canonical üretirse önce kanonik mantığı tekleştirin.
• Headless/Next.js: SSR ile client-side head güncellemesi farklı çıktılar üretiyorsa yalnız rendered HTML’ye güvenmeyin, kaynak ve canlı render’ı birlikte kontrol edin.

İlgili video kaynak olarak Google Search Central’ın çok dilli ve çok bölgeli site yönetimi anlatımları faydalıdır; fakat günlük hata ayıklamada asıl belirleyici, sizin kendi şablon çıktınızı ve yönlendirme mantığınızı satır satır doğrulamanızdır.

20 ülke, 12 dil teardown: HTML, sitemap ve header ne gösterdi?

Bu rehberin en pratik kısmı, 20 ülke ve 12 dil varyantı olan bir projede yaptığımız teardown mantığıdır. Aynı şablon ailesine ait varyant URL’leri aynı gün içinde rendered HTML, XML sitemap ve URL yanıt başlıkları üzerinden karşılaştırdığımızda, Search Console’un tek başına göstermediği sorunlar net biçimde ayrıştı. HTML tarafında bazı locale’lerde client-side head güncellemesinin geç çalıştığını, sitemap tarafında yeni açılan varyantların tüm eski sürümlere dönmediğini, header tarafında ise PDF dosyalarının sessizce küme dışına düştüğünü gördük. Sorun, etiketin var olup olmamasından çok, tüm katmanların aynı URL gerçekliğini yansıtıp yansıtmamasıydı.

Bu tür teardown’larda Search Console değerli ama eksik bir aynadır. Genellikle yanlış canonical seçimi, erişilebilirlik sorunu veya dizine alınmama sinyali verir; fakat eksik return tag zincirini, yinelenen head üretimini ya da non-HTML varlıkların hreflang eksikliğini tam açıklamaz. Crawler ise kümeyi toplu okuduğu için asimetrik eşleşmeleri ve 3xx hedefleri daha hızlı yakalar. Header kontrolü de özellikle katalog PDF’leri, teknik dökümanlar ve medya kütüphaneleri olan sitelerde kritik fark yaratır.

• Rendered HTML şablon ve JavaScript kaynaklı head hatalarını görünür kıldı.
• XML sitemap yeni locale eklendiğinde unutulan karşılıklı eşleşmeleri ortaya çıkardı.
• HTTP header HTML dışında kalan dosyalardaki sessiz eksikleri yakaladı.

Buradaki deneyim dersi şu: yalnız Search Console’a bakarsanız semptom görürsünüz, üç katmanı birlikte okursanız kök neden bulursunuz. Özellikle büyük uluslararası yapılarda hangi yöntemin hangi dosya türünde daha güvenilir olduğunu baştan belirlemek, sonraki deploy’larda hatanın yeniden üretilmesini ciddi biçimde azaltır.

Düzeltme sonrası doğrulama, izleme ve SEOYEN ile operasyon

Düzeltme bittiğinde iş tamamlanmış sayılmaz. Önce kritik URL kümesini yeniden crawl edin, sonra XML sitemap’ı güncelleyin, ardından yüksek öncelikli sayfalarda canlı test ve indeksleme sinyallerini tekrar okuyun. Hedef, yalnız etiketin görünmesi değil; doğru canonical, erişilebilir URL, karşılıklı eşleşme ve locale bazlı görünürlük sinyalinin birlikte toparlanmasıdır. Özellikle kategori, ürün, fiyatlandırma ve ülke giriş sayfaları önce kontrol edilmelidir; çünkü yanlış eşleşmenin en pahalı etkisi genelde burada görülür.

Operasyon tarafında SEOYEN’in değeri, bu süreci tek seferlik bir temizlik yerine sürekli denetim döngüsüne çevirmesidir. Hreflang kümelerini periyodik izlemek için site sağlığı denetimi katmanı, düzeltme sonrası locale etkisini görmek için sıralama takibi ile ülke bazlı görünürlük yaklaşımı doğal bir akış sunar. Türkçe arayüz, TL bazlı planlama ve yerel destek, özellikle teknik ekip ile pazarlama ekibinin aynı raporu yorumlamasında sürtünmeyi azaltır. Güncel yapı için paket ve abonelik detayları sayfası yeterlidir; burada sabit rakam vermemek daha sağlıklı bir içerik ömrü sağlar.

• Deploy sonrası QA: Yeni şablon veya locale açılışında örnek URL kümesini hemen test edin.
• Aylık denetim: Kırılan return tag, 3xx hedef ve canonical kaymalarını tarayın.
• Görünürlük izlemesi: Ana ülke ve dil kümelerinde landing page değişimini takip edin.
• İç süreç: İçerik, geliştirme ve SEO ekipleri aynı envanter dosyasında çalışsın.

2026 itibarıyla en sürdürülebilir yaklaşım, hreflang’i yalnız teknik SEO görevi olarak değil, yayın operasyonunun parçası olarak ele almaktır. Yeni sayfa tipi, yeni ülke veya tema güncellemesi çıktığında hreflang QA adımı otomatikleşmezse, eski hata desenleri birkaç deploy içinde geri döner.

Adım Adım Hreflang hatalarını bulma ve düzeltme akışı

Uygulamada en az hata veren sıra, tespit ve düzeltmeyi aynı akışta toplamaktır. Önce kümeyi tanımlayıp sonra katmanları okumak, en son da canonical ve yönlendirme mantığını hizalamak gerekir. Aşağıdaki sıra, hem küçük ekiplerde manuel denetim hem büyük yapılarda süreç standardı olarak çalışır.

1. Varyant URL envanterini çıkarın: Tüm dil ve bölge sürümlerini, canonical hedeflerini ve indexlenebilirlik durumunu tek listede toplayın.
2. Üç katmanda işaretleri karşılaştırın: Rendered HTML, XML sitemap ve HTTP header anotasyonlarını aynı URL kümesi üzerinde kontrol edin.
3. Kod ve eşleşmeleri doğrulayın: Dil-bölge kodları, self-reference, return tag ve x-default kullanımını standartlara göre gözden geçirin.
4. Canonical ve yönlendirmeleri hizalayın: Farklı dil varyantına canonical vermeyin; zorunlu yönlendirmeleri kullanıcı dostu fallback mantığıyla güncelleyin.
5. Yeniden crawl ve izleme başlatın: Düzeltme sonrası kritik sayfaları tekrar test edin, sitemap’ı yenileyin ve locale görünürlüğünü izleyin.

Bu akışın avantajı, hreflang’i dağınık etiket kontrolünden çıkarıp ölçülebilir bir kalite sürecine dönüştürmesidir. Özellikle uluslararası sitelerde sorun çoğu zaman tek URL’de değil, bütün kümenin birbiriyle çelişmesinde ortaya çıkar; bu yüzden düzeltme de küme mantığıyla yapılmalıdır.

Sıkça Sorulan Sorular