Cluster · 01 · T2.A · Access Entity
한국 SaaS의 38%가 무의식적으로 GPTBot 또는 ClaudeBot을 차단하고 있다. ChatGPT가 인용하려 도달했지만 Cloudflare가 가로막은 흔적이 access log에 매일 남는다. 사이트 owner가 모르는 사이에.
4GRIT 에디터 • 읽는 시간 9분 • robots.txt · AI Crawlers · Access Entity
–
01 · The Scene
–
01 · The Scene
CTO에게 디버깅을 부탁한다. 30분 후 server access log에서 한 가지 사실이 드러난다. OAI-SearchBot이 사이트에 한 번도 도달한 적이 없다. GPTBot, ClaudeBot도 마찬가지다. PerplexityBot의 도달 시도는 모두 403 Forbidden으로 끝났다. 사이트 root에 robots.txt 파일은 정확하게 작성되어 있고, 모든 AI 봇이 Allow 처리되어 있다. 그런데 봇은 도달조차 못한다.
원인은 robots.txt 파일이 아니다. Cloudflare WAF의 Bot Fight Mode다. 보안팀이 6개월 전 활성화한 봇 보호 기능이 GPTBot·ClaudeBot·OAI-SearchBot 등을 “automated traffic”으로 분류해 robots.txt 파일을 읽기도 전에 차단했다. 사이트 owner는 자기 회사가 AI 답변에서 사라진 6개월 동안 이 사실을 몰랐다.
이 시나리오는 한국 SaaS의 38%에서 측정된 패턴이다(4GRIT 50개사 robots.txt 측정 2026.04). 차단의 원인은 두 가지로 수렴된다. 첫째는 Cloudflare 기본 봇 보호 기능의 인식 부재다. 둘째는 “AI 봇 차단”의 일반 가이드를 무차별 적용한 결과다. 한 줄의 robots.txt 수정 또는 Cloudflare WAF 설정 변경 5분이면 해결되는 문제다. 그러나 그 5분의 작업이 일어나려면 먼저 차단되고 있다는 사실의 인지가 필요하다.
–
02 · Why robots.txt now
1994년의 협약이 2026년 AI 인용을 결정한다
robots.txt는 1994년 Martijn Koster가 제안한 단순 텍스트 파일 협약이다. 사이트 root에 `/robots.txt`로 두면, 검색엔진 봇이 자발적으로 그 파일의 정책을 따른다. 30년간 이 파일은 검색엔진 SEO의 보조 layer였고, 대부분의 사이트 운영자는 한 번 작성한 후 잊어버리는 파일이었다.
2024년 이후 robots.txt가 다시 critical한 파일이 됐다. 이유는 AI 봇 ecosystem의 폭증과 분화다. 1994년에는 한 봇이 한 검색엔진을 위해 있었다. Googlebot은 Google 검색을 위해, Bingbot은 Bing을 위해. 2026년에는 한 회사가 3개 봇을 운영한다. OpenAI는 GPTBot(학습) · OAI-SearchBot(검색) · ChatGPT-User(사용자 트리거) 셋. Anthropic도 ClaudeBot · Claude-SearchBot · Claude-User 셋. Perplexity는 PerplexityBot · Perplexity-User 둘. 같은 회사의 봇이라도 사이트가 어느 봇을 허용하느냐에 따라 학습은 거부하지만 검색에는 노출되는 정밀한 통제가 가능해졌다.
이 분화가 만든 새 규칙은 한 줄로 요약된다. “AI 봇 차단”이라는 문구는 2026년에 의미가 없다. 어느 카테고리의 어느 봇을 차단할지가 별도 결정이다. Hostinger의 66.7억 봇 요청 분석에 따르면 OpenAI의 검색 크롤러(OAI-SearchBot) 커버리지가 4.7%에서 55%로 1년 만에 폭증한 동시에 학습 크롤러(GPTBot) 커버리지는 84%에서 12%로 급감했다. 사이트들이 학습 봇은 차단하기 시작했고, 검색 봇은 점점 더 많은 사이트가 허용하는 방향으로 양극화가 진행 중이다.
–
–
그러나 이 분화의 의미는 한 가지가 더 있다. 학습 봇은 사이트에 단방향 자원 소비다. Am I Cited 2026.01 분석은 GPTBot의 crawl-to-refer 비율이 1,700:1, ClaudeBot이 73,000:1이라고 보고한다. 1,700페이지를 크롤하는 동안 1번의 트래픽 referral을 보낸다는 의미다. Googlebot의 14:1과 비교하면 학습 봇은 사실상 트래픽을 보내지 않는다. 검색 봇과 사용자 트리거 봇은 다르다. 차단하면 ChatGPT·Claude·Perplexity 답변에서 직접 누락되고, 허용하면 답변에 인용되어 인지도와 referral의 두 효과가 모두 발생한다.
요약하면 이렇다. 학습 봇은 정책 결정의 여지가 있고, 검색 봇과 사용자 봇은 거의 모든 사이트에 대해 ALLOW가 합리적이다. 이 단순한 framework가 12개 봇의 정책을 3번의 결정으로 압축한다.
–
03 · 12 Bots · 3 Categories
“학습 봇 / 검색 봇 / 사용자 트리거 봇” 3분 분류로 끝난다
2026년 4월 기준 한국 SaaS가 인지해야 하는 12개 주요 AI 봇을 3개 카테고리로 분류한다. 각 카테고리에 대해 정책 결정 1개씩, 총 3번의 결정으로 robots.txt가 정리된다.
01
학습 봇 · 5종
GPTBot(OpenAI), ClaudeBot(Anthropic), CCBot(Common Crawl, OpenAI·Meta·Google이 공동 사용), Google-Extended(Google AI 학습 token), Bytespider(ByteDance·TikTok). Common Crawl과 Google-Extended는 정확히는 별도 크롤러가 아니라 token에 가깝다. Google-Extended는 HTTP 요청을 보내지 않고 Googlebot이 수집한 데이터의 학습 사용 여부만 토글한다. Bytespider는 robots.txt 명시적 차단을 무시하는 사례가 보고되어 server-level 차단이 추가로 필요한 유일한 학습 봇이다(Cloudflare 2025.08 보고).
학습 봇 정책 결정은 사이트의 콘텐츠 가치 vs 노출 욕구 트레이드오프에 따른다. 콘텐츠 가치가 매우 높고(연구 보고서·독점 데이터·핵심 매뉴얼), 그 콘텐츠가 학습되어 AI에 흡수되는 것이 상업적 손실이라고 판단되면 차단한다. 콘텐츠가 마케팅 자산이고 AI에 학습되는 것이 인지도 확장과 동등하다면 허용한다. 양극단이 아닌 회사는 차단 쪽이 보수적 선택이지만, 차단했을 때 실제 손실은 학습 시점의 한 번, 차단의 효과는 영구라는 비대칭이 있다.
02
검색 봇 · 4종
OAI-SearchBot(OpenAI ChatGPT 검색), Claude-SearchBot(Anthropic 2025.02 분리 출시), PerplexityBot(Perplexity 검색 인덱싱), Applebot(Apple Spotlight·Siri). 4개 모두 사이트 콘텐츠를 인덱싱해 AI 검색 답변의 retrieval source로 활용한다. OpenAI 공식 문서는 분명히 명시한다. “OAI-SearchBot을 차단한 사이트는 ChatGPT 검색 답변에 표시되지 않는다.” Claude-SearchBot, PerplexityBot, Applebot 모두 동일 방향이다.
검색 봇 정책 결정은 사실상 결정이 아니다. 모든 검색 봇 ALLOW가 거의 모든 사이트에 정답이다. 검색 봇이 사이트를 인덱싱하지 않으면 AI 답변에 인용될 가능성이 0이 된다. SEO에서 검색엔진 차단을 검토하지 않는 것과 같은 default다. 예외는 정말 비공개여야 하는 영역(`/admin`·`/internal`·`/staging`)인데 그 영역은 카테고리 무관하게 모든 봇 차단으로 처리되어야 하므로 검색 봇 정책 결정과는 별개다.
03
사용자 트리거 봇 · 3종
ChatGPT-User(OpenAI), Claude-User(Anthropic 2025.10 분리), Perplexity-User(Perplexity). 사용자가 AI에게 특정 URL을 직접 요청했을 때만 fetch하는 봇이다. 자동 크롤링이 아닌 사용자 의도의 직접 표현이다.
사용자 트리거 봇 정책도 거의 모든 사이트에 ALLOW가 합리적이다. 차단하면 사용자가 명시적으로 우리 회사 페이지를 AI에 요청해도 AI가 페이지를 가져오지 못해 답변에서 누락된다. 사용자 의도와 정확히 반대 방향의 결정이다. 단 한 가지 주의가 있다. Perplexity-User는 Cloudflare 2025.08 보고에서 robots.txt 차단을 우회하는 stealth crawl 사례가 documented됐다. ALLOW가 default이지만, 만약 정말 차단하고 싶다면 server-level 또는 Cloudflare WAF 추가 layer가 필요하다.
04
2026년 추가로 인지할 봇 4종
위의 12개 외에 한국 SaaS가 robots.txt 정책에 포함시켜야 하는 추가 학습 봇 4종이 있다. Meta-ExternalAgent(Meta AI · Llama 학습), cohere-ai(Cohere 학습), Amazonbot(Amazon Q + Alexa AI), DuckAssistBot(DuckDuckGo AI). 4개 모두 학습 봇 카테고리에 속하므로 정책 결정은 GPTBot·ClaudeBot 결정과 같이 묶어 처리하면 된다. 학습 봇 5개를 쓰던 기존 robots.txt에 4줄 더 추가해 9개 user-agent block으로 확장. 추가 결정은 없다.
이 4개를 별도로 다루는 이유는 측정 데이터 때문이다. 4GRIT 50개사 server log 분석에서 Meta-ExternalAgent의 도달 빈도가 GPTBot의 60% 수준으로 빠르게 증가 중이고(2026.01 → 2026.04 약 4×), Amazonbot은 한국 e-commerce 사이트에서 특히 활발하다. cohere-ai와 DuckAssistBot은 도달 빈도가 낮지만 향후 12개월 동안 증가가 예상된다. 학습 봇 차단 정책을 적용하기로 결정한 회사는 4개 봇을 함께 추가하는 것이 일관성 있는 결정이다. 일부만 차단하면 학습 데이터가 일부 corpus(예: Common Crawl 경로)로 우회 진입할 수 있다.
–
04 · Decision Matrix
학습 ALLOW/DISALLOW × 검색 ALLOW/DISALLOW = 4 site profiles
3개 카테고리 중 검색 봇과 사용자 트리거 봇은 거의 모든 사이트에 ALLOW이므로 사실상 결정해야 하는 1축은 학습 봇이다. 학습 봇 ALLOW/DISALLOW에 대한 결정이 사이트의 본질적 정체성을 드러낸다.
4개 site profile로 정리한다. Profile A · 양면 ALLOW. 콘텐츠 마케팅 회사, 미디어, blog-heavy SaaS. 콘텐츠가 학습 corpus에 들어가는 것이 인지도와 동등하다는 판단이다. AI 답변에서 학습 시점의 정보로 인용될 가능성과 검색 시점의 인용 가능성 두 채널 모두 활용. 4GRIT 표본에서 약 25%.
Profile B · 학습 DISALLOW · 검색 ALLOW. 가장 일반적인 SaaS 선택이다. 독점 데이터 또는 핵심 콘텐츠가 학습되어 AI 모델 자체에 흡수되는 것은 거부하지만, AI 검색 답변에서는 인용되어 referral 받기를 원하는 경우. 4GRIT 표본에서 약 50%로 가장 흔한 결정이고, 가장 합리적인 default이기도 하다.
Profile C · 양면 DISALLOW. 정부 사이트, 의료 정보, 금융 컴플라이언스 사이트. AI 답변에서의 인용 자체가 컴플라이언스 리스크라고 판단되는 경우다. 한국 SaaS 표본에서는 거의 없다(5% 미만).
Profile D · 학습 ALLOW · 검색 DISALLOW. 비합리적 조합으로, 의도적으로 이 profile을 선택하는 사이트는 거의 없다. 보통 잘못된 가이드의 결과로 발생한다(예: “학습 봇은 트래픽 안 보내니 차단해도 되지만, 검색 봇이 무엇인지는 모름”의 잘못된 적용). 4GRIT 표본의 8%가 이 profile이었고, 100% 의도하지 않은 차단이었다.
–
–
한국 SaaS에 가장 안전한 default은 Profile B다. 학습 봇 5종 모두 DISALLOW, 검색 봇 4종 + 사용자 트리거 봇 3종 모두 ALLOW. 이 결정이 콘텐츠 가치와 AI 인용 가능성 두 마리 토끼를 모두 잡는 합리적 균형이다. 양면 ALLOW(Profile A)로 가는 회사는 콘텐츠 마케팅 capacity가 강한 회사 한정. 양면 DISALLOW(Profile C)로 가는 회사는 GEO 작업 자체를 포기하는 회사이므로 이 글의 대상이 아니다.
–
05 · Cloudflare WAF Layer Collision
robots.txt를 정확히 작성해도 Cloudflare가 가로막는다
한국 SaaS의 38% 무의식 차단 패턴 중 가장 큰 단일 원인은 Cloudflare Bot Fight Mode 또는 Super Bot Fight Mode다. 두 모드는 Cloudflare가 자동으로 “automated traffic”으로 분류한 요청을 challenge하거나 차단한다. AI 봇은 모두 automated traffic이다. robots.txt 파일에 무엇이 적혀 있든 Cloudflare WAF layer가 robots.txt 파일을 읽기도 전에 차단한다는 뜻이다.
2026년 4월 기준 Cloudflare는 추가로 Managed Robots.txt라는 신규 기능을 출시했다. 이 기능을 활성화하면 Cloudflare가 자동으로 GPTBot·ClaudeBot·Bytespider·CCBot·Google-Extended·Applebot-Extended·Meta-ExternalAgent·anthropic-ai를 모두 DISALLOW하는 robots.txt 파일을 자동 생성해 serve한다. 사이트 운영자가 이 기능을 인지하지 못한 채 활성화하면, 자체 robots.txt 파일은 무시되고 Cloudflare가 만든 차단 정책이 대신 노출된다.
–
–
해결은 3단계다. (1) Cloudflare dashboard → Security → Bots → “Bot Fight Mode” / “Super Bot Fight Mode” 비활성화 또는 정밀화. AI 봇 user-agent를 명시적으로 ALLOW에 추가. (2) Cloudflare → Security Settings → “Instruct AI bot traffic with robots.txt” Managed Robots.txt 기능 비활성화. 자체 robots.txt 정책을 사이트가 직접 관리. (3) Cloudflare WAF Custom Rule을 추가해 GPTBot/ClaudeBot/OAI-SearchBot/PerplexityBot/Claude-SearchBot 등 사이트가 ALLOW하기로 결정한 봇의 user-agent를 명시적으로 통과시킴. 동시에 Bytespider 같은 robots.txt 비호환 봇은 Custom Rule로 차단.
Bytespider server-level 차단의 nginx 설정 예시는 다음과 같다. map $http_user_agent $block { default 0; “~*Bytespider” 1; } if ($block) { return 403; }. Apache는 mod_rewrite로 같은 효과를 낸다. 한국 SaaS의 경우 Bytespider 차단은 ChatGPT·Claude 인용에 영향을 주지 않는다. Bytespider는 ByteDance·TikTok의 자체 학습 corpus용이고 OpenAI·Anthropic·Perplexity와는 별개 ecosystem이기 때문이다. 한국 시장에서 Bytespider 차단은 콘텐츠 보호와 AI 인용 둘 다 손실 없이 가능하다.
Cloudflare 외 한국 SaaS가 자주 사용하는 호스팅 환경의 차단 패턴도 정리해야 한다. AWS WAF는 Cloudflare와 GUI/API가 다르지만 동일한 layer 충돌 가능성이 있다. AWS WAF에서는 Web ACL → Rules → Custom Rule로 user-agent 패턴 ALLOW를 명시적으로 추가해야 한다. AWS Managed Rules 중 “AWSManagedRulesAnonymousIpList” 또는 “AWSManagedRulesBotControl-DataCenterIp” 규칙이 활성화된 경우 일부 AI 봇 IP가 anonymous 또는 datacenter 분류로 차단되는 사례가 있다. 측정 방식은 AWS WAF Sample Requests 로그에서 user-agent grep.
한국 클라우드(NHN Cloud · KT Cloud · Naver Cloud)는 자체 WAF가 약하지만 호스팅 회사가 별도 봇 차단 설정을 하는 경우가 있다. Cafe24 호스팅은 특수한 케이스다. 일부 요금제에서 robots.txt 파일이 자동 관리 영역에 있어 사용자가 직접 수정할 수 없다. FTP로 root 영역에 robots.txt 파일을 업로드해도 Cafe24 시스템이 자체 robots.txt를 우선 serve하는 경우가 측정에서 발견됐다. 해결은 Cafe24 customer service 문의 + 자체 robots.txt 우선 사용 옵션 활성화다. 한국 SaaS 50개사 측정에서 Cafe24 호스팅 회사 6개 중 4개가 이 문제로 robots.txt 정책이 무력화되어 있었다.
호스팅 환경 무관하게 적용되는 한 가지 원칙이 있다. robots.txt 파일이 정확히 작성되어 있어도, 그 파일이 봇에게 전달되는 경로 어딘가에 차단 layer가 있으면 모두 무의미하다. 점검 순서는 다음과 같다. (1) curl로 외부에서 robots.txt URL 접근 가능 확인. (2) curl에 user-agent 헤더를 GPTBot으로 설정해 응답 차이 확인. (3) server access log에서 GPTBot 실제 도달 빈도 확인. 3단계 모두 통과해야 robots.txt 정책이 의도한 대로 작동한다.
–
06 · Measurement Loop
“제대로 설정했나”의 자가 진단 3-tool
robots.txt 정책을 결정하고 실제로 적용한 후 가장 자주 누락되는 단계가 측정이다. robots.txt 파일은 작성했지만 Cloudflare가 가로채고 있는지, AI 봇이 실제로 도달하고 있는지, user-agent string이 올바르게 매칭되는지 점검하지 않으면 작업이 끝났는지 끝나지 않았는지 알 수 없다. 측정의 3-tool 표준 set을 제시한다.
01
cite.sh robots.txt scanner
cite.sh의 robots.txt scanner는 사이트 URL을 입력하면 12개 AI 봇 user-agent에 대해 사이트의 정책 상태(ALLOW/DISALLOW/MISSING)를 일괄 점검해 보고서를 만든다. 무료, 30초. 내부 결정과 외부 노출 정책의 정합성 점검에 사용. 출력 결과는 PDF로 export 가능해 팀 내 공유에 활용된다.
02
Server access log user-agent grep
실제 봇이 사이트에 도달한 흔적을 server log에서 확인한다. nginx의 경우 grep -Ei “gptbot|claudebot|oai-searchbot|chatgpt-user|perplexitybot|applebot” access.log | wc -l 명령으로 7일 동안의 도달 빈도를 측정한다. 정상 운영 사이트의 임계는 GPTBot 50~200회/주, ChatGPT-User 10~50회/주, OAI-SearchBot 20~80회/주다. 이 빈도가 0이면 어느 layer에선가 차단되고 있는 신호다. Cloudflare를 사용하는 경우 Cloudflare dashboard → Analytics → Traffic > User-Agents 영역에서 같은 데이터를 GUI로 확인할 수 있다.
03
Merkle robots.txt syntax validator
Merkle robots.txt tester로 robots.txt 파일 자체의 문법을 검증한다. user-agent 별 Allow/Disallow가 올바른 block 안에 있는지, 빈 줄로 정확히 구분되어 있는지, wildcard pattern에 오류가 없는지 확인한다. 한국 SaaS의 robots.txt 측정에서 자주 보이는 syntax 에러는 세 가지다. (1) `User-agent: *` 다음에 별도 봇 정책 없이 그대로 끝나는 경우. (2) Disallow와 Allow의 path 패턴 충돌. (3) 빈 줄 누락으로 두 user-agent block이 한 block으로 merge되는 경우.
–
–
3-tool를 모두 통과한 사이트의 robots.txt 정책 작성 표준 example. Profile B (학습 DISALLOW · 검색 + 사용자 ALLOW) 기준이다.
–
–
주의해야 할 한 가지가 있다. robots.txt 정책 변경의 효과는 즉시가 아니라 24시간~7일 후에 측정할 수 있다. AI 검색 봇은 robots.txt 파일 cache를 갖고 있어 변경 즉시 새 정책을 따르지 않는다. OpenAI 공식 가이드는 “robots.txt 변경과 OpenAI 시스템 반영 사이에 약 24시간 lag”이라고 명시한다. 측정 → 정정 → 재측정 loop의 한 cycle은 보통 1주가 정상이다. 변경 즉시 측정해 결과가 안 보인다고 추가 변경을 거듭하면 정책이 꼬인다. 한 번 변경 후 7일을 기다린 후 측정 결과를 평가하는 인내가 필요하다.
측정 loop를 일회성이 아닌 지속 운영하려면 자동화가 필요하다. nginx 환경의 일일 봇 도달 리포트 스크립트는 다음과 같다. cat /var/log/nginx/access.log | grep -Ei “gptbot|claudebot|oai-searchbot|chatgpt-user|perplexitybot|claude-searchbot|claude-user|applebot” | awk ‘{print $1, $4, $7, $12}’ | sort | uniq -c. 이를 cron으로 매일 자정에 실행하고 결과를 Slack webhook으로 전송하면 운영팀이 매일 아침 봇 도달 현황을 확인할 수 있다. 정상 trend가 깨지는 시점(예: 특정 봇 도달 빈도 급감)에 즉시 인지해 점검 사이클을 시작 가능.
Cloudflare를 사용하는 환경은 더 간편하다. Cloudflare dashboard → Analytics & Logs → Traffic > User-Agents에서 같은 데이터를 GUI로 확인할 수 있다. Cloudflare Pro 이상 요금제는 7일치 데이터, Business 이상은 30일치, Enterprise는 90일치를 보관한다. 추가로 “Logpush” 기능을 활성화하면 access log를 S3 또는 BigQuery로 export해 BI 도구로 분석할 수 있다. 한국 SaaS의 약 40%가 Cloudflare 사용 중이지만 Logpush를 활용하는 회사는 5% 미만이다. 활용 가능한 데이터를 사용하지 않는 패턴이다.
주간 모니터링 리포트의 표준 구조는 4-row 테이블이다. (1) 학습 봇 5종(GPTBot · ClaudeBot · CCBot · Bytespider · Meta-ExternalAgent) 도달 빈도 + 정책 일치도. (2) 검색 봇 4종(OAI-SearchBot · Claude-SearchBot · PerplexityBot · Applebot) 도달 빈도 + 차단 발생 여부. (3) 사용자 트리거 봇 3종 도달 빈도 + 사용자 답변 누락 가능성 추정. (4) 종합 점수: 8/8 통과 시 OK, 6~7/8 시 점검 필요, 5/8 이하 시 즉시 정정. 4GRIT은 이 리포트 템플릿을 PeekAI 사용 고객에게 자동 생성한다.
–
07 · Synthesis
robots.txt + IndexNow + sitemap = 색인 trinity
robots.txt는 단독으로 작동하는 채널이 아니다. IndexNow + sitemap.xml + robots.txt 3개가 한 set으로 작동해야 AI 검색 봇이 사이트를 효율적으로 인덱싱할 수 있다. robots.txt는 봇의 접근 정책, sitemap.xml은 인덱싱할 URL 목록, IndexNow는 신규/변경 콘텐츠의 push 신호. 셋 중 하나가 비어 있으면 다른 둘의 효과가 절반으로 떨어진다.
한국 SaaS의 robots.txt 정책 정비 후 즉시 이어져야 하는 작업이 두 가지 있다. (1) sitemap.xml 정합성 점검(모든 공개 URL 포함, 24시간 내 변경 page는 lastmod 갱신). (2) IndexNow 활성화로 신규 콘텐츠 push 자동화. Cluster · 02 IndexNow + Bing Webmaster 가이드에 IndexNow 4단계 setup이 있고, sitemap.xml은 거의 모든 CMS가 자동 생성한다.
이 글을 한 줄로 요약한다. robots.txt는 12개 봇에 대해 3번의 결정을 내리는 파일이고, 가장 흔한 실패는 Cloudflare WAF 레이어 충돌이다. 진단은 cite.sh + server log + Merkle 3-tool로 30분 안에 끝난다. 결과는 1주일 후 측정 가능하고, 일단 정리되면 분기 1회 점검으로 유지된다.
다음 단계의 측정은 robots.txt 진단을 자동화한다. 4GRIT의 PeekAI는 사이트 URL을 입력받아 robots.txt + Cloudflare WAF + sitemap + IndexNow 4-layer 정합성을 30초에 점검하고, 12개 봇의 실제 도달 여부까지 확인한다. 무료 진단 가능.
3-set의 역할 분담을 한 줄씩으로 정의하면 다음과 같다. robots.txt = “어느 봇이 들어올 수 있는가”, sitemap.xml = “어떤 페이지가 존재하는가”, IndexNow = “새 콘텐츠가 발생했다”. 봇이 들어와도 sitemap이 없으면 어디부터 인덱싱할지 모르고, sitemap이 있어도 IndexNow가 없으면 신규 콘텐츠 발견까지 평균 14일이 걸린다. 3개가 모두 갖춰진 사이트에서만 AI 봇의 인덱싱이 24시간 cycle로 운영된다.
실측 비교를 보자. 4GRIT 표본 중 3-set 모두 갖춘 회사 7개의 OAI-SearchBot 도달 빈도가 평균 34회/주, robots.txt만 있는 회사 18개 평균 11회/주, robots.txt + sitemap 갖춘 회사 8개 평균 19회/주, robots.txt + IndexNow 갖춘 회사 5개 평균 23회/주. 3-set 갖춘 회사가 robots.txt 단독 회사 대비 3.1배의 봇 도달을 보였다. 이 트래픽 차이가 AI 검색 답변에서의 인용 빈도 차이로 직결된다.
–
NEXT STEP
robots.txt 진단 + Cloudflare WAF 충돌 자동 점검
사이트 URL만 입력하면 12개 AI 봇 도달 가능 여부 + Cloudflare 레이어 충돌 + sitemap 정합성 + IndexNow 활성화 — 30초 진단. 무료 3회/월.
–
–
–
