Ada satu pola yang saya lihat berulang setiap kali seseorang mengirim pesan soal trafik yang turun. Mereka sudah punya tersangka sebelum saya lihat datanya. “Sepertinya crawl budget saya habis, Mas.” Lalu menyusul daftar hal yang sudah mereka lakukan: hapus beberapa artikel lama, blokir folder di robots.txt, pasang plugin optimasi. Trafiknya tetap datar. Kadang malah turun lagi.
Masalahnya bukan mereka salah paham soal definisi crawl budget. Definisinya biasanya sudah benar. Yang keliru adalah urutan diagnosanya. Crawl budget itu diagnosa akhir, bukan dugaan awal, dan untuk sebagian besar website di Indonesia ia sama sekali bukan penyebabnya. Tapi untuk sebagian kecil yang lain, ia penyebab yang sangat nyata dan sangat mahal.
Di tulisan ini saya mau memisahkan dua kelompok itu sejelas mungkin. Anda akan tahu cara menentukan apakah situs Anda termasuk yang perlu peduli, cara membaca laporan yang benar untuk membuktikannya, dan apa yang harus dilakukan kalau ternyata benar budget Anda bocor. Saya juga akan tunjukkan beberapa “optimasi” populer yang menurut saya justru memperburuk keadaan.
Mayoritas Website yang Mengeluh Soal Crawl Budget Sebenarnya Tidak Punya Masalah Crawl Budget
Saya mulai dari bagian yang paling tidak populer. Kalau situs Anda punya di bawah seribu URL dan artikel baru Anda terindeks dalam hitungan hari, crawl budget bukan masalah Anda. Titik. Googlebot tidak sedang kehabisan jatah di situs Anda, ia hanya sedang tidak tertarik.
Dua hal itu terlihat identik dari luar. Halaman tidak muncul di Google, dan Anda menyimpulkan Googlebot tidak sampai ke sana. Padahal di banyak kasus Googlebot sudah datang, sudah baca, dan memutuskan halaman itu tidak layak masuk indeks. Itu bukan soal anggaran perayapan. Itu soal kualitas dan permintaan.
Google sendiri cukup tegas soal siapa yang perlu membaca panduan crawl budget mereka: situs dengan lebih dari satu juta halaman unik yang berubah mingguan, atau situs di atas sepuluh ribu halaman dengan perubahan harian yang cepat, ditambah situs yang punya banyak URL berstatus “Discovered, currently not indexed” di Search Console. Kalau Anda tidak masuk salah satu dari tiga kategori itu, energi Anda lebih berguna dipakai di tempat lain.
Cara Cepat Menolak Diagnosa Crawl Budget
Ada satu tes lima menit yang biasanya saya jalankan lebih dulu. Ambil sepuluh URL yang Anda rasa tidak terindeks, cek satu-satu di URL Inspection di Search Console, lalu lihat kolom “Last crawl”. Kalau tanggalnya ada dan relatif baru, Googlebot tidak kehabisan budget. Ia datang lalu memilih tidak mengindeks. Beda penyebab, beda penanganan, dan ini bidang tersendiri yang saya bahas lebih jauh di tulisan soal siapa yang sebenarnya memutuskan sebuah halaman tidak terindeks Google.
Kalau kolom “Last crawl” kosong atau tanggalnya jauh di belakang, sementara halaman itu sudah lama ada dan sudah terhubung dari navigasi, barulah percakapan soal crawl budget jadi relevan.
Apa Itu Crawl Budget: Dua Angka yang Dikalikan, Bukan Satu Kuota Harian
Crawl budget bukan kuota harian yang diberikan Google ke setiap domain. Istilah ini adalah hasil pertemuan dua hal yang bergerak terpisah:
- Crawl capacity limit, batas kapasitas. Seberapa banyak koneksi yang boleh Googlebot pakai ke server Anda tanpa membebani situs. Ini ditentukan kesehatan server Anda: kestabilan waktu respons, dan ada tidaknya error 5xx atau sinyal 429.
- Crawl demand, permintaan perayapan. Seberapa besar keinginan Google mengakses konten Anda. Ini ditentukan ukuran inventaris situs, popularitas URL, kesegaran konten, dan seberapa sering Google merasa perlu memeriksa apakah halaman lama sudah berubah.
Crawl budget adalah irisan keduanya: himpunan URL yang Google bisa dan mau rayapi. Dua kata itu yang sering hilang dari pembahasan.
Kenapa pembedaan ini penting secara praktis? Karena obatnya berbeda total. Kalau masalah Anda di kapasitas, jawabannya ada di sisi teknis dan infrastruktur: waktu respons server, caching, menghentikan error. Kalau masalah Anda di permintaan, menambah RAM server tidak akan mengubah apa pun. Yang perlu diperbaiki adalah alasan Google merasa konten Anda layak sering dikunjungi.
Google menyebut hanya ada dua cara menaikkan crawl budget secara nyata: tambah kapasitas server, atau naikkan kualitas dan relevansi konten. Semua trik lain di luar dua itu bukan menaikkan anggaran, melainkan memindahkan alokasinya.
Dari Mana Googlebot Memutuskan Jatah Perayapan Situs Anda
Cara paling mudah memahami ini: bayangkan Googlebot punya waktu terbatas dan riwayat pengalaman dengan situs Anda. Ia mulai konservatif di semua situs baru, lalu menyesuaikan diri berdasarkan apa yang ia temukan.
Setiap kali server Anda merespons cepat dan konsisten, batas kapasitas naik sedikit. Setiap kali muncul timeout, error 500, atau respons yang melambat drastis di jam tertentu, batas itu ditarik turun, dan pemulihannya tidak instan. Ini yang membuat kebocoran crawl budget sering punya efek berantai: situs melambat karena dirayapi, kapasitas dipotong karena melambat, lalu halaman penting ikut kena imbasnya.
Di sisi permintaan, yang paling sering diremehkan adalah persepsi inventaris. Google tidak menghitung jumlah artikel Anda, ia menghitung jumlah URL yang bisa ia temukan. Situs dengan 300 artikel bisa punya 80 ribu URL yang bisa diakses kalau filter, urutan, pagination, dan parameter pelacakan semuanya menghasilkan alamat sendiri. Dari sudut pandang Googlebot, itu situs 80 ribu halaman yang isinya mayoritas duplikat.
Mekanisme dasar di balik semua ini, mulai dari penemuan URL sampai penjadwalan ulang perayapan, saya jabarkan lebih runtut di panduan tentang bagaimana Googlebot bekerja saat merayapi dan mengindeks sebuah situs, jadi di sini saya tidak akan mengulanginya.
Yang Saya Temukan Setelah Membaca Log Server: Budget Bocor di Tempat yang Tidak Anda Curigai
Ini bagian yang mengubah cara saya bekerja.
Bertahun-tahun saya mendiagnosis crawl budget hanya dari crawler pihak ketiga seperti Screaming Frog. Masalahnya, crawler itu menunjukkan apa yang bisa dirayapi. Ia tidak menunjukkan apa yang benar-benar dirayapi Googlebot. Dua hal yang kelihatan mirip tapi jauh berbeda.
Begitu saya mulai minta akses log server, gambarannya berubah. Pada satu proyek e-commerce dengan sekitar 4.000 halaman produk, tebakan awal saya adalah pagination kategori yang jadi biang keladi. Ternyata bukan. Porsi terbesar hit Googlebot dalam sebulan jatuh ke URL hasil kombinasi filter warna dan ukuran, halaman yang tidak pernah sekali pun mendatangkan klik organik. Halaman produk paling menguntungkan justru dirayapi paling jarang.
Yang membuat saya agak malu: sebelum melihat log, saya sudah menyiapkan rekomendasi memperbaiki pagination. Tiga minggu kerja yang hampir saya buang ke tempat yang salah.
Pelajaran yang saya pegang sejak itu sederhana. Tanpa log, semua rekomendasi optimasi crawl budget adalah hipotesis. Boleh dikerjakan, tapi jangan dijual sebagai kepastian.
Kenapa Log Server Tidak Tergantikan Laporan Lain
Search Console memberi Anda ringkasan. Log memberi Anda bukti per baris: user agent apa, jam berapa, URL mana, kode respons apa, berapa byte. Dari situ tiga pertanyaan bisa dijawab dengan angka, bukan opini:
- Berapa persen hit Googlebot jatuh ke URL yang tidak Anda inginkan di indeks?
- Berapa banyak hit terbuang ke respons 301, 404, dan 500?
- Kapan halaman-halaman terpenting Anda terakhir kali disentuh?
Kalau Anda pakai hosting bersama dan tidak bisa mengakses raw log, minta ke penyedia hosting. Dalam pengalaman saya sebagian besar bisa memberikan, hanya tidak pernah ditanya.
Diagnosis 4 Langkah: Dari Crawl Stats ke Keputusan Blokir
Ini urutan yang saya pakai. Sengaja bertahap, karena tiga langkah pertama gratis dan sering sudah cukup menutup kasusnya.
Langkah 1: Baca Crawl Stats, Bukan Jumlah Requestnya
Buka Settings lalu Crawl stats di Search Console. Abaikan dulu angka total request harian, itu angka yang paling sering disalahartikan sebagai skor. Yang Anda cari ada tiga:
- Average response time. Kalau grafiknya naik dari waktu ke waktu, kapasitas Anda sedang dipangkas dan penyebabnya ada di server, bukan di konten.
- By response. Berapa porsi yang bukan 200? Setiap 404, rantai 301, dan 5xx adalah hit yang dibelanjakan tanpa hasil.
- By purpose. Perbandingan Discovery dengan Refresh. Kalau Refresh mendominasi sangat berat sementara Anda rutin menerbitkan konten baru, artinya URL baru Anda sulit ditemukan, dan itu masalah tautan internal, bukan masalah anggaran.
Langkah 2: Hitung Rasio Inventaris Anda
Bandingkan jumlah URL yang Anda mau ada di indeks dengan jumlah URL yang bisa diakses crawler. Rasio 1 banding 3 masih wajar. Rasio 1 banding 20 adalah kebocoran, dan Anda sudah tahu ke mana harus melihat.
Angka pembanding ini biasanya saya ambil dari sitemap XML untuk sisi “mau”, dan dari hasil crawl penuh untuk sisi “bisa”.
Langkah 3: Kelompokkan Pemborosan Berdasarkan Pola URL, Bukan Satu-Satu
Jangan pernah menangani URL boros satu per satu. Kelompokkan berdasarkan pola. Biasanya yang muncul tidak lebih dari lima keluarga: parameter pelacakan, kombinasi filter, hasil pencarian internal, pagination dalam, dan varian urutan. Satu keputusan per keluarga jauh lebih mudah dipelihara daripada tiga puluh aturan tambal sulam.
Langkah 4: Pilih Instrumen yang Tepat untuk Tiap Keluarga
Di sini banyak orang tersandung, karena tiga instrumen ini terlihat mirip padahal fungsinya berbeda:
| Situasi | Instrumen yang benar | Alasan |
|---|---|---|
| URL tidak berguna dan tidak perlu dilihat Google sama sekali | Disallow di robots.txt | Menghentikan perayapan sebelum biaya dikeluarkan |
| URL perlu diakses tapi tidak boleh masuk indeks | noindex | Masih dirayapi, jadi tidak menghemat anggaran |
| Beberapa URL menyajikan konten sama | Canonical | Sinyal konsolidasi, bukan penghematan perayapan |
| Halaman sudah dihapus permanen | 404 atau 410 | Memberi kepastian, hentikan kunjungan ulang |
Satu hal yang perlu ditekankan: noindex tidak menghemat crawl budget. Google tetap harus merayapi halaman itu untuk membaca instruksinya. Kalau tujuan Anda benar-benar penghematan anggaran, hanya robots.txt yang bekerja di level itu. Teknis penulisan aturannya, termasuk kesalahan sintaks yang paling sering saya temui di audit, ada di panduan setting robots.txt untuk WordPress, Wix, dan Shopify.
Kalau proses empat langkah ini terasa terlalu banyak untuk dijalankan sendirian sambil mengurus hal lain, biasanya hasilnya jauh lebih cepat kalau tahap diagnosanya dikerjakan bersama, terutama di bagian pembacaan log yang paling sering jadi titik macet. Itu salah satu pekerjaan yang saya tangani lewat jasa SEO.
Lima Kesalahan Optimasi Crawl Budget yang Justru Memperburuk Keadaan
Saya urutkan dari yang paling sering saya temui.
Memblokir folder besar tanpa memeriksa isinya. Disallow adalah instrumen tumpul. Saya pernah menemukan situs yang memblokir seluruh direktori aset demi “menghemat crawl”, dan akibatnya Google tidak bisa merender halamannya dengan benar. Hemat anggaran, rusak peringkat.
Menghapus artikel lama dengan harapan budget beralih ke artikel baru. Ini hampir tidak pernah bekerja seperti yang dibayangkan. Google menyatakan bahwa memblokir sebagian situs sementara untuk memindahkan anggaran ke bagian lain tidak menggeser kapasitas, kecuali batas kapasitas Anda memang sudah terlampaui. Untuk situs kecil, yang Anda dapat dari menghapus artikel bukan tambahan anggaran, melainkan kehilangan halaman.
Mengejar jumlah request Googlebot seperti mengejar KPI. Request naik bukan berarti bagus. Pada situs dengan banyak URL sampah, request naik justru gejala kebocoran. Yang layak jadi ukuran adalah proporsi hit ke URL bernilai, bukan totalnya.
Memasang noindex di ribuan halaman lalu menganggap pekerjaan selesai. Seperti di tabel tadi, noindex tidak mengurangi perayapan. Di beberapa kasus efek jangka panjangnya justru Google menurunkan frekuensi kunjungan ke seluruh pola URL itu, termasuk yang sebenarnya Anda butuhkan.
Mengurus crawl budget sementara waktu respons server dibiarkan buruk. Ini yang paling sering saya lihat pada situs WordPress berplugin berat di hosting bersama. Semua pekerjaan pemangkasan URL bisa hilang efeknya kalau kapasitas terus dipotong karena server lambat. Perbaiki urutannya: kesehatan server dulu, arsitektur URL kemudian.
Kalau saya harus memilih satu pesan dari daftar ini: crawl budget bukan sesuatu yang “dioptimasi” dengan satu tindakan. Ia hasil samping dari situs yang teknisnya sehat dan strukturnya masuk akal.
Crawl Budget di Era Bot AI: Anggaran Baru yang Belum Dihitung Siapa Pun
Bagian ini jarang masuk pembahasan, padahal sejak dua tahun terakhir dampaknya makin terasa di log yang saya baca.
Semua diskusi crawl budget klasik berpusat pada Googlebot. Sementara itu, hit dari GPTBot, ClaudeBot, PerplexityBot, dan kerabatnya sekarang bisa mengambil porsi yang nyata dari kapasitas server Anda. Perlu diluruskan supaya tidak salah kaprah: bot-bot ini tidak mengurangi anggaran perayapan Google secara langsung. Yang mereka lakukan lebih halus dan justru lebih berbahaya.
Mereka membebani server yang sama. Dan batas kapasitas Googlebot ditentukan oleh kesehatan server itu. Jadi jalurnya seperti ini: trafik bot AI naik, waktu respons memburuk, Googlebot menarik turun kapasitasnya. Crawl budget Anda terpotong bukan karena Google berubah pikiran, tapi karena tamu lain menghabiskan bandwidth di ruang yang sama.
Implikasi praktisnya ada dua, dan keduanya bertolak belakang, jadi perlu keputusan sadar:
- Untuk situs dengan server terbatas, identifikasi bot mana yang paling agresif di log Anda, lalu atur crawl-delay atau blokir yang tidak memberi nilai apa pun.
- Untuk situs yang ingin dikutip di jawaban AI, memblokir bot pengambil konten sama dengan memilih tidak hadir di kanal itu. Biaya kesempatannya nyata.
Keputusan mana yang tepat tergantung target Anda, bukan tergantung praktik terbaik umum. Yang jelas Anda tidak bisa memutuskan tanpa tahu siapa saja yang sedang mengetuk pintu, dan saya sudah mengelompokkan siapa saja mereka di daftar website crawler 2026 yang memisahkan bot Google dan bot AI.
Satu catatan teknis yang menurut saya paling kurang dimanfaatkan di seluruh topik ini: dukungan header 304 Not Modified. Kalau server Anda bisa menjawab “tidak ada perubahan” tanpa mengirim ulang seluruh halaman, Anda menghemat kapasitas di setiap kunjungan ulang, untuk semua crawler sekaligus. Ini hal yang masuk daftar rekomendasi resmi Google, tapi hampir tidak pernah saya lihat diterapkan di situs Indonesia yang saya audit.
Mulai dari Satu Laporan, Bukan dari Satu Plugin
Kalau ada satu hal yang saya harap tersangkut setelah membaca ini: jangan mulai dari tindakan, mulai dari pembuktian.
Crawl budget adalah topik yang mengundang orang untuk langsung bergerak. Rasanya produktif memblokir sesuatu, menghapus sesuatu, memasang sesuatu. Tapi setiap tindakan yang dilakukan sebelum diagnosa hanya menambah variabel yang nanti harus Anda urai lagi.
Langkah pertama yang saya sarankan sangat kecil, dan bisa Anda lakukan dalam sepuluh menit hari ini: buka Crawl stats di Search Console, catat average response time dan porsi respons non-200. Dua angka itu saja. Kalau keduanya sehat dan situs Anda di bawah seribu URL, Anda baru saja menghemat berminggu-minggu kerja yang tidak perlu, dan bisa kembali ke pekerjaan yang benar-benar menggerakkan trafik.
Kalau keduanya tidak sehat, sekarang Anda punya titik awal yang benar.
Butuh bantuan yang lebih hands-on untuk tahap diagnosa dan pembenahannya? Detail layanan yang saya tangani bisa dicek di https://achmadfarid.com/jasa-seo/.
Pertanyaan yang Sering Diajukan
Berapa crawl budget website saya? Tidak ada satu angka resmi yang bisa Anda lihat. Yang paling dekat adalah total request Googlebot per hari di laporan Crawl stats Search Console. Perlakukan itu sebagai indikator tren, bukan sebagai kuota yang diberikan Google.
Apakah website kecil perlu mengoptimasi crawl budget? Umumnya tidak. Kalau situs Anda di bawah seribu URL dan konten baru terindeks dalam beberapa hari, waktu Anda lebih bernilai dipakai untuk kualitas konten dan tautan internal.
Apakah noindex menghemat crawl budget? Tidak. Googlebot tetap harus merayapi halaman untuk membaca tag noindex. Kalau tujuan Anda menghentikan perayapan, instrumennya disallow di robots.txt, dengan catatan halaman itu memang tidak perlu dinilai Google sama sekali.
Kenapa halaman saya berstatus “Discovered, currently not indexed”? Status itu berarti Google sudah tahu URL-nya tapi belum merayapinya. Pada situs besar ini memang sering terkait kapasitas perayapan. Pada situs kecil, penyebab yang lebih sering adalah tautan internal yang lemah atau sinyal kualitas yang belum cukup.
Apakah menghapus artikel lama menaikkan crawl budget untuk artikel baru? Hampir tidak pernah, dan untuk situs kecil ini cenderung merugikan. Anggaran tidak berpindah begitu saja antarbagian situs. Memperbarui artikel lama yang masih relevan biasanya memberi hasil jauh lebih baik daripada menghapusnya.
Apakah bot AI seperti GPTBot mengurangi crawl budget Google? Tidak secara langsung, tapi efeknya bisa sampai juga. Bot AI membebani server yang sama, dan waktu respons yang memburuk bisa membuat Google menurunkan batas kapasitas perayapannya.
English 