Hreflang Kurulumu: TR-EN Sitelerde Yapılan Hatalar
Kurumsal bir sitenin İngilizce versiyonunu devreye alırken önümüzde iki yol vardı: ayrı bir alan adı mı açacaktık, yoksa aynı domain altında /en/ dizini mi kullanacaktık. Bütçe ve zaman kısıtı netti. İki ayrı domain yönetmek hem SEO otoritesini bölecek hem de içerik ekibine fazladan iş yükü getirecekti.
Aynı domain altında dizin yapısı kurmaya karar verdik ve hreflang etiketlerini bu yapıya göre kurguladık. Karar basitti, uygulaması hiç basit olmadı. Çok dilli SEO'da hreflang, arama motoruna bu sayfanın şu dildeki karşılığının nerede olduğunu söylemenin yoludur; teknik olarak küçük bir kod parçasıdır ama yanlış yazıldığında Google yanlış dildeki sayfayı yanlış kullanıcıya gösterebilir. Biz de bu süreçte birkaç kez aynı hataya düştük, düzeltme maliyetini gördük ve bugün aynı projeyi kursak nasıl ilerleyeceğimizi öğrendik.
İlk karar: domain yapısı yerine dizin yapısı
TR içeriği ana domain kökünde, EN içeriği /en/ dizini altında tuttuk. Bu kararın arkasındaki mantık, tek domain üzerinde biriken backlink ve marka otoritesinin iki dil versiyonu arasında bölünmemesiydi. Ayrı domain kullansaydık, örneğin .com ve .com.tr gibi iki farklı uzantıyla ilerleseydik, her biri sıfırdan otorite kazanmak zorunda kalırdı.
Dizin yapısının da bir bedeli vardı. Teknik ekip her yeni sayfa eklediğinde TR ve EN karşılığını aynı anda planlamak zorunda kaldı, içerik takvimi tek dilde ilerleyen bir proje için bu fazladan koordinasyon demekti. Kısıtlı bütçeyle çalışan projelerde bu noktanın gözden kaçırılmaması gerekiyor; web tasarım ve geliştirme sürecinde çok dilli yapı en baştan planlanmazsa, sonradan eklemek üç kat daha fazla zaman alıyor.
Hreflang etiketlerini nereye yazdık, ilk hata buradan çıktı
Hreflang etiketlerini her sayfanın head bölümüne manuel olarak eklemeye başladık. İlk iki hafta fark etmediğimiz şey şuydu: TR sayfadaki etiket EN sayfayı işaret ediyordu ama EN sayfadaki etiket karşılıktan geri dönüş yapmıyordu. Google Search Console bu durumu "hreflang karşılıksız" uyarısı olarak gösterdi, biz bunu fark edene kadar üç haftalık bir süre geçti.
Hreflang çalışmasının temel kuralı şudur: A sayfası B sayfasını işaret ediyorsa, B sayfası da A sayfasını işaret etmek zorundadır. Bu karşılıklılık eksik olduğunda arama motoru etiketi tamamen göz ardı eder ve harcanan emek boşa gider. Hatayı fark ettikten sonra tüm etiketleri tek tek elden geçirip eşleştirdik; bu da bir günlük ek iş çıkardı.
x-default etiketini atlamak
İkinci hatamız x-default etiketini hiç kullanmamaktı. x-default, kullanıcının tarayıcı dili TR veya EN dışında bir dil olduğunda hangi sayfanın gösterileceğini belirtir. Bunu eklemeyince dil eşleşmesi olmayan trafik bazen TR sayfaya, bazen EN sayfaya rastgele yönlendi. Sonradan x-default'u EN sayfaya bağladık, çünkü hedef kitlemizin uluslararası tarafı İngilizce içerikle daha iyi eşleşiyordu.
Canonical ve hreflang çelişkisi nasıl ortaya çıktı
Projenin dördüncü haftasında başka bir sorunla karşılaştık. TR sayfanın canonical etiketi kendi URL'sini gösteriyordu, ama bir önceki CMS ayarından kalan eski bir kural, benzer başlıklı sayfaları otomatik olarak tek bir canonical'a yönlendiriyordu. Bu durumda hreflang EN sayfaya işaret ederken canonical farklı bir TR sayfayı gösteriyordu. Google bu çelişkiyi gördüğünde hreflang sinyalini güvenilmez bulup devre dışı bırakabiliyor.
Canonical etiket sayfanın asıl, tekrarsız hali budur der; hreflang ise bu sayfanın şu dildeki karşılığı şudur der. İkisi çelişince arama motoru hangisine güveneceğini bilemiyor ve genelde ihtiyatlı davranıp hreflang sinyalini devre dışı bırakıyor. Bu çelişkiyi düzeltmek için CMS'teki otomatik canonical kuralını kapattık, her sayfanın canonical'ını kendi URL'sine sabitledik.
Bu noktada öğrendiğimiz bir şey daha vardı: sitemap.xml üzerinden hreflang bildirmek, her sayfaya tek tek head etiketi eklemekten daha az hataya açık. Sitemap'te dil eşleşmelerini merkezi bir dosyada tanımlayınca karşılıksız etiket veya yanlış dil kodu riski azalıyor. Bugün aynı projeyi kursak, manuel head etiketi yerine doğrudan sitemap tabanlı hreflang ile başlardık.
Dil kodu mu bölge kodu mu, hangi formatı seçtik
Hreflang'da dil kodu (tr, en) ile bölge kodu (tr-TR, en-US, en-GB) arasında seçim yapmak gerekiyordu. Sade dil kodunu tercih ettik, çünkü bölgesel ayrım yapacak kadar farklı içeriğimiz yoktu. EN içerik hem İngiltere hem ABD hem de Türkiye'de İngilizce okuyan kullanıcılar için aynıydı. Bölge kodu kullanmak, farklı ülkelerde farklı fiyat veya kampanya gösterecek e-ticaret projelerinde daha mantıklı; bizim kurumsal içerik yapımızda gereksiz karmaşıklık olurdu.
Burada dikkat edilmesi gereken şey, dil kodunun ISO 639-1 standardına uyması. Bazı projelerde "tr" yerine "tur" gibi üç harfli kodlar kullanıldığını görüyoruz; bu etiketi geçersiz kılıyor ve Google tarafından okunmuyor. Tarayıcı konsolunda hata vermeyen ama fiilen işlemeyen bir etiket, çok sık karşılaşılan bir tuzak.
Çok dilli yapı kurarken SEO ve GEO optimizasyonu tarafında dikkat edilmesi gereken bir diğer nokta, her dil versiyonunun kendi hedef kitlesine göre anahtar kelime araştırmasıyla yazılmış olması. TR içeriği birebir çevirip EN sayfaya koymak, hreflang'ı teknik olarak doğru kursanız bile EN tarafında arama hacmi düşük kelimelerle sıralanmanıza yol açıyor. Bizim projede EN içerik önce çeviri olarak başladı, üç ay sonra yeniden yazıldı ve organik trafik o noktadan sonra anlamlı şekilde arttı.
Bugün aynı projeyi kursak neyi değiştirirdik
Geriye dönüp baktığımızda üç şeyi baştan farklı yapardık. Birincisi, hreflang'ı sitemap üzerinden merkezi şekilde yönetmek; sayfa sayısı arttıkça manuel head etiketi yönetilemez hale geliyor. İkincisi, canonical ve hreflang kurallarını aynı kişi veya ekibin baştan birlikte planlaması. Bizde bu iki iş farklı aşamalarda farklı kişiler tarafından yapıldığı için çelişki fark edilmedi.
Üçüncüsü, Google Search Console'daki Uluslararası Hedefleme raporunu proje bitiminde değil, ilk haftadan itibaren düzenli kontrol etmek. Bu raporu üç hafta boyunca açmadık ve hata orada birikti. Bugün bir çok dilli proje teslim ettiğimizde, ilk hafta sonunda bu raporun temiz çıkması bizim için teslim kriterlerinden biri haline geldi.
Benzer çok dilli proje kurulumlarını ve karşılaştığımız teknik detayları portfolyomuzda görebilirsiniz. Dil yapısı, URL mimarisi ve içerik stratejisi birbirine bağlı kararlar; birini diğerinden ayrı düşünmek projenin ilerleyen aşamasında geri dönüp düzeltme maliyeti doğuruyor.
Çok dilli bir site planlıyorsanız ve hreflang yapısını baştan doğru kurmak istiyorsanız, mevcut site yapınızı değerlendirip size özel bir yol haritası çıkarmamız için bizimle iletişime geçebilirsiniz.
