AI 검색 모니터링, 무엇을 얼마나 자주 봐야 하나

AI 검색 모니터링은 전통 SEO 모니터링과 측정 대상과 방법이 근본적으로 다르다. Googlebot 크롤링 주기와 Search Console 색인 상태만 보는 것으로는 GPTBot·ClaudeBot·PerplexityBot 같은 AI 크롤러가 어떤 경로를 수집하는지, LLM이 실제 답변에서 어떤 소스를 인용하는지 파악할 수 없다. AEO(답변엔진최적화)·GEO(생성형엔진최적화) 관점의 모니터링 항목은 크게 네 계층으로 나뉜다: 크롤러 접근 신호, 구조화 데이터 유효성, LLM 인용 추적, Knowledge Graph 반영 여부. 각 계층마다 적합한 측정 주기와 도구가 다르며, 이를 혼동하면 관측 비용과 노이즈만 늘어난다.

1. AI 크롤러 접근 신호 모니터링

어떤 봇이 어떤 경로를 수집하는가

AI 크롤러는 HTTP User-Agent에 식별자를 포함한다. 주요 봇과 확인 방법은 다음과 같다.

GPTBot (User-Agent: GPTBot/1.1) — 왜: ChatGPT Search·Browsing의 웹 색인 수집원이므로 차단 여부가 ChatGPT 답변 인용에 직접 영향; 어떻게: nginx 로그에서 grep "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn으로 수집 경로 빈도 확인
ClaudeBot (User-Agent: ClaudeBot/1.0) — 왜: Claude의 웹 검색·Tool Use 경로 실시간 수집; 어떻게: 상태코드 200/304 필터링해 수집 성공률 산출, 403·410이 높으면 robots.txt 설정 점검
PerplexityBot (User-Agent: PerplexityBot/1.0) — 왜: Perplexity가 직접 소스를 크롤해 인용 URL을 명시적으로 표기; 어떻게: /sitemap.xml 요청 빈도로 재크롤 주기 추정, 미요청 시 sitemap 등록 경로 점검
CCBot (User-Agent: CCBot/2.0) — 왜: Common Crawl이 오픈소스 LLM 훈련 데이터 원천; 어떻게: 수집 후 훈련 데이터 반영은 다음 모델 릴리스 시점이므로 주간 추세로 장기 관찰

구현 — nginx 로그에서 AI 크롤러 통계 추출

아래 스크립트는 날별 AI 크롤러 접근 통계와 수집 성공률을 산출한다. 권장 실행 주기는 일 1회 cron으로 집계 후 슬랙·텔레그램 알림 연동이다.

import re
from collections import defaultdict

AI_CRAWLERS = {
    "GPTBot": r"GPTBot/",
    "ClaudeBot": r"ClaudeBot/",
    "PerplexityBot": r"PerplexityBot/",
    "CCBot": r"CCBot/",
    "GoogleOther": r"GoogleOther",
}

LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[[^\]]+\] '
    r'"(?P<method>\S+) (?P<path>\S+) \S+" '
    r'(?P<status>\d+) \d+ "[^"]*" "(?P<ua>[^"]*)"'
)

def parse_crawler_stats(log_path: str) -> dict:
    stats = defaultdict(lambda: {"total": 0, "success": 0, "paths": defaultdict(int)})
    with open(log_path) as f:
        for line in f:
            m = LOG_PATTERN.match(line)
            if not m:
                continue
            ua = m.group("ua")
            status = int(m.group("status"))
            path = m.group("path").split("?")[0]
            for name, pattern in AI_CRAWLERS.items():
                if re.search(pattern, ua):
                    stats[name]["total"] += 1
                    if status in (200, 304):
                        stats[name]["success"] += 1
                    stats[name]["paths"][path] += 1
                    break
    return stats

if __name__ == "__main__":
    result = parse_crawler_stats("/var/log/nginx/access.log")
    for bot, data in result.items():
        rate = data["success"] / data["total"] * 100 if data["total"] else 0
        print(f"{bot}: total={data['total']}, success_rate={rate:.1f}%")
        for path, cnt in sorted(data["paths"].items(), key=lambda x: -x[1])[:5]:
            print(f"  {path}: {cnt}회")

2. 구조화 데이터 유효성 모니터링

JSON-LD 스키마 오류는 리치 결과 자격 박탈과 AI 크롤러의 시맨틱 파싱 실패로 이어진다.

Search Console 리치 결과 보고서 — 왜: Google이 실제 파싱한 스키마 오류가 URL 단위로 집계됨; 어떻게: searchconsole.googleapis.com/v1/urlInspection/index:inspect API로 주간 자동 집계, richResultsResult.detectedItems 필드에서 오류 수 추출
배포 시 스키마 자동 검사 — 왜: 신규 템플릿 배포 시 기존 JSON-LD 블록이 덮어써지는 사고가 빈번; 어떻게: CI 파이프라인에서 HTML 빌드 결과물의 application/ld+json 블록 추출 후 필수 필드(author, datePublished, publisher) 존재 여부 assert
FAQPage 마크업 유효성 — 왜: LLM RAG 파이프라인이 Q&A 쌍을 직접 파싱해 답변에 활용; 어떻게: mainEntity 배열 내 acceptedAnswer.text 길이 400자 이상 여부 검사

권장 주기: 배포 시마다 자동 검사 + 주 1회 Search Console API 리포트 집계.

3. LLM 인용 추적 — 가장 불확실한 계층

ChatGPT·Claude·Gemini는 어떤 URL을 인용했는지 공식 API로 외부에 공개하지 않는다. 실무에서 사용할 수 있는 방법은 세 가지다.

수동 프로브 쿼리 — 왜: 브랜드명·제품명·고유 개념이 LLM 답변에 등장하는지 확인하는 가장 신뢰할 수 있는 방법; 어떻게: 주 1~2회, 10~20개 쿼리 템플릿을 복수 LLM에 실행 후 인용 URL·등장 위치를 스프레드시트에 기록
Perplexity API 파싱 — 왜: Perplexity는 응답 JSON의 citations 배열에 출처 URL을 명시적으로 반환; 어떻게: POST https://api.perplexity.ai/chat/completions로 모니터링 쿼리 실행 후 response.citations에서 자사 도메인 포함 여부 추출, 일별 자동화 가능
Bing Webmaster + Copilot 유입 — 왜: Bing이 Copilot 출처 URL 일부를 Search Analytics에 반영; 어떻게: Bing Webmaster /traffic/analytics에서 referrer 패턴으로 Copilot 유입 추정

4. 모니터링 항목·주기·도구 비교

모니터링 항목	SEO 맥락	AEO/GEO 맥락	권장 주기	실용 도구
크롤러 접근 로그	Googlebot 빈도·커버리지	GPTBot·ClaudeBot·PerplexityBot 수집 성공률	일별 집계, 이상 시 즉시 알림	nginx 로그, Cloudflare Analytics
구조화 데이터 유효성	리치 결과 자격	AI 시맨틱 파싱 정확도	배포 시 자동 + 주 1회	Search Console, Schema Validator
LLM 인용 추적	해당 없음	브랜드·URL이 LLM 답변에 등장하는지	주 1~2회(수동) / 일별(Perplexity API)	수동 프로브, Perplexity API
Knowledge Graph 반영	Knowledge Panel 노출	LLM의 엔티티 인식 정확도	월 1회	Google KG Search API, 수동 쿼리
robots.txt·llms.txt 유효성	Disallow 규칙 점검	AI 크롤러 허용 범위 명시 여부	배포 시 자동	robots.txt tester, curl HEAD

5. 흔한 오해: "Google 1위 페이지는 LLM도 자동 인용한다"

많은 실무자가 Google 검색 상위 노출이 LLM 인용을 보장한다고 가정한다. 이는 틀리다. LLM의 훈련 데이터 선정과 RAG 파이프라인의 소스 선택은 Google 페이지랭크와 독립적으로 작동한다. Perplexity가 인용하는 소스는 도메인 권위도보다 콘텐츠의 팩트 밀도, 직접 인용 가능성, 구조화 수준에 더 영향을 받는 경향이 있다(추정: 내부 랭킹 신호는 공개되지 않음). 올바른 대응은 다음과 같다.

H2/H3 헤딩 아래 명확한 단문 답변 배치 — LLM이 문단 단위로 발췌하기 유리한 구조
숫자·날짜·고유명사 포함 팩트 문장을 본문 상단에 집중 배치
FAQ 섹션에 FAQPage JSON-LD 마크업 적용 — LLM이 Q&A 쌍을 직접 파싱
Google 순위 지표와 LLM 인용 지표를 별개 컬럼으로 주간 추적해 상관관계 측정

Q. llms.txt를 설치하면 AI 크롤러가 더 자주 방문하나요?

llms.txt는 크롤링 빈도를 높이는 신호가 아니다. 이 파일의 역할은 AI 에이전트·LLM 파이프라인이 사이트의 주요 문서·API·정책 위치를 기계 판독 가능한 형태로 파악하도록 돕는 것이다. 크롤링 주기는 여전히 AI 크롤러 측의 내부 스케줄에 따라 결정된다. 설치 후 모니터링 포인트는 해당 파일의 HTTP 200 응답 여부와 주요 AI 크롤러가 /llms.txt를 실제로 요청했는지 nginx 로그에서 확인하는 것이다.

Q. AI 크롤러를 robots.txt로 차단했는데 LLM이 여전히 우리 콘텐츠를 인용합니다. 왜 그런가요?

robots.txt 차단은 신규 크롤링을 막지만, 이미 수집된 훈련 데이터에는 소급 적용되지 않는다. CCBot 차단 이전에 Common Crawl이 수집한 스냅샷이 이미 훈련 데이터셋에 포함됐다면, 해당 모델은 다음 버전 릴리스 전까지 해당 콘텐츠를 계속 인용할 수 있다. RAG 기반 실시간 검색(Perplexity 등)은 robots.txt 차단이 즉시 효과를 발휘하지만, 정적 학습 기반 LLM에 대해서는 모델 업데이트 주기를 감안한 장기 추적이 필요하다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.