Ada satu percakapan yang saya alami berkali-kali dalam delapan tahun terakhir, dan isinya selalu mirip. Klien mengirim tangkapan layar kode sumber halamannya, menunjuk satu baris elemen link rel canonical yang terpasang rapi di bagian head, lalu bertanya kenapa Google tetap menampilkan URL yang lain. Tag-nya benar. Ejaannya benar. URL-nya absolut, huruf kecil, HTTPS, persis seperti yang disarankan semua tutorial. Dan Google tetap tidak menurut.
Kalau Anda pernah di posisi itu, kabar baiknya: tidak ada yang rusak. Yang salah adalah asumsi di baliknya. Hampir semua artikel Indonesia tentang canonical tag menjelaskannya seperti tombol, pasang lalu selesai. Dokumentasi Google sendiri menjelaskannya sebagai petunjuk, dan Google bahkan menyediakan satu halaman dokumentasi khusus tentang apa yang harus Anda lakukan ketika petunjuk Anda ditolak. Dua cara pandang itu menghasilkan dua jenis pekerjaan yang sama sekali berbeda.
Di artikel ini saya tidak akan mengulang cara memasang tag-nya, karena bagian itu memang sudah banyak dan memang mudah. Saya akan membahas hal yang jauh lebih menentukan: lima tempat di website Anda yang diam-diam ikut memberi suara soal URL mana yang utama, kenapa Google berhak mengabaikan suara Anda, apa yang Google sebut sebagai perbaikan sebenarnya (bukan tag-nya), dan satu saran keliru yang pernah saya tulis sendiri di blog ini serta perlu saya perbaiki di depan Anda.
Tag-nya Sudah Terpasang Benar, dan Google Tetap Memilih URL Lain
Awal tahun ini saya menangani sebuah situs layanan dengan sekitar 40 halaman kota. Struktur kontennya klasik: satu layanan, satu template, nama kota berganti. Halaman induk layanan sudah punya canonical ke dirinya sendiri, semua halaman kota juga. Semua rapi.
Laporan Pengindeksan Halaman di Search Console berkata lain. Dua puluh sembilan dari 40 halaman kota masuk kategori duplikat dengan kanonis pilihan Google yang berbeda dari pilihan pengguna. Google membaca tag-nya, memahaminya, lalu memutuskan bahwa halaman induk layanan lebih pantas.
Yang menarik bukan angkanya. Yang menarik adalah reaksi standar di lapangan. Tim internal mereka sudah tiga kali “memperbaiki” tag itu: mengganti relatif jadi absolut, memastikan HTTPS, menambahkan halaman kota ke sitemap, menekan Request Indexing untuk seluruh 29 URL. Semua benar secara teknis. Semua tidak berpengaruh.
Sebab masalahnya bukan di tag. Empat puluh halaman itu memang hampir identik. Google mengelompokkannya, dan pengelompokan itulah yang harus dibongkar, bukan deklarasinya.
Canonical Tag Adalah Apa, dan Bedanya dengan Redirect 301
Canonical tag adalah elemen link dengan atribut rel canonical yang dipasang di bagian head sebuah halaman HTML, berisi URL yang Anda anggap sebagai versi utama dari konten itu. Fungsinya memberi tahu mesin pencari: kalau kamu menemukan beberapa URL dengan isi yang mirip, tolong perlakukan URL ini sebagai versi yang diindeks dan ditampilkan.
Tiga hal yang perlu langsung diluruskan, dan ketiganya berasal dari dokumentasi Google sendiri:
Ini petunjuk, bukan aturan. Dokumentasi kanonikalisasi Google menyebut rel canonical sebagai sinyal kuat, bukan perintah. Google bisa memilih URL berbeda dari yang Anda deklarasikan, dan alasannya bisa apa saja, dari kualitas konten sampai sinyal teknis lain di situs Anda.
Ini tidak wajib. Kalimat Google persis begini: meski mereka menganjurkan pemakaiannya, tidak satu pun metode kanonikalisasi bersifat wajib, dan situs Anda kemungkinan besar tetap berjalan baik tanpa menyatakan preferensi kanonis. Kalau Anda tidak menyatakan apa pun, Google akan memilih sendiri versi yang paling lengkap dan paling berguna bagi pengguna. Banyak situs kecil sebetulnya tidak punya masalah di sini sama sekali.
Ini bukan redirect. Perbedaannya sederhana kalau dilihat dari sisi pengunjung. Dengan canonical, kedua URL tetap bisa dibuka manusia; hanya mesin pencari yang diberi tahu mana yang utama. Dengan redirect 301, URL lama tidak bisa dibuka lagi, pengunjung dipaksa pindah. Dari situ aturan pemilihannya jatuh sendiri, dan dokumentasi Google menyebutnya lugas: gunakan redirect ketika Anda ingin menyingkirkan halaman duplikatnya, gunakan rel canonical ketika kedua halaman memang harus tetap hidup.
Contoh paling umum untuk masing-masing. Halaman produk yang bisa diakses lewat jalur kategori dan lewat jalur promo, keduanya sah dan keduanya harus tetap terbuka: itu wilayah canonical. Halaman lama yang sudah Anda gabungkan ke artikel baru dan tidak perlu ada lagi: itu wilayah redirect. Mekanisme redirect-nya sendiri, termasuk beda 301 dan 302 serta rantai redirect, punya jebakan tersendiri yang layak dibahas terpisah, jadi di sini saya berhenti di aturan pemilihannya saja.
Satu catatan yang sering dicampur: canonical bukan obat untuk kanibalisasi keyword. Kalau dua halaman Anda bersaing di kueri yang sama tetapi isinya memang berbeda dan keduanya punya alasan untuk ada, mengkanonikalkan salah satunya berarti membuang satu halaman, bukan menyelesaikan persaingannya. Itu masalah pemetaan topik, bukan masalah sinyal.
Lima Tempat Website Anda Menyatakan Pilihan, dan Bobotnya Tidak Sama
Di sini letak akar masalah yang hampir tidak pernah dibahas di artikel berbahasa Indonesia. Anda mengira menyatakan preferensi kanonis di satu tempat. Website Anda sebenarnya menyatakannya di lima tempat sekaligus, sering dengan jawaban yang berbeda-beda.
Dokumentasi Google menyusun tiga metode eksplisit beserta kekuatannya, lalu menambahkan dua sinyal lain yang berasal dari cara situs disetel.
Tiga metode yang Anda pilih secara sadar
Redirect permanen: sinyal kuat. Redirect 301 atau 308 dibaca sebagai sinyal bahwa tujuan redirect itulah yang seharusnya menjadi kanonis. Penting: redirect sementara, yaitu 302, 303, dan 307, secara eksplisit tidak dipakai untuk kanonikalisasi. Ini jebakan yang mahal. Perpindahan yang niatnya permanen tetapi dipasang sebagai 302 (biasanya karena default plugin atau karena “sementara dulu” lalu lupa) berarti halaman tujuan tidak pernah menerima sinyal itu sama sekali.
Elemen link rel canonical: sinyal kuat. Ini yang semua orang bahas. Syaratnya lebih ketat dari yang dikira: hanya diterima kalau muncul di bagian head, jadi head Anda harus HTML yang valid. URL-nya sebaiknya absolut, bukan relatif. Dan Google punya versi HTTP header dari sinyal yang sama, yang berguna untuk file non-HTML seperti PDF karena file itu tidak punya bagian head untuk dititipi tag.
Pencantuman di sitemap: sinyal lemah. Google menyebutnya lemah dengan satu kalimat penjelas yang jarang dikutip: untuk kanonis apa pun yang Anda deklarasikan lewat sitemap, Google masih harus menentukan sendiri duplikat mana yang berpasangan dengannya. Sitemap menguatkan sinyal lain, ia tidak menggantikannya.
Dua sinyal yang muncul dari cara situs disetel
Preferensi HTTPS. Google memilih HTTPS di atas HTTP versi setara. Tapi ada empat pengecualian yang didokumentasikan: sertifikat SSL tidak valid, halaman HTTPS memuat dependensi tidak aman selain gambar, halaman HTTPS mengarahkan pengunjung ke atau melewati halaman HTTP, dan halaman HTTPS memasang rel canonical ke versi HTTP-nya. Bagian yang paling perlu diingat: sertifikat bermasalah dan redirect dari HTTPS ke HTTP membuat Google memilih HTTP dengan sangat kuat, dan menurut dokumentasi Google, memasang HSTS tidak bisa membatalkan preferensi kuat itu.
Klaster hreflang. Google lebih memilih URL yang menjadi bagian dari klaster hreflang. Kalau versi de-de dan de-ch saling menunjuk lewat anotasi hreflang tetapi versi de-at tidak ikut, dua yang pertama lebih disukai sebagai kanonis. Konsekuensinya untuk situs berbahasa ganda cukup besar, dan itu topik tersendiri.
Ada satu sinyal keenam yang tidak masuk daftar formal tetapi Google sebutkan sebagai praktik terbaik: tautan internal Anda sendiri. Kalimatnya jelas, ketika menaut di dalam situs, tautlah ke URL kanonis, bukan ke URL duplikat, karena menaut secara konsisten ke URL yang Anda anggap kanonis membantu Google memahami preferensi Anda. Artinya menu, breadcrumb, dan tautan di dalam artikel Anda ikut memberi suara. Diam-diam, ribuan kali.
Kata Google Sendiri, Perbaikannya Bukan di Tag
Ini temuan yang paling mengubah cara saya bekerja, dan saya belum menemukan satu pun artikel Indonesia yang membahasnya.
Halaman dokumentasi Google berjudul Fix canonicalization issues, yang terakhir diperbarui 21 Agustus 2026, menutup langkah ketiganya dengan kalimat ini: memperbaiki masalah kanonikalisasi secara teknis pada dasarnya berarti memastikan halaman-halaman yang dikelompokkan bersama cukup berbeda satu sama lain.
Baca ulang. Perbaikannya bukan memasang tag lebih benar. Perbaikannya adalah membuat halamannya benar-benar berbeda, atau menerima bahwa keduanya memang layak digabung.
Dua catatan operasional yang menyertainya, juga dari dokumen yang sama. Pertama, evaluasi ulang butuh waktu: bahkan setelah masalah konten diperbaiki, Google bisa menahan halaman di dalam satu klaster duplikat sampai dua minggu. Kedua, halaman akan terpisah lebih cepat kalau perbedaan antara konten baru dan halaman lain di klaster itu jelas dan signifikan. Bukan “sudah saya tambah 200 kata”. Jelas dan signifikan.
Kalau digabung dengan pernyataan John Mueller pada 29 Juli 2026, gambarannya jadi lengkap. Ditanya soal sinyal yang bertentangan, dengan contoh persis redirect 301 dari URL A ke URL B sementara URL B memasang canonical kembali ke A, Mueller menjawab bahwa tidak ada urutan prioritas yang dipublikasikan untuk rekonsiliasi metadata. Alasannya, semua sinyal itu punya bobot dan filter yang berbeda, dan bobotnya berubah dari waktu ke waktu. Saran praktisnya satu kalimat: kalau Anda memberi metadata yang bertentangan, perbaiki, jangan menganalisis apakah tetap akan berhasil.
Jadi tidak ada tabel “siapa menang”. Yang ada hanya satu strategi yang tidak bisa salah: bikin semua sinyal Anda mengatakan hal yang sama.
Termasuk Saran Saya Sendiri yang Perlu Saya Perbaiki
Sekarang bagian yang tidak nyaman.
September 2025 saya menerbitkan panduan mengatasi konten duplikat, dari deteksi lewat laporan Pengindeksan Halaman sampai konsolidasi otoritas dengan canonical dan redirect. Langkah terakhir di artikel itu membahas sindikasi konten, dan saya menulis bahwa Anda harus selalu meminta situs mitra memasang tag kanonikal yang menunjuk kembali ke URL asli Anda.
Itu saran yang beredar luas, saya juga mendengarnya dari praktisi lain, dan untuk kasus sindikasi Google justru tidak menganjurkannya. Kalimat Google di halaman troubleshooting kanonikalisasi: elemen link canonical tidak direkomendasikan bagi mereka yang ingin menghindari duplikasi oleh mitra sindikasi, karena halamannya sering kali sangat berbeda. Solusi paling efektif menurut Google adalah mitra memblokir pengindeksan konten Anda.
Logikanya konsisten dengan temuan di atas. Canonical bekerja pada halaman yang cukup mirip untuk dikelompokkan. Halaman mitra sindikasi biasanya punya template, navigasi, dan konteks yang berbeda jauh, sehingga tidak masuk klaster yang sama, sehingga tag itu tidak punya apa pun untuk dikonsolidasikan. Saya menyarankan alat yang benar untuk masalah yang salah.
Artikel lama itu belum saya ubah saat tulisan ini terbit, dan saya sengaja menyebutnya di sini alih-alih menyuntingnya diam-diam. Kalau Anda pernah membacanya dan mengikuti saran sindikasi itu, bagian inilah yang perlu Anda ganti: minta mitra memasang noindex, bukan canonical.
Audit 5 Suara: Cara Membuat Semua Sinyal Anda Mengatakan Hal yang Sama
Karena tidak ada urutan prioritas yang dipublikasikan, satu-satunya posisi yang aman adalah suara bulat. Ini urutan pemeriksaan yang saya pakai, dan sengaja dimulai dari yang paling sering salah, bukan dari yang paling teknis.
Suara nol: tanya dulu siapa yang Google pilih
Sebelum memperbaiki apa pun, cari tahu Anda sedang berselisih dengan siapa. Buka URL Inspection di Search Console untuk URL yang bermasalah, dan bandingkan dua baris yang ditampilkan berdampingan: kanonis yang dinyatakan pengguna, dan kanonis yang dipilih Google. Selama keduanya berbeda, sistem Google masih menolak preferensi Anda dan tidak ada gunanya menekan tombol apa pun.
Lalu pertanyaan yang lebih penting, dan ini pertanyaan bisnis bukan pertanyaan teknis: apakah pilihan Google lebih masuk akal daripada pilihan Anda? Dokumentasi Google secara eksplisit menyuruh Anda memikirkan itu. Cukup sering, jawabannya iya, dan pekerjaan Anda selesai di langkah nol.
Suara satu: elemen canonical yang benar-benar dikirim server
Jangan percaya pengaturan plugin, lihat kode sumber yang benar-benar keluar. Yang saya cari: apakah ada lebih dari satu elemen canonical (dua plugin SEO aktif bersamaan menghasilkan dua tag, dan tag yang saling bertentangan akan diabaikan, artinya Anda kembali ke pilihan Google), apakah URL-nya absolut, apakah ia berada di dalam head, dan apakah ada isian canonical manual yang tertinggal dari masa lalu. Yang terakhir ini penyebab paling licik di WordPress: kolom Canonical URL di panel lanjutan Yoast menimpa semua logika otomatis, jadi satu URL yang salah tempel di sana akan mengalahkan setiap perbaikan lain yang Anda lakukan.
Kalau tag-nya lahir dari template atau plugin, perbaikannya juga harus di situ. Dokumentasi Google bahkan menyuruh Anda melaporkan ke penyedia CMS kalau plugin memakai teknik kanonikalisasi secara keliru. Di titik ini pekerjaannya sudah pindah dari SEO ke lapisan pembangunan situs, dan kalau template Anda memang tidak bisa diarahkan tanpa membongkar tema, itu memang pekerjaan web development dan bukan pekerjaan yang bisa ditambal dari dasbor.
Suara dua: redirect yang sedang hidup
Petakan redirect di jalur URL yang bersangkutan. Dua hal yang dicari: apakah ada redirect yang arahnya berlawanan dengan tag Anda (URL A dialihkan ke B, tetapi B memasang canonical ke A, kasus persis yang ditanyakan ke Mueller), dan apakah ada redirect yang niatnya permanen tetapi statusnya masih 302. Yang pertama harus dibongkar salah satunya. Yang kedua naikkan ke 301.
Suara tiga: sitemap
Sitemap Anda harus berisi satu URL per konten, dan URL itu harus URL yang sama dengan yang dinyatakan tag-nya. Dokumentasi sitemap Google tegas: kalau konten yang sama bisa diakses lewat beberapa URL, pilih satu yang Anda inginkan dan cantumkan itu saja. Konflik jenis ini paling sering muncul tanpa disadari, karena generator sitemap dan generator tag adalah dua bagian sistem yang berbeda dan diperbarui pada waktu yang berbeda.
Suara empat: protokol dan tautan internal
Pastikan tidak ada sisa jalur HTTP yang bisa dijangkau, dan tidak ada halaman HTTPS yang mengarahkan pengunjung melewati HTTP. Lalu periksa tautan internal Anda: menu, breadcrumb, tautan di dalam artikel. Kalau navigasi Anda menaut ke versi tanpa www sementara canonical Anda menyatakan versi dengan www, Anda memberi dua jawaban berbeda ribuan kali sehari.
Suara lima: pastikan halamannya memang berbeda
Ini langkah yang paling sering dilewati dan paling menentukan. Kalau setelah empat suara di atas Google masih memilih URL lain, masalahnya sudah bukan sinyal, melainkan kemiripan. Pilihannya jujur cuma dua: bikin halaman itu benar-benar berbeda dengan cara yang jelas dan signifikan, atau terima penggabungannya dan alihkan yang kalah. Lalu beri waktu sampai dua minggu sebelum menilai hasilnya.
Enam Keputusan Setelah Panik yang Justru Mengunci Masalahnya
Hampir semua kerugian dari urusan canonical bukan datang dari tidak tahu, tapi dari bertindak cepat setelah melihat laporan yang menakutkan. Enam ini saya lihat berulang.
Memblokir URL duplikat di robots.txt supaya canonical “lebih didengar”. Dokumentasi Google menyebut ini secara khusus sebagai hal yang jangan dilakukan untuk keperluan kanonikalisasi, karena Google masih bisa mengindeks URL yang diblokir tanpa isinya. Efeknya malah kebalikan: Googlebot tidak bisa lagi membaca tag canonical yang Anda pasang di halaman itu, jadi sinyal Anda hilang sementara URL-nya tetap bisa muncul. Mekanismenya sama dengan jebakan noindex plus Disallow, dan saya sudah membedahnya di panduan setting robots.txt yang menjelaskan kenapa Disallow hanya menghentikan perayapan dan bukan pengindeksan.
Memakai alat penghapusan URL untuk mengatur kanonis. Google melarangnya dengan alasan yang mudah dilupakan: alat itu menyembunyikan semua versi URL dari Penelusuran, bukan hanya yang duplikat. Anda bermaksud menghapus satu, yang hilang dua.
Menambahkan noindex ke halaman duplikat sebagai jalan pintas. Dokumentasi Google tidak menyarankan noindex untuk mencegah pemilihan kanonis di dalam satu situs, karena itu memblokir halaman sepenuhnya dari Penelusuran, dan rel canonical adalah solusi yang lebih disukai. Kapan noindex justru pilihan yang tepat dan kapan canonical yang tepat sudah saya urai di perbandingan noindex dan disallow beserta skenario pemakaian masing-masing, jadi di sini cukup satu aturan: kalau Anda ingin sinyalnya digabung, jangan pakai noindex.
Menyatakan URL berbeda lewat dua teknik berbeda. Sitemap bilang X, tag bilang Y. Google menyebut ini larangan eksplisit, dan hasilnya bukan kompromi, melainkan Google memutuskan sendiri.
Mengkanonikalkan seluruh halaman paginasi ke halaman pertama. Halaman kedua daftar artikel Anda bukan duplikat halaman pertama, isinya beda. Menunjuknya ke halaman satu berpotensi membuat semua isi di halaman dua ke atas hilang dari perhitungan. Kanonis yang menunjuk ke diri sendiri lebih aman.
Menekan Request Indexing untuk seluruh daftar URL. Fiturnya berkuota, dan dokumentasi Google menyuruh menyimpannya untuk URL yang paling penting. Kalau penyebabnya kemiripan konten, mengajukan ulang URL yang isinya tidak berubah tidak menambah apa pun selain kesibukan.
Satu pola yang menyatukan keenamnya: semuanya adalah upaya menekan Google lebih keras, padahal Google sudah membaca sinyal Anda dan sudah memutuskan. Yang perlu diubah adalah alasan keputusannya, bukan volume suaranya.
Empat Hal tentang Canonical yang Hampir Tidak Pernah Ditulis
Canonical tag adalah permukaan serangan
Ini yang paling jarang disadari. Dalam daftar penyebab umum masalah kanonikalisasi, Google mencantumkan peretasan: sebagian serangan menyisipkan redirect 3xx atau menyisipkan anotasi rel canonical lintas domain ke dalam head HTML atau HTTP header, biasanya menunjuk ke URL berisi konten jahat atau spam. Dan menurut Google, dalam kasus seperti itu algoritma mereka bisa memilih URL jahat atau spam itu, bukan URL di situs yang diretas.
Artinya satu baris canonical bisa memindahkan identitas halaman Anda ke domain orang lain, dan gejalanya di Search Console akan terlihat seperti masalah teknis biasa. Kalau situs Anda pernah kena insiden keamanan, memeriksa canonical yang benar-benar dikirim server adalah salah satu pemeriksaan pertama, bukan yang terakhir.
Kalau kanonis pilihan Google ada di properti orang lain, data Anda hilang
Masih dari dokumen yang sama, ada satu kotak “Important” yang layak dibaca dua kali: kalau URL kanonis berada di properti Search Console yang tidak Anda miliki, Anda tidak akan bisa melihat trafik apa pun untuk halaman duplikat Anda.
Ini bukan sekadar kehilangan peringkat. Ini kehilangan kemampuan mengukur. Situs penjiplak yang kontennya identik, atau server yang salah konfigurasi sehingga dua domain menyajikan isi yang sama, bisa berakhir dengan Google memilih URL di luar kendali Anda dan laporan Anda menjadi buta di bagian itu. Google menyebut jalur pemulihannya: menghubungi penyedia hosting situs itu, dan kalau ada pelanggaran hak cipta, mengajukan permintaan penghapusan.
Beberapa canonical diabaikan tanpa pemberitahuan
Dokumentasi Google menyebut satu hal yang sangat spesifik: anotasi rel canonical yang menyarankan versi alternatif sebuah halaman diabaikan. Konkretnya, anotasi rel canonical yang membawa atribut hreflang, lang, media, atau type tidak dipakai untuk kanonikalisasi. Untuk versi alternatif, yang benar adalah rel alternate dengan hreflang.
Dua hal lain di kategori “diabaikan tanpa kabar”: kanonis yang menunjuk ke fragmen URL, karena Google umumnya tidak mendukung fragmen, dan kanonis relatif, yang secara teknis didukung tetapi tidak dianjurkan karena mudah berubah arti di lingkungan lain seperti situs uji coba yang tidak sengaja terayapi.
Aturan JavaScript yang berlawanan dengan intuisi
Kalau situs Anda merender di sisi klien, dokumentasi Google memberi urutan yang jelas: cara terbaik adalah menuliskan URL kanonis di kode sumber HTML dan memastikan JavaScript tidak mengubahnya. Bagian yang mengejutkan ada di kalimat berikutnya. Kalau Anda tidak bisa menuliskannya di kode sumber, tinggalkan saja kosong dan atur hanya lewat JavaScript.
Jadi pilihannya bukan “pasang di dua tempat supaya aman”. Justru itu yang harus dihindari, karena dua sumber berarti dua kemungkinan jawaban. Logika yang sama dipakai Google untuk elemen HTML versus HTTP header: keduanya didukung, memakai keduanya sekaligus lebih rawan salah, jadi pilih satu.
Satu Pemeriksaan yang Bisa Anda Lakukan Lima Menit dari Sekarang
Kalau seluruh artikel ini harus dipadatkan jadi satu kalimat: canonical tag bukan tombol yang Anda tekan, ia satu suara di antara beberapa, dan Google berhak menghitung ulang.
Langkah pertama yang paling kecil dan paling berguna: ambil satu URL penting di situs Anda, halaman layanan utama atau halaman produk paling laku. Buka URL Inspection di Search Console. Bandingkan kanonis yang Anda nyatakan dengan kanonis yang Google pilih. Kalau sama, Anda tidak punya masalah di halaman itu dan bisa berhenti. Kalau berbeda, Anda baru saja menemukan pekerjaan yang paling murah dan paling berdampak untuk minggu ini, dan Anda sudah tahu urutan pemeriksaannya.
Satu peringatan penutup. Label kategori di laporan Pengindeksan Halaman kadang diganti nama oleh Google, jadi jangan menghafal kalimatnya. Hafalkan kategorinya: Google menerima preferensi Anda dan menolaknya. Itu yang perlu Anda kejar, apa pun bunyi labelnya nanti.
Kalau setelah pemeriksaan itu Anda menemukan bukan satu halaman melainkan puluhan yang bermasalah, biasanya penyebabnya satu dan ada di lapisan template. Untuk kasus semacam itu saya membuka jasa SEO dengan audit yang membaca kanonis pilihan Google di seluruh situs, bukan hanya tag yang Anda pasang. Dan supaya jujur sejak awal: cukup sering hasil audit seperti ini berakhir dengan rekomendasi menggabungkan halaman, bukan memperbaiki tag. Itu keputusan yang tidak nyaman, tapi lebih murah daripada tiga bulan menekan Request Indexing.
Pertanyaan yang Sering Muncul soal Canonical Tag
Apakah canonical tag wajib dipasang di setiap halaman?
Tidak wajib. Dokumentasi Google menyatakan tidak satu pun metode kanonikalisasi bersifat wajib dan situs Anda kemungkinan tetap berjalan baik tanpanya. Tetapi Google menganjurkan kanonis yang menunjuk ke diri sendiri, dan hampir semua plugin SEO modern sudah memasangnya otomatis, jadi biasanya Anda tidak perlu melakukan apa pun.
Kenapa Google memilih kanonis yang berbeda dari yang saya nyatakan?
Karena rel canonical adalah sinyal kuat, bukan perintah. Penyebab tersering menurut dokumentasi Google: halamannya terlalu mirip sehingga dikelompokkan, ada sinyal lain di situs yang bertentangan (redirect, sitemap, protokol), plugin memasang kanonis yang salah, atau ada masalah di sisi server. Cek dulu di URL Inspection kanonis mana yang Google pilih, lalu telusuri sinyal mana yang tidak sejalan.
Lebih baik pakai canonical atau redirect 301?
Tergantung apakah halaman duplikatnya masih perlu dibuka manusia. Kalau masih perlu, misalnya URL dengan parameter pelacakan atau produk yang bisa dijangkau lewat dua kategori, pakai canonical. Kalau halaman itu sudah tidak perlu ada, pakai redirect permanen, karena dokumentasi Google menyebut redirect tepat dipakai justru ketika Anda ingin menyingkirkan duplikatnya.
Berapa lama sampai canonical yang saya perbaiki berpengaruh?
Dokumentasi Google menyebut bahwa bahkan setelah masalah konten diperbaiki, halaman bisa tertahan di dalam klaster duplikat sampai dua minggu. Perbedaan konten yang jelas dan signifikan membuat halaman terpisah lebih cepat. Jadi beri waktu minimal dua minggu sebelum menyimpulkan perbaikan Anda gagal.
Apakah canonical bisa dipakai untuk file PDF?
Bisa, tapi tidak lewat elemen HTML karena PDF tidak punya bagian head. Google mendukung rel canonical lewat HTTP response header untuk dokumen non-HTML, dan Google menyebut dukungan ini berlaku untuk hasil penelusuran web. Pakai URL absolut, sama seperti pada versi elemen HTML-nya.
Apakah dua canonical tag di satu halaman berbahaya?
Bukan berbahaya, tapi sia-sia. Anotasi yang saling bertentangan tidak dipakai untuk kanonikalisasi, jadi Google kembali menentukan sendiri. Penyebab paling umum adalah dua plugin SEO aktif bersamaan, atau isian canonical manual yang bertabrakan dengan kanonis otomatis. Periksa kode sumber yang benar-benar dikirim server, bukan pengaturan di dasbor.
Indonesian 