AI 크롤러 로그 분석

요약 — AI 크롤러 로그 분석은 서버의 원시 액세스 로그를 살펴보며 OpenAI의 GPTBot이나 Anthropic의 ClaudeBot 같은 AI 봇이 실제로 사이트를 방문했는지, 얼마나 자주 방문했고 무엇을 받아 갔는지 확인하는 작업입니다. 이를 기록하는 곳은 로그뿐입니다. Google Search Console에는 AI 봇이 표시되지 않으며, Google Analytics는 봇 자체가 아니라 링크를 클릭해 들어온 사람만 확인합니다. 다만 유명 AI 봇이라고 주장하는 트래픽 중에는 가짜가 많으므로 이름만 믿어서는 안 됩니다.

로그 파일이란

서버 액세스 로그는 서버에 도달한 요청을 기록하며, 설정에 따라 사용자 에이전트, 시간, 경로, 응답 세부 정보가 포함됩니다. 이 주장에 대한 근거 Server access logs record requests and can include fields such as request path, status, referrer, and user agent. 범위: Apache HTTP Server logging; available fields depend on server configuration. 신뢰도: 높음 · 검증일: 2026-07-14 Apache: Log files 공급업체의 크롤러 문서에는 사용자 에이전트가 명시되어 있지만, 문자열만으로 요청자가 진짜인지 입증할 수는 없습니다. 이 주장에 대한 근거 OpenAI publishes user-agent tokens and controls for several of its crawlers. 범위: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. 신뢰도: 높음 · 검증일: 2026-07-14 OpenAI: Crawlers

사람의 브라우저, Googlebot, GPTBot 등 무엇이든 서버에 페이지를 요청하면 서버는 로그 파일에 한 줄을 작성합니다. 각 줄에는 시간, 방문자의 IP 주소, 요청한 항목, 방문자가 자신을 식별할 때 사용하는 이름인 “user-agent”(예: GPTBot), 서버가 돌려준 응답 코드(성공은 200, 찾을 수 없음은 404 등)가 기록됩니다.

AI 크롤러 로그 분석은 이 기록을 읽고 AI 봇의 요청만 추려내는 작업입니다. 다른 방법으로는 답할 수 없는 다음 질문에 답할 수 있습니다.

• AI 봇이 실제로 내 사이트를 방문하기는 했는가?
• 어떤 페이지를 가져갔고, 어떤 중요한 페이지는 무시했는가?
• 진짜 봇이었는가, 아니면 봇을 사칭한 요청이었는가?
• 실제 콘텐츠를 받아 갔는가, 아니면 오류 페이지를 받았는가?

AI 봇의 전체 목록과 각각의 용도(학습 봇, 검색 봇, 지금 바로 특정 페이지를 가져오는 봇)가 궁금하다면 별도 주제인 AI 크롤러를 참고하세요. 이 페이지에서는 로그를 확보하고 읽는 방법을 다룹니다.

대시보드로는 확인할 수 없는 이유

• Google Search Console의 크롤링 통계 보고서는 Googlebot만 다룹니다. GPTBot, ClaudeBot, PerplexityBot에 대한 정보는 표시하지 않습니다.
• **Google Analytics(GA4)**는 사이트의 링크를 클릭하고 “referrer”(리퍼러)와 함께 도착한 방문자만 기록합니다. 백그라운드에서 페이지를 가져가는 크롤러는 여기에 전혀 나타나지 않습니다.

따라서 로그가 실제 상황을 확인하는 기준입니다. 다른 곳에서는 봇을 볼 수 없습니다.

초보자가 놓치기 쉬운 한 가지

로그에 GPTBot이라고 표시되어 있다고 해서 실제로 OpenAI의 요청이라는 뜻은 아닙니다. 누구나 요청에 원하는 사용자 에이전트 문자열을 넣을 수 있습니다. 봉투에 발신 주소를 적는 것과 같습니다. 많은 스크레이퍼가 정상적인 요청처럼 보이려고 유명 봇의 이름을 붙입니다. 확실히 확인하려면 방문자의 IP 주소를 AI 회사가 공개한 실제 주소 목록과 대조해야 합니다. 이 검증 단계가 올바른 분석의 핵심이며, 고급 탭에서 자세히 설명합니다.

요약 — Apache/Nginx 또는 CDN 액세스 로그를 확보한 다음 네 가지 작업을 수행하세요. 검증: 사용자 에이전트가 일치하는지 확인하고 각 운영자의 공개 목록으로 IP도 확인합니다. 사칭 비율은 HUMAN Security의 5.7%부터 Duane Forrester가 직접 조사한 81.8%까지 나타났습니다. 도구 선택: 규모에 맞춰 grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare를 선택합니다. 측정: 봇별 크롤링 빈도, 요청한 페이지, 크롤링과 렌더링의 차이, 상태 코드를 확인합니다. 정직한 해석: 콘텐츠를 가져오는 것은 필요조건이지 충분조건이 아니므로 “크롤링이 많을수록 인용도 많다”는 주장은 입증되지 않았습니다. 이 글은 방법을 다루며, 봇의 정체를 설명하는 AI 크롤러, 클릭을 다루는 AI 트래픽 기여도 분석, 가져옴 → 언급 → 인용이라는 체계를 설명하는 LLM 가시성과 연결됩니다. 로그로 관찰하는 것은 그 첫 단계입니다.

이 글에서 다루는 것과 다루지 않는 것

로그는 요청이 있었다는 사실을 보여줄 뿐, 콘텐츠가 학습, 검색·가져오기 또는 답변에 사용되었는지는 보여주지 않습니다. 이 주장에 대한 근거 Server access logs record requests and can include fields such as request path, status, referrer, and user agent. 범위: Apache HTTP Server logging; available fields depend on server configuration. 신뢰도: 높음 · 검증일: 2026-07-14 Apache: Log files 공급업체가 공개한 검증 방법이 있다면 이를 사용하고, 요청 주체의 식별 결과를 한계가 있는 증거로 취급하세요. 이 주장에 대한 근거 OpenAI publishes user-agent tokens and controls for several of its crawlers. 범위: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. 신뢰도: 높음 · 검증일: 2026-07-14 OpenAI: Crawlers

관련 글인 AI 크롤러에서는 이미 봇별 표, 세 가지 분류(학습 / AI 검색 / 사용자 요청에 따른 가져오기), Google-Extended가 봇이 아니라 토큰이라는 구분, robots.txt 설정 예시를 다룹니다. 여기서는 이를 다시 설명하지 않습니다. AI 트래픽 기여도 분석은 GA4와 리퍼러, 즉 봇이 돌려보낸 트래픽을 다룹니다. 이 글은 퍼널의 반대쪽, 봇이 가져간 것을 다룹니다. LLM 가시성은 가져옴 → 언급 → 인용이라는 체계를 다루며, 로그 분석으로 관찰할 수 있는 것은 구체적으로 가져옴 단계뿐입니다. 그 이후는 알 수 없습니다.

이 글은 전통적인 SEO 로그 파일 분석의 AI 시대 후속편입니다. 제가 Ahrefs의 How to Do an SEO Log File Analysis 글을 검토했을 때 분석 항목은 크롤링 빈도, 크롤링한 URL, 상태 코드, Google의 공개 IP를 통한 봇 검증이었습니다. 기본 틀은 같지만, 여기서는 대부분 JavaScript를 렌더링하지 않고, 끊임없이 사칭당하며, 일정하게 방문하기보다 불규칙하게 요청을 몰아 보내는 봇들을 대상으로 합니다.

1단계 — 로그 확보

로그는 다음 두 곳 중 하나 또는 양쪽 모두에 있습니다.

• 원본 서버 로그. Apache(access.log), Nginx(access.log) 또는 애플리케이션 서버의 로그입니다. 각 줄에는 최소한 타임스탬프, 클라이언트 IP, 요청 메서드와 경로, 상태 코드, 바이트 수, 리퍼러, 사용자 에이전트가 포함됩니다.
• CDN / 엣지 로그. Cloudflare, Fastly, Akamai 등을 사용하면 많은 봇 요청이 엣지에서 처리되어 원본 서버에 전혀 도달하지 않을 수 있습니다. 따라서 엣지 로그가 더 완전한 기록입니다. Cloudflare는 Logpush와 GraphQL API로, Fastly는 실시간 로그 스트리밍으로 이를 제공합니다.

AI 봇 분석에 실제로 필요한 필드는 타임스탬프, 클라이언트 IP, 사용자 에이전트, 요청 경로, 상태 코드이며, 바이트 수와 리퍼러도 있으면 좋습니다.

현실적인 문제는 보관 기간입니다. 많은 호스팅 업체가 로그를 며칠만 보관합니다. Lauren Busby의 Search Engine Land 글은 해결책을 직접 제시합니다. 정기적으로 로그를 수집하면 짧은 보관 기간을 넘어 시간에 따른 분석이 가능해집니다. n8n 같은 워크플로 도구나 스크립트로 예약된 SFTP 작업을 구성하는 것만으로도 장기간 분석할 자료를 확보할 수 있습니다(Busby, SEL). 데이터가 필요해지기 전에 설정하세요.

처음부터 기억해야 할 한계도 있습니다. Busby의 설명대로 로그 파일은 사이트에 도달한 요청을 보여주지만, 도달을 시도한 모든 요청을 보여주지는 않습니다(SEL). 상위 구간에서 차단되거나 응답이 완료된 요청은 로그에 전혀 나타나지 않을 수 있습니다.

2단계 — 사용자 에이전트를 믿기 전에 검증

이 단계가 AI 봇 로그 분석을 전통적인 분석과 구별하며, 다른 많은 안내 글에서 빠뜨리는 부분이기도 합니다. 사용자 에이전트 문자열은 아주 쉽게 위조할 수 있습니다. 문제의 규모를 보여주는 서로 독립적인 두 가지 관측 결과가 있습니다.

• HUMAN Security는 유명 AI 크롤러 16개 중 하나라고 주장하는 트래픽을 2주간 분석하여 5.7%가 사칭 트래픽이라는 사실을 확인했습니다. 대략 요청 18건 중 1건입니다(SEJ의 보도).
• Duane Forrester가 자신의 로그에서 같은 검사를 했을 때는 결과가 훨씬 나빴습니다. 실시간 가져오기 봇 이름을 사용한 요청 33건 중 공급업체가 공개한 IP에서 온 것은 6건, 그렇지 않은 것은 27건이었습니다. 확인 가능한 요청의 사칭 비율은 81.8%였습니다(SEJ). Googlebot 수치는 더 나빴습니다. Googlebot이라는 이름을 사용한 요청 799건 중 검증된 Google 주소에서 온 것은 107건뿐이었고, 나머지 약 87%는 Google의 요청이 아니었습니다(SEJ).

이 수치들은 서로 다른 표본과 방법에서 나온 경향을 보여줄 뿐, 하나의 보편적인 비율이 아닙니다. 더 중요한 것은 한 공급업체의 검증 방법을 모든 봇에 일반화하지 않는 것입니다. 일부 운영자는 주소 범위를 공개하지만, 현재 공개 주소 범위나 DNS 검증 절차 없이 사용자 에이전트 토큰만 문서화하는 운영자도 있습니다(SEJ).

검증 방법:

1. 사용자 에이전트 문자열을 대조합니다. GPTBot은 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot으로 자신을 식별합니다. OAI-SearchBot과 ChatGPT-User는 각각 별도의 토큰을 사용합니다(OpenAI 봇 문서).
2. 공급업체가 현재 공식 검증 방법을 제공한다면 그 방법을 사용합니다. OpenAI는 openai.com/gptbot.json, searchbot.json, chatgpt-user.json 목록을 제공합니다. Anthropic의 현재 크롤러 문서 내용에 따르면 공개 목록 안에 포함된 주소는 Anthropic에서 온 크롤러임을 나타냅니다. 해당 공급업체의 현재 방법을 사용하고, 이를 모든 봇에 적용되는 보편적인 검증 규칙으로 일반화하지 마세요.
3. 임의의 대체 방법을 만들지 않습니다. 역방향 조회 후 정방향 조회를 수행하는 DNS 검증은 해당 공급업체가 호스트 이름 패턴과 검증 절차를 공개했을 때만 유효합니다. 일반적인 PTR 일치는 DNS 제어권을 입증할 뿐, 주장하는 봇의 정체를 입증하지 않습니다. Screaming Frog의 Log File Analyser는 공개적으로 확인된 목록이 있을 때 이를 적용할 수 있습니다. 가져오기 시 검증 기능은 공개적으로 확인된 IP 목록과 대조하여 진짜 봇인지 확인합니다(Screaming Frog).

검증 결과는 정밀한 정책 설정과 사고 대응에 활용해야 합니다. 크롤링 정책에는 공급업체가 문서화한 robots 토큰을 우선 사용하세요. 네트워크 제어는 악용이나 보안 사례에 사용하고 robots 준수 여부와 구분하여 표시하세요.

3단계 — 도구 선택

작업 규모에 맞춰 선택하세요. 대략 무료 → 유료, 원시 기록 직접 분석 → 관리형 서비스 순서입니다.

• grep / PowerShell — 일회성으로 빠르게 집계하고 검증 여부를 고려해 필터링할 때 사용합니다. AI 크롤러 글에 기본 봇 집계 코드가 있으며, 이 글의 스크립트 탭에서는 IP 검증, 상태 코드별 분석, 크롤링과 렌더링의 구별로 확장합니다.
• Screaming Frog Log File Analyser — AI 봇 사전 설정(GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot)과 “Verify Bots When Importing”(가져올 때 봇 검증) 옵션을 제공하는 데스크톱 가져오기 도구입니다. Response Codes 탭은 URL별 2XX/3XX/4XX/5XX를, User Agents 탭은 봇별 요청과 오류율을 보여줍니다. URLs 탭에서 Num Events로 정렬하면 가장 많이 가져간 페이지를 확인할 수 있고, IPs 탭에서는 의심스러운 요청 출처를 조사할 수 있습니다(사용 안내).
• ELK Stack(Elasticsearch / Logstash / Kibana) 또는 Splunk — 대시보드와 알림을 갖춘 지속적인 대규모 수집에 적합합니다. 단일 가져오기 방식의 데스크톱 도구가 너무 느려지거나, 주기적인 내보내기 대신 상시 모니터링이 필요할 때 사용합니다.
• BigQuery — 대규모 데이터의 장기 보관과 SQL 조회에 적합합니다. 흔히 Cloudflare Logpush나 Cloudflare의 httpRequestsAdaptiveGroups 데이터세트를 정기적으로 수집하는 GraphQL 작업에서 데이터를 받습니다. 일반 파일을 다시 가져오지 않고 페이지, 날짜, 상태 코드별 봇 활동을 조회할 수 있습니다.
• Cloudflare AI Crawl Control(Cloudflare를 사용하는 사이트) — 직접 파이프라인을 구축하지 않고 크롤러 활동과 요청 패턴, 봇 검증, 지시문 준수를 추적할 수 있는 관리형 대시보드입니다(문서).

4단계 — 측정할 항목과 해석 방법

봇별 크롤링 빈도. 봇 이름별 일간·주간 요청 수입니다. AI 봇은 일정하게 방문하지 않고 요청을 몰아 보냅니다. WISLR의 48일간 CDN 로그 사례에서 GPTBot은 몇 주 동안 나타나지 않다가 한 주에 요청 187건을 보냈습니다. 그중 152건이 3분 동안 몰렸고, 최고치는 분당 114건이었습니다(WISLR). 빈도는 합계뿐 아니라 패턴으로 읽으세요.

요청한 페이지와 요청하지 않은 중요한 페이지. 요청 수로 정렬하세요. Busby는 AI 크롤러가 홈페이지, 기본 내비게이션, 소수의 상위 URL처럼 얕은 수준에 머무는 경우가 흔하다고 설명합니다(SEL). 인용에 가장 중요한 것이 깊은 페이지여도 방문은 급격히 줄어듭니다. 로그에 전혀 나타나지 않는 깊은 페이지는 가져올 수 없습니다.

원시 HTML 의존성 — 측정하되 일반화하지 마세요. 공급업체 문서에는 GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot 및 다른 에이전트에 공통으로 적용되는 JavaScript 렌더링 보장이 없습니다. 그래도 유용한 관측 패턴은 있습니다. WISLR 표본에서 ChatGPT-User는 HTML만 가져갔고 이미지, CSS, JS 파일 요청은 전혀 없었습니다. 반면 Googlebot과 OAI-SearchBot은 이미지도 가져갔습니다(WISLR). 원시 HTML이 거의 빈 JS 껍데기인 페이지에 AI 봇이 반복해서 요청한다면 확인 가능한 의존성 위험입니다. 모든 공급업체가 항상 그렇게 동작한다는 증거는 아닙니다. 전달한 HTML을 결과 또는 공급업체별 가져오기 테스트와 비교하세요. 렌더링의 기초는 JavaScript SEO를 참고하세요.

상태 코드와 차단 내역. 200(성공), 304(변경 없음 — 효율적인 재크롤링이므로 좋은 신호), 404(봇이 따라간 깨진 링크), 403/429(차단 / 속도 제한)를 확인하세요. Busby는 로그에서 크롤러가 겪는 문제를 확인할 수 있으며, 특히 403 응답(차단된 요청)과 429 응답(속도 제한)을 짚습니다(SEL). 의도한 차단인지 실수인지 확인하세요.

robots.txt와 llms.txt 요청을 별도의 신호로 확인. 어떤 봇이 크롤링 전에 /robots.txt를 요청하는지, 금지된 경로에도 요청하는지 교차 확인하세요. WISLR 표본에서 GPTBot과 Meta-WebIndexer는 48일 동안 이를 한 번도 확인하지 않았습니다. 같은 48일 동안 어떤 AI 봇에서도 /llms.txt 요청은 한 건도 기록되지 않았습니다(WISLR). 이는 AI 크롤러 글에서 다룬 약 97%가 읽히지 않았다는 결과와도 일치합니다. llms.txt가 “효과가 있다”는 증거로 로그에 해당 요청이 나타나기를 기대하지 마세요.

크롤링이 많으면 인용도 많을까요? 정직하게 해석하세요.

“크롤링을 더 많이 하면 더 많이 인용된다”는 주장을 뒷받침하는 확립된 데이터는 없습니다. 콘텐츠를 가져오는 것은 인용의 필요조건이지만 충분조건과는 거리가 멉니다. 클라이언트 측 렌더링, 유료 장벽, 빈약하거나 중복된 콘텐츠, 또는 모델의 검색·순위 결정 단계에서 더 나은 출처에 밀리는 등의 이유로 계속 크롤링되면서도 전혀 인용되지 않는 페이지가 있습니다. 핵심 체계는 LLM 가시성 글의 가져옴 → 언급 → 인용이며, 로그 분석으로 관찰하는 것은 그 첫 단계뿐입니다.

이를 정직하게 연결하려면 크롤링 입력 측면인 로그와 인용 출력 측면을 함께 봐야 합니다. Bing의 AI Performance 보고서(2026년 2월 공개 미리보기)는 인용 데이터와 그라운딩 쿼리, 즉 AI 생성 답변에서 참조한 콘텐츠를 가져올 때 AI가 사용한 핵심 구문을 함께 보여주는 첫 공식 도구입니다(Bing Webmaster Blog). 로그는 무엇을 가져갔는지, 그라운딩 쿼리와 인용 수는 그 결과가 무엇인지 보여줍니다. 어느 하나만으로는 전체를 알 수 없습니다. 이 층위들을 어떻게 연결하는지는 측정 및 보고 허브를 참고하세요.

은밀한 크롤링이라는 변수

검증은 일회성 감사가 아닙니다. Seer Interactive의 Clint Spaulding에 따르면 차단된 은밀한 크롤러는 일반 브라우저 헤더와 관련 없는 IP를 사용해 다시 나타날 수 있습니다. 이런 세션은 로그에서 사람처럼 보이므로 세션 수는 부풀려지고, 봇 트래픽은 적게 집계되며, GEO 세분화의 신뢰성은 낮아집니다(Seer). 그의 요지는 명확합니다. 이런 은밀한 크롤러를 볼 수 없다면 영향도 측정할 수 없습니다. 따라서 로그 분석은 한 번으로 끝내지 말고 주기적으로 다시 검증하고 기준선을 갱신해야 합니다.

AI 요약

고급 버전의 핵심을 간추리면 다음과 같습니다.

• AI 크롤러 로그 분석은 원시 서버/CDN 로그에서 AI 봇 요청을 읽는 작업입니다. 자사 데이터로 어떤 봇이 방문했는지, 진짜인지, 무엇을 받아 갔는지 검증합니다. GSC(Googlebot만)와 GA4(리퍼러만)에서는 이를 볼 수 없습니다.
• 범위: 이 글은 방법을 다룹니다. 봇의 정체는 AI 크롤러, 클릭은 AI 트래픽 기여도 분석, 가져옴 → 언급 → 인용 체계는 LLM 가시성에서 다룹니다. 로그로는 가져옴만 관찰합니다.
• 검증된 정체와 주장하는 사용자 에이전트를 구분하세요. 사용자 에이전트는 위조됩니다. HUMAN Security는 16개 봇에서 5.7%를, Duane Forrester는 자신의 실시간 가져오기 요청에서 81.8%(Googlebot은 87%)의 가짜 비율을 측정했습니다. UA를 대조하고 동시에 운영자의 현재 공식 목록이 있으면 출발지 IP를 확인하세요. 예를 들면 openai.com/gptbot.json이나 Anthropic의 claude.com/crawling/bots.json입니다. 일반적인 역방향 DNS 대체 검증법을 임의로 만들지 마세요.
• 규모별 도구: grep → Screaming Frog LFA(AI 사전 설정과 가져오기 시 검증) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• 측정: 봇별 크롤링 빈도(요청이 몰리는 패턴 — WISLR에서는 GPTBot 요청 152건이 3분에 집중), 요청한 페이지, 원시 HTML 의존성(WISLR의 ChatGPT-User 표본에서는 이미지/CSS/JS 요청이 전혀 없음), 상태 코드(403/429), robots.txt/llms.txt 요청(WISLR에서는 48일간 llms.txt 요청 0건)을 확인합니다.
• 크롤링 ≠ 인용. 가져오기는 필요조건이지 충분조건이 아닙니다. “크롤링 증가 = 인용 증가”는 입증되지 않았습니다. 로그와 Bing의 그라운딩 쿼리를 함께 보며 입력과 결과를 연결하세요.
• 주기적으로 재검증하세요. 차단된 은밀한 크롤러는 사람처럼 보이는 요청으로 다시 나타납니다.

공식 문서

1차 출처인 봇 운영자의 검증 파일과 플랫폼 문서입니다.

OpenAI

• OpenAI bots / crawlers docs — GPTBot, OAI-SearchBot, ChatGPT-User, OAI-AdsBot의 사용자 에이전트 문자열과 동작을 설명합니다.
• 검증용 공개 IP 목록: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• Does Anthropic crawl data from the web? — 현재 봇 이름, 용도, robots 제어 방법, 공개 목록에 있는 주소가 Anthropic 크롤러임을 나타낸다는 설명을 제공합니다.
• Anthropic crawler IP list — ClaudeBot, Claude-SearchBot, Claude-User가 현재 공유하는 검증용 목록입니다.

Google

• Crawl Stats report — Google의 크롤링 활동을 보여주는 보고서입니다. Googlebot만 다루고 타사 AI 봇은 포함하지 않으므로, AI 봇 분석에는 원시 로그가 필요합니다.

Cloudflare

• AI Crawl Control — AI 크롤러 활동, 봇 검증, 지시문 준수를 확인하는 관리형 대시보드입니다.

Bing / Microsoft

• Introducing AI Performance in Bing Webmaster Tools (Public Preview) — 로그 분석에 대응하는 인용 결과 측면의 도구입니다. Total Citations(총 인용 수), Average Cited Pages(평균 인용 페이지 수), Grounding Queries(그라운딩 쿼리), 페이지별 인용 활동을 제공합니다.

출처의 직접 인용

운영자와 실명이 명시된 실무자의 공개 발언입니다.

Anthropic — 현재 범위

• Anthropic의 현재 지원 페이지는 ClaudeBot, Claude-SearchBot, Claude-User를 구분하고 robots 제어가 적용되는 방식을 설명합니다. 또한 공개 목록 안의 주소가 Anthropic 크롤러임을 나타낸다고 명시합니다. 출처

Lauren Busby, Trebletree 공동 창업자 — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (번역) 「로그 파일은 그 빠진 층위에 가장 가까운 자료입니다. 활동을 요약하거나 해석하지 않습니다. 모든 요청, 모든 URL, 모든 크롤러를 기록합니다.」
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (번역) 「Screaming Frog Log File Analyzer 같은 도구를 사용하면 이 데이터를 빠르게 처리할 수 있습니다.」
• AI 크롤러의 탐색 깊이에 대해: “It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (번역) 「홈페이지, 기본 내비게이션, 소수의 상위 URL 같은 최상위 페이지에만 머무는 경우가 흔합니다.」
• 드러나는 문제에 대해: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (번역) 「로그 파일은 크롤러가 문제를 겪는 지점도 드러냅니다. 여기에는 403 응답(차단된 요청)과 429 응답(속도 제한)이 포함됩니다.」
• 보관 기간에 대해: “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.” (번역) 「n8n 같은 워크플로 도구로 만들든 스크립트로 작성하든, 예약된 SFTP 작업이면 짧은 보관 기간을 넘어 시간에 따라 실제로 분석할 수 있는 자료를 확보하기에 충분합니다.」
• 명확한 한계: “Log files show you what reached your site. They don’t always show you what tried to.” (번역) 「로그 파일은 사이트에 도달한 요청을 보여줍니다. 도달을 시도한 모든 요청을 보여주지는 않습니다.」 출처

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.” (번역) 「그런 실시간 가져오기 이름 중 하나를 사용한 요청 33건 가운데 공급업체가 공개한 IP에서 온 것은 6건이었고, 27건은 그렇지 않았습니다. 제가 확인할 수 있었던 요청의 사칭 비율은 81.8%입니다.」
• “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.” (번역) 「실제 검사는 복잡하지 않습니다. 주요 운영자는 봇이 사용하는 실제 IP 주소를 지금 바로 열어 볼 수 있는 일반 파일로 공개합니다. 이름이 일치하고 주소가 공개 목록에 포함되어야만 정상 요청입니다.」
• 규모를 비교하기 위한 Googlebot 수치: “Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (번역) 「Googlebot이라는 이름을 사용한 요청 799건 중 검증된 Google 주소에서 온 것은 107건뿐이었습니다. 나머지 692건, 약 87%는 Google의 요청이 아니었습니다.」
• 권고하는 행동: “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.” (번역) 「제 수치를 가져가지 말고 방법을 가져가세요… 날짜 범위를 정해 로그를 확보하고, 이름을 대조하고, 공개 목록으로 IP를 검증하여 자신의 실제 비율을 구하세요.」 출처

Clint Spaulding, Seer Interactive 기술 SEO 선임 관리자

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (번역) 「차단된 은밀한 크롤러는 일반 브라우저 헤더와 관련 없는 IP를 사용해 다시 나타날 수 있습니다.」
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (번역) 「이 세션들은 로그에서 사람처럼 보입니다. 따라서 세션 수는 부풀려지고, 봇 트래픽은 적게 집계되며, GEO 세분화의 신뢰성은 낮아집니다.」
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (번역) 「이런 은밀한 크롤러를 볼 수 없다면 그 영향도 측정할 수 없습니다.」 출처

Screaming Frog — Log File Analyser 사용 안내(제품 문서)

• 가져오기 시 검증에 대해: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (번역) 「검색엔진 봇은 자주 사칭됩니다. 이 기능은 공개적으로 확인된 IP 목록과 대조하여 진짜 봇인지 확인합니다.」
• “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.” (번역) 「검증되지 않는 IP에서 많은 요청이 발생한다면 서버 수준에서 차단해야 할 가짜 봇 트래픽일 가능성이 높습니다.」 출처

Bing Webmaster Tools — AI Performance 보고서(2026년 2월 공개 미리보기)

• Grounding Queries(그라운딩 쿼리): “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (번역) 「AI 생성 답변에서 참조한 콘텐츠를 가져올 때 AI가 사용한 핵심 구문을 보여줍니다.」
• Total Citations(총 인용 수): “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (번역) 「선택한 기간 동안 AI 생성 답변에서 출처로 표시된 총 인용 수를 보여줍니다.」 출처

”이 AI 봇 요청은 진짜인가? 어떻게 대응해야 하는가?”

의심스러운 로그 한 줄이나 특정 봇의 전체 트래픽을 이 흐름에 따라 확인하세요. 2단계의 검증 논리를 순서도로 옮긴 것입니다.

AI 크롤러 로그 분석 체크리스트

로그 수집부터 해석까지 반복해서 수행할 수 있는 점검 절차입니다.

• 필요한 필드인 타임스탬프, 클라이언트 IP, 사용자 에이전트, 요청 경로, 상태 코드를 포함해 로그를 수집하고 있습니다. 바이트 수와 리퍼러도 도움이 됩니다.
• 올바른 계층에서 수집하고 있습니다. Cloudflare/Fastly를 사용하면 CDN/엣지 로그를 수집합니다. 많은 봇 트래픽이 원본 서버에 도달하지 않기 때문입니다.
• 예약 수집(SFTP/n8n/스크립트)으로 보관 기간이 지나기 전에 로그를 확보하여 최근 며칠뿐 아니라 과거 기록도 보유합니다.
• 모든 AI 봇 요청을 검증합니다. 사용자 에이전트를 대조하고 동시에 출발지 IP를 운영자의 공개 목록으로 확인합니다. 역방향 DNS는 보조 수단으로 사용합니다.
• 사칭하거나 검증되지 않은 요청은 해당 봇으로 집계하지 않고 AI 크롤링 지표에서 제외합니다.
• 봇별 크롤링 빈도 기준선을 설정합니다. 몰아서 요청하는지 꾸준히 요청하는지 확인합니다.
• 가장 많이 가져간 페이지를 파악하고, 중요한 깊은 페이지가 실제로 크롤링되는지도 확인합니다.
• 크롤링과 렌더링을 구분해 확인합니다. 콘텐츠가 JS로 렌더링되는 페이지에서 AI 봇이 HTML만 가져가나요? 이를 원시 HTML 의존성 테스트로 기록합니다. 동작은 에이전트별로 다르며 문서화되지 않았을 수도 있습니다.
• 상태 코드를 검토합니다. 200/304는 정상, 404는 깨진 링크입니다. 403/429는 의도된 것인지 확인하거나 수정합니다.
• robots.txt 요청 여부, 즉 봇이 크롤링 전에 이를 가져가는지 확인합니다. 금지된 경로에 예상치 못한 요청이 없어야 합니다.
• “효과가 있는가”라는 결론을 내리기 전에 인용 측 데이터(Bing 그라운딩 쿼리 / GSC AI 기능)와 함께 분석합니다.
• 재검증 일정을 잡습니다. 은밀한 크롤러가 사람처럼 보이는 요청으로 다시 나타나므로 일회성 감사로 끝내지 않습니다.

AI 크롤러 로그 분석 요약표

검증 파일 — 북마크해 두세요

살펴볼 상태 코드

믿기 전에 검증하세요

• 사용자 에이전트만 있으면 미검증 상태입니다. UA를 대조하고 공급업체의 공개 검증 데이터가 있으면 활용하세요. 없다면 불확실성을 그대로 남기세요.
• 실제 관측된 사칭 비율: 5.7%(HUMAN, 봇 16개) → 81.8%(Forrester의 실시간 가져오기 로그). 같은 감사에서 가짜 Googlebot 비율은 **87%**였습니다.

원시 HTML 의존성을 보여주는 단서

• 봇이 HTML만 가져가고 .js/.css/이미지를 전혀 요청하지 않는 것은 관측된 가져오기 패턴입니다. JS에 의존하는 페이지에서는 위험 신호이지만, 모든 봇의 기능을 입증하는 보편적인 증거는 아닙니다.

핵심 사항

• 크롤링 빈도 ≠ 인용 가능성. 가져오기는 필요조건이지 충분조건이 아닙니다.
• 크롤링 정책에는 문서화된 robots 토큰을 사용하고, 네트워크 차단은 별도의 악용·보안 통제로 유지하세요.

AI 크롤러 로그 분석 스크립트

AI 크롤러 글에는 기본적인 봇 요청 집계 코드가 있습니다. 다음 코드는 추출, 검증, 상태 코드별 분석, 크롤링과 렌더링의 구별까지 다룹니다.

1. 모든 AI 봇 로그 줄 추출(grep + 정규식)

macOS / Linux — 흔히 쓰이는 AI 사용자 에이전트를 하나의 선택 패턴으로 묶습니다.

# 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. GPTBot을 자칭하는 IP를 OpenAI 공개 목록으로 검증

사용자 에이전트만으로는 아무것도 입증되지 않습니다. IP를 확인하세요. 다음 코드는 OpenAI 목록을 가져와 로그의 IP가 공개 CIDR 중 하나에 포함되는지 검사합니다.

# 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.

Anthropic의 경우 현재 https://claude.com/crawling/bots.json 목록을 가져오고 문서화된 형식에 맞게 jq 경로를 조정하세요. 다른 운영자가 현재 검증 피드를 공개하지 않는다면 결과를 사용자 에이전트의 주장으로만 남기세요.

3. 역방향 + 정방향 DNS 보조 검증(목록에 없는 IP)

해당 공급업체가 예상 호스트 이름 접미사와 역방향·정방향 검증 절차를 공개한 경우에만 사용하세요. 모든 봇의 정체를 입증하는 일반적인 방법은 아닙니다.

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. 봇별 상태 코드 분석

봇이 받는 403/429 차단 응답과 404 응답을 찾습니다.

# 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. 원시 HTML 의존성 신호 — 봇이 어떤 파일 형식을 가져가는가?

봇을 자칭하는 요청이 .html//만 가져가고 .js/.css/이미지는 전혀 가져가지 않으며 콘텐츠가 JS로 렌더링된다면, 조사해야 할 의존성 신호입니다.

# 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. Chrome DevTools Console — 실제 페이지에서 AI 가져오기 도구 점검

로그 쿼리는 아니지만, 페이지가 원시 HTML로 제공하는 것과 JS 실행 후 제공하는 것, 즉 AI 봇이 볼 수 있는 것과 볼 수 없는 것을 빠르게 확인하는 방법입니다. 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. 북마클릿 — 모든 봇의 IP 목록을 한 번에 열기

빠르게 대조할 수 있도록 검증 파일을 각각의 탭에서 여는 코드입니다. 북마크로 끌어다 놓으세요.

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"));})();

표준 운영 절차: 월간 AI 크롤러 로그 검토

정기적으로 실행하는 절차입니다. 대부분의 사이트는 매월, AI 트래픽이 중요하다면 매주 수행하세요. 매번 서로 비교할 수 있는 기준선을 만듭니다.

준비

1. 올바른 계층에서 지난 검토 이후의 로그를 확보합니다. CDN을 사용하면 CDN/엣지 로그, 그렇지 않으면 원본 서버 로그를 가져옵니다. 예약된 SFTP/n8n 수집이 실제로 실행됐는지 확인하세요. 수집 누락은 눈에 띄지 않게 추세선을 훼손합니다.
2. 기본 분석 도구로 가져옵니다. 정기적인 파일 가져오기는 Screaming Frog LFA, 파이프라인을 사용한다면 BigQuery/ELK를 이용합니다.

검증 — 절대 생략하지 마세요 3. 공급업체의 현재 공개 검증 자료(gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json, Anthropic의 claude.com/crawling/bots.json)를 각각 갱신합니다. 이 자료들은 변경됩니다. 4. 가져오기 시 검증(Screaming Frog)을 켜거나 모든 AI 봇 요청에 IP의 CIDR 포함 여부 검사(스크립트 탭)를 실행합니다. 5. 트래픽을 검증됨과 미검증으로 나눕니다. 미검증 비율을 보고하세요. 이것이 이번 기간의 사칭 비율입니다. 급증 자체가 하나의 발견 사항입니다.

측정 — 검증된 트래픽만 사용 6. 봇별 크롤링 빈도를 이전 기간과 비교합니다. 새로 나타난 봇, 사라진 봇, 요청 급증을 기록합니다. 7. 가장 많이 가져간 페이지를 확인하고 우선순위가 높거나 깊은 페이지가 실제로 크롤링되는지 확인합니다. 8. JS 비중이 높은 템플릿 2–3개에서 원시 HTML 의존성을 표본 점검합니다. 봇이 HTML만 가져가나요? 9. 봇별 상태 코드를 분석하고 새로 나타난 403/429/404 집중 구간을 조사합니다. 10. robots.txt / llms.txt 요청 여부와 금지된 경로에 대한 요청을 확인합니다.

보고와 조치 11. 기간별 수치(봇별 검증된 요청 수, 사칭 %, 상위 페이지, 오류 집중 구간)를 계속 사용하는 시트에 기록하여 일회성 현황이 아닌 추세를 확보합니다. 12. 가시성에 관한 결론을 내리기 전에 인용 측 데이터(Bing 그라운딩 쿼리 / GSC AI 기능)와 함께 분석합니다. 13. 구체적인 수정 작업을 등록합니다. 의도한 차단과 우발적 차단 구별, JS 렌더링 누락, 깨진 링크, 확인된 사칭 요청에 대한 정밀한 사용자 에이전트 규칙 등이 해당합니다.

주기 관련 참고: 매 기간 검증을 다시 실행하세요. “정상으로 확인된” IP 목록을 그대로 캐시해 두지 마세요. 은밀한 크롤러는 새로운 IP와 일반 브라우저 UA로 다시 나타납니다.

대응 지침: “GPTBot(또는 ClaudeBot)이 403 / 429를 받는데 의도한 차단인지 모르겠다”

검증된 AI 봇이 로그에서 오류를 받는 흔한 상황에 대응하는 순차적 절차입니다. 순서대로 수행하세요.

1단계 — 먼저 진짜 봇인지 확인합니다. 다른 작업에 앞서 해당 공급업체의 현재 공식 검증 방법을 사용하세요. 방법이 없다면 정체는 미검증 상태로 남습니다. 설명 없이 진짜로 격상하거나 사칭으로 단정하지 마세요. 403은 WAF가 제 역할을 한 결과일 수도 있습니다.

2단계 — 정확한 응답과 발생 지점을 확인합니다. 해당 봇의 상태 코드별 내역을 가져옵니다(스크립트 탭). 403(차단), 429(속도 제한), 503 중 무엇인가요? CDN/WAF, 서버 설정, robots.txt와 연관된 규칙 중 어디에서 차단이 발생했는지 기록하세요.

3단계 — 의도한 차단인지 결정합니다.

• 이 봇을 차단하려던 경우(예: 참여를 거부한 학습 크롤러) → 403은 의도대로 작동하는 것입니다. 문서화된 robots 정책은 네트워크 수준의 악용·보안 규칙과 별도로 유지하세요. 여기서 마칩니다.
• 차단할 의도가 없었던 경우(예: AI 검색 가시성을 원하므로 OAI-SearchBot / PerplexityBot을 허용하려던 경우) → 계속 진행합니다.

4단계 — 의도치 않은 규칙을 찾습니다. 흔한 원인은 범위가 지나치게 넓은 WAF “봇” 규칙, 요청을 몰아 보내는 크롤러에 비해 너무 낮은 속도 제한, 잊고 있던 robots.txt 금지 규칙, 운영자의 주소 범위를 포함하는 지역/ASN 차단입니다. WISLR의 GPTBot 급증은 분당 114건이었습니다. 분당 상한은 정상적인 집중 요청에도 걸릴 수 있습니다.

5단계 — 정확히 필요한 부분만 수정합니다. 사용자 에이전트와 공개 IP 범위로 검증된 봇을 허용 목록에 추가하거나, 해당 검증된 봇에 한해서만 속도 제한 상한을 높이세요. 모든 요청에 대한 보호를 완화하지 마세요.

6단계 — 로그에서 수정 결과를 검증합니다. 배포 후 해당 봇의 로그를 다시 수집하세요. 중요한 페이지의 403/429 집중 구간이 200/304로 바뀌었는지 확인합니다.

7단계 — 기준선을 갱신하고 관찰합니다. 계속 사용하는 시트에 변경 사항을 기록하세요. 다음 기간에 다시 확인하고, 차단이 의도적이었던 경우에는 봇이 다른 UA로 다시 나타나는 은밀한 크롤링도 경계하세요.

잘못된 결론을 낳는 로그 분석 실수

현장에서 접하는 오해와 그 이유, 대신 해야 할 일을 정리했습니다.

오해: “robots.txt에서 봇을 차단하면 로그에 나타나지 않으며 문제도 없다.” 잘못된 이유: robots.txt는 요청이지 강제 집행이 아닙니다. 사용자 요청에 따른 가져오기 도구는 명시적으로 예외를 두며, 차단을 우회했다고 보고된 크롤러도 있습니다(Perplexity의 은밀한 크롤링, Cloudflare 2025년 8월). 차단 지시를 완전히 무시할 수도 있습니다. 대신 할 일: 로그로 규칙을 지키는지 확인하세요. 금지된 경로의 요청과 봇이 /robots.txt를 요청하기는 하는지 살펴보세요.

오해: “로그의 GPTBot / ClaudeBot 사용자 에이전트는 실제 OpenAI / Anthropic 요청을 뜻한다.” 잘못된 이유: 사용자 에이전트는 쉽게 위조됩니다. HUMAN Security는 16개 봇에서 가짜 비율 5.7%를 측정했고, Duane Forrester는 자신의 실시간 가져오기 요청에서 81.8%를 확인했습니다. 대신 할 일: 사용자 에이전트를 대조하고 운영자의 현재 공식 검증 방법이 있으면 사용하세요. 없다면 정체를 미검증으로 표시하세요.

오해: “AI 크롤러 요청이 많을수록 인용될 가능성이 높다.” 잘못된 이유: 이를 뒷받침하는 확립된 인과·상관 데이터가 없습니다. 가져오기는 필요조건이지 충분조건이 아니며, 많이 크롤링되어도 인용되지 않는 페이지는 흔합니다. 대신 할 일: 로그는 가져옴 단계만 보여주는 것으로 취급하고 인용 측 데이터(Bing 그라운딩 쿼리, GSC AI 기능)와 함께 분석하세요.

오해: “모든 AI 크롤러의 렌더링 동작은 같다.” 잘못된 이유: 공급업체들은 공통된 JavaScript/하위 리소스 동작 보장을 공개하지 않으며 관측된 동작도 에이전트와 표본에 따라 다릅니다. 대신 할 일: 원시 응답과 렌더링된 페이지를 비교하고, 봇 이름별 하위 리소스 요청을 조사하며, 결과를 보편적 특성이 아니라 관측 결과로 표시하세요.

오해: “AI 봇은 적어도 내 llms.txt가 있는지는 확인한다.” 잘못된 이유: WISLR의 48일 표본에서는 어떤 AI 봇에서도 /llms.txt 요청이 한 건도 기록되지 않았습니다. 이는 AI 크롤러 글의 약 97%가 읽히지 않았다는 결과와 일치합니다. 대신 할 일: llms.txt 요청을 당연히 나타나야 할 검증 신호로 취급하지 말고 봇이 실제로 가져가는 것을 측정하세요.

오해: “네트워크 차단과 robots 정책은 같은 통제 수단이다.” 잘못된 이유: robots는 크롤링 선호를 전달하지만 방화벽은 네트워크 접근을 강제 통제하며 관련 없는 트래픽에도 영향을 줄 수 있습니다. 대신 할 일: 정책에는 문서화된 사용자 에이전트 규칙을 사용하고, 네트워크 차단은 별도로 정당화된 악용·보안 대응에만 사용하세요.

실제 사례

Duane Forrester — 자신의 로그에서 직접 측정한 사칭 비율. Forrester는 자신의 사이트에 이 방법을 그대로 적용하고 수치를 공개했습니다. 실시간 가져오기 요청 33건 중 공급업체 공개 IP에서 온 것은 6건뿐이어서 사칭 비율은 81.8%였습니다. Googlebot이라는 이름의 요청 799건 중 검증된 것은 107건뿐으로 약 87%가 가짜였습니다(SEJ). 분석 전: 사용자 에이전트를 믿으면 “AI 어시스턴트” 트래픽이 진짜처럼 보였습니다. 분석 후: 이름과 공개 IP 목록을 대조하자 대부분이 사칭이었습니다. 핵심: 그의 특정 수치보다 방법이 중요합니다. 그가 권한 대로 자신의 날짜 범위를 정해 실제 비율을 구하세요.

WISLR — 48일간의 CDN 로그와 크롤링·렌더링 구별 패턴. Tony Castillo는 48일 동안 CDN 로그 288,566줄(AI/봇 요청 12,099건)을 분석했습니다(WISLR). 구체적으로 GPTBot은 몇 주 동안 나타나지 않다가 3분에 요청 152건을 몰아 보냈고 최고치는 분당 114건이었습니다. ChatGPT-User는 이미지, CSS, JS를 전혀 가져가지 않고 HTML만 추출했으며, 전체 기간에 /llms.txt 요청은 한 건도 없었습니다. 분석 전: 꾸준한 크롤링과 JS를 처리하는 봇을 예상했을 것입니다. 분석 후: 로그는 요청이 몰리는 HTML 전용 동작을 보여줍니다. n=1, 한 사이트의 데이터이지만 실제 분석이 드러내는 것을 생생하게 보여줍니다. 핵심: JS를 전혀 가져가지 않은 패턴이 크롤링과 렌더링을 구별해 점검하는 직접적인 근거입니다.

Cloudflare — 네트워크 규모의 크롤링 대 유입 비율. Cloudflare 집계는 크롤링이 실제 트래픽으로 이어지는 비율이 얼마나 낮은지 보여줍니다. Anthropic이 웹사이트에 방문자 한 명을 보내기까지 크롤러는 이미 수만 페이지를 방문합니다(Cloudflare). 분석 전: 많은 크롤링이 참여로 이어질 것이라는 직관입니다. 분석 후: 네트워크 규모에서 비율은 크게 불균형합니다. 이제 학습이 AI 봇 활동의 대부분을 차지하며, 학습 봇은 애초에 트래픽을 돌려보내기 위한 것이 아닙니다(Cloudflare). 핵심: 많이 크롤링되면서 유입은 전혀 없는 페이지가 정상적인 현상이지 성공의 신호는 아닙니다. 크롤링 빈도가 인용 예측 지표가 아닌 이유입니다.

바로 사용할 수 있는 AI 프롬프트

LLM으로 AI 크롤러 로그 분석을 빠르게 진행하기 위한 복사·붙여넣기용 프롬프트입니다. 결과는 반드시 원시 로그와 대조하여 타당성을 확인하세요. LLM은 환각을 일으킵니다. 환각으로 만들어 낸 IP 일치를 믿는 검증 파이프라인은 없는 것보다 나쁩니다.

검증을 고려하는 로그 파서 초안 작성

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.

상태 코드와 크롤링·렌더링 보고서 요약

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]

의심스러운 IP의 초기 분류

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.

AI 크롤러 로그 분석 도구

대략 무료·원시 기록 직접 분석 → 유료·관리형 서비스 순서입니다.

• grep / PowerShell — 원시 액세스 로그에서 봇 요청을 집계하고 검증을 고려해 필터링하는 가장 빠른 방법입니다. 별도 설정이 필요 없습니다. 스크립트 탭을 참고하세요.
• Screaming Frog Log File Analyser — AI 봇 사전 설정과 공개적으로 확인된 IP 목록을 대조하는 “Verify Bots When Importing”(가져올 때 봇 검증) 옵션이 있는 데스크톱 가져오기 도구입니다. Response Codes, User Agents, URLs(Num Events로 정렬), IPs 탭을 제공합니다. 정기적인 가져오기에 가장 적합합니다.
• ELK Stack(Elasticsearch / Logstash / Kibana) 또는 Splunk — 데스크톱 가져오기가 너무 느리거나 상시 모니터링이 필요할 때 지속적인 수집, 대시보드, 알림을 제공합니다.
• BigQuery — 장기 보관과 대규모 SQL 분석에 적합하며, 흔히 Cloudflare Logpush나 httpRequestsAdaptiveGroups의 정기 GraphQL 수집으로 데이터를 받습니다.
• Cloudflare AI Crawl Control — Cloudflare를 사용하는 사이트에서 직접 파이프라인을 구축하지 않고 크롤러 활동, 봇 검증, 지시문 준수를 확인할 수 있는 관리형 화면입니다.
• Google Search Console — Crawl Stats — AI 봇용은 아니며 Googlebot만 다룹니다. 다만 원시 로그로 AI 봇에 대해 재구성하려는 크롤러별·응답 코드별 분석의 본보기입니다.
• Bing Webmaster Tools — AI Performance — 인용 결과 측면의 도구입니다. 그라운딩 쿼리와 인용 수를 크롤링 입력 로그와 함께 분석해 입력과 결과를 연결하세요.

AI 봇을 자칭하는 트래픽이 하룻밤 사이에 급증

증상: 유명 크롤러 사용자 에이전트를 사용한 요청이 갑자기 증가합니다. 가능성 높은 원인: 사칭, 모니터링 트래픽 또는 실제 크롤링 변화입니다. 해결: 트래픽의 주체를 판단하기 전에 운영자의 현재 공개 방법으로 출발지 IP를 검증한 뒤 ASN, 경로, 상태, 시간별로 나누세요.

로그에는 크롤링이 보이지만 콘텐츠는 전혀 인용되지 않음

증상: 검증된 봇이 페이지를 가져가지만 인용 증가는 보이지 않습니다. 가능성 높은 원인: 크롤링은 대상이 될 수 있다는 증거일 뿐이며, 검색·가져오기와 답변 선택은 별개입니다. 해결: 봇이 실질적인 HTML을 받았는지 확인한 뒤 색인 가능성, 구절의 품질, 쿼리 적합성, 외부 사이트의 뒷받침을 평가하세요. 크롤링 횟수를 순위로 취급하지 마세요.

모든 요청이 200을 반환하는 것처럼 보임

증상: 없는 URL과 차단된 콘텐츠가 성공으로 기록됩니다. 가능성 높은 원인: 앱 셸, CDN 규칙 또는 사용자 정의 오류 페이지가 소프트 404를 반환합니다. 해결: 응답 본문과 최종 헤더를 표본 확인하고, 상태만 믿지 말고 상태 처리 방식을 수정하세요.

검증된 봇이 빈 껍데기만 받음

증상: 브라우저는 콘텐츠를 렌더링하지만 로그와 대조한 가져오기 응답에는 유용한 HTML이 거의 없습니다. 가능성 높은 원인: 페이지가 크롤러가 실행하지 않는 클라이언트 측 JavaScript에 의존합니다. 해결: 원시 출력과 렌더링된 출력을 비교하고 SSR, 정적 렌더링 또는 다른 신뢰할 수 있는 전달 전략으로 핵심 콘텐츠와 링크를 HTML에 담아 제공하세요.

AI 크롤러 로그 지표

읽어 볼 만한 자료

제가 쓴 관련 글

• How to Do an SEO Log File Analysis (Ahrefs, Patrick Stox와 Michal Pecánek 검토) — 측정 항목, 도구, 봇 검증을 다룬 AI 이전 시대의 기본 틀입니다. 이 글은 AI에 특화한 후속편입니다.
• What is Log File Analysis? (Ahrefs 용어집) — 정의를 설명하는 보충 자료입니다.
• Meet the New Web Crawlers: AI Bots Are Closing in on Search Engine Bots — AI 봇의 크롤링 점유율을 분석한 저의 Cloudflare Radar 분석입니다.
• The AI Bots That ~140 Million Websites Block the Most — 공개 웹 전반의 robots.txt 차단율 데이터입니다.
• 80% of Our AI Search Traffic Goes to Our Homepage, Product Pages, and Free Tools — 페이지 유형별 AI 활동 분석으로, “어떤 페이지가 크롤링되는가”에 대응하는 분석입니다.

제 발표

• How Search Works (SlideShare) — 크롤링, 렌더링, 색인 생성, 순위 결정을 설명한 발표로, 로그에서 봇의 행동을 읽는 데 유용한 배경지식입니다. 늘 적용되는 면책 사항도 같습니다. 시스템에 대한 제 이해이며, 100% 완전하거나 정확하다는 보장은 아닙니다.

업계 자료

• Why log file analysis matters for AI crawlers and search visibility — Lauren Busby(Trebletree), Search Engine Land. 로그가 빠진 층위라는 관점, 보관 기간, 403/429를 다룹니다.
• 81.8% Of My “AI Assistant” Traffic Was Fake. The Googlebot Number Was Worse — Duane Forrester, Search Engine Journal. 주목할 만한 자사 데이터 검증 사례와 방법입니다.
• Perplexity, Stealth AI Crawling, and the Impacts on GEO and Log File Analysis — Clint Spaulding, Seer Interactive. 차단된 봇이 사람처럼 보이는 요청으로 다시 나타나는 이유를 설명합니다.
• How to Monitor AI Bots in the Log File Analyser — Screaming Frog. 가져오기 시 검증을 포함하는 실용적인 도구 사용 안내입니다.
• The crawl-to-click gap: Cloudflare data on AI bots, training, and referrals — Cloudflare. 네트워크 수준의 크롤링 대 유입 비율과 학습·검색 활동의 구분을 다룹니다.
• Does Anthropic crawl data from the web? — Anthropic의 현재 봇 용도와 robots 제어 문서입니다.
• OpenAI bots / crawlers docs — 사용자 에이전트 문자열과 검증용 공개 IP 파일을 제공합니다.

인용할 만한 통계

• 사칭 비율 — AI 크롤러 16개에서 5.7%. HUMAN Security가 유명 AI 크롤러 16개 중 하나라고 주장하는 트래픽을 2주간 분석한 결과, 약 18건 중 1건이 사칭이었습니다. 공급업체 수치를 SEJ 보도로 전달된 것입니다.
• 사칭 비율 — 한 실무자의 자체 로그에서 81.8%. Duane Forrester의 자체 감사에서 실시간 가져오기 요청 33건 중 27건이 공급업체가 공개하지 않은 IP에서 왔으며, Googlebot은 약 87%가 가짜였습니다(SEJ).
• 크롤링 대 유입 — ClaudeBot과 OpenAI 비교. Cloudflare 데이터(2026년 5월 25일–6월 1일 주간)에서 유입 1건당 크롤링한 페이지는 ClaudeBot 약 11,122개, OpenAI 약 857:1이었으며 Googlebot은 약 5:1이었습니다(Cloudflare).
• 학습이 AI 봇 활동 대부분을 차지. Cloudflare에 따르면 학습은 이제 AI 봇 활동의 거의 80%를 차지하며, 1년 전 72%에서 증가했습니다. 크롤링이 많아도 유입이 전혀 없는 것이 정상인 이유를 보여주는 맥락입니다(Cloudflare).
• 실제 로그 기간 하나: 288,566줄, 봇 요청 12,099건, 48일. WISLR 사례에는 GPTBot이 3분에 요청 152건을 몰아 보낸 현상과 ChatGPT-User가 이미지/CSS/JS를 전혀 가져가지 않은 결과가 포함됩니다(WISLR).

실력 점검: AI 크롤러 로그 분석

AI 봇 로그를 확보하고 읽는 방법에 관한 짧은 질문 다섯 개입니다. 각 질문의 답을 선택한 뒤 확인하세요.

변경 내역