Hreflang Tag’leri Çoklu Lokasyon Hosting’de Nasıl Kurulur?

Giriş

Çoklu lokasyon (multi-region) hosting ve CDN kullanıldığında sayfalar farklı sunucu bölgelerinde farklı hızlarda açılır. Ancak arama motorlarının URL’leri doğru dil ve ülke eşleştirmesi için hreflang etiketleri tek bir şarta bağlıdır: Her HTML yanıtında, doğru URL setiyle tutarlı biçimde bulunması gerekir. Bu içerikte; çoklu lokasyon mimarisinde (ör. CDN edge + origin) hreflang etiketlerinin nasıl üretileceğini, önbellek ve yönlendirme kaynaklı bozulmaları nasıl tespit edeceğinizi ve pratikte nasıl doğrulayacağınızı adım adım öğreneceksiniz.

Çoklu lokasyon hosting hreflang’ı neden “bozabilir”?

Multi-region altyapıda problem genellikle etiketin kendisinden değil, etiketin üretildiği anda hangi içeriğin döndüğünden kaynaklanır.

Yaygın bozulma senaryoları

• Edge cache (CDN önbelleği) dil/ülke bazlı varyasyonu farklılaştırmıyor: Aynı önbellek girdisi farklı bölgeden gelen kullanıcılara aynı HTML’i verir.
• Originden üretilen hreflang listesi dinamik ama cache-key’i yetersiz: Dil seçimine bağlı içerik üretiliyor fakat önbellek anahtarı (cache key) dili dikkate almıyor.
• HTTP 301/302 ön yönlendirmeler hreflang’ı yarım bırakıyor: Arama motoru yönlendirme sonrası doğru sayfayı görmeden önce etiketler yanlış URL’lerle kaydoluyor.
• İçerik parçalama (template) uyumsuz: Bazı lokasyonlarda farklı tema/şablon sürümü çalışıyor ve hreflang blokları eksik çıkıyor.
• Canonical ile hreflang çelişiyor: canonical farklı ülke sayfasına gidiyor, hreflang ise başka bir URL kümesi öneriyor. Arama motoru “hangisi doğru?” sorusunu çözemiyor.

Bu yüzden çoklu lokasyon senaryosunda hedef şudur: hreflang etiketleri her bölgede aynı URL setiyle, aynı mantıkla üretilmeli ve doğru varyasyonla önbelleğe alınmalıdır.

Doğru hreflang stratejisi: “Lokasyon bazlı değil, dil/ülke bazlı varyasyon”

Hreflang etiketleri CDN veya sunucu bölgesine göre değişmez; değişmesi gereken şey dil ve ülke varyantlarıdır. Çoklu lokasyon hosting’de bunu korumanın temel kuralı şudur:

• Tek bir “sayfa ailesi” (page family) oluştur: Aynı içeriğin en, tr, de gibi sürümleri.
• Her sürümün kendi kalıcı URL’si olsun: Örn. /tr/urun/abc, /en/product/abc.
• Hreflang sadece bu URL’leri tarif etsin: x-default dahil.

Örnek hreflang seti

Aşağıdaki yapı, çoklu lokasyonda da aynı kalmalıdır: - tr-TR -> Türkiye Türkçesi sayfası - en-US -> ABD İngilizcesi sayfası - x-default -> Dil tespiti yapılamadığında genel sayfa

<link rel="alternate" hreflang="tr-TR" href="https://example.com/tr/urun/abc" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/product/abc" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Çoklu lokasyonda kurulum: adım adım teknik kontrol

Aşağıdaki adımlar, “etiket var ama yine de hata alıyorum” durumlarını sistematik biçimde çözer.

1) URL mimarinizi kilitleyin

Hreflang, URL doğruluğuna dayanır. Çoklu lokasyonda üretim hatası görmenin en sık sebebi URL’lerin farklı bölgelerde farklı normalization’a uğramasıdır.

• Tüm dil sürümleri için tek bir canonical standardı belirleyin.
• URL sonu slash (son /), büyük/küçük harf ve query parametreleri yönetimini sabitleyin.
• İndekslenmeyecek varyantlarda (ör. taslak, arama sonuçları) hreflang yayınlamayın.

2) CDN önbelleğini “dil varyasyonu” ile eşleştirin

Multi-region CDN kullanıyorsanız edge katmanının sizin için yanlış HTML döndürmesi mümkündür. Kuracağınız varyasyon şu olmalı:

• Eğer dil route üzerinden belirleniyorsa (/tr/..., /en/...): cache key path’i dil yolunu içermelidir.
• Eğer dil header/cookie ile seçiliyorsa (Accept-Language, lang cookie): cache key’e bu bileşenler dahil edilmelidir.

Pratik hedef: Aynı URL (aynı path) için aynı bölgede aynı HTML dönecek şekilde cache davranışı kurun. Hreflang’ın değişmesi gerekmiyorsa cache-key’i lokasyona göre değiştirmenize gerek yoktur.

3) Hreflang’ı tek yerde üretin: server-side şablon

Çoklu lokasyonda client-side (JS ile) hreflang üretimi güvenilir değildir. Arama motorları her zaman JS’i aynı şekilde işleyemez.

• Hreflang etiketlerini server-side olarak, her lokasyonda aynı şablon kaynağından üretin.
• Template’te “dile göre seçenekler” varsa aynı kural setini kullanın.
• Şablon sürümü farklıysa (özellikle birden fazla origin) bazı bölgelerde etiket eksik kalır.

4) Redirect kuralını hreflang ile uyumlu yapın

Ön yönlendirme (301/302) hreflang doğrulamasını zorlaştırır.

• Dil tespiti yapan redirect’ler için hedef URL her zaman nihai canonical URL olmalı.
• 301 dönüşümlerde hreflang yayınlanan sayfanın kendisi indekslenebilir olmalı.

Örnek kural: - /tr -> https://example.com/tr/ (301) - / -> https://example.com/ (hreflang seti içerir, x-default burada yer alır)

5) X-default’u “dil seçimi yapılamayan” sayfaya bağlayın

x-default rastgele bir sayfaya işaret ederse arama motoru dil eşleşmesi konusunda hata alabilir.

• Kullanıcı ülkesine/diline göre otomatik yönlendirme yapıyorsanız bile x-default sabit bir “genel” URL olmalıdır.
• Multi-region’da, x-default URL’si her lokasyonda aynı içeriği sunmalıdır.

Karşılaştırma: Çoklu lokasyonda hreflang yönetimi yaklaşımları

Aşağıdaki tablo, iki yaygın yaklaşımı “başarı/riski” açısından netleştirir.

Net öneri: Multi-region altyapıda ilk hedef “tutarlılık” olmalı. Eğer dinamik üretim kullanıyorsanız cache-key ve şablon sürümünü birlikte standardize edin.

Doğrulama: Hreflang hatasını lokasyon kaynaklı mı anlamalısınız?

Hreflang doğrulamasında yalnızca “etiket var mı” değil, “aynı URL için tüm bölgelerde aynı etiket seti mi geliyor” sorusu kritik.

1) Aynı URL’yi farklı bölgelerden test edin

• CDN provider’ın sunduğu test/trace araçlarını kullanın (varsa).
• En az 2 farklı bölgeden (örn. Avrupa ve Türkiye/Orta Doğu edge) aynı path’i açın.
• Sayfa kaynağında rel="alternate" etiketlerini karşılaştırın.

Beklenen: URL değişmediği sürece etiket seti birebir aynı olmalı.

2) Google Search Console’da yaygın uyarıları kontrol edin

Arama motoru şu tür hatalara daha sık düşer: - Eksik karşılıklı bağlantılar (ör. A sayfasında B’ye referans var ama B’de A yok) - Geçersiz dil/ülke kodu (örn. yanlış format) - canonical ile çelişki - Yönlendirme sonrası uyumsuzluk

Çoklu lokasyonda bu hatalar bazen “tamam, etiket doğru” zannedilmesine rağmen, edge cache yüzünden belirli bölgelerde eksik çıkınca ortaya çıkar.

3) Cache’den kaynaklı farklı içerik tespit listesi

Aşağıdakilerden biri varsa hreflang tutarsızlığı yüksektir: - Aynı URL için response header’larında farklı Content-Type, farklı HTML body - Cache hit/origin hit oranı bazı bölgelerde farklı - Cookie/Accept-Language’a göre HTML değişiyor ama cache-key ayarlanmadı

En sık yapılan 6 hata (çoklu lokasyon özelinde)

1. Hreflang’ı client-side render ile üretmek: Bazı bot’lar JS sonrası kaynağı aynı şekilde görmez.
2. Cache-key’e dil bilgisini eklememek: Cookie ile dil seçiliyorsa en büyük risk budur.
3. Canonical’ı tek bir URL’ye zorlamak: Her dil sürümü kendi canonical’ına sahip olmalı.
4. Yönlendirme zincirleri: 302 sonrası 301 gibi zincirler hreflang doğrulamasını bozabilir.
5. x-default’u dil yönlendirme sayfası yapmak: x-default sabit olmalı.
6. Origin sunucu sürümlerinin farklı olması: Bir lokasyonda şablon güncel değilse hreflang eksik kalır.

Sonuç: Aksiyon planı (hemen uygulanabilir)

Çoklu lokasyon hosting’de hreflang’ın doğru çalışması için en kritik iki adım şunlardır: (1) hreflang etiketlerini server-side ve tek şablondan üretmek, (2) CDN önbelleğinde dil/ülke varyasyonunu URL path’i üzerinden deterministik hale getirmek. İlk gün için şu kontrolleri yapın: aynı URL’yi en az iki farklı edge bölgesinden açın, rel="alternate" etiket setinin birebir aynı geldiğini doğrulayın; ayrıca canonical ile hreflang arasındaki URL ilişkisini tek standarda bağlayın. Bu kontrolleri tamamladığınızda “hreflang var ama yine de hata alıyorum” problemlerinin büyük kısmı lokasyon/önbellek kaynaklı şekilde çözüme kavuşur.