Tenten AIGEO
블로그로 돌아가기
기술 AEO 구현도입·실행

GPTBot이 실제로 웹사이트를 크롤링하는지 서버 로그로 확인하는 법(로그 분석 예시 포함)

GA4에서는 GPTBot을 확인할 수 없습니다. OpenAI의 AI 크롤러가 실제로 웹사이트를 방문했는지 확인하려면 서버 로그를 살펴봐야 합니다. 이 글에서는 grep과 awk로 액세스 로그에서 GPTBot 요청을 찾고, 공식 IP와 대조해 진위를 판별하며, 상태 코드를 해석하고 차단된 페이지를 확인하는 방법을 설명합니다.

Tenten GEO 팀게시일 2026-01-255 분 소요
어두운 서버실에서 빛나는 로그 데이터가 서버에서 라벤더색 광선을 받은 크롤러 형상으로 흘러가며, 로그에 포착된 AI 크롤러를 표현한 이미지

Google Analytics에서는 GPTBot을 볼 수 없습니다. GA4를 비롯한 대부분의 서드파티 분석 도구는 브라우저가 JavaScript를 실행해야 방문을 기록하지만, GPTBot은 JS를 실행하지 않아 추적 코드가 작동하지 않습니다. OpenAI 크롤러가 실제로 페이지를 방문했는지, 어떤 콘텐츠를 가져갔는지, 어떤 응답을 받았는지 입증할 수 있는 신뢰도 높은 근거는 서버의 원본 액세스 로그뿐입니다.

서버 로그가 유일하게 신뢰할 수 있는 근거인 이유

AI 크롤러와 실제 사용자는 사이트에 접근하는 방식부터 다릅니다. 사용자는 브라우저에서 페이지를 열고 JS를 실행해 GA4 이벤트를 발생시키므로 대시보드에 방문 기록이 남습니다. 반면 GPTBot 같은 크롤러는 HTTP 요청을 보내고 반환된 HTML을 수집한 뒤 떠납니다. 추적 코드를 실행하지 않기 때문에 분석 도구에는 아무 기록도 남지 않습니다. 서버 로그는 다릅니다. 요청 주체가 실제 사용자든 Googlebot이든 GPTBot이든, Nginx나 Apache는 모든 요청의 출발지 IP, 시간, 요청 경로, 응답 상태 코드, User-Agent를 한 줄씩 기록합니다. 프런트엔드에서 차단할 수 없고, 요청 주체가 JS를 실행하지 않는다고 사라지지도 않습니다.

GPTBot만 보지 말고 OpenAI의 3가지 크롤러부터 구분합니다

OpenAI 크롤러가 하나뿐이라고 생각해 로그에서 GPTBot만 찾으면 실제 노출 현황을 크게 과소평가할 수 있습니다. OpenAI에는 목적과 User-Agent가 서로 다른 크롤러가 적어도 3가지 있습니다. 각각 구분해 집계해야 합니다.

  • GPTBot: 모델 학습과 개선을 위해 콘텐츠를 가져옵니다. User-Agent에 "GPTBot"이 포함됩니다. robots.txt를 준수하며, 출발지 IP는 openai.com/gptbot.json에 공개됩니다.
  • OAI-SearchBot: ChatGPT 검색 기능에 사용할 인덱스를 생성합니다. User-Agent에 "OAI-SearchBot"이 포함됩니다. ChatGPT 답변에서 콘텐츠가 인용되는 문제와 가장 직접적인 관련이 있습니다.
  • ChatGPT-User: 사용자가 ChatGPT에 특정 링크를 읽어 달라고 요청할 때 작동합니다. User-Agent에 "ChatGPT-User"가 포함됩니다. 이 요청이 보인다면 실제 사용자가 ChatGPT를 통해 해당 페이지에 접근하고 있다는 뜻입니다.
  • 범위를 넓혀 확인합니다. 같은 로그에는 보통 PerplexityBot, ClaudeBot, Google-Extended 등 다른 AI 크롤러의 요청도 남습니다. 분석 방법은 모두 같습니다.

1단계: 액세스 로그에서 GPTBot의 흔적 찾기

가장 일반적인 Nginx combined 형식을 예로 들면 로그 한 줄에는 출발지 IP, 시간, "GET /blog/geo-audit HTTP/1.1", 상태 코드 200, 응답 바이트 수, User-Agent 문자열이 차례로 기록됩니다. GPTBot 요청의 User-Agent 끝부분에는 compatible; GPTBot/1.2; +https://openai.com/gptbot이 표시됩니다. 이 특징을 이용하면 몇 줄의 명령어만으로 GPTBot의 활동을 추려낼 수 있습니다.

  • 모든 GPTBot 요청 찾기: grep -i "GPTBot" /var/log/nginx/access.log
  • 오늘 방문 횟수 집계하기: grep -ic "GPTBot" access.log
  • 응답 상태 코드 분포 확인하기(combined 형식의 9번째 열이 HTTP 상태 코드): grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
  • 가장 자주 가져간 페이지 확인하기(7번째 열이 요청 경로): grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
  • 3가지 크롤러의 크롤링 요청 수 비교하기: grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log

출력 결과만으로도 세 가지를 바로 파악할 수 있습니다. 첫째는 빈도입니다. 하루에 몇 번, 어느 시간대에 방문하는지 확인합니다. 둘째는 범위입니다. 핵심 제품 페이지와 주요 아티클을 가져가는지, 홈페이지 주변만 맴도는지 살펴봅니다. 셋째는 응답 상태입니다. 대부분의 요청에 상태 코드 200이 반환되는지 확인합니다. grep 결과가 비어 있다면 해당 기간에 GPTBot이 한 번도 방문하지 않았다는 뜻입니다. robots.txt나 방화벽이 차단하고 있는지 점검해야 합니다.

액세스 로그 확보, GPTBot 진위 확인, 상태 코드 해석의 3단계 흐름을 보여주는 도식
서버 로그에서 AI 크롤러를 검증하는 3단계: grep으로 요청을 찾고, 공식 IP와 대조해 진위를 확인한 뒤, 상태 코드로 크롤링 응답 상태를 판단합니다.

2단계: 로그에 찍힌 GPTBot이 진짜인지 확인하기

User-Agent 문자열은 얼마든지 위조할 수 있습니다. 일반 크롤러는 물론 악성 트래픽도 헤더에 "GPTBot"을 넣어 신원을 가장하고, 특정 규칙을 우회하거나 서버 자원을 소모할 수 있습니다. 따라서 요청을 찾은 뒤에는 진위를 검증해야 합니다. 신뢰도 높은 방법은 두 가지입니다.

  • 공식 IP 목록과 대조합니다. OpenAI는 크롤러별 출발지 IP 대역을 openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json에 공개합니다. 로그의 출발지 IP가 해당 크롤러의 공식 대역에 포함될 때만 유효한 요청으로 집계합니다.
  • 역방향 DNS를 검증합니다. 출발지 IP를 PTR 조회(host 또는 dig -x)하면 실제 GPTBot은 OpenAI가 관리하는 도메인으로 확인됩니다. 이어 해당 도메인을 정방향 조회해 원래 IP로 돌아오는지 확인합니다(forward-confirmed rDNS). 양쪽 결과가 모두 일치해야 신뢰할 수 있습니다.

3단계: 어떤 페이지를 가져갔고 어떤 상태 코드를 받았는지 확인하기

크롤러가 방문했다고 해서 콘텐츠 수집까지 성공한 것은 아닙니다. ChatGPT에 인용될 가능성을 좌우하는 것은 각 요청에서 실제로 어떤 응답을 받았느냐입니다. 다음 4가지 신호를 확인해야 합니다.

  • 상태 코드: 이상적인 결과는 모두 200입니다. 403이 대량으로 발생한다면 Cloudflare나 WAF가 GPTBot을 의심스러운 트래픽으로 보고 차단했을 가능성이 큽니다. 404는 사이트맵이나 내부 링크가 유효하지 않은 URL을 가리킨다는 뜻입니다. 5xx가 계속된다면 크롤러 방문 시 서버 오류가 발생하고 있는 것입니다.
  • 수집된 페이지: 요청 경로 목록에서 인용 가능성이 높은 가격 페이지, 요금제 페이지, 심층 아티클이 포함됐는지 확인합니다. 홈페이지와 오래된 글 몇 개만 가져간다면 핵심 콘텐츠가 AI에 노출되지 않고 있다는 뜻입니다.
  • llms.txt와 robots.txt 요청 여부: 크롤러가 /llms.txt와 /robots.txt를 요청했는지 로그에서 확인할 수 있습니다. llms.txt를 배치했는데도 한 번도 읽지 않았다면 현재 해당 크롤러는 이 파일을 활용하지 않는다는 뜻입니다. 역할을 과대평가해서는 안 됩니다.
  • 크롤링 빈도와 최신성: 아티클을 게시하거나 수정한 시점과 GPTBot이 다시 방문한 시점을 비교합니다. 재방문 간격이 너무 길다면 새 콘텐츠가 모델의 이해에 반영되기까지 오랜 시간이 걸릴 수 있습니다.

최적화에 앞서 로그부터 확인합니다

llms.txt를 작성하고, 구조화 데이터(Schema)를 보완하고, 콘텐츠를 다시 쓰기 전에 액세스 로그부터 10분만 grep으로 확인해 보십시오. Tenten이 맡았던 한 사례에서는 고객사의 llms.txt와 Schema가 모두 잘 구축돼 있었습니다. 그러나 로그를 살펴보니 반년 동안 GPTBot의 모든 요청에 WAF가 403을 반환하고 있었습니다. 그전에 진행한 최적화는 전혀 효과를 낼 수 없는 상태였습니다. 로그는 GPTBot이 방문했는지, 무엇을 가져갔는지, 어디서 차단됐는지를 그대로 보여줍니다. GEO 기술 최적화에서 비용은 가장 적게 들지만 가장 중요한 단계입니다. 로그에 어떤 브랜드 노출 공백이 숨어 있고 무엇부터 개선해야 하는지 알고 싶다면 30분 GEO 진단을 예약할 수 있습니다. 실제 크롤링 상태를 직접 확인하고, 우선 실행할 수 있는 개선 지점을 짚어드립니다.

자주 묻는 질문

GPTBot이 Google Analytics에 표시되나요?
표시되지 않습니다. GA4는 브라우저가 JavaScript를 실행해야 방문을 기록하지만, GPTBot은 JS를 실행하거나 추적 코드를 작동시키지 않기 때문에 완전히 누락됩니다. 방문 여부를 확인할 수 있는 근거는 서버의 원본 액세스 로그뿐입니다.
로그의 GPTBot이 진짜인지 어떻게 확인하나요?
두 가지 방법이 있습니다. 먼저 출발지 IP를 OpenAI가 openai.com/gptbot.json에 공개한 공식 IP 대역과 대조합니다. 다음으로 역방향 DNS 조회와 forward-confirmed rDNS 검증을 진행합니다. 두 결과가 모두 일치해야 신뢰할 수 있습니다.
GPTBot의 크롤링 상태를 빠르게 확인하려면 어떤 명령어를 사용하나요?
grep -i "GPTBot" access.log로 요청을 찾은 뒤 awk '{print $9}' | sort | uniq -c로 상태 코드 분포를 확인합니다. 403이 대량으로 나타난다면 대개 WAF나 방화벽에 차단된 상태입니다.

다음 단계

AI 답변에서 우리 브랜드는 얼마나 보일까요?

30분 GEO 진단을 통해 주요 AI 엔진에서의 가시성 격차와 우선 개선 과제를 확인해 보세요.

30분 진단 예약