Crawl budget layak diselidiki ketika volume URL, kecepatan perubahan, atau keterlambatan pengambilan halaman menimbulkan masalah yang dapat dibuktikan. Ia bukan diagnosis otomatis untuk setiap artikel yang belum terindeks. Website kecil sering lebih terbantu oleh perbaikan link, akses, dan isi daripada upaya mengatur crawl secara rumit.
Google menjelaskan crawl budget melalui kapasitas crawling dan permintaan crawling. Panduannya terutama ditujukan pada situs besar, sering berubah, atau memiliki banyak URL discovered yang belum diambil. Angka ukuran situs dalam panduan merupakan perkiraan, bukan batas matematis. Panduan crawl budget Google.
Ubah keluhan menjadi pertanyaan yang bisa diukur
“Google jarang datang” belum cukup. Pilih pertanyaan seperti: apakah produk baru yang penting terlambat diambil, apakah server gagal saat crawler meminta halaman, atau apakah request didominasi kombinasi filter yang tidak diperlukan?
Kamu membutuhkan rentang waktu, daftar URL penting, sumber waktu perubahan, dan bukti request atau laporan crawl. Jika salah satunya tidak tersedia, catat keterbatasannya sebelum menghitung.
Jangan menyamakan tanggal URL masuk sitemap dengan tanggal pertama kali Google mengetahuinya. Keduanya peristiwa berbeda dan tidak selalu dapat diamati secara lengkap.
Kelompokkan URL berdasarkan fungsi
Contoh ilustratif inventory toko:
| Kelompok | Jumlah URL diketahui | Fungsi | Bukti yang perlu dilihat |
|---|---|---|---|
| Produk aktif | 3.000 | Keputusan pembelian | Pengambilan setelah perubahan data |
| Kategori | 80 | Penemuan produk | Jalur link dan respons |
| Filter kombinasi | 90.000 | Penyaringan | Pola berguna versus berulang |
| URL lama | 400 | Rujukan historis | Redirect dan sumber link |
Angka hanya simulasi. Inventory besar sendiri belum membuktikan kapasitas crawling habis. Lihat request yang benar-benar terjadi dan apakah halaman penting mengalami hambatan.
Periksa server dan pola request bersama
Gunakan Crawl Stats untuk melihat riwayat permintaan, respons, dan masalah ketersediaan. Catat cakupan properti karena resource di host lain dapat berada di luar laporan. Request dalam rantai redirect dihitung per langkah, sehingga jumlah request bukan jumlah halaman unik. Dokumentasi Crawl Stats.
Jika punya log, pertahankan respons gagal dalam analisis. Menghapus semua 4xx dan 5xx membuat laporan tampak bersih tetapi menghilangkan petunjuk masalah akses. Pisahkan HTML, gambar, script, dan resource lain sebelum membandingkan jumlah.
Tanyakan apakah peningkatan waktu respons bersamaan dengan error server dan keterlambatan pengambilan. Hubungan waktu membantu membentuk hipotesis, tetapi belum membuktikan satu penyebab tanpa pemeriksaan sistem.
Contoh diagnosis yang menghasilkan tindakan
Misalnya log terverifikasi menunjukkan banyak request ke kalender yang dapat maju tanpa batas. Pada saat sama, URL produk baru hanya terhubung dari pencarian internal. Dua masalah ditemukan: ruang URL kalender yang tidak terkendali dan jalur penemuan produk yang lemah.
Tindakan untuk kalender adalah memperbaiki pembentukan serta pengelolaan URL yang tidak diperlukan. Tindakan untuk produk adalah menyediakan jalur kategori yang dapat diikuti. Jangan hanya memblokir kalender lalu menganggap produk otomatis mudah ditemukan.
Bila server menghasilkan error saat beban tinggi, libatkan developer untuk memeriksa cache, query data, dan kapasitas berdasarkan bukti. Jangan membeli paket hosting lebih mahal sebelum mengetahui komponen yang lambat.
Rencanakan pengamatan sebelum perubahan
| Pertanyaan | Sebelum | Sesudah | Batas kesimpulan |
|---|---|---|---|
| Apakah pola kalender berkurang? | Request per pola | Periode setara | Volume total dapat berubah |
| Apakah produk punya jalur link? | Crawl graph | Crawl ulang bagian terkait | Bukan bukti indeks |
| Apakah respons membaik? | Waktu dan error | Konfigurasi sebanding | Beban pengguna dapat berubah |
| Apakah produk diambil? | Log per URL | Log per URL | Pengambilan tidak menjamin indexing |
Pilih periode sesuai ritme website. Tidak ada kewajiban menunggu tepat sekian hari untuk setiap situs. Perbandingan harus cukup mewakili pola perubahan yang sedang diteliti.
Jika request filter turun tetapi pengambilan produk tidak berubah, jangan mengklaim masalah telah selesai. Periksa kembali jalur kategori, waktu publikasi, dan apakah URL penting memang masuk dalam cakupan data. Hasil negatif atau belum jelas tetap memberi informasi tentang hipotesis awal.
Hindari perbaikan yang menghilangkan bukti
Pemblokiran luas dapat menghalangi crawler membaca canonical atau noindex. Penghapusan halaman karena jarang diambil juga bisa menghilangkan informasi yang dibutuhkan pengguna. Putuskan berdasarkan fungsi URL dan urutan tindakan yang benar.
Langkah pertama adalah membandingkan satu kelompok URL penting dengan satu kelompok variasi yang dicurigai. Kalau tidak ada bukti masalah skala crawling, kembali ke pemeriksaan akses, link, rendering, dan isi. Menentukan bahwa crawl budget bukan prioritas juga merupakan hasil diagnosis yang berguna.
