{"id":1906,"date":"2026-09-02T10:34:11","date_gmt":"2026-09-02T03:34:11","guid":{"rendered":"https:\/\/achmadfarid.com\/?p=1906"},"modified":"2026-09-02T10:34:11","modified_gmt":"2026-09-02T03:34:11","slug":"mobile-first-indexing","status":"publish","type":"post","link":"https:\/\/achmadfarid.com\/en\/mobile-first-indexing\/","title":{"rendered":"Mobile First Indexing: Transisinya Selesai, Tapi Alat Pengeceknya Ikut Dihapus"},"content":{"rendered":"<p dir=\"ltr\">Ada satu jenis penurunan ranking yang paling sulit saya jelaskan ke klien, dan bentuknya selalu sama: tidak ada yang terjadi. Tidak ada manual action. Tidak ada core update di tanggal itu. Core Web Vitals hijau. Halaman terindeks, statusnya normal, sitemap bersih. Tapi posisinya turun pelan-pelan selama tiga sampai empat bulan sampai halaman yang dulu di posisi 4 sekarang ada di halaman dua, dan tidak ada satu pun laporan di Search Console yang menyala.<\/p>\n<p dir=\"ltr\">Sebagian besar kasus seperti ini yang saya tangani berakhir di tempat yang sama: versi mobile halaman itu tidak berisi hal yang sama dengan versi desktop-nya. Dan sejak Google menyelesaikan peralihan ke <strong>mobile first indexing<\/strong>, versi mobile itulah satu-satunya yang dibaca. Yang bikin repot bukan masalahnya \u2014 masalahnya sederhana dan bisa diperbaiki dalam sehari. Yang bikin repot adalah Google sudah menghapus semua laporan yang dulu memberi tahu Anda kalau hal ini sedang terjadi.<\/p>\n<p dir=\"ltr\">Artikel ini bukan panduan &#8220;siapkan website Anda untuk mobile first indexing&#8221;. Persiapan itu sudah lewat tenggatnya dua tahun lalu, dan hampir semua artikel Indonesia yang muncul di halaman satu masih menulis seolah transisinya belum terjadi. Yang akan saya bahas: apa yang sebenarnya berubah, dua kalimat resmi Google yang membatalkan separuh nasihat yang beredar, empat pemeriksaan yang menggantikan laporan yang dihapus, dan satu lapisan baru di 2026 yang membuat pertanyaan paritas berubah bentuk sepenuhnya.<\/p>\n<h2 dir=\"ltr\">Ranking Turun Empat Bulan Tanpa Satu Pun Peringatan<\/h2>\n<p dir=\"ltr\">Awal tahun ini saya diminta melihat website sebuah perusahaan jasa yang kehilangan sekitar sepertiga trafik organiknya secara bertahap. Bukan jatuh mendadak. Turun landai, minggu demi minggu, selama hampir empat bulan.<\/p>\n<p dir=\"ltr\">Mereka sudah melakukan semua pemeriksaan standar. Tidak ada penalti. Tidak ada perubahan struktur URL. Konten tidak dihapus. Mereka bahkan menambah dua puluh artikel baru di periode yang sama, yang justru membuat angkanya lebih membingungkan \u2014 kerja bertambah, hasil berkurang.<\/p>\n<p dir=\"ltr\">Penyebabnya ketemu di menit kesepuluh, dan letaknya tidak di tempat yang mereka cari. Enam bulan sebelumnya, tim desain merapikan tampilan mobile. Salah satu yang mereka rapikan adalah blok penjelasan layanan sepanjang sekitar 600 kata di bawah lipatan \u2014 di desktop blok itu tampil utuh, di mobile blok itu diganti dengan versi ringkas tiga kalimat yang dimuat lewat komponen terpisah. Alasannya masuk akal secara desain: halaman mobile jadi jauh lebih enak dibaca.<\/p>\n<p dir=\"ltr\">Masalahnya, sejak Juli 2024 Google membaca website itu <strong>hanya<\/strong> dari versi mobile. Enam ratus kata yang menjelaskan layanan mereka \u2014 lengkap dengan istilah-istilah yang jadi target kata kunci \u2014 secara efektif berhenti ada di indeks Google. Dan tidak ada satu pun laporan yang memberi tahu mereka. Kalau Anda pernah menghadapi penurunan trafik yang penyebabnya tidak jelas, saya sudah menulis <a href=\"https:\/\/achmadfarid.com\/en\/traffic-website-turun-ini-urutan-diagnosa\/\">urutan diagnosa yang saya pakai sebelum menyentuh konten sama sekali<\/a> \u2014 artikel ini membahas satu penyebab spesifik dari daftar itu, yaitu penyebab yang paling sulit dilihat karena tidak meninggalkan jejak di mana pun.<\/p>\n<h2 dir=\"ltr\">Apa Itu Mobile First Indexing dan Apa yang Sebenarnya Berubah pada 2024<\/h2>\n<p dir=\"ltr\">Mobile first indexing adalah cara Google merayapi, mengindeks, dan menilai halaman web menggunakan <strong>versi mobile<\/strong> halaman itu, bukan versi desktop-nya. Perayapnya adalah Googlebot Smartphone. Konten, heading, data terstruktur, dan metadata yang masuk ke indeks Google diambil dari apa yang dilihat perayap itu di layar ponsel.<\/p>\n<p dir=\"ltr\">Yang penting dipahami di 2026 bukan definisinya, melainkan status pelaksanaannya. Tiga hal ini yang benar sekarang.<\/p>\n<p dir=\"ltr\"><strong>Transisinya sudah selesai, bukan sedang berjalan.<\/strong> Google mengumumkan peralihan ini pertama kali pada November 2016. Setelah beberapa kali tenggat mundur, Google menyatakan prosesnya rampung pada 31 Oktober 2023 untuk hampir seluruh web. Sisanya \u2014 sekumpulan kecil situs yang masih dirayapi Googlebot Desktop \u2014 ikut dialihkan setelah 5 Juli 2024. Sejak tanggal itu tidak ada lagi kategori &#8220;situs yang belum beralih&#8221;.<\/p>\n<p dir=\"ltr\"><strong>Tidak ada lagi laporan tentang statusnya.<\/strong> Informasi indexing crawler di Search Console sudah dinonaktifkan, karena tidak ada lagi yang perlu dilaporkan: semuanya dirayapi dengan perayap yang sama. Jadi kalau Anda mencari menu &#8220;cek status mobile first indexing&#8221; di Search Console, Anda tidak akan menemukannya, dan itu bukan karena Anda salah lihat.<\/p>\n<p dir=\"ltr\"><strong>Googlebot Desktop belum benar-benar punah.<\/strong> Google menyatakan masih kadang memakai perayap desktop untuk product listing dan Google for Jobs. Jadi kalau Anda melihat Googlebot Desktop di log server, itu normal dan bukan tanda ada yang salah.<\/p>\n<p dir=\"ltr\">Yang berubah, dengan kata lain, bukan aturannya. Aturannya sudah stabil selama dua tahun. Yang berubah adalah <strong>posisi Anda sebagai pemilik situs<\/strong>: dulu Anda punya laporan, sekarang tidak.<\/p>\n<h2 dir=\"ltr\">Dua Kalimat Resmi Google yang Membatalkan Separuh Nasihat yang Beredar<\/h2>\n<p dir=\"ltr\">Kalau Anda membaca lima artikel Indonesia teratas untuk kata kunci ini, ada satu klaim yang muncul di hampir semuanya dengan tingkat kepercayaan diri yang tinggi: kalau website Anda tidak mobile-friendly, Google tidak akan mengindeksnya. Beberapa artikel menyebut tanggal 5 Juli 2024 sebagai tenggatnya.<\/p>\n<p dir=\"ltr\">Klaim itu salah, dan salahnya bukan di detail kecil.<\/p>\n<h3 dir=\"ltr\">Perbedaan antara &#8220;tidak bisa dibuka&#8221; dan &#8220;tidak nyaman dibuka&#8221;<\/h3>\n<p dir=\"ltr\">Yang John Mueller tulis di blog resmi Google adalah kalimat yang jauh lebih sempit: jika konten situs Anda <strong>sama sekali tidak bisa diakses<\/strong> dengan perangkat mobile, situs itu tidak lagi bisa diindeks. Barry Schwartz di Search Engine Land mengejanya dengan gamblang di artikel yang sama-sama terbit sebelum tenggat itu: ini tidak berarti Google berhenti mengindeks situs yang tidak mobile-friendly. Kalau Anda hanya punya template desktop, itu tidak apa-apa \u2014 asalkan versi desktop itu tetap termuat di perangkat mobile.<\/p>\n<p dir=\"ltr\">Dokumentasi Google sendiri lebih jelas lagi. Di halaman praktik terbaik mobile first indexing, Google menulis bahwa memiliki versi mobile <strong>tidak diwajibkan<\/strong> agar konten Anda masuk hasil pencarian, meski sangat dianjurkan. Dua frasa itu \u2014 tidak diwajibkan, sangat dianjurkan \u2014 adalah posisi resmi Google, dan posisinya berbeda jauh dari &#8220;tidak mobile-friendly berarti dihapus&#8221;.<\/p>\n<p dir=\"ltr\">Jadi garisnya begini. Halaman yang <strong>gagal termuat<\/strong> di ponsel (misalnya karena skrip yang error di perangkat mobile, atau redirect yang membuang pengunjung mobile ke halaman kosong) memang keluar dari indeks. Halaman yang <strong>termuat tapi jelek<\/strong> \u2014 tulisan kecil, harus dicubit-zoom, tombol berdesakan \u2014 tetap diindeks. Ia cuma akan kalah bersaing, dan kalahnya lewat jalur lain: pengalaman pengguna, bukan pengindeksan.<\/p>\n<h3 dir=\"ltr\">Kenapa perbedaan ini menentukan ke mana uang Anda pergi<\/h3>\n<p dir=\"ltr\">Perbedaan ini terdengar akademis sampai Anda melihat keputusan anggaran yang lahir darinya. Saya cukup sering bertemu pemilik bisnis yang datang dengan kalimat &#8220;katanya website saya bakal dihapus Google kalau tidak dibuat ulang&#8221;. Yang mereka butuhkan biasanya bukan bangun ulang. Yang mereka butuhkan adalah memastikan versi mobile berisi hal yang sama dengan desktop \u2014 pekerjaan beberapa jam, bukan beberapa puluh juta.<\/p>\n<p dir=\"ltr\">Sebaliknya, ada juga yang merasa aman karena situsnya &#8220;sudah responsif dan sudah rapi di HP&#8221;, padahal masalah paritasnya nyata. Rapi di HP dan lengkap di HP adalah dua hal berbeda. Yang dinilai Google adalah yang kedua. Soal bagaimana tampilan dan kenyamanan memengaruhi peringkat lewat jalur yang berbeda, itu sudah saya bahas terpisah di <a href=\"https:\/\/achmadfarid.com\/en\/ux-dan-seo\/\">kenapa website yang cantik justru bisa kalah ranking<\/a> \u2014 dan sengaja saya pisahkan, karena mencampur dua jalur ini adalah sumber utama kebingungan di topik ini.<\/p>\n<h2 dir=\"ltr\">Google Menghapus Semua Alat yang Dulu Memberi Tahu Anda Ada yang Salah<\/h2>\n<p dir=\"ltr\">Ini bagian yang menurut saya paling jarang dibahas, dan paling menentukan.<\/p>\n<p dir=\"ltr\">Dulu, kalau versi mobile Anda bermasalah, Anda diberi tahu. Search Console punya laporan Mobile Usability yang menandai halaman bermasalah satu per satu. Ada Mobile-Friendly Test, alat gratis untuk mengecek satu URL. Ada juga API-nya, yang dipakai banyak tool audit pihak ketiga. Dan ketika sebuah situs dialihkan ke mobile first indexing, Google mengirim notifikasi.<\/p>\n<p dir=\"ltr\">Semuanya sudah tidak ada. Laporan Mobile Usability, Mobile-Friendly Test, dan API-nya dihentikan pada 1 Desember 2023. Alamat alat tesnya sekarang mengalihkan ke dokumentasi Lighthouse. Informasi indexing crawler di Search Console dinonaktifkan.<\/p>\n<p dir=\"ltr\">Yang menarik adalah <strong>alasannya<\/strong>. Alat-alat itu tidak dihapus karena masalahnya selesai. Alat-alat itu dihapus karena masalahnya berhenti jadi peristiwa dan berubah jadi kondisi. Selama transisi masih berjalan, &#8220;apakah situs saya siap&#8221; adalah pertanyaan yang punya jawaban ya atau tidak, dan pertanyaan seperti itu layak punya laporan sendiri. Setelah semua situs berada di mobile first indexing, tidak ada lagi kesiapan yang perlu dilaporkan \u2014 yang tersisa hanyalah kualitas, dan kualitas tidak muncul sebagai lampu merah.<\/p>\n<p dir=\"ltr\">Efek sampingnya persis seperti kasus di awal artikel ini. Kegagalan paritas konten sekarang <strong>tidak bergejala di dashboard mana pun<\/strong>. Tidak ada error. Tidak ada peringatan. Halaman tetap terindeks \u2014 memang benar-benar terindeks, cuma isinya lebih sedikit dari yang Anda kira. Satu-satunya gejala adalah peringkat yang meluruh pelan, dan peluruhan pelan adalah gejala paling generik dalam SEO. Ia bisa berarti seratus hal.<\/p>\n<p dir=\"ltr\">Ada satu hal kecil yang menurut saya menggambarkan situasi ini dengan baik. Salah satu artikel Indonesia yang masih bertengger di halaman satu untuk kata kunci ini menganjurkan pembacanya memakai Google Mobile-Friendly Test untuk mengaudit situs. Artikel itu terbit 3 November 2023. Alat yang direkomendasikannya dimatikan 1 Desember 2023 \u2014 empat minggu setelahnya. Artikelnya tidak pernah diperbarui, dan sampai hari ini masih dibaca ribuan orang yang lalu mencari alat yang sudah tidak ada.<\/p>\n<h2 dir=\"ltr\">Empat Pemeriksaan yang Menggantikan Laporan yang Dihapus<\/h2>\n<p dir=\"ltr\">Karena tidak ada lagi laporan otomatis, pemeriksaannya harus manual. Kabar baiknya, empat pemeriksaan ini semuanya gratis dan yang pertama cuma butuh ponsel Anda sendiri. Saya mengurutkannya bukan dari dampak, melainkan dari <strong>berapa mahal biayanya untuk dibuktikan<\/strong> \u2014 yang paling murah dulu, karena sebagian besar situs berhenti di pemeriksaan pertama atau kedua dan tidak perlu melanjutkan.<\/p>\n<h3 dir=\"ltr\">Pemeriksaan 1: apakah halaman ini terbuka sama sekali di ponsel<\/h3>\n<p dir=\"ltr\">Ini satu-satunya pemeriksaan yang berhubungan langsung dengan risiko keluar dari indeks, dan cara mengujinya sengaja saya buat primitif: buka halaman itu di ponsel Anda, <strong>dengan wifi dimatikan<\/strong>, pakai kuota. Bukan di mode responsive DevTools, bukan di simulator.<\/p>\n<p dir=\"ltr\">Alasan wifi dimatikan bukan soal kecepatan. Alasannya, sejumlah kegagalan hanya muncul di jaringan seluler nyata \u2014 skrip yang time-out, aset yang diblokir, atau CDN yang berperilaku beda per jaringan. Kalau halamannya tetap tampil, meski tampilannya jelek atau harus di-zoom, Anda lulus pemeriksaan ini. Situs Anda tidak akan dihapus.<\/p>\n<h3 dir=\"ltr\">Pemeriksaan 2: bandingkan HTML yang dirender, bukan tampilannya<\/h3>\n<p dir=\"ltr\">Ini pemeriksaan yang paling sering dilewati, padahal ini yang menangkap kasus seperti di awal artikel. Buka Search Console, masuk ke URL Inspection, tempel URL-nya, klik Test Live URL, lalu buka View Tested Page. Anda akan mendapat dua hal: HTML hasil render dan tangkapan layar.<\/p>\n<p dir=\"ltr\">Yang Anda lakukan berikutnya bukan melihat tangkapan layarnya. Tangkapan layar menipu \u2014 konten bisa saja ada di HTML tapi tidak terlihat di layar, dan sebaliknya. Yang Anda lakukan adalah <strong>Ctrl+F di HTML itu<\/strong>, cari satu kalimat yang Anda tahu pasti ada di versi desktop halaman tersebut. Ambil kalimat dari tengah halaman, bukan dari judul. Kalau kalimat itu ketemu, konten Anda masuk. Kalau tidak ketemu, Anda baru saja menemukan sesuatu yang tidak akan pernah dilaporkan Search Console kepada Anda.<\/p>\n<p dir=\"ltr\">Lakukan ini untuk tiga jenis halaman: satu halaman layanan atau produk, satu artikel panjang, dan satu halaman kategori. Tiga halaman biasanya cukup untuk tahu apakah masalahnya sistemik atau kasuistis.<\/p>\n<h3 dir=\"ltr\">Pemeriksaan 3: paritas empat lapis, bukan cuma teksnya<\/h3>\n<p dir=\"ltr\">Dokumentasi Google menyebut beberapa hal yang harus setara antara versi mobile dan desktop, dan orang biasanya cuma memeriksa yang pertama.<\/p>\n<p dir=\"ltr\"><strong>Konten utama.<\/strong> Teks inti halaman harus setara. Boleh tampil beda, boleh dilipat, tapi harus ada.<\/p>\n<p dir=\"ltr\"><strong>Heading.<\/strong> Google meminta heading yang sama dan sama jelasnya di versi mobile. Ini sering rusak diam-diam ketika template mobile memakai struktur heading yang berbeda demi kerapian tampilan.<\/p>\n<p dir=\"ltr\"><strong>Data terstruktur.<\/strong> Harus ada di kedua versi, dengan URL yang benar di dalamnya. Kalau schema Anda hanya di-render di template desktop, rich result Anda akan menghilang perlahan tanpa alasan yang kelihatan.<\/p>\n<p dir=\"ltr\"><strong>Title dan meta description.<\/strong> Ini yang paling luput. Sebagian page builder dan plugin SEO memungkinkan pengaturan berbeda per perangkat, dan kalau ada yang pernah mengisinya, versi mobile-lah yang dipakai Google \u2014 bukan versi yang Anda lihat saat mengedit di desktop.<\/p>\n<h3 dir=\"ltr\">Pemeriksaan 4: konten yang butuh ketukan untuk MUAT<\/h3>\n<p dir=\"ltr\">Ini pemeriksaan terakhir dan paling teknis, tapi juga yang paling sering salah dipahami, jadi saya bahas lengkap di bagian berikutnya. Aturannya satu kalimat: Google tidak akan memuat konten yang baru diambil setelah pengguna melakukan sesuatu \u2014 mengetuk, menggeser, atau mengetik.<\/p>\n<p dir=\"ltr\">Kalau ada bagian halaman yang isinya baru dijemput dari server ketika tombol ditekan, bagian itu tidak pernah masuk indeks. Bukan karena Google menghukumnya. Karena Google tidak pernah menekan tombolnya.<\/p>\n<h2 dir=\"ltr\">Lima Keyakinan yang Membuat Orang Memperbaiki Hal yang Salah<\/h2>\n<p dir=\"ltr\">Yang menarik dari topik ini adalah sebagian besar kesalahan terjadi <strong>sebelum<\/strong> ada yang menyentuh kode. Kesalahannya ada di keyakinan yang dibawa masuk.<\/p>\n<p dir=\"ltr\"><strong>&#8220;Konten di dalam accordion atau tab tidak dihitung Google.&#8221;<\/strong> Ini keyakinan paling merugikan di daftar ini, dan ini salah. Gary Illyes sudah menyatakan sejak 2016 bahwa di dunia mobile first, konten yang disembunyikan demi UX mendapat bobot penuh. John Mueller mengulanginya pada 2020: apa pun yang ada di HTML diperhitungkan, dan itu normal. Halaman kebijakan spam Google \u2014 yang diperbarui Mei 2026 \u2014 bahkan secara eksplisit mendaftar konten accordion dan tab sebagai pola desain yang <strong>tidak<\/strong> melanggar aturan teks tersembunyi. Dokumentasi Google malah menyarankan sebaliknya: daripada menghapus konten di mobile, pindahkan ke accordion atau tab. Saya sudah beberapa kali melihat orang membongkar accordion yang berfungsi baik demi ketakutan yang tidak berdasar.<\/p>\n<p dir=\"ltr\"><strong>&#8220;Tidak mobile-friendly berarti tidak diindeks.&#8221;<\/strong> Sudah dibahas di atas. Yang benar: tidak bisa dimuat sama sekali berarti tidak diindeks. Tidak nyaman dibaca berarti kalah bersaing \u2014 dua konsekuensi yang berbeda, dengan biaya perbaikan yang berbeda jauh.<\/p>\n<p dir=\"ltr\"><strong>&#8220;Mobile first indexing itu urusan kecepatan.&#8221;<\/strong> Ini pergeseran topik yang halus dan hampir selalu terjadi. Kecepatan memang penting, dan memang diukur dari perangkat mobile, tapi ia bekerja lewat jalur pengalaman pengguna \u2014 bukan lewat apa yang dibaca Google dari halaman Anda. Halaman yang lambat tetap diindeks lengkap. Halaman yang cepat tapi kehilangan 600 kata di versi mobile tidak. Kalau yang ingin Anda benahi memang sisi kecepatannya, itu pekerjaan yang berdiri sendiri dan sudah saya urai di <a href=\"https:\/\/achmadfarid.com\/en\/cara-mempercepat-website-wordpress\/\">cara mempercepat website WordPress dengan menghitung anggaran waktu muat alih-alih mengejar skor<\/a>. Dua hal ini sering dijual dalam satu paket, padahal cara memeriksanya berbeda.<\/p>\n<p dir=\"ltr\"><strong>&#8220;Situs saya responsif, jadi otomatis aman.&#8221;<\/strong> Ini yang paling mendekati benar, dan saya mau jujur soal itu: kalau situs Anda benar-benar responsif \u2014 HTML yang sama dikirim ke semua perangkat, tampilannya saja yang menyesuaikan \u2014 maka sebagian besar risiko paritas memang hilang dengan sendirinya. Itulah alasan Google merekomendasikan desain responsif di atas dua konfigurasi lainnya. Sisa risikonya cuma satu: konten yang dimuat secara kondisional lewat JavaScript berdasarkan lebar layar, atau komponen mobile terpisah yang isinya diambil belakangan. Kalau Anda tidak punya itu, Anda boleh lewati sebagian besar artikel ini.<\/p>\n<p dir=\"ltr\"><strong>&#8220;Sudah saya cek pakai Mobile-Friendly Test dan hasilnya lulus.&#8221;<\/strong> Kalau kalimat ini datang dari pemeriksaan yang dilakukan setelah Desember 2023, pemeriksaannya tidak pernah terjadi. Alatnya tidak ada lagi. Yang sering terjadi: seseorang membuka tautannya, dialihkan ke halaman lain, mengira sudah selesai, lalu melapor &#8220;aman&#8221;.<\/p>\n<h2 dir=\"ltr\">Sejak 2026 Ada Dua Perayap dengan Kemampuan Berbeda Membaca Halaman yang Sama<\/h2>\n<p dir=\"ltr\">Bagian ini adalah alasan saya menulis artikel ini sekarang, dan bukan tahun lalu.<\/p>\n<p dir=\"ltr\">Selama hampir sepuluh tahun, pertanyaan paritas selalu berbentuk sama: apakah versi mobile berisi hal yang sama dengan versi desktop. Sejak 2026 pertanyaannya berubah bentuk, karena bukan cuma Google yang membaca halaman Anda \u2014 dan pembaca yang baru punya kemampuan yang jauh lebih terbatas.<\/p>\n<h3 dir=\"ltr\">Yang membaca halaman Anda sekarang ada dua kelas<\/h3>\n<p dir=\"ltr\">Googlebot merender JavaScript. Ia memakai mesin berbasis Chrome tanpa tampilan, menjalankan skrip Anda, menunggu hasilnya, lalu mengindeks halaman yang sudah jadi. Itu sebabnya situs yang kontennya baru muncul setelah JavaScript berjalan tetap bisa masuk peringkat satu.<\/p>\n<p dir=\"ltr\">Perayap mesin jawaban AI tidak melakukan itu. Sampai pertengahan 2026, tidak ada satu pun perayap AI besar yang menjalankan JavaScript. Analisis Vercel terhadap lebih dari 500 juta permintaan GPTBot tidak menemukan satu pun bukti eksekusi JavaScript. GPTBot memang mengunduh berkas JavaScript pada sekitar 11,5 persen permintaannya dan ClaudeBot pada sekitar 23,84 persen \u2014 tapi mengunduh bukan menjalankan. Mereka mengambil HTML mentah yang dikirim server Anda, memungut apa yang ada di situ, lalu pergi. Tanpa render, tanpa menunggu, tanpa percobaan kedua.<\/p>\n<p dir=\"ltr\">Artinya paritas sekarang punya sumbu kedua. Bukan lagi cuma mobile lawan desktop, tapi <strong>HTML mentah lawan HTML hasil render<\/strong>. Dan konsekuensinya berat sebelah dengan cara yang tidak intuitif: sebuah halaman bisa berada di posisi satu Google dan sekaligus benar-benar kosong bagi ChatGPT, Perplexity, dan mesin jawaban lainnya. Peringkat Anda bagus, tapi Anda tidak pernah dikutip. Dan sama seperti masalah paritas mobile, tidak ada laporan apa pun yang memberi tahu Anda.<\/p>\n<h3 dir=\"ltr\">Cara mengeceknya butuh tiga puluh detik<\/h3>\n<p dir=\"ltr\">Buka halaman Anda, lalu lihat sumbernya \u2014 View Source, bukan Inspect Element. Bedanya penting: Inspect Element menampilkan DOM setelah JavaScript berjalan, jadi ia akan selalu memperlihatkan konten Anda dan membuat Anda merasa aman. View Source menampilkan HTML mentah persis seperti yang diterima perayap AI.<\/p>\n<p dir=\"ltr\">Di halaman sumber itu, cari satu paragraf inti dari artikel Anda. Kalau ketemu, aman. Kalau yang Anda temukan cuma kerangka kosong dan setumpuk tag skrip, maka semua yang ditulis di artikel ini soal paritas mobile berlaku dua kali lipat untuk Anda \u2014 sekali untuk Google, sekali lagi untuk lapisan mesin jawaban yang tidak punya kemampuan render sama sekali.<\/p>\n<p dir=\"ltr\">Ini juga alasan kenapa nasihat lama &#8220;pakai lazy load untuk semua yang di bawah lipatan&#8221; perlu dibaca ulang. Untuk Googlebot, lazy load yang benar tidak masalah. Untuk perayap yang tidak menjalankan JavaScript, apa pun yang dimuat belakangan sama saja dengan tidak ada.<\/p>\n<p dir=\"ltr\">Kalau bagian ini terasa seperti disiplin yang berbeda dari SEO biasa, itu karena memang berbeda \u2014 cara mengukurnya lain, dan yang dikejar bukan peringkat melainkan kutipan. Saya menanganinya sebagai pekerjaan terpisah lewat <a href=\"https:\/\/achmadfarid.com\/en\/jasa-geo-ai-search\/\">jasa GEO untuk AI search<\/a>. Tapi jujur saja: kalau yang Anda butuhkan sekarang hanya memastikan Google membaca halaman Anda dengan utuh, itu pekerjaan pemeriksaan biasa, dan Anda bisa mulai sendiri dari empat pemeriksaan di atas tanpa menyewa siapa pun.<\/p>\n<h2 dir=\"ltr\">Mulai dari Satu Halaman, Bukan dari Rencana Besar<\/h2>\n<p dir=\"ltr\">Kalau ada satu hal yang saya ingin Anda bawa dari artikel ini, ini dia: mobile first indexing bukan proyek yang perlu Anda siapkan. Ia sudah jadi cara kerja default sejak 2024, dan kemungkinan besar situs Anda baik-baik saja. Yang berubah dan jarang disadari adalah kalau ternyata tidak baik-baik saja, tidak ada yang akan memberi tahu Anda.<\/p>\n<p dir=\"ltr\">Jadi jangan mulai dari audit besar. Mulai dari satu halaman \u2014 halaman yang paling penting untuk bisnis Anda, biasanya halaman layanan atau produk utama. Buka Search Console, jalankan Test Live URL untuk halaman itu, buka HTML hasil render, lalu cari satu kalimat dari tengah halaman yang Anda tahu ada di versi desktop.<\/p>\n<p dir=\"ltr\">Butuh sepuluh menit. Kalau kalimat itu ketemu, Anda baru saja mencoret satu kemungkinan penyebab dari daftar Anda, dan itu bernilai. Kalau tidak ketemu, Anda baru saja menemukan hal yang mungkin sudah menggerogoti peringkat Anda diam-diam selama berbulan-bulan \u2014 dan menemukannya lebih awal jauh lebih murah daripada menemukannya lewat laporan penjualan.<\/p>\n<p dir=\"ltr\">Kalau ternyata perbaikannya ada di lapisan yang lebih dalam \u2014 template yang merender konten berbeda per perangkat, komponen yang isinya baru dijemput setelah diketuk, atau struktur yang membuat konten inti hanya muncul setelah JavaScript berjalan \u2014 itu memang bukan pekerjaan yang bisa diselesaikan dari editor konten. Di titik itu saya biasanya membantu lewat <a href=\"https:\/\/achmadfarid.com\/en\/web-development\/\">jasa web development<\/a>. Tapi periksa dulu sepuluh menit itu. Cukup sering yang ditemukan bukan kebutuhan membangun ulang, melainkan satu blok yang tanpa sengaja dimatikan di versi mobile enam bulan lalu.<\/p>\n<h2 dir=\"ltr\">Pertanyaan yang Sering Muncul Soal Mobile First Indexing<\/h2>\n<p dir=\"ltr\"><strong>Apakah website saya akan dihapus dari Google kalau tidak mobile-friendly?<\/strong> Tidak. Yang membuat halaman keluar dari indeks adalah kalau kontennya sama sekali tidak bisa diakses dari perangkat mobile \u2014 misalnya halamannya gagal termuat. Situs dengan template desktop saja tetap diindeks selama halamannya tetap terbuka di ponsel; ia hanya akan kalah bersaing lewat sisi pengalaman pengguna.<\/p>\n<p dir=\"ltr\"><strong>Bagaimana cara cek indeks mobile Google sekarang kalau Mobile-Friendly Test sudah dihapus?<\/strong> Pakai URL Inspection di Search Console, klik Test Live URL, lalu buka View Tested Page untuk melihat HTML hasil render dan tangkapan layarnya. Untuk pemeriksaan kualitas tampilan dan performa seluler, penggantinya adalah Lighthouse dan PageSpeed Insights.<\/p>\n<p dir=\"ltr\"><strong>Apakah konten di dalam accordion atau tab tetap dihitung Google?<\/strong> Ya, dengan bobot penuh, selama kontennya ada di dalam HTML halaman. Ini sudah dikonfirmasi berulang kali oleh Google dan halaman kebijakan spam mereka secara eksplisit menyatakan pola accordion dan tab bukan pelanggaran teks tersembunyi. Yang tidak dihitung adalah konten yang baru diambil dari server setelah pengguna mengetuk atau menggeser.<\/p>\n<p dir=\"ltr\"><strong>Apakah responsive design seo sudah cukup untuk mobile first indexing?<\/strong> Untuk sebagian besar situs, ya \u2014 dan Google memang merekomendasikan desain responsif karena HTML yang dikirim sama untuk semua perangkat, sehingga paritas konten terjaga otomatis. Yang tetap perlu diperiksa adalah konten yang dimuat secara kondisional lewat JavaScript berdasarkan ukuran layar.<\/p>\n<p dir=\"ltr\"><strong>Apakah mobile first indexing sama dengan seo mobile atau optimasi seluler?<\/strong> Tidak sama. Mobile first indexing adalah soal versi mana yang dibaca Google untuk mengindeks halaman Anda. Optimasi seluler adalah soal seberapa baik pengalaman pengguna di ponsel \u2014 kecepatan, keterbacaan, kemudahan navigasi. Keduanya penting, tapi bekerja lewat mekanisme yang berbeda dan diperbaiki dengan cara yang berbeda.<\/p>\n<p dir=\"ltr\"><strong>Kenapa saya masih melihat Googlebot Desktop di log server saya?<\/strong> Karena Google menyatakan masih sesekali memakai perayap desktop untuk keperluan tertentu seperti product listing dan Google for Jobs. Kemunculannya di log bukan tanda situs Anda belum beralih ke mobile first indexing.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ada satu jenis penurunan ranking yang paling sulit saya jelaskan ke klien, dan bentuknya selalu sama: tidak ada yang terjadi. Tidak ada manual action. Tidak ada core update di tanggal itu. Core Web Vitals hijau. Halaman terindeks, statusnya normal, sitemap bersih. Tapi posisinya turun pelan-pelan selama tiga sampai empat bulan sampai halaman yang dulu di [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1907,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,1,12,13],"tags":[469,51,467,465,253,466,468,464,463,113],"class_list":["post-1906","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-off-page","category-on-page","category-technical","category-website","tag-ai-crawler","tag-google-search-console","tag-googlebot-smartphone","tag-indeks-mobile-google","tag-mobile-first-indexing","tag-optimasi-seluler","tag-paritas-konten-mobile","tag-responsive-design-seo","tag-seo-mobile","tag-technical-seo"],"_links":{"self":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1906","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/comments?post=1906"}],"version-history":[{"count":1,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1906\/revisions"}],"predecessor-version":[{"id":1908,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1906\/revisions\/1908"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media\/1907"}],"wp:attachment":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media?parent=1906"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/categories?post=1906"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/tags?post=1906"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}