Panduan SEO AMP

TL;DR — AMP (Accelerated Mobile Halaman) adalah kerangka kerja Google dari 2015 untuk membuat halaman seluler yang sangat cepat. AMP tidak pernah menjadi faktor peringkat, dan sejak Juni 2021 Anda tidak lagi memerlukannya agar bisa muncul di carousel Top Stories Google—Core Web Vitals kini mengambil alih peran itu. Untuk situs baru, AMP tidak perlu dipakai. Jika sudah menggunakannya, putuskan apakah manfaatnya masih sepadan dengan kerepotannya.

Apa itu AMP

AMP adalah singkatan dari Accelerated Mobile Halaman. Google meluncurkannya pada 2015 (AMP tersedia di Google Search sejak Oktober tahun itu) sebagai cara sumber terbuka untuk membuat halaman seluler dimuat hampir seketika.

Cara kerjanya adalah dengan membatasi halaman secara ketat. AMP hanya mengizinkan himpunan HTML yang terbatas, JavaScript buatan Anda sebagian besar dilarang, CSS harus sebaris dan berukuran kecil, serta Anda harus memuat pustaka AMP khusus. Sebagai gantinya, Google dapat menyimpan salinan halaman di jaringannya yang sangat cepat (Google AMP Cache) dan memuatnya di latar belakang sebelum seseorang mengetuk hasil Anda—sehingga terasa instan.

Mengapa orang dulu menggunakannya

Selama bertahun-tahun, AMP pada dasarnya adalah tiket masuk ke carousel Top Stories—kotak berita di bagian atas hasil penelusuran seluler. Jika Anda mengelola situs berita dan ingin muncul di Top Stories, Anda membutuhkan AMP. Google juga menampilkan ikon petir kecil (⚡) di sebelah hasil AMP agar orang tahu halaman itu akan dimuat cepat.

Apa yang berubah

Pada Juni 2021, Google berhenti mewajibkan AMP untuk Top Stories. Kini halaman apa pun dapat muncul di sana selama memenuhi kriteria berita Google—untuk sisi performa, yang penting adalah Core Web Vitals, metrik kecepatan dan kestabilan Google, bukan AMP. Google juga menghapus badge petir dari hasil penelusuran pada waktu yang kurang lebih sama.

Hal yang paling sering disalahpahami

AMP bukan peningkat peringkat. Google selalu mengatakan bahwa AMP sendiri bukan faktor peringkat. Halaman cepat memang dapat memiliki peringkat lebih baik, tetapi AMP hanyalah salah satu cara untuk mendapatkannya, bukan satu-satunya. Halaman biasa yang dibangun dengan baik dapat sama cepatnya (atau lebih cepat) tanpa semua batasan AMP.

Perlukah Anda menggunakannya sekarang?

• Situs baru? Jangan membangunnya di atas AMP. Gunakan upaya itu untuk Core Web Vitals.
• Sudah memiliki AMP? AMP masih berfungsi dan tetap diindeks. Namun, banyak penerbit menonaktifkannya tanpa kehilangan banyak traffic, antara lain karena AMP membuat analytics lebih rumit. Tanyakan apakah AMP masih memberikan hasil yang sepadan dengan biaya pemeliharaannya.

Ingin versi lengkap—tag canonical, masalah penulisan ulang URL, Signed Exchange, jebakan analytics, dan checklist penghapusan yang nyata? Beralihlah ke tab Advanced.

TL;DR — AMP adalah kerangka kerja sumber terbuka Google dari 2015 untuk halaman seluler yang hampir seketika—HTML/CSS/JS terbatas ditambah prerendering dari Google AMP Cache. AMP tidak pernah menjadi faktor peringkat (Google menyatakannya secara eksplisit), dan sejak pembaruan Halaman Experience Juni 2021, AMP tidak lagi diperlukan untuk Top Stories— Core Web Vitals menggantikannya dan badge AMP dihapus. AMP yang di-cache tetap disajikan di bawah google.com/amp/s/…; Signed Exchange (SXG) dapat menyajikannya di bawah URL Anda sendiri, tetapi hanya di Chrome. Hubungan canonical memasangkan halaman non-AMP yang canonical ke dirinya sendiri (dengan rel="amphtml") dengan halaman AMP yang mengarah kembali melalui rel="canonical". Kini AMP bersifat opsional dan makin ditinggalkan: jangan membangun AMP baru, dan timbang biaya operasionalnya (terutama analytics) sebelum mempertahankannya.

Sedikit sejarah

Google meluncurkan AMP pada 2015 dan membuatnya tersedia di Google Search pada Oktober 2015, menempatkannya sebagai jawaban open web terhadap Facebook Instant Artikel dan Apple News—cara agar halaman penerbit tetap kompetitif dalam kecepatan seluler. Saat diluncurkan, AMP didukung oleh mitra seperti Twitter, LinkedIn, WordPress, dan Pinterest; proyek ini kemudian berada di bawah tata kelola OpenJS Foundation, meski Google tetap menjadi kontributor terbesar.

Alasan kebanyakan penerbit benar-benar mengadopsinya bukan ideologi, melainkan carousel Top Stories. Sekitar 2016 hingga 2021, AMP pada praktiknya diwajibkan untuk tampil di sana, dan Google menandai hasil AMP dengan badge petir (⚡).

Cara kerja AMP secara teknis

AMP memperoleh kecepatannya melalui berbagai batasan:

• Markup terbatas. Halaman AMP mendeklarasikan <html ⚡> (atau <html amp>), memuat runtime AMP JS (<script async src="https://cdn.ampproject.org/v0.js">), serta menyertakan boilerplate AMP dan meta tag charset serta viewport yang diwajibkan.
• Tidak ada JavaScript dari penulis. JS buatan Anda dilarang kecuali melalui komponen amp-script yang disandbox; JS pihak ketiga hanya berjalan di dalam iframe. Semua yang berjalan bersifat asinkron, sehingga tidak ada yang menghambat rendering.
• CSS harus sebaris dan dibatasi 75KB. Stylesheet eksternal tidak diperbolehkan.
• Dimensi resource dideklarasikan secara statis. Gambar dan embed memesan ruangnya sejak awal, sehingga pergeseran layout dapat dicegah.

Aturan-aturan itulah yang memungkinkan Google melakukan prerender halaman AMP dengan aman di iframe tersembunyi sebelum pengguna mengetuknya—dari situlah sensasi “instan” berasal.

Google AMP Cache

Kecepatan AMP bukan hanya berkat kerangka kerja, melainkan juga cara penyajiannya. Google menyimpan salinan halaman AMP yang sudah divalidasi dan dioptimalkan di cdn.ampproject.org, menyajikannya melalui HTTPS dan protokol modern, serta mengoptimalkan gambar. Satu konsekuensi yang perlu dipahami: dengan AMP yang di-cache, infrastruktur Google menjadi host konten Anda, bukan server Anda. Perhatikan juga bahwa halaman AMP desktop tidak disajikan dari AMP Cache—AMP canonical berperilaku sebagai hasil standar di sana—jadi manfaat akselerasi CDN pada dasarnya hanya berlaku untuk seluler.

Apa yang sebenarnya terjadi di Google Search

Linimasa yang penting:

• 2016–2021: Badge AMP (⚡) ditampilkan di hasil; AMP diwajibkan untuk Top Stories.
• April 2021: Google mengumumkan bahwa, melalui pembaruan Halaman Experience, “menggunakan itu AMP format adalah Tidak lebih lama wajib” (terjemahan) “format AMP tidak lagi diwajibkan” untuk Top Stories.
• Juni 2021: Pembaruan Halaman Experience diluncurkan. Core Web Vitals menjadi sinyal performa untuk kelayakan Top Stories, dan Google menghapus badge AMP dari hasil.
• 2021–sekarang: AMP bersifat opsional, tidak membawa peningkatan peringkat, dan CWV-lah yang benar-benar mendorong sinyal terkait performa.

Inti yang perlu Anda ingat: AMP sendiri bukan faktor peringkat, dan AMP bukan lagi tiket Anda ke Top Stories.

Masalah penulisan ulang URL (dan Signed Exchange)

Ada tiga URL yang terlibat untuk satu artikel AMP: URL penerbit asli Anda, URL AMP Cache di cdn.ampproject.org, dan URL Google AMP Viewer, yang tampak seperti https://www.google.com/amp/s/[your-domain]/[path]. Karena prerendering memerlukan iframe dengan origin yang sama, Viewer menyajikan konten Anda di bawah URL google.com—pengguna melihat domain Google, bukan milik Anda. Ini benar-benar pernah menimbulkan kebingungan merek dan masalah atribusi.

Signed Exchange (SXG) adalah solusinya. SXG membungkus dokumen AMP dalam tanda tangan kriptografis yang terikat pada URL Anda; ketika Chrome memvalidasinya, browser menampilkan domain Anda di bilah alamat. Google memprioritaskan signed exchange dibandingkan AMP Viewer ketika didukung. Kekurangannya: SXG hanya tersedia di Chrome, masa berlaku tanda tangan maksimal 7 hari (jadi packager harus menandatangani ulang), cakupannya terbatas pada hasil kaya dan dasar (bukan carousel), dan Anda perlu menjalankan server amppackager atau penyedia SXG pihak ketiga. Inilah metode penyajian yang “tepat”, tetapi membutuhkan tambahan kerja operasional yang berarti.

Pemberian tag canonical AMP

Di sinilah implementasi AMP paling sering rusak. Ada dua konfigurasi:

• Berpasangan (paling umum): satu halaman non-AMP dan satu halaman AMP terpisah.
  • Halaman non-AMP menjadi canonical untuk dirinya sendiri dan menambahkan <link rel="amphtml" href="https://example.com/article/amp/">.
  • Halaman AMP menambahkan <link rel="canonical" href="https://example.com/article/"> yang menunjuk kembali ke versi non-AMP.
• AMP saja: satu URL berfungsi sebagai canonical sekaligus AMP, sehingga merujuk ke dirinya sendiri.

Aturan praktis: Google mengindeks URL canonical (AMP diperlakukan sebagai duplikat), jadi letakkan data terstruktur pada kedua versi, masukkan hanya URL canonical ke sitemap, dan biarkan rel="amphtml" menangani penemuan AMP. Google mendokumentasikan pasangan rel="amphtml" / rel="canonical" ini secara spesifik—lihat Tentang AMP: membuat Anda konten discoverable untuk hubungan referensi jika penyiapan Anda tidak cocok dengan kedua kasus di atas.

Tantangan analytics AMP

Kerumitan pelacakan AMP adalah biaya operasional yang nyata, bukan sekadar teori:

• Masalah referral. Traffic dari halaman AMP yang di-cache secara historis muncul sebagai referral dari cdn.ampproject.org, bukan dari penelusuran organik—solusinya adalah mengecualikan domain itu dari referral.
• Fragmentasi sesi. Perpindahan dari halaman AMP yang di-cache ke halaman non-AMP Anda secara default memulai sesi baru. AMP Linker (meneruskan Client ID melalui parameter URL amp_id= melintasi batas cache-ke-situs) menyatukan keduanya.
• GTM untuk AMP memakai komponen amp-analytics—penyiapannya lebih rumit daripada GTM standar dan fiturnya lebih sedikit.
• GA4 memperoleh dukungan AMP native pada Juni 2024; sebelumnya, pengukuran AMP banyak bergantung pada implementasi komunitas.

Saat Search Engine Land menonaktifkan AMP, “a clearer picture dari mereka audience analytics” (terjemahan) “gambaran analytics audiens mereka yang lebih jelas” adalah salah satu manfaat yang mereka laporkan—jadi ini memang titik masalah yang sudah dikenal.

Permukaan AMP lainnya (agar tidak tercampur)

• Web Stories (diluncurkan sebagai AMP Stories pada 2018 dan berganti nama menjadi Google Web Stories pada 2020) adalah format cerita visual yang dapat diketuk dan dibangun di atas AMP. Format ini muncul di Penelusuran, Discover, dan Images, serta berbeda dari artikel AMP standar.
• AMP untuk Email menghadirkan konten interaktif (formulir, carousel, data real-time) ke Gmail dan beberapa klien lainnya. Ini adalah fitur email, bukan fitur penelusuran-SEO—cukup ketahui bahwa fitur ini ada; dampaknya tidak relevan bagi peringkat.

Bing dan AMP

Bing bergabung dalam upaya sumber terbuka AMP pada September 2016 dan sempat menjalankan viewer serta cache AMP sendiri, lengkap dengan tampilan ikon petirnya. Namun, menurut Bing, AMP tidak memengaruhi algoritme peringkat mereka dengan cara apa pun, dan dukungan AMP di Bing kini sebagian besar bersifat historis—tidak ada carousel berita saat ini yang mensyaratkan AMP dan tidak ada pelaporan AMP yang menonjol di Bing Webmaster Tools. Dalam praktiknya, sikap Bing mencerminkan Google: opsional, tanpa peningkatan peringkat.

Haruskah Anda masih menggunakan AMP?

Situasi ketika mempertahankan AMP dapat masuk akal:

• Penerbit berita/media yang sudah memakai AMP, dengan tingkat error Search Console rendah dan biaya perpindahan tinggi.
• Situs dengan konten sederhana yang kebetulan paling mudah mencapai Core Web Vitals yang baik melalui AMP.

Situasi untuk menghapusnya:

• Situs perusahaan besar dengan fungsi yang tidak dapat didukung AMP—persis seperti kasus yang saya bahas di SMX West: bagi perusahaan besar dengan struktur kompleks, AMP bisa terlalu sulit diterapkan dan membawa risiko berlebihan, sementara ada alasan bisnis nyata untuk mempertahankan elemen situs yang tidak diizinkan AMP.
• Situs yang menjalankan AMP hanya demi badge Top Stories yang sudah tidak ada.
• Situs yang memerlukan kejelasan analytics—kerumitan pelacakan AMP adalah biaya nyata.
• Situs yang sudah memenuhi Core Web Vitals—tidak ada manfaat tambahan dari AMP.
• Situs apa pun yang penulisan ulang URL oleh AMP menimbulkan masalah merek atau atribusi.

Jawaban jujur untuk 2026: AMP bersifat opsional dan makin ditinggalkan. Untuk proyek baru, jangan menerapkannya. Untuk proyek yang sudah ada, evaluasi biaya operasional dibandingkan manfaat yang tersisa.

Cara menghapus AMP (jika Anda memutuskan demikian)

1. Hapus tag rel="amphtml" dari halaman canonical (non-AMP).
2. Alihkan dengan 301 URL AMP ke padanan canonical non-AMP.
3. Berhenti memantau laporan status AMP di Search Console.
4. Pastikan error AMP berangsur hilang dari Search Console dalam beberapa minggu berikutnya.

Jika dilakukan dengan benar, halaman canonical tetap diindeks dan diberi peringkat. Penerbit besar, termasuk Search Engine Land, telah menghapus AMP dengan gangguan traffic yang minimal.

Mitos yang layak diluruskan

• “AMP memberikan a ranking boost.” (terjemahan) “AMP memberi peningkatan peringkat.” Itu tidak benar. AMP bukan faktor peringkat; yang penting adalah kecepatan, dan AMP hanyalah salah satu cara untuk mencapainya.
• “Anda perlu AMP untuk Top Stories.” (terjemahan) “Anda memerlukan AMP untuk Top Stories.” Salah sejak Juni 2021.
• “AMP adalah selalu lebih cepat daripada a regular halaman.” (terjemahan) “AMP selalu lebih cepat daripada halaman biasa.” Tidak—keunggulannya berasal dari Google yang melakukan prerender salinan cache. Halaman non-AMP yang cepat dapat mengalahkan halaman AMP yang lambat.
• “AMP URLs adalah Anda URLs.” (terjemahan) “URL AMP adalah URL Anda.” Hanya dengan Signed Exchange (khusus Chrome); Viewer bawaan menampilkan google.com/amp/s/….
• “Removing AMP akan tank traffic.” (terjemahan) “Menghapus AMP akan menjatuhkan traffic.” Tangani canonical dan pengalihan dengan benar; dampaknya biasanya minimal.

Untuk sinyal performa yang memang penting sekarang, lihat Core Web Vitals dan cluster Web Performance yang lebih luas.

Ringkasan AI

Ringkasan singkat versi Advanced:

• AMP = Accelerated Mobile Halaman, kerangka kerja sumber terbuka Google yang diluncurkan pada 2015 (tersedia di Google Search sejak Oktober 2015) untuk halaman seluler yang hampir seketika melalui HTML/CSS/JS terbatas dan prerendering dari Google AMP Cache.
• Tidak pernah menjadi faktor peringkat—Google menyatakannya secara eksplisit. Kecepatan penting; AMP adalah salah satu cara untuk mendapatkannya, bukan satu-satunya.
• Tidak lagi diperlukan untuk Top Stories sejak pembaruan Halaman Experience Juni 2021— Core Web Vitals menggantikannya, dan badge AMP dihapus dari hasil.
• Penyajian: AMP yang di-cache biasanya muncul di bawah google.com/amp/s/…; Signed Exchange (SXG) dapat menyajikannya di bawah URL Anda sendiri, tetapi khusus Chrome (tanda tangan maksimal 7 hari, tanpa carousel, dan memerlukan packager).
• Pasangan canonical: halaman non-AMP menjadi canonical untuk dirinya sendiri dan membawa rel="amphtml"; halaman AMP mengarahkan balik dengan rel="canonical". Google mengindeks canonical; letakkan data terstruktur pada kedua versi; sitemap hanya mencantumkan URL canonical.
• Analytics adalah biaya sebenarnya: masalah referral cdn.ampproject.org, fragmentasi sesi (diperbaiki dengan AMP Linker / amp_id=), dan GTM untuk AMP yang rumit. GA4 menambahkan dukungan AMP native pada Juni 2024.
• Permukaan yang berbeda: Web Stories (AMP Stories, berganti nama pada 2020) dan AMP untuk Email— keduanya bukan AMP artikel untuk penelusuran.
• Bing: bergabung dengan AMP pada 2016, tetapi AMP tidak pernah memengaruhi peringkat Bing; dukungannya kini sebagian besar bersifat historis.
• Keputusan: opsional dan makin ditinggalkan. Jangan membangun AMP baru; hapus AMP (hapus rel="amphtml", alihkan URL AMP dengan 301) ketika biaya operasional melampaui manfaat yang kian menyusut.

Dokumentasi resmi

Dokumentasi sumber utama dari mesin pencari dan proyek AMP.

Google

• Tentang AMP —cara Google menyajikan AMP (Viewer versus Signed Exchange), baris “not a ranking factor” (terjemahan) “bukan faktor peringkat”, dan catatan bahwa cache tidak digunakan di desktop.
• Validasi halaman AMP —AMP Test, Rich Hasil Test, dan laporan status AMP di Search Console.
• Rincian pembaruan pengalaman halaman (April 2021) —pengumuman bahwa AMP tidak lagi diperlukan untuk Top Stories.
• Ikhtisar Google AMP Cache dan Format URL AMP Cache —cara cache menyimpan dan membentuk alamat halaman AMP.
• Apa yang ada di URL AMP? —mengapa URL Viewer diperlukan untuk prerendering.
• Signed Exchanges (SXG) —menyajikan AMP di bawah URL Anda sendiri.
• AMP untuk Email —kasus penggunaan email yang terpisah.
• Pengukuran AMP di GA4 dan Penyatuan sesi AMP —rincian analytics.

Proyek AMP

• Bagaimana AMP berfungsi —penjelasan proyek tentang batasan dan prerendering.
• Serve AMP menggunakan Signed Exchanges —panduan implementasinya.

Bing / Microsoft

• Aplikasi Bing bergabung dengan upaya AMP sumber terbuka (September 2016) —keterlibatan Bing dalam AMP.

Kutipan dari sumber

Pernyataan resmi dari Google dan Bing. Setiap tautan adalah deep link yang melompat ke bagian yang dikutip pada halaman sumber jika dukungan tersebut tersedia.

Google—AMP bukan faktor peringkat

• “AMP itself isn’t a ranking factor.” (terjemahan) “AMP sendiri bukan faktor peringkat.” — Dokumentasi Google Search Central. Lompat ke kutipan

Google—AMP tidak lagi diperlukan untuk Top Stories

• “using the AMP format is no longer required” (terjemahan) “menggunakan format AMP tidak lagi diwajibkan” untuk carousel Top Stories. Lompat ke kutipan

Google—Signed Exchange diprioritaskan daripada Viewer

• Google “prioritizes signed exchange over AMP Viewer when supported.” (terjemahan) “memprioritaskan signed exchange daripada AMP Viewer jika didukung.” Lompat ke kutipan

Google—AMP desktop tidak disajikan dari cache

• “Desktop AMP pages are not currently served from Google AMP Cache; canonical AMP pages behave as standard results.” (terjemahan) “Halaman AMP desktop saat ini tidak disajikan dari Google AMP Cache; halaman AMP canonical berperilaku sebagai hasil standar.” Lompat ke kutipan

Bing—AMP bukan faktor peringkat Bing

• “AMP does not impact our ranking algorithms in any way.” (terjemahan) “AMP tidak memengaruhi algoritme peringkat kami dengan cara apa pun.”—manajer teknik grup Bing pada saat AMP diluncurkan. Baca liputannya

Pertahankan AMP, hapus, atau hindari?

Sedang mempertimbangkan AMP untuk proyek baru? Jangan menambahkannya demi SEO. AMP bukan faktor peringkat dan tidak lagi diperlukan untuk Top Stories. Bangun situs canonical agar memenuhi persyaratan performa dan publikasinya secara langsung.

Sudah mengoperasikan halaman AMP? Lanjutkan hanya jika versi AMP masih memberikan manfaat bisnis atau penyajian yang terukur dan nilainya melebihi biaya memelihara implementasi kedua.

• AMP stabil, murah, dan benar-benar berguna: Pertahankan, tetapi audit pasangan canonical, validasi, analytics, dan kesetaraan konten.
• AMP hanya ada karena persyaratan Top Stories lama: Rencanakan penghapusannya.
• AMP menimbulkan masalah analytics, fitur, merek, atau pemeliharaan: Hapus dengan pengalihan per URL ke padanan canonical.
• Halaman canonical belum memenuhi kebutuhan performa: Perbaiki itu terlebih dahulu, lalu lakukan migrasi; jangan menghapus versi yang masih berfungsi tanpa pengganti.

Checklist pemeliharaan dan penghapusan AMP

Jika AMP dipertahankan

• Setiap halaman canonical menunjuk ke halaman AMP pasangannya melalui rel="amphtml".
• Setiap halaman AMP mengarahkan canonical kembali ke URL non-AMP yang sesuai.
• Konten dan data terstruktur tetap setara di kedua versi.
• Dokumen AMP tervalidasi setelah perubahan template, komponen, dan iklan.
• Analytics mempertahankan atribusi dan sesi saat navigasi dari cache ke situs.
• Hanya URL canonical yang muncul di sitemap XML.

Jika AMP dihapus

• Pastikan halaman canonical memuat konten lengkap dan lulus pemeriksaan penerimaan performa tim.
• Hapus rel="amphtml" dari halaman canonical.
• Petakan setiap URL AMP ke padanan canonical yang tepat melalui pengalihan permanen.
• Uji ulang canonical, data terstruktur, tautan internal, dan analytics pada target.
• Pantau Search Console saat laporan AMP menghilang dan URL canonical dirayapi ulang.

Kesalahan AMP yang harus dihindari

Mempertahankan AMP demi peningkatan peringkat yang tidak ada

AMP tidak pernah menjadi faktor peringkat dan sejak 2021 tidak diwajibkan untuk Top Stories. Pertahankan AMP hanya untuk manfaat operasional yang masih ada dan dapat diukur.

Menerbitkan dua versi yang makin berbeda

Halaman AMP dengan salinan yang lebih tipis, data terstruktur yang hilang, atau ajakan bertindak yang berbeda menimbulkan masalah kesetaraan dan pemeliharaan. Gunakan satu sumber konten, lalu validasi kedua output.

Menghapus AMP tanpa pengalihan tingkat URL

Menghapus endpoint AMP atau mengarahkan semuanya ke beranda memutus hubungan URL yang sudah ditetapkan. Alihkan setiap URL AMP ke halaman canonical yang sesuai.

Menyatakan berhasil hanya karena dokumen tervalidasi

Validasi membuktikan kesesuaian dengan AMP, bukan kesinambungan analytics, kebenaran canonical, kesetaraan konten, atau hasil pengguna yang baik. Uji seluruh jalur penyajian.

Lembar contekan AMP

Fakta yang menyelesaikan sebagian besar perdebatan

Pasangan canonical

Sitemap / data terstruktur: sitemap hanya mencantumkan URL canonical; letakkan data terstruktur pada kedua versi.

Fakta singkat penyajian dan analytics

• AMP yang di-cache biasanya disajikan di bawah cdn.ampproject.org / google.com/amp/s/….
• SXG = URL Anda di bilah alamat, khusus Chrome, tanda tangan maksimal 7 hari, tanpa carousel.
• Kecualikan cdn.ampproject.org sebagai referral; gunakan AMP Linker (amp_id=) untuk menyatukan sesi.
• Dukungan AMP native GA4: Juni 2024.

Menghapus AMP

1. Hapus rel="amphtml" dari halaman canonical → 2. 301 URL AMP ke canonical →
2. hentikan pemantauan AMP di GSC → 4. pastikan error menghilang.

Validasi: AMP Test (search.google.com/test/amp), Rich Hasil Test, dan laporan status AMP GSC.

Perintah audit AMP

Menemukan hubungan AMP dalam ekspor crawl

Gunakan regular expression ini pada ekstraksi kustom crawler terhadap sumber HTML:

<link\s+[^>]*rel=["'](?:amphtml|canonical)["'][^>]*href=["']([^"']+)["'][^>]*>

Grup tangkapan 1 mengembalikan URL AMP atau canonical yang tertaut. Tinjau pasangan hasil ekstraksi untuk mencari pemetaan yang hilang, lintas domain, atau banyak-ke-satu.

Memeriksa pengalihan AMP saat penghapusan

Jalankan di terminal dan ganti URL contoh:

curl -sSIL https://example.com/article/amp/

Respons pertama seharusnya berupa pengalihan permanen dan tujuan akhirnya harus tepat ke artikel canonical, tanpa rantai yang sebenarnya dapat dihindari.

Menginventarisasi tautan AMP dalam dokumen saat ini

Jalankan ini di Console Chrome DevTools pada halaman canonical atau AMP:

[...document.querySelectorAll('link[rel="amphtml"], link[rel="canonical"]')].map(link => ({ rel: link.rel, href: link.href }))

Alat untuk memelihara atau menghapus AMP

• AMP Validator: Periksa apakah dokumen yang dipublikasikan mematuhi aturan markup AMP setelah perubahan template dan komponen.
• Search Console URL Inspection: Bandingkan canonical yang diindeks dan output yang dirender untuk URL canonical dan AMP yang mewakili.
• Pelaporan status AMP Search Console: Gunakan saat AMP masih diterapkan untuk menemukan kegagalan validitas pada seluruh template, lalu harapkan inventaris menurun setelah penghapusan yang direncanakan.
• PageSpeed Insights: Pastikan pengganti canonical memenuhi sasaran performa yang sebelumnya dilayani AMP; uji URL canonical, bukan hanya salinan AMP yang di-cache.
• Crawler dengan ekstraksi kustom: Inventaris pasangan amphtml/canonical dan pastikan setiap URL AMP yang dipensiunkan dialihkan ke canonical yang sesuai.

Memvalidasi perubahan AMP

Menguji pasangan canonical setelah rilis template AMP

Uji yang dijalankan: Crawl pasangan yang mewakili, lalu ekstrak tautan amphtml dan canonical. Hasil yang diharapkan: Canonical menunjuk ke satu URL AMP yang cocok dan halaman AMP mengarah kembali ke canonical tersebut. Interpretasi kegagalan: Sinyal penemuan atau konsolidasi rusak. Jendela pemantauan: Segera. Pemicu rollback: Muncul pemetaan yang hilang, menyilang, atau banyak-ke-satu.

Menguji pengalihan penghapusan AMP

Uji yang dijalankan: Minta sampel dari setiap pola URL AMP dengan mengikuti pengalihan dinonaktifkan, lalu diaktifkan. Hasil yang diharapkan: Satu lompatan permanen ke padanan canonical yang tepat dan dapat diakses. Interpretasi kegagalan: Peta migrasi tidak lengkap atau berantai. Jendela pemantauan: Segera setelah deploy dan selama perayapan ulang. Pemicu rollback: URL AMP mana pun error, berputar, atau mendarat di halaman umum.

Menguji pengalaman pengganti canonical

Uji yang dijalankan: Jalankan target canonical melalui PageSpeed Insights dan QA analytics. Hasil yang diharapkan: Pengganti memenuhi baseline performa seluler yang ditetapkan tim dan mempertahankan pengukuran yang diharapkan. Interpretasi kegagalan: AMP dihapus sebelum peran penyajian atau pelacakannya digantikan. Jendela pemantauan: Pemeriksaan lab segera; data lapangan selama jendela bergulir normalnya. Pemicu rollback: Regresi performa sistematis atau hilangnya pengukuran yang diperlukan setelah migrasi.

Uji diri: SEO AMP

Lima pertanyaan singkat tentang apa itu AMP, apa yang dilakukannya, dan posisinya sekarang. Pilih jawaban untuk masing-masing pertanyaan, lalu periksa hasilnya.

Sumber yang layak Anda baca

Tulisan saya

• Panduan Pemula untuk SEO Teknis —tempat performa seluler dan AMP berada dalam gambaran yang lebih besar.

Ceramah saya

• AMP: Bertindak atau mati?—ringkasan sesi SMX West 2018 (Search Engine Land) —pandangan “angry old man” (terjemahan) “orang tua yang pemarah” dari saya, yang berpendapat bahwa AMP mungkin bukan solusi yang tepat untuk setiap perusahaan, terutama perusahaan besar dengan struktur kompleks dan fungsi yang tidak dapat didukung AMP.

Resmi

• Google—Tentang AMP dan Validasi halaman AMP.
• Google—Rincian pembaruan pengalaman halaman (April 2021) —AMP tidak lagi diperlukan untuk Top Stories.

Dari industri

• Mengapa kami menonaktifkan halaman AMP di Search Engine Land —keputusan penerbit besar untuk menghentikan AMP.
• Apa yang terjadi ketika kami menonaktifkan AMP (Search Engine Land) —postmortem: gangguan traffic sangat kecil dan analytics audiens lebih jelas.
• Akankah penerbit meninggalkan AMP setelah tidak lagi diwajibkan untuk Top Stories? (Search Engine Land).
• Google AMP sudah mati! (Plausible Analytics) —sudut pandang “AMP adalah declining” (terjemahan) “AMP makin ditinggalkan”, serta konteks pengawasan antimonopoli di balik keputusan Google menghapus kewajiban tersebut.
• Google AMP dan SEO: Semua yang perlu Anda ketahui (Search Engine Journal) —panduan teknis, termasuk penanganan canonical.
• Kabar baik: Google tidak lagi mewajibkan penerbit menggunakan AMP (Itu Register) —liputan peralihan ke Core Web Vitals.

Video

• Google Search Central (YouTube) —seri Bagaimana Google Search Berfungsi dan penjelasan Martin Splitt tentang pengalaman halaman serta Core Web Vitals, yang membahas sinyal performa pengganti AMP untuk Top Stories. Channel

Log perubahan