Apa yang dilakukan tag canonical ketika Anda salah mengaturnya

Tag canonical bukan penghapus konten duplikat

Tag canonical memberi tahu mesin pencari URL mana yang Anda pilih ketika beberapa URL memuat konten yang sama, atau sangat mirip. Versi HTML yang umum terlihat seperti ini:

<link rel="canonical" href="https://example.com/preferred-page/">

Ada juga versi HTTP header, yang terutama berguna untuk file non-HTML seperti PDF:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Kedengarannya cukup sederhana. Masalah dimulai ketika tim memperlakukan tag canonical sebagai cara aman untuk merapikan apa pun yang terasa berantakan: navigasi berfaset, parameter pelacakan, halaman cetak, halaman produk yang hampir duplikat, paginasi, URL staging, dan halaman kampanye lama.

Tag canonical bukan tombol hapus. Bukan redirect. Bukan pengganti arsitektur informasi. Dan tidak dijamin akan dipatuhi.

Mesin pencari menggunakan canonical sebagai petunjuk kuat. Mereka membandingkan tag canonical dengan sinyal lain: redirect, tautan internal, URL sitemap, anotasi hreflang, kemiripan konten, kode status HTTP, serta URL yang benar-benar ditemui pengguna dan crawler. Jika sinyal-sinyal itu bertentangan, mesin pencari dapat mengabaikan canonical Anda atau memilih URL canonical yang sepenuhnya berbeda.

Itulah mengapa kesalahan canonical bisa sangat membingungkan. Markup terlihat benar di browser, tetapi halaman yang salah muncul di hasil pencarian — atau halaman yang benar menghilang.

Apa yang terjadi ketika canonical mengarah ke URL yang salah

Ketika mesin pencari melihat URL duplikat atau hampir duplikat, biasanya mereka mengelompokkannya ke dalam satu cluster dan memilih satu URL sebagai canonical. Canonical yang dipilih adalah versi yang paling mungkin diindeks dan ditampilkan di hasil pencarian. Sinyal dari duplikatnya dapat dikonsolidasikan ke URL yang dipilih tersebut.

Jika tag canonical Anda mengarah ke halaman yang salah, beberapa hal dapat terjadi.

1. URL yang salah diindeks

Misalkan Anda memiliki dua URL:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Jika halaman sale menggunakan canonical ke halaman kategori utama, itu mungkin baik-baik saja jika kontennya hampir identik dan URL sale hanya versi terfilter. Namun jika halaman sale memiliki copy unik, produk unik, dan permintaan pencarian tersendiri, canonical dapat menekannya.

Halaman itu mungkin tetap di-crawl. Mungkin tetap dapat diakses pengguna. Namun mesin pencari dapat memutuskan untuk tidak mengindeksnya secara terpisah karena Anda memberi tahu mereka bahwa URL lain adalah versi yang dipilih.

Ini adalah kegagalan canonical yang paling umum: bukan gangguan teknis besar, hanya hilangnya halaman dari indeks secara senyap.

2. Sinyal peringkat terkonsolidasi ke tempat yang salah

Canonical sering digunakan untuk mengonsolidasikan sinyal seperti tautan dan varian konten duplikat. Itu berguna ketika duplikatnya benar-benar setara. Ini berisiko ketika tidak demikian.

Jika sebuah artikel blog memiliki URL pelacakan seperti:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

Maka menetapkan canonical keduanya ke /guide-to-canonical-tags/ adalah langkah yang masuk akal.

Namun jika versi bahasa Spanyol, versi cetak dengan konten tambahan, atau varian produk dengan intent berbeda mengarah ke canonical yang sama, Anda mungkin menggabungkan sinyal yang seharusnya tetap terpisah. Hasilnya bisa berupa relevansi yang lebih lemah untuk semuanya.

Tag canonical berkaitan dengan kesetaraan. Jika dua halaman memenuhi intent pencarian yang berbeda, kemungkinan besar keduanya tidak boleh saling dicanonicalkan.

3. Mesin pencari mengabaikan tag tersebut

Canonical bukan perintah. Jika target canonical melakukan redirect, mengembalikan 404, diblokir, memiliki noindex, atau memuat konten yang sangat berbeda, mesin pencari dapat mengabaikannya.

Dalam satu sisi, itu baik: canonical yang buruk tidak selalu menghancurkan pengindeksan. Namun itu juga berarti Anda tidak bisa berasumsi bahwa tag tersebut bekerja seperti yang Anda kira. Sebuah halaman dapat mendeklarasikan satu canonical sementara Google memilih yang lain.

Ini sangat umum ketika tautan internal, sitemap, dan canonical tidak sejalan. Jika setiap tautan internal mengarah ke /product, sitemap Anda mencantumkan /product/, dan canonical Anda mengarah ke https://www.example.com/product?ref=main, Anda telah menciptakan perdebatan kecil di antara sinyal Anda sendiri.

Mesin pencari cukup baik dalam menyelesaikan perdebatan itu. Mereka tidak selalu menyelesaikannya dengan cara yang Anda maksudkan.

4. Debugging menjadi sulit tanpa perlu

Canonical yang buruk jarang gagal secara terang-terangan. Mereka menghasilkan gejala yang terlihat seperti masalah SEO lain:

• “Discovered, currently not indexed” atau limbo pengindeksan yang setara
• URL yang salah merangking untuk sebuah kueri
• URL parameter muncul dalam laporan
• Halaman kategori tidak muncul meski dapat di-crawl
• Halaman internasional tergabung ke versi bahasa yang salah
• Template baru diluncurkan dengan jumlah halaman terindeks lebih sedikit dari perkiraan

Itulah mengapa debugging canonical harus mencakup HTML mentah, HTML yang dirender, HTTP header, redirect, dan entri sitemap. Jika Anda sudah menyelidiki rantai redirect atau header yang tidak cocok, kebiasaan yang sama berlaku; alur kerja inspeksi HTTP praktis seperti yang ada di panduan kami untuk debugging redirect dan HTTP header di production biasanya akan menangkap kontradiksi canonical lebih cepat daripada menatap field CMS.

Kesalahan canonical yang paling mahal

Menetapkan canonical semuanya ke halaman beranda

Ini masih terjadi. Sebuah field template dibiarkan kosong, plugin kembali ke root situs sebagai fallback, dan tiba-tiba ratusan halaman mendeklarasikan halaman beranda sebagai canonical.

Mesin pencari dapat mengabaikan ini karena kontennya jelas berbeda. Namun jika cukup banyak sinyal yang berantakan, beberapa halaman dapat dihapus atau dikelompokkan secara keliru. Setidaknya, Anda mengirimkan petunjuk yang tidak berguna dan bertentangan di setiap halaman.

Halaman beranda hampir tidak pernah menjadi canonical untuk halaman internal.

Menetapkan canonical halaman paginasi ke halaman pertama

Untuk waktu yang lama, beberapa situs menetapkan canonical /category/page/2/, /page/3/, dan seterusnya kembali ke halaman pertama. Niatnya adalah menghindari halaman kategori duplikat.

Masalahnya, halaman paginasi bukan duplikat. Halaman-halaman itu memuat item berbeda dan membantu crawler menemukan konten yang lebih dalam. Menetapkan semuanya ke halaman pertama sebagai canonical dapat mengurangi peluang mesin pencari memproses halaman-halaman berikutnya secara penuh.

Biasanya, halaman paginasi sebaiknya memiliki canonical yang merujuk ke dirinya sendiri kecuali ada alasan khusus untuk mengonsolidasikannya.

Menetapkan canonical halaman terfilter tanpa memeriksa intent pencarian

Navigasi berfaset menciptakan pilihan yang sulit. Beberapa URL terfilter adalah sampah:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Yang lain mungkin merupakan landing page bernilai:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Aturan canonical menyeluruh sering menghapus halaman pencarian yang berguna bersama dengan kebisingan parameter yang tidak berguna. Sebelum menetapkan canonical halaman terfilter, tanyakan apakah halaman terfilter tersebut memiliki konten stabil, tautan internal, permintaan pencarian, dan kebutuhan pengguna yang berbeda.

Jika jawabannya ya, halaman itu mungkin layak untuk dapat diindeks dengan canonical yang merujuk ke dirinya sendiri.

Mengarahkan canonical ke URL yang diredirect atau diblokir

Target canonical harus bersih, dapat diindeks, dan mengembalikan 200 OK. Jangan arahkan canonical ke URL yang melakukan redirect, mengembalikan error, membutuhkan cookies, diblokir oleh robots.txt, atau membawa noindex.

Ini salah satu pemeriksaan termudah untuk diotomatisasi. Crawl situs Anda dan tandai target canonical yang tidak mengembalikan respons 200 yang bersih.

Mencampur canonical dengan noindex seolah-olah maknanya sama

rel="canonical" dan noindex menyelesaikan masalah yang berbeda.

Gunakan canonical ketika duplikat ada dan Anda ingin sinyal dikonsolidasikan ke URL pilihan. Gunakan noindex ketika Anda sama sekali tidak ingin sebuah halaman diindeks.

Menggunakan keduanya bersama-sama mengirim pesan yang canggung: “Jangan indeks halaman ini, tetapi juga gunakan halaman ini sebagai sinyal duplikat untuk halaman lain.” Mesin pencari sering dapat mengatasinya, tetapi itu bukan instruksi yang bersih. Jika sebuah halaman adalah duplikat, tetapkan canonical untuknya. Jika halaman itu tidak seharusnya muncul di pencarian dan tidak memiliki hubungan duplikat yang berguna, pertimbangkan noindex.

Audit canonical yang praktis

Anda tidak memerlukan platform SEO besar untuk menemukan banyak masalah canonical. Mulailah dengan crawl, beberapa sampel URL, dan spreadsheet.

Untuk setiap template penting, periksa:

1. Apakah halaman memiliki tepat satu tag canonical? Beberapa tag canonical menciptakan ambiguitas.
2. Apakah canonical bersifat absolut? Gunakan URL lengkap, termasuk protokol dan hostname.
3. Apakah target canonical mengembalikan 200 OK? Hindari target yang diredirect, diblokir, atau error.
4. Apakah target canonical dapat diindeks? Tidak ada noindex, tidak ada blok robots, tidak ada persyaratan autentikasi.
5. Apakah kontennya benar-benar setara? Mirip tidak selalu berarti setara.
6. Apakah tautan internal sejalan? Tautkan ke format URL canonical bila memungkinkan.
7. Apakah sitemap sejalan? Sitemap umumnya sebaiknya mencantumkan URL canonical yang dapat diindeks.
8. Apakah tag hreflang sejalan? Halaman internasional membutuhkan hubungan canonical dan hreflang yang konsisten.
9. Apakah HTML yang dirender cocok dengan HTML mentah? JavaScript dapat mengubah atau menyisipkan tag.
10. Canonical mana yang dipilih mesin pencari? Alat inspeksi dapat mengungkap ketika canonical yang Anda deklarasikan berbeda dari canonical yang dipilih.

Di sinilah Lighthouse juga bisa membantu, tetapi hanya dalam batasannya. Ia dapat menandai beberapa masalah crawlability dan dokumen, tetapi tidak memahami intent komersial atau strategi canonical Anda. Perlakukan sebagai salah satu masukan, bukan putusan. Jika Anda membutuhkan cara yang lebih tenang untuk memisahkan temuan berguna dari noise, lihat cara membaca laporan Lighthouse tanpa panik.

Canonical yang merujuk ke dirinya sendiri biasanya default yang baik

Setiap halaman penting yang dapat diindeks biasanya sebaiknya mendeklarasikan dirinya sendiri sebagai canonical. Ini bukan karena mesin pencari tidak dapat mengetahuinya tanpa tag tersebut. Ini karena canonical yang merujuk ke dirinya sendiri mengurangi ambiguitas ketika parameter, tautan pelacakan, URL yang disalin, dan keanehan CMS menciptakan jalur alternatif ke konten yang sama.

Untuk halaman produk yang bersih, ini biasanya benar:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Untuk URL pelacakan, canonical biasanya sebaiknya kembali ke versi bersih:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Untuk varian produk yang benar-benar berbeda, jawabannya tergantung. Jika kemeja merah, kemeja biru, dan kemeja hitam memiliki deskripsi yang sama dan hanya warnanya yang berubah, satu halaman produk canonical mungkin cukup. Jika setiap varian memiliki permintaan, ulasan, gambar, stok, dan tautan internal yang terpisah, halaman terindeks yang terpisah mungkin masuk akal.

Tidak ada aturan canonical universal untuk varian. Yang ada hanya pertanyaan: apakah halaman-halaman ini dapat saling menggantikan bagi pencari?

Tag canonical harus sesuai dengan kebijakan URL aktual situs Anda

Sebagian besar bug canonical adalah gejala dari masalah kebijakan URL yang lebih dalam. Situs belum memutuskan apakah trailing slash penting, apakah URL huruf besar harus resolve, apakah parameter diizinkan, apakah HTTP redirect ke HTTPS, atau apakah www adalah canonical.

Pilih satu versi bersih dari setiap URL dan buat seluruh sistem sejalan:

• Redirect versi URL yang tidak dipilih ke versi pilihan.
• Tautkan secara internal ke versi pilihan.
• Masukkan versi pilihan ke XML sitemap.
• Gunakan canonical yang merujuk ke dirinya sendiri pada halaman pilihan.
• Tetapkan canonical hanya untuk duplikat sejati ke URL pilihan.

Ketika semua sinyal ini mengarah ke arah yang sama, tag canonical menjadi membosankan. Itulah tujuannya.

Intinya

Tag canonical kuat karena memengaruhi pengindeksan dan konsolidasi sinyal. Tag tersebut berbahaya karena alasan yang sama.

Canonical yang salah tidak selalu akan menghapus halaman dari pencarian. Mesin pencari dapat mengabaikannya. Namun mengandalkan mesin pencari untuk menyelamatkan sinyal yang buruk bukanlah strategi. Pendekatan yang lebih aman adalah membatasi canonicalization hanya untuk duplikat sejati, menjaga target tetap bersih dan dapat diindeks, serta membuat tautan internal, redirect, sitemap, dan canonical Anda menceritakan kisah yang sama.

Canonical bukan tempat untuk menyembunyikan arsitektur yang berantakan. Canonical adalah tempat Anda mengonfirmasi bahwa arsitektur itu telah dirapikan.