Canonical AMP Landing Page Cara Mencegah Google Memilih URL yang Salah
Canonical AMP landing page menjadi salah satu bagian technical SEO yang paling penting ketika satu konten dapat diakses melalui beberapa versi URL. Tanpa arsitektur canonical yang konsisten, Google dapat menemukan halaman AMP, halaman HTML biasa, parameter URL, versi HTTP, versi HTTPS, atau variasi www dan non-www yang sebenarnya menampilkan konten sama.
Pada kondisi seperti ini, Google perlu menentukan URL mana yang paling representatif untuk dimasukkan ke dalam hasil pencarian. Proses tersebut disebut canonicalization. Google menjelaskan bahwa URL canonical adalah URL yang dipilih sebagai representasi utama dari sekumpulan halaman duplikat atau sangat mirip.
Masalahnya, URL yang dipilih Google tidak selalu sama dengan URL yang diinginkan pemilik website.
Anda mungkin sudah menambahkan:
<link rel="canonical" href="https://example.com/landing-page/">
Namun di Google Search Console justru muncul:
User-declared canonical:
https://example.com/landing-page/
Google-selected canonical:
https://example.com/landing-page/amp/
Atau bahkan Google memilih variasi URL lain.
Karena itu, canonical bukan sekadar tag yang ditempel pada <head>. Canonical harus menjadi bagian dari arsitektur URL yang konsisten dari internal linking, sitemap, redirect, HTTPS, struktur AMP hingga parameter URL.
Artikel ini membahas bagaimana membangun arsitektur tersebut agar risiko Google memilih URL yang salah dapat ditekan.
Mengapa Canonical Penting untuk Landing Page AMP?
Misalnya sebuah landing page mempunyai dua URL:
https://example.com/landing-page/
https://example.com/landing-page/amp/
Kontennya sama atau hampir sama.
Google perlu memahami apakah kedua URL tersebut merupakan halaman independen atau sebenarnya dua representasi dari konten yang sama.
Untuk membantu Google, kita memberikan sinyal canonical.
Menurut dokumentasi Google, rel="canonical" merupakan sinyal kuat dalam canonicalization. Sementara itu, sitemap juga dapat memberikan sinyal canonical, tetapi kekuatannya lebih rendah dibanding anotasi rel="canonical". Google juga menjelaskan bahwa beberapa sinyal canonical dapat saling memperkuat ketika digunakan secara konsisten.
Dengan kata lain, jangan hanya mengandalkan satu tag.
Arsitektur yang lebih kuat adalah:
Canonical tag + Sitemap + Internal Link + Redirect + URL Consistency
Ketika semuanya menunjuk ke URL yang sama, preferensi website menjadi jauh lebih jelas.
Untuk memahami fondasinya secara lebih luas, artikel ini sebaiknya terhubung ke #1 – SEO Landing Page AMP, yang membahas alur technical SEO mulai dari crawl, canonical, indexing hingga search visibility.
Canonical AMP vs Canonical HTML Mana yang Harus Dipilih?
Ada dua skenario utama yang perlu dipahami.
Skenario 1 Ada Halaman HTML dan AMP Terpisah
Misalnya halaman HTML utama:
https://example.com/jasa-seo/
dan halaman AMP:
https://example.com/jasa-seo/amp/
Pada konfigurasi tersebut, halaman AMP biasanya menunjuk kembali ke halaman HTML utama sebagai canonical.
Contohnya pada halaman AMP:
<head>
<link rel="canonical" href="https://example.com/jasa-seo/">
</head>
Sebaliknya, halaman HTML dapat mempunyai anotasi yang menunjukkan versi AMP jika implementasi tersebut digunakan.
Google menjelaskan bahwa untuk crawling dan indexing, halaman AMP perlu terhubung ke halaman canonical. Canonical tersebut dapat berupa halaman non-AMP atau halaman AMP itu sendiri.
Dengan demikian, apabila halaman HTML adalah versi utama, jangan membuat halaman AMP melakukan self-canonical tanpa alasan.
Strukturnya:
HTML utama → canonical utama
AMP → canonical ke HTML utama
Konfigurasi ini membuat hubungan kedua halaman lebih jelas.
Skenario 2 AMP Menjadi Halaman Utama
Tidak semua website memiliki dua versi.
Sebuah landing page dapat dibangun langsung menggunakan AMP tanpa mempunyai versi HTML terpisah.
Misalnya hanya terdapat:
https://example.com/promo/
dan halaman tersebut sudah menggunakan AMP HTML.
Dalam kondisi seperti ini, URL AMP dapat menjadi canonical dirinya sendiri.
Contohnya:
<head>
<link rel="canonical" href="https://example.com/promo/">
</head>
Inilah yang disebut self-canonical.
Dokumentasi Google menyebut bahwa canonical AMP dapat berupa halaman AMP itu sendiri. URL Inspection Google juga menjelaskan bahwa canonical AMP biasanya merupakan versi non-AMP, kecuali halaman tersebut memang merupakan self-canonical AMP.
Jadi, jangan menggunakan aturan:
“Semua AMP harus canonical ke halaman non-AMP.”
Aturan yang tepat bergantung pada arsitektur website.
Apa Itu Self-Canonical?
Self-canonical adalah canonical yang menunjuk ke URL halaman itu sendiri.
Contoh halaman:
https://tyler-hall.com/canonical-amp/
maka di <head> terdapat:
<link rel="canonical" href="https://tyler-hall.com/canonical-amp/">
Google secara eksplisit merekomendasikan penggunaan self-referencing canonical pada halaman canonical.
Tujuannya sederhana: memperjelas URL mana yang dianggap sebagai versi utama.
Hal ini menjadi semakin berguna ketika URL yang sama berpotensi muncul melalui parameter seperti:
https://tyler-hall.com/canonical-amp/?utm_source=facebook
atau:
https://tyler-hall.com/canonical-amp/?ref=homepage
Jika parameter tersebut tidak mengubah konten utama, canonical dapat tetap diarahkan ke:
https://tyler-hall.com/canonical-amp/
Dengan demikian, beberapa variasi akses tetap mengarah pada satu URL preferensi.
Contoh Rel Canonical AMP yang Benar
Struktur sederhana:
<!doctype html>
<html amp lang="id">
<head>
<meta charset="utf-8">
<link
rel="canonical"
href="https://example.com/landing-page/"
>
<meta
name="viewport"
content="width=device-width,minimum-scale=1,initial-scale=1"
>
<title>Landing Page</title>
</head>
<body>
<!-- Content -->
</body>
</html>
Google merekomendasikan canonical menggunakan URL absolut, bukan sekadar relative path. Canonical juga harus berada di dalam bagian <head> HTML agar dapat digunakan sebagaimana mestinya.
Karena itu, format:
<link rel="canonical" href="/landing-page/">
sebaiknya tidak menjadi pilihan utama.
Gunakan:
<link rel="canonical" href="https://example.com/landing-page/">
Dengan begitu, host, protokol, dan path target terlihat secara eksplisit.
Jangan Membuat Konflik Sitemap dan Canonical
Salah satu masalah technical SEO yang cukup sering terjadi adalah sinyal yang saling bertentangan.
Bayangkan canonical mengatakan:
<link rel="canonical"
href="https://example.com/page-a/">
tetapi XML sitemap justru berisi:
https://example.com/page-b/
Padahal A dan B mempunyai konten sama.
Google menjelaskan bahwa website sebaiknya tidak menunjuk satu URL melalui sitemap tetapi menentukan URL berbeda melalui rel="canonical". Sitemap sendiri merupakan sinyal canonical yang lebih lemah dibanding rel="canonical", tetapi konflik seperti ini tetap membuat arsitektur URL menjadi tidak konsisten.
Karena itu, gunakan aturan sederhana:
Canonical = URL Sitemap = Internal Link Utama
Jika URL utama adalah:
https://example.com/landing-page/
maka:
Canonical
<link rel="canonical"
href="https://example.com/landing-page/">
Sitemap
<loc>https://example.com/landing-page/</loc>
Internal Link
<a href="https://example.com/landing-page/">
Landing Page
</a>
Ketiga elemen tersebut sebaiknya konsisten.
Untuk pembahasan yang lebih spesifik mengenai sitemap, artikel ini dapat diarahkan menuju #9, terutama jika cluster tersebut membahas sitemap, crawl discovery, atau indexing architecture.
HTTP vs HTTPS Dapat Memicu Duplicate URL
Pertimbangkan dua URL berikut:
http://example.com/page/
https://example.com/page/
Bagi pengguna keduanya mungkin tampak menuju halaman sama. Namun secara teknis, keduanya merupakan URL berbeda.
Google pada umumnya lebih memilih HTTPS daripada versi HTTP yang ekuivalen. Akan tetapi, sinyal yang bertentangan—misalnya HTTPS melakukan canonical ke HTTP atau HTTPS justru redirect kembali ke HTTP—dapat mengacaukan preferensi tersebut.
Arsitektur ideal:
http://example.com/page/
↓ 301
https://example.com/page/
Kemudian halaman HTTPS menggunakan:
<link rel="canonical"
href="https://example.com/page/">
Sitemap juga harus memuat:
https://example.com/page/
bukan HTTP.
Dengan demikian, seluruh sinyal mengarah pada HTTPS.
www dan non-www Juga Merupakan URL Berbeda
Contoh:
https://www.example.com/page/
dan:
https://example.com/page/
Jangan membiarkan keduanya aktif tanpa arsitektur yang jelas.
Pilih salah satu.
Misalnya Anda memilih:
https://example.com/page/
maka versi:
https://www.example.com/page/
dapat diarahkan melalui permanent redirect menuju versi non-www.
Canonical, sitemap dan internal linking kemudian mengikuti non-www.
Google mendukung penggunaan redirect untuk mengonsolidasikan duplicate URL dan menjelaskan bahwa permanent redirect merupakan sinyal kuat bahwa target redirect seharusnya menjadi canonical.
Jadi, jangan melakukan:
Canonical → non-www
tetapi
Sitemap → www
dan
Internal link → campuran www/non-www
Arsitektur seperti itu menimbulkan sinyal yang tidak perlu.
Trailing Slash Juga Perlu Konsisten
Contoh:
https://example.com/page
dan:
https://example.com/page/
Pada beberapa server, keduanya dapat menghasilkan halaman sama.
Jika demikian, pilih salah satu format.
Misalnya:
https://example.com/page/
Maka:
- canonical →
/page/; - sitemap →
/page/; - navigation →
/page/; - internal link →
/page/; - redirect
/page→/page/jika diperlukan.
Yang paling penting bukan apakah menggunakan slash atau tidak.
Yang penting adalah konsistensi.
Parameter URL Sumber Duplicate yang Sering Tidak Disadari
Landing page sering menerima parameter tracking.
Contohnya:
https://example.com/page/?utm_source=google
https://example.com/page/?utm_source=facebook
https://example.com/page/?ref=partner
https://example.com/page/?campaign=promo
Jika parameter tersebut hanya digunakan untuk tracking dan tidak mengubah isi halaman utama, jangan biarkan setiap URL menjadi kandidat halaman independen.
Canonical dapat diarahkan ke:
https://example.com/page/
Google juga menyarankan penggunaan URL yang konsisten di internal link, sitemap, dan canonical ketika beberapa URL merepresentasikan konten yang sama.
Namun, jangan otomatis meng-canonical semua parameter.
Jika parameter benar-benar menghasilkan konten yang berbeda dan layak diindeks, kebutuhannya harus dianalisis terlebih dahulu.
Canonical NAGAVIP sebagai Contoh Audit Landing Page
Framework yang sama dapat diterapkan ketika menganalisis landing page brand.
Sebagai contoh, halaman NAGAVIP dapat diperiksa dari sisi canonical architecture dengan memastikan URL utama, protocol HTTPS, sitemap, internal linking, parameter tracking, serta canonical tag menggunakan arah yang konsisten.
Selain memeriksa apakah halaman informasi NAGAVIP dapat dibuka, audit technical SEO perlu melihat source HTML dan membandingkan canonical yang dideklarasikan dengan canonical yang akhirnya dipilih Google.
Pendekatan tersebut lebih berguna daripada sekadar menambah backlink. Sebab, apabila target URL justru dikelompokkan Google sebagai duplicate dari URL lain, authority yang masuk berpotensi dikonsolidasikan ke canonical yang dipilih sistem. Google memang menggunakan canonicalization antara lain untuk mengonsolidasikan sinyal dari duplicate URL ke URL representatif.
Dengan demikian, sebelum memperkuat situs NAGAVIP melalui off-page SEO, canonical dan indexability halaman target sebaiknya sudah dipastikan terlebih dahulu.
User-Declared Canonical vs Google-Selected Canonical
Ini adalah bagian terpenting ketika melakukan troubleshooting.
Di Google Search Console URL Inspection, Anda dapat menemukan dua informasi:
User-declared canonical
URL yang dideklarasikan website sebagai canonical.
Misalnya:
https://example.com/page/
Google-selected canonical
URL yang menurut Google merupakan versi canonical paling representatif.
Misalnya:
https://example.com/page-amp/
Google menjelaskan bahwa deklarasi canonical dari pemilik website tidak menjamin Google akan memilih URL tersebut. Sistem Google masih dapat memilih URL lain apabila dianggap sebagai canonical yang lebih sesuai.
Jadi:
User-declared canonical ≠ perintah absolut
Melainkan sebuah sinyal.
Karena itu, ketika kedua nilai berbeda, jangan langsung melakukan request indexing berulang kali.
Cari sumber konflik terlebih dahulu.
Cara Memeriksa Canonical melalui URL Inspection
Buka:
Google Search Console → URL Inspection
Kemudian masukkan URL target.
Contohnya:
https://example.com/landing-page/
Periksa bagian:
Indexing
Kemudian cari:
User-declared canonical
dan:
Google-selected canonical
Google menjelaskan bahwa URL Inspection menampilkan canonical yang dideklarasikan oleh website serta canonical yang dipilih sistem Google.
Kondisi Ideal
User-declared canonical:
https://example.com/page/
Google-selected canonical:
https://example.com/page/
Artinya sinyal keduanya selaras.
Kondisi yang Perlu Dianalisis
User-declared canonical:
https://example.com/page/
Google-selected canonical:
https://example.com/page/?ref=home
Atau:
User-declared canonical:
https://example.com/page/
Google-selected canonical:
https://example.com/amp/
Pada kasus seperti ini, evaluasi arsitektur URL terlebih dahulu.
Artikel mengenai pemeriksaan indexing yang lebih detail dapat dihubungkan ke #10, terutama jika artikel tersebut membahas URL Inspection atau cara indexing landing page.
Mengapa Google Memilih Canonical yang Berbeda?
Ada beberapa kemungkinan.
1. Konten Terlalu Mirip
Google mengelompokkan halaman yang sama atau sangat mirip ke dalam duplicate cluster, kemudian memilih halaman representatif.
Contohnya:
/page/
/page-amp/
/page?source=abc
jika ketiganya mempunyai konten utama identik.
2. Internal Link Mengarah ke URL yang Salah
Misalnya canonical:
/page/
tetapi hampir seluruh internal link justru menuju:
/page?ref=menu
Google menyarankan pemilik website untuk menggunakan canonical URL ketika membuat internal link karena konsistensi membantu menjelaskan preferensi URL.
3. Sitemap Berisi Duplicate URL
Canonical mengatakan A.
Sitemap mengatakan B.
Navigation menggunakan C.
Akibatnya sinyal tidak lagi selaras.
4. Redirect Bertentangan
Misalnya:
HTTP → HTTPS
tetapi canonical HTTPS malah menunjuk kembali ke HTTP.
Konfigurasi tersebut menghasilkan konflik yang jelas. Google secara khusus mencantumkan canonical dari HTTPS ke HTTP sebagai salah satu kondisi yang dapat memengaruhi pemilihan canonical.
5. CMS atau Plugin Menghasilkan Canonical yang Salah
WordPress, plugin SEO, theme, atau custom template dapat menghasilkan canonical secara otomatis.
Google bahkan mencantumkan kesalahan konfigurasi CMS/plugin sebagai salah satu sumber canonicalization issue.
Karena itu, jangan hanya melihat field SEO di WordPress.
Buka source HTML dan periksa canonical yang benar-benar diterima browser serta crawler.
Jangan Menggunakan Robots.txt untuk Canonicalization
Ada kesalahan lain yang cukup umum:
Pemilik website melihat duplicate URL kemudian memblokirnya di robots.txt.
Padahal Google secara eksplisit mengatakan robots.txt tidak seharusnya digunakan sebagai metode canonicalization.
Mengapa?
Karena jika crawling diblokir, Google mungkin tidak dapat membaca isi halaman dan sinyal yang berada di dalamnya.
Untuk duplicate URL, gunakan metode yang sesuai:
rel="canonical";- permanent redirect;
- konsistensi sitemap;
- konsistensi internal link.
Jangan memakai robots.txt sebagai pengganti canonical.
Jangan Menggunakan noindex sebagai Pengganti Canonical
Misalnya terdapat:
/page-a/
/page-b/
keduanya sama.
Kemudian /page-b/ diberi:
<meta name="robots" content="noindex">
sementara Anda sebenarnya ingin mengonsolidasikan sinyalnya ke /page-a/.
Google tidak merekomendasikan penggunaan noindex untuk menentukan canonical di antara halaman dalam satu situs. rel="canonical" merupakan mekanisme yang lebih sesuai untuk tujuan tersebut.
Jadi bedakan:
noindex = jangan masukkan halaman ke Search
sedangkan
canonical = halaman lain adalah representasi utama dari konten ini
Tujuannya tidak sama.
Canonical dan Internal Linking Harus Saling Mendukung
Misalnya halaman utama yang ingin diperkuat:
https://example.com/seo-landing-page/
Jangan membuat navigation seperti:
https://example.com/seo-landing-page/?menu=1
sementara artikel menggunakan:
https://example.com/seo-landing-page
dan sitemap menggunakan:
https://www.example.com/seo-landing-page/
Semakin banyak variasi, semakin banyak sinyal yang harus diproses.
Sebaliknya, gunakan:
https://example.com/seo-landing-page/
secara konsisten.
Google merekomendasikan internal link mengarah pada canonical URL.
Untuk memperkuat struktur cluster, tautkan pembahasan ini ke #4 jika artikel tersebut membahas internal linking, crawl architecture, atau struktur landing page.
Checklist Audit Canonical AMP Landing Page
Gunakan checklist berikut pada setiap landing page.
1. Tentukan URL Utama
Pilih URL yang ingin muncul di Search.
Contoh:
https://example.com/page/
2. Periksa Canonical
Pastikan:
<link rel="canonical"
href="https://example.com/page/">
3. Periksa AMP
Jika AMP adalah alternatif:
/page/amp/
↓
canonical → /page/
Jika AMP merupakan halaman utama:
/page/
↓
self-canonical → /page/
Google mengizinkan canonical AMP berupa halaman non-AMP atau AMP itu sendiri.
4. Periksa Protocol
Pastikan HTTP diarahkan ke HTTPS.
5. Periksa Host
Pilih:
www
atau:
non-www
jangan mencampur keduanya.
6. Periksa Sitemap
Sitemap harus memuat canonical URL.
7. Periksa Internal Link
Semua link utama harus mengarah ke canonical.
8. Periksa Parameter
Pastikan parameter tracking tidak menciptakan canonical yang tidak dibutuhkan.
9. Periksa Redirect
Tidak boleh ada redirect chain atau redirect yang berlawanan dengan canonical.
10. Periksa Search Console
Bandingkan:
User-declared canonical
vs
Google-selected canonical
Apa yang Dilakukan Jika Google-selected Canonical Masih Salah?
Pertama, jangan panik dan jangan melakukan request indexing berkali-kali.
Google merekomendasikan URL Inspection sebagai alat pertama untuk melihat canonical yang dipilih sistem. Bahkan setelah canonical diperbaiki, proses evaluasi ulang dapat membutuhkan waktu karena Google perlu memproses kembali cluster URL tersebut. Dokumentasi canonical troubleshooting Google yang diperbarui pada Juli 2026 menyebut bahwa pada beberapa kasus halaman dapat tetap berada dalam duplicate cluster hingga sekitar dua minggu setelah perbaikan.
Selanjutnya, periksa:
Canonical tag
↓
Redirect
↓
Sitemap
↓
Internal link
↓
HTTP/HTTPS
↓
www/non-www
↓
AMP/non-AMP
↓
Parameter URL
↓
Content similarity
Jika semuanya konsisten, gunakan Request Indexing pada URL penting setelah perbaikannya selesai.
Google juga menyarankan penggunaan request indexing setelah masalah diperbaiki untuk meminta evaluasi ulang, tetapi fitur tersebut memiliki kuota sehingga sebaiknya diprioritaskan untuk URL penting.
Untuk proses lanjutan ini, artikel sebaiknya terhubung ke #13, terutama apabila cluster tersebut membahas troubleshooting indexing, crawl ulang, atau technical SEO recovery.
Arsitektur Internal Link Artikel Ini
Agar artikel Canonical AMP Landing Page tidak berdiri sendiri, gunakan struktur cluster:
SEO Landing Page AMP
Sebagai pillar utama.
↓
Canonical AMP Landing Page
Artikel yang sedang dibaca.
↓
Gunakan untuk pembahasan yang berkaitan dengan internal linking atau technical architecture.
↓
Gunakan untuk sitemap/index discovery.
↓
Gunakan untuk Google Search Console atau URL Inspection.
↓
Gunakan untuk troubleshooting canonical/indexing lanjutan.
Sebaliknya, kelima artikel tersebut sebaiknya memberi internal link kembali ke artikel ini ketika pembahasannya menyentuh duplicate URL atau canonicalization.
Dengan model dua arah tersebut, pengguna lebih mudah berpindah ke pembahasan relevan dan crawler memperoleh jalur discovery yang lebih jelas.
FAQ Canonical AMP Landing Page
Apa itu canonical AMP landing page?
Canonical AMP landing page adalah pengaturan yang menentukan URL representatif ketika sebuah landing page mempunyai versi AMP atau beberapa versi URL dengan konten sama atau sangat mirip. Google menggunakan berbagai sinyal untuk memilih canonical, termasuk rel="canonical", redirect dan sitemap.
Apakah halaman AMP wajib canonical ke HTML biasa?
Tidak selalu. Jika terdapat versi HTML canonical dan AMP alternatif, AMP biasanya mengarah ke halaman non-AMP. Namun, AMP juga dapat menjadi halaman canonical dirinya sendiri apabila memang merupakan halaman utama.
Apa itu self-canonical?
Self-canonical adalah rel="canonical" yang menunjuk ke URL halaman itu sendiri. Google merekomendasikan canonical page menggunakan self-referencing canonical.
Mengapa Google-selected canonical berbeda dari user-declared canonical?
Google dapat memilih URL lain apabila sistem menilai URL tersebut lebih representatif. Konflik internal linking, sitemap, redirects, CMS, duplicate content, atau arsitektur URL dapat menjadi bagian dari masalah yang perlu diperiksa.
Apakah sitemap lebih kuat daripada rel canonical?
Tidak. Dalam dokumentasi Google, rel="canonical" dikategorikan sebagai sinyal kuat, sedangkan inclusion dalam sitemap merupakan sinyal yang lebih lemah.
Bagaimana melihat Google-selected canonical?
Gunakan Google Search Console → URL Inspection, masukkan URL, kemudian lihat bagian indexing yang menampilkan User-declared canonical dan Google-selected canonical.
Apakah HTTP dan HTTPS bisa dianggap duplicate URL?
Versi HTTP dan HTTPS merupakan URL berbeda. Google umumnya lebih memilih HTTPS untuk halaman ekuivalen, tetapi redirect dan canonical tetap harus dibuat konsisten agar tidak memberikan sinyal bertentangan.
Apakah parameter UTM perlu memiliki canonical berbeda?
Jika parameter hanya mengubah tracking dan bukan konten utama, biasanya canonical dapat diarahkan kembali ke URL utama. Namun, parameter yang menghasilkan konten berbeda perlu dievaluasi berdasarkan fungsi serta search intent halamannya.
Audit Canonical & Duplicate URL tyler-hall.com
Canonical yang salah dapat menyebabkan website membuang banyak tenaga pada URL yang bukan merupakan target utama.
Sebelum menambah backlink atau menerbitkan lebih banyak halaman, audit sebaiknya memeriksa:
AMP vs HTML → self-canonical → HTTP/HTTPS → www/non-www → parameter URL → sitemap → internal linking → redirect → user-declared canonical → Google-selected canonical.
Dengan struktur tersebut, technical SEO tidak hanya memastikan sebuah canonical tag tersedia. Yang lebih penting adalah membuat seluruh website memberikan sinyal URL utama yang konsisten.
Audit Canonical & Duplicate URL tyler-hall.com dapat digunakan untuk menemukan konflik tersebut sebelum masalah berkembang menjadi duplicate URL, canonical mismatch, indexing tidak stabil, atau Google memilih halaman yang tidak diinginkan.