Laporan status AMP

Laporan ini membantu Anda memperbaiki error yang mencegah halaman AMP muncul di hasil Google Penelusuran dengan fitur khusus AMP.

Tampilan tingkat teratas menunjukkan masalah kritis yang memengaruhi halaman AMP di situs Anda. Klik masalah tertentu untuk melihat halaman yang terpengaruh oleh masalah ini beserta detail masalahnya.

BUKA LAPORAN AMP

 

Laporan status AMP di Search Console - Pelatihan Google Search Console

 

Yang ada dalam laporan

Masalah kritis: Halaman yang terpengaruh oleh masalah AMP kritis tidak dapat ditampilkan di Google. Daftar masalah kritis yang ditemukan di situs Anda ditampilkan langsung di bawah diagram di halaman tingkat teratas dalam laporan AMP, dengan judul Penyebab halaman AMP tidak valid. Klik masalah dalam daftar untuk melihat halaman dengan masalah yang dipilih.

Masalah non-kritis (peringatan): Halaman AMP dengan masalah non-kritis masih dapat ditampilkan di Google jika tidak memiliki masalah kritis. Daftar masalah non-kritis yang ditemukan di situs Anda ditampilkan di bawah daftar masalah kritis di halaman tingkat teratas dalam laporan AMP, dengan judul Masalah non-kritis. Klik masalah dalam daftar untuk melihat halaman dengan masalah yang dipilih. Halaman AMP dengan peringatan mungkin tidak ditampilkan dengan semua fitur AMP yang memungkinkan (seperti yang ditampilkan di carousel Berita Utama). Dengan kata lain, halaman ini mungkin hanya ditampilkan di hasil penelusuran sebagai link biru biasa.

Status halaman (halaman valid dan tidak valid): Halaman AMP dapat berstatus valid atau tidak valid. Halaman AMP yang valid dapat ditampilkan di Google; halaman AMP yang tidak valid tidak dapat ditampilkan di Google. Jika memiliki masalah kritis, halaman dianggap tidak valid; jika hanya memiliki peringatan, atau tidak ada masalah sama sekali, maka halaman akan dianggap valid. Anda dapat melihat daftar halaman AMP yang valid dengan mengklik Lihat data tentang halaman AMP yang valid di bawah diagram di halaman tingkat teratas dalam laporan AMP.

Yang perlu diperhatikan

Anda harus menargetkan nilai berikut dalam laporan Anda:

Daftar URL yang terpengaruh hanyalah contoh. Tidak ada jaminan bahwa setiap URL yang terpengaruh oleh masalah tertentu akan ditampilkan. Laporan ini dibatasi maksimal 1.000 URL per masalah. Selain itu, mungkin ada halaman tambahan yang tidak terdeteksi atau terhitung karena alasan tertentu.

Laporan ini hanya dapat menampilkan 200 total masalah kritis + non-kritis. Jika situs Anda memiliki daftar masalah yang sangat panjang (baik ada instance aktif atau tidak), laporan hanya akan menampilkan 200 masalah yang dianggap paling penting.

Masalah AMP

Selain error khusus AMP standar, laporan ini dapat menampilkan masalah tambahan berikut (error dan peringatan).

Masalah AMP khusus Google
Masalah Deskripsi
Ketidakcocokan konten: Video tersemat tidak ada Halaman kanonis telah menyematkan video yang tidak ada di versi AMP. Biasanya sangat disarankan untuk menyertakan semua resource konten penting yang sama pada versi AMP seperti di halaman kanonis. Perlu diketahui bahwa video dideteksi oleh URL; jika Anda memiliki 2 URL berbeda yang mengarah ke video yang sama, peringatan ini akan muncul.
Ukuran gambar lebih kecil dari ukuran yang direkomendasikan Data terstruktur di AMP mengacu pada gambar yang lebih kecil dari ukuran yang direkomendasikan. Hal ini dapat mencegah halaman muncul dengan semua fitur yang terkait dengan AMP di Google Penelusuran, serta dapat mencegah kartu Discover Anda ditampilkan dengan gambar besar (menyebabkan penurunan traffic situs dan interaksi pengguna). Untuk memperbaikinya, gunakan gambar yang berukuran lebih besar sesuai dengan panduan kami.
Ketidakcocokan domain halaman AMP Halaman AMP dihosting di domain yang berbeda dari versi kanonisnya. Hal ini dapat membingungkan bagi penelusur versi seluler yang melihat 1 domain URL di hasil penelusuran dan domain URL yang berbeda saat mereka membuka halaman di pembaca AMP. (Tidak memengaruhi pengindeksan atau peringkat halaman.)
URL tidak ditemukan (404) URL AMP yang diminta tidak dapat ditemukan. Pelajari cara memperbaiki halaman 404.
Error server (5XX) Terjadi error server 5XX yang tidak ditentukan saat meminta halaman AMP. Pelajari error server lebih lanjut.
Diblokir oleh robots.txt URL AMP yang diminta diblokir oleh aturan robots.txt. Jika ini tidak sesuai dengan keinginan Anda, uji file robots.txt untuk aturan pemblokirannya, lalu ubah atau hapus aturan tersebut (atau minta developer web Anda untuk melakukannya).
Masalah crawl Terjadi error crawling yang tidak ditentukan untuk halaman AMP. Gunakan alat Inspeksi URL di URL AMP Anda untuk memecahkan masalah ini.
URL AMP mengarah ke halaman non-AMP Halaman kanonis mengarah ke AMP yang sebenarnya bukan halaman AMP. Pelajari cara halaman non-AMP mengarah ke halaman AMP.
URL AMP mengarah ke AMP yang berdiri sendiri Halaman kanonis mengarah ke AMP yang berdiri sendiri. Anda tidak dapat mengarah ke AMP yang berdiri sendiri sebagai versi AMP dari sebuah halaman. Pelajari cara mengarah ke halaman AMP dari halaman non-AMP.
URL ditandai 'noindex' AMP diblokir oleh perintah 'noindex'. Google tidak dapat mengindeks halaman yang diblokir oleh noindex; hapus perintah noindex, atau hapus referensi ke halaman yang diblokir.
Tanggal 'unavailable_after' untuk halaman ini telah lewat Halaman AMP memiliki perintah atau tag meta "available_after" yang telah lewat, yang menunjukkan bahwa halaman tersebut seharusnya tidak ditayangkan lagi. Anda harus mengubah tag ini ke tanggal mendatang, atau menghapusnya.
Kanonis mengarah ke URL yang tidak valid Halaman kanonis mengarah ke versi AMP menggunakan URL yang formatnya tidak valid. Pelajari cara mengarah ke versi AMP dengan benar.
Error kanonis amp-story

Halaman salah mengarah ke halaman amp-story sebagai versi AMP-nya. Hal ini tidak diizinkan karena, secara definisi, halaman amp-story berdiri sendiri: halaman tersebut harus mengarah ke halaman itu sendiri dengan tag <rel="canonical">, dan tidak dapat berfungsi sebagai versi AMP dari halaman lain.
Skrip modul dideklarasikan tanpa alternatif nomodule (atau sebaliknya) Anda menggunakan tag <script type="module"> tanpa tag <script nomodule async> yang cocok, atau sebaliknya. Tag ini harus digunakan dalam pasangan yang cocok agar browser yang memiliki atau tidak memiliki dukungan terhadap skrip modul dapat memberikan penanganan yang tepat.
URL tidak ada dalam tag HTML Tag HTML yang ditentukan mewajibkan atribut dengan URL valid yang panjangnya bukan nol, tetapi URL berupa string kosong. Berikan URL yang valid untuk atribut yang ditandai.
Atribut tidak ada atau salah, tetapi diwajibkan oleh atribut 'on' Atribut yang ditentukan bersifat wajib, tetapi salah atau tidak ada. Atribut ini diwajibkan karena Anda menentukan atribut "on" dalam tag yang sama.
Tag turunan <svg> ditemukan di luar blok <svg>. Anda menentukan tag di luar blok <svg> yang harus ditempatkan di dalam blok <svg>.
Halaman memuat beberapa versi skrip ekstensi yang sama Halaman memuat beberapa versi ekstensi AMP yang sama. Untuk memperbaikinya, hapus salah satu versi skrip.
Masalah pertukaran bertanda tangan

Laporan status AMP dan laporan inspeksi URL dapat menampilkan masalah untuk AMP yang menggunakan protokol pertukaran bertanda tangan.

Untuk melihat detail pertukaran bertanda tangan tentang suatu masalah

Anda dapat menemukan informasi tentang pertukaran bertanda tangan yang terkait dengan AMP di beberapa tempat:

  • Di Alat Inspeksi URL, klik masalah di bawah Detail versi AMP.
  • Pada Laporan status AMP, klik URL dalam tabel detail masalah.

Untuk mengetahui apakah AMP Anda menggunakan Signed HTTP Exchange

Untuk mengetahui apakah Google telah mendeteksi adanya header atau payload pertukaran bertanda tangan untuk AMP Anda:

  1. Periksa URL AMP (baik menggunakan Alat Inspeksi URL untuk memeriksa URL tertentu maupun mengklik ikon periksa di samping URL dalam tabel detail masalah pada Laporan status AMP).
  2. Klik Lihat halaman yang di-crawl di halaman hasil untuk membuka panel samping yang memuat informasi selengkapnya.
  3. Klik tab Info Lainnya.
  4. Di bawah label Pertukaran bertanda tangan, Anda akan melihat status yang menunjukkan apakah Google telah mendeteksi adanya komponen pertukaran bertanda tangan untuk AMP tersebut.

Daftar masalah pertukaran bertanda tangan

Masalah berikut ini dapat terjadi apabila AMP Anda menggunakan protokol pertukaran bertanda tangan.

Pertukaran bertanda tangan tidak valid

Respons HTTP berupa pertukaran bertanda tangan yang tidak memenuhi persyaratan Google AMP Cache. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Error ini dapat terjadi karena beberapa alasan, termasuk:

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Payload pertukaran bertanda tangan mengalami error penguraian

Respons HTTP berupa pertukaran bertanda tangan yang “payload”-nya (isinya) tidak memenuhi persyaratan Google AMP Cache. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Coba langkah berikut untuk menemukan dan memperbaiki error:

  • Pastikan bahwa HTML tidak memuat encoding UTF-8 yang tidak valid. Untuk $URL yang mengalami error, jalankan curl $URL | iconv -f UTF-8 -t UTF-8 >/dev/null, lalu periksa apakah ada pesan error seperti "urutan input ilegal". Jika ada, pastikan dokumen sudah dienkode dengan benar menggunakan UTF-8. Dua sumber umum karakter multibyte adalah teks non-Inggris dan spasi.
  • Pastikan bahwa HTML tidak memuat karakter U+0000 NULL atau Unicode yang menyebabkan error penguraian HTML.
  • Pastikan bahwa HTML tidak berubah setelah memanggil transform -config NONE. Ada dua alasan umum untuk perubahan ini:

Header 'header_name' untuk payload Signed HTTP Exchange memiliki nilai yang tidak valid

Respons HTTP berupa pertukaran bertanda tangan yang memuat header respons bertanda tangan yang tidak memenuhi salah satu persyaratan Google AMP Cache. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Header wajib 'header_name' untuk payload Signed HTTP Exchange tidak ada

Respons HTTP berupa pertukaran bertanda tangan yang tidak memiliki header tersebut, yang diwajibkan oleh spesifikasi pertukaran bertanda tangan maupun persyaratan Google AMP Cache. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Header tanda tangan untuk Signed HTTP Exchange tidak dapat diuraikan

Respons HTTP berupa pertukaran bertanda tangan yang memuat header tanda tangan yang tidak dibentuk dengan baik sesuai spesifikasi pertukaran bertanda tangan. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Parameter 'parameter_name' dalam header tanda tangan pertukaran bertanda tangan tidak valid

Respons HTTP berupa pertukaran bertanda tangan yang header tanda tangannya memiliki nilai salah untuk parameter tertentu, seperti yang diwajibkan oleh spesifikasi pertukaran bertanda tangan. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Tanggal untuk pertukaran bertanda tangan tidak valid

Respons HTTP berupa pertukaran bertanda tangan yang header tanda tangannya memiliki nilai salah untuk parameter tanggal atau berakhir, seperti yang diwajibkan oleh spesifikasi pertukaran bertanda tangan atau persyaratan Google AMP Cache. (Khususnya, tanda tangan harus valid pada saat diambil, dan setidaknya 4 hari setelahnya.) Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika Anda menggunakan AMP Packager, hal ini dapat terjadi karena beberapa alasan:

  • Pastikan reverse-proxy front-end Anda tidak menyimpan respons pertukaran bertanda tangan terlalu lama dalam cache. Buat beberapa permintaan untuk halaman dengan curl -H 'Accept: application/signed-exchange;v=b3' -H 'AMP-Cache-Transform: any' dan cari "date=" dalam setiap respons; pastikan bahwa angka berikutnya selalu berbeda.
  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika Anda sudah melakukan semua hal di atas, mungkin terdapat bug dalam AMP Packager; silakan laporkan bug.

Rantai sertifikat yang direferensikan oleh 'cert-url' Signed HTTP Exchange tidak dapat diuraikan

Respons HTTP berupa pertukaran bertanda tangan dengan cert-url yang tidak terbentuk dengan baik sesuai spesifikasi pertukaran bertanda tangan. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika sudah, silakan laporkan bug.

Rantai sertifikat yang direferensikan oleh 'cert-url' tidak valid untuk pertukaran bertanda tangan

Respons HTTP berupa pertukaran bertanda tangan dengan cert-url yang tidak valid menurut spesifikasi pertukaran bertanda tangan. Akibatnya, halaman akan disajikan kepada pengguna tanpa informasi apa pun dari tanda tangan tersebut.

Dampak terhadap situs Anda:

Halaman akan disajikan dalam AMP viewer dengan URL Google, bukan URL aslinya.

Langkah berikutnya:

Anda boleh memilih untuk tidak mengatasinya; halaman yang terdampak error ini masih akan ditampilkan dengan benar di AMP viewer. Jika ingin halaman ini ditampilkan dengan URL bertanda tangan miliknya, lanjutkan membaca.

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika Anda menggunakan AMP Packager, error ini dapat terjadi karena beberapa alasan. Beberapa hal yang perlu diperiksa:

  • Pastikan bahwa CertFile Anda tidak memuat daftar lengkap sertifikat leaf beserta perantara.
  • Pastikan bahwa AMP Packager tidak diluncurkan dengan tanda -development atau -invalidcert. Dalam mode produksi, AMP Packager akan memverifikasi beberapa aspek sertifikat.
  • Pastikan bahwa reverse-proxy frontend Anda tidak menyimpan URL /amppkg/cert/ dalam cache lebih lama dari waktu yang ditetapkan oleh max-age miliknya.
  • Pastikan bahwa reverse-proxy frontend Anda tidak mengubah header cache apa pun; hal ini dapat menyebabkan proxy upstream menyimpan rantai sertifikat ini terlalu lama dalam cache. Untuk melakukan pengujian, tentukan URL /amppkg/cert/ yang sesuai pada domain packager internal Anda, ambil URL tersebut beserta header respons (misalnya, dengan curl -i), lalu bandingkan header respons dengan yang ditampilkan oleh server frontend.
  • Pastikan bahwa sertifikat Anda berisi SCT, misalnya menggunakan alat openssl x509. Jika tidak, hubungi certificate authority Anda.
  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika Anda sudah melakukan semua hal di atas, mungkin terdapat bug dalam AMP Packager; silakan laporkan bug.

Pertukaran bertanda tangan tidak dapat diuraikan

Respons HTTP memiliki jenis konten application/signed-exchange;v=b3 , tetapi isi respons tidak dapat diekstrak. Hal ini mungkin dikarenakan persyaratan tingkat tinggi jenis tersebut tidak berhasil dipenuhi, atau payload-nya dienkode menggunakan Merkle secara tidak semestinya.

Dampak terhadap situs Anda:

Jika halaman memiliki halaman non-AMP yang terkait, Google Penelusuran akan mengindeksnya. Jika tidak, halaman mungkin tidak muncul sama sekali dalam Google Penelusuran.

Langkah berikutnya:

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika Anda menggunakan AMP Packager, hal ini dapat terjadi karena beberapa alasan:

  • Pastikan bahwa reverse-proxy front-end Anda tidak mengubah respons dari packager. Untuk URL yang mengalami error, tentukan URL /priv/doc yang terkait pada domain packager internal Anda, lalu uji menggunakan dump-signedexchange. Jika respons packager internal berupa pertukaran yang valid, tetapi respons front-end eksternalnya tidak demikian, kemungkinan terdapat error konfigurasi dalam front end.
  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika Anda sudah melakukan semua hal di atas, mungkin terdapat bug dalam AMP Packager; silakan laporkan bug.

URL untuk payload dalam tidak cocok dengan URL permintaan untuk pertukaran bertanda tangan

Respons HTTP berupa pertukaran bertanda tangan dengan fallbackUrl yang tidak cocok dengan URL permintaan; keduanya harus setara dalam setiap byte-nya. Akibatnya, Google Penelusuran tidak akan percaya bahwa respons tersebut mewakili URL permintaan.

Dampak terhadap situs Anda:

Jika halaman memiliki halaman non-AMP yang terkait, Google Penelusuran akan mengindeksnya. Jika tidak, halaman mungkin tidak muncul sama sekali dalam Google Penelusuran.

Langkah berikutnya:

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan. Solusi yang mungkin dilakukan meliputi mengubah URL halaman untuk menghindari bug dalam parser URL umum. Sebagai contoh, cobalah menghapus karakter percent-encoded atau reserved, atau encoding string kueri yang tidak biasa seperti ? tanpa parameter.

Jika Anda menggunakan AMP Packager, hal ini dapat terjadi karena beberapa alasan:

  • Pastikan bahwa reverse-proxy front-end Anda menulis ulang URL dengan benar. Masalah paling sering terjadi pada URL dengan karakter percent-encoded atau reserved. Sebagai contoh, nginx memiliki masalah dengan perintah penulisan ulangnya dan bentuk tanpa alur dari perintah proxy_pass miliknya. Untuk melakukan pengujian, kirim beberapa permintaan pengujian ke front end Anda, lalu bandingkan dengan URL yang dicatat dalam log oleh AMP Packager ke stdout miliknya.
  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika Anda sudah melakukan semua hal di atas, mungkin terdapat bug dalam AMP Packager; silakan laporkan bug.

Header 'header_name' untuk respons HTTP Signed HTTP Exchange memiliki nilai yang tidak valid

Respons HTTP memiliki jenis konten application/signed-exchange, tetapi header responsnya tidak valid dalam suatu keadaan lain. Misalnya, jenis konten mungkin kekurangan parameter v=b3. Akibatnya, format ini tidak dikenali oleh Google sehingga isi responsnya tidak dapat diekstraksi.

Dampak terhadap situs Anda:

Jika halaman memiliki halaman non-AMP yang terkait, Google Penelusuran akan mengindeksnya. Jika tidak, halaman mungkin tidak muncul sama sekali dalam Google Penelusuran.

Langkah berikutnya:

Jika Anda menggunakan penyedia layanan Signed HTTP Exchange, hubungi penyedia tersebut untuk mendapatkan bantuan.

Jika Anda menggunakan AMP Packager, hal ini dapat terjadi karena beberapa alasan:

  • Pastikan bahwa reverse-proxy front-end Anda tidak mengubah header jenis konten. Untuk URL yang mengalami error, tentukan URL /priv/doc yang sesuai pada domain packager internal Anda, lalu ambil URL tersebut beserta header respons (misalnya, dengan curl -i). Jika header antara respons packager internal dan respons frontend eksternal berbeda, error tersebut mungkin disebabkan oleh hal ini. Jika perbedaannya terdapat dalam header selain jenis konten, harap laporkan bug terkait dokumen bantuan ini untuk memperbarui daftar persyaratan.
  • Pastikan Anda menggunakan rilis terbaru AMP Packager.
  • Jika Anda sudah melakukan semua hal di atas, mungkin terdapat bug dalam AMP Packager; silakan laporkan bug.

Memprioritaskan dan memperbaiki masalah

  1. Lihat daftar masalah kritis untuk situs Anda di tabel Penyebab halaman AMP tidak valid.
  2. Analisis error Anda:
    • Lihat apakah ada peningkatan jumlah total error yang kebanyakan disebabkan oleh satu error: cari lonjakan yang sesuai untuk satu masalah dalam tabel.
    • Perbaiki error yang diakibatkan oleh penyebab umum terlebih dahulu (seperti template yang buruk), lalu perbaiki error yang unik untuk setiap halaman.
  3. Perbaiki error: klik baris dalam tabel untuk melihat halaman detail error:
    1. Halaman detail mencakup contoh URL yang terpengaruh. Daftar dibatasi maksimal 1.000 baris, dan mungkin tidak mencakup instance error ini yang baru saja ditemukan, atau halaman yang belum di-crawl ulang sejak error muncul.
    2. Klik Pelajari lebih lanjut di samping masalah untuk mendapatkan dokumentasi resmi terkait error tersebut.
    3. Klik URL dalam tabel contoh URL untuk melihat masalah yang ditandai di kode halaman.
    4. Klik ikon periksa  untuk menjalankan pengujian mendetail terhadap halaman tertentu. Pengujian ini akan mengidentifikasi semua error (bukan hanya masalah saat ini) dan memberikan penjelajah kode yang menandai error dan menampilkan informasi selengkapnya. Jika baru-baru ini halaman belum di-crawl ulang, Anda akan melihat masalah untuk halaman yang diindeks, bukan untuk halaman aktif. Jika demikian, Anda dapat meminta pengindeksan untuk halaman tersebut.
    5. Perbaiki semua instance masalah di situs, uji perbaikan, dan pastikan bahwa perbaikan telah diterapkan di web.
  4. Setelah Anda memperbaiki semua instance, kembali ke halaman detail masalah, lalu klik tombol Validasi Perbaikan untuk memulai proses validasi. Proses ini tidak langsung dilakukan. Lihat Tentang validasi untuk memahami proses validasi.
  5. Lanjutkan perbaikan error.
  6. Jika total halaman yang valid dan tidak valid jauh lebih rendah daripada jumlah halaman AMP di situs Anda, lihat Memecahkan masalah halaman AMP tidak ada.
  7. Jika semua error kritis telah diperbaiki, sebaiknya perbaiki masalah non-kritis. Beberapa masalah non-kritis (misalnya, menggunakan fitur yang tidak digunakan lagi) dapat menjadi kritis pada masa mendatang.

Membagikan laporan

Anda dapat membagikan detail masalah di laporan cakupan atau penyempurnaan dengan mengklik tombol Bagikan di halaman. Link ini memberikan akses hanya ke halaman detail masalah saat ini, juga halaman histori validasi untuk masalah ini, kepada siapa pun yang memiliki link. Link tidak memberikan akses ke halaman lain resource Anda atau memungkinkan pengguna bersama melakukan tindakan apa pun di properti atau akun Anda. Anda dapat mencabut link kapan saja dengan menonaktifkan fitur berbagi untuk halaman ini.

Mengekspor data laporan

Banyak laporan yang menyediakan tombol ekspor untuk mengekspor data laporan. Data diagram dan tabel diekspor. Nilai yang ditampilkan sebagai ~ atau - dalam laporan (tidak tersedia/bukan angka) akan bernilai nol dalam data hasil download.

Memecahkan masalah halaman AMP tidak ada

Jika jumlah halaman AMP (valid + tidak valid) dalam laporan lebih rendah daripada jumlah halaman AMP di situs Anda, berikut ini beberapa kemungkinan alasannya:

  • Konfirmasi apakah halaman non-AMP kanonis ditautkan ke halaman AMP dengan benar.
  • Konfirmasi bahwa halaman AMP atau kanonis Anda tidak dibatasi oleh robots.txt atau noindex, atau dilindungi oleh persyaratan login.
  • Periksa URL halaman kanonis untuk AMP Anda guna melihat apakah URL tersebut diindeks.
  • Google memerlukan waktu beberapa hari untuk menemukan dan meng-crawl halaman yang tidak ada, bergantung pada cara Anda memberi tahu Google tentang halaman baru.
  • Beberapa halaman AMP yang valid mungkin tidak disertakan dalam laporan ini, meskipun halaman tersebut mungkin tercantum dalam Laporan Pengindeksan Halaman. Hal ini karena Laporan Pengindeksan Halaman harus lebih komprehensif agar dapat membantu Anda men-debug masalah pengindeksan pada laporan. Sementara itu, laporan Status AMP kemungkinan mencakup lebih sedikit halaman, tetapi lebih relevan dan mendetail, untuk membantu Anda men-debug masalah AMP tertentu di situs. Untuk mengonfirmasi apakah halaman AMP diindeks atau tidak, gunakan Alat Inspeksi URL, yang akan memberikan jawaban pasti.
Memvalidasi perbaikan

Setelah memperbaiki semua instance masalah tertentu di situs, Anda dapat meminta Google untuk mengonfirmasi perubahan. Jika semua instance yang diketahui telah diperbaiki, jumlah masalah akan menjadi nol dalam tabel masalah dan turun ke bagian bawah tabel.

Mengapa melakukan validasi

Memberi tahu Google bahwa Anda telah memperbaiki semua masalah dalam status atau kategori masalah tertentu memiliki manfaat sebagai berikut:

  • Anda akan mendapatkan email saat Google telah mengonfirmasi perbaikan Anda di semua URL, atau sebaliknya, jika Google telah menemukan sisa instance dari masalah tersebut.
  • Anda dapat melacak progres Google dalam mengonfirmasi perbaikan, dan melihat log dari semua halaman yang dimasukkan dalam antrean untuk diperiksa, serta status perbaikan setiap URL.

Bisa jadi langkah Anda untuk memperbaiki dan memvalidasi masalah tertentu di situs tidak selalu tepat: misalnya, URL yang diblokir oleh robots.txt mungkin memang sengaja diblokir. Gunakan penilaian Anda saat memutuskan apakah akan mengatasi masalah tertentu atau tidak.

Anda juga dapat memperbaiki masalah tanpa melakukan validasi; Google memperbarui jumlah instance Anda setiap kali meng-crawl halaman yang memiliki masalah umum, baik Anda meminta validasi perbaikan secara eksplisit ataupun tidak.

Tips pro: Validasi perbaikan Anda berdasarkan peta situs
Untuk mempercepat permintaan perbaikan, buat dan kirim peta situs yang hanya berisi halaman Anda yang paling penting, lalu filter laporan berdasarkan peta situs tersebut sebelum meminta validasi perbaikan. Permintaan validasi terhadap subkumpulan URL yang terpengaruh dapat diselesaikan lebih cepat daripada permintaan yang menyertakan semua URL yang terpengaruh di situs Anda.

Memulai validasi

Untuk memberi tahu Search Console bahwa Anda telah memperbaiki masalah:

  1. Perbaiki semua instance masalah di situs Anda. Jika Anda melewatkan perbaikan, validasi akan berhenti saat Google menemukan satu instance yang tersisa untuk masalah tersebut.
  2. Buka halaman detail masalah untuk masalah yang telah Anda perbaiki. Klik masalah dalam daftar masalah di laporan Anda.
    • ⚠️ Jika diterapkan filter ke peta situs tertentu dalam laporan, validasi hanya akan berlaku untuk item dalam peta situs pada saat Anda meminta validasi. Mungkin ini yang Anda inginkan, atau mungkin juga tidak. Perhatikan saja.
  3. Klik Validasi perbaikan. Jangan mengklik Validasi perbaikan lagi hingga validasi berhasil atau gagal. Detail selengkapnya tentang cara Google memeriksa perbaikan Anda.
  4. Anda dapat memantau progres validasi. Validasi biasanya berlangsung hingga sekitar dua minggu, tetapi dalam beberapa kasus dapat memerlukan waktu lebih lama, jadi harap bersabar. Anda akan menerima notifikasi saat validasi berhasil atau gagal.
  5. Jika validasi gagal, Anda dapat melihat URL mana yang menyebabkan validasi gagal dengan mengklik Lihat detail di halaman detail masalah. Perbaiki halaman ini, konfirmasi perbaikan Anda di semua URL dalam status Tertunda, dan mulai ulang validasi.

Kapan masalah dianggap sebagai "diperbaiki" untuk URL atau item?

Masalah ditandai sebagai diperbaiki untuk URL atau item saat salah satu ketentuan berikut terpenuhi:

  • Saat URL di-crawl dan masalahnya tidak ditemukan lagi di halaman. Untuk error tag AMP, hal ini dapat berarti bahwa Anda telah memperbaiki tag atau tag tersebut telah dihapus (jika tag tidak diperlukan). Selama upaya validasi, masalah akan diberi label Lulus.
  • Jika halaman tidak tersedia untuk Google dengan alasan apa pun (halaman dihapus, ditandai noindex, perlu autentikasi, dan sebagainya), masalah tersebut akan dianggap sebagai diperbaiki untuk URL tersebut. Selama upaya validasi, masalah akan dikategorikan dalam status validasi Lainnya.

Masa aktif masalah

Masa aktif masalah dimulai sejak pertama kali instance dari masalah tersebut terdeteksi di situs, hingga 90 hari setelah instance terakhir ditandai sebagai sudah tidak ada di situs. Jika sembilan puluh hari berlalu tanpa ada pengulangan, masalah akan dihapus dari tabel masalah.

Tanggal pertama kali terdeteksinya masalah adalah waktu pertama kali masalah terdeteksi selama masa aktif masalah, dan tidak mengalami perubahan. Jadi:

  • Jika semua instance masalah telah diperbaiki, tetapi ada instance masalah baru yang muncul 15 hari kemudian, masalah tersebut akan ditandai sebagai terbuka, dan tanggal pertama kali terdeteksi tetap menjadi tanggal aslinya.
  • Jika masalah yang sama terjadi 91 hari setelah instance terakhir diperbaiki, masalah sebelumnya akan ditutup, dan masalah ini dicatat sebagai masalah baru, dengan tanggal terdeteksi pertama kali ditetapkan ke tanggal deteksi baru.
Alur validasi

Berikut ini ringkasan proses validasi setelah Anda mengklik Validasi Perbaikan untuk masalah. Proses ini dapat memerlukan waktu beberapa hari atau bahkan lebih lama, dan Anda akan menerima pemberitahuan progres melalui email.

  1. Saat Anda mengklik Validasi Perbaikan, Search Console akan langsung memeriksa beberapa halaman.
    • Jika instance saat ini ada di salah satu halaman tersebut, validasi akan berakhir, dan status validasi tetap tidak berubah.
    • Jika halaman contoh tidak memiliki error saat ini, validasi akan dilanjutkan dengan status Dimulai. Jika validasi menemukan masalah lain yang tidak terkait, masalah tersebut akan dianggap sebagai jenis masalah lain dan validasi dilanjutkan.
  2. Search Console memproses daftar URL yang diketahui, yang terpengaruh oleh masalah ini. Antrean untuk crawling ulang hanya berisi URL dengan instance masalah yang diketahui, bukan keseluruhan situs. Search Console menyimpan catatan semua URL yang diperiksa di histori validasi, yang dapat dibuka di halaman detail masalah.
  3. Saat URL diperiksa:
    1. Jika masalah tidak ditemukan, status validasi instance berubah menjadi Lulus. Jika ini adalah instance pertama yang diperiksa setelah validasi dimulai, status validasi masalah berubah menjadi Terlihat bagus.
    2. Jika URL tidak lagi dapat dijangkau, status validasi instance berubah menjadi Lainnya (bukan merupakan status error).
    3. Jika instance masih ada, status masalah berubah menjadi Gagal dan validasi berakhir. Jika ini adalah halaman baru yang ditemukan oleh crawling normal, halaman ini akan dianggap sebagai instance lain dari masalah yang ada.
  4. Jika URL yang ada dalam antrean telah diperiksa untuk masalah ini dan masalah tersebut ternyata telah diperbaiki, status masalah akan berubah menjadi Lulus. Namun, meskipun semua instance telah diperbaiki, label tingkat keparahan masalah tidak berubah (Error atau Peringatan), hanya jumlah item yang terpengaruh (0).

Meskipun Anda tidak pernah mengklik Mulai validasi, Google dapat mendeteksi instance masalah yang telah diperbaiki. Jika Google mendeteksi bahwa semua instance masalah telah diperbaiki selama proses crawling reguler, jumlah masalah di laporan akan berubah menjadi 0.

Validasi ulang

⚠️ Tunggu siklus validasi selesai sebelum meminta siklus validasi lagi, meskipun jika Anda telah memperbaiki beberapa masalah selama siklus saat ini.

Untuk memulai ulang validasi yang gagal:

  1. Buka log validasi untuk validasi yang gagal: Buka halaman detail masalah untuk masalah yang gagal divalidasi, lalu klik Lihat detail.
  2. Klik Mulai validasi baru.
  3. Validasi akan dimulai ulang untuk semua URL yang ditandai sebagai Tertunda atau Gagal, serta instance baru dari masalah ini yang ditemukan melalui crawling normal sejak upaya validasi terakhir. URL yang ditandai sebagai Lulus atau Lainnya tidak diperiksa ulang.
  4. Validasi biasanya berlangsung hingga sekitar dua minggu, tetapi dalam beberapa kasus dapat memerlukan waktu lebih lama, jadi harap bersabar.

Melihat progres validasi

Untuk melihat progres permintaan validasi saat ini, atau histori permintaan terakhir jika validasi tidak sedang berlangsung:

  1. Buka halaman detail masalah untuk masalah tertentu. Klik baris masalah di halaman laporan utama untuk membuka halaman detail masalah.
  2. Klik Lihat detail untuk membuka halaman detail validasi untuk permintaan tersebut.
    • Status instance untuk setiap URL yang disertakan dalam permintaan akan ditampilkan di tabel.
    • Status instance berlaku untuk masalah tertentu yang sedang Anda periksa. Anda dapat memiliki satu masalah yang diberi label Lulus di halaman, tetapi masalah lainnya diberi label Gagal, Tertunda, atau Lainnya di halaman yang sama.
    • Dalam laporan AMP dan Laporan Pengindeksan Halaman, entri di halaman histori validasi dikelompokkan berdasarkan URL.
    • Dalam laporan Kegunaan Seluler dan Hasil Kaya, item dikelompokkan berdasarkan kombinasi URL + item data terstruktur (seperti yang ditentukan berdasarkan nilai Nama item).
Status permintaan validasi

Status validasi berikut berlaku untuk validasi masalah tertentu:

  • Belum dimulai: Satu atau beberapa instance masalah ini tidak pernah diajukan dalam permintaan validasi untuk masalah tersebut.
    Langkah berikutnya:
    1. Klik masalah untuk mempelajari detail error-nya. Periksa setiap halaman untuk melihat contoh error pada halaman aktif.
    2. Klik Pelajari lebih lanjut di halaman detail untuk melihat detail masalah.
    3. Klik contoh baris URL pada tabel untuk mendapatkan detail tentang error tertentu.
    4. Perbaiki halaman, lalu klik Validasi perbaikan untuk memulai validasi. Validasi biasanya berlangsung hingga sekitar dua minggu, tetapi dalam beberapa kasus dapat memerlukan waktu lebih lama, jadi harap bersabar.
  • Dimulai: Anda telah memulai upaya validasi dan belum ada sisa instance masalah yang ditemukan.
    Langkah berikutnya: Google akan mengirimkan notifikasi saat proses validasi berlangsung, yang memberi tahu Anda tindakan yang harus dilakukan, jika perlu.
  • Terlihat bagus: Anda telah memulai upaya validasi, dan semua instance masalah yang diperiksa telah diperbaiki.
    Langkah berikutnya: Tidak ada tindakan yang harus dilakukan, tetapi Google akan mengirimkan notifikasi saat proses validasi berlangsung, yang memberi tahu Anda tindakan yang harus dilakukan.
  • Lulus: Semua instance masalah yang diketahui sudah tidak ada (atau URL yang terpengaruh tidak tersedia lagi). Status ini muncul karena Anda telah mengklik Validasi perbaikan (jika instance menghilang tanpa adanya permintaan validasi, statusnya akan berubah menjadi T/A).
    Langkah berikutnya: Tidak ada lagi tindakan yang harus dilakukan.
  • T/A: Google menemukan bahwa masalah telah diperbaiki di semua URL, meskipun Anda belum pernah memulai upaya validasi.
    Langkah berikutnya: Tidak ada lagi tindakan yang harus dilakukan.
  • Gagal: Nilai minimum tertentu dari halaman masih berisi masalah ini, setelah Anda mengklik Validasi.
    Langkah berikutnya: Perbaiki masalah dan mulai ulang validasi.
Status validasi instance

Setelah validasi diminta, setiap instance masalah diberi salah satu status validasi berikut:

  • Tertunda: Menunggu validasi diproses. Terakhir kali Google memeriksanya, instance masalah ini sudah ada.
  • Lulus: [Tidak tersedia di semua laporan] Google telah memeriksa instance masalah dan instance tersebut sudah tidak ada lagi. Status ini hanya bisa didapatkan jika Anda secara eksplisit mengklik Validasi untuk instance masalah ini.
  • Gagal: Google memeriksa instance masalah, dan instance tersebut masih ada. Status ini hanya bisa didapatkan jika Anda secara eksplisit mengklik Validasi untuk instance masalah ini.
  • Lainnya: [Tidak tersedia di semua laporan] Google tidak dapat menjangkau URL yang menghosting instance tersebut, atau (untuk data terstruktur) tidak dapat lagi menemukan item di halaman. Dianggap setara dengan Lulus.

Perlu diketahui bahwa URL yang sama dapat memiliki status yang berbeda untuk masalah yang berbeda. Misalnya, jika sebuah halaman memiliki masalah X dan masalah Y, masalah X dapat memiliki status validasi Lulus dan masalah Y di halaman yang sama dapat memiliki status validasi Tertunda.

 

Masalah umum

Berikut adalah masalah umum pada Search Console. Anda tidak perlu melaporkannya kepada kami, tetapi kami mengharapkan masukan Anda terkait fitur atau masalah lain yang Anda temukan. Gunakan mekanisme Masukan yang ada pada menu navigasi.

  • Beberapa masalah memiliki nama panjang yang tidak mudah dipahami.
  • Mungkin terdapat keterlambatan antara saat masalah ditambahkan ke grafik dan saat ditambahkan ke tabel.

Apakah ini membantu?

Bagaimana cara meningkatkannya?

Perlu bantuan lain?

Coba langkah-langkah selanjutnya berikut:

Posting ke komunitas bantuan Dapatkan jawaban dari anggota komunitas
true
Baru mengenal Search Console?

Belum pernah menggunakan Search Console? Mulai di sini, baik Anda adalah pemula, pakar SEO, atau developer situs.

Telusuri
Hapus penelusuran
Tutup penelusuran
Menu utama
12610409023795408760
true
Pusat Bantuan Penelusuran
true
true
true
true
true
83844
false
false