TechnoRadical notları · Makale
Kanonik etiket ne zaman sessizce yanlış kurulur
Kanonik etiket sessizce yanlış kurulabilir. Google'ın resmi rehberindeki 11 hata nedenini, JS çakışmasını ve sayfalama tuzağını kaynaklı anlatıyoruz.
Kanonik etiket (aynı içeriğin hangi adresinin asıl sayılacağını arama motoruna söyleyen HTML satırı), sessizce yanlış kurulabilir: hiçbir hata mesajı çıkmaz, sayfa kullanıcıya normal görünmeye devam eder, yalnızca Google’ın indekste tuttuğu adres beklenmedik biçimde değişir veya hiç değişmez. Bu sessizlik on bir ayrı yapılandırma hatasından doğabilir: etiketin <head> dışına sızması, CMS eklentisinin yanlış hedefe yönlendirmesi, robots.txt/noindex/göreceli URL çelişkileri, hreflang ile dil uyumsuzluğu, JavaScript enjeksiyonunun çelişkili etiket üretmesi, sayfalamada 2. sayfanın canonical’ını 1. sayfaya göstermek, sunucu yanlış yapılandırması, kötü niyetli müdahale, sendikasyon içeriği ve dört yıl önce kapanmış URL Parametreleri aracına hâlâ güvenmek. Google’ın resmi “Fix canonicalization issues” rehberi bu nedenlerden altısını tek tek isimlendiriyor, ama Türkçe arama sonuçlarında bu konuda çıkan dokuz kaynaktan hiçbiri bu sayfaya atıf yapmıyor. Her hata kalıbının kendi teşhis yöntemi var; kesin doğrulama ise URL İnceleme aracıyla Google’ın gerçekte hangi adresi seçtiğini görmekten geçiyor. Hiçbir yöntem (301 yönlendirme, canonical etiketi, sitemap kaydı) zorunlu değildir; hiçbiri belirtilmezse Google kendi objektif seçimini yapar, ama yanlış kurulmuş bir canonical, hiç canonical vermemekten daha kötü bir sonuç doğurabilir.
Kanonik etiket sessizce yanlış kurulduğunda site ne kaybeder
Site bir hata mesajı almaz; kaybettiği şey, seçilmeyen URL’nin topladığı sinyallerin Google’ın seçtiği başka bir adrese devredilmesi ve seçilmeyen URL’nin o sorgudaki tüm gösterim ve tıklama payını kaybetmesidir.
Google Search Central’ın canonicalization sayfası süreci şöyle tanımlıyor: önce her sayfanın ana içeriği belirlenir, benzer içerikli sayfalar bir grupta toplanır, sonra Google toplanan sinyallere göre “objektif olarak en eksiksiz ve kullanışlı” sayfayı seçer. Bu kararı etkileyen sinyaller arasında HTTP/HTTPS protokolü, yönlendirmeler, sitemap kaydı ve rel="canonical" etiketi sayılıyor; Google seçtiği sayfayı içerik ve kaliteyi değerlendirmede ana kaynak olarak kullanıyor. Aynı rehber üç yöntemi güç sırasına göre veriyor: 301 yönlendirme ve rel="canonical" etiketi güçlü sinyal, sitemap kaydı zayıf sinyal, ama hiçbiri zorunlu değil. Google’ın kendi ifadesiyle: hiçbir yöntem belirtilmezse “Google, hangi URL sürümünün arama kullanıcılarına gösterilmek için objektif olarak en iyi sürüm olduğunu kendisi belirler.”
Sessiz hata tam bu noktada devreye giriyor. Kullanıcı sayfayı ziyaret etmeye devam eder, 404 çıkmaz, tarayıcı hiçbir uyarı vermez. Değişen tek şey, Google’ın hangi URL’yi indekste temsilci olarak tuttuğudur; seçilmeyen URL’nin geri bağlantı ve iç bağlantı sinyalleri seçilen adrese devredilir, seçilmeyen adres ise aynı sorguda bir daha hiç görünmez. Google sinyalleri topladıktan sonra kendi seçtiği sayfayı öne çıkarır ve böylece aynı sorguda birbiriyle yarışan sayfalarınızı tek bir kazanana indirger; bu indirgemeyi besleyen sinyaller ise aşağıdaki on bir yoldan biriyle sessizce yanlış kurulabilir.
Kanonik etiket neden <head> dışında sessizce yok sayılır
Google, rel="canonical" etiketini yalnızca HTML’in <head> bölümünde kabul eder; etiket <body> içine düşerse Google onu tamamen yok sayar ve herhangi bir hata bildirmez.
Google Search Central’ın canonical belirleme rehberi bunu açıkça yazıyor: “rel=“canonical” link öğesi, yalnızca HTML’in <head> bölümünde yer alıyorsa kabul edilir.” Bazı CMS temaları veya üçüncü parti scriptler, sayfa şablonunu değiştirirken bu etiketi yanlışlıkla <body> içine enjekte edebilir; tema güncellemesi sırasında <head> kapanışının yanlış yere taşınması veya bir eklentinin çıktıyı sayfa gövdesine yazdırması bu senaryonun tipik nedenidir.
Bu hatayı yakalamanın çalışan yöntemi, tarayıcının “İncele” (DevTools) panelini değil, ham kaynak kodunu görmektir. Tarayıcıda sayfayı açıp Ctrl+U (veya sağ tık, “Sayfa kaynağını görüntüle”) ile ham HTML görüntülendiğinde, canonical etiketinin </head> kapanışından önce mi sonra mı geldiği doğrudan görülür. “İncele” paneli buna uygun bir kontrol noktası değildir, çünkü tarayıcının render ettiği DOM’u gösterir; tarayıcı geçersiz bir HTML’i kendi kurallarına göre otomatik olarak düzeltip etiketi görsel olarak <head> içindeymiş gibi gösterebilir, oysa Google’ın gördüğü ham kaynak kodda etiket hâlâ <body> içindedir.
CMS eklentisi kanonik URL’yi neden yanlış hedefe yönlendirir
Google, bazı CMS’lerin veya eklentilerin rel="canonical" etiketini ya da 3xx yönlendirmeyi yanlış kullanarak istenmeyen bir URL’ye işaret edebileceğini “incorrect canonical elements” başlığı altında ayrı bir neden olarak sayıyor.
Bu genellikle tek bir eklentinin hatası değil, iki eklentinin aynı anda canonical yazmaya çalışmasının sonucudur. Örneğin bir SEO eklentisi her sayfaya kendi hesapladığı canonical URL’yi yazarken, ayrı bir önbellekleme veya CDN eklentisi statik sayfa üretirken farklı bir canonical değeri ekleyebilir; ikisi de sayfanın <head> bölümüne yazdığı için sonuçta iki ayrı rel="canonical" satırı veya son yazan eklentinin sessizce üzerine yazdığı tek bir yanlış satır ortaya çıkar.
Teşhis, tarayıcının geliştirici araçlarında “Ağ” (Network) sekmesinden ham HTML yanıtını incelemekle başlar; sayfa kaynağında birden fazla rel="canonical" satırı görülüyorsa veya satırdaki URL beklenen adresle uyuşmuyorsa, hangi eklentinin bu değeri yazdığı eklenti listesi tek tek devre dışı bırakılarak (veya eklenti dokümantasyonundaki canonical ayarları kontrol edilerek) bulunur. Kaynak tema veya çekirdek CMS koduysa, sorunun CMS sağlayıcısına net bir örnekle (hatalı URL + sayfa adresi) bildirilmesi, sonraki bir güncellemenin aynı hatayı sessizce tekrar üretmesini önler.
robots.txt, noindex ve göreceli URL canonical’ı hangi kombinasyonda bozar
Dört ayrı Google kuralı aynı anda ihlal edildiğinde canonical etiketi bozulur: canonical hedefinin robots.txt ile engellenmesi, noindex ile canonical’ın birlikte kullanılması, göreceli URL kullanımı ve aynı sayfa için farklı tekniklerde farklı URL belirtilmesi.
Google Search Central’ın robots.txt dokümantasyonu net bir uyarı taşıyor: robots.txt “bir web sayfasını Google’dan gizleme mekanizması değildir” ve disallow edilen bir sayfa, başka bir yerden linkleniyorsa yine de indekslenebilir. Aynı ailedeki canonical rehberi bunun canonicalization tarafındaki karşılığını veriyor: “robots.txt dosyasını canonicalization amacıyla kullanmayın.” Bir sayfanın canonical hedefi robots.txt ile engellenmişse Google o hedefi hiç tarayamaz, dolayısıyla üzerindeki hiçbir sinyali okuyamaz; canonical etiketi teknik olarak yerinde durur ama işlevsizdir.
İkinci çelişki noindex ile ortaya çıkar. Google açıkça öneriyor: “Tek bir site içinde canonical sayfa seçimini engellemek için noindex kullanılmasını önermiyoruz, çünkü bu sayfayı Arama’dan tamamen bloklar.” Bir sayfaya hem “beni tercih et” (canonical) hem “beni hiç gösterme” (noindex) talimatı verilirse sonuç canonical’ın işlevsiz kalması değil, sayfanın aramadan tamamen çıkmasıdır. Üçüncü hata göreceli URL kullanımıdır: Google mutlak URL kullanılmasını öneriyor, çünkü göreceli bir yol (/urun/123 gibi) sayfanın bulunduğu dizine, CDN yapılandırmasına veya <base> etiketine göre farklı şekilde çözümlenebilir. Dördüncü hata ise aynı sayfa için HTML etiketi, HTTP başlığı (Link: header) ve XML sitemap’in farklı URL’ler göstermesidir; CMS ile CDN veya sunucu katmanı ayrı yapılandırıldığında bu çelişki sessizce oluşur.
Dört kural birlikte şu tabloda özetlenir.
| Yapılandırma | Sonuç | Doğru kullanım |
|---|---|---|
| Canonical hedefi robots.txt ile engelli | Google hedefi taramaz, sinyal okunmaz | Canonical hedefini asla robots.txt ile engelleme |
| Canonical + noindex aynı sayfada | Sayfa Arama’dan tamamen bloklanır | İkisini birlikte kullanma; sayfa kalmalıysa yalnız canonical, tamamen çıkmalıysa yalnız noindex |
| Canonical’da göreceli URL | CDN/dizine göre farklı çözümlenme riski | Her zaman mutlak URL (https://... ile başlayan) kullan |
| HTML, HTTP header, sitemap farklı URL gösteriyor | Google hangi sinyale güveneceğini bilemez | Üç kanalda da aynı URL’yi yaz |
Tablodaki dört satır tek başına yeterli değildir, çünkü hangi kombinasyonun doğru sayılacağı sayfanın kaderine bağlıdır. 301, canonical ve noindex arasında seçim yapmak, iki sayfadan hangisinin feda edileceği kararı netleşmeden zaten mümkün değildir.
Çok dilli sitede hreflang ile kanonik nasıl çelişir
hreflang kullanılan sayfalarda canonical, aynı dildeki sayfayı göstermelidir; tüm dil varyantlarını tek bir ana dile canonical’lamak bu kuralı doğrudan ihlal eder.
Google Search Central’ın canonical rehberi bunu tek cümleyle veriyor: “hreflang öğeleri kullanıyorsanız, aynı dildeki bir sayfayı canonical olarak belirttiğinizden emin olun.” Çok dilli sitelerde sık görülen hata, tüm dil sürümlerinin canonical’ını varsayılan dile (genellikle İngilizce veya Türkçe ana sürüm) yöneltmektir; bu, hreflang’ın “her dil kendi sayfasında kalsın” sinyaliyle çelişir. Google’ın kendi troubleshooting rehberi de dil varyantı eksikliğini beklenmedik canonical seçiminin altı adlandırılmış nedeninden biri sayıyor: hreflang eksik veya yanlışsa, farklı bölgelerdeki kullanıcılar için doğru dil sürümü yüzeye çıkamayabilir ve Google başka bir dildeki sayfayı canonical seçebilir.
Bu hatanın somut sonucu, diğer dil sürümlerinin canonical sinyali kendi lehlerine değil ana dile işaret ettiği için zamanla indeksten düşmesidir; site teknik olarak on yedi dilde yayın yapıyor görünse de Google fiilen tek dili canonical olarak tutar. Dil varyantlarındaki bu uyumsuzluğu elle, sayfa sayfa aramak yerine hreflang ve canonical etiketlerini birlikte tarayan denetim sorunlu çiftleri tek seferde listeler.
JavaScript ile eklenen kanonik Google’ın gördüğünden neden farklı olabilir
Google, JavaScript ile canonical etiketi eklenmesini önermiyor ama mümkün olduğunu kabul ediyor; şart koştuğu tek kural sayfada yalnızca tek bir rel="canonical" etiketi olmasıdır, çünkü çelişkili veya çoklu etiket “beklenmedik sonuçlara” yol açabiliyor.
Google’ın JavaScript SEO temelleri sayfası şöyle diyor: “Bunun için JavaScript kullanmanızı önermesek de, JavaScript ile bir rel=“canonical” link etiketi eklemek mümkündür.” Ardından uyarıyor: “sayfada bunun tek rel=“canonical” link etiketi olduğundan emin olun. Hatalı uygulamalar birden fazla rel=“canonical” link etiketi oluşturabilir veya mevcut bir rel=“canonical” link etiketini değiştirebilir. Çelişkili veya çoklu rel=“canonical” link etiketleri beklenmedik sonuçlara yol açabilir.” Aynı aileden “Consolidate duplicate URLs” sayfası en iyi yöntemi netleştiriyor: canonical URL’yi mümkünse doğrudan HTML kaynak kodunda belirtmek ve JavaScript’in bu etiketi sonradan değiştirmediğinden emin olmak; yalnızca kaynak koda eklenemiyorsa JavaScript ile eklenmelidir.
Bu hata Türkçe kaynaklarda hiç işlenmiyor, çünkü görünür değil: JavaScript ile render edilen bir sitede şablon hem statik bir canonical hem de çalışma zamanında farklı bir canonical enjekte edebilir, ama tarayıcının “İncele” paneli yalnızca son (render edilmiş) hâli gösterir. Çelişkiyi görmenin çalışan yolu, ham HTML’i tarayıcı DOM’undan bağımsız almaktır.
curl -s https://example.com/urun/123 | grep -i 'rel="canonical"'Bu komutun çıktısı, sayfanın sunucudan geldiği hâldeki (JavaScript çalışmadan önceki) canonical değerini gösterir. Tarayıcının “İncele” panelindeki DOM görünümü ayrıca kontrol edilir; ikisi farklı bir URL gösteriyorsa, JavaScript sayfa yüklendikten sonra ham HTML’deki etiketi değiştiriyor demektir ve bu, Google’ın hangi değeri esas alacağını belirsizleştiren tam olarak “çelişkili etiket” durumudur.
Sayfalama sayfalarında kanonik en sık hangi hatayla kurulur
En sık görülen sayfalama hatası, 2. sayfanın canonical’ını 1. sayfaya göstermektir; Google’ın Arama Savunucusu John Mueller’a göre bu yanlıştır, çünkü sayfa 2 sayfa 1’e eşdeğer değildir.
Mueller, resmî olmayan bir r/TechSEO forum yanıtında (Search Engine Journal’ın aktardığı şekliyle) şunu yazdı: “Bu gönderi canonicalization ile ilgili olduğu için kaçınılması gereken asıl şey, 2. sayfada 1. sayfaya işaret eden rel=canonical kullanmaktır. 2. sayfa, 1. sayfaya eşdeğer değildir, bu yüzden pratikte böyle bir rel=canonical yanlış olur.” Bu bir Google dokümantasyon sayfası değil, gayri resmi bir forum yanıtıdır; yine de Google’ın Arama Savunucusu’nun adı geçen bir açıklaması olarak pratik bir yönlendirme sayılır. Google 2019’da rel=next/rel=prev etiketlerini sıralama sinyali olarak kullanmayı bıraktı, ama bu ilke o değişiklikten sonra da geçerliliğini korudu: sayfalanmış bir serideki her sayfa kendi içeriğini taşır, dolayısıyla birbirinin duplikesi değildir.
Doğru kurulum, sayfalanmış serideki her sayfanın kendi self-referencing canonical’ını taşımasıdır; yani 2. sayfa kendi URL’sine, 3. sayfa kendi URL’sine işaret eder. Google, canonical rehberinde self-referencing canonical eklemeyi öneriyor ama bunun da zorunlu olmadığını ekliyor: hiçbir yöntem belirtilmezse Google kendi seçimini yapar. Sayfalama serisinde fark şu: tüm seriyi 1. sayfaya canonical’lamak Google’a “diğer sayfalar önemsiz” sinyali göndermek anlamına gelir ve 2. sayfadaki ürünler veya içerik indeksten düşebilir; hiç canonical eklenmemesi bu riski taşımaz.
Sunucu yanlış yapılandırması veya kötü niyetli müdahale kanoniği nasıl değiştirir
Google, beklenmedik canonical seçiminin nadir görülen ama gerçek iki nedenini ayrıca adlandırıyor: sunucu yanlış yapılandırması ve web sitesine yönelik kötü niyetli müdahale; ikisi de sektörde neredeyse hiç konuşulmuyor çünkü çoğu sitede hiç yaşanmıyor.
Sunucu yanlış yapılandırması senaryosunda Google şu örneği veriyor: “Bir sunucu, other.example üzerindeki bir URL isteğine yanıt olarak example.com içeriğini döndürecek şekilde yanlış yapılandırılmış olabilir. İki ilgisiz web sunucusu, Google’ın hata sayfası olarak tanımlayamadığı aynı soft 404 sayfalarını döndürebilir.” Bu, DNS/CDN yapılandırması veya çok kiracılı (multi-tenant) barındırma ortamlarında farklı domainlerin yanlışlıkla aynı içeriği sunmasıyla ortaya çıkabilir.
Kötü niyetli müdahale ise bir güvenlik olayıdır: Google, “web sitelerine yönelik bazı saldırıların, HTTP 3xx yönlendirmesi döndüren veya HTML head ya da HTTP header’a genellikle kötü amaçlı ya da spam içerik barındıran bir URL’ye işaret eden cross-domain rel=“canonical” bağlantı ek açıklaması ekleyen kod eklediğini” belirtiyor. Bu durumda canonical etiketi sitenin kendi yapılandırma hatası değil, saldırganın enjekte ettiği koddur; teşhis kaynak kodun beklenmedik biçimde değiştiğini fark etmekten geçer. Üçüncü, daha da nadir durum ise Google’ın algoritmasının bazen izinsiz olarak içeriği barındıran bir dış siteyi kaynak olarak seçebilmesidir. Google bu üç nedeni de “nadir durumlar” olarak çerçeveliyor; çoğu sitede canonical sorunlarının kaynağı CMS/eklenti hatası veya robots.txt/noindex çelişkisidir, sunucu güvenliği değil.
Sendikasyon içeriğinde cross-domain kanonik neden artık önerilmiyor
Google, içeriklerini başka sitelere sendikasyonla dağıtan yayıncılara artık cross-domain canonical etiketi önermiyor; bunun yerine partner sitenin içeriği noindex etmesini öneriyor, çünkü sendike edilen sayfalar genellikle orijinalinden çok farklı görünüyor.
Google’ın resmi ifadesi net: “canonical link öğesi, sendikasyon partnerleri kaynaklı yinelemeden kaçınmak isteyenler için önerilmiyor, çünkü sayfalar genellikle çok farklı oluyor. En etkili çözüm, partnerlerin içeriğinizin dizine eklenmesini engellemesidir.” Bu, önceki sektör pratiğinin tersidir: eskiden sendikasyon partnerlerinin içeriği orijinal kaynağa canonical’lamaları önerilirdi, Google bu tavsiyeyi güncelleyerek noindex’e çevirdi.
Gerekçe canonical’ın ne işe yaradığıyla ilgili: canonical, “bu sayfa ile şu sayfa aynı içerik, birini seç” der; ama sendike edilen bir sayfa genellikle farklı tasarım, farklı navigasyon, farklı ek içerik taşır ve Google’ın gözünde “aynı içerik” sayılmayabilir. Bu durumda canonical etiketi güvenilir bir sinyal üretmez, sadece kafa karıştırır. Noindex ise daha net bir talimattır: partner site “bu sayfayı hiç dizine ekleme” der ve iki tarafın hangi sayfanın aslî kaynak olduğu konusunda kafa karışıklığı biter. Bu ayrımın haber sendikasyonu dışındaki genel içerik sendikasyonuna ne ölçüde uygulandığı Google’ın metninde ayrıca açılmıyor; genel sendikasyon pratiğinde de aynı öneri geçerli sayılır.
URL Parametreleri aracı kapandıktan sonra parametre kaynaklı çoğaltmayı kanonik nasıl yönetir
Search Console’daki URL Parametreleri aracı 26 Nisan 2022’de tamamen kapatıldı; parametre kaynaklı URL çoğaltmasını yönetmek bugün büyük ölçüde canonical etiketinin, URL yapısının ve gerektiğinde robots.txt’in sorumluluğunda.
Google Search Central Blog’un duyurusu, aracın kapatılma gerekçesini şöyle açıklıyor: Google’ın sistemleri hangi URL parametrelerinin faydalı olduğunu kendiliğinden çok daha iyi tahmin edebiliyor ve aracın sunduğu yapılandırmaların yalnızca yaklaşık %1’i tarama için gerçekten kullanışlıydı. Sektörde hâlâ “parametreli URL çoğaltmasını Search Console’daki URL Parametreleri aracından yönetin” tavsiyesi dolaşıyor; bu tavsiye dört yıldır geçersiz, çünkü önerdiği araç ortada yok.
Güncel yöntem üç katmandan oluşur: URL yapısını mümkün olduğunca sabit tutmak (gereksiz izleme veya oturum parametresi eklememek), parametreli varyasyonların tümünde parametresiz kanonik URL’yi rel="canonical" ile işaretlemek ve yalnızca gerçekten farklı içerik üretmeyen parametreler (ör. ?sort= veya ?ref= gibi sıralama/izleme parametreleri) için gerekirse robots.txt ile tarama engeli eklemek. Bu üçü ayrı ayrı çalışan mekanizmalardır; robots.txt ile engellenen bir parametreli URL’yi aynı zamanda canonical hedefi yapmak K-90’daki hatayla aynı çelişkiyi üretir, bu yüzden parametreli URL’ler yalnızca canonical hedefi olmadıklarında robots.txt ile engellenmelidir.
Kanonik etiketin gerçekten yanlış kurulduğu nasıl doğrulanır
Kanonik etiketin gerçekten yanlış kurulduğunu doğrulamanın yolu, kaynak kodu tahmin etmek değil, Search Console’un URL İnceleme aracıyla Google’ın o sayfa için fiilen hangi URL’yi canonical seçtiğini görmektir.
Google’ın “Fix canonicalization issues” rehberi bu adımı doğrudan öneriyor: “Google’ın hangi sayfayı canonical saydığını kontrol etmek için URL İnceleme aracını kullanın.” Search Console’da ilgili URL yapıştırılıp incelendiğinde araç, “Google tarafından seçilen canonical” alanında sitenin beyan ettiği URL ile Google’ın fiilen seçtiği URL’yi ayrı ayrı gösterir; ikisi farklıysa bu, önceki bölümlerdeki on bir hata kalıbından birinin devrede olduğunun somut kanıtıdır.
Düzeltme yapıldıktan sonra bekleme adımı atlanmaz. Google aynı rehberde şunu öneriyor: “kümelenmiş sayfaları yeniden değerlendirmesi için Google’a sormak üzere Search Console URL İnceleme aracındaki ‘Dizine Ekleme İste’ özelliğini kullanın.” Bu istek Google’a “düzeltmeyi yaptım, yeniden tara” sinyali verir; yeniden tarama hemen gerçekleşmeyebilir, ama düzeltmenin etkisini beklemeden fark etmenin tek yolu budur. Self-referencing canonical eklemek bu noktada da önerilir ama zorunlu değildir; hatırlatma gerekirse, hiçbir yöntem belirtilmezse Google kendi objektif seçimini yapmaya devam eder.
URL İnceleme aracı tek bir adresi derinlemesine gösterir, ama sitedeki hangi sayfaların şüpheli olduğunu tek tek bulmak elle saatler alır. Canonical, noindex ve robots.txt çelişkilerini otuz saniyede birlikte tarayan site denetimi aynı SEO-CANONICAL-YOK bulgu koduyla sonucu doğrudan raporlar; araç sitenin tamamını tek seferde tarar, URL İnceleme aracı sonrasında yalnız şüpheli çıkan sayfalar için kullanılır. İkisi birbirinin yerine geçmez: geniş tarama hangi sayfaların şüpheli olduğunu bulur, URL İnceleme aracı Google’ın o sayfa için gerçekte ne yaptığını doğrular.
Her sayfaya kanonik etiketi eklemek zorunlu mu?
Hayır; self-referencing canonical eklemek önerilir ama hiçbir yöntem zorunlu değildir. Google’ın kendi ifadesiyle, canonical belirtilmezse “Google, hangi URL sürümünün objektif olarak en iyi sürüm olduğunu kendisi belirler.” Etiket eklenmemesi tek başına bir hata değildir; asıl risk etiketin hiç olmaması değil, yanlış kurulmuş olmasıdır.
Kanonik etiketi ile 301 yönlendirme aynı işi mi yapar?
Hayır; 301 yönlendirme kullanıcıyı fiziksel olarak yeni adrese taşır, canonical etiketi ise sayfayı olduğu yerde bırakıp yalnızca arama motoruna bir tercih sinyali verir. Google’ın duplike URL rehberi 301’i “yönlendirmenin hedefinin canonical olması gerektiğine dair güçlü bir sinyal” olarak tanımlarken, canonical etiketini de ayrı bir “güçlü sinyal” sayıyor; ikisinin ortak noktası güç, farkı ise sayfanın kaderi. 301 sonrası eski URL kullanıcıya bir daha hiç gösterilmez; canonical sonrası sayfa hâlâ ziyaret edilebilir durumda kalır, yalnızca arama sonuçlarında öne çıkması beklenmez.
canonical · teknik SEO · Search Console · hreflang