İçindekiler
- 1 Kısa Bir Ofis Hikâyesi ve Hreflang’a Yumuşak Bir Giriş
- 2 Hreflang Nedir, Ne İşe Yarar? Basitçe, Yoldaki Tabelalar
- 3 ccTLD ile Ülke Ülke Yolculuk: Ayrı Domende Hreflang Mantığı
- 4 Alt Dizin Düzeni: Tek Çatı, Çok Oda
- 5 Alt Alan (Subdomain) Senaryosu: Ayrı Bloklar, Aynı Site
- 6 x-default Neden Hayati? Dil Seçici, Ana Sayfa ve Sürprizler
- 7 Uygulama Tarzları: HTML Head, HTTP Başlığı ve XML Sitemap
- 8 Test, Yayına Alma ve Küçük Kazalar: Nasıl Toparlarsınız?
- 9 Kapanış: Yolun Sonu Değil, Sürdürülebilir Bir Rutin
Kısa Bir Ofis Hikâyesi ve Hreflang’a Yumuşak Bir Giriş
Bir gün öğleden sonra, kahvemi almış ekran başına geçmişim. Slack’te bir mesaj: “Almanya’dan gelen kullanıcılar Türkçe sayfayı görüyor, dönüşümler düştü!” Hemen aklıma şu geldi: “Hreflang var mı?” Cevap tipik: “Vardı sanki… ama emin değiliz.” İşte o an anladım, uluslararası trafiğin kalbi bazen tek bir satır etikette atıyor. Hreflang, kulağa teknik gibi gelse de özünde nazik bir rehber; arama motorlarına, “Bu içerik şu kitleye, şu dil/ülke için” diye fısıldayan bir yol arkadaşı.
Hiç başınıza geldi mi? Kullanıcı “kendi dilinde” mükemmel hazırlanmış sayfanız varken başka bir dile yönlenir, üst menüde dil seçici arar, bulur ama geç kalmıştır. Oysa doğru kurulan hreflang, daha kullanıcı arama sonuçlarında karar vermeden pusulayı ayarlar. Bu yazıda, ccTLD, alt dizin, alt alan ve x-default ile hreflang’i baştan sona, deneyimle harmanlayarak konuşacağız. Mesela şöyle düşünün: Markanız büyüyor, ülkeler çoğalıyor, sayfalar dallanıp budaklanıyor. Yol ayrımında hangi haritayı kullanırsınız? ccTLD ile ülke ülke mi ilerlersiniz, yoksa tek alan adı altında alt dizinlerle mi yürürsünüz? Bir de o çok sorulan konu: x-default’ı nereye koyacağız? Hadi gelin, tüm bunları akışta, örneklerle sakin sakin ele alalım.
Hreflang Nedir, Ne İşe Yarar? Basitçe, Yoldaki Tabelalar
Hreflang etiketini, aynı içeriğin farklı dil/ülke versiyonları arasında konan dostça tabelalar gibi düşünün. “Bu sayfanın Almanca kardeşi şurada, Türkçe olanı burada, her durumda kaçış sayfası da şurada” diye arama motorlarına haber uçurur. Bu sayede arama sonuçlarında doğru kullanıcıya doğru varyasyon çıkar. Hem kullanıcı mutlu olur hem de arama motoru “Ben bunu anladım” der. Sihir gibi görünür ama aslında tutarlılık gerektirir.
Burada iki küçük altın kural var. Birincisi, karşılıklılık: A sayfası B’nin alternatifi olduğunu söylüyorsa, B de A için aynı şeyi söylemeli. İkincisi, kendini de göstermesi: Her sayfa kendisini de hreflang ile işaretlemeli. Bu iki küçük ilke, kırılmayan bir zincir yaratır. Zincir kırılırsa? Arama motorları dalgınlaşır; bazen yanlış dili seçer, bazen hiçbirini anlamaz. O yüzden hreflang’ı, tek seferde yazıp bırakılan bir etiket değil, bir içerik mimarisi alışkanlığı olarak düşünmek daha doğru.
Kod kısmına gelmeden bir noktanın altını çizeyim: Hreflang, canonical ile kavga etmez; doğru kurulumda omuz omuza yürür. Her dil/ülke varyasyonu, kendi canonical’ına işaret etmeli; canonical’ı başka bir dile çekmek, “Bu içeriğin aslı aslında o” demek olur, bu da arama motorunu kararsız bırakır. Yol tarifleri çakışmamalı.
ccTLD ile Ülke Ülke Yolculuk: Ayrı Domende Hreflang Mantığı
ccTLD, yani ülke uzantılı alan adları (örneğin .de, .tr, .fr), ülke sinyali açısından güçlü bir kart gibi durur. Markanızın bölgesel olarak kendi kültürüne kök saldığı durumlarda bu çok doğal gelir. Ama pratikte yönetimi biraz daha özen ister. Çünkü hreflang’ı artık tek domainde değil, çapraz domain olarak birbirine bağlamanız gerekir. Mesela, “www.site.de” ile “www.site.com.tr” arasındaki ilişkileri her iki tarafta da eksiksiz kurmanız şart.
Mesela şöyle düşünün: Ürün A için Almanca sayfanız “https://www.site.de/produkt/a”, Türkçe sayfanız “https://www.site.com.tr/urun/a” olsun. Her iki sayfanın head’inde de karşılıklı hreflang etiketleri yer almalı. Alternatif olarak XML sitemap içinde xhtml:link ile de tanımlayabilirsiniz. Çok sayıda sayfa varsa sitemap yaklaşımı temizlik ve ölçeklenebilirlik sağlar. Unutmayın, çapraz domain sitemap’ı kullanacaksanız, her domain’i doğrulayıp ilgili sitemapi ayrı ayrı Search Console mülklerine tanıtmalısınız.
Ne zaman ccTLD? Markanız ülke bazlı ayrı yasal oluşumlara sahipse, fiyatlama ve içerik tamamen yerelse ve pazarlama ekipleri bağımsız çalışıyorsa, ccTLD doğal bir yol olur. Bu noktada ccTLD mi gTLD mi, uluslararası SEO’da hangi yol ne zaman doğru sorusunu daha geniş bir çerçevede ele aldığım yazıyı da bırakayım; fikir yürütürken iyi arkadaşlık eder.
Bir dipnot daha: Yeni uzantıları mı düşünüyorsunuz? Pazarların genişlediği dönemlerde, ICANN’in yeni gTLD turu ve kendi uzantını düşünmenin zamanlaması üzerine de uzun uzun konuşmuştuk. TLD stratejisi, hreflang mimarisini nasıl kuracağınızı doğrudan etkiler.
Alt Dizin Düzeni: Tek Çatı, Çok Oda
Alt dizin (ör. site.com/tr/ ve site.com/de/) yaklaşımı, teknik ekiplerin hoşuna gider çünkü tek bir domain ve genellikle tek bir barındırma/altyapı altında ilerlersiniz. Hreflang tarafında işler nispeten sade akar; tüm alternatifler aynı domainde olduğu için doğrulama, canonical ve yönlendirme mantığı daha tekdüzedir. Yine de “tek çatı” sizi yanıltmasın, x-default ve varsayılan dil kurgusu burada da temiz olmalı.
Pratik kuralları, kısa bir hikâye ile akılda tutalım. Diyelim ki ana sayfanızın İngilizce versiyonu “site.com/”, Türkçe “site.com/tr/”, Almanca “site.com/de/”. Eğer ana sayfanız herkese aynı içeriği vermiyorsa, yani farklı ülkelere farklı içerik sunan bir yönlendirme varsa, o zaman bir “dil seçme” sayfasını x-default olarak belirlemek daha sağlıklı olur. Böylece arama motoru “Genel giriş kapısı bu, kim geldiğini anladıkça doğru odaya yönlendireceğiz” mesajını alır.
Alt dizinle giderken performans ve altyapı konusu da akla gelir. Trafik artıp bölgeler çoğalınca, içerik dağıtımı ve geo-routing gibi konular kapıyı çalar. O dünyayı merak ediyorsanız, farklı bölgelerde mimari kurarken DNS seviyesinde kararları nasıl aldığımı DNS geo-routing ve çok bölgeli mimariler yazısında anlatmıştım; hreflang tek başına her şeyi çözmez, bazen altyapı da ritme katılır.
Alt Alan (Subdomain) Senaryosu: Ayrı Bloklar, Aynı Site
Alt alan kullandığınızda (tr.site.com, de.site.com) hissiyat ccTLD kadar “ayrı ülke” netliği vermez ama teknikten bakınca yönetim esnekliği sağlar. Farklı alt alanlar farklı sunucularda yaşayabilir, yine de tek marka şemsiyesi altındasınızdır. Hreflang’ı burada da tıpkı alt dizindeki gibi düşünebilirsiniz; tek fark, domain değişmese de “host” değişir, dolayısıyla bakım ve test listesinde alt alanların da eksiksiz karşılıklılık içinde olduğunu kontrol etmek gerekir.
Bu modelde en sık gördüğüm iki pürüz: Birincisi, ana alan “www.site.com” ile alt alanların birbirini alternatifi olarak tanımlanmaması. Yani tr.site.com ana sayfası, www.site.com/tr/ ile kardeşse, bu kardeşliği açıkça kurun. İkincisi, otomatik yönlendirme hevesi. “IP’si Almanya, o halde de.site.com’a yönlendirelim” yaklaşımı bazen arama motorunu yanıltır, çünkü botlar farklı lokasyonlardan gelir. Otomatiğe bağlamak yerine, hreflang ve dil seçici bileşimini nazik, ama net bir şekilde tasarlamak daha sürdürülebilir.
x-default Neden Hayati? Dil Seçici, Ana Sayfa ve Sürprizler
x-default, ekibinizde “Arazi ekibi şefi” gibi çalışır. “Hangi dile, hangi ülkeye koyacağımı bilmiyorsam, şu adrese gönder” dersiniz. Özellikle ana sayfa ve dil seçici sayfalarında hayat kurtarır. Benim uygulama rutinimde, kullanıcıyı karşılayıp “Dilini seç” dediğim sayfayı x-default yaparım. SEO açısından şu kazanımı sağlar: Arama motoru, belirsiz bir durumda bu adresi “genel” kabul eder ve yanlış dile yapışma ihtimali azalır.
Şunu sorabilirsiniz: “x-default her sayfada zorunlu mu?” Değil. Ama stratejik sayfalarda, özellikle ana sayfa ve “/intl/” ya da “/language-select” gibi kullanıcıyı kapıda karşılayan geçitlerde çok işe yarar. Google’ın bu konudaki yönergeleri nettir, takılırsa göz atın; Google’ın hreflang dokümantasyonu x-default senaryolarını da gayet yalın anlatır.
Ufak bir ipucu: x-default’ı, “herkese İngilizce” gibi bir varsayımı dayatmak yerine “nötr karşılayıcı” adres olarak düşünmek, özellikle çok pazar hedefleyen markalar için daha doğal akış sağlar. Kullanıcıyı karşılar, tercihini alır, sonra dil/ülke varyasyonuna nazikçe geçirirsiniz.
Uygulama Tarzları: HTML Head, HTTP Başlığı ve XML Sitemap
HTML head içinde
En bilinen yöntem, her sayfanın head bölümüne alternatiflerini yazmaktır. Aynı kümeye ait tüm alternatifler birlikte listelenmeli ve her biri kendisini de göstermelidir.
<link rel="alternate" hreflang="tr-TR" href="https://www.site.com/tr/urun/a/" />
<link rel="alternate" hreflang="de-DE" href="https://www.site.com/de/produkt/a/" />
<link rel="alternate" hreflang="en" href="https://www.site.com/en/product/a/" />
<link rel="alternate" hreflang="x-default" href="https://www.site.com/language-select/" />
Dil/ülke kodları için “dil-bölge” mantığını kullanın: tr-TR, de-DE gibi. Yalnızca dile odaklanacaksanız “en”, “tr” gibi sade hâli yeter. Kodlamayı karıştırırsanız arama motoru “Hangi ülkeydi?” diye duraklar.
HTTP başlıklarında (PDF gibi dosyalar)
HTML olmayan dosyalar için Link başlığı ile hreflang bildirebilirsiniz. Bu, katalog, broşür gibi statik dosyalarda çok işe yarar.
Link: <https://www.site.com/de/broschuere.pdf>; rel="alternate"; hreflang="de-DE",
<https://www.site.com/tr/brosur.pdf>; rel="alternate"; hreflang="tr-TR",
<https://www.site.com/language-select/>; rel="alternate"; hreflang="x-default"
HTTP başlıklarını doğru biçimlendirmek için teknik referansa ihtiyacınız olursa, MDN’deki Link başlığı dokümantasyonu açıklayıcıdır.
XML sitemap ile
Çok dil/ülkeli büyük sitelerde, sitemap ile hreflang’ı toplu yönetmek huzur verir. Her URL kümesini tek bir blokta, tüm alternatifleriyle birlikte verirsiniz.
<url>
<loc>https://www.site.com/tr/urun/a/</loc>
<xhtml:link rel="alternate" hreflang="tr-TR" href="https://www.site.com/tr/urun/a/" />
<xhtml:link rel="alternate" hreflang="de-DE" href="https://www.site.de/produkt/a/" />
<xhtml:link rel="alternate" hreflang="en" href="https://www.site.com/en/product/a/" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://www.site.com/language-select/" />
</url>
Çapraz domain kullanıyorsanız, ilgili tüm domainleri doğrulayın ve sitemapi her birinin Search Console’una ekleyin. Çapraz bağlantılar eksiksiz olmalı; biri eksik kalırsa zincir tek yönlü olur, sinyal zayıflar.
Kodlama ve canonical uyumu
Her varyasyon kendi canonical’ına işaret etsin. Canonical’ı başka dile çekmek, hreflang ile verdiğiniz mesajı bozar. “noindex” ile hreflang çiftini de bir arada kullanmaktan kaçının; indexlenmeyecekse alternatif olmak da mantıksızlaşır. Temiz ve dürüst bir kurgu, en çok burada kazanır.
Test, Yayına Alma ve Küçük Kazalar: Nasıl Toparlarsınız?
Benim yayına alma ritüelim basit ama disiplinli. Önce staging ortamında hreflang kümelerini kurarım. Sonra örnek URL’lerde kaynak kodu kontrol eder, linklerin her yönde karşılıklı olduğunu doğrularım. Sitemap tarafını günceller, bekleyen redirect’leri temizlerim. Canlıya çıktıktan sonra, arama motoru günlüklerini izler, botların doğru varyasyonları taradığını görmeye çalışırım. URL denetleme araçları ile beklenen URL’lerin index statülerini kontrol etmek de alışkanlıktır.
En yaygın küçük kazalar neler? Birincisi, yanlış dil/ülke kodları (örneğin “tr-DE” gibi hayali bir eşleşme). İkincisi, tek yönlü bildirim (A, B’yi söyler ama B, A’yı söylemez). Üçüncüsü, gereksiz otomatik yönlendirmeler (IP’ye bakıp durmadan ülke sayfasına atmak). Dördüncüsü, canonical karmaşası (başka dile canonical vermek). Beşincisi, indexlenmeyen sayfaya hreflang (noindex’li veya engelli sayfaları alternatif göstermek). Bu beşli, çoğu zaman trafiği sessizce kemirir.
Bir müşteride yaşadığım vaka: “/de/” ve “/tr/” alt dizinleri çok güzel kurulmuştu, fakat x-default yoktu. Ana sayfa ülkeye göre otomatik yönlendiriyordu. Google ise bazen İngilizce ana sayfayı, bazen Almanca’yı getiriyordu. Çözüm, sade: Dil seçici sayfayı x-default yapmak ve ana sayfa yönlendirmesini kullanıcı hareketi ile tetiklemek. Birkaç hafta içinde arama sonuçları istikrara kavuştu. Yol gösterici tek bir tabela, bazen aylarca anlatamadığınız derdi iki günde çözer.
Derinleşmek isterseniz, Google’ın yönergesine yine bir göz atın: localized versions rehberi ufak ayrıntıları bile açıklar. Kodlar, örnekler, kenar durumlar; hepsi tek yerde. Not: Link’teki sayfayı okumak, ekibin ortak dilini kurmak için de güzel bir başlangıçtır.
Kapanış: Yolun Sonu Değil, Sürdürülebilir Bir Rutin
Hreflang, bir kere kurup rafa kaldıracağınız bir şey değil; içerik güncellemeleriyle, yeni pazar girişleriyle, site mimariniz büyüdükçe siz de onu yeniden düzenlersiniz. Bunu bir tür bahçıvanlık gibi düşünmek hoşuma gidiyor: Kökler sağlam, dallar dengeli, tabelalar okunaklı olursa, bahçe hem büyür hem de düzenini kaybetmez. ccTLD, alt dizin, alt alan… Hangisini seçerseniz seçin, önemli olan tutarlılık, karşılıklılık ve kullanıcı niyeti ile uyumlu bir rehberlik sunmak.
Pratik bir kapanış listesi veremem, çünkü her sitenin hikâyesi farklı. Ama küçük bir yol haritası bırakayım: Önce mimariyi netleştirin (tek domain mi, çok domain mi). Sonra içerik eşleşmelerini çıkarın; hangi sayfanın hangi dil/ülke kardeşi olduğunu yazılı hale getirin. x-default için “gerçekten nötr” bir kapı belirleyin. Uygulamayı head, HTTP başlığı ya da sitemap üzerinden standartlaştırın. Yayına alırken karşılıklılığı ve canonical uyumunu tek tek doğrulayın. Gerisini trafik ve kullanıcılar size anlatır.
Umarım bu yazı, aklınızdaki düğümleri biraz rahatlattı. Eğer “Alan adı tarafını da masaya yatıralım, stratejiyi bir bütün olarak görelim” derseniz, şu yazılar da yol arkadaşınız olabilir: alan adı stratejisi ve uluslararası SEO kararı, yeni gTLD turu ve uzantı düşüncesi ve çok bölgeli sunum için DNS geo-routing deneyimlerim. Bir dahaki yazıda görüşmek üzere; sorularınızı, ilhamlarınızı her zaman beklerim.
