Analisis Log Crawler AI

TL;DR — Analisis log crawler AI berarti melihat log akses mentah server untuk mengetahui bot AI mana — seperti GPTBot milik OpenAI atau ClaudeBot milik Anthropic — yang benar-benar mengunjungi situs, seberapa sering, dan apa yang diterimanya. Log Anda adalah satu-satunya tempat yang mencatatnya. Google Search Console tidak menampilkan bot AI, dan Google Analytics hanya melihat orang yang mengeklik tautan dan tiba di situs, bukan botnya. Perhatikan: banyak traffic mengaku sebagai bot AI terkenal padahal bukan, jadi jangan mempercayai namanya saja.

Apa itu file log

Log akses server mencatat permintaan yang mencapai server, termasuk user-agent, waktu, path, dan detail respons jika dikonfigurasi. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Dokumentasi crawler vendor mengidentifikasi user-agent, tetapi string saja tidak membuktikan bahwa pemintanya asli. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Setiap kali—browser seseorang, Googlebot, atau GPTBot—meminta halaman dari server Anda, server menulis satu baris ke file log. Setiap baris mencatat waktu, alamat IP pengunjung, apa yang diminta, “user-agent” (terjemahan) “agen pengguna” (label yang digunakan pengunjung untuk mengidentifikasi dirinya, seperti GPTBot), dan kode respons yang dikirim server Anda (200 untuk sukses, 404 untuk tidak ditemukan, dan seterusnya).

Analisis log crawler AI hanyalah membaca baris-baris itu dan menyaringnya untuk bot AI. Inilah cara literal untuk menjawab pertanyaan yang tidak dapat dijawab dengan cara lain:

• Apakah bot AI benar-benar mengunjungi situs saya?
• Halaman mana yang diambilnya, dan halaman penting mana yang diabaikannya?
• Apakah ini bot nyata, atau sesuatu yang berpura-pura menjadi bot tersebut?
• Apa yang diterimanya—konten saya yang sebenarnya, atau halaman error?

Jika Anda ingin daftar lengkap bot AI dan fungsi masing-masing (bot pelatihan vs. bot penelusuran vs. bot “fetch ini halaman saat ini” (terjemahan) “ambil halaman ini sekarang”), itu topik terpisah—lihat AI crawler. Halaman ini membahas cara: menarik log dan membacanya.

Mengapa dashboard Anda tidak mencakup ini

• Google Search Console memiliki laporan statistik crawl, tetapi hanya tentang Googlebot. Laporan ini tidak menampilkan GPTBot, ClaudeBot, atau PerplexityBot.
• Google Analytics (GA4) hanya mencatat pengunjung yang mengeklik tautan ke situs Anda dan tiba dengan sebuah “referrer.” (terjemahan) “referrer.” Crawler yang mengambil halaman Anda di latar belakang tidak pernah muncul di sana.

Jadi, log adalah sumber kebenaran utama. Tidak ada hal lain yang melihat bot.

Satu hal yang sering terlewat pemula

Label GPTBot di log Anda tidak membuktikan bahwa bot itu benar-benar OpenAI. Siapa pun dapat menaruh string user-agent apa pun pada permintaan—seperti menulis alamat pengembalian pada amplop. Banyak scraper menempelkan nama bot terkenal pada traffic mereka agar terlihat sah. Satu-satunya cara untuk memastikan adalah memeriksa alamat IP pengunjung terhadap daftar alamat nyata yang diterbitkan perusahaan AI. Langkah verifikasi itu adalah inti pekerjaan ini, dan tab Advanced memandu Anda melaluinya.

TL;DR — Tarik access log Apache/Nginx atau CDN Anda, lalu lakukan empat hal: verifikasi (cocokkan user-agent dan konfirmasikan IP terhadap daftar yang diterbitkan setiap operator—tingkat spoof berkisar dari 5,7% menurut HUMAN Security hingga 81,8% dalam pengujian mandiri Duane Forrester); pilih alat berdasarkan skala (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); ukur frekuensi crawl per bot, halaman yang terkena, crawl-vs-render, dan kode status; lalu interpretasikan dengan jujur—retrieval diperlukan tetapi tidak cukup, jadi “lebih crawling = lebih citations” (terjemahan) “lebih banyak crawling = lebih banyak sitasi” belum terbukti. Ini adalah metode pendamping untuk AI crawler (yang menjelaskan bot apa), AI traffic attribution (sisi klik), dan LLM visibility (kerangka retrieved → mentioned → cited yang diamati di tahap pertama).

Cakupan artikel ini—dan yang tidak dicakup

Log membuktikan permintaan, bukan apakah konten digunakan untuk pelatihan, retrieval, atau sebuah jawaban. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Verifikasi bot menggunakan mekanisme yang diterbitkan provider jika tersedia, dan perlakukan atribusi sebagai bukti yang terbatas. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

artikel AI crawler saudara telah membahas tabel per bot, taksonomi tiga kategori (training / AI-penelusuran / fetch yang dipicu pengguna), perbedaan Google-Extended sebagai token bukan bot, dan resep robots.txt. Saya tidak mengulanginya di sini. AI traffic attribution membahas sisi GA4/referrer — apa yang dikirim kembali bot. Artikel ini adalah sisi berlawanan dari funnel: apa yang diambil bot. Sementara itu, LLM visibility memiliki kerangka retrieved → mentioned → cited; analisis log adalah cara mengamati tahap retrieved secara khusus, bukan tahap setelahnya.

Ini adalah kelanjutan era AI dari analisis log file SEO klasik. Saat meninjau artikel Ahrefs Bagaimana untuk Lakukan an SEO Log File Analysis, dimensinya adalah frekuensi crawl, URL yang di-crawl, kode status, dan verifikasi bot terhadap IP yang diterbitkan Google. Kerangkanya sama di sini, tetapi diarahkan pada populasi bot yang sebagian besar tidak merender JavaScript, terus-menerus ditiru, dan melakukan crawl dalam lonjakan tidak teratur, bukan aliran stabil.

Langkah 1 — Dapatkan log Anda

Log Anda berada di salah satu dari dua tempat, atau keduanya:

• Log server origin. Apache (access.log), Nginx (access.log), atau server aplikasi Anda. Setiap baris minimal memuat timestamp, IP klien, metode permintaan + path, kode status, byte, referrer, dan user-agent.
• Log CDN/edge. Jika Anda berada di balik Cloudflare, Fastly, Akamai, dan sebagainya, banyak traffic bot dijawab di edge dan mungkin tidak pernah mencapai origin—jadi log edge adalah catatan yang lebih lengkap. Cloudflare mengeksposnya melalui Logpush (dan API GraphQL); Fastly melalui streaming log waktu nyata.

Field yang benar-benar Anda perlukan untuk analisis bot AI adalah timestamp, IP klien, user-agent, path permintaan, dan kode status, idealnya ditambah byte dan referrer.

Masalah praktisnya adalah retensi. Banyak host hanya menyimpan log beberapa hari. Tulisan Lauren Busby di Search Engine Land menyebutkan perbaikannya secara langsung—penarikan terjadwal mengubah jendela pendek menjadi sesuatu yang dapat dianalisis dari waktu ke waktu: job SFTP terjadwal, yang dibangun dalam alat workflow seperti n8n atau dibuat dengan skrip, cukup untuk mengubah jendela retensi pendek menjadi data yang dapat Anda analisis dari waktu ke waktu (Busby, SEL). Siapkan sebelum Anda membutuhkan data tersebut.

Satu batasan yang jujur untuk diingat sejak awal: seperti yang dikatakan Busby, file log menunjukkan apa yang mencapai situs Anda, tetapi tidak selalu menunjukkan apa yang mencoba mencapainya (SEL) —permintaan yang diblokir atau dijawab upstream mungkin tidak muncul sama sekali.

Langkah 2 — Verifikasi sebelum memercayai user-agent

Inilah langkah yang membedakan analisis log bot AI dari versi klasik, dan yang sering dilewati panduan lain. String user-agent dapat dipalsukan dengan mudah. Dua titik data independen menunjukkan seberapa buruknya:

• HUMAN Security menganalisis traffic selama dua minggu yang mengklaim berasal dari salah satu dari 16 crawler AI terkenal dan menemukan bahwa 5,7% di antaranya adalah spoof—kira-kira 1 dari 18 permintaan (dilaporkan melalui SEJ).
• Duane Forrester melakukan pemeriksaan yang sama pada lognya sendiri dan menemukan hasil yang jauh lebih buruk. Dari 33 permintaan yang membawa nama langsung-fetch, hanya enam berasal dari IP yang diterbitkan vendor dan 27 tidak—tingkat spoof 81,8% di antara permintaan yang dapat ia periksa (SEJ). Angka Googlebot miliknya bahkan lebih buruk: dari 799 permintaan yang membawa nama Googlebot, hanya 107 berasal dari alamat Google terverifikasi—sekitar 87% lainnya bukan Google (SEJ).

Anggap angka-angka itu sebagai petunjuk dari sampel dan metode yang berbeda, bukan satu angka universal. Yang lebih penting, jangan menggeneralisasi metode verifikasi satu provider ke semua bot. Sebagian operator menerbitkan rentang alamat; yang lain mendokumentasikan token user-agent tanpa rentang publik mutakhir atau kontrak verifikasi DNS (SEJ).

Metode verifikasi:

1. Cocokkan string user-agent. GPTBot mengidentifikasi dirinya dengan Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBot dan ChatGPT-User memiliki token masing-masing (OpenAI bot docs).
2. Gunakan metode verifikasi resmi provider yang mutakhir jika tersedia. OpenAI menerbitkan openai.com/gptbot.json, searchbot.json, dan chatgpt-user.json. Dokumentasi crawler Anthropic yang mutakhir (dokumentasi crawler) menyatakan bahwa alamat dalam daftar yang diterbitkannya menunjukkan crawler berasal dari Anthropic. Gunakan metode spesifik provider yang mutakhir itu; jangan mengubahnya menjadi aturan verifikasi bot universal.
3. Jangan mengarang fallback. Reverse-plus-forward DNS valid untuk sebuah provider hanya jika provider tersebut menerbitkan pola hostname dan prosedur verifikasi. Kecocokan PTR generik hanya membuktikan kendali atas DNS, bukan identitas bot yang diklaim. Screaming Frog Log File Analyser dapat menerapkan daftar yang dikonfirmasi publik jika tersedia; fitur verify-pada-import melakukan lookup terhadap daftar IP yang dikonfirmasi publik untuk memastikan bot asli (Screaming Frog).

Verifikasi seharusnya menginformasikan kebijakan dan respons insiden secara tepat. Utamakan token robots yang didokumentasikan provider untuk kebijakan crawl; simpan kontrol jaringan untuk kasus penyalahgunaan atau keamanan, dan beri label terpisah dari kepatuhan robots.

Langkah 3 — Pilih alat Anda

Skalakan pilihan sesuai ukuran pekerjaan, kira-kira dari gratis → berbayar dan ground truth → terkelola:

• grep / PowerShell — hitungan cepat satu kali dan filter yang sadar verifikasi. Artikel AI crawler memiliki cuplikan dasar penghitungan bot; tab Scripts di sini memperluasnya menjadi verifikasi IP, rincian kode status, dan deteksi crawl-vs-render.
• Screaming Frog Log File Analyser — importer desktop dengan preset bot AI bawaan (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) dan toggle “Verify Bots When Importing” (terjemahan) “Verifikasi bot saat mengimpor”. Tab Response Codes memecah 2XX/3XX/4XX/5XX per URL, tab User Agents menampilkan permintaan dan tingkat error per bot, tab URLs mengurutkan berdasarkan Num Events (halaman yang paling banyak diambil), dan tab IPs memungkinkan penyelidikan sumber mencurigakan (tutorial).
• ELK Stack (Elasticsearch / Logstash / Kibana) atau Splunk — untuk ingest berkelanjutan berskala besar dengan dashboard dan alert, setelah alat desktop satu kali impor terlalu lambat atau Anda membutuhkan pemantauan terus-menerus, bukan ekspor berkala.
• BigQuery — untuk retensi jangka panjang dan kueri SQL berskala besar, biasanya diisi melalui Cloudflare Logpush atau penarikan GraphQL terjadwal dari dataset httpRequestsAdaptiveGroups Cloudflare, sehingga Anda dapat mengueri aktivitas bot berdasarkan halaman, tanggal, dan kode status tanpa mengimpor ulang file datar.
• Cloudflare AI Crawl Control (untuk situs di balik Cloudflare) — dashboard terkelola untuk aktivitas crawler dan pola permintaan, verifikasi bot, serta pelacakan kepatuhan direktif, tanpa membangun pipeline sendiri (dokumentasi).

Langkah 4 — Apa yang diukur dan cara membacanya

Frekuensi crawl per bot. Hit per hari/minggu menurut nama bot. Crawl bot AI datang dalam lonjakan, bukan aliran stabil. Dalam studi kasus log CDN 48 hari WISLR, GPTBot tidak muncul selama berminggu-minggu, lalu menghasilkan 187 permintaan dalam satu minggu—152 di antaranya dalam lonjakan tiga menit, dengan puncak 114 permintaan/menit (WISLR). Baca frekuensi sebagai pola, bukan sekadar total.

Halaman mana yang terkena—dan halaman penting mana yang tidak. Urutkan berdasarkan jumlah permintaan. Busby mencatat crawler AI biasanya tetap dangkal—umumnya hanya terlihat pada halaman tingkat atas: beranda, navigasi utama, dan sedikit URL tingkat tinggi (SEL) —lalu turun tajam pada halaman dalam, bahkan ketika halaman dalam itu penting untuk sitasi. Halaman dalam yang tidak pernah muncul di log tidak dapat diambil.

Ketergantungan mentah HTML — ukur, jangan digeneralisasi. Dokumentasi provider tidak memberikan kontrak rendering JavaScript bersama untuk GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, dan agen lainnya. Satu sinyal teramati tetap berguna: dalam sampel WISLR, ChatGPT-User hanya mengambil HTML — nol permintaan gambar, CSS, atau file JS — sedangkan Googlebot dan OAI-SearchBot juga mengambil gambar (WISLR). Jika log Anda menunjukkan bot AI terus-menerus meminta halaman yang mentah HTML-nya hampir hanya shell JS, itu adalah risiko dependensi yang dapat diperiksa, bukan bukti bahwa setiap provider selalu berperilaku demikian. Bandingkan HTML yang dikirim dengan hasil atau uji fetch spesifik provider. (Untuk dasar rendering, lihat JavaScript SEO.)

Rincian kode status / pemblokiran. Pantau: 200 (sukses), 304 (tidak diubah—baik untuk crawl ulang yang efisien), 404 (tautan rusak yang diikuti bot), dan 403/429 (diblokir/dibatasi lajunya). Busby secara khusus menunjukkan bahwa file log menampilkan tempat crawler menemui masalah, termasuk respons 403 (permintaan diblokir) dan 429 (pembatasan laju) (SEL). Periksa apakah pemblokiran disengaja atau kecelakaan.

Permintaan robots.txt dan llms.txt sebagai sinyal tersendiri. Periksa silang bot mana yang meminta /robots.txt sebelum crawl—dalam sampel WISLR, GPTBot dan Meta-WebIndexer tidak pernah memeriksanya selama 48 hari—dan apakah path yang dilarang tetap terkena. WISLR juga mencatat nol permintaan ke /llms.txt dari bot AI mana pun selama 48 hari (WISLR), selaras dengan temuan sekitar 97% tidak dibaca yang dibahas dalam artikel AI crawlers. Jangan menganggap permintaan llms.txt di log sebagai bukti bahwa file itu “works.” (terjemahan) “benar-benar dipakai atau berfungsi seperti yang diharapkan.”

Apakah lebih banyak crawl berarti lebih banyak sitasi? Bersikaplah jujur.

Tidak ada data mapan yang mendukung “crawl lebih, mendapatkan cited lebih.” (terjemahan) “lebih banyak crawl, lebih banyak sitasi.” Retrieval adalah prasyarat yang diperlukan untuk sitasi tetapi jauh dari cukup—halaman dapat terus-menerus di-crawl dan tidak pernah disitasi, entah karena rendering sisi klien, paywall, konten tipis atau duplikat, atau karena kalah dari sumber yang lebih baik pada langkah retrieval/peringkat model. Kerangka pentingnya ada di artikel LLM visibility: retrieved → mentioned → cited, dan analisis log hanya mengamati tahap pertama itu.

Cara menutup loop dengan jujur adalah memasangkan sisi input crawl (log Anda) dengan sisi output sitasi. Laporan AI Performance Bing (pratinjau publik, Februari 2026) adalah alat resmi pertama yang menampilkan data sitasi bersama kueri grounding—frasa kunci yang digunakan AI ketika mengambil konten yang dirujuk dalam jawaban buatan AI (Bing Webmaster Blog). Log memberi tahu apa yang diambil; kueri grounding dan jumlah sitasi memberi tahu hasilnya. Tidak ada yang sendirian memberi gambaran utuh—lihat hub pengukuran dan pelaporan untuk cara lapisan ini bertumpuk.

Kerutan crawl tersembunyi

Verifikasi bukan audit satu kali. Menurut Clint Spaulding dari Seer Interactive, setelah diblokir, crawler stealth dapat muncul kembali di bawah header browser generik dan IP yang tidak terkait—sesi ini tampak seperti manusia dalam log, sehingga jumlah sesi meningkat secara semu, traffic bot terhitung lebih rendah, dan segmentasi GEO menjadi kurang dapat dipercaya (Seer). Ringkasan lugasnya: jika Anda tidak dapat melihat crawler stealth ini, Anda tidak dapat mengukur dampaknya. Inilah alasan analisis log memerlukan verifikasi ulang dan penetapan baseline berkala, bukan satu kali proses.

Ringkasan AI

Ringkasan singkat versi Advanced:

• AI crawler log analysis = membaca log server/CDN mentah untuk permintaan bot AI guna memverifikasi, dengan data pertama-party, bot mana yang mengakses Anda, apakah asli, dan apa yang diterimanya. GSC (khusus Googlebot) dan GA4 (khusus referrer) tidak melihatnya.
• Cakupan: ini adalah metode. Informasi tentang bot ada di AI crawler; sisi klik ada di AI traffic attribution; kerangka retrieved → mentioned → cited ada di LLM visibility (log hanya mengamati retrieved).
• Pisahkan identitas terverifikasi dari user-agent yang diklaim. User-agent dapat di-spoof — HUMAN Security mengukur 5,7% di 16 bot; Duane Forrester menguji sendiri 81,8% palsu pada permintaan langsung-fetch (87% untuk Googlebot). Cocokkan UA dan periksa IP sumber terhadap daftar resmi operator yang mutakhir jika tersedia (misalnya openai.com/gptbot.json atau claude.com/crawling/bots.json). Jangan mengarang fallback reverse-DNS generik.
• Alat menurut skala: grep → Screaming Frog LFA (preset AI + verify-pada-import) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• Ukur: frekuensi crawl per bot (berbentuk lonjakan, misalnya 152 permintaan GPTBot WISLR dalam 3 menit), halaman yang terkena, ketergantungan mentah HTML (sampel ChatGPT-User WISLR mengambil nol gambar/CSS/JS), kode status (403/429), serta permintaan robots.txt/llms.txt (WISLR mencatat nol hit llms.txt selama 48 hari).
• Crawl ≠ sitasi. Retrieval diperlukan, tetapi tidak cukup — “lebih crawls = lebih citations” (terjemahan) “lebih banyak crawl = lebih banyak sitasi” belum terbukti. Pasangkan log dengan kueri grounding Bing untuk menutup loop.
• Verifikasi ulang secara berkala — crawler stealth yang diblokir dapat muncul kembali dengan tampilan seperti manusia.

Dokumentasi resmi

Sumber primer—file verifikasi milik operator bot dan dokumentasi platform.

OpenAI

• Dokumentasi bot/crawler OpenAI —string user-agent dan perilaku GPTBot, OAI-SearchBot, ChatGPT-User, dan OAI-AdsBot.
• Daftar IP yang diterbitkan untuk verifikasi: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• Apakah Anthropic mengambil data dari web? —nama bot, tujuan, kontrol robots, dan pernyataan bahwa alamat dalam daftar yang diterbitkannya menunjukkan crawler Anthropic.
• Daftar IP crawler Anthropic —sumber verifikasi bersama untuk ClaudeBot, Claude-SearchBot, dan Claude-User.

Google

• Laporan Statistik Crawling —tampilan aktivitas crawl milik Google sendiri (khusus Googlebot; tidak mencakup bot AI pihak ketiga, sehingga log mentah diperlukan).

Cloudflare

• AI Crawl Control —dashboard terkelola untuk aktivitas crawler AI, verifikasi bot, dan kepatuhan direktif.

Bing / Microsoft

• Memperkenalkan AI Performance di Bing Webmaster Tools (Pratinjau Publik) —pasangan hasil sitasi untuk analisis log: Total Citations, Average Cited Halaman, kueri grounding, dan aktivitas sitasi tingkat halaman.

Kutipan dari sumber

Pernyataan tercatat dari operator dan praktisi yang disebutkan.

Anthropic — cakupan saat ini

• Halaman Anthropic saat ini membedakan ClaudeBot, Claude-SearchBot, dan Claude-User, mendokumentasikan penerapan kontrol robots, serta menyatakan bahwa alamat dalam daftar yang diterbitkan menunjukkan crawler Anthropic. Sumber

Lauren Busby, Co-Founder, Trebletree—Search Engine Land

• “Log files adalah itu closest hal untuk itu missing layer. They jangan summarize atau interpret activity. They record it — setiap request, setiap URL, setiap crawler.” (terjemahan) “File log adalah hal yang paling mendekati lapisan yang hilang itu. File log tidak merangkum atau menafsirkan aktivitas. File log merekamnya—setiap permintaan, setiap URL, setiap crawler.”
• “Tools like Screaming Frog Log File Analyzer membuat it possible untuk proses itu data quickly.” (terjemahan) “Alat seperti Screaming Frog Log File Analyzer memungkinkan data itu diproses dengan cepat.”
• Tentang kedalaman crawler AI: “ini umum untuk see them limited untuk top-level halaman – itu homepage, utama navigation, dan a small number dari high-level URLs.” (terjemahan) “Umumnya crawler hanya terbatas pada halaman tingkat atas—beranda, navigasi utama, dan sedikit URL tingkat tinggi.”
• Tentang apa yang ditampilkan: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (terjemahan) “File log juga menunjukkan tempat crawler mengalami masalah. Ini mencakup respons 403 (permintaan diblokir) dan respons 429 (pembatasan laju).”
• Tentang retensi: “A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (terjemahan) “Job SFTP terjadwal—dibangun dalam alat workflow seperti n8n atau dibuat dengan skrip—cukup untuk mengubah jendela retensi pendek menjadi sesuatu yang benar-benar dapat dianalisis dari waktu ke waktu.”
• Batasan yang jujur: “Log files show you what reached your site. They don’t always show you what tried to.” (terjemahan) “File log menunjukkan apa yang mencapai situs Anda. File log tidak selalu menunjukkan apa yang mencoba mencapainya.” Sumber

Duane Forrester—Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (terjemahan) “Dari 33 permintaan yang membawa salah satu nama langsung-fetch itu, enam berasal dari IP yang diterbitkan vendor. Dua puluh tujuh tidak. Itu adalah tingkat spoof 81.8% di antara permintaan yang dapat saya periksa.”
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (terjemahan) “Pemeriksaan sebenarnya tidak rumit. Operator utama menerbitkan alamat IP yang digunakan bot mereka sebagai file biasa yang dapat Anda buka sekarang, dan permintaan hanya sah jika namanya cocok serta alamatnya berada dalam daftar yang diterbitkan.”
• Tentang Googlebot, untuk skala: “Dari 799 requests carrying itu Googlebot name, hanya 107 came dari a verified Google address. Itu other 692, roughly 87%, adalah tidak Google.” (terjemahan) “Dari 799 permintaan yang membawa nama Googlebot, hanya 107 berasal dari alamat Google terverifikasi. Sebanyak 692 lainnya, sekitar 87%, bukan Google.”
• Seruan tindakannya: “Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (terjemahan) “Jangan mengambil angka saya; ambil metodenya… Tarik rentang tanggal, cocokkan nama, verifikasi IP terhadap daftar yang diterbitkan, dan temukan fraksi Anda yang sebenarnya.” Sumber

Clint Spaulding, Senior Manager SEO teknis, Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (terjemahan) “Setelah diblokir, crawler stealth dapat muncul kembali dengan header browser generik dan IP yang tidak terkait.”
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (terjemahan) “Sesi ini tampak seperti manusia dalam log. Akibatnya, jumlah sesi mengembang secara semu, traffic bot kurang terhitung, dan segmentasi GEO menjadi kurang dapat dipercaya.”
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (terjemahan) “Jika Anda tidak dapat melihat crawler stealth ini, Anda tidak dapat mengukur dampaknya.” Sumber

Screaming Frog—tutorial Log File Analyser (dokumentasi produk)

• Tentang verifikasi saat impor: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (terjemahan) “Bot mesin pencari sering dipalsukan, dan fitur ini melakukan pencarian pada daftar IP yang dikonfirmasi publik untuk memastikan keasliannya.”
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (terjemahan) “Jika Anda melihat volume permintaan tinggi dari IP yang tidak lolos verifikasi, kemungkinan Anda menghadapi traffic bot palsu yang seharusnya diblokir di tingkat server.” Sumber

Bing Webmaster Tools—laporan AI Performance (pratinjau publik Februari 2026)

• Kueri grounding: “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (terjemahan) “Menampilkan frasa kunci yang digunakan AI saat mengambil konten yang dirujuk dalam jawaban buatan AI.”
• Total Citations: “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (terjemahan) “Menampilkan jumlah total sitasi yang ditampilkan sebagai sumber dalam jawaban buatan AI selama rentang waktu yang dipilih.” Sumber

”Is this AI-bot request real, and what do I do about it?” (terjemahan) “Apakah permintaan bot AI ini nyata, dan apa yang harus saya lakukan?”

Telusuri satu baris log yang mencurigakan—atau seluruh lalu lintas sebuah bot—melalui alur ini. Inilah logika verifikasi dari Langkah 2 yang diubah menjadi sebuah alur.

Checklist analisis log crawler AI

Prosedur berulang, mulai dari menarik log hingga membacanya:

• Log direkam dengan field yang diperlukan: timestamp, IP klien, user-agent, path permintaan, dan kode status (byte + referrer membantu).
• Anda menarik dari lapisan yang tepat—log CDN/edge jika berada di balik Cloudflare/Fastly (banyak traffic bot tidak pernah mencapai origin).
• Penarikan terjadwal (SFTP/n8n/script) mengalahkan jendela retensi sehingga Anda memiliki riwayat, bukan hanya beberapa hari terakhir.
• Setiap permintaan bot AI diverifikasi: user-agent cocok dan IP sumber diperiksa terhadap daftar yang diterbitkan operator (reverse-DNS sebagai cadangan).
• Permintaan spoof/tidak terverifikasi dikeluarkan dari metrik crawl AI, bukan dihitung sebagai bot bernama tersebut.
• Frekuensi crawl dibuat baseline per bot (pantau pola lonjakan dibanding aliran stabil).
• Halaman yang paling banyak diambil diidentifikasi—dan halaman dalam yang penting dipastikan benar-benar di-crawl.
• Crawl-vs-render diperiksa: apakah bot AI hanya mengambil HTML pada halaman yang kontennya dirender JavaScript? (Catat sebagai uji dependensi mentah HTML; perilaku provider spesifik agen dan mungkin tidak terdokumentasi.)
• Kode status ditinjau: 200/304 sehat; 404 tautan rusak; 403/429 dikonfirmasi disengaja atau diperbaiki.
• Keberadaan permintaan robots.txt diperiksa (apakah bot mengambilnya sebelum crawl?); tidak ada hit tak terduga pada path yang dilarang.
• Dipasangkan dengan data sisi sitasi (kueri grounding Bing / fitur AI GSC) sebelum menarik kesimpulan apa pun tentang “adalah it berfungsi” (terjemahan) “apakah ini berfungsi”.
• Penjadwalan verifikasi ulang—ini bukan audit satu kali (crawler stealth dapat muncul kembali dengan tampilan manusia).

Lembar contekan analisis log crawler AI

File verifikasi (simpan sebagai bookmark)

Kode status yang perlu dipantau

Verifikasi, jangan langsung percaya

• User-agent saja = belum terverifikasi. Cocokkan UA dan data verifikasi yang diterbitkan provider jika tersedia; jika tidak, pertahankan ketidakpastian.
• Tingkat spoof yang terlihat di lapangan: 5,7% (HUMAN, 16 bot) → 81,8% (log langsung-fetch Forrester); 87% Googlebot palsu dalam audit yang sama.

Petunjuk dependensi mentah HTML

• Bot yang hanya mengambil HTML tanpa permintaan .js/.css/gambar adalah pola pengambilan yang teramati. Pada halaman yang bergantung pada JavaScript, ini adalah sinyal risiko, bukan bukti kemampuan universal.

Fakta singkat

• Frekuensi crawl ≠ kemungkinan sitasi. Retrieval diperlukan, tetapi tidak cukup.
• Gunakan token robots yang terdokumentasi untuk kebijakan crawl; pertahankan pemblokiran jaringan sebagai kontrol penyalahgunaan/keamanan yang terpisah.

Skrip untuk menganalisis log crawler AI

Artikel AI crawlers memuat cuplikan dasar “count itu bot hits” (terjemahan) “hitung hit bot”. Skrip berikut melangkah lebih jauh: ekstraksi, verifikasi, perincian kode status, serta deteksi crawl-vs-render.

1. Ekstrak setiap baris AI-bot (grep + regex)

macOS / Linux — satu alternasi untuk user-agent AI umum:

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

Windows PowerShell:

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. Verifikasi IP GPTBot yang diklaim terhadap daftar yang diterbitkan OpenAI

User-agent saja tidak membuktikan apa pun—periksa IP. Ini mengambil daftar OpenAI dan menguji apakah IP dari log Anda berada dalam CIDR yang diterbitkan:

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Untuk Anthropic, ambil daftar saat ini dari https://claude.com/crawling/bots.json dan sesuaikan path jq dengan bentuk yang didokumentasikan. Jika operator lain tidak menerbitkan feed verifikasi saat ini, pertahankan hasilnya sebagai user-agent yang diklaim.

3. Fallback DNS reverse + forward (IP di luar daftar)

Gunakan ini hanya jika provider yang disebutkan menerbitkan akhiran hostname yang diharapkan dan prosedur verifikasi reverse-plus-forward. Ini bukan bukti generik identitas bot:

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. Rincian kode status per bot

Temukan blok 403/429 dan 404s yang ditemui bot:

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. Sinyal dependensi mentah HTML—jenis file apa yang diambil bot?

Jika bot yang diklaim hanya mengambil .html// dan tidak pernah meminta .js/.css/gambar, sementara konten Anda dirender oleh JS, itu adalah sinyal dependensi yang perlu diselidiki:

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Konsol Chrome DevTools—temukan pengambil AI pada halaman langsung

Ini bukan kueri log, melainkan pemeriksaan cepat atas apa yang dikirim halaman dalam HTML mentah dibandingkan setelah JS (apa yang akan dan tidak akan dilihat bot AI). Tempelkan ke Console:

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. Bookmarklet—buka semua daftar IP bot sekaligus

Seret ini sebagai bookmark untuk membuka file verifikasi di tab untuk pencarian cepat:

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP: tinjauan bulanan log crawler AI

Prosedur berulang yang dijalankan sesuai jadwal (bulanan untuk sebagian besar situs; mingguan jika traffic AI penting bagi Anda). Prosedur ini menghasilkan baseline yang dapat dibandingkan setiap kali.

Persiapan

1. Tarik jendela log sejak tinjauan terakhir Anda dari lapisan yang tepat (log CDN/edge jika berada di balik CDN, atau log origin jika tidak). Pastikan penarikan SFTP/n8n terjadwal benar-benar berjalan—kesenjangan di sini diam-diam merusak garis tren.
2. Muat ke alat pencatatan utama Anda (Screaming Frog LFA untuk impor berkala; BigQuery/ELK jika Anda menggunakan pipeline).

Verifikasi (jangan pernah dilewati) 3. Perbarui setiap sumber verifikasi terkini yang diterbitkan provider (gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json, dan claude.com/crawling/bots.json milik Anthropic) —semua ini dapat berubah. 4. Aktifkan verify-pada-import (Screaming Frog) atau jalankan pemeriksaan IP-di-CIDR (tab Scripts) terhadap setiap permintaan bot AI. 5. Pisahkan traffic menjadi terverifikasi dan tidak terverifikasi. Laporkan fraksi yang tidak terverifikasi—itulah tingkat spoof Anda untuk periode ini. Lonjakan adalah temuan tersendiri.

Ukur (hanya traffic terverifikasi) 6. Frekuensi crawl per bot dibanding periode terakhir—catat bot baru, bot yang menghilang, dan lonjakan. 7. Halaman yang paling banyak diambil; pastikan halaman prioritas/dalam benar-benar di-crawl. 8. Pemeriksaan spot dependensi mentah HTML pada 2–3 template yang berat JavaScript (apakah bot hanya mengambil HTML?). 9. Perincian kode status per bot; selidiki cluster baru 403/429/404. 10. Keberadaan permintaan robots.txt / llms.txt dan setiap hit pada path yang dilarang.

Laporkan & bertindak 11. Catat angka periode ini ke lembar berjalan (hit terverifikasi per bot, spoof %, halaman teratas, cluster error) agar Anda memiliki tren, bukan snapshot. 12. Padukan dengan data sisi sitasi (kueri grounding Bing / fitur AI GSC) sebelum menyimpulkan apa pun tentang visibilitas. 13. Catat perbaikan konkret: blokir yang disengaja vs. tidak sengaja, celah render JS, tautan rusak, dan aturan user-agent yang tepat untuk impersonator terkonfirmasi.

Catatan jadwal: jalankan ulang verifikasi setiap periode—jangan menyimpan daftar IP “known-good” (terjemahan) “sudah terbukti baik” dalam cache. Crawler stealth muncul kembali dengan IP baru dan UA browser generik.

Playbook: “GPTBot (atau ClaudeBot) adalah getting 403s / 429s dan I jangan know jika itu pada purpose” (terjemahan) “GPTBot (atau ClaudeBot) menerima 403/429 dan saya tidak tahu apakah itu disengaja”

Runbook linear untuk insiden umum—bot AI terverifikasi menemui error di log Anda. Kerjakan berurutan.

Langkah 1—Pastikan ini bot yang sebenarnya terlebih dahulu. Sebelum hal lain, gunakan metode verifikasi resmi terkini dari provider yang disebutkan. Jika tidak ada, identitas tetap tidak terverifikasi; jangan diam-diam menganggapnya asli atau menurunkannya menjadi spoof. 403 mungkin tetap merupakan WAF Anda yang bekerja sesuai tugasnya.

Langkah 2—Identifikasi respons persis dan asalnya. Tarik perincian kode status untuk bot tersebut (tab Scripts). Apakah 403 (diblokir), 429 (dibatasi laju), atau 503? Catat apakah blokir berada di CDN/WAF, konfigurasi server, atau aturan yang berdekatan dengan robots.txt.

Langkah 3—Putuskan: apakah blokir disengaja?

• Anda memang bermaksud memblokir bot ini (misalnya crawler pelatihan yang Anda pilih untuk tidak diikutsertakan) → 403 bekerja sesuai desain. Pisahkan kebijakan robots yang terdokumentasi dari aturan penyalahgunaan/keamanan tingkat jaringan. Selesai.
• Anda TIDAK bermaksud memblokirnya (misalnya OAI-SearchBot / PerplexityBot dan Anda menginginkan visibilitas AI-penelusuran) → lanjutkan.

Langkah 4—Temukan aturan yang tidak sengaja. Penyebab umum: aturan WAF “bot” (terjemahan) “bot” yang terlalu luas, ambang pembatasan laju yang terlalu rendah untuk crawler yang berpola lonjakan (ingat lonjakan GPTBot WISLR sebesar 114 permintaan/menit—batas per menit dapat memicu pada lonjakan yang sah), robots.txt disallow yang terlupakan, atau blokir geo/ASN yang menangkap rentang milik operator.

Langkah 5—Perbaiki secara tepat. Masukkan bot terverifikasi ke whitelist berdasarkan user-agent + rentang IP yang diterbitkan, atau naikkan batas laju khusus untuk bot terverifikasi tersebut. Jangan melonggarkan perlindungan untuk semua orang.

Langkah 6—Verifikasi perbaikan di log. Setelah menerapkan, tarik ulang log untuk bot tersebut. Anda ingin cluster 403/429 berubah menjadi 200/304 pada halaman yang Anda pedulikan.

Langkah 7—Buat baseline ulang dan pantau. Catat perubahan di lembar berjalan Anda. Periksa kembali periode berikutnya—dan tetap waspada terhadap bot yang muncul kembali dengan UA berbeda jika Anda memang bermaksud memblokirnya (crawling stealth).

Kesalahan analisis log yang menghasilkan kesimpulan keliru

Masing-masing adalah keyakinan yang beredar, alasan keyakinan itu keliru, dan apa yang sebaiknya dilakukan sebagai gantinya.

Mitos: “If my robots.txt blocks a bot, it won’t be in my logs / it’s not a problem.” (terjemahan) “Jika robots.txt saya memblokir bot, bot itu tidak akan muncul di log saya / ini bukan masalah.” Mengapa ini salah: robots.txt adalah permintaan, bukan penegakan. Fetcher yang dipicu pengguna secara eksplisit mengecualikan diri, dan beberapa crawler dilaporkan melewati blokir (Perplexity stealth crawling, Cloudflare Aug 2025). Blokir mungkin diabaikan sepenuhnya. Lakukan sebagai gantinya: Gunakan log untuk memeriksa apakah aturan dipatuhi—cari hit pada path yang dilarang dan apakah bot bahkan meminta /robots.txt.

Mitos: “A GPTBot / ClaudeBot user-agent di my logs berarti ini benar-benar OpenAI / Anthropic.” (terjemahan) “User-agent GPTBot / ClaudeBot di log saya berarti benar-benar OpenAI / Anthropic.” Mengapa ini salah: User-agent mudah dipalsukan—HUMAN Security mengukur 5,7% palsu di antara 16 bot, dan Duane Forrester menemukan 81,8% palsu di antara permintaan langsung-fetch miliknya. Lakukan sebagai gantinya: Cocokkan user-agent dan gunakan metode verifikasi resmi terkini operator jika ada; jika tidak, tandai identitas sebagai tidak terverifikasi.

Mitos: “More AI-crawler hits = more likely to get cited.” (terjemahan) “Lebih banyak hit crawler AI = lebih mungkin dikutip.” Mengapa ini salah: Tidak ada data kausal/korelasional yang mapan untuk mendukungnya. Retrieval diperlukan tetapi tidak cukup—halaman yang sering di-crawl terus-menerus tidak dikutip. Lakukan sebagai gantinya: Anggap log hanya sebagai visibilitas ke tahap retrieved, lalu padukan dengan data sisi sitasi (kueri grounding Bing, fitur AI GSC).

Mitos: “Every AI crawler has the same rendering behavior.” (terjemahan) “Setiap crawler AI memiliki perilaku rendering yang sama.” Mengapa ini salah: Provider tidak menerbitkan satu kontrak JavaScript/subresource bersama, dan perilaku yang teramati berbeda menurut agen dan sampel. Lakukan sebagai gantinya: Bandingkan respons mentah dengan halaman yang dirender, periksa permintaan subresource berdasarkan nama bot, dan beri label hasil sebagai observasi, bukan perilaku universal.

Mitos: “AI bots are at least checking for my llms.txt.” (terjemahan) “Setidaknya bot AI memeriksa llms.txt milik saya.” Mengapa ini salah: Sampel WISLR selama 48 hari mencatat nol permintaan /llms.txt dari bot AI mana pun, selaras dengan temuan ~97% tidak dibaca dalam artikel AI crawlers. Lakukan sebagai gantinya: Jangan menganggap permintaan llms.txt sebagai validasi yang diharapkan; ukur apa yang benar-benar diambil bot.

Mitos: “Network blocking and robots policy are the same control.” (terjemahan) “Pemblokiran jaringan dan kebijakan robots adalah kontrol yang sama.” Mengapa ini salah: robots menyampaikan preferensi crawl; firewall menegakkan akses jaringan dan dapat memengaruhi traffic yang tidak terkait. Lakukan sebagai gantinya: Gunakan aturan user-agent yang terdokumentasi untuk kebijakan, dan simpan pemblokiran jaringan untuk respons penyalahgunaan/keamanan yang dibenarkan secara terpisah.

Kasus nyata

Duane Forrester—tingkat spoof yang diuji sendiri pada log miliknya. Forrester menjalankan metode persis ini di situsnya dan menerbitkan angkanya. Dari 33 permintaan langsung-fetch, hanya 6 berasal dari IP yang diterbitkan vendor—tingkat spoof 81,8%; dari 799 permintaan bernama Googlebot, hanya 107 yang terverifikasi—sekitar 87% palsu (SEJ). Sebelum: Dengan mempercayai user-agent, traffic “AI assistant” (terjemahan) “asisten AI” miliknya tampak nyata. Sesudah: Dengan mencocokkan nama dengan daftar IP yang diterbitkan, sebagian besar ternyata adalah impersonasi. Intinya: Metode lebih penting daripada angka spesifiknya—seperti katanya, tarik rentang tanggal Anda sendiri dan temukan fraksi nyata Anda.

WISLR—48 hari log CDN, ciri crawl-vs-render. Tony Castillo menganalisis 288 566 baris log CDN (12 099 permintaan AI/bot) selama 48 hari (WISLR). Temuan konkret: GPTBot tidak muncul selama berminggu-minggu lalu melonjak 152 permintaan dalam tiga menit (puncak 114 permintaan/menit); ChatGPT-User mengambil nol gambar, CSS, atau JS—ekstraksi HTML murni; dan ada nol permintaan /llms.txt sepanjang jendela tersebut. Sebelum: Anda mungkin menganggap crawl stabil dan bot sadar-JS. Sesudah: log menunjukkan perilaku berpola lonjakan dan hanya HTML—n=1, data dari satu situs, tetapi gambaran jelas tentang apa yang diungkap analisis nyata. Intinya: pola pengambilan tanpa JS adalah bukti langsung di balik pemeriksaan crawl-vs-render.

Cloudflare—rasio crawl terhadap referral pada skala jaringan. Data agregat Cloudflare menunjukkan betapa sedikit crawling yang menjadi traffic: untuk setiap pengunjung yang dirujuk Anthropic kembali ke sebuah situs web, crawler-nya telah mengunjungi puluhan ribu halaman (Cloudflare). Sebelum: intuisi bahwa crawling berat berarti engagement. Sesudah: pada skala jaringan, rasionya timpang—training kini mendorong mayoritas aktivitas bot AI, dan bot training memang tidak dimaksudkan mengirim traffic kembali sama sekali (Cloudflare). Intinya: halaman yang di-crawl berat tanpa referral adalah hal wajar, bukan tanda keberhasilan—itulah tepatnya mengapa frekuensi crawl bukan prediktor sitasi.

Prompt AI siap pakai

Prompt copy-paste untuk menggunakan LLM guna mempercepat analisis log crawler AI. Selalu periksa kewajaran output terhadap log mentah—LLM berhalusinasi, dan pipeline verifikasi yang mempercayai kecocokan IP hasil halusinasi lebih buruk daripada tidak ada pipeline.

Buat parser log yang sadar verifikasi

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

Ringkas laporan kode status + crawl-vs-render

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

Triage IP yang mencurigakan

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

Alat untuk menganalisis log crawler AI

Urutannya kira-kira dari gratis/ground truth → berbayar/terkelola:

• grep / PowerShell — cara tercepat menghitung hit bot dan menerapkan filter sadar verifikasi pada log akses mentah. Tanpa setup; lihat tab Scripts.
• Screaming Frog Log File Analyser — importer desktop dengan preset bot AI bawaan dan toggle “Verify Bots When Importing” (terjemahan) “Verifikasi bot saat mengimpor” yang memeriksa daftar IP yang dikonfirmasi publik. Tersedia tab Response Codes, User Agents, URLs (urutkan berdasarkan Num Events), dan IPs; cocok untuk impor berkala.
• ELK Stack (Elasticsearch / Logstash / Kibana) atau Splunk — ingestion kontinu, dashboard, dan alerting ketika impor desktop terlalu lambat atau Anda membutuhkan pemantauan berkelanjutan.
• BigQuery — retensi jangka panjang dan SQL dalam skala besar, biasanya diisi melalui Cloudflare Logpush atau penarikan GraphQL terjadwal dari httpRequestsAdaptiveGroups.
• Cloudflare AI Crawl Control — untuk situs di balik Cloudflare: tampilan aktivitas crawler, verifikasi bot, dan kepatuhan directive terkelola tanpa pipeline sendiri.
• Google Search Console — Statistik Crawling — bukan untuk bot AI (hanya Googlebot), tetapi menjadi model rincian per crawler + per kode respons yang Anda bangun kembali untuk bot AI dari log mentah.
• Bing Webmaster Tools — AI Performance — padanan hasil sitasi: pasangkan kueri grounding dan jumlah sitasinya dengan log input crawl untuk menutup loop.

Lonjakan traffic bot AI yang diklaim dalam semalam

Gejala: permintaan dengan user-agent crawler terkenal melonjak tiba-tiba. Kemungkinan penyebab: spoofing, traffic pemantauan, atau perubahan crawl nyata. Perbaikan: verifikasi IP sumber terhadap metode terkini yang diterbitkan operator sebelum mengaitkan traffic itu, lalu segmentasikan menurut ASN, path, status, dan waktu.

Log menunjukkan crawling, tetapi konten tidak pernah dikutip

Gejala: bot terverifikasi mengambil halaman tanpa peningkatan sitasi yang terlihat. Kemungkinan penyebab: crawling hanya bukti kelayakan; retrieval dan pemilihan jawaban terpisah. Perbaikan: pastikan bot menerima HTML substantif, lalu evaluasi kemampuan diindeks, kualitas passage, kecocokan kueri, dan penguatan off-site tanpa menganggap jumlah crawl sebagai peringkat.

Setiap permintaan tampak mengembalikan 200

Gejala: URL yang hilang dan konten yang diblokir tercatat sebagai sukses. Kemungkinan penyebab: app shell, aturan CDN, atau halaman error khusus mengembalikan soft 404. Perbaikan: ambil sampel body respons dan header akhir, lalu perbaiki penanganan status alih-alih hanya mempercayai status.

Bot terverifikasi menerima shell kosong

Gejala: browser merender konten, tetapi fetch yang cocok dengan log hanya menerima sedikit HTML berguna. Kemungkinan penyebab: halaman bergantung pada JavaScript sisi klien yang tidak dijalankan crawler. Perbaikan: bandingkan output mentah dan hasil render, lalu sajikan konten serta tautan penting dalam HTML melalui SSR, static rendering, atau strategi pengiriman andal lainnya.

Metrik untuk log crawler AI

Sumber yang layak Anda baca

Tulisan saya yang terkait

• Cara melakukan analisis file log SEO (Ahrefs, ditinjau oleh Patrick Stox & Michal Pecánek) —template era pra-AI yang menjadi sekuel khusus AI untuk artikel ini: apa yang diukur, alat, dan verifikasi bot.
• Apa itu Analisis File Log? (glosarium Ahrefs) —pendamping definisi.
• Kenali crawler web baru: Bot AI mendekati bot mesin pencari —analisis Cloudflare Radar saya tentang pangsa crawl bot AI.
• ~140 juta situs memblokir bot AI ini paling sering —data tingkat pemblokiran robots.txt di web terbuka.
• 80% traffic Pencarian AI kami menuju beranda, halaman produk, dan alat gratis —analisis aktivitas AI berdasarkan jenis halaman, analog dengan “yang halaman mendapatkan crawled.” (terjemahan) “halaman mana yang di-crawl.”

Presentasi saya

• Bagaimana Penelusuran Berfungsi (SlideShare) —panduan saya tentang crawling, rendering, pengindeksan, dan peringkat; latar belakang berguna untuk memahami apa yang dilakukan bot di log Anda. (Penafian tetap berlaku: ini pemahaman saya tentang sistem, bukan jaminan bahwa 100% lengkap atau akurat.)

Dari industri

• Mengapa analisis file log penting untuk crawler AI dan visibilitas penelusuran —Lauren Busby (Trebletree), Search Engine Land: “logs adalah itu missing layer,” (terjemahan) “log adalah lapisan yang hilang”, jendela retensi, dan pembahasan 403/429.
• 81.8% Traffic “AI Assistant” (terjemahan) “Asisten AI” Saya Palsu. Angka Googlebot Lebih Buruk —Duane Forrester, Search Engine Journal: studi kasus verifikasi pihak pertama yang menonjol beserta metodenya.
• Perplexity, crawling AI stealth, dan dampaknya pada GEO serta analisis file log —Clint Spaulding, Seer Interactive: mengapa bot yang diblokir muncul kembali dengan tampilan manusia.
• Cara memantau bot AI di Log File Analyser —Screaming Frog: panduan alat praktis dengan verify-pada-import.
• Celah crawl-ke-klik: data Cloudflare tentang bot AI, training, dan referral —Cloudflare: rasio crawl-ke-referral tingkat jaringan dan perbedaan training vs. penelusuran.
• Apakah Anthropic merayapi data dari web? —dokumentasi Anthropic terkini tentang tujuan bot dan kontrol robots.
• Dokumentasi bot/crawler OpenAI —string user-agent dan file IP yang diterbitkan untuk verifikasi.

Statistik yang layak dikutip

• Tingkat spoof—5,7% di antara 16 crawler AI. Analisis dua minggu HUMAN Security terhadap traffic yang mengaku berasal dari salah satu dari 16 crawler AI terkenal menemukan kira-kira 1 dari 18 permintaan dipalsukan (bersumber dari vendor, disampaikan lewat SEJ).
• Tingkat spoof—81,8% dalam log milik seorang praktisi. Audit mandiri Duane Forrester menemukan 27 dari 33 permintaan langsung-fetch berasal dari IP yang tidak diterbitkan vendor; angka Googlebot miliknya ~87% palsu (SEJ).
• Crawl-ke-referral, ClaudeBot vs. OpenAI. Data Cloudflare (minggu 25 Mei–1 Juni 2026) menempatkan ClaudeBot sekitar ~11 122 halaman di-crawl per referral dan OpenAI ~857:1, dibandingkan Googlebot sekitar 5:1 (Cloudflare).
• Training mendorong sebagian besar aktivitas bot AI. Menurut Cloudflare, training kini mendorong hampir 80% aktivitas bot AI, naik dari 72% setahun sebelumnya—konteks mengapa crawling berat dengan nol referral adalah wajar (Cloudflare).
• Satu jendela log nyata: 288 566 baris, 12 099 permintaan bot, 48 hari. Studi kasus WISLR—dengan lonjakan GPTBot 152 permintaan dalam 3 menit dan pengambilan gambar/CSS/JS nol oleh ChatGPT-User (WISLR).

Uji pemahaman: Analisis Log Crawler AI

Lima pertanyaan singkat tentang mengambil dan membaca log bot AI. Pilih jawaban untuk masing-masing, lalu periksa.

Log perubahan