Hreflang kullanılan Türkçe sitelerde en sık görülen uygulama hataları

Hreflang kullanılan Türkçe sitelerde hata neden kurulum aşamasında başlar?

Hreflang sorunlarının büyük bölümü etiket yazımında değil, yanlış eşleme tablosunda başlar. Ekip önce hangi URL’nin hangi dili ve gerekiyorsa hangi bölgeyi hedeflediğini netleştirmeden etiket basarsa, sonradan yüzlerce sayfada aynı hata çoğalır. Google Search Central’ın 22 Aralık 2025’te güncellenen rehberi, ilk değerin dil, ikinci değerin ise isteğe bağlı bölge olduğunu ve yalnız bölge kodunun geçerli olmadığını açıkça hatırlatıyor. 2026’da çok dilli Türkçe sitelerde en sık gördüğümüz kırılma noktası tam olarak bu ilk haritalama aşaması.

Pratikte şu ayrımı net yapmak gerekir: tüm Türkçe içerik tek dil hedefliyorsa tr yeterlidir; yalnız Türkiye pazarına özel farklı varyasyon varsa tr-TR anlam kazanır; İngilizce içerik Türkiye kullanıcısına özel hazırlanmışsa en-TR kullanılabilir. Buna karşılık yalnız TR yazmak, UK kullanmak ya da tr_TR gibi alt çizgili biçimler üretmek kümenin güvenilirliğini düşürür. Google aynı dokümanda UK gibi ayrılmış olmayan bölge kodlarının etkisiz kalacağını da not eder.

Kurulum öncesi kısa karar ağacı

• .com/tr yapısı, tek domain altında merkezi yönetim isteyen ekipler için genelde en kolay modeldir.
• Subdomain yapısı, ülke veya ekip bazlı ayrı yayın akışı olan projelerde daha nettir.
• .com.tr ve farklı ccTLD yapıları, pazara özel güven sinyali verir ama hreflang bakımını zorlaştırır.
• HTML head, XML sitemap ve HTTP header yöntemlerinden birini ana kaynak seçmek çifte bakım riskini azaltır.

Google, HTML, HTTP header ve XML sitemap yöntemlerini destekler; ancak üç yöntemi aynı anda farklı ekiplerin yönetmesi genelde tutarsızlık üretir. PDF gibi HTML dışı dosyalar yoksa tek kaynağı çoğu zaman HTML head veya sitemap yapmak daha sürdürülebilirdir. Ekip içinde kavram birliği kurmak için SEO terimleri sözlüğü gibi ortak bir referans sayfası da süreci hızlandırır.

En sık görülen hreflang uygulama hataları nelerdir?

İlk büyük hata kümesi return tag ve self-reference eksikliğidir. Bir sayfa başka dil sürümünü işaret edip karşı sayfa geri dönmüyorsa, Google bu ilişkiyi yok sayabilir. Google’ın resmi rehberi her varyasyonun kendisini ve diğer varyasyonları işaretlemesi gerektiğini açık biçimde belirtir. Özellikle kategori ve ürün şablonlarında tek taraflı ilişki sık görülür; çünkü ekip yalnız ana dili günceller, ikincil dil şablonunu unutabilir.

İkinci büyük hata canonical ile hreflang’in birbirine ters sinyal vermesidir. Türkçe sayfanız kendi kanonik URL’sine işaret etmek yerine İngilizce versiyona canonical veriyorsa, hreflang kümesi kağıt üzerinde doğru görünse bile Google kanonik sinyali daha baskın okuyabilir. Google’ın 27 Mart 2026 tarihli canonical dokümanı, hreflang kullanıyorsanız aynı dilde bir canonical belirtmenizi, bu mümkün değilse en iyi ikameyi seçmenizi önerir. Yani canonical ve hreflang aynı eşdeğerlik mantığı üzerinde kurulmalıdır.

• x-default eksikliği, dil seçici veya genel uluslararası açılış sayfalarında yanlış inişleri artırır.
• Yanlış hedef sayfa seçimi, blog yazısını kategoriye ya da ürün detayını listeleme sayfasına bağlar.
• Absolute URL kullanılmaması, ortam değişince test veya staging adreslerinin canlı kümeye sızmasına yol açar.
• HTTP/HTTPS karışıklığı, canonical ve hreflang kümelerini ikiye böler.
• Parametreli kopya URL’ler, gerçek eşdeğer yerine filtreli veya kampanyalı versiyonların işaretlenmesine neden olur.
• Yalnızca şablonu çevrilen sayfalar, içerik gerçekten eşdeğer değilse hreflang için zayıf adaydır.

HTML tarafında da hata çoktur. MDN’nin 20 Nisan 2026’da güncellenen rel referansına göre rel=”alternate” ile birlikte kullanılan hreflang, mevcut dokümanın başka dilde veya alternatif temsilini anlatır. Bu yüzden etiketin body içine düşmesi, bozuk head yapısı içinde kalması veya yanlış sayfaya çevrilmiş içerik göstermesi teknik olarak geçerli görünse bile arama motoru açısından işe yaramaz bir kurgu üretir.

Hreflang hataları Search Console ve crawl ile nasıl doğrulanır?

En sağlıklı teşhis akışı üç kaynağı birlikte okumaktır: Search Console uyarısı, canlı kaynak kod ve crawl exportu. Tek başına yalnız kaynak koda bakarsanız yönlendirmeyi kaçırırsınız; yalnız crawl verisine bakarsanız template’in hangi sayfada bozulduğunu göremezsiniz. Bu nedenle önce uyarıyı hata tipine göre sınıflandırın, sonra aynı URL kümesini canlıda açın ve en son tarama verisinde canonical, status code ve indexlenebilirlik kolonlarını karşılaştırın.

• 3xx dönen hreflang hedefleri
• 4xx ve 5xx kırık hedefler
• 200 dönen ama noindex olan alternatifler
• Canonical’ı başka dile giden sayfalar
• Head içindeki etiket ile sitemap satırı uyuşmayan URL’ler
• Dil eşleşmesi yanlış olan veya eşdeğer olmayan açılış sayfaları

HTML head kontrolünde, her sayfanın kendisine ve tüm varyantlarına dönüp dönmediğini tek tek görmek gerekir. Sitemap tarafında ise aynı URL için listelenen alternatif bloklarının head tarafıyla birebir eşleşmesi gerekir. MDN, rel=”alternate” ve hreflang kombinasyonunun çeviri veya alternatif temsil ilişkisi kurduğunu açıklar; bu ilişki sitemap’te başka, head içinde başka ise sorun etiketin varlığı değil, tutarsız veri kaynağıdır.

Geliştiriciye iletilecek kontrol listesinde en az dört alan zorunlu olmalı: status code, canonical hedefi, indexlenebilirlik ve dil eşleşmesi. Bu dört kolon olmadan yapılan düzeltmeler yarım kalır. Düzenli denetim için tek ekrandan filtrelenebilen bir site sağlığı taraması akışı kurmak, özellikle yüzlerce ürün veya kategori URL’si olan Türkçe e-ticaret sitelerinde hata ayıklamayı ciddi biçimde kolaylaştırır.

Adım Adım Hreflang hatasını doğrulama ve düzeltme akışı

Hreflang sorunlarını parça parça çözmeye çalışmak yerine, kısa ama disiplinli bir akış izlemek daha hızlı sonuç verir. Aşağıdaki sıra, hem geliştiriciye net görev çıkarmak hem de düzeltme sonrası yeniden doğrulama yapmak için pratik bir çerçeve sunar.

1. Dil ve bölge eşleşmelerini haritalandır: Her URL için hedef dil, gerekiyorsa bölge ve gerçek eşdeğer sayfa karşılığını tek tabloda topla.
2. Tek uygulama yöntemini seç: HTML head, XML sitemap veya HTTP header yöntemlerinden birini ana kaynak olarak belirle.
3. Return tag ve canonical uyumunu kontrol et: Her sayfanın kendisine ve alternatiflerine döndüğünü, canonical’ın bu yapıyla çakışmadığını doğrula.
4. 3xx ve 4xx hedefleri temizle: Yönlendiren veya kırık URL’leri doğrudan 200 açılan gerçek hedeflerle değiştir.
5. Search Console ve crawl ile yeniden doğrula: Düzeltme sonrası aynı kümeyi tekrar tarayıp kalan sapmaları önceliklendir.

Bu akışı uygularken teknik ekip için ekran görüntüsü, crawl exportu ve değişiklik notunu aynı ticket içinde toplamak faydalıdır. İsterseniz ekip içi eğitim için Google Search Central’ın resmi hreflang anlatımlarını kısa bir referans olarak kullanabilirsiniz; ancak asıl karar noktası her zaman canlı kaynak kod, sitemap ve response verisinin birbiriyle uyumudur.

50-100 URL’lik örnek crawl’da Türkçe sitelerde hangi hatalar öne çıkıyor?

50-100 URL’lik örnek crawl, özellikle Türkçe ve İngilizce sürümü olan sitelerde şablon kaynaklı bozulmaları görmek için yeterli bir ilk kesittir. Burada amaç tüm siteyi saymak değil, hata tiplerini kümelendirmektir. Benzer denetimlerde önce kategori, ürün ve bilgi sayfalarını ayrı segmentlerim; sonra her segmentte declared hreflang, return tag, status code, canonical ve indexlenebilirlik kolonlarını yan yana açarım. Bu yöntem küçük örneklemde bile hangi hatanın şablon, hangisinin tekil içerik kaynaklı olduğunu hızlıca ayırır.

• .com/tr kurgusunda en sık sorun, aynı şablonun tüm filtreli URL’lere alternates basmasıdır.
• .com.tr kurgusunda en sık sorun, ikinci domain açıldıktan sonra eski .com yollarının 3xx ile kümeye girmesidir.
• Ürün sayfalarında stoktan düşen URL’lerin 404 veya yönlendirme sonrası hâlâ hreflang içinde kalması yaygındır.
• Kategori sayfalarında yalnız şablon çevrilip içerik eşdeğerliği korunmadığında yanlış eşleşme artar.

Bu bölümde abartılı oran vermek yerine kanıt üretme yöntemi daha değerlidir: canlı kaynak kod ekran görüntüsü, export tablosu ve hata önceliklendirme matrisi. İlk 20 URL’de aynı bozuk kalıp tekrar ediyorsa, sorun büyük olasılıkla editörden değil şablondan gelir. Tam tersine hatalar yalnız birkaç ürün veya landing page’de yoğunlaşıyorsa, içerik ekibinin manuel bağlantı ya da yönlendirme değişikliği daha olası sebeptir.

Özellikle çok dilli e-ticaret sitelerinde mini vaka genelde benzer ilerler: kategori sayfaları doğru görünür, ancak ürün detaylarında kampanya parametreleri, eski dil seçici yönlendirmeleri veya stok dışı sayfa akışları hreflang’i bozar. Bu yüzden örnek crawl kümesine yalnız ana menü URL’lerini değil, farklı şablon türlerini de dahil etmek gerekir. Aksi halde rapor temiz görünür, gerçek sorun canlı trafikte kalır.

Canonical, x-default ve yönlendirme senaryolarında doğru düzeltme akışı

Sayfa silindiğinde, başka bir URL’ye yönlendirildiğinde veya yeni dil versiyonu açıldığında hreflang bakımı sırayla yapılmalıdır. Önce hedef URL gerçekten 200 açılıyor mu bakın; sonra canonical’ı düzeltin; en son hreflang kümesini güncelleyin. Tersini yaparsanız, kümeye eklediğiniz URL kısa süre sonra yönlendirmeye düşer ve aynı hata yeniden üretilir. Bu durum özellikle kampanya landing page’leri ve sezonluk kategori sayfalarında sık yaşanır.

Canonical kararında temel kural şudur: aynı içeriğin Türkçe sayfası varsa Türkçe sayfa kendi canonical’ına bakmalı, İngilizce sürüm de kendi canonical’ına bakmalıdır. Google’ın canonical dokümanı, hreflang kullanırken aynı dilde canonical belirtilmesini; bu mümkün değilse en iyi ikame dilin seçilmesini önerir. Yani canonical, dil varyasyonlarını birleştirmek için değil, aynı varyasyon içindeki kopyaları toplamak için kullanılır.

x-default ise dil seçici, ülke seçici veya genel uluslararası giriş sayfalarında anlamlıdır. Her sayfaya otomatik x-default vermek iyi uygulama değildir. Bir de içerik eşdeğerliği zayıfsa, sırf şablon çevrildi diye hreflang eklemekten kaçının. Ürün listesi Türkçe’de 40 öğe, İngilizce’de 5 öğe ve metinler de ciddi biçimde farklıysa bu sayfaları eşdeğer kabul etmek yerine ayrı hedefleme mantığı kurmak daha temizdir. Hreflang, benzer niyetli sayfalar için güçlüdür; alakasız varyasyonları aynı kümeye zorla sokmak için değil.

Hreflang denetimini SEOYEN ile nasıl operasyonelleştirirsiniz?

Hreflang denetimi tek seferlik bir kurulum işi değil, yaşayan bir bakım sürecidir. Bu yüzden status code, canonical ve hreflang verisini ayrı araçlarda gezmek yerine tek akışta toplamak daha verimlidir. SEOYEN içinde bir site sağlığı taraması kurgulayıp bozuk alternates, yönlendiren hedefler ve kanonik çakışmaları aynı listede topladığınızda, teknik ekip ile içerik ekibi aynı öncelik sırasına bakabilir. Türkçe arayüz burada küçük görünür ama günlük operasyon hızında ciddi fark yaratır.

Ahrefs, SEMrush, Moz, SE Ranking ve SEOptimer gibi platformların güçlü olduğu alanlar vardır; ancak Türkiye odaklı ekiplerde sorun çoğu zaman veriye ulaşmak değil, veriyi aksiyon listesine çevirmektir. SEOYEN bu noktada Türkçe arayüz, TL bazlı fiyatlandırma ve yerel destekle daha akıcı bir iş akışı sunar. Karşılaştırma yapmak isterseniz Ahrefs alternatifi ve SEMrush alternatifi sayfaları, hangi senaryoda hangi yaklaşımın daha pratik kaldığını netleştirir.

Küçük işletme sahipleri ve SEO uzmanları için kritik fark, raporun anlaşılır olması ve düzeltmenin gecikmemesidir. Bu yüzden hreflang denetimini yalnız teknik bir kontrol olarak değil, yayın operasyonunun parçası olarak düşünmek gerekir. Plan, deneme ve kapsam tarafını statik rakamlarla değil güncel bağlantı üzerinden incelemek isterseniz paket detayları sayfası yeterlidir. Buradaki amaç araç değiştirmek değil, çok dilli hata yönetimini daha az sürtünmeyle yürütmektir.

Sıkça Sorulan Sorular