Pada posting sebelumnya saya menunjukkan bagaimana ibahasa.com kedatangan satu pola scraper yang menyamar sebagai Googlebot. Pola itu memakai banyak alamat IP agar terlihat seperti pengunjung biasa. Sekarang saya tunjukkan cara memeriksanya dan bagaimana membedakan Googlebot asli dari yang palsu.
User-Agent hanyalah teks yang dikirim pengunjung kepada server. Isinya belum membuktikan siapa pengunjung itu sebenarnya.
Kenapa Bot Mengaku sebagai Googlebot
Banyak situs memberi perlakuan khusus kepada crawler yang mengaku sebagai Google. Misalnya, pembatasan laju dibuat lebih longgar agar proses pengindeksan tidak terganggu. Penyerang tahu ini, jadi mereka menulis ulang header User-Agent supaya terbaca seperti Googlebot resmi. Di level server, header itu tidak diverifikasi siapa pun secara otomatis.
Padahal memeriksa Googlebot itu mudah. Kuncinya bukan di User-Agent, tapi di DNS.
Cek Manual via Perintah DNS bawaan
Googlebot asli selalu bisa dibuktikan lewat pengecekan DNS dua arah. Siapa pun bisa mencobanya dari terminal:
host 66.249.66.34
# hasil: crawl-66-249-66-34.googlebot.com
host crawl-66-249-66-34.googlebot.com
# hasil: 66.249.66.34 (kembali persis ke IP semula)Langkah pertama mencari nama domain balik dari IP yang mengaku Googlebot. Langkah kedua mencari lagi IP dari nama domain itu. Kalau hasilnya kembali persis ke IP semula, itu asli. Kalau satu langkah saja gagal, atau baliknya ke domain lain, itu bukan Googlebot, apa pun isi header User-Agent-nya.
Nama domain balik itu disebut PTR, dan pencariannya disebut reverse DNS. Google memublikasikan daftar pola domainnya, jadi pemeriksaan ini tidak bergantung pada tebak-menebak.
Cek Otomatis untuk Ratusan IP
Cek manual satu-satu tidak mungkin untuk puluhan sampai ratusan alamat IP per hari. Karena itu saya memasang script kecil berbahasa Python di server ibahasa. Script ini mengotomatiskan pemeriksaan yang sama, dengan tiga tambahan:
- Ia mengenali mesin pencari dari User-Agent: Googlebot, Bingbot, Yandex, Baiduspider, AhrefsBot, dan lainnya, lalu memeriksa PTR masing-masing.
- Pemeriksaannya paralel dan hasilnya di-cache. IP yang sudah terverifikasi tidak dicek ulang, sehingga beban DNS tetap kecil.
- Ada kuota lookup per hari, supaya script ini tidak bisa dipakai untuk membebani server DNS.
Ada satu detail yang saya pelajari dari pembangunan script ini, dimana hasil pemeriksaan harus dibedakan menjadi tiga, bukan dua. IP dengan PTR yang cocok berarti asli. IP yang DNS-nya berhasil dijawab tapi tidak cocok berarti palsu. Lalu IP yang pemeriksaannya gagal, misalnya karena server DNS sedang sibuk atau timeout. Kegagalan cek bukan bukti pemalsuan. IP seperti itu tidak saya cap palsu, tapi saya coba lagi pada pemeriksaan berikutnya.
Ada pula alamat IP yang belum sempat diperiksa karena kena kuota harian. Alamat-alamat ini saya catat sebagai belum diverifikasi, dan saya laporkan secara terpisah. Sebab kalau tidak, angka “sekian asli, sekian palsu” terlihat lengkap padahal sebagian datanya hilang tanpa jejak.
Cara Lainnya
Kabar baiknya, cara ini tidak harus dibangun dari nol. Ada beberapa proyek open source yang mengotomatiskan pemeriksaan yang sama, tinggal pasang. Saya ambil dua yang paling banyak dipakai, sesuai dengan jenis server.
Untuk server yang memakai Traefik (reverse proxy yang mengatur lalu lintas masuk), ada plugin bernama SearchBot detector. Mekanismenya mirip dengan script yang saya gunakan, yakni mendeteksi bot dari User-Agent, lalu memverifikasi lewat reverse DNS. Bedanya, plugin ini bisa langsung memutuskan apa yang dilakukan terhadap bot yang terdeteksi, misalnya mengarahkan bot ke domain khusus atau menandai request-nya lewat header. Kalau IP-nya tidak cocok dengan pola DNS Google, request itu tidak akan dianggap Googlebot, apa pun isi User-Agent-nya.
Untuk server yang memakai Nginx, ada proyek nginx-block-fake-googlebot. Pendekatannya sedikit berbeda, dimana ia tidak melakukan reverse DNS per request, melainkan membandingkan IP pengunjung dengan daftar blok IP resmi yang dipublikasikan Google dan Bing. Kalau IP-nya ada di daftar itu dan User-Agent-nya mengaku Googlebot, berarti asli. Kalau tidak, request langsung dijatuhkan tanpa respons. Daftar IP-nya diperbarui otomatis dua kali sehari lewat script.
Dua pendekatan ini sama-sama valid. Yang Traefik memverifikasi lewat DNS, yang Nginx lewat daftar IP resmi. Keduanya lebih bisa masuk akal daripada mengandalkan pembacaan User-Agent.
Contoh Nyata: 1 dari 108 yang Asli
Pada 18 Agustus 2026, saya melihat dua sesi yang berdampingan di log server ibahasa.
Sesi pertama adalah Googlebot asli. Delapan permintaan dalam delapan detik, jarak antar permintaan tidak beraturan: setengah sampai 1,4 detik, lalu jeda 61 detik, lalu dua permintaan lagi. Semua IP-nya, saat dicek, kembali ke crawl-*.googlebot.com. Pola waktunya tidak rapi, khas penjadwal crawler sungguhan yang menyesuaikan beban server.
Sesi kedua sekitar tiga jam kemudian, dari IP yang sama sekali berbeda. Intervalnya nyaris seperti jam: 12 sampai 13 detik setiap kali, dan satu IP dipakai sekali lalu dibuang untuk permintaan berikutnya. PTR-nya, saat dicek, balik ke domain hosting murah. Bukan Google.
Hasil verifikasi otomatis dalam skala satu hari penuh menunjukkan angka yang lebih besar. Ketika itu pemeriksaan masih dilakukan manual plus script versi awal, dan hasilnya dipecah per mesin pencari yang diklaim:
| Mengaku sebagai | Klaim (jumlah IP) | Terverifikasi asli | Terbukti palsu |
|---|---|---|---|
| 108 | 1 | 107 | |
| Bing | 6 | 6 | 0 |
| Baidu | 5 | 3 | 2 |
| Yandex | 2 | 2 | 0 |
Dari 108 alamat IP yang mengaku Googlebot dalam satu hari, hanya satu yang benar-benar dari Google. Sisanya menyamar, dan sebagian besar memakai laju permintaan yang teratur seperti mesin.
Ini contohnya dari log server ibahasa pada 22 Agustus 2026. Kelima request di bawah ini datang dari dua alamat IP yang terverifikasi asli sebagai Googlebot:
Perhatikan polanya. Request pertama dan kedua berjarak sekitar satu detik, lalu jeda hampir satu menit, lalu dua request di waktu yang sama, lalu jeda lebih dari satu jam ke halaman berikutnya. Tidak ada interval yang rata. Googlebot asli menyesuaikan jadwalnya dengan beban server, bukan berdetak seperti metronom.
Request ketiga dan keempat datang bersamaan dari IP yang sama, tapi membawa dua bentuk User-Agent yang berbeda. Googlebot memang punya beberapa varian: satu menulis identitas polos, satu lagi membawa User-Agent Chrome seperti yang dipakai browser sungguhan. Keduanya sah, selama IP-nya bisa diverifikasi balik ke googlebot.com.
Kalau penasaran, cek sendiri: perintah host 66.249.66.34 membalas crawl-66-249-66-34.googlebot.com. Artinya, IP ini benar milik Google.
Kalau log server kamu penuh Googlebot tapi halaman-halamannya tidak pernah naik peringkat, coba cek dulu: apakah Googlebot itu asli?
Dua Ciri yang Bisa Kamu Lihat Tanpa DNS
Kalau tidak sempat mengecek DNS satu-satu, dua sinyal ini cukup kuat sebagai kecurigaan awal:
- Interval waktu yang terlalu rata. Crawler sungguhan punya jadwal tidak beraturan, menyesuaikan beban server dan prioritas. Interval yang nyaris identik setiap permintaan adalah tanda skrip otomatis, bukan crawler asli.
- Satu IP, satu kali pakai. Operasi yang sah biasanya memakai rentang IP yang sama berulang. Operasi yang berganti IP baru setiap satu atau dua permintaan biasanya sedang menghindari deteksi berbasis IP.
Setelah menemukan IP yang mencurigakan, saya juga bisa menelusuri satu alamat secara detail: halaman apa saja yang ia minta, kapan, dan dengan User-Agent apa. Timeline seperti ini berguna untuk membedakan scraper yang memanen ribuan halaman dari pengunjung yang sekadar mampir beberapa kali.
Pelajaran dari kasus ini
Kalau kalian mengelola situs sendiri, pemeriksaan Googlebot ini bisa dilakukan kapan saja dan tidak butuh alat berbayar. Cukup dua perintah DNS untuk satu IP, atau script otomatis kalau jumlahnya banyak.
- Jangan langsung percaya User-Agent yang mengaku Googlebot. Periksa PTR-nya.
- Bedakan “gagal dicek” dari “terbukti palsu”. Kegagalan teknis bukan bukti.
- Kalau trafik bot besar, laporkan juga IP yang belum sempat diverifikasi, supaya angkanya jujur.
Data di artikel ini berasal dari log server ibahasa yang saya periksa pada 18 sampai 20 Agustus 2026. Semua bisa ditelusuri ulang dengan perintah host dan dig. Di seri berikutnya saya akan membahas pertanyaan yang lebih besar: kalau siapa pun bisa menyamar dan memanen data terbuka, apa gunanya tetap menerbitkan data secara terbuka?
Tinggalkan Balasan