Tentukan apakah URL benar-benar duplikat
URL kanonik adalah alamat perwakilan untuk halaman yang duplikat atau hampir duplikat. rel=canonical tepat digunakan ketika target berisi konten duplikat atau superset dari konten halaman yang merujuk. Ini bukan cara untuk menyembunyikan produk berbeda, filter yang berguna, artikel, atau locale.
Tanyakan apakah pengunjung akan kehilangan konten penting, pilihan, atau kemampuan menyelesaikan tugas jika URL ini direpresentasikan oleh kandidat URL. Jika ya, pertahankan sebagai halaman terpisah dan perbaiki kontennya atau lokalisasinya. Jika tidak, pilih satu URL yang stabil dan dokumentasikan aturan protokol, host, path, trailing-slash, dan parameter-nya.
Tambahkan rel=canonical yang merujuk ke diri sendiri pada setiap halaman HTML indexable yang diutamakan, bahkan ketika tidak ada duplikat yang jelas hari ini.
Arahkan duplikat yang diperlukan, seperti rute parameter analitik, ke URL pilihan hanya jika kedua halaman mengembalikan konten utama yang sama.
Gunakan pengalihan saat URL lama harus menghilang
Gunakan pengalihan permanen sisi-server ketika path lama, host yang dihentikan, atau versi HTTP tidak lagi harus menjadi tujuan bagi pengunjung atau perayap. Google memperlakukan pengalihan sebagai sinyal kanonisasi yang kuat dan merekomendasikannya saat mendepresiasi duplikat.
Gunakan rel=canonical ketika kedua URL harus merespons dengan konten tetapi salah satu harus mewakili klaster di hasil pencarian. Tag tidak mengubah alamat pengunjung atau menghapus rute lain. Target harus berhasil (succeed) dan tidak boleh melakukan pengalihan atau men-canonical-kan ke tempat lain.
Kirim URL HTTP warisan langsung ke URL HTTPS akhir dan gunakan URL HTTPS itu di mana-mana.
Robots.txt, penghapusan URL, dan noindex tidak menyatakan duplikat yang diutamakan. Noindex justru memblokir halaman dari Pencarian.
Publikasikan satu anotasi yang jelas
Untuk HTML, letakkan satu anotasi rel=canonical absolut di elemen head. Tinjau sumber yang dikirim (delivered source), bukan hanya pengaturan CMS: tema, plugin, aturan edge, atau JavaScript dapat mengganti nilainya. Google menyarankan menyediakannya dalam sumber HTML dan memastikan JavaScript tidak mengubahnya.
Untuk dokumen non-HTML seperti PDF, gunakan header respons Link HTTP (HTTP Link response header) di mana sesuai. Hindari nilai yang saling bertentangan antara HTML dan header. Target harus dapat diakses, tidak boleh mengembalikan respons 4xx, dan tidak boleh menjadi URL yang mengalihkan atau berantai.
Publikasikan satu target canonical per sumber; beberapa target membuat preferensi menjadi tidak jelas.
Ambil sampel halaman dan header setelah perubahan template, CDN, CMS, atau routing dan konfirmasi target akhir.
Buat sinyal pendukung saling setuju
Tautkan secara internal ke URL yang dipilih di navigasi, breadcrumb, tautan badan, dan feed yang dihasilkan. Masukkan hanya URL yang Anda inginkan ditampilkan di pencarian ke dalam sitemap. Inklusi sitemap adalah sinyal yang lebih lemah, tetapi memperkuat pilihan ketika setuju dengan pengalihan dan anotasi.
Hasilkan URL sitemap lengkap dengan host, protokol, dan gaya slash yang sama seperti canonical. Hapus duplikat yang dialihkan dan yang berparameter. Uji sitemap yang dihasilkan secara otomatis setelah perubahan permalink, domain, bahasa, atau e‑commerce.
Ganti tautan ke URL yang dilacak, warisan, atau host alternatif dengan canonical yang dipilih.
Jaga konsistensi pengalihan HTTPS, target canonical, sitemap, dan tautan; masalah sertifikat atau pengalihan HTTPS-ke-HTTP mengirimkan sinyal yang bertentangan.
Tangani parameter, paginasi, dan bahasa berdasarkan tujuan
Parameter tidak otomatis membuat halaman menjadi duplikat. Parameter analitik mungkin tidak mengubah konten, sementara filter dan pengurutan dapat mengubah himpunan hasil. Uji kombinasi perwakilan. Pertahankan parameter yang diperlukan untuk cart, login, persetujuan, atau konfigurasi; canonical tidak boleh memutus alur pengunjung.
Jangan canonical-kan seluruh seri paginasi ke halaman pertama: halaman berikutnya biasanya berisi konten yang tidak ada di halaman satu. Untuk URL bahasa atau negara, tetapkan halaman dengan bahasa yang sama sebagai canonical ketika ada dan gunakan hreflang untuk alternatenya. Canonical bukan pengganti desain lokalisasi.
Dokumentasikan filter mana yang merupakan halaman landing yang berbeda dan mana yang hanya pengurutan ulang duplikat agar perubahan produk dan engineering tetap selaras.
Gunakan satu halaman lihat-semua hanya ketika itu benar-benar superset konten yang dapat digunakan; uji pemuatan dan navigasinya sebelum memilihnya.
Debug konflik dengan bukti terindeks dan langsung
Di Search Console, inspeksi URL yang terpengaruh dan bandingkan canonical yang dipilih Google (indexed Google-selected canonical) dengan nilai yang Anda deklarasikan. Inspeksi juga target kandidat. Laporan terindeks mencerminkan apa yang terakhir diproses Google; uji langsung berguna untuk fetch saat ini, halaman yang dirender, header, dan resource, tetapi tidak dapat memprediksi pemilihan canonical akhir.
Jika nilainya berbeda, pertimbangkan apakah Google memilih perwakilan yang lebih baik. Jika tidak, telusuri pengalihan, anotasi HTML dan HTTP-header, keluaran yang dirender, tautan, entri sitemap, hreflang, dan kemiripan konten. Perbaiki ketidaksepakatan, catat perubahan, dan beri waktu untuk evaluasi ulang.
Periksa template, header, routing host, dan perubahan keamanan. Canonical atau pengalihan lintas-domain yang tidak dapat dijelaskan memerlukan investigasi keamanan.
Bandingkan sumber dan header yang dikirim dengan pengaturan CMS; plugin atau aturan platform mungkin mengeluarkan nilai berbeda.
Tambahkan pemeriksaan canonical ke penguatan rilis SIU
Sebelum rilis domain, HTTPS, CDN, CMS, template, atau katalog, ambil sampel homepage, halaman konten dan produk, satu rute parameter, satu locale, satu URL warisan, dan dokumen yang dipublikasikan. Catat status, URL final, target canonical, inklusi sitemap, dan contoh tautan internal.
Buat perbaikan yang dapat dibalik: tangkap pemetaan saat ini, ubah satu set aturan, verifikasi rute terpengaruh, dan pertahankan rencana rollback. Ini mendukung optimasi uptime proaktif dengan melindungi path publik yang stabil selama perubahan; ini bukan deteksi outage atau jaminan pengindeksan.
Tetapkan aturan canonical di antara tim pemasaran dan engineering dan catat template, pengalihan, sitemap, atau perubahan platform di balik setiap pembaruan.
Lampirkan sampel URL dan header kecil sebelum-dan-sesudah ke tiket rilis untuk remediasi yang lebih cepat.