AI 검색이 우리 사이트를 읽고 있을까: 서버 로그로 확인하는 법

유입이 없다는 것과 접근이 없다는 것은 다르다

GA4나 PostHog는 대체로 브라우저에서 실행된 이벤트를 봅니다. 검색 로봇과 AI 관련 크롤러가 페이지를 요청해도 자바스크립트를 실행하지 않으면 방문 세션으로 남지 않을 수 있습니다. 반대로 브라우저 유입이 있다고 해당 서비스가 사이트를 직접 수집했다는 뜻도 아닙니다.

서버 로그에는 요청 시각, URL, 응답 코드, 사용자 에이전트, 응답 크기 같은 흔적이 남습니다. 이 정보로 ‘접근을 시도했는가’와 ‘정상 문서를 받았는가’를 확인할 수 있습니다.

처음에는 여섯 필드면 충분하다

사용자 에이전트 이름만 믿으면 안 된다

누구나 요청 헤더에 유명 크롤러 이름을 쓸 수 있습니다. 서비스가 공식 IP 확인 방법을 제공한다면 역방향·정방향 DNS나 공개 IP 범위처럼 공식 절차를 사용하세요. 요청 빈도와 경로도 함께 보고, 의심스러운 트래픽을 이유 없이 허용하지 않습니다.

OpenAI는 ChatGPT 검색 포함을 위해 OAI-SearchBot 접근과 공개 IP 대역 허용을 안내합니다. ChatGPT 검색 공식 안내를 확인하되 이 봇을 허용한다고 노출이 보장되는 것은 아닙니다. 학습용 봇과 검색용 봇의 역할도 서비스 문서에서 구분해야 합니다.

상태 코드별로 다음 확인이 달라진다

200 응답이면 끝이라는 오해

서버가 200을 반환해도 로그인 화면, 빈 앱 셸, ‘잠시 후 다시 시도’ 메시지를 보냈을 수 있습니다. 핵심 페이지의 HTML을 직접 저장해 제목, 본문 첫 문단, canonical, robots 메타가 들어 있는지 확인하세요. 모바일·국가별 라우팅이 다르면 같은 URL에서 다른 응답이 나올 수도 있습니다.

Naver 서치어드바이저는 robots.txt를 루트에서 일반 텍스트로 제공하고 정상 2xx 응답을 주며, 사이트맵 위치를 알릴 수 있다고 설명합니다. 공식 robots.txt 가이드와 실제 서버 응답이 일치하는지 확인하세요.

일주일 로그 점검 순서

• 핵심 제품·가격·가이드 URL 목록을 만든다.
• 공식적으로 식별 가능한 검색·AI 크롤러 요청만 필터링한다.
• URL별 요청 수보다 4xx·5xx·리다이렉트·빈 응답을 먼저 찾는다.
• 배포·방화벽 변경 시점과 오류 발생 시점을 맞춘다.
• 브라우저와 curl로 같은 URL의 HTML을 재현한다.
• 해결 뒤 동일한 요청이 정상화됐는지 확인한다.
• 접근 정상화와 검색·AI 가시성 변화는 별도 지표로 기록한다.

개인정보와 로그 비용도 설계해야 한다

전체 쿼리 문자열과 요청 헤더를 무기한 저장하면 이메일, 토큰, 검색어 같은 민감 정보가 섞일 수 있습니다. 필요한 필드만 수집하고 쿼리 값을 마스킹하며 접근 권한과 보관 기간을 정하세요. 크롤러 분석을 위해 실제 사용자 로그 전체를 외부 도구로 보내지 않는 편이 좋습니다.

요청량이 많다면 모든 성공 로그를 오래 보관하기보다 오류와 핵심 URL을 우선하고 집계 데이터를 남깁니다. 조사에 필요한 표본 원문과 운영 지표를 분리하세요.

로그로 증명할 수 없는 것도 분명하다

크롤러가 페이지를 가져갔다고 색인, 학습, 답변 사용, 인용을 증명하지는 못합니다. 요청이 없다고 어떤 AI도 해당 정보를 모른다고 단정할 수도 없습니다. 검색 제휴나 다른 색인, 외부 출처를 사용할 수 있기 때문입니다.

서버 로그는 파이프라인의 접근 단계를 확인하는 증거입니다. 접근이 정상임을 확인한 뒤 검색 색인, 답변 원문, 인용 URL, 실제 유입을 순서대로 연결해야 전체 상황을 이해할 수 있습니다.