Canonical Audit Nasıl Yapılır? Yanlış Canonical, Duplicate URL ve Google-Selected Canonical

Canonical audit, sitedeki rel="canonical" etiketlerini topluca kontrol etmekten ibaret değildir. Asıl amaç, duplicate veya çok benzer URL kümelerinde sitenin hangi URL’yi ana sürüm olarak işaretlediğini ve Google’ın hangi URL’yi temsilci olarak seçtiğini anlamaktır.

Sağlıklı bir canonical audit; user-declared canonical, Google-selected canonical, redirects, XML sitemap, internal linking, indexability ve içerik benzerliğini birlikte değerlendirir.

Çünkü canonical etiketi güçlü bir tercih sinyalidir fakat kesin bir direktif değildir. Google farklı sinyaller nedeniyle sizin belirttiğiniz URL’den farklı bir canonical seçebilir.

Canonical Nedir?

Canonicalization, duplicate veya birbirine çok benzeyen URL’lerden birinin temsilci URL olarak seçilmesi sürecidir.

Örneğin aynı kategori şu varyasyonlardan erişilebilir olabilir:

• https://example.com/matkaplar/
• https://example.com/matkaplar?sort=price
• https://example.com/matkaplar?utm_source=email
• http://example.com/matkaplar/

Bu URL’ler aynı veya çok benzer ana içeriği gösteriyorsa site bir ana sürüm belirlemek isteyebilir.

Canonical etiketi bu tercihi açıklayan sinyallerden biridir:

<link rel="canonical" href="https://example.com/matkaplar/">

User-Declared Canonical ile Google-Selected Canonical Aynı Şey Değildir

Canonical audit’in en kritik ayrımlarından biri budur.

• User-declared canonical, site sahibinin canonical etiketi veya diğer teknik sinyallerle tercih ettiği URL’dir.
• Google-selected canonical, Google’ın duplicate kümesini değerlendirip temsilci olarak seçtiği URL’dir.

İdeal durumda ikisi aynı olabilir. Ancak Google farklı bir URL seçebilir.

Bu nedenle “sayfada doğru canonical etiketi var” sonucu tek başına audit’i bitirmez.

Google Neden Farklı Canonical Seçebilir?

Google’ın farklı canonical seçmesi otomatik olarak teknik hata olduğu anlamına gelmez. Önce URL’lerin gerçekten duplicate olup olmadığı ve sitedeki diğer sinyallerin ne söylediği incelenmelidir.

Farklı canonical seçimine katkıda bulunabilecek durumlar arasında şunlar bulunabilir:

• sayfaların beklenenden daha benzer olması,
• canonical etiketlerinin tutarsız olması,
• internal linklerin başka URL sürümüne gitmesi,
• XML sitemap’te farklı URL bulunması,
• redirect sinyallerinin canonical tercihiyle çelişmesi,
• HTTP ve HTTPS veya www ve non-www varyasyonları,
• parametreli URL’lerin ana URL ile aynı içeriği göstermesi,
• CMS veya JavaScript’in canonical etiketini beklenmedik biçimde değiştirmesi.

Canonical Audit’e URL Envanteri ile Başlayın

Önce sitedeki URL tiplerini anlamak gerekir. Büyük sitelerde canonical hataları çoğu zaman tek tek sayfalardan değil, template veya URL üretim sistemlerinden kaynaklanır.

Örnek URL segmentleri:

• ana sayfa,
• kategori ve alt kategori,
• ürün sayfaları,
• faceted navigation URL’leri,
• pagination,
• site içi arama URL’leri,
• blog ve rehber içerikleri,
• etiket veya taxonomy sayfaları,
• lokasyon veya hizmet sayfaları,
• parametreli URL’ler,
• redirect ve legacy URL’ler.

Audit çıktısını bu segmentlere ayırmak, bir canonical probleminin sistemik mi yoksa tekil mi olduğunu görmeyi kolaylaştırır.

Her URL İçin Hangi Alanları Toplamalısınız?

Teknik crawl veya URL inventory üzerinde en azından şu alanlar yararlıdır:

Alan	Neden önemli?
URL	İncelenen kaynak URL
Status code	Kaynak URL’nin 200, 3xx, 4xx veya 5xx durumu
Indexability	URL’nin indexable olup olmadığı
Declared canonical	Sayfanın bildirdiği canonical hedefi
Canonical target status	Canonical hedefinin HTTP durumu
Self-canonical	URL’nin kendisini canonical gösterip göstermediği
Sitemap presence	URL’nin sitemap’te bulunup bulunmadığı
Internal inlinks	Site içi bağlantıların hangi URL sürümüne gittiği
Google-selected canonical	Gerekli URL örneklerinde Search Console kontrolü

Self-Canonical Ne Zaman Beklenir?

Organik aramada bağımsız görev taşımasını istediğiniz canonical URL’lerde self-referencing canonical yaygın ve anlaşılır bir uygulamadır.

Örneğin:

URL:
https://example.com/matkaplar/
Canonical:
https://example.com/matkaplar/

Ancak her URL’nin self-canonical olması gerektiği gibi mekanik bir kural uygulanmamalıdır. Duplicate veya parametreli varyasyonlar başka bir ana URL’ye canonical verebilir.

Audit’in görevi “kaç URL self-canonical?” saymaktan çok, canonical davranışının page role ve duplicate ilişkisiyle tutarlı olup olmadığını anlamaktır.

Canonical Hedefi 200 Dönüyor mu?

Canonical target’ın başka bir URL’ye redirect etmesi, 404 vermesi, 5xx üretmesi veya index dışı olması site içinde çelişkili sinyaller oluşturabilir.

Örnek:

Kaynak URL
/category-a/
Canonical
/category-b/
Category-b response
301 → /category-c/

Bu durumda canonical doğrudan tercih edilen son URL’yi göstermiyorsa gereksiz canonical zinciri oluşur.

Benzer biçimde canonical hedefi 404 veriyorsa önce bunun yanlış URL, kaldırılmış içerik veya CMS üretim hatası olup olmadığı araştırılmalıdır.

Canonical Chain ve Loop Nasıl Tespit Edilir?

Canonical ilişkisinin mümkün olduğunca açık olması gerekir.

Canonical chain örneği:

A → B
B → C
C → C

Canonical loop örneği:

A → B
B → A

Bu yapılar sitenin tercih ettiği temsilci URL’yi gereksiz biçimde belirsizleştirir. Audit sırasında canonical hedeflerinin tekrar canonical verdiği zincirler ayrı raporlanmalıdır.

Canonical ile Redirect Aynı Şey Değildir

301 redirect kullanıcıyı ve crawler’ı başka URL’ye taşır. Canonical ise duplicate veya çok benzer içerikler arasında tercih edilen URL’yi işaretleyen sinyaldir.

Bu yüzden artık kullanılmaması gereken eski bir URL için yalnız canonical eklemek, gerçek redirect ihtiyacının yerine geçmez.

Örnek migration senaryosunda:

/eski-kategori/
301
/yeni-kategori/

ilişkisi, iki URL’nin eş zamanlı erişilebilir kaldığı canonical senaryosundan farklıdır.

Canonical ile Noindex Aynı Sorunu Çözmez

noindex, bir URL’nin arama sonuçlarında indekslenmemesi yönünde bir direktiftir. Canonical ise duplicate kümesinde hangi URL’nin temsilci olması gerektiğini bildirir.

Bu araçları “ikisinden birini koy, sorun çözülür” mantığıyla kullanmak doğru değildir.

Örneğin bir facet URL organik görev taşımıyor olabilir. Burada karar URL’nin crawl, index ve duplicate rolüne göre verilmelidir. Canonical etiketi, her index dışı bırakılmak istenen URL için genel amaçlı çözüm değildir.

Internal Linking Canonical Tercihiyle Tutarlı mı?

Sitenin canonical olarak tercih ettiği URL’ye kendi internal linkleriyle de tutarlı biçimde bağlanması beklenir.

Şu yapı çelişkilidir:

Canonical owner:
/matkaplar/
Navigation links:
/matkaplar?ref=menu
Category cards:
/matkaplar/index.php
Breadcrumb:
/matkaplar

Bu URL’lerin tamamı aynı içeriğe gidiyorsa site kendi içinde farklı sürümleri dolaşıma sokuyor olabilir.

Canonical audit sırasında internal link hedefleri normalize edilmeli ve mümkün olduğunca tercih edilen canonical URL sürümüne yönlendirilmelidir.

XML Sitemap Canonical URL’leri mi İçeriyor?

XML sitemap, indekslenmesini istediğiniz tercih edilen URL’leri sunmak için kullanılmalıdır.

Sitemap’te:

• redirect URL’ler,
• noindex URL’ler,
• canonical olmayan duplicate varyasyonlar,
• 404 veya 5xx URL’ler

bulunuyorsa site sinyalleri birbirine karışabilir.

Audit sırasında sitemap URL’leri canonical inventory ile karşılaştırılmalıdır.

HTTP, HTTPS, WWW ve Slash Varyasyonlarını Kontrol Edin

Tek URL’nin farklı teknik varyasyonları erişilebilir durumda kalabilir:

• http://example.com/page
• https://example.com/page
• https://www.example.com/page
• https://example.com/page/

Canonical audit bu varyasyonların redirect, canonical ve internal linking sinyallerinin aynı tercih edilen URL sürümünü destekleyip desteklemediğini kontrol etmelidir.

Parametreli URL’lerde Canonical Nasıl Denetlenir?

E-ticaret sitelerinde canonical karmaşasının önemli bölümü filtre, sıralama, takip ve diğer parametrelerden gelir.

Örnekler:

• ?sort=price
• ?color=black
• ?brand=bosch
• ?utm_source=newsletter
• ?page=2

Ancak bütün parametre URL’leri aynı değildir.

Bir URL gerçekten duplicate varyasyon olabilirken başka bir facet ayrı search demand ve farklı product set nedeniyle bağımsız landing page görevi taşıyabilir. Bu nedenle canonical audit, URL parametresi gördüğü her sayfayı otomatik ana kategoriye canonical etmemelidir.

E-Ticaret Kategori ve Facet Sayfalarında En Kritik Risk

Bir kategori ile marka, renk veya özellik filtresi aynı product set’e çok yakınsa canonical kararı duplicate ilişkisine göre verilebilir.

Fakat şu iki URL farklı kullanıcı ihtiyacı taşıyorsa:

/matkaplar/
/bosch-matkaplar/

ikinci sayfayı yalnız benzer ürünler gösteriyor diye ana kategoriye canonical etmek ayrı bir search intent’i ortadan kaldırabilir.

Canonical teknik temizlik aracı olduğu kadar ownership kararının da sonucudur. Yanlış page role tanımı varsa canonical etiketi bunu düzeltemez.

Pagination URL’lerinde Canonical Audit Nasıl Yapılır?

Pagination sayfalarını otomatik olarak ilk sayfaya canonical etmek her durumda doğru değildir.

Örneğin:

/kategori/
/kategori/?page=2
/kategori/?page=3

Sayfa 2 ve 3 farklı ürünleri gösteriyorsa ana içerik tamamen aynı değildir. Audit sırasında pagination’ın ürün discovery içindeki rolü, indexability, internal links ve canonical davranışı birlikte incelenmelidir.

Burada amaç yalnız duplicate azaltmak değil, Googlebot’un derin ürünlere ulaşma yolunu da korumaktır.

Product Variant URL’lerinde Canonical Nasıl Değerlendirilir?

Ürün varyantları canonical audit’in sık hata üreten alanlarından biridir.

Örneğin beden veya renk varyantları:

/urun/model-x/
/urun/model-x?renk=siyah
/urun/model-x?renk=mavi

aynı ana ürün entity’sinin varyantları olabilir.

Ancak variant URL’lerinin ayrı indekslenip indekslenmeyeceği; arama talebi, ürün içeriği, kullanılabilirlik ve site veri modeline bağlıdır. Canonical audit burada teknik etiketi product ownership kararından ayrı değerlendirmemelidir.

JavaScript Canonical’ı Değiştiriyor mu?

JavaScript kullanan sitelerde kaynak HTML ile render edilmiş DOM’daki canonical farklı olabilir.

Audit sırasında yalnız crawler’ın ham HTML çıktısına güvenmek yerine gerektiğinde render edilmiş sürüm de kontrol edilmelidir.

Özellikle:

• SPA veya client-side routing,
• dynamic rendering,
• head management kütüphaneleri,
• CMS + JavaScript kombinasyonları

canonical etiketinin istemeden değişmesine veya birden fazla canonical elementi oluşmasına yol açabilir.

Bir Sayfada Birden Fazla Canonical Varsa Ne Olur?

HTML içinde birden fazla ve birbiriyle çelişen canonical öğesi bulunması açık bir kalite problemidir.

Örnek:

<link rel="canonical" href="https://example.com/a/">
<link rel="canonical" href="https://example.com/b/">

Bu durumda önce canonical’ın hangi template, plugin veya component tarafından tekrar üretildiği bulunmalıdır.

Cross-Domain Canonical Audit Nasıl Yapılır?

Bazı yapılarda aynı veya çok benzer içerik farklı domainlerde yayınlanabilir ve cross-domain canonical kullanılabilir.

Bu senaryoda:

• canonical hedefinin gerçekten eşdeğer içerik olup olmadığı,
• hedef URL’nin erişilebilirliği,
• yanlış domain’e canonical üreten CMS veya hack vakaları,
• site sahibinin gerçekten bu tercihi amaçlayıp amaçlamadığı

özellikle kontrol edilmelidir.

Beklenmeyen cross-domain canonical güvenlik ve altyapı problemi de olabilir.

Search Console ile Canonical Nasıl Kontrol Edilir?

URL Inspection, örnek URL’lerde Google’ın canonical seçimini incelemek için kullanılabilir.

Indexed version tarafında iki alan özellikle önemlidir:

• User-declared canonical
• Google-selected canonical

Bu alanlar farklıysa sayfanın kaynak HTML’i, canonical target, duplicate adaylar, internal links, sitemap ve içerik farkları birlikte incelenmelidir.

Önemli bir ayrım: Live Test, Google-selected canonical’ın ne olacağını tahmin etmez. Google-selected canonical bilgisi indexed version üzerinden değerlendirilir.

“Duplicate, Google Chose Different Canonical Than User” Ne Demek?

Search Console bu durumu gösterdiğinde Google sizin belirttiğiniz canonical yerine başka bir URL’yi temsilci olarak seçmiştir.

Bunu düzeltmeye çalışmadan önce şu kontroller yapılmalıdır:

1. Test edilen URL ile user-declared canonical gerçekten duplicate mı?
2. Google-selected canonical hangi URL?
3. Google’ın seçtiği URL kullanıcı açısından daha mantıklı olabilir mi?
4. Internal links hangi URL’ye gidiyor?
5. Sitemap hangi URL’yi içeriyor?
6. Canonical cluster içindeki içerik farkları yeterince belirgin mi?
7. Redirect veya teknik konfigürasyon çelişkisi var mı?

Google’ın farklı URL seçmesini yalnız etiketi tekrar yazarak çözmeye çalışmak çoğu zaman kök nedeni kaçırır.

Canonical Audit’te Duplicate Cluster Nasıl İncelenir?

Tek URL yerine kümeye bakmak daha yararlıdır.

Örneğin aynı ürün şu varyasyonlarda bulunuyorsa:

/urun/model-x/
/product/model-x/
/urun/model-x?ref=category
/urun/model-x?utm_source=email

audit şu sorulara cevap vermelidir:

• Hangi URL ana owner?
• Diğer URL’ler neden üretiliyor?
• Hepsi crawl edilebilir mi?
• Hepsi internal link alıyor mu?
• Canonical sinyalleri aynı hedefi mi gösteriyor?
• Sitemap yalnız owner URL’yi mi içeriyor?
• Google hangi URL’yi canonical seçiyor?

Canonical Sorunlarını Önceliklendirin

Her canonical warning aynı ticari veya teknik öneme sahip değildir.

Bulgu	Öncelik
Money page yanlış URL’ye canonical veriyor	Yüksek
Canonical target 404 / 5xx	Yüksek
Site çapında canonical template hatası	Yüksek
Google önemli owner yerine duplicate URL seçiyor	Yüksek
Sitemap canonical olmayan URL’lerle dolu	Orta-Yüksek
Internal links sürekli duplicate URL’lere gidiyor	Orta-Yüksek
Tekil düşük değerli parametre hatası	Bağlama göre

Canonical Audit İçin Önerilen Teknik Akış

1. Sitenin crawl ve URL envanterini çıkarın.
2. URL’leri template ve page role bazında segmentleyin.
3. Her URL’nin status code, indexability ve canonical hedefini alın.
4. Self-canonical, canonicalized ve canonical’sız URL’leri ayırın.
5. Canonical target status code’larını kontrol edin.
6. Canonical chain, loop ve çoklu canonical hatalarını bulun.
7. Internal link hedeflerini canonical URL’lerle karşılaştırın.
8. XML sitemap inventory’sini canonical URL’lerle karşılaştırın.
9. Parametre, facet, pagination ve variant kümelerini ayrıca inceleyin.
10. Önemli örnek URL’lerde Search Console user-declared ve Google-selected canonical alanlarını karşılaştırın.
11. Problemleri page role ve organik değerine göre önceliklendirin.
12. Düzeltmeden sonra crawl ve Search Console kontrollerini tekrar edin.

Düzeltme Sonrası Nasıl Doğrulanır?

Canonical değişikliği yayınlandığı anda Google’ın seçimi aynı saniye değişmez. Google’ın sayfaları yeniden crawl etmesi ve duplicate cluster’ı yeniden değerlendirmesi gerekir.

Yayın sonrası:

• HTML ve render edilmiş DOM’u tekrar kontrol edin,
• canonical target’ın doğru HTTP status verdiğini doğrulayın,
• internal links ve sitemap’i yeniden crawl edin,
• önemli URL’lerde URL Inspection indexed data’yı izleyin,
• canonical-related indexing durumlarını zaman içinde karşılaştırın.

Search Console’da anlık değişim beklemek yerine teknik sinyallerin tutarlı hale geldiğini ve Google’ın sonraki crawl’larda bu yapıyı yeniden değerlendirdiğini izlemek gerekir.

Canonical Audit Checklist

• Her önemli indexable owner URL’nin canonical davranışı doğru mu?
• Canonical target erişilebilir ve beklenen URL mi?
• Canonical chain veya loop var mı?
• Birden fazla canonical elementi oluşuyor mu?
• HTTP/HTTPS, www/non-www ve slash varyasyonları tutarlı mı?
• Internal links canonical URL sürümüne mi gidiyor?
• XML sitemap yalnız tercih edilen URL’leri mi içeriyor?
• Redirect sinyalleri canonical tercihiyle uyumlu mu?
• Facet ve parametre URL’leri gerçek page role’e göre yönetiliyor mu?
• Pagination yanlışlıkla ilk sayfaya konsolide ediliyor mu?
• Product variant ownership ile canonical politikası uyumlu mu?
• JavaScript canonical etiketini değiştiriyor mu?
• Önemli örneklerde user-declared ve Google-selected canonical aynı mı?
• Google farklı canonical seçtiğinde duplicate cluster gerçekten incelendi mi?

Canonical Audit’i Etiket Kontrolünden Çıkarın

İyi canonical audit, yalnız “canonical var/yok” raporu üretmez. Sitenin duplicate URL kümelerini nasıl yönettiğini, hangi URL’leri owner olarak gördüğünü ve Google’a verdiği sinyallerin birbirini destekleyip desteklemediğini ortaya çıkarır.

Site genelinde canonical, duplicate URL, redirect, sitemap ve query-to-page ilişkilerini birlikte incelemek için SEO Audit kapsamını; crawling, indexation ve teknik uygulama sorunları için Teknik SEO yaklaşımını inceleyebilirsiniz.