Laporan Kegunaan Seluler

Laporan Kegunaan Seluler menunjukkan halaman di properti Anda yang memiliki masalah kegunaan saat ditampilkan di perangkat seluler.

Tampilan tingkat atas menampilkan semua halaman yang memiliki masalah kegunaan seluler melebihi level ambang batas. 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.

BUKA LAPORAN KEGUNAAN SELULER

Halaman ringkasan

Diagram menampilkan jumlah halaman dalam status error dan/atau valid, tergantung pilihan Anda. Kotak centang Tayangan menampilkan tayangan halaman properti Anda dari perangkat seluler. 

Tentang data

Tabel ini dapat menampilkan hingga 1.000 baris data. Sebagian halaman yang terpengaruh mungkin tidak ditampilkan karena ada lebih dari 1.000 halaman yang terpengaruh, karena kami tidak mendeteksi masalah itu, karena masalah tersebut masih sangat baru, atau karena masalahnya terjadi di halaman yang memiliki skor kegunaan di atas ambang batas.

Informasi berikut ditampilkan dalam laporan:

  • Status: Halaman memiliki dua kemungkinan status:
    • Error: Halaman tersebut tidak mobile friendly
    • Valid: Halaman tersebut mobile friendly.
  • Halaman: Jumlah halaman dalam status Error dengan masalah ini.
Detail tentang status halaman

Google menandai suatu halaman sebagai valid atau error bergantung pada skor kegunaan seluler internal. Skor ini dihitung berdasarkan jumlah masalah dan tingkat keparahan relatifnya.

  • Error berarti halaman belum mencapai level kegunaan seluler minimum. Status Error ini akan dicantumkan di halaman detail untuk setiap masalah kegunaan seluler yang memengaruhinya.
  • Valid berarti halaman mencapai level kegunaan seluler minimum, meskipun mungkin masih memiliki beberapa masalah kegunaan seluler, yang tidak akan dikaitkan dengan halaman tersebut dalam laporan ini. Jika ingin mengonfirmasi bahwa halaman yang berstatus valid sudah sepenuhnya bebas dari masalah kegunaan seluler, Anda harus mengujinya menggunakan Alat Uji untuk Mobile-Friendly.

 Kapan masalah ini dimulai?

Bayangkan sebuah halaman yang dianggap valid, namun memiliki masalah kegunaan yang tidak serius. Halaman ini kemudian dipengaruhi oleh masalah lain yang memengaruhi skor kegunaan sehingga menyebabkan halaman itu ditandai sebagai error. Dalam hal ini, Anda akan melihat kedua masalah ditampilkan bersamaan untuk halaman tersebut, namun satu masalah muncul beberapa waktu sebelumnya. Kesimpulan: tidak semua masalah yang ditampilkan pada sebuah halaman terjadi pada waktu ketika halaman itu diberi status error.

Detail tentang jumlah halaman yang terpengaruh

Halaman yang berstatus valid tidak disertakan dalam jumlah halaman terpengaruh untuk setiap masalah yang mungkin dimilikinya. Halaman yang valid juga tidak ditampilkan dalam daftar halaman terpengaruh untuk setiap masalah yang dimilikinya. Hanya halaman yang berstatus error yang dihitung untuk setiap masalah yang memengaruhi halaman itu, dan ditampilkan dalam daftar halaman yang terpengaruh.

Contoh:

Bayangkan skenario ini dengan dua halaman:

  • Halaman 1 dipengaruhi oleh masalah A dan B, tetapi ditandai Valid, karena skor kegunaan selulernya di atas ambang batas yang valid.
  • Halaman 2 dipengaruhi oleh masalah B, C, dan D, dan ditandai Error, karena skor kegunaan selulernya di bawah ambang batas yang valid.

Dalam skenario ini:

  • Jumlah halaman yang terpengaruh untuk masalah A adalah 0.
  • Jumlah halaman yang terpengaruh untuk masalah B, C, dan D adalah 1.
  • Halaman yang ditampilkan sebagai terpengaruh oleh masalah B: Halaman 2.

Memprioritaskan dan memperbaiki masalah

  1. Di halaman laporan ringkasan, masalah diurutkan berdasarkan kombinasi status validasi dan jumlah halaman yang terpengaruh; sebaiknya perbaiki masalah dalam urutan default ini. Perbaiki masalah umum terlebih dahulu (seperti template yang buruk), lalu perbaiki instance yang kurang umum.
  2. Lihat apakah ada peningkatan jumlah total error yang paling banyak disebabkan oleh sebuah error: carilah lonjakan yang sesuai dalam satu masalah pada tabel. Lihat informasi di bawah tentang jenis error dan lonjakan error proses debug.
  3. Pilih satu baris dalam tabel untuk melihat halaman detail error:
    1. Halaman detail mencakup contoh URL yang terpengaruh. Daftar ini tidak selalu lengkap, karena dibatasi hanya 1.000 baris, dan mungkin tidak termasuk instance error yang baru ditemukan ini.
    2. Pilih Pelajari lebih lanjut untuk mendapatkan dokumentasi resmi terkait sintaks yang benar.
    3. Pilih URL yang terpengaruh dalam tabel untuk membuka panel yang berisi informasi lebih lanjut, termasuk jumlah masalah kegunaan seluler, dan link Periksa untuk menjalankan fitur Inspeksi URL terhadap versi terindeks halaman ini, dan link Uji versi langsung untuk menjalankan Pengujian Situs Mobile-Friendly di halaman ini. Ada kemungkinan bahwa error telah diperbaiki di halaman aktif tetapi masih tercantum dalam laporan Kegunaan Seluler karena halaman belum di-crawl ulang; jika demikian, mintalah validasi setelah Anda memperbaiki semua instance masalah ini.
  4. Perbaiki semua instance masalah di situs, uji perbaikan, dan pastikan bahwa perbaikan telah diterapkan di web.
  5. Kembali ke halaman detail masalah dan klik tombol "Validasi & Update Google" untuk memulai proses validasi. Proses ini tidak langsung dilakukan. Lihat Tentang validasi untuk memahami proses validasi.
  6. Lanjutkan perbaikan error.

Membagikan laporan

Anda dapat membagikan detail masalah dengan mengklik tombol Bagikan di halaman. Link ini hanya memberikan akses ke halaman saat ini dan 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.

Melakukan debug pada 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.

Error

Error berikut dapat muncul dalam laporan Kegunaan Seluler:

Menggunakan plugin yang tidak kompatibel

Halaman ini menyertakan plugin, seperti Flash, yang tidak didukung oleh sebagian besar browser seluler. Kami merekomendasikan Anda untuk mendesain ulang halaman menggunakan teknologi web modern yang didukung secara luas, seperti HTML5. Baca lebih lanjut pedoman animasi web.

Viewport tidak ditetapkan

Halaman Anda tidak menentukan properti viewport, yang memberi tahu browser cara menyesuaikan dimensi dan penskalaan halaman agar sesuai dengan ukuran layar. Karena pengunjung ke situs Anda menggunakan berbagai perangkat dengan ukuran layar yang berbeda-beda—dari monitor desktop yang lebar, hingga tablet dan smartphone berlayar kecil—halaman Anda harus menentukan viewport menggunakan tag meta viewport. Pelajari lebih lanjut di Dasar-Dasar Desain Web yang Responsif.

Viewport tidak ditetapkan ke "device-width"

Halaman Anda menentukan properti viewport lebar tetap, sehingga tidak dapat menyesuaikan dengan ukuran layar yang berbeda-beda. Untuk memperbaiki error ini, gunakan desain responsif untuk halaman situs Anda, dan setel viewport agar sesuai dengan skala dan lebar perangkat. Baca cara Menyetel Viewport dengan benar.

Konten lebih lebar daripada layar

Laporan ini menunjukkan halaman yang harus di-scroll secara horizontal untuk melihat kata dan gambar di halaman. Hal ini terjadi saat halaman menggunakan nilai mutlak di deklarasi CSS, atau menggunakan gambar yang didesain agar terlihat sangat baik pada lebar browser tertentu (misalnya 980 piksel). Untuk memperbaiki error ini, pastikan halaman menggunakan lebar relatif dan nilai posisi untuk elemen CSS, dan pastikan gambar dapat diskalakan juga. Baca selengkapnya di Menyesuaikan Konten dengan Viewport.

Teks terlalu kecil untuk dibaca

Laporan ini mengidentifikasi halaman yang ukuran fontnya terlalu kecil untuk dapat dibaca dan pengguna seluler perlu "mencubit jari untuk melakukan zoom" untuk membaca. Setelah menentukan viewport untuk halaman web, setel ukuran font agar diskalakan dengan benar di dalam viewport. Baca lebih lanjut tentang praktik terbaik ukuran font di Menggunakan Ukuran Font yang Dapat Dibaca.

Elemen yang dapat diklik terlalu berdekatan satu sama lain

Laporan ini menunjukkan URL untuk situs yang elemen sentuhnya, seperti link navigasi dan tombol, terlalu berdekatan sehingga pengguna seluler tidak dapat menge-tap elemen yang diinginkan dengan mudah menggunakan jari mereka tanpa juga menge-tap elemen di sampingnya. Untuk memperbaiki error ini, pastikan Anda memberi ukuran dan jarak link navigasi dan tombol dengan benar agar sesuai untuk pengunjung seluler Anda. Baca selengkapnya di Atur Ukuran Target Tap dengan Sesuai.

Validasi

Setelah memperbaiki error di situs, beri tahu Google untuk meng-crawl ulang halaman yang Anda perbaiki. Luaskan bagian di bawah untuk melihat detailnya.

Tentang validasi

Setelah memperbaiki semua instance masalah khusus 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 pemberitahuan 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 oleh 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 bernilai 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 diwajibkan). 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 1 atau lebih dari 1 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. Validasi dapat memakan waktu beberapa hari hingga kira-kira 2 minggu, jadi harap bersabar. 
  • Dimulai: Anda telah memulai upaya validasi dan belum ada sisa instance masalah yang ditemukan. Langkah berikutnya: Google akan mengirimkan pemberitahuan saat validasi diproses, 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, namun Google akan mengirimkan pemberitahuan saat validasi diproses, yang memberi tahu Anda tentang 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 mendapati 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 yang diketahui akan diberi salah satu status validasi berikut untuk masalah tertentu (status Lulus dan Lainnya tidak digunakan dalam laporan Status Indeks):

  • Validasi tertunda: Menunggu proses validasi. Terakhir kali Google memeriksanya, instance masalah ini sudah ada.
  • Lulus: Google memeriksa instance masalah, namun instance tersebut sudah tidak ada. 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: Google tidak dapat menjangkau URL yang menghosting instance, atau (untuk data terstruktur) tidak dapat menemukan item di halaman tersebut lagi. 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.

Apakah ini membantu?
Bagaimana cara meningkatkannya?