Hreflang Çoklu Lokasyon Hosting’de Nasıl Kurulur? Net Rehber

Hreflang (hreflang tag) çoklu dil ve çoklu ülke hedeflemede arama motoruna hangi sayfanın hangi kullanıcıya uygun olduğunu anlatır. Çoklu lokasyon hosting (edge/CDN veya coğrafi olarak dağıtılmış uygulama sunucuları) devreye girdiğinde ise aynı URL farklı lokasyonlarda farklı içerik döndürebilir; bu da hreflang eşleşmelerini bozabilir. Bu rehberde, çoklu lokasyon kurulumlarında hreflang’ı tutarlı çalıştırmak için kontrol listesi, doğrulama yöntemleri ve sık hata senaryolarını net biçimde öğreneceksiniz.

Hreflang’ın çoklu lokasyonda “kırılma” sebebi

Çoklu lokasyon kurulumlarında istek kullanıcıya yakın sunucuya yönlenir. Bu, iki problem yaratır:

Aynı URL için farklı içerik / farklı canonical / farklı dil işaretleri
Farklı lokasyonlarda farklı header davranışı (ör. X-Robots-Tag, Location, Vary, dil tespiti)

Hreflang doğruluğu yalnızca etiketin doğru yazılmasına bağlı değildir. Etiketin işaret ettiği hedef sayfaların da gerçekten erişilebilir, indekslenebilir ve canonical ile uyumlu olması gerekir.

Kritik varsayım: “Aynı URL = aynı dil sinyali”

Çoklu lokasyon hostingde pratik kural şudur: Aynı path (ör. /tr/ veya /en-us/) tüm lokasyonlarda aynı dili, aynı canonical’i ve aynı hreflang setini vermelidir. Lokasyona göre farklı fragmentlar üretiliyorsa (dinamik içerik, kişiselleştirme, A/B test), hreflang setinin lokasyondan etkilenmediğinden emin olmanız gerekir.

Çoklu lokasyon hosting için doğru hreflang mimarisi

Hreflang’ı kurarken en sağlıklı yöntem, dil/ülke varyantlarını server-side olarak deterministik üretmektir. Yani bir lokasyonda hreflang="tr" dönerken başka lokasyonda hreflang="tr-TR" dönmemeli; ya da bir lokasyonda canonical example.com/tr/ iken diğerinde example.com/tr olmamalıdır.

1) Canonical ve hreflang eşleşmesini tek kaynaktan üretin

Aşağıdaki kombinasyon bozulduğunda arama motoru yanlış sinyal alır: - Hreflang hedefi (ör. https://example.com/en-us/) erişilebilir değil - Canonical farklı URL’ye gidiyor - Lokasyon bazlı redirect davranışı farklı

Uygulanacak net hedef: - Her dil/ülke varyantında <link rel="canonical" href="..."> her lokasyonda aynı değeri göstersin. - <link rel="alternate" hreflang="..." href="..."> değerleri de her lokasyonda aynı seti döndürsün.

2) X-default’i standartlaştırın

Çoklu lokasyonda kullanıcı yönlendirmesi bazen beklenmedik lander sayfasına düşebilir. Bu yüzden x-default alanını yalnızca “sayfa yoksa” gibi davranışlarla kullanmayın; tüm varyantların mantığıyla tutarlı bir x-default belirleyin.

Örnek mantık: - Kullanıcı dili bilinmiyorsa bir “ana dil” sayfası (ör. İngilizce global) gösteriliyor olabilir. - Bu karar tüm lokasyonlarda aynı URL’ye işaret etmeli.

3) Vary (Vary: Accept-Language) header’ını bilinçli kullanın

Bazı sistemler dil tespiti için Accept-Language gibi header’ları baz alır. Eğer CDN/edge cache bu header’a göre içerik saklıyorsa, lokasyondan lokasyona farklı varyasyonlar üretebilir.

Net kontrol: - CDN/edge tarafında dil varyantı için cache key’in gerçekten doğru parametreleri kullandığını doğrulayın. - Vary: Accept-Language kullanıyorsanız, bu davranışın hreflang setini değiştirmediğinden emin olun.

Multi-lokasyon ve CDN kullanırken hreflang’ın doğru şekilde “dökülmesi”

Çoklu lokasyon senaryosunda iki yer hreflang ile etkileşir: - Uygulama katmanı (PHP/Node/Java tarafında HTML çıktısı) - Ön uç katman (CDN/edge, WAF, reverse proxy, cache)

Sık hata: CDN’in HTML’i yanlış varyasyonda cache’lemesi

Örnek: Bir lokasyondaki kullanıcı en-us için HTML alıyor; aynı edge pop’ta cache key, dil bilgisini içermediği için diğer lokasyondaki tr kullanıcısına da aynı HTML’i dönüyor. Sonuç: hreflang tag’leri en-us setiyle tr sayfasında görünüyor.

Net çözüm yaklaşımı: - Dinamik HTML değişkenliğini CDN cache key’e yansıtın (ör. dil varyantına göre ayrı varyasyon). - Veya dil varyantı tamamen path tabanlıysa (ör. /tr/, /en-us/) cache key’te path kullanımı yeterlidir; Accept-Language ile kişiselleştirme yapmayın.

Sık hata: Lokasyonda farklı redirect zinciri

Örnek: Bir pop /tr -> /tr/ redirect ederken diğer pop /tr -> /tr/index.html gibi farklı bir rota döndürüyor. Canonical farklılaşır ve hreflang hedefleri anlamsız hale gelir.

Net kontrol: - Tüm lokasyonlarda redirect kurallarının aynı olduğundan emin olun. - Hreflang’ta kullandığınız URL’ler, redirect sonrası final URL ile birebir aynı olmalı.

Kontrol listesi: Kurulumdan sonra hreflang doğrulaması

Aşağıdaki adımlar, “doğru yazdım” hissini teknik kanıtla destekler.

1) Her lokasyonda aynı HTML çıktısını doğrulayın

Mümkünse 2–3 farklı coğrafyadan aynı path’i çağırın. Her çağrıda şu kontrolleri yapın: - <link rel="canonical"> aynı mı? - <link rel="alternate" hreflang> seti aynı mı? - x-default aynı mı?

Pratik araç yaklaşımı: - CDN varsa her pop’ı simüle edebilen test (edge location test) kullanın. - Alternatif: Farklı lokasyonlardan ayrı HTTP client ile GET alıp HTML içinde hreflang/canonical arayın.

2) Hreflang’ın işaret ettiği sayfaların indekslenebilirliğini doğrulayın

Aşağıdaki durumlar hreflang etiketini “görmezden” gelmenize yol açar: - Hedef sayfa noindex döndürüyor - Hedef sayfa robots.txt ile engellenmiş - Hedef sayfa 404 / 410 dönüyor

Net kontrol listesi: - Her hreflang hedef URL için status kodu 200 - Meta robots / X-Robots-Tag ile indeks engeli yok - Hedef sayfa canonical ile tutarlı

3) XML sitemap ve HTML içi hreflang uyumunu kontrol edin

Sitemap tek başına hreflang yerine geçmez; ama lokasyona bağlı üretim hatalarını yakalamaya yardımcı olur.

Net kural: - Sitemap içindeki hreflang mantığı ile sayfa içi hreflang mantığı aynı olmalı. - Örneğin sitemap’de en-US ile sayfa içinde en-us yazımı tutarsızsa bile bu eşleşmeyi karmaşık hale getirebilir. Dil/ülke formatını tek standarda çekin.

Lokasyon bazlı sunucu farklıysa (tema/konfig farkı) ne yapmalı?

Çoklu lokasyon kurulumlarında bazen her lokasyonda farklı PHP config, farklı template derlemesi veya farklı CMS cache politikası bulunur. Bu, hreflang’ın bozulmasında doğrudan etkili olur.

Konfig farkını yakalamak için “tek örnek HTML” yaklaşımı

Aynı varyant URL’sini (ör. https://example.com/tr/) tüm lokasyonlardan isteyin.
HTML’in başındaki canonical ve hreflang bloklarını karşılaştırın.

Eğer farklılık varsa, sorun büyük ihtimalle şunlardandır: - Template caching - CDN edge cache purge eksikliği - CMS’te dil alanlarının lokasyon bazlı yanlış set edilmesi - Backend’te ülke/dil tespiti kurgusu

Önerilen pratik: Dil varyantlarını path bazlı üretin

example.com/tr/ ve example.com/en-us/ gibi path tabanlı yapı tercih edin.
Böylece cache key mantığı daha basit olur ve lokasyona göre dil tahmini değişmez.

Net karşılaştırma: En yaygın senaryolarda doğru yaklaşım

Aşağıdaki tabloda, çoklu lokasyon hostingte hreflang için “en çok yapılan hata” ve “doğru yaklaşım” yan yana verilmiştir.

Senaryo	En sık hata	Net doğru yaklaşım
CDN/edge HTML cache yapıyor	Dil varyantını cache key’e almadan farklı kullanıcıya farklı hreflang gelmesi	Cache key’de path bazlı ayrım kullanın; dil varyantını path’ten türetin
Backend Accept-Language ile karar veriyor	Lokasyon/operatör bazlı header farkı ile hreflang seti değişmesi	Hreflang’ı path tabanlı belirleyin; Accept-Language sadece yönlendirme/otomatik tercih için kullanılsın
Redirect zinciri lokasyonlarda farklı	Canonical/hreflang URL eşleşmez	Redirect kurallarını tüm pop’larda standardize edin; hreflang’ta final URL’yi esas alın
CMS cache farklı lokasyonda farklı	Aynı URL’de farklı canonical/hreflang blokları	Konfig ve template sürümünü senkronlayın; cache purge stratejisi kurun
Hedef sayfa noindex veya erişilemez	hreflang “kör” bağlantı verir	Her hedef için indexlenebilirlik, 200 status ve robots uyumluluğu kontrol edin

Hreflang tag yazım standardı (biçim ve içerik)

Çoklu lokasyonda en az hata toleransı, yazım standardında olur. Aşağıdaki kurallar pratikte en çok sorun çıkaran konulardır.

Dil-ülke kodlarını tek standarda sabitleyin

tr-TR yerine tüm sitede tr-TR (veya tüm sitede tr) hangisi kullanılıyorsa aynı kalıbı koruyun.
en-us yerine aynı anda hem en-US hem en-us kullanmayın.

URL’leri mutlak (absolute) verin

Hreflang’ta href değerleri mutlak URL olarak verildiğinde yönlendirme ve göreli yol kaynaklı farklılaşmalar azalır.

Aynı sayfada kendine referans ekleyin

Bir varyant sayfasında o varyantın kendi hreflang’ı bulunmalıdır. Bu, arama motoru için “bu sayfa hangi dile aittir” bilgisini netleştirir.

Örnek: Çoklu dil için temel şablon (uygulanabilir kalıp)

Aşağıdaki kalıp, her lokasyonda aynı olacak şekilde uygulayın:

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

Buradaki kritik nokta: canonical değeri sayfanın kendisiyle aynı varyanta ait olmalı. Çoklu lokasyonda cache/redirect nedeniyle canonical başka URL oluyorsa hreflang seti kadar canonical de bozulur.

Ne zaman “hreflang doğru ama yine de sorun var” dersiniz?

Eğer hreflang tag’leri doğru görünüyor ama indeksleme/yerleşim beklediğiniz gibi değilse, çoğunlukla şu alanlarda problem çıkar: - Hreflang’ın işaret ettiği sayfalar farklı canonical’e sahip - Bazı lokasyonlarda hedef sayfa geçici hata (5xx) üretiyor - CDN edge tarafında farklı sürüm (stale HTML) servis ediliyor - Dil varyantları arasında içerik çok benzer ama sayfalar arası ilişki (internal linking) zayıf

Bu durumda tek tek doğrulama yapın: 1) HTML’de canonical/hreflang tutarlılığı 2) Hedef sayfalarda indexlenebilirlik 3) Redirectlerin final URL ile uyumu 4) CDN cache key ve purge düzeni

Sonuç: Çoklu lokasyonda hreflang için “lokasyonlar arası deterministik çıktı” hedefleyin

Çoklu lokasyon hostingde hreflang’ın çalışması, tag’in doğru yazılmasından daha fazlasıdır: Aynı URL tüm lokasyonlarda aynı canonical ve aynı hreflang setini döndürmelidir. Bu yüzden kurulumu tamamladıktan sonra farklı coğrafyalardan aynı path’i çekip canonical/hreflang bloklarını karşılaştırın; hedef URL’lerin 200 ve indexlenebilir olduğunu doğrulayın. Bu kontrol setini uyguladığınızda, hreflang kaynaklı “yanlış dil/ülke eşleşmesi” riskini ölçülebilir şekilde azaltırsınız. Eğer altyapınızda CDN/edge veya VDS’ler arasında template/config farkı varsa, ilk aksiyon olarak deterministik HTML çıktısını sağlamlaştırın ve cache key/purge politikasını standardize edin.