Canonical etiketi, içerik çakışması ve URL varyasyonu sorunlarını çözmek için tasarlanmış bir yönlendirme mekanizmasıdır. Bir sayfanın "tercih edilen" versiyonunu Google'a bildiren bu etiket, doğru uygulandığında hangi URL'nin indeksleneceğini ve hangi sayfanın sıralama gücünü toplayacağını belirler. Sorun şu ki pek çok site canonical etiketini eksiksiz biçimde yapılandırdığını düşünürken aslında sessiz ama sistematik hatalar üretmektedir.
Canonical etiketinin çalışması için birden fazla koşulun aynı anda karşılanması gerekir. Etiketin sözdizimi doğru olmalı, gösterdiği URL gerçekten erişilebilir ve indekslenebilir olmalı, aynı sayfadaki diğer sinyallerle çelişmemeli ve Googlebot'un sayfayı render ettiği anda da aynı değeri taşımalıdır. Bu koşulların herhangi birinin karşılanmaması durumunda Google canonical önerisini yoksayabilir ve kendi tercih ettiği URL'yi seçer.
Canonical hatalarının büyük kısmı görünür değildir. Sayfa 200 yanıtı döndürür, etiket kaynak kodda yer alır ve site dışarıdan sorunsuz görünür. Ancak Googlebot'un aynı içeriği farklı URL'ler üzerinden çoklu isteklerle taradığı log satırlarına veya GSC'nin beklenmedik dizin kararlarına bakıldığında canonical yönlendirmesinin nerede sessizce başarısız olduğu anlaşılır.
Self-canonical yokluğu sessiz bir hata olarak kalır çünkü hiçbir araç onu doğrudan raporlamaz
Canonical etiketini yalnızca çakışan içerikler için düşünmek yaygın bir eksikliktir. Tekil ve benzersiz içerik taşıyan sayfalarda bile self-canonical (yani sayfanın kendi URL'sini işaret eden canonical) bulunmalıdır. Bu etiketin yokluğu Google'ın neyin tercih edilen URL olduğuna dair kendi kararını vermesine zemin hazırlar.
Self-canonical olmadığında Google, aynı içeriğe ulaşan farklı URL varyasyonlarını (parametreli haller, www/non-www farkı, http/https geçişleri, trailing slash varyasyonları) birbirinden bağımsız adaylar olarak değerlendirebilir. Bu değerlendirme genellikle tarama döngüsü içinde gerçekleşir ve araçlar tarafından doğrudan "self-canonical eksik" olarak raporlanmaz. Screaming Frog veya benzer tarama araçlarının varsayılan ayarları bu hatayı listelemez; görmek için canonical sütununu boş olan URL'leri filtrelemek gerekir.
Pratikte bu eksiklik en sık sayfa şablonlarında ortaya çıkar. Bir e-ticaret sitesinde kategori sayfaları, filtreleme sonuçları veya sıralama varyasyonları ek mantık gerektirdiği için canonical etiket alanı şablondan çıkarılmış olabilir. Bu durumda yüzlerce URL, herhangi bir canonical sinyali taşımadan yayına çıkmış olur. Site düzeyinde düzenli tarama çıktılarının canonical alanı boş olan satırlarını izlemek pratik bir kontrol noktasıdır.
Canonical ve noindex aynı sayfada birlikte çalışmaz, birisi diğerini geçersiz kılar
Canonical etiketi Google'a "bu sayfanın doğru sürümü şurasıdır" der. Noindex etiketi ise "bu sayfayı indeksleme" der. İkisini aynı sayfada birlikte kullanmak çelişkili bir sinyal paketine yol açar ve Google'ın bu çelişkiyi nasıl çözümleyeceği deterministik değildir.
Yaygın senaryo şudur: Bir sayfa noindex aldıkça Googlebot zamanla onu taramayı azaltır ya da tamamen bırakır. Canonical ise başka bir URL'ye işaret etmektedir. Ancak Googlebot taramayı bıraktığı sayfadan canonical sinyalini de okuyamaz. Bu durumda canonical yönlendirmesinin hedef URL üzerinde herhangi bir etkisi kalmaz; kaynak URL ne indekslenir ne de canonical gücünü hedefe aktarır.
Tersi de sorun üretir: Hedef canonical URL noindex alırsa canonical önerisi işlevsiz hale gelir. Kaynak sayfalar canonical ile bir URL'ye yönlendirirken o URL noindex nedeniyle indeks dışında kalır. Bu tür yapılandırma hataları tarama araçlarında tek tek görünebilir ancak bütünlüklü bir analiz yapılmadan fark edilmesi güçtür. Tarama çıktısında canonical hedefini ayrı bir sütun olarak listeleyip hedef URL'nin noindex durumunu çapraz kontrol etmek bu hatayı bulmanın en güvenilir yoludur.
Parametreli URL'lerde canonical değerleri şablon kaynaklı tutarsızlığa düşer
Parametreli URL'ler, arama filtresi veya sıralama tercihini içeren ?sort=price&color=blue gibi adresler, canonical etiket uygulamasının en karmaşık alanını oluşturur. Şablona yanlış enjekte edilen canonical değeri, dinamik parametre kombinasyonlarında farklı sonuçlar üretir ve bunu manuel olarak tespit etmek neredeyse imkânsız hale gelir.
Bir örnek üzerinden düşünmek gerekirse: Bir kategori sayfası şablonu canonical'ı canonicalBase + requestPath olarak oluşturuyorsa ve parametre filtrelemesi doğru çalışmıyorsa her URL varyasyonu kendi varyant adresini canonical olarak işaret eder. Yani /urunler?sort=price sayfası /urunler?sort=price adresini, /urunler?color=blue sayfası ise /urunler?color=blue adresini canonical gösterir. Her ikisi de aslında /urunler ana sayfasını işaret etmesi gerekirken birbirlerinden bağımsız canonical'a sahip onlarca ya da yüzlerce URL ortaya çıkar.
Bu tür hataları bulmak için tarama aracının canonical'ı takip etmeden raporlamasını sağlamak ve ardından canonical değerinin URL ile özdeş olduğu kayıtları filtrelemek gerekir. Parametreli URL sayısı büyükse tek tek değil, parametre grubu bazında örnekleme yaparak tutarlılık kontrolü uygulanabilir. Teknik SEO analizinde URL varyantlarının canonical eşleşmesini sistematik biçimde kontrol etmek, bu tür şablon hatalarını erken aşamada yakalamanın temel yoludur.
Cross-domain canonical, yetki dengesi kurulmadan yönlendirme değeri taşımaz
Cross-domain canonical (bir sitenin başka bir alan adındaki URL'yi canonical göstermesi) teoride geçerli bir uygulama olsa da pratikte pek çok hata barındırır. Bu yapıyı genellikle içerik sendikasyon senaryolarında, çoklu dil veya bölge versiyonlarında ya da eski domain'den yeni domain'e geçiş süreçlerinde görülür.
Google'ın cross-domain canonical'ı kabul edip etmemesi, kaynak ve hedef site arasındaki güvenilirlik dengesiyle doğrudan ilişkilidir. Hedef alan adı daha düşük otoriteli bir site ise Google bu canonical'ı görmezden gelip her iki sayfayı bağımsız içerik olarak değerlendirebilir. Bu durumda kaynak site içeriği canonical olarak işaret ettiği URL üzerinde güç birikimine katkı sağlayamaz; aksine iki ayrı içerik bloğu rakip konuma düşebilir.
Cross-domain canonical hatalarını tespit etmenin iki yolu vardır. Birincisi, tarama aracını her iki alan adı üzerinde ayrı ayrı çalıştırıp canonical değerlerini çapraz karşılaştırmak. İkincisi, GSC'de her iki alan adının performans verilerini inceleyerek hangi URL'nin impression ve tıklama aldığını gözlemlemek. Kaynak URL beklenmeden impression alıyorsa ve hedef URL sessiz kalıyorsa cross-domain canonical'ın Google tarafından onaylanmadığının sinyalini verir. Taranabilirlik ve indeksleme sorunlarını analiz ederken bu çapraz kontrol adımı sıklıkla atlanır.
Rendered DOM'daki canonical değeri kaynak koddakinden farklı çıkabilir
Sayfa kaynak kodunu görüntülediğinizde gördüğünüz canonical değeri, Googlebot'un sayfayı render ettiği anda gördüğüyle aynı olmayabilir. JavaScript tabanlı canonicalization (yani canonical etiketini sunucu değil istemci tarafı script'lerin eklemesi veya değiştirmesi) bu iki değer arasında sessiz bir ayrışma yaratır.
Googlebot JavaScript'i iki aşamalı işler: önce HTML'i tarar, sonra render eder. Render aşaması gecikebilir veya tüm senaryolarda aynı biçimde gerçekleşmeyebilir. Eğer canonical etiketi JavaScript ile dinamik olarak enjekte ediliyorsa ya da mevcut bir canonical değeri JavaScript tarafından güncelleniyorsa, Googlebot bu değişikliği her taramada yakalayamayabilir. Bu ayrışma rendered HTML ile kaynak kodun karşılaştırılması gerekliliğinin en somut örneklerinden birini oluşturur.
Kontrol için Google Search Console'un URL İnceleme aracını kullanmak ve "Sayfa getirme" bölümünde canonical değerini incelemek gerekir. Bu bölüm, Google'ın sayfayı nasıl render ettiğini ve hangi canonical'ı gördüğünü doğrudan raporlar. Kaynak koddaki değerle örtüşmüyorsa JavaScript kaynaklı bir canonical ayrışması var demektir. Bu tür sayfaları toplu taramak için render edilmiş HTML çıktısını ayrıca analiz eden araçlar kullanmak gerekir; standart tarama yalnızca kaynak kod canonical'ını okur ve bu farkı göremez.
Tarama çıktısı ve GSC, canonical hatalarını farklı çözünürlüklerde gösterir
Canonical hatalarının tamamını tek bir araçla tespit etmek mümkün değildir. Tarama araçları ve GSC birbirini tamamlayan ama farklı derinlikte bilgi sunan veri kaynaklarıdır.
Tarama aracı (Screaming Frog, Sitebulb ya da benzerleri) her URL'nin canonical değerini, o değerin geçerli bir URL'ye işaret edip etmediğini ve kaynak-hedef zincirinin düzgün kurulup kurulmadığını raporlar. Ancak tarama aracı Google'ın bu canonical'ı gerçekten onaylayıp onaylamadığını bilemez. Google, canonical önerilerini bir "ipucu" olarak değerlendirir ve başka sinyalleri daha güçlü bulursa kendi tercihini seçebilir.
GSC'nin Dizin Oluşturma > Sayfalar raporu ise Google'ın hangi URL'yi kanonize ettiğini (yani canonical olarak indekslediğini) doğrudan gösterir. Bir URL "Yinelenen, Google tarafından başka bir sayfayı standart olarak seçildi" ya da "Standart olarak başka bir sayfayı belirledi" gibi notlarla listede yer alıyorsa canonical öneri ile Google'ın seçimi arasında uyumsuzluk var demektir. Log analizi ise bu tabloya üçüncü bir boyut ekler: aynı içeriğin birden fazla URL'den tekrar tekrar taranması, canonical'ın Googlebot için gerçek anlamda çalışmadığının en güçlü işaretidir.
Bu üç veri kaynağını birlikte okumak şu soruyu yanıtlar: Canonical etiketi sözdizimsel olarak doğru mu? Bunu tarama aracı söyler. Google bu canonical'ı onayladı mı? Bunu GSC söyler. Googlebot hâlâ çakışan URL'leri bağımsız olarak tarayıp durdu mu? Bunu log verisi söyler. Crawl budget analizinde canonical'ın etkinliği bu üçlü kontrolle doğrulanmadan tarama verimliliği değerlendirmesi eksik kalır.
Canonical hataları zaman zaman yalnızca görünürlük kaybı değil, birikimli indeks kirliliği olarak da kendini gösterir. Onlarca URL varyasyonu yanlış canonical ile birlikte indekste yer almaya devam ederse aynı içerik için birden fazla URL rekabet halinde kalır. Bu durum hem tarama kaynaklarını hem de sıralama gücünü parçalar.
Tespiti kolaylaştıran en önemli alışkanlık, canonical denetimini tek bir tarama çıktısına indirgemek yerine çok katmanlı yürütmektir: kaynak kodu, rendered DOM, GSC dizin durumu ve log verisi bir arada okunduğunda canonical zincirinin nerede kırıldığı ve nerede sessizce başarısız olduğu görünür hale gelir. Duplicate title ve meta açıklama sorunları gibi canonical hataları da çoğu zaman şablon düzeyinde kök nedenler barındırır; tekil URL düzeltmeleri bu köklere dokunmadan kalıcı çözüm üretmez.
Canonical denetimini bir kez yapılan kontrol olarak değil, site büyüdükçe ve şablonlar değiştikçe periyodik olarak tekrarlanan bir süreç olarak konumlandırmak gerekir. Yeni sayfa türleri eklendiğinde, şablon güncellemesi yapıldığında ya da URL yapısında değişikliğe gidildiğinde canonical sinyallerinin beklendiği gibi çalışıp çalışmadığını doğrulamak, sorunların birikmeden tespit edilmesinin tek güvenilir yoludur.