Çok dilli sitelerde en sık yanlış anlaşılan teknik sinyallerden biri canonical etikettir. Sebep basit: ekipler yinelenen içerik sorununu çözmeye çalışırken bir noktadan sonra farklı dil ve ülke sürümlerini de aynı kümeye koymaya başlar. Orada iş karışır. Arama motoruna "bunların hepsi aynı sayfa" demekle "bunlar aynı içeriğin farklı hedef kitle sürümleri" demek aynı şey değildir.
Canonical etiketi, arama motoruna bir URL kümesi içinde hangi adresin tercih edilen sürüm olduğunu söyler. Ama bu yetki sınırsız değildir. Gerçekten ayrı kullanıcı niyetine, ayrı ülke hedeflemesine, ayrı fiyatlandırmaya ya da ayrı teslimat koşullarına sahip sayfaları tek canonical altında toplarsanız, teknik temizlik yaptığınızı sanırken görünürlüğü daraltırsınız.
Çok dilli yapıların kırıldığı nokta da tam burasıdır. Hreflang sistemi alternatif sürümleri birbirine tanıtırken canonical, hangi URL'nin asıl sayfa kabul edileceğini işaret eder. İkisi aynı yöne bakmadığında Google genellikle daha sert olan sinyali, yani canonical'ı ciddiye alır. Sonuç: hreflang kuruludur ama beklenen ülke veya dil sürümü yine görünmez.
Canonical neyi seçer, hreflang neyi ayırır?
Önce iki etiketin rolünü net ayırmak gerekir. Canonical, aynı ya da neredeyse aynı içeriğe sahip URL kümelerinde bir temsilci seçer. Hreflang ise içeriklerin eşdeğer olduğunu ama farklı dil ya da bölge kitlelerine hitap ettiğini anlatır. Biri birleştirir, diğeri ayırır.
UTM parametreli bir kampanya URL'si ile temiz URL aynı sayfayı gösteriyorsa canonical kararı kolaydır; parametreli sürüm, temiz URL'ye bağlanır. Ama Türkçe bir kategori sayfası ile İngilizce karşılığı arasında böyle bir ilişki kurulmaz. Konu aynı olabilir, ürünler aynı olabilir, hatta görsellerin çoğu da aynı kalabilir. Yine de kullanıcıya sunulan sürüm farklıdır; dolayısıyla bunlar canonical kümesi değil, hreflang kümesidir.
Burada çok yaygın bir refleks devreye girer: "İngilizce sayfa ana sürüm olsun, diğer diller ona canonical versin." Teknik olarak yapılabilir görünür. Pratikte ise diğer dilleri ikincil hatta gereksiz sürüm gibi tanımlamış olursunuz. Google da çoğu zaman o sinyali bu şekilde okur. Özellikle çok dilli ve çok ülkeli yapılarda canonical etiketini bir otorite sıralaması aracı gibi kullanmak risklidir.
Kısa versiyon şu: URL farkı yalnızca izleme, sıralama, filtreleme veya baskı görünümü gibi teknik nedenlerden kaynaklanıyorsa canonical birleştirir. URL farkı farklı dil, farklı pazar, farklı kullanıcı beklentisi veya farklı ticari koşullar üretiyorsa canonical birleştirmez. O durumda her sayfa kendi kanonik sürümünü işaret eder.
Varsayılan karar neden self-canonical olmalı?
Çok dilli sitede yayınlanan her gerçek sayfa için başlangıç kararı genellikle self-canonical olmalıdır. Yani her URL kendi canonical etiketinde kendisini göstermelidir. Bu yaklaşım hem en güvenli olandır hem de hreflang ile uyumlu çalışır.
Türkçe ana sayfanız, İngiltere İngilizcesi sürümünüz ve ABD İngilizcesi sürümünüz varsa, üçü de ayrı hedefler taşıyorsa şu mantık çalışır: her biri kendisine canonical verir, sonra birbirlerini hreflang ile alternatif olarak tanıtır. Özellikle aynı dilin ülke varyantlarında bu karar daha kritik hale gelir. Çünkü ekipler, dil aynı olduğu için sayfaların tek sayfa sayılabileceğini düşünmeye daha yatkındır.
Doğru kurulum çoğu zaman şöyledir:
<link rel="canonical" href="https://ornek.com/en-us/" />
<link rel="alternate" hreflang="en-US" href="https://ornek.com/en-us/" />
<link rel="alternate" hreflang="en-GB" href="https://ornek.com/en-gb/" />
<link rel="alternate" hreflang="tr-TR" href="https://ornek.com/tr/" />
Sorunlu örnek ise daha kısa görünür ama daha yıkıcıdır: en-gb ve tr sayfalarının canonical etiketini en-us sürümüne bağlamak. Böyle yaptığınızda arama motoruna şu mesajı vermiş olursunuz: "Asıl sayfa bu, diğerleri ikincil türev." Ardından hreflang ile "ama bunları yine de ayrı düşün" demeye çalışırsınız. İki sinyal aynı cümlede birbirini boşa düşürür.
URL yapısı alt dizin, alt alan adı veya ülke klasörü tabanlı olabilir; burada fark eden şey adres biçimi değil, sayfanın gerçekten ayrı bir hedef üretip üretmediğidir. Ayrı hedef varsa self-canonical güvenli tabandır.
Aynı dili kullanan ülke varyantlarında nerede birleşilir?
Canonical kararının en zor kısmı burada başlar. en-us ve en-gb gibi iki sayfa dil olarak aynı göründüğü için ekipler bunları sık sık tek sayfa gibi yorumlar. Oysa kullanıcı açısından bakıldığında para birimi, kargo koşulu, vergi bilgisi, iade süreci, teslimat süreleri, yasal metinler ve yerel örnekler ciddi fark yaratır. Küçük farklar tek başına yeterli olmayabilir; ama bu unsurlar birlikte kullanıcı niyetini değiştiriyorsa sayfa artık ayrı bir sürümdür.
Tersine, iki URL aynı dili hedefliyor ve içerikleri de gerçekte aynıysa canonical birleştirme düşünülebilir. Örneğin sisteminiz yanlış yönlendirme yüzünden aynı ürün sayfasını hem /en/product/ hem /en-us/product/ altında üretiyor olabilir. Kullanıcıya sunulan metin, fiyat ve lojistik bilgisi aynıysa bu iki URL'yi ayrı yaşatmanın pek anlamı yoktur.
| Senaryo | Canonical kararı | Not |
|---|---|---|
| UTM parametreli ve temiz URL aynı sayfayı açıyor | Temiz URL'ye canonical verilir | Bu bir teknik çoğaltmadır, hreflang konusu değildir |
en-us ve en-gb sayfalarında fiyat, teslimat ve yasal içerik farklı |
Her sayfa kendine canonical verir | Ayrı pazar niyeti vardır |
| Aynı dilde iki URL yanlış yönlendirme nedeniyle aynı içeriği taşıyor | Tek URL seçilip diğeri ona bağlanır | Önce URL mimarisi temizlenir |
| Şehir ya da ülke sayfaları yalnızca başlık değiştirip aynı gövdeyi kullanıyor | Birleştirme veya yeniden yazım gerekir | Bu durum çoğu zaman ince içerik problemidir |
Buradaki kritik ölçüt şu sorudur: kullanıcı yanlış varyanta düşerse deneyim gerçekten bozulur mu? Cevap evetse canonical ile birleştirmemek gerekir. Çünkü arama motoruna göre küçük görünen fark, kullanıcı açısından yanlış ülkeye ait fiyat veya yanlış teslimat bilgisi anlamına gelebilir.
Canonical ve hreflang birlikte nasıl kurulmalı?
Sağlıklı çok dilli kurulumda iki sinyal aynı hikâyeyi anlatır. Canonical, "bu URL kendi kümesinde tercih edilen sürümdür" der. Hreflang ise "aynı amacın farklı dil veya ülke hedefli sürümleri de burada" der. Yani ayrı pazar sayfalarını tek sayfaya indirmek yerine, her sürümü yerinde bırakıp ilişkilerini tanımlarsınız.
En güvenli model üç adımda özetlenir: sayfa 200 durum koduyla açılır, canonical kendisini işaret eder, hreflang bloğu diğer alternatifleri listeler. Global bir karşılama sürümünüz varsa buna ek olarak x-default kullanımını ayrı bir katman olarak düşünürsünüz. Ama x-default, canonical kararının yerine geçmez; yalnızca eşleşme bulunamadığında varsayılan sürümü tarif eder.
Sorunlu yapı ise genellikle şöyledir: tüm varyantlar tek bir URL'ye canonical verir, aynı anda hreflang bloklarında birbirlerini gösterir. Teoride "hepsi bağlı" görünür. Fakat canonical sinyali, bazı sayfaların artık asıl sürüm olmadığını söylediği için hreflang'ın etkisini zayıflatır. Google bu durumda ya bazı alternatifleri görmezden gelir ya da yalnızca baskın URL'yi indekslemeye eğilim gösterir.
Canonical ile hreflang arasında çelişki varsa önce canonical kararına dönüp sayfaların gerçekten ayrı yaşaması gerekip gerekmediğini sorgulamak gerekir. Teknik denetim sırasında sadece etiketin varlığına bakmak yetmez; etiketin anlattığı mantığın sayfanın iş modeliyle uyumlu olması gerekir.
En sık yapılan canonical hataları nelerdir?
Birinci hata, tüm dil sürümlerini kaynak dil sayfasına bağlamaktır. Özellikle içerik çeviriyle üretildiyse bu refleks daha da artar. "Orijinal metin İngilizceydi, o halde diğerleri ona canonical versin" düşüncesi teknik olarak rahatlatıcı görünür. Ama çeviri yayınlandıktan sonra sayfa artık bağımsız bir hedef kitleye hitap ediyordur; kaynak dosya mantığıyla yönetilemez.
İkinci hata, ülke varyantlarını küresel sayfaya bağlamaktır. Örneğin /en-au/, /en-ca/ ve /en-gb/ sayfalarının hepsi /en/ sürümüne canonical veriyorsa, yerel sürümlerin indekslenme şansı daralır. Bu hata çoğu zaman "ana İngilizce sayfa güçlü, diğerleri ona yaslansın" düşüncesinden doğar. Arama motoru ise bunu çoğu kez "diğerleri türev" diye okur.
Üçüncü hata, canonical etiketini yönlendirme yerine kullanmaktır. Artık yaşamasını istemediğiniz URL'yi 301 ile taşımak yerine sayfayı açık bırakıp başka adrese canonical vermek, sinyali belirsizleştirir. Canonical bir taşıma mekanizması değildir; benzer içerikler içindeki tercih bildirimidir.
Dördüncü hata, canonical'ı hatalı hedeflere göndermektir: 301 dönen URL'ler, noindex sayfalar, 404 veren adresler, protokolü değişmiş sürümler veya slash tutarsızlığı olan yollar. Şablon düzeyinde yapılan küçük bir değişiklik binlerce sayfanın aynı yanlış hedefe bağlanmasına yol açabilir. İşte bu yüzden canonical denetimi yalnızca kaynak kod kontrolü değil, HTTP durum kodu kontrolü de ister.
Beşinci hata daha sessizdir: içeriği gerçekte zayıf olan pazar sayfalarını canonical ile kurtarmaya çalışmak. Oysa sorun çoğu zaman canonical değil, sayfaların birbirinden yeterince ayrışmamasıdır. Aynı gövdeye yalnızca ülke adı değiştirerek on farklı URL üretildiğinde teknik etiketler bir noktadan sonra sorunu örtemez.
Yayın öncesi ve sonrası kontrol nasıl yapılmalı?
Canonical yönetimini sağlıklı tutmanın yolu bir kez etiket yazıp bırakmak değil, tekrar eden küçük bir kontrol rutinidir. Özellikle yeni ülke sürümü eklendiğinde ya da URL yapısı değiştirildiğinde bu rutin şart olur.
- Sayfanın 200 durum koduyla açıldığını doğrulayın; canonical verilen hedef de aynı şekilde erişilebilir olsun.
- Kaynak kodda canonical etiketinin self-canonical mı yoksa başka bir URL'yi mi gösterdiğini kontrol edin.
- Hreflang bloğunun aynı URL kümesini desteklediğini doğrulayın; canonical ile hreflang farklı mantık anlatmamalı.
- Sayfa sitemap içinde doğru URL ile yer alsın; eski veya yönlenen adresler site haritasında kalmasın.
- İç linkler gerçekten yaşatmak istediğiniz sürüme gidiyor mu bakın; menü ve içerik içi linklerde farklı adres varyantları oluşmasın.
Büyük yapılarda buna bir toplu tarama katmanı eklemek gerekir. Kaynak sayfa 200 dönebilir, ama canonical verdiği hedef 301, 302 hatta 404 olabilir. Özellikle dil klasörü taşındığında, protokol değiştiğinde veya CDN kuralı güncellendiğinde bu tür kırılmalar sessizce yayılır. Tek tek sayfa açarak yakalamak zordur; tarama çıktısında canonical hedef durum kodunu toplu görmek daha güvenilir bir yöntemdir.
Bir diğer pratik kontrol de ortam sızıntısıdır. Test ortamından canlıya taşınan şablonlar bazen production sayfalarında yanlış domain'e canonical üretir. Çok dilli projelerde hata daha sinsi ilerler; yalnızca belirli dil şablonlarında ortaya çıkabilir. Bu yüzden her dil kümesinden örnek URL seçip canonical çıktısını karşılaştırmak, sonradan temizlenmesi pahalı sorunları daha yayına çıkmadan durdurur.
Aynı denetim iç linklerde de yapılmalıdır. Menü en-gb sürümünü yaşatırken gövde içi linkler sürekli genel en sürümüne akıyorsa, canonical kararı kağıt üzerinde doğru olsa bile sinyaller dağılır. Canonical etiket tek başına düzen kurmaz; site içi link mimarisi onu desteklemelidir.
Bu kontrolü daha geniş bir tarama akışına oturtmak istiyorsanız teknik SEO denetim listesi işinizi kolaylaştırır. Canonical tek başına bir ayar değildir; URL yapısı, hreflang, sitemap ve iç linkler birlikte çalıştığında anlamlı hale gelir.
Canonical kalite sorununun yerine geçmez
Bazen ekipler çok benzeyen ülke sayfalarını canonical ile temizlemeye çalışır. Oysa doğru soru şudur: bu sayfalar gerçekten ayrı yaşamayı hak ediyor mu? Ayrı yaşıyorsa içerik, teklif, lojistik ve kullanıcı beklentisi tarafından desteklenmelidir. Hak etmiyorsa canonical son adım olur; önce mimari sadeleşir.
Başka bir deyişle canonical, kötü içerik planını sihirli biçimde düzeltmez. Yalnızca hangi URL'nin temsilci olacağını söyler. Temsilci seçilecek kadar güçlü olmayan sayfaları arka planda biriktirmek, teknik karar değil editoryal borç üretir.
Ne zaman tek sayfaya dönmek daha doğrudur?
Eğer aynı dilde iki pazar sayfası arasında para birimi dışında anlamlı hiçbir fark yoksa, teslimat ve yasal bilgiler de aynıysa, ayrı URL tutmanın faydası sınırlı olabilir. Böyle durumlarda tek sayfaya dönmek ve kullanıcıya sayfa içinde ülke seçimi sunmak daha temiz bir çözüm haline gelir. Karar burada verilir; canonical etiketinde değil.
Çok dilli sitede doğru canonical yönetimi çoğu zaman gösterişli bir teknik hamle değildir. Daha çok, hangi sayfanın gerçekten ayrı bir ürün vaadi taşıdığını dürüst biçimde kabul etme işidir. Fazla birleştirme görünürlüğü budar; fazla çoğaltma ise kaliteyi dağıtır.
Dengeli yapı nettir: ayrı pazar sayfaları kendini işaret eder, birbirini hreflang ile tanır ve yalnızca gerçek teknik kopyalar bir canonical altında birleşir. Bu çizgi korunduğunda hem tarama sinyali temiz kalır hem de kullanıcı yanlış ülke ya da yanlış dil sürümüne düşmez.