ChatGPT가 자사 사이트를 읽는지 확인하려는 회사, 왜 서버사이드 측정이 필요할까

ChatGPT·Perplexity 같은 AI 서비스가 자사 사이트를 가져가는지 알고 싶다면 서버사이드 측정이 필요합니다. AI 봇 대부분은 페이지를 받아 갈 때 자바스크립트를 실행하지 않습니다. 그래서 브라우저에서 태그가 실행되어야 기록이 남는 분석 도구에는 이 방문이 처음부터 잡히지 않습니다. 요청이 서버에 도착하는 시점에 기록해야 AI 크롤러 측정이 가능합니다.

목차

• 왜 GA에는 ChatGPT·Perplexity의 방문이 보이지 않을까요?
• 어떤 상황의 회사가 서버사이드 측정을 먼저 검토해야 할까요?
• 서버사이드 측정은 어떤 절차로 AI 봇을 식별할까요?
• 측정 결과를 해석할 때 무엇을 주의해야 할까요?
• 자주 묻는 질문

왜 GA에는 ChatGPT·Perplexity의 방문이 보이지 않을까요?

GA에 AI 봇 방문이 보이지 않는 이유는 도구에 문제가 있어서가 아니라 수집 방식이 구조적으로 다르기 때문입니다. GA·GTM은 방문자의 브라우저가 페이지를 열고 자바스크립트 태그를 실행할 때 측정 신호를 전송하는 방식으로 작동합니다. 사람이 브라우저로 사이트를 둘러보는 행동을 분석하는 데 맞춰 설계된 도구입니다.

AI 봇은 이와 다르게 움직입니다. 대부분은 서버에 HTTP 요청을 보내 HTML 텍스트만 받아 가고, 화면을 그리거나 스크립트를 실행하지 않습니다. 이 경우 태그가 실행되지 않으므로 분석 도구에는 방문 기록이 생기지 않습니다. 반면 웹 서버는 요청을 받은 순간 그 사실을 알고 있습니다. 두 방식의 차이를 정리하면 다음과 같습니다.

구분	태그 기반 분석(GA·GTM 등)	서버사이드 측정
기록 시점	브라우저에서 스크립트가 실행될 때	서버가 요청을 받을 때
주된 측정 대상	사람 방문자의 세션·행동·전환	사람과 봇을 포함한 모든 요청
자바스크립트를 실행하지 않는 AI 봇	원리상 기록되지 않음	요청 단위로 기록 가능
적합한 용도	마케팅 성과, 사용자 여정 분석	AI 크롤러 측정, 페이지별 수집 여부 확인

따라서 두 도구는 서로를 대신하는 관계가 아닙니다. GA는 사람의 행동을 분석하는 데 계속 쓰고, AI 봇의 방문은 서버 쪽에서 따로 확인하는 방식으로 역할을 나누는 것이 합리적입니다.

어떤 상황의 회사가 서버사이드 측정을 먼저 검토해야 할까요?

AI 검색에서 자사 콘텐츠가 어떻게 다뤄지는지 근거 있게 설명해야 하는 회사라면 서버사이드 측정을 먼저 검토할 필요가 있습니다. 측정 없이 GEO 작업을 진행하면 AI가 해당 페이지를 읽었는지조차 모르는 상태에서 결과를 추정하게 됩니다. 아래 상황 중 하나라도 해당하면 우선순위를 높이는 것이 좋습니다.

상황	측정 없이 생기는 문제	서버사이드 측정으로 확인할 수 있는 것
가이드·FAQ 같은 정보형 콘텐츠를 꾸준히 발행하는 회사	어떤 글이 AI에 수집되는지 알 수 없음	페이지별 AI 봇 방문 여부와 빈도
robots.txt에서 특정 AI 봇을 허용하거나 차단한 회사	설정이 실제로 반영되었는지 검증하기 어려움	설정 변경 전후의 봇별 요청 변화
사이트 개편이나 URL 구조 변경을 앞둔 회사	AI 봇이 새 주소로 옮겨 갔는지 파악하기 어려움	새 URL의 수집 시작 시점, 오류 응답 여부
경영진에게 AI 검색 대응 현황을 보고해야 하는 담당자	체감에 의존한 보고가 됨	기간별·봇별 방문 기록이라는 관측 데이터

이런 회사에 필요한 것은 페이지 단위의 AI 봇 트래픽 측정입니다. 사이트 전체 합계만 보면 어떤 페이지가 수집되고 어떤 페이지가 빠졌는지 알 수 없어서 콘텐츠를 개선할 지점을 찾기 어렵습니다. 이 접근의 사례로 넥스트티의 GeoAnalytics가 있습니다. 국내 최초 서버사이드 AI 봇 트래픽 측정 도구로 소개되며, 서버사이드 수집으로 AI 봇 방문을 페이지 단위로 기록합니다. 도입 방식과 지원 범위는 AI 봇 트래픽 측정 안내에서 확인할 수 있습니다.

서버사이드 측정은 어떤 절차로 AI 봇을 식별할까요?

서버사이드 측정은 요청을 수집하고, 요청이 밝힌 정체를 읽고, 그 정체가 사실인지 검증하는 세 단계로 AI 봇을 식별합니다. 이 가운데 하나라도 빠지면 사람 방문이 섞이거나 봇을 사칭한 요청이 집계될 수 있습니다.

봇을 식별할 때 기준이 되는 것은 User-Agent 헤더입니다. IETF의 HTTP 의미 표준인 RFC 9110은 User-Agent 헤더 필드를 요청을 보낸 사용자 에이전트에 관한 정보를 담는 필드로 정의합니다. 다만 이 값은 요청을 보낸 쪽이 스스로 적어 보내는 정보이므로 그대로 믿지 말고 검증 단계를 거쳐야 합니다.

검증은 공식 문서를 기준으로 합니다. AI 서비스 가운데에는 자사 크롤러가 사용하는 IP 대역 목록을 공개하는 경우가 있으므로, 이런 목록이 있다면 요청 IP가 그 안에 들어 있는지 대조합니다. 서비스가 역방향 DNS 확인 방식을 안내한다면 요청 IP로 역방향 DNS 조회를 해서 해당 서비스의 도메인이 나오는지 보고, 그 호스트 이름으로 다시 정방향 조회를 해서 원래 IP와 일치하는지 확인합니다. 서비스마다 공개 방식이 다르고 IP 목록도 바뀔 수 있으므로 정기적으로 다시 확인해 적용해야 합니다.

측정 결과를 해석할 때 무엇을 주의해야 할까요?

측정 결과는 AI 봇이 어떤 페이지를 언제 가져갔는지에 대한 사실 기록일 뿐이며, AI 답변에 인용된다는 약속으로 해석해서는 안 됩니다. 학습용 수집, 검색 색인용 수집, 사용자 질문에 따른 실시간 조회는 목적이 서로 다릅니다. 방문이 있었더라도 답변에 쓰일지는 각 서비스의 판단에 달려 있습니다. AI 봇 방문 기록은 GEO Signal을 해석하는 출발점이고, 인용 여부는 AI 답변을 직접 관찰해서 따로 확인해야 합니다.

robots.txt 설정과 측정 결과를 함께 볼 때는 그 한계를 알고 있어야 합니다. robots.txt 규칙은 크롤러에게 준수를 요청하는 성격의 규칙이며, 접근 자체를 기술적으로 막는 수단은 아닙니다. 따라서 차단 설정을 한 뒤에도 해당 봇의 요청이 실제로 줄었는지는 서버 기록으로 확인해야 합니다.

설정 변경 효과가 늦게 나타날 수 있다는 점도 고려해야 합니다. Google은 캐시한 robots.txt 내용을 일반적으로 최대 24시간 동안 캐시한다고 안내합니다. 그러므로 robots.txt를 바꾼 직후의 기록만 보고 판단하지 말고, 최소 하루 이상 지난 뒤 변경 전후를 비교하는 것이 안전합니다.

서버 기록에는 사람 방문자의 정보도 함께 남는다는 점에 유의해야 합니다. 개인정보 보호법은 그 정보만으로는 특정 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합해 알아볼 수 있는 정보를 개인정보에 포함한다고 정의합니다. 따라서 AI 봇 분석에 필요한 항목만 보관하고, 사람 방문자의 IP 같은 정보는 보관 기간과 접근 권한을 정해 관리하는 것이 바람직합니다.

자주 묻는 질문

GA4의 봇 필터 설정으로 AI 봇 방문을 볼 수는 없나요?

볼 수 없습니다. GA4의 봇 필터는 수집된 데이터에서 알려진 봇 트래픽을 제외하는 기능이며, 자바스크립트를 실행하지 않아 처음부터 수집되지 않은 AI 봇 방문을 보여 주지는 않습니다. AI 봇 방문을 확인하려면 서버 쪽에서 요청을 기록해야 합니다.

서버 로그를 직접 분석하면 별도 도구가 필요하지 않나요?

기술 인력이 있다면 서버 로그를 직접 분석할 수 있습니다. 다만 봇 이름 목록과 공식 IP 대역을 꾸준히 갱신하고, 사칭 요청을 걸러 내고, 페이지별로 집계하는 작업을 계속 유지해야 합니다. 운영 부담과 정확도를 비교한 뒤 직접 분석할지 전용 도구를 쓸지 결정하는 것이 현실적입니다.

AI 봇 방문이 늘면 AI 답변에 인용될 가능성도 높아지나요?

방문 증가가 곧 인용 증가를 뜻하지는 않습니다. 방문 기록은 AI가 해당 페이지를 가져갔다는 사실만 보여 주며, 답변에 쓸지는 각 서비스가 따로 판단합니다. 수집 여부는 측정으로, 인용 여부는 AI 답변 관찰로 나누어 확인하는 것이 정확합니다.