Laporan status AMP

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

Tampilan tingkat atas menampilkan semua halaman AMP dengan masalah yang ditemukan oleh Google di situs Anda, yang dikelompokkan berdasarkan masalah. Klik masalah tertentu untuk melihat detail masalah, termasuk daftar contoh halaman yang terpengaruh oleh masalah tersebut, informasi tentang cara memperbaikinya, dan proses untuk memberi tahu Google tentang perbaikan yang Anda lakukan.

Untuk melihat diagram yang menampilkan pengaruh masalah dan perbaikan, buka halaman Status.

Mengapa ini disebut daftar contoh? Kami menampilkan sebanyak mungkin halaman yang terpengaruh berdasarkan error. Namun, maksimal hanya 1.000 URL yang dapat ditampilkan dalam tabel kami. Selain itu, mungkin ada halaman tambahan yang tidak terdeteksi atau terhitung karena beberapa alasan.

MEMBUKA LAPORAN AMP

 

Laporan status AMP di Search Console - Pelatihan Google Search Console

Yang harus dicari

Biasanya Anda akan melihat ini di laporan:

Daftar masalah AMP

Selain error khusus AMP standar, laporan tersebut dapat menampilkan masalah tambahan berikut ini (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.
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 boleh karena halaman amp-story, secara definisi, berdiri sendiri: harus mengarah ke halaman itu sendiri dengan tag <rel="canonical">, dan tidak dapat berfungsi sebagai versi AMP dari halaman lain.

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 mencari tahu apakah AMP Anda menggunakan pertukaran bertanda tangan

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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Error ini dapat terjadi karena beberapa alasan, termasuk:

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Error ini dapat terjadi karena beberapa alasan:

  • 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 pertukaran bertanda tangan 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 pertukaran bertanda tangan 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka untuk mendapatkan bantuan.

Jika menggunakan AMP Packager:

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

Header tanda tangan untuk pertukaran bertanda tangan 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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' pertukaran bertanda tangan 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 disajikan dengan URL bertanda tangan miliknya, silakan lanjutkan membaca.

Jika menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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 pertukaran bertanda tangan 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 menggunakan penyedia layanan pertukaran bertanda tangan, hubungi mereka 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. Pada halaman ringkasan AMP, filter peringatan dan fokus pada error terlebih dahulu. Secara default, masalah diurutkan berdasarkan kombinasi tingkat keparahan, status validasi, dan jumlah halaman yang terpengaruh; sebaiknya perbaiki masalah dalam urutan default ini. Perbaiki error yang disebabkan oleh penyebab umum terlebih dahulu (seperti template yang buruk), lalu perbaiki error yang terkait dengan setiap halaman.
  2. Cari tahu apakah peningkatan jumlah total error kebanyakan disebabkan oleh satu error: cari lonjakan yang terkait dalam satu masalah pada tabel.
  3. Lihat informasi di bawah tentang proses debug lonjakan dan halaman AMP yang tidak ada.
  4. Klik baris dalam tabel untuk melihat halaman detail error:
    1. Halaman detail mencakup contoh URL yang terpengaruh. Daftar ini tidak selalu lengkap karena dibatasi hanya untuk 1.000 baris, dan mungkin tidak mencakup instance yang baru ditemukan untuk error ini.
    2. Jika error-nya adalah error sintaks, klik Pelajari lebih lanjut untuk mendapatkan dokumentasi resmi terkait sintaks yang benar.
    3. Klik ikon periksa untuk menjalankan pengujian validitas terhadap halaman yang terpengaruh. Pengujian ini akan mengidentifikasi semua error (bukan hanya masalah saat ini) dan memberikan pengguna kode yang menandai error dan memberikan informasi selengkapnya. Ada kemungkinan bahwa error telah diperbaiki di halaman yang aktif, namun masih tercantum sebagai error karena belum di-crawl ulang; jika demikian, mintalah validasi setelah Anda memperbaiki semua instance masalah ini.
  5. Perbaiki semua instance masalah di situs, uji perbaikan, dan pastikan bahwa perbaikan telah diterapkan di web.
  6. Kembali ke halaman detail masalah dan klik tombol Validasi Perbaikan untuk memulai proses validasi. Proses ini tidak langsung dilakukan. Lihat Tentang validasi untuk memahami proses validasi ini.
  7. Lanjutkan perbaikan error.
  8. Jika semua error telah diperbaiki, hapus filter peringatan, lalu pertimbangkan untuk memperbaiki peringatan. Beberapa peringatan berisi markup data terstruktur opsional yang tidak ada, yang dapat memungkinkan fitur penelusuran baru untuk halaman dengan konten yang relevan.

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.

Lonjakan error

Tentukan apakah lonjakan disebabkan oleh sekelompok halaman yang tingkat keparahannya mengalami perubahan:

  1. Jika Anda melihat lonjakan, carilah penurunan yang sesuai pada status lainnya (error atau valid).
  2. Jika Anda menemukan penurunan yang sesuai, konfirmasi apakah penurunan tersebut berasal dari URL yang sama.
  3. Jika status URL berubah, cari tahu perubahan yang Anda lakukan yang menyebabkan hal tersebut.

Alasan paling umum terjadinya lonjakan error adalah penambahan error ke template yang digunakan oleh banyak halaman di situs Anda.

Memecahkan masalah halaman AMP tidak ada

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

  • Konfirmasikan apakah halaman non-AMP kanonis Anda sudah ditautkan dengan benar ke halaman AMP.
  • Pastikan halaman AMP atau halaman kanonis Anda tidak menggunakan robot atau noindex, atau dilindungi oleh persyaratan autentikasi atau login.
  • Periksa kehadiran halaman AMP dan kanonis Anda dalam indeks dengan menelusuri Google untuk URL halaman kanonis. Jika tidak tercantum, berarti halaman kanonis tidak diindeks.
  • Apakah halaman AMP/kanonis ditautkan oleh halaman lain? Apakah halaman tersebut tercantum di peta situs? Gunakan fitur Inspeksi URL di halaman kanonis untuk meminta pengindeksan halaman AMP dalam jumlah kecil, namun untuk halaman dalam jumlah besar, gunakan peta situs. (Anda hanya perlu mencantumkan kanonis di peta situs.) Pertimbangkan untuk menggunakan Laporan peta situs guna mengirimkan peta situs.
  • Google memerlukan waktu beberapa hari untuk menemukan dan meng-crawl halaman yang tidak ada, tergantung pada cara Anda memberi tahu Google tentang halaman baru tersebut.
  • Beberapa halaman AMP yang valid mungkin tidak disertakan dalam laporan ini, meskipun halaman tersebut mungkin tercantum dalam Laporan Cakupan Indeks. Hal ini karena laporan Cakupan Indeks harus lebih komprehensif agar dapat digunakan untuk membantu Anda mendebug masalah pengindeksan pada laporan, sementara laporan Status AMP kemungkinan mencakup lebih sedikit halaman, tetapi lebih relevan dan dengan detail yang lebih baik, untuk membantu mendebug masalah AMP tertentu di situs Anda. Untuk mengonfirmasi apakah halaman AMP diindeks atau tidak, gunakan fitur Inspeksi URL, yang akan memberikan jawaban pasti.

Memahami peringatan

Halaman AMP dengan peringatan diindeks dan dapat ditampilkan di hasil Google Penelusuran, namun mungkin tidak ditampilkan dengan semua fitur AMP yang memungkinkan (seperti yang ditampilkan dalam carousel Berita Utama). Dengan kata lain, halaman ini mungkin hanya ditampilkan sebagai hasil penelusuran link biasa berwarna biru.

Tentang validasi

Setelah memperbaiki semua instance masalah spesifik di situs, Anda dapat meminta Google memvalidasi perubahan. Jika semua instance yang diketahui sudah tidak ada, masalah akan ditandai sebagai diperbaiki pada tabel status dan dipindahkan ke bagian bawah tabel. Search Console memantau status validasi masalah secara keseluruhan, serta status setiap instance masalah. Jika semua instance masalah sudah tidak ada, masalah akan dianggap telah diperbaiki. (Untuk rekaman status aktual, lihat Status validasi masalah dan Status validasi instance.)

Selengkapnya tentang 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 90 hari berlalu tanpa ada perulangan, masalah akan dihapus dari histori laporan.

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, namun ada instance masalah yang baru terjadi 15 hari kemudian, masalah 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 pada "hari ini".

Alur validasi dasar

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

  1. Saat Anda mengklik Validasi Perbaikan, Search Console 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 bekerja melalui 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 rekaman semua URL yang diperiksa pada 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 dengan crawling normal, halaman ini akan dianggap sebagai instance lain dari masalah yang ada.
  4. Jika semua URL peringatan dan error telah diperiksa dan jumlah masalahnya adalah 0, status masalah akan berubah menjadi Lulus. Penting: Meskipun jumlah halaman yang terpengaruh berkurang hingga 0 dan status masalah berubah menjadi Lulus, label tingkat keparahan asli akan tetap ditampilkan (Error atau Peringatan).

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 crawl regulernya, status masalah akan berubah menjadi "T/A" pada laporan.

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, status masalah akan dianggap sebagai "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 dilakukan, masalah akan dianggap dalam status validasi "lainnya".

Validasi ulang

Saat Anda mengklik Validasi ulang untuk validasi yang gagal, validasi akan dimulai ulang untuk semua instance yang gagal, serta instance baru apa pun dari masalah ini yang ditemukan melalui crawling normal.

Anda harus menunggu siklus validasi selesai sebelum meminta siklus validasi lagi, meskipun Anda telah memperbaiki beberapa masalah selama siklus saat ini.

Instance yang telah lulus validasi (ditandai sebagai Lulus) atau tidak dapat dijangkau lagi (ditandai sebagai Lainnya) tidak akan diperiksa lagi dan dihapus dari histori saat Anda mengklik Validasi ulang.

Histori validasi

Anda dapat melihat progres permintaan validasi dengan mengklik link detail validasi di halaman detail masalah.

Entri di halaman histori validasi dikelompokkan berdasarkan URL untuk laporan AMP dan laporan Status Indeks. Dalam laporan Kegunaan Seluler dan Hasil Kaya, item dikelompokkan berdasarkan kombinasi URL + item data terstruktur (seperti yang ditentukan berdasarkan nilai Nama item). Status validasi berlaku untuk masalah tertentu yang Anda periksa. Anda dapat memiliki satu masalah berlabel "Lulus" di halaman, tetapi masalah lainnya berlabel "Gagal", "Tertunda", atau "Lainnya".

Status validasi masalah

Status validasi berikut berlaku untuk masalah tertentu:

  • Belum dimulai: Ada satu atau beberapa halaman dengan instance masalah ini yang belum pernah Anda coba validasi. Langkah berikutnya:
    1. Klik masalah untuk mempelajari detail error-nya. Periksa setiap halaman untuk melihat contoh error pada halaman aktif menggunakan Pengujian AMP. (Jika Pengujian AMP tidak menampilkan error pada halaman, ini terjadi karena Anda telah memperbaiki error pada halaman aktif setelah Google menemukan error dan membuat laporan masalah ini.)
    2. Klik "Pelajari lebih lanjut" pada halaman detail untuk melihat detail aturan yang telah dilanggar.
    3. Klik contoh baris URL pada tabel untuk mendapatkan detail tentang error tersebut.
    4. Perbaiki halaman, lalu klik Validasi perbaikan agar Google meng-crawl ulang halaman. Google akan memberi tahu Anda tentang progres validasi. Harap bersabar karena validasi dapat memakan waktu beberapa hari hingga kira-kira 2 minggu. 
  • Dimulai:  Anda telah memulai upaya validasi dan belum ada sisa instance masalah yang ditemukan. Langkah berikutnya: Google akan mengirimkan notifikasi saat validasi berjalan, 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 validasi berjalan, 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 tidak muncul 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 pada semua URL, meskipun Anda belum pernah memulai upaya validasi. Langkah berikutnya: Tidak ada lagi tindakan yang harus dilakukan.
  • Gagal: Ambang batas tertentu dari halaman masih berisi masalah ini, setelah Anda mengklik "Validasi". Langkah berikutnya: Perbaiki masalah dan validasi ulang.

Status validasi instance

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

  • Validasi tertunda: Menunggu validasi diproses. Terakhir kali Google memeriksanya, instance masalah ini sudah ada.
  • Lulus: [Tidak tersedia di semua laporan] Google telah memeriksa masalah tersebut dan laporan 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 meng-hosting instance tersebut, atau (untuk data terstruktur) tidak dapat lagi menemukan item pada halaman apa pun. 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 pada 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 waktu antara saat masalah ditambahkan ke grafik dan saat ditambahkan ke tabel.
  • Jika jumlah masalah di situs Anda sangat banyak (terlepas dari ada tidaknya instance yang aktif), laporan hanya akan menampilkan 200 masalah pertama, yang diurutkan berdasarkan tingkat kepentingannya.
Apakah ini membantu?
Bagaimana cara meningkatkannya?