PageSpeed Insights sudah bertahun-tahun memberi skor untuk Performa, Aksesibilitas, Praktik Terbaik, dan SEO. Pada 2026, satu item kelima diam-diam bergabung di baris itu: Agentic Browsing. Item ini menjawab satu pertanyaan yang diabaikan empat kategori lain — apakah agen AI benar-benar bisa bekerja dengan halaman ini?
Panduan ini tentang memakai pemeriksaan itu di situs Anda sendiri: menjalankannya, membaca apa yang sebenarnya dikatakan tiap audit, dan pulang dengan daftar perbaikan.
Yang akan Anda dapatkan di akhir
Untuk siapa: tim SEO, pengembang, dan pemilik situs yang ingin tahu bagaimana halaman mereka berperilaku ketika yang menjelajah adalah agen, bukan manusia.
Yang akan Anda miliki setelah selesai: hasil Agentic Browsing yang nyata untuk situs Anda, bacaan per pemeriksaan tentang apa yang lulus, gagal, atau tidak berlaku, dan daftar perbaikan yang sudah diprioritaskan.
Prasyarat: URL yang bisa diakses publik, sekitar sepuluh menit untuk menjalankan pertama kali, dan akses kode jika Anda berencana memperbaiki sesuatu di hari yang sama.
Definisi selesai: Anda bisa menjelaskan skor pecahan Anda audit demi audit, dan bisa menyebut kegagalan mana yang benar-benar menghalangi agen menyelesaikan tugas di halaman Anda.
Dari mana pemeriksaan ini berasal, dan kenapa sekarang
Kategori Agentic Browsing belum ada setahun lalu. Peluncurannya terjadi dalam tiga langkah, semuanya didokumentasikan Google:
- 7 Mei 2026: Lighthouse 13.3 menambahkan kategori ini ke konfigurasi bawaannya, sehingga menjadi bagian dari proses standar.
- 22 Juni 2026: blog Chrome for Developers mengumumkannya dalam "A developer toolkit to make your website agent-ready", bersama DevTools for agents dan panduan WebMCP.
- 20 Juli 2026: Lighthouse 13.4.1 mengaktifkan kategori ini untuk jalur API PageSpeed Insights dan menyebut rilis ini akan sampai ke PageSpeed Insights "dalam 2 minggu". Artinya peluncuran publik terjadi pada awal Agustus 2026.
Saat saya menjalankan pemeriksaan ini pada 11 September 2026, footer laporan berbunyi "Emulated Moto G Power with Lighthouse 13.4.1", dan Agentic Browsing berada tepat di samping SEO. Jadi fitur ini sudah aktif, bukan hanya kanari. Fitur ini juga secara eksplisit belum selesai. Deskripsi kategori di laporan mengatakannya dengan gamblang: "This category is still under development and subject to change."
Satu catatan praktis sebelum mulai: PSI menjalankan kategori ini untuk Anda, di sisi Google. Anda tidak perlu Chrome 150 atau origin trial untuk pemeriksaan tingkat halaman. Yang punya syarat versi adalah menjalankannya di lokal lewat Chrome DevTools.
Jalankan pemeriksaan di situs Anda
- Buka pagespeed.web.dev dan tempel URL Anda. Jalankan untuk mobile dulu, lalu ulangi untuk desktop, karena dua uji lab ini dinilai terpisah.
- Tunggu data lab selesai. Data lapangan di atas berasal dari Chrome UX Report dan cepat termuat. Uji Lighthouse di bawahnya butuh lebih lama, dan di situlah kategori berada.
- Temukan baris skor. Anda akan melihat Performa, Aksesibilitas, Praktik Terbaik, SEO, lalu Agentic Browsing sebagai pecahan, bukan skor 0–100.
- Buka kategorinya. Daftar audit dikelompokkan menjadi Agent Accessibility, WebMCP, dan kumpulan lulus serta tidak berlaku seperti biasa.
- Buka setiap audit yang gagal. Setiap baris bisa dibuka dan menunjukkan aturan, elemen, atau file spesifik di balik kegagalan — inilah yang Anda butuhkan untuk tiket perbaikan.
Kategori kelima berada di baris yang sama dengan skor yang diperiksa tim SEO setiap hari. Diambil di PageSpeed Insights pada 11 September 2026.
Pemeriksaan kualitas: pastikan versi Lighthouse di detail uji sebelum membandingkan hasil dengan rekan. PSI memperbarui Lighthouse sesuai jadwalnya sendiri, dan kategori ini masih berubah antar versi.
Jika gagal: PSI kadang mengembalikan timeout RPC pada halaman berat. Itu terjadi pada saya di sebuah situs besar saat riset. Coba lagi, atau uji halaman itu dengan Lighthouse lokal.
Baca skor pecahan dengan benar
Agentic Browsing tidak punya skor berbobot 0–100, dan itu memang disengaja. Dokumentasi Lighthouse menyebut standar untuk web agentik masih terbentuk, jadi fokusnya pada sinyal yang bisa ditindaklanjuti, bukan peringkat.
Inilah aritmetika yang sebenarnya penting:
Tampilan | Artinya |
|---|---|
3/3 | Semua pemeriksaan yang dinilai lulus. Pemeriksaan yang tidak berlaku dikecualikan. |
1/3 | Satu lulus, dua gagal. Penyebutnya hanya pemeriksaan yang lulus dan gagal. |
0/3 | Belum ada pemeriksaan bernilai yang lulus. Umum pada uji pertama di halaman berat penuh iklan. |
Tanpa pecahan | Semua audit tidak berlaku atau kategorinya belum dijalankan. Periksa detail uji. |
Jebakannya adalah membaca 1/3 sebagai "33 persen siap agen". Itu bukan persentase apa pun. Itu sebuah hitungan: satu dari tiga pemeriksaan yang bisa dinilai di halaman tersebut lulus, dan audit yang tidak berlaku dikeluarkan sepenuhnya dari perhitungan. Di laporan yang saya ambil, enam audit berjalan, tiga tidak berlaku, dan tiga sisanya menghasilkan 1/3.
Skor juga bergerak antar uji di halaman yang sama. Tiga penyebab yang disebut Lighthouse adalah pendaftaran alat dinamis (alat WebMCP yang didaftarkan lewat JavaScript bisa tertangkap atau terlewat tergantung waktu), perubahan DOM yang mengubah bentuk pohon aksesibilitas, dan pergeseran tata letak dari iklan, gambar tanpa ukuran, atau konten yang disuntikkan. Kalau angka Anda berubah-ubah, biasanya itu penyebabnya.
Telusuri keenam auditnya
Build PSI saat ini menjalankan enam audit. Satu lagi akan menyusul: cabang pengembangan Lighthouse sudah menambahkan pemeriksaan ai-catalog.json (Agent Resource Discovery) di bawah grup baru Agent Discoverability, jadi anggap daftar ini bergantung versi.
Audit | Yang diperiksa | Arti "tidak berlaku" |
|---|---|---|
Pohon aksesibilitas tidak terbentuk dengan baik | Sebagian aturan aksesibilitas yang fokus pada agen: nama dan label programatik, struktur ARIA yang valid, dan elemen yang tetap interaktif meski disembunyikan dari pohon | Tidak pernah; ini selalu dinilai |
llms.txt tidak mengikuti rekomendasi | Apakah | File mengembalikan 404. llms.txt yang tidak ada dianggap opsional, bukan kegagalan |
Pergeseran Tata Letak Kumulatif | Stabilitas visual, agar agen yang bertindak berdasarkan posisi elemen tidak mengklik hal yang salah saat bergeser | Tidak pernah; ini selalu dinilai |
Alat WebMCP terdaftar | Apakah halaman mendaftarkan alat WebMCP lewat API deklaratif atau imperatif | Tidak terdeteksi adanya alat WebMCP |
Cakupan borang WebMCP | Borang deklaratif yang kehilangan anotasi alat | Sama seperti di atas |
Skema WebMCP valid | Bahwa alat yang terdaftar menerbitkan skema input dan output yang valid | Sama seperti di atas |
Tampilan kategori yang diperluas: dua kegagalan, satu lulus, dan tiga pemeriksaan tidak berlaku. Daftar kegagalan adalah jalur terpendek menuju item pekerjaan.
Tiga audit WebMCP yang menampilkan "tidak berlaku" itu normal pada 2026. WebMCP adalah standar yang diusulkan, dalam origin trial dan pratinjau awal, dengan dua API: deklaratif yang menganotasi borang HTML standar, dan imperatif yang mendaftarkan alat dari JavaScript. Sebagian besar situs belum menerapkan keduanya, jadi sebagian besar laporan menampilkan tiga lingkaran kelabu di sana. Kelabu bukan merah. Jangan menganggapnya kegagalan.
Perbaiki apa yang ditandai pemeriksaan
Empat tema perbaikan mencakup keenam audit. Tiga baris WebMCP hanya perlu perhatian kalau Anda benar-benar mengirim alat agen.
Buat pohon aksesibilitas terbaca oleh agen
Agen bersandar pada pohon aksesibilitas sebagai peta utama halaman Anda. Di sana tercatat peran, nama, dan status. Tombol tanpa nama aksesibel adalah jalan buntu bagi mereka, dan juga bagi pengguna pembaca layar.
Tindakan: kerjakan aturan yang gagal dari audit yang diperluas. Tersangka biasanya tombol hanya ikon, kolom borang tanpa label, tautan yang teksnya cuma "klik di sini", kombinasi peran ARIA yang tidak valid, dan ID duplikat yang dirujuk ARIA. Utamakan HTML semantik, tambahkan atribut for pada label, dan beri widget kustom peran eksplisit serta tabindex ketika elemen native tidak memungkinkan.
Hasil yang diharapkan: audit berbalik lulus, dan skor Aksesibilitas biasa Anda biasanya ikut membaik, karena versi Agentic Browsing adalah subset terfokus dari pemeriksaan yang sama.
Jalur pemulihan: kalau daftar perbaikan mencapai ratusan elemen, jangan kejar satu per satu. Perbaiki komponen bersama, misalnya tombol hanya ikon di header Anda, lalu jalankan ulang. Satu komponen sering membersihkan puluhan baris.
Terbitkan llms.txt yang lolos pemeriksaan format
Yang ini punya jebakan yang menjebak orang teliti. Audit tidak hanya memeriksa keberadaan /llms.txt. Audit memeriksa isi file, dan file yang mencantumkan URL telanjang akan gagal, karena pemeriksaannya mencari tautan bergaya Markdown.
Tindakan: buat /llms.txt di domain akar Anda dengan heading H1 dan tautan Markdown sungguhan:
# Your Company
Short description of what the site covers and how it should be used.
## Key pages
- [Product overview](https://example.com/product)
- [Pricing](https://example.com/pricing)
- [Documentation](https://example.com/docs)Hasil yang diharapkan: audit menjadi hijau. Sebaliknya, 404 tampil sebagai tidak berlaku, yang masih dapat diterima hari ini. Respons seri 500, atau error pengambilan, adalah kegagalan nyata yang butuh perbaikan server.
Pemeriksaan kualitas: ambil /llms.txt Anda sendiri di terminal dan hitung tautannya. Kalau bentuknya seperti https://example.com/pricing tanpa tanda kurung siku, audit akan gagal meskipun filenya aktif dan terbaca manusia.
Satu catatan jujur: Google Search tidak memakai llms.txt. Panduan optimasi AI Google sendiri menyebut file ini "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them". Tulis untuk perkakas agen yang membaca konvensi itu, bukan untuk peringkat.
Stabilkan tata letak agar agen bisa membidik
Pergeseran tata letak lebih penting dari sebelumnya. Agen yang menemukan tombol lalu mengklik koordinatnya akan meleset kalau iklan, banner, atau gambar yang lambat termuat mendorong tombol itu 200 piksel ke bawah di antara dua momen tersebut.
Tindakan: tetapkan lebar dan tinggi eksplisit (atau aspect-ratio) pada gambar dan embed, sediakan ruang tetap untuk slot iklan dan banner persetujuan, hindari menyisipkan konten di atas konten yang sudah ada setelah pemuatan, dan animasikan dengan transform alih-alih properti yang memicu tata letak.
Hasil yang diharapkan: Pergeseran Tata Letak Kumulatif di bawah 0,1 pada uji lab, ambang yang sama dipakai Core Web Vitals.
Pemeriksaan kualitas: insight Layout shift culprits di bawah Performa menyebut elemen persis yang bertanggung jawab. Mulai dari sana daripada menebak.
Putuskan soal WebMCP nanti
Tiga audit WebMCP hanya dinilai kalau situs Anda mendaftarkan alat. Kalau Anda menjalankan alur pemesanan, checkout, borang dukungan, atau tugas terstruktur apa pun yang bisa diselesaikan agen, WebMCP layak diprototipekan: ini memberi tahu agen alat mana yang harus dipanggil, bukan membuat mereka menebak dari DOM. Chrome merilis fitur ini di balik origin trial dan flag pengujian lokal, jadi ini opsi nyata, bukan eksperimen pikiran.
Kalau tidak ada tugas yang layak diotomatiskan, biarkan WebMCP. Tidak ada yang salah dengan tiga lingkaran kelabu. Satu hal yang jangan dilakukan adalah mendaftarkan alat dekoratif hanya agar pecahannya terlihat lebih baik. Kategori ini sinyal kesiapan, dan mempermainkannya menghancurkan tujuannya.
Verifikasi perbaikannya
Jalankan ulang URL yang sama di PSI dan bandingkan tiga hal, bukan satu: pecahannya, status tiap audit, dan jenis perangkat. Sebuah perbaikan bisa menggeser pecahan tanpa memperbaiki hal yang Anda pedulikan, dan mobile serta desktop menghasilkan hasil lab terpisah.
Untuk iterasi lebih cepat, jalankan Lighthouse secara lokal daripada menunggu PSI. Kategori ini ada di Lighthouse 13.3 dan setelahnya, jadi instalasi lokal akan membawanya. Kalau Anda ingin versi panel DevTools, dokumentasi Google mencatat bahwa menguji kategori ini butuh Chrome 150 atau lebih baru, dan audit WebMCP juga butuh origin trial terdaftar.
Simpan catatan singkat sebelum-sesudah. Satu baris bertanggal seperti "2026-09-11: mobile 1/3, gagal pohon a11y + llms.txt" sudah cukup. Itu memberi tahu apakah regresi di kemudian hari nyata atau sekadar goyangan antar uji.
Apa yang bukan pemeriksaan ini
Tiga hal yang tidak dilakukannya, karena kebingungannya luas:
- Ini bukan faktor peringkat. Pengumuman Chrome menyebut kategori ini informasional dan tanpa benchmark. Peringkat Google Search tidak terpengaruh oleh pecahan Agentic Browsing Anda.
- Ini bukan skor visibilitas AI. Ini mengukur apakah agen bisa mengoperasikan halaman Anda. Tidak ada kaitannya dengan apakah ChatGPT atau Perplexity mengutip Anda dalam sebuah jawaban.
- Ini bukan vonis lulus/gagal untuk situs Anda. Pecahan rendah di halaman pemasaran sederhana biasanya berarti sedikit yang bisa dinilai, bukan bahwa agen terkunci di luar.
Lensa yang membantu: kategori ini memeriksa apakah situs Anda bertahan ketika pengunjungnya bukan manusia. Semua yang dihargainya tetap layak dikerjakan: HTML semantik, tata letak stabil, kontrol berlabel. Panduan agen-friendly dari Google sendiri menutup dengan poin yang sama: yang membuat situs siap agen juga membuatnya lebih baik untuk manusia.
Simpan di siklus tinjauan Anda
Kesiapan agen adalah salah satu area di mana platform bergerak lebih cepat daripada checklist. Dua kebiasaan menjaga Anda tetap mutakhir tanpa mengubahnya jadi proyek:
- Jalankan ulang pemeriksaan setelah setiap perubahan template, navigasi, borang, atau checkout. Itu editan yang menggeser pohon aksesibilitas dan kestabilan tata letak.
- Lacak pecahannya per template, bukan per URL. Sepuluh halaman produk yang semuanya bernilai sama adalah masalah template, dan satu perbaikan menyelesaikan semuanya.
Pemeriksaan PSI sengaja sempit: enam audit, satu halaman setiap kali. Kalau Anda ingin gambaran yang lebih luas — termasuk apakah aturan robots, kartu server MCP, penemuan OAuth, dan sinyal perdagangan agen sudah siap — Auspia memelihara pemeriksaan Agent Readiness gratis yang memindai URL terhadap standar tingkat protokol tersebut dan menampilkan papan peringkat untuk perbandingan.
FAQ
Apakah skor Agentic Browsing memengaruhi peringkat Google? Tidak. Google menyebut kategori ini informasional dan tidak termasuk sistem peringkat Search. Perlakukan sebagai pemeriksaan kesiapan untuk agen, bukan skor SEO.
Kenapa pecahan saya berubah antara dua uji di halaman yang sama? Pendaftaran alat dinamis, perubahan DOM yang mengubah pohon aksesibilitas, dan pergeseran tata letak yang terlambat semuanya menyebabkan variasi antar uji. Uji ulang, dan bandingkan daftar auditnya, bukan hanya pecahannya.
Kenapa ketiga audit WebMCP tampil tidak berlaku? Karena halaman Anda tidak mendaftarkan alat WebMCP. Itu kondisi yang diharapkan untuk sebagian besar situs pada 2026, dan bukan kegagalan.
Apakah llms.txt yang hilang jadi masalah? Untuk audit ini, tidak. 404 diperlakukan sebagai tidak berlaku. File yang ada tapi cacat akan gagal, jadi kalau Anda menerbitkannya, terbitkan dengan benar.
Bisakah saya menjalankannya di CI? Bisa, setelah kategori ini ada di versi Lighthouse Anda. Auditnya deterministik by design, itulah yang membuatnya cocok untuk pemeriksaan pipeline. Ingat bahwa bagian WebMCP bergantung pada dukungan browser dan keikutsertaan origin trial, jadi perkirakan bagian itu terbaca tidak berlaku di sebagian besar lingkungan CI.
Apakah saya butuh Chrome 150 untuk memakainya? Tidak. PageSpeed Insights menjalankannya di sisi server. Syarat Chrome 150 berlaku untuk menjalankan kategori ini secara lokal di DevTools.
Penulis: Alice Monroe, Analis Alat AI SEO yang meliput 150+ alat di Auspia. Alice menulis tentang SEO dan perkakas pencarian AI, pemeriksaan mana yang layak waktu Anda, dan cara menyelipkannya ke rutinitas kerja.
