Cara Cek Googlebot Asli Lewat Reverse DNS Sebelum Blokir IP Crawler

Access log penuh dengan request ber-user-agent Googlebot, CPU naik, dan kamu ingin memblokir IP-IP itu. Tapi ada keraguan: kalau ternyata itu Googlebot asli, indexing situs bisa terganggu. Masalahnya, user-agent hanyalah teks yang dikirim client, jadi siapa pun bisa menulis Googlebot di sana. Kabar baiknya, verifikasinya bisa dilakukan sendiri dari terminal dalam beberapa menit. Di meja support, pertanyaan seperti "ini Google bukan sih, boleh diblokir?" cukup sering muncul, terutama saat situs WordPress tiba-tiba lambat. Jawabannya tidak perlu tebak-tebakan. Ada dua lookup DNS yang memberi kepastian.

Kenapa user-agent saja tidak bisa dipercaya

User-agent adalah header HTTP yang diisi bebas oleh client. Scraper, bot pencari celah, dan tool brute-force sering memakai string Googlebot karena tahu banyak admin enggan memblokirnya. Beberapa firewall atau plugin keamanan juga melonggarkan aturan untuk user-agent tersebut, jadi memalsukannya bisa jadi cara murah untuk lolos. Yang tidak bisa dipalsukan semudah itu adalah kepemilikan DNS. Google menyarankan verifikasi dua arah:

Reverse DNS lookup. IP penyerang di-query PTR record-nya, yaitu record yang memetakan IP ke hostname. Untuk crawler Google, hasilnya harus berakhiran domain milik Google, biasanya googlebot.com atau google.com.
Forward DNS lookup. Hostname hasil langkah pertama di-query balik ke A/AAAA record-nya. Hasilnya harus mengandung IP yang sama dengan IP asal.

Langkah kedua sering dilewati, padahal justru di situ kuncinya. PTR record dikontrol oleh pemilik blok IP, bukan pemilik domain. Artinya, orang yang menyewa server dengan akses ke pengaturan reverse DNS bisa saja memasang PTR crawl-sesuatu.googlebot.com di IP miliknya. Tapi forward lookup untuk nama di bawah googlebot.com dijawab oleh nameserver Google, dan jawabannya tidak akan pernah menunjuk ke IP penyerang. Kalau hasil forward tidak cocok dengan IP asal, IP itu palsu. Ada satu jebakan lagi. Google juga memakai googleusercontent.com untuk fetcher yang dipicu pengguna, misalnya tool yang mengambil halaman atas permintaan seseorang. Masalahnya, IP VM di Google Cloud biasanya juga punya reverse DNS di bawah domain itu. Jadi request yang mengaku Googlebot dari IP googleusercontent.com justru perlu dicurigai, karena bisa saja itu VM sewaan siapa pun. Untuk user-agent Googlebot, aku lebih suka aturan yang ketat: hanya terima googlebot.com dan google.com.

Cek manual satu IP: reverse lalu forward

Sebelum mulai, pastikan IP yang kamu lihat di log memang IP pengunjung. Kalau situs ada di belakang Cloudflare, load balancer, atau reverse proxy lain, kolom pertama access log bisa saja berisi IP proxy. Memverifikasi IP itu tidak ada gunanya, dan memblokirnya malah bisa memutus semua trafik. Cek dulu konfigurasi real IP di web server kamu. Setelah itu, ambil daftar IP yang paling sering mengaku Googlebot, lalu cek satu per satu. Contoh di bawah memakai path log Nginx default di Debian/Ubuntu dengan format combined. Di cPanel, LiteSpeed, atau Apache, lokasi log dan formatnya berbeda, jadi sesuaikan path dan kolomnya.

BASH

# IP teratas yang mengirim user-agent Googlebot (IP di kolom pertama format combined)
grep -i 'googlebot' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 20

# Langkah 1: reverse lookup (PTR) untuk satu IP
host 66.249.66.1

# Langkah 2: forward lookup untuk hostname hasil langkah 1
host crawl-66-249-66-1.googlebot.com

Kalau host belum terpasang, dig -x IP +short dan dig +short HOSTNAME memberi hasil yang sama. Di Debian/Ubuntu keduanya biasanya ada di paket bind9-dnsutils atau dnsutils, sedangkan di keluarga RHEL ada di bind-utils. Nama paketnya bisa berbeda tergantung versi distro. Hasil yang lolos verifikasi kira-kira seperti ini:

TEXT

# contoh format output, bukan dari insiden nyata
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Baris pertama menunjukkan PTR berakhiran googlebot.com. Baris kedua menunjukkan forward lookup kembali ke IP yang sama. Dua syarat terpenuhi, jadi IP ini crawler asli. Ada tiga pola gagal yang biasa muncul. Pertama, PTR tidak ada sama sekali (not found atau NXDOMAIN), dan ini hampir pasti bukan Google. Kedua, PTR mengarah ke hostname milik penyedia VPS atau ISP. Ketiga, PTR terlihat meyakinkan tapi forward lookup-nya gagal atau menunjuk ke IP lain. Ketiganya berarti user-agent dipalsukan. Sebagai pembanding, Google juga menerbitkan daftar rentang IP crawler-nya dalam format JSON. Daftar itu berguna kalau kamu ingin mencocokkan dalam jumlah besar tanpa lookup DNS, tapi perlu diperbarui secara berkala karena rentangnya bisa berubah. Cara DNS tetap jadi acuan yang paling mudah dijalankan di server mana pun.

Verifikasi massal dari access log

Mengecek dua puluh IP satu per satu cukup membosankan. Script kecil di bawah membaca daftar IP dari stdin lalu memberi label ASLI atau PALSU. Script ini hanya melakukan query DNS dan tidak mengubah apa pun di server.

BASH

#!/usr/bin/env bash
# verify-googlebot.sh: baca IP (satu per baris) dari stdin, cek PTR + forward lookup.
# Pakai: grep -i 'googlebot' /var/log/nginx/access.log | awk '{print $1}' | sort -u | ./verify-googlebot.sh
# ponytail: lookup serial tanpa cache; untuk ribuan IP, simpan hasil ke file dan jalankan ulang hanya untuk IP baru.
while read -r ip; do
  [ -z "$ip" ] && continue
  ptr=(dig -x "ip" +short | head -n1)
  ptr=${ptr%.}
  case "$ptr" in
    *.googlebot.com|*.google.com)
      fwd=( { dig +short "ptr" A; dig +short "$ptr" AAAA; } )
      if grep -qxF "ip" <<< "fwd"; then
        echo "ASLI  ipptr"
      else
        echo "PALSU ipptr (forward tidak cocok)"
      fi
      ;;
    *)
      echo "PALSU ip{ptr:-tanpa-PTR}"
      ;;
  esac
done

Beberapa catatan supaya hasilnya tidak menyesatkan. Perbandingan IP di script ini berupa teks persis. Untuk IPv4 hasilnya aman, tapi IPv6 bisa ditulis dalam bentuk yang berbeda antara log dan output dig (misalnya ada atau tidaknya nol di depan). Kalau ada IPv6 yang berlabel PALSU padahal PTR-nya googlebot.com, cek manual sebelum mengambil tindakan. Selain itu, timeout dari resolver bisa membuat ptr kosong. Kalau hasilnya mencurigakan, jalankan ulang untuk IP tersebut sebelum memblokir. Script ini juga sengaja tidak dijalankan per request di web server. Melakukan lookup DNS untuk setiap request akan memperlambat situs dan membebani resolver. Pola yang lebih masuk akal adalah menjalankannya berkala terhadap log, lalu memakai hasilnya sebagai daftar blokir atau daftar izin.

Memutuskan: blokir, rate limit, atau biarkan

Setelah daftar IP berlabel, keputusannya biasanya lebih jelas. IP berlabel PALSU aman diblokir dari sisi SEO karena memang bukan crawler Google. Blokir di level firewall (iptables/nftables, CSF, atau firewall dari penyedia) supaya request berhenti sebelum sampai ke PHP. Satu hal yang perlu diingat: bot palsu sering berpindah IP. Kalau IP baru terus bermunculan dari satu penyedia, blokir per IP akan jadi pekerjaan tanpa ujung. Di titik itu, rate limit per IP di web server biasanya lebih efektif. Untuk memastikan aturan seperti itu benar-benar aktif, pola pengujiannya mirip dengan yang dibahas di Cara Cek Rate Limiting Nginx Benar-Benar Aktif di wp-login.php. Hati-hati dengan dua langkah yang sering dilakukan saat panik. Memblokir seluruh request ber-user-agent Googlebot akan ikut memblokir yang asli. Sebaliknya, meloloskan semua request ber-user-agent Googlebot dari rate limit sama saja membuka pintu untuk bot palsu. Aturan yang aman adalah memperlakukan user-agent sebagai klaim, bukan identitas. IP berlabel ASLI sebaiknya tidak diblokir. Kalau Googlebot asli memang terlalu agresif dan server kewalahan, ada beberapa hal yang bisa dicek. Pertama, lihat URL apa yang paling banyak di-crawl. Sering kali penyebabnya adalah URL dengan parameter tanpa batas, misalnya filter produk, halaman pencarian internal, atau kalender, yang bisa ditata lewat robots.txt atau canonical. Kedua, perlu diketahui bahwa Googlebot tidak mengikuti directive crawl-delay di robots.txt. Saat server benar-benar kewalahan, Google menyarankan membalas dengan status 503 atau 429 untuk sementara, karena crawler akan menurunkan lajunya. Jangan biarkan respons itu berlangsung berhari-hari, karena halaman yang terus-menerus gagal di-crawl bisa berdampak ke indexing. Pola verifikasi yang sama berlaku untuk crawler lain dengan domain yang berbeda. Bingbot, misalnya, biasanya punya reverse DNS di bawah search.msn.com. Untuk crawler lain, cek dokumentasi resmi masing-masing soal domain apa yang dipakai sebelum menambahkannya ke pola case di script. Kalau ingin satu kebiasaan yang dibawa pulang: sebelum memblokir IP yang mengaku Googlebot, jalankan reverse lookup, lalu forward lookup, lalu pastikan IP-nya kembali sama. IP yang lolos jangan diblokir, tapi cari tahu URL apa yang membuatnya sibuk. IP yang gagal boleh diblokir tanpa rasa bersalah, dan kalau IP-nya terus berganti, pindahkan fokus ke rate limit.