File PDF tidak punya <head>, jadi Anda tidak bisa memasang tag <link rel="canonical"> di dalam dokumen. Google mendukung anotasi canonical PDF lewat response header HTTP dengan pola Link: <URL absolut>; rel="canonical". Pola itu melengkapi metode HTML pada halaman web biasa saat Anda menandai versi representatif konten duplikat atau sangat mirip.
Canonical bukan perintah mutlak. Google memperlakukannya sebagai sinyal kuat saat memilih URL representatif, namun mesin pencari tetap bisa memilih canonical berbeda bila sinyal lain lebih kuat.
Artikel ini fokus pada implementasi server, verifikasi, dan batas scope technical SEO. Jangan memakai canonical untuk konten yang intent-nya berbeda hanya demi memindahkan sinyal ranking.
Syntax Link Header dan URL Absolut
Contoh pola resmi Google Search Central ada di bawah ini. Untuk header HTTP, Google meminta URL absolut (skema + host + path). Path relatif seperti </report/> tidak memenuhi aturan dokumentasi consolidate duplicate URLs.
Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical"Jika HTML dan PDF menggambarkan konten yang setara, file PDF dapat mengarahkan header canonical ke halaman artikel HTML. Contoh: /article/report-2026/ sebagai versi utama dan /download/report-2026.pdf mengirim header ke URL HTML tersebut. Dua URL PDF identik di folder berbeda juga bisa saling menunjuk versi pilihan, asalkan konten benar-benar duplicate.
Penjelasan lengkap canonicalization ada di dokumentasi canonicalization Google dan halaman consolidate duplicate URLs.
Kapan Header Canonical Dibutuhkan untuk Dokumen
HTTP Link relevan untuk PDF, DOC, dan dokumen non-HTML lain yang Google dapat crawl. Kasus umum: satu konten hidup di beberapa URL (CDN, folder upload berbeda) atau mirror versi HTML. Jangan memasang canonical pada setiap file unduhan hanya demi SEO.
Google membandingkan kekuatan sinyal: redirect HTTP permanen dan rel="canonical" keduanya sinyal kuat; inclusion di sitemap lebih lemah. Bila URL lama tidak perlu lagi diakses pengguna, redirect 301 sering lebih jelas daripada canonical. Canonical cocok bila pengunjung masih perlu mengunduh duplikat tersebut.
Redirect permanen mengalihkan browser dan crawler ke URL baru. Header canonical hanya memberi petunjuk versi representatif sambil membiarkan URL lama tetap merespons. Pilih redirect bila URL lama tidak lagi valid untuk dibagikan. Pilih header bila URL lama masih dipakai di email, materi cetak, atau CDN lama.
Indexing PDF di Google Search berbeda dari HTML. Sebelum mengandalkan dokumen unduhan sebagai aset utama, baca konteks di PDF bisa ranking di Google, tetapi HTML tetap lebih disarankan. Sitemap XML tetap membantu discovery. Inclusion sitemap lemah dibanding sinyal canonical atau redirect. Gunakan kombinasi yang konsisten dengan strategi konten Anda, bukan sebagai pengganti hubungan duplicate yang jelas.
Tim legal atau riset kadang mempublikasikan white paper sementara marketing memegang landing HTML ringkas. Header canonical dari unduhan ke HTML (atau sebaliknya) hanya valid bila isi setara. Jika lampiran data mentah hanya ada di file unduhan sedangkan HTML ringkasan eksekutif, jangan paksa canonical hanya karena judul mirip.
Contoh Apache dan Nginx
Di Apache, modul mod_headers (jika aktif) dapat men-set header per file seperti contoh berikut. Pastikan modul enabled dan quoting URL absolut benar sebelum menerapkan ke production.
<Files "report.pdf">
Header set Link '<https://example.com/article/report-2026/>; rel="canonical"'
</Files>Di Nginx, scope location harus tepat agar regex massal tidak salah mengarahkan semua PDF ke satu canonical. Gunakan location = untuk path spesifik, lalu uji inheritance add_header bila Anda juga memakai header keamanan di parent block.
location = /downloads/report.pdf {
add_header Link '<https://example.com/article/report-2026/>; rel="canonical"';
}Sebelum reload, jalankan nginx -t, backup vhost, dan uji di staging. Jika web server menyajikan PDF langsung tanpa PHP, jangan menambahkan header lewat skrip aplikasi yang tidak ikut menangani response. Praktik hardening server sejalan dengan cara website bisa diretas dan pencegahannya, termasuk memeriksa header tak terduga setelah insiden keamanan.
Verifikasi Header dan Konflik Sinyal
Setelah deploy, verifikasi respons HTTP (bukan hanya log reload sukses) dengan perintah berikut. Crawler Google melihat header yang benar-benar terkirim ke klien.
curl -I https://example.com/downloads/report.pdfCari baris Link: dengan rel="canonical", lalu bandingkan URL dengan versi HTML jika Anda menetapkan hubungan PDF-ke-artikel. Hindari konflik internal: jangan memakai canonical HTML ke URL A dan header HTTP ke URL B pada respons yang sama. Google merekomendasikan satu mekanisme per dokumen bila memungkinkan.
Cross-domain canonical hanya masuk akal untuk konten sindikasi atau duplikat resmi, bukan trik transfer otoritas. Canonical tidak menggantikan noindex, tidak memperbaiki robots.txt yang memblokir, tidak memaksa crawl, dan tidak mengalihkan pengunjung manusia; scope-nya konsolidasi URL duplikat. Untuk lapisan technical SEO situs HTML, tinjau risiko technical SEO pada situs statis agar sinyal selaras dengan struktur URL keseluruhan.
Header dari Aplikasi dan Audit Keamanan
Bila unduhan dikirim lewat endpoint aplikasi (PHP, Node, dll.), tambahkan header Link di layer aplikasi. Contoh PHP: header('Link: <https://example.com/report/>; rel="canonical"'); asalkan respons berasal dari aplikasi tersebut. Dokumentasi troubleshooting Google juga mencatat header canonical bisa disalahgunakan penyerang setelah kompromi situs. Setelah insiden, audit respons file publik untuk header Link tak terduga selain redirect dan injeksi HTML.
Fokuskan HTTP canonical pada hubungan duplicate atau near-duplicate yang Anda yakini benar secara editorial. Jangan menjadikannya alat memaksa indexing, mengganti perbaikan file corrupt, atau mengatasi halaman yang memang seharusnya noindex. Awali pemulihan dari backup bersih dan review konfigurasi server, bukan hanya menghapus satu baris header.
