Panduan Analisis File Log

TL;DR — Server web Anda menyimpan log untuk setiap permintaan yang diterimanya, termasuk kunjungan bot mesin pencari seperti Googlebot. Analisis file log berarti membaca log tersebut untuk melihat secara persis halaman mana yang benar-benar diambil bot, seberapa sering, dan apakah bot menemui kesalahan. Inilah satu-satunya tempat yang menunjukkan apa yang benar-benar terjadi—tetapi kebanyakan situs kecil tidak memerlukannya.

Ketuk untuk memperbesar

The four-week chart compares automated and human requests to HTML content. Bot share is higher in the captured worldwide Cloudflare traffic period.

Apa itu file log

Setiap kali siapa pun—manusia, Googlebot, atau bot acak—meminta sebuah halaman dari situs Anda, server menulis satu baris tentang permintaan itu ke sebuah file. File tersebut adalah log akses Anda. Setiap baris umumnya mencatat hal yang sama:

• siapa yang meminta (alamat IP dan nama “user agent” seperti Googlebot),
• apa yang diminta (URL),
• kapan permintaan terjadi (timestamp), dan
• apa responsnya (kode status HTTP—200 berarti OK, 404 berarti tidak ditemukan, dan seterusnya).

Kumpulkan baris-baris itu selama beberapa minggu dan Anda memperoleh catatan lengkap dan jujur tentang cara mesin pencari meng-crawl situs Anda. Bukan perkiraan, melainkan permintaan yang benar-benar terjadi.

Mengapa perlu membacanya

Alat SEO lain biasanya menebak cara bot meng-crawl situs Anda—alat crawling berpura-pura menjadi mesin pencari lalu menjelajahi situs—atau meringkasnya, seperti Google Search Console yang menampilkan tampilan dengan sampling dan pembulatan. Log menunjukkan kejadian sebenarnya, permintaan demi permintaan. Dengan itu, Anda dapat menjawab pertanyaan seperti:

• Halaman mana yang benar-benar dikunjungi Googlebot, dan mana yang diabaikan?
• Apakah bot membuang waktu pada URL sampah alih-alih halaman penting?
• Apakah bot menemui halaman rusak (404) atau kesalahan server (5xx)?
• Apakah ada halaman yang sama sekali belum pernah dijangkau bot?

Satu aturan yang tidak boleh dilewati

Siapa pun dapat berpura-pura menjadi Googlebot. Nama user agent dalam baris log hanyalah teks; scraper dapat memasukkan Googlebot untuk melewati pertahanan Anda. Karena itu, sebelum memercayai satu pun baris “Googlebot”, Anda harus memverifikasi bahwa permintaan itu benar-benar berasal dari Google. Ada pemeriksaan DNS sederhana di tab Advanced dan Scripts. Jika verifikasi dilewati, kesimpulan Anda dapat berasal dari lalu lintas palsu.

Apakah Anda benar-benar memerlukannya?

Sejujurnya, mungkin tidak jika Anda mengelola situs kecil. Analisis file log paling bermanfaat untuk situs besar—puluhan ribu URL, ecommerce dengan banyak halaman hasil filter, situs yang sedang bermigrasi, atau situs dengan halaman yang disebut Google “discovered” tetapi tidak pernah diindeks. Jika situs Anda hanya memiliki beberapa ratus halaman dan semuanya di-crawl dengan baik, waktu Anda lebih berguna untuk hal lain. Logikanya sama dengan anggaran crawling: kebanyakan situs tidak perlu mencemaskannya.

Ingin alur kerja lengkap untuk memverifikasi bot, menemukan pemborosan crawling, dan mendeteksi halaman orphan? Beralihlah ke tab Advanced.

TL;DR — Log adalah sumber kebenaran tanpa sampling untuk crawling: setiap permintaan, setiap bot, dan setiap kode status. Langkah pertama yang tidak dapat ditawar adalah memverifikasi Googlebot/Bingbot melalui DNS balik dan maju atau JSON rentang IP resmi Google. User agent terus-menerus dipalsukan, jadi semua perhitungan crawling harus memakai kumpulan yang terverifikasi. Setelah itu, baca URL dan bagian yang paling atau paling jarang di-crawl, frekuensi crawling dari waktu ke waktu, kode status menurut frekuensi, pemborosan crawling, halaman orphan dan belum di-crawl, serta pembagian Googlebot seluler dan desktop. Bing tidak menerbitkan rentang IP resmi, sehingga metodenya adalah DNS ke *.search.msn.com. Log melengkapi GSC Crawl Stats, bukan menggantikannya. Pada 2026, bot AI juga menjadi bagian besar dari lalu lintas log.

Mengapa log menjadi sumber kebenaran

Ada tiga cara untuk “melihat” bagaimana mesin pencari meng-crawl situs Anda, dan ketiganya tidak setara:

• Alat crawling seperti Screaming Frog SEO Spider atau Ahrefs Site Audit mensimulasikan crawling. Alat itu menunjukkan apa yang dapat ditemukan bot, bukan apa yang benar-benar diambil Google.
• GSC Crawl Stats meringkas kejadian nyata, tetapi datanya disampling, diagregasi, dan dibatasi—sekitar 1 000 baris, kurang lebih 90 hari, tanpa ekspor per URL.
• Log server merekam kejadian nyata: setiap permintaan dari setiap bot, lengkap dengan URL, timestamp, dan kode status yang persis.

Panduan file log Ahrefs yang saya tinjau menyatakannya dengan jelas: log server adalah “the most trustworthy source of information to understand the URLs that search engines have crawled.” (terjemahan) “sumber informasi paling tepercaya untuk memahami URL yang telah di-crawl mesin pencari.” Itulah alasan teknik ini ada. Ketika saya ingin tahu apa yang benar-benar dilakukan Googlebot—bukan apa yang mungkin dilakukan atau ringkasan yang dibulatkan—saya membuka log.

Baris log yang umum memuat alamat IP, user agent, jalur URL, timestamp, metode permintaan (GET/POST), dan kode status HTTP. Seluruh analisis berikutnya hanya memilah kolom-kolom tersebut dengan cermat.

Kapan Anda benar-benar memerlukannya

Bersikaplah jujur: analisis file log adalah alat untuk situs besar. Manfaatnya terasa pada situs dengan puluhan ribu URL, ecommerce dan navigasi berfaset, situs yang sedang bermigrasi, serta situs yang terjebak pada Discovered – currently not indexed. Seperti yang saya tulis dalam panduan anggaran crawling, “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” (terjemahan) “Kebanyakan situs tidak perlu mencemaskan anggaran crawling, tetapi ada beberapa kondisi yang layak diperiksa.” Daniel Waisberg dari Google menyampaikan gagasan serupa mengenai Crawl Stats; menurut liputan Search Engine Journal, laporan itu tidak terlalu menjadi masalah bagi situs dengan kurang dari sekitar 1 000 halaman.

Jika situs Anda hanya memiliki beberapa ratus halaman dan di-crawl dengan baik, lewati analisis ini dan perbaiki sesuatu yang memberi dampak lebih besar.

Cara mendapatkan log Anda

Log berada di lapisan tempat permintaan benar-benar berakhir:

• Apache & Nginx → format log Apache “combined” yang paling umum.
• Microsoft IIS → format W3C.
• AWS ELB/ALB → format ELB.
• CDN seperti Cloudflare, Fastly, dan Akamai → ekspor log masing-masing. Ini penting: pada situs di belakang CDN, log khusus origin tidak memuat hit yang dilayani dari cache edge. Ambil log dari lapisan yang benar-benar dijangkau bot.

Usahakan memperoleh data selama minimal 30 hari, idealnya 90 hari agar variasi frekuensi crawling terlihat. Siapkan waktu karena akses ke log server sering menjadi bagian tersulit akibat pembatasan DevOps. Bahkan Googler dalam episode migrasi Search Off the Record menyoroti betapa sulitnya memperoleh file log dalam praktik.

Log tidak hanya berisi lalu lintas bot. Log merekam setiap permintaan, termasuk pengunjung nyata, dan dapat memuat nilai query string, pengenal sesi, atau data sensitif lain bersama jalur URL. Panduan logging OWASP tegas: kredensial autentikasi, token akses, dan informasi pribadi umumnya tidak boleh dicatat langsung; data tersebut harus dihapus, disamarkan, atau di-hash terlebih dahulu. Terapkan aturan ini pada kontrol akses dan proses ekspor sebelum menyerahkan file log kepada siapa pun untuk dianalisis.

Langkah 1 — Verifikasi bahwa bot itu asli

Banyak panduan hanya menyinggung langkah ini dalam satu baris. Jangan menirunya. Many bots pretend to be Googlebot to get past firewalls. (terjemahan) “Banyak bot berpura-pura menjadi Googlebot untuk melewati firewall.” User agent hanyalah teks tanpa autentikasi; perlakukan setiap baris “Googlebot” sebagai klaim yang harus dibuktikan.

Googlebot—dua metode yang valid:

1. DNS balik dan maju, atau pemeriksaan dua arah. Ikuti langkah resmi Google: jalankan pencarian DNS balik pada IP dalam log dengan perintah host; pastikan domainnya adalah googlebot.com, google.com, atau googleusercontent.com; lalu jalankan pencarian DNS maju pada hostname tersebut dan pastikan hasilnya kembali ke IP asal. Langkah maju inilah yang membuat pemeriksaan dapat dipercaya. Pemalsu dapat mengarahkan DNS balik ke nama *.googlebot.com, tetapi hanya perjalanan pulang ke IP yang sama yang membuktikannya. Perintah macOS/Linux dan Windows tersedia di tab Scripts.
2. Cocokkan dengan rentang IP resmi Google. Google menerbitkan file JSON rentang IP crawler dalam format CIDR: common-crawlers.json untuk Googlebot dan crawler umum, ditambah special-crawlers.json, file fetcher yang dipicu pengguna, dan goog.json untuk seluruh Google. Seperti yang saya tulis dalam panduan Googlebot, Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (terjemahan) “menyediakan daftar IP publik untuk memverifikasi bahwa permintaan berasal dari Google; Anda dapat membandingkannya dengan data dalam log server.”

Bingbot—hanya DNS. Perbedaannya penting: Bing tidak menerbitkan rentang IP resmi. Bing menyatakan “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,” (terjemahan) “seperti mesin pencari lain, Bing tidak menerbitkan daftar alamat atau rentang IP yang digunakan untuk meng-crawl internet,” karena “the IP addresses or ranges we use can change any time.” (terjemahan) “alamat atau rentang IP yang digunakan dapat berubah kapan saja.” Jadi, verifikasi Bingbot dengan DNS balik dan maju ke hostname yang berakhir dengan *.search.msn.com, misalnya msnbot-157-55-33-18.search.msn.com, atau gunakan alat Verify Bingbot. Microsoft kemudian merilis JSON IP bingbot, tetapi panduan verifikasi resminya tetap berpusat pada DNS karena IP dapat berubah.

Kemudian buang yang palsu. Lakukan semua perhitungan crawling hanya pada kumpulan terverifikasi. “Googlebot” yang tidak terverifikasi hampir selalu merupakan scraper atau bot palsu dan harus masuk ke tinjauan keamanan, bukan analisis pemborosan crawling.

Langkah 2 — Hal yang perlu dicari

Setelah hanya memakai hit terverifikasi, lakukan pembacaan berikut:

• URL dan bagian yang paling serta paling jarang di-crawl. Urutkan permintaan menurut URL dan direktori. Di sinilah anggaran crawling Anda benar-benar dihabiskan, dan hasilnya sering mengejutkan.
• Frekuensi crawling dari waktu ke waktu. Lihat tren menurut URL atau bagian untuk menangkap penurunan akibat migrasi yang rusak atau lonjakan akibat bagian baru maupun spider trap yang menghasilkan URL tanpa batas.
• Kode status yang ditemui bot, diprioritaskan menurut frekuensi. Hitung 200, 301/302 beserta rantainya, 404, dan 5xx. 404 yang terkena 5 000× per minggu berbeda dari 404 yang hanya terkena sekali—perbaiki menurut frekuensi crawling, bukan sekadar keberadaan kesalahan.
• Pemborosan crawling. Navigasi berfaset, parameter URL, hasil pencarian internal, serta kalender atau paginasi tanpa batas dapat menghabiskan banyak anggaran crawling. Log menunjukkan pola sampah mana yang benar-benar menghabiskan waktu bot.
• Halaman orphan dan belum di-crawl. Anda memerlukan kedua kumpulan data. Bandingkan log dengan hasil crawl situs: URL yang ada di log tetapi tidak di crawl dapat berupa orphan, pengalihan lama, atau halaman dengan tautan eksternal; URL yang ada di crawl tetapi tidak di log belum pernah diambil Google.
• Googlebot seluler dibanding desktop. Pisahkan menurut user agent. Setelah mobile-first indexing, mayoritas seharusnya Googlebot Smartphone; dominasi desktop patut diperiksa.
• Waktu respons dan kesehatan crawling. Kenaikan waktu respons rata-rata berkorelasi dengan berkurangnya crawling. Liputan SEJ atas panduan Waisberg menyatakan: “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (terjemahan) “Waspadai kenaikan waktu respons rata-rata yang terus meningkat. Google mengatakan hal itu mungkin tidak langsung memengaruhi laju crawling, tetapi merupakan indikasi bahwa server Anda mungkin tidak mampu menangani seluruh beban.”

Hal yang tidak dapat diketahui dari log

Jangan mencampuradukkan batas-batas berikut:

• Crawl ≠ indeks. URL yang diambil Googlebot setiap hari dapat tetap tidak diindeks. Log membuktikan pengambilan, bukan status indeks. Pasangkan dengan Page Indexing atau URL Inspection di GSC untuk mengetahui sisi pengindeksannya.
• Crawl ≠ peringkat, dan lebih banyak crawling tidak membantu. Seperti yang sering saya katakan, “The rate of crawling isn’t going to impact your rankings.” (terjemahan) “Laju crawling tidak akan memengaruhi peringkat Anda.” Jangan mengejar volume crawling seolah-olah itu tuas peringkat.
• noindex tidak mengurangi crawling. noindex mengendalikan pengindeksan, bukan crawling. Untuk benar-benar menghentikan crawl, gunakan robots.txt atau kode status.
• Crawl ≠ pelatihan model atau sitasi. Hit terverifikasi dari GPTBot, ClaudeBot, atau PerplexityBot hanya membuktikan bahwa permintaan dan pengambilan terjadi pada lapisan itu. Hal tersebut tidak membuktikan halaman dipakai untuk melatih model, disimpan di hilir, atau disitasi dalam jawaban chat. Semua itu adalah hasil berbeda yang tidak diamati; jangan menarik kesimpulan melampaui satu baris log terverifikasi.

Perubahan pada 2026: bot AI memenuhi log

Pelaku yang muncul dalam file log modern telah berubah. Dalam analisis saya atas data Cloudflare Radar, Mengenal Crawler Web Baru, bot mesin pencari masih melakukan crawling terbanyak, tetapi bot AI sudah kokoh di posisi kedua dan berpotensi menyalipnya dalam beberapa tahun. GPTBot, ClaudeBot, PerplexityBot, dan bot lain kini sering muncul. Saat hit terverifikasi dikelompokkan menurut user agent, jangan kaget jika porsi permintaan crawler AI menyaingi mesin pencari. Screaming Frog Log File Analyser bahkan menambahkan tutorial khusus pemantauan bot AI untuk kebutuhan ini.

Hubungannya dengan crawling secara keseluruhan

Log adalah lapisan diagnostik di bawah seluruh kelompok crawling. Dengan log, Anda benar-benar mengukur penggunaan anggaran crawling yang biasanya dijelaskan mesin pencari secara abstrak. Gary Illyes mendefinisikannya sebagai “the number of URLs Googlebot can and is willing or is instructed to crawl” (terjemahan) “jumlah URL yang dapat, bersedia, atau diperintahkan untuk di-crawl Googlebot.” Log juga menangkap spider trap saat terjadi: ruang URL tak terbatas dari kalender atau faset tampak sebagai banjir permintaan yang hampir identik. Log membantu mengonfirmasi apakah upaya pada frekuensi crawling, seperti lastmod yang akurat dan tautan internal ke halaman penting, benar-benar mengubah perilaku bot. Ingat, log melengkapi, bukan menggantikan, GSC Crawl Stats. Crawl Stats adalah pintu masuk dengan sampling; log memberi detail tanpa sampling, lintas bot, per URL.

Ringkasan AI

Versi ringkas dari pembahasan Advanced:

• Log = sumber kebenaran. Alat crawling mensimulasikan dan GSC melakukan sampling; log akses server merekam setiap permintaan, setiap bot, URL, timestamp, dan kode status.
• Verifikasi sebelum menganalisis. User agent terus dipalsukan. Konfirmasikan Googlebot melalui DNS balik dan maju atau JSON rentang IP resmi Google; konfirmasikan Bingbot melalui DNS ke *.search.msn.com karena Bing tidak menerbitkan rentang IP resmi. Lakukan semua perhitungan crawling hanya pada kumpulan terverifikasi.
• Yang perlu dibaca: URL dan bagian yang paling atau paling jarang di-crawl; frekuensi dari waktu ke waktu; kode status menurut frekuensi—404 yang terkena 5 000× per minggu tidak sama dengan satu hit; pemborosan crawling; halaman orphan dan belum di-crawl; pembagian Googlebot seluler dan desktop; serta kenaikan waktu respons sebagai peringatan.
• Jangan menafsirkannya berlebihan: crawl ≠ indeks ≠ peringkat, lebih banyak crawling tidak menaikkan peringkat, noindex tidak mengurangi crawling, dan hit bot AI terverifikasi membuktikan pengambilan—bukan pelatihan model atau sitasi.
• Cakupan: alat untuk situs besar, ecommerce, dan migrasi. Kebanyakan situs kecil tidak memerlukannya.
• 2026: bot AI seperti GPTBot, ClaudeBot, dan PerplexityBot menjadi bagian besar dan terus tumbuh dari lalu lintas log.
• Melengkapi GSC Crawl Stats—gunakan keduanya.

Dokumentasi resmi

Dokumentasi sumber primer untuk memverifikasi crawler dan membaca data crawling.

Google

• Memverifikasi permintaan dari crawler dan fetcher Google — dua metode resmi: DNS balik dan maju secara manual, atau pencocokan dengan rentang IP yang diterbitkan.
• Cara memverifikasi Googlebot (Search Central Blog) — artikel pendamping yang lebih lama dan masih dirujuk.
• common-crawlers.json — IP Googlebot dan crawler umum dalam format CIDR. Catatan: “the IP addresses in the JSON files are represented in CIDR format” (terjemahan) “alamat IP dalam file JSON direpresentasikan dalam format CIDR.” File pendamping: special-crawlers.json, user-triggered-fetchers.json, dan goog.json untuk seluruh Google.
• Ringkasan crawler dan fetcher Google — seluruh user agent Google yang mungkin terlihat dalam log.
• Laporan Crawl Stats (Bantuan) dan artikel peluncurannya — tampilan resmi dengan sampling yang dilengkapi oleh log.

Bing / Microsoft

• Cara memverifikasi Bingbot (bantuan Webmaster) — halaman verifikasi resmi.
• Cara memverifikasi bahwa Bingbot benar-benar Bingbot (blog) — metode kanonis DNS balik dan maju serta pernyataan bahwa Bing tidak menerbitkan rentang IP.
• Alat Verify Bingbot — tempelkan IP untuk memeriksanya.

Kutipan dari sumber

Pernyataan resmi yang tercatat. Jika didukung, setiap tautan mengarah langsung ke bagian yang dikutip pada halaman sumber.

Google—memverifikasi crawler

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command.” (terjemahan) “Jalankan pencarian DNS balik pada alamat IP pengakses dari log Anda dengan perintah host.” — Dokumentasi Google Search Central. Buka kutipan
• “Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (terjemahan) “Pastikan nama domainnya adalah googlebot.com, google.com, atau googleusercontent.com.” Buka kutipan
• “Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name.” (terjemahan) “Jalankan pencarian DNS maju pada nama domain yang diperoleh di langkah 1 menggunakan perintah host.” Buka kutipan
• “Verify that it’s the same as the original accessing IP address from your logs.” (terjemahan) “Pastikan hasilnya sama dengan alamat IP pengakses asli dari log Anda.” Buka kutipan

Bing—verifikasi dan tidak adanya rentang IP resmi

• “Perform a reverse DNS lookup using the IP address from the logs to verify that it resolves to a name that end with search.msn.com.” (terjemahan) “Lakukan pencarian DNS balik menggunakan alamat IP dari log untuk memastikan hasilnya berupa nama yang berakhir dengan search.msn.com.” — Bing Webmaster Blog. Buka kutipan
• “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet.” (terjemahan) “Seperti mesin pencari lain, Bing tidak menerbitkan daftar alamat atau rentang IP yang digunakan untuk meng-crawl internet.”—dan alasannya: “the IP addresses or ranges we use can change any time, so responding to requests differently based on a hardcoded list is not a recommended approach.” (terjemahan) “Alamat atau rentang IP yang kami gunakan dapat berubah kapan saja, sehingga menanggapi permintaan secara berbeda berdasarkan daftar yang ditulis permanen bukan pendekatan yang disarankan.” Buka kutipan

Patrick Stox—fungsi log (dari pekerjaan saya di Ahrefs)

• Log server adalah “the most trustworthy source of information to understand the URLs that search engines have crawled.” (terjemahan) “sumber informasi paling tepercaya untuk memahami URL yang telah di-crawl mesin pencari.” Buka kutipan
• “Many bots pretend to be Googlebot to get past firewalls.” (terjemahan) “Banyak bot berpura-pura menjadi Googlebot untuk melewati firewall.” Buka kutipan
• “If you want to see hits from all bots and users, you’ll need access to your log files.” (terjemahan) “Jika ingin melihat hit dari semua bot dan pengguna, Anda memerlukan akses ke file log.” Buka kutipan
• “The rate of crawling isn’t going to impact your rankings.” (terjemahan) “Laju crawling tidak akan memengaruhi peringkat Anda.” Buka kutipan

Gary Illyes, Google—anggaran crawling yang dapat diukur melalui log

• Anggaran crawling adalah “the number of URLs Googlebot can and is willing or is instructed to crawl.” (terjemahan) “jumlah URL yang dapat, bersedia, atau diperintahkan untuk di-crawl Googlebot.” Baca liputannya

Daniel Waisberg, Google—waktu respons sebagai sinyal kesehatan crawling (penyajian SEJ atas panduan Crawl Stats-nya)

• “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (terjemahan) “Waspadai kenaikan waktu respons rata-rata yang konsisten. Google mengatakan hal itu mungkin tidak langsung memengaruhi laju crawling, tetapi merupakan indikasi bahwa server Anda mungkin tidak mampu menangani seluruh beban.” Buka kutipan

Memverifikasi bahwa bot benar-benar Googlebot melalui DNS balik dan maju

User agent dalam baris log hanyalah teks; scraper memalsukan Googlebot untuk melewati firewall. Pemeriksaan yang dapat dipercaya adalah DNS dua arah: cari IP secara balik, pastikan hostname berada di domain Google, lalu cari hostname itu secara maju dan pastikan hasilnya kembali ke IP yang sama.

macOS / Linux (menggunakan host)

# 1) Reverse DNS the IP from your logs — it must end in googlebot.com,
#    google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows (menggunakan nslookup)

:: 1) Reverse DNS the IP — confirm it ends in a Google domain
nslookup 66.249.66.1

:: 2) Forward DNS the returned hostname — confirm it matches the original IP
nslookup crawl-66-249-66-1.googlebot.com

Jika pencarian balik tidak berakhir pada domain Google atau pencarian maju tidak mengembalikan IP asal, permintaan itu bukan Googlebot. Untuk Bingbot, jalankan dua langkah yang sama tetapi harapkan hostname berakhiran search.msn.com. Anda juga dapat melewati DNS dan mencocokkan IP dengan rentang resmi Google di common-crawlers.json, dalam format CIDR.

Mengekstrak dan menghitung hit crawler dari log mentah

Perintah singkat berikut berlaku untuk log akses Apache/Nginx berformat combined. Perintah ini memilih berdasarkan string user agent; verifikasikan IP sebelum memercayai hasil hitungannya.

# Pull only the lines claiming to be Googlebot
grep -i "googlebot" access.log > googlebot-hits.log

# Count Googlebot hits per URL, most-crawled first
# (combined format: $7 is the request path)
grep -i "googlebot" access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Count Googlebot hits per status code (combined format: $9 is the status)
grep -i "googlebot" access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# List the URLs Googlebot hit that returned a 404, by frequency
grep -i "googlebot" access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn

# Get the unique IPs claiming Googlebot — the list you then verify by DNS
grep -i "googlebot" access.log | awk '{print $1}' | sort -u

Sesuaikan posisi kolom $7/$9 jika format log Anda berbeda; IIS/W3C dan ELB mengurutkan kolom secara berbeda.

Alur kerja analisis file log

• Dapatkan log — log akses server atau ekspor CDN/load balancer. Pada situs di belakang CDN, ambil juga log edge karena origin tidak memuat hit cache.
• Ambil rentang waktu yang cukup — minimal 30 hari, idealnya 90 hari.
• Verifikasi bot terlebih dahulu — DNS balik dan maju atau rentang IP resmi Google. Untuk Bingbot, gunakan DNS ke *.search.msn.com.
• Buang yang palsu — lakukan semua perhitungan crawling pada kumpulan terverifikasi; arahkan “Googlebot” palsu ke tinjauan keamanan.
• Urutkan URL dan bagian yang paling atau paling jarang di-crawl — lihat ke mana anggaran crawling digunakan.
• Pantau tren frekuensi crawling — temukan penurunan akibat migrasi dan lonjakan akibat bagian baru atau spider trap.
• Hitung kode status — 200, rantai 301-302, 404, dan 5xx; prioritaskan perbaikan menurut frekuensi crawling, bukan sekadar keberadaannya.
• Cari pemborosan crawling — parameter, navigasi berfaset, pencarian internal, paginasi, atau kalender tanpa batas.
• Temukan halaman orphan dan belum di-crawl — bandingkan log dengan crawl situs; ada di log tetapi tidak di crawl berarti kemungkinan orphan, sedangkan ada di crawl tetapi tidak di log berarti belum pernah diambil.
• Periksa pembagian Googlebot seluler dan desktop — mayoritas seharusnya Smartphone.
• Pantau waktu respons rata-rata — tren yang naik dapat menekan crawling.
• Kelompokkan bot AI — GPTBot, ClaudeBot, PerplexityBot, dan lainnya kini menyumbang lalu lintas nyata.
• Konfirmasikan dengan GSC — pasangkan temuan crawling dengan Crawl Stats dan URL Inspection karena crawl ≠ indeks.

Tampilan yang perlu dibuat dalam lembar analisis

Baik Anda memakai Screaming Frog Log File Analyser, BigQuery, maupun templat file log Ahrefs, Anda tetap membangun beberapa tampilan yang sama. Setelah bot diverifikasi, uraikan setiap baris menjadi kolom lalu buat pivot.

Kolom yang perlu diambil dari setiap baris log

Pivot yang perlu dibuat

• Crawling per URL dan per direktori, diurutkan menurun—yang paling dan paling jarang di-crawl.
• Crawling per kode status, lalu kode status × URL, agar 404 berfrekuensi tinggi langsung terlihat.
• Crawling per hari/minggu, dipisahkan menurut bagian—tren frekuensinya.
• Crawling per bot/user agent—pembagian seluler/desktop dan porsi bot AI.
• Gabungan log vs. crawl melalui VLOOKUP atau merge terhadap ekspor crawl Screaming Frog atau Ahrefs untuk menemukan halaman orphan dan yang belum pernah diambil.

Panduan Ahrefs menyediakan templat unduhan untuk tampilan tersebut; tautannya ada di panduan analisis file log.

Cara membaca file log: hal yang perlu dicari

Kerangka yang dapat diulang untuk analisis log apa pun. Verifikasi dahulu, lalu jalankan pemeriksaan berikut.

1. Verifikasi, lalu analisis. Kualitas data bergantung pada identitas bot. Gunakan DNS balik dan maju atau rentang IP, kemudian analisis hanya kumpulan terverifikasi. Bot palsu masuk ke keamanan, bukan SEO.

2. Ke mana anggaran digunakan? (paling vs. paling jarang di-crawl.) Urutkan menurut URL dan bagian. Tujuannya adalah menemukan perhatian yang dihabiskan di tempat salah serta halaman penting yang terlalu jarang dijangkau.

3. Apa yang ditemui bot? (kode status menurut frekuensi.) 200 sehat; rantai 3xx, 404, dan 5xx adalah kebocoran. Prioritaskan menurut seberapa sering bot menemuinya, bukan sekadar apakah kesalahan itu ada.

4. Apa yang terbuang? (pemborosan crawling.) Parameter, navigasi berfaset, pencarian internal, dan paginasi atau kalender tanpa batas adalah penyedot anggaran klasik. Log menunjukkan pola pelakunya secara persis.

5. Apa yang hilang? (orphan dan belum di-crawl.) Bandingkan log dengan crawl. Ada di log tetapi tidak di crawl berarti orphan, pengalihan lama, atau tautan eksternal. Ada di crawl tetapi tidak di log berarti belum diambil Google.

6. Siapa yang meng-crawl? (segmentasi bot.) Pisahkan Googlebot seluler dan desktop—mayoritas seharusnya Smartphone—serta porsi bot AI yang kini menyaingi mesin pencari.

7. Apakah server sehat? (waktu respons.) Kenaikan waktu respons rata-rata adalah peringatan dini bahwa crawling dapat dibatasi.

Alat untuk analisis file log

• Screaming Frog SEO Log File Analyser — alat desktop utama. Alat ini memverifikasi otomatis bot mesin pencari dan menandai IP palsu, serta menyediakan filter User-Agent dan Verification-Status untuk analisis bot yang terperinci. Impor crawl SEO Spider lalu gunakan filter “Not In URL Data” untuk menemukan orphan: “URLs which were discovered in your logs, but are not present in the crawl data imported.” (terjemahan) “URL yang ditemukan dalam log, tetapi tidak terdapat dalam data crawl yang diimpor.” Alat ini juga memiliki tutorial khusus pemantauan bot AI. Alat
• BigQuery serta Splunk / ELK Stack / Logflare / logz.io — penyimpanan dan kueri mentah berskala besar ketika volume log terlalu besar untuk alat desktop.
• Ahrefs — bandingkan log dengan crawl Ahrefs Site Audit untuk menemukan orphan dan memastikan halaman yang dijangkau bot. Ini alat utama saya.
• Semrush Log File Analyzer, OnCrawl, Botify, dan JetOctopus — platform crawling dan log lain; tiga yang terakhir ditujukan untuk enterprise.
• GSC Crawl Stats — pintu masuk resmi, gratis, dan disampling. Ini melengkapi log mentah, bukan menggantikannya: datanya diagregasi, dibatasi, dan tidak dapat diekspor per URL.
• Alat Verify Bingbot — tempelkan IP untuk memastikan permintaan benar-benar berasal dari Bingbot: bing.com/toolbox/verify-bingbot.

Kesalahan yang perlu dihindari

• Memercayai string “Googlebot” tanpa memverifikasinya. Mengapa salah: user agent hanyalah teks tanpa autentikasi; siapa pun dapat menaruh Googlebot dalam header untuk melewati pertahanan atau mencemari analisis. Lakukan ini: jalankan DNS balik dan maju atau cocokkan dengan rentang IP resmi Google sebelum satu baris pun dihitung.
• Menganggap GSC Crawl Stats sebagai gambaran lengkap. Mengapa salah: datanya disampling, dibulatkan, dibatasi sekitar 1 000 baris dan 90 hari, serta tidak memiliki ekspor per URL. Laporan itu meringkas, bukan merekam. Lakukan ini: gunakan log sebagai sumber kebenaran dan Crawl Stats sebagai pintu masuk pelengkap yang lebih cepat.
• Hanya mengambil log origin pada situs di belakang CDN. Mengapa salah: log origin tidak memuat permintaan yang dilayani CDN dari cache edge, sehingga gambaran tentang respons yang diterima bot tidak lengkap. Lakukan ini: ambil log dari lapisan yang benar-benar dijangkau bot—ekspor CDN/edge, bukan hanya server origin.
• Memperbaiki 404 dan 5xx berdasarkan keberadaan, bukan frekuensi. Mengapa salah: 404 yang terkena sekali sebulan berbeda dari 404 yang terkena 5 000 kali seminggu. Menganggap semuanya sama mendesak membuang upaya. Lakukan ini: urutkan masalah kode status menurut frekuensi bot menemuinya.
• Mengejar volume crawling sebagai tuas peringkat. Mengapa salah: lebih banyak crawling tidak menaikkan peringkat; ini sinyal diagnostik, bukan metrik pertumbuhan. Lakukan ini: gunakan frekuensi untuk mendeteksi penurunan atau spider trap, bukan KPI yang harus dimaksimalkan.
• Menggunakan noindex untuk menghentikan crawling. Mengapa salah: noindex mengendalikan pengindeksan, bukan crawling. Google tetap perlu mengambil halaman untuk melihat tag. Lakukan ini: jika tujuannya benar-benar menghentikan crawl, gunakan robots.txt atau kode status.
• Menyebut URL sebagai orphan hanya berdasarkan log. Mengapa salah: URL yang muncul di log tetapi tidak dalam crawl baru dapat berupa pengalihan lama, tautan eksternal, atau orphan sungguhan; log saja tidak membedakannya. Lakukan ini: bandingkan log dengan crawl situs sebelum menarik kesimpulan.

KPI tetap untuk analisis file log

Porsi bot terverifikasi

• Metrik: hit Googlebot/Bingbot terverifikasi ÷ seluruh hit yang mengaku sebagai Googlebot/Bingbot berdasarkan user agent.
• Yang ditunjukkan: berapa banyak “lalu lintas bot” yang sebenarnya berasal dari scraper palsu, bukan mesin pencari asli.
• Cara mengambil: jalankan setiap IP yang mengaku bot melalui DNS balik dan maju atau JSON rentang IP, lalu hitung tingkat kelulusannya.
• Tolok ukur / rentang realistis: tidak ada angka universal; hasil bergantung pada seberapa agresif situs Anda di-scrape. Porsi terverifikasi yang rendah atau menurun adalah sinyal untuk bertindak, bukan ambang tetap.
• Frekuensi: setiap kali mengambil rentang log baru.

Porsi pemborosan crawling

• Metrik: persentase permintaan bot terverifikasi yang mengenai parameter, faset, pencarian internal, atau paginasi/kalender tanpa batas.
• Yang ditunjukkan: bagian anggaran crawling yang dihabiskan pada URL sampah alih-alih halaman penting.
• Cara mengambil: kelompokkan hit terverifikasi berdasarkan pola URL, seperti query string dan jalur faset atau pencarian yang diketahui.
• Tolok ukur / rentang realistis: tidak ada angka universal; hasil sangat bergantung pada struktur URL dan faset situs. Tetapkan baseline dari pengambilan pertama, lalu pantau trennya.
• Frekuensi: rentang log 30–90 hari; periksa lagi setelah pembersihan robots.txt, penanganan parameter, atau perbaikan paginasi.

Campuran kode status, dibobot menurut frekuensi

• Metrik: porsi 200 / 3xx / 404 / 5xx dari permintaan bot terverifikasi.
• Yang ditunjukkan: tempat bot membuang pengambilan pada kesalahan alih-alih konten aktif, serta apakah kondisinya memburuk.
• Cara mengambil: hitung kolom kode status dari baris log terverifikasi.
• Tolok ukur / rentang realistis: tidak ada target universal; hasil bergantung pada usia situs dan riwayat pengalihan. Pantau tren, bukan satu snapshot. Kenaikan porsi 404/5xx adalah sinyal yang dapat ditindaklanjuti.
• Frekuensi: 30–90 hari atau segera setelah migrasi.

Pembagian Googlebot seluler dan desktop

• Metrik: porsi hit Googlebot terverifikasi dari user agent Smartphone dibanding Desktop.
• Yang ditunjukkan: apakah Google benar-benar meng-crawl situs secara mobile-first, seperti yang diharapkan setelah mobile-first indexing.
• Cara mengambil: kelompokkan hit terverifikasi berdasarkan string UA Googlebot Smartphone dan Desktop.
• Tolok ukur / rentang realistis: mayoritas seharusnya Smartphone pada kebanyakan situs; dominasi desktop patut diselidiki, tetapi bukan kegagalan mutlak.
• Frekuensi: setiap pengambilan log.

Jumlah halaman orphan / belum di-crawl

• Metrik: URL yang ada di log tetapi tidak dalam crawl baru—kemungkinan orphan atau tautan lama—serta URL yang ada dalam crawl tetapi tidak di log—belum pernah diambil.
• Yang ditunjukkan: halaman yang sulit dijangkau bot dan halaman yang Anda tautkan tetapi belum pernah diambil Google.
• Cara mengambil: gabungkan daftar URL hit terverifikasi dengan ekspor crawl situs dari Screaming Frog atau Ahrefs.
• Tolok ukur / rentang realistis: sepenuhnya situasional; hasil bergantung pada ukuran situs serta waktu migrasi atau restrukturisasi terakhir. Pantau jumlah dari waktu ke waktu, bukan membandingkannya dengan angka luar.
• Frekuensi: setiap kuartal untuk situs besar atau segera setelah migrasi.

Prompt siap salin untuk analisis log

Prompt berikut digunakan untuk menafsirkan data log yang sudah Anda ambil dan verifikasi, bukan untuk membuat data log. Jangan pernah membiarkan AI mengarang baris log atau statistik.

Merangkum pemborosan crawling dari sampel URL

Here is a list of URL paths that verified Googlebot hits landed on, one per
line, from my server logs. Group them into patterns (query parameters,
faceted navigation, internal search, pagination/calendars, or "looks like a
real page"), and tell me which pattern has the most URLs. Don't invent URLs
that aren't in the list — only group what I've pasted.

[paste your URL list here]

Hasil yang diharapkan: beberapa kelompok bernama beserta jumlahnya dan penanda kelompok yang tampak sebagai sumber pemborosan crawling terbesar. Gunakan hasil itu sebagai titik awal untuk diverifikasi terhadap jalur sebenarnya, bukan jawaban final.

Memprioritaskan rincian kode status

I have this table of HTTP status codes and how many times verified Googlebot
hit each one over the last 30 days. Rank them by which I should fix first,
weighting frequency over severity — a 404 hit 5,000 times matters more than a
500 hit twice. Explain the reasoning in one line per row.

status_code, hit_count
[paste your table here]

Hasil yang diharapkan: baris yang sama, diurutkan ulang menurut prioritas perbaikan, dengan satu alasan singkat untuk setiap baris. Periksa kembali alasannya terhadap konteks situs Anda sebelum bertindak.

Menyusun permintaan akses log kepada DevOps

Write a short, plain-English email to my DevOps/hosting team asking for
30-90 days of raw web server access logs (Apache/Nginx combined format, or
our CDN's edge logs if we're behind one) for [site name]. Explain in one
sentence why I need it (verifying real Googlebot/Bingbot crawl activity vs
GSC's sampled report) and ask what export format and delivery method works
for them.

Hasil yang diharapkan: draf email singkat yang dapat Anda sesuaikan dengan nama situs sebenarnya. Tinjau sendiri sebelum mengirim; alat ini tidak mengirim pesan atas nama Anda.

Menjelaskan hasil verifikasi DNS

I ran a reverse DNS lookup on an IP from my server logs and then a forward
DNS lookup on the hostname it returned. Here's the raw output from the
`host` command. Tell me plainly whether this confirms the request came from
real Googlebot or Bingbot, and point to exactly which line proves or
disproves it.

[paste your host/nslookup output here]

Hasil yang diharapkan: putusan dalam bahasa sederhana yang terikat pada baris tertentu dalam keluaran. Anggap sebagai pendapat kedua, bukan pengganti aturan sebenarnya: hostname harus berakhir pada domain Google/Bing dan pencarian maju harus kembali ke IP asal.

Sumber daya yang layak Anda gunakan

Tulisan saya yang terkait

• Cara melakukan analisis file log SEO [termasuk templat] — panduan utama Ahrefs yang saya tinjau; kerangka dan templat artikel ini banyak mengacu padanya.
• Kapan Anda perlu mencemaskan anggaran crawling? — kapan analisis log layak dan tidak layak dilakukan.
• Apa itu Googlebot dan bagaimana cara kerjanya? — latar belakang crawler dan verifikasi IP.
• Mengenal crawler web baru: bot AI mendekati bot mesin pencari — alasan log Anda terlihat berbeda pada 2026.
• Panduan pemula untuk SEO teknis — posisi crawling dan log dalam gambaran yang lebih luas.

Presentasi saya

• Cara Kerja Penelusuran (SlideShare) — penjelasan saya tentang crawling: Googlebot sebagai lebih dari 1 000 sistem dengan banyak crawler khusus—Desktop, Mobile, Image, News, Video, dan Ads—yang berbagi satu kumpulan anggaran crawling, dengan permintaan terutama berasal dari Mountain View. Ini pemeriksaan kewajaran log yang berguna bersama, bukan sebagai pengganti, verifikasi yang benar. Penyangkalan tetap: “This is my understanding of systems… not going to be 100% complete or accurate.” (terjemahan) “Ini adalah pemahaman saya tentang sistem; tidak akan 100% lengkap atau akurat.”

Dari pihak lain

• Panduan pengguna Screaming Frog Log File Analyser dan tutorial bot AI.
• Search Engine Land—panduan analisis file log oleh Kody Wirth — langkah praktis tentang format, alat, dan pola yang perlu dicari.
• Search Engine Journal—cara menggunakan laporan Crawl Stats Google — panduan Daniel Waisberg dari Google untuk membaca Crawl Stats, termasuk peringatan waktu respons; pendamping terbaik untuk analisis log.
• Search Engine Journal—pengindeksan dan anggaran crawling (Illyes + Splitt) — definisi anggaran crawling yang tercatat dan cara kualitas mendorong permintaan crawling.
• Search Engine Roundtable—alamat IP Bingbot dirilis — nuansa bahwa Microsoft akhirnya menerbitkan JSON IP bingbot meskipun panduan resmi masih berpusat pada DNS.
• Conductor—analisis file log untuk SEO — penjelasan mudah dipahami tentang hal yang diungkap log dan cara menindaklanjutinya.
• r/TechSEO — komunitas untuk debugging crawl dan indeks.

Video

• Google Search Central (YouTube) — penjelasan crawling/rendering dari Martin Splitt dan seri Cara Kerja Google Search; latar belakang berguna tentang bot yang hit-nya Anda verifikasi dalam log. Kanal

Uji pemahaman Anda

Lima pertanyaan tentang verifikasi bot dan pembacaan hal yang benar-benar ditunjukkan log.

Log perubahan