llms.txt & AI 크롤러 가이드 — robots.txt·sitemap·canonical과 무엇이 다른가

Prompt Architect 편집팀 · 2026-06-19 · 10분

TL;DR — GPTBot·ClaudeBot·PerplexityBot 같은 AI 크롤러를 어떻게 제어하고, 요즘 화제인 llms.txt는 정말 효과가 있을까? robots.txt·sitemap·canonical과의 차이를 정리하고, 과신하지 않으면서도 실무에 바로 쓸 수 있는 권장안을 제시한다.

ChatGPT, Claude, Perplexity, Google AI Overviews가 일상이 되면서 "우리 사이트는 AI에게 어떻게 보일까?"라는 질문이 부쩍 늘었다. 그러면서 함께 떠오른 키워드가 AI 크롤러 제어와 llms.txt다. "robots.txt에 GPTBot을 막아야 하나?", "llms.txt를 만들면 ChatGPT가 우리 글을 더 잘 인용하나?" 같은 질문이 대표적이다.

결론부터 말하면, AI 크롤러 제어는 실제로 동작하는 표준 메커니즘(robots.txt)이지만, llms.txt는 아직 비표준 제안이고 효과가 불확실한 실험적 수단이다. 이 둘을 같은 무게로 다루면 잘못된 우선순위로 시간을 낭비하게 된다. 이 글에서는 AI 크롤러의 실체, robots.txt를 통한 제어, llms.txt의 정체와 한계, 그리고 robots.txt·sitemap.xml·canonical·llms.txt가 각각 무엇을 위한 도구인지 명확히 구분한다.

전체 그림(검색·답변 엔진 최적화의 큰 흐름)이 궁금하다면 먼저 SEO·AEO·GEO 완벽 정리를 읽고 오면 이 글의 위치가 더 또렷해진다.

AI 크롤러란 무엇인가 — 학습용 vs 검색용, 그리고 실제 User-Agent

AI 크롤러를 하나로 뭉뚱그리면 제어를 잘못하게 된다. 목적에 따라 크게 세 갈래로 나뉜다.

학습(training)용: 모델 학습 데이터를 수집한다. 대표적으로 OpenAI의 GPTBot, Google의 Google-Extended, Apple의 Applebot-Extended가 여기에 해당한다.
검색/답변(retrieval)용: 사용자가 질문할 때 실시간 혹은 색인 기반으로 웹을 참조해 답변에 인용한다. OpenAI의 OAI-SearchBot(ChatGPT 검색), PerplexityBot 등이 대표적이다.
사용자 동작(user action)용: 사용자가 특정 URL을 붙여넣거나 요청했을 때 그 페이지를 가져온다. OpenAI의 ChatGPT-User, Anthropic의 Claude-User가 여기에 속한다.

실제로 존재하는 주요 User-Agent를 정리하면 다음과 같다.

운영사	User-Agent	주 용도
OpenAI	`GPTBot`	모델 학습 데이터 수집
OpenAI	`OAI-SearchBot`	ChatGPT 검색 색인/참조
OpenAI	`ChatGPT-User`	사용자 요청 시 페이지 가져오기
Anthropic	`ClaudeBot`	크롤링(학습 등)
Anthropic	`Claude-User`	사용자 요청 시 페이지 가져오기
Perplexity	`PerplexityBot`	검색/답변 참조
Google	`Google-Extended`	Gemini/Vertex 학습 옵트아웃 토큰
Apple	`Applebot-Extended`	학습 옵트아웃 토큰

여기서 중요한 점 하나. Google-Extended와 Applebot-Extended는 "별도의 봇"이 아니라 robots.txt에서 학습 사용 여부만 제어하는 토큰이다. 즉 Google-Extended를 막아도 일반 Googlebot의 검색 색인에는 영향을 주지 않는다. 학습 옵트아웃과 검색 노출은 분리되어 있다는 뜻인데, 이 구분이 뒤에서 다룰 트레이드오프의 핵심이다.

robots.txt로 AI 크롤러 제어하기

AI 크롤러 제어의 표준이자 1차 수단은 robots.txt다. 새로운 기술이 아니라 우리가 이미 알고 있는 그 robots.txt다. 대부분의 주요 AI 크롤러는 robots.txt의 User-agent 규칙을 존중한다고 공표하고 있다.

예를 들어, 학습용 크롤러는 막되 검색/답변용 참조는 허용하고 싶다면 다음과 같이 작성한다.

# 모델 학습용 수집은 차단
User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

# 검색/답변 참조는 허용 (명시적 Allow)
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 일반 검색엔진은 그대로
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

반대로 "AI에 우리 콘텐츠가 학습되든 인용되든 상관없다, 노출이 더 중요하다"는 사이트라면 굳이 막을 필요가 없다. 콘텐츠 노출과 인용이 곧 브랜드 가시성으로 이어진다고 보는 미디어·블로그가 여기에 해당한다.

몇 가지 주의점이 있다.

robots.txt는 "신사협정"이다. 규칙을 따르는 것은 각 크롤러의 정책에 달려 있다. 악의적 스크래퍼나 robots.txt를 무시하는 봇까지 막아주지는 않는다. 그건 WAF·방화벽·rate limit의 영역이다.
User-Agent 문자열은 바뀔 수 있다. 운영사가 봇을 추가/개명하므로, 막거나 허용한 목록은 분기마다 한 번씩 점검하는 편이 좋다.
차단은 "이미 학습된 것"을 되돌리지 않는다. robots.txt는 "앞으로의 수집"에 대한 정책일 뿐이다.

llms.txt란 무엇인가 — 제안 배경과 형식, 그리고 한계

llms.txt는 2024년 **Jeremy Howard(Answer.AI)**가 제안한 마크다운 기반 규약이다(llmstxt.org). 아이디어는 단순하다. 사람을 위한 HTML과 별개로, LLM이 사이트를 빠르게 이해하도록 핵심 정보·중요 링크를 마크다운으로 정리한 파일을 사이트 루트(/llms.txt)에 두자는 것이다. HTML 페이지는 내비게이션·광고·스크립트 등 노이즈가 많으니, 깔끔한 요약본을 따로 제공하자는 발상이다.

형식은 정해진 골격이 있다. 최상단에 사이트 이름(H1), 한 줄 요약(블록인용), 그 아래 섹션별 링크 목록을 둔다.

# Prompt Architect

> AI 프롬프트 분석과 AI 검색 최적화(AEO/GEO)를 다루는 기술 블로그.

## 핵심 가이드

- [SEO·AEO·GEO 완벽 정리](https://example.com/blog/seo-aeo-geo-ai-search-optimization-guide): 검색·답변·생성 엔진 최적화 개요
- [llms.txt & AI 크롤러 가이드](https://example.com/blog/llms-txt-ai-crawler-guide): AI 크롤러 제어와 llms.txt
- [AI 검색 성과 측정](https://example.com/blog/ai-search-measurement-search-console-ga4): GA4·Search Console로 AI 유입 보기

## 소개

- [About](https://example.com/about): 편집 방침과 방법론

여기서 반드시 짚어야 할 한계가 있다.

공식 웹표준이 아니다. W3C나 검색엔진이 정한 표준이 아니라 한 개인/조직의 제안이며, 채택 여부는 전적으로 각 엔진의 선택이다.
주요 검색·AI 엔진이 실제로 사용한다는 증거가 불확실하다. "llms.txt를 두면 ChatGPT가 더 잘 인용한다"는 식의 보장된 효과는 현재로선 입증되지 않았다. 일부 개발자 도구·문서 사이트가 실험적으로 채택하는 단계다.
이중 관리 비용이 생긴다. HTML과 llms.txt 내용이 어긋나면 오히려 혼란을 준다. 자동 생성 파이프라인이 없으면 금세 낡은 정보가 된다.

정리하면, llms.txt는 **"하면 손해는 적지만, 이득이 보장되지도 않는 보조·실험적 수단"**이다. 핵심 작업을 끝낸 사이트가 "여유가 되면 추가로 시도해 보는" 옵션 정도로 보는 게 현실적이다.

robots.txt vs sitemap.xml vs canonical vs llms.txt

네 가지를 자주 헷갈리지만, 사실 각자 완전히 다른 문제를 푼다. 한 표로 정리한다.

파일/요소	목적	누구에게	표준 지위	AI에 대한 효과
`robots.txt`	접근(크롤링) 허용/차단	모든 크롤러(AI 포함)	사실상 표준, 널리 존중됨	AI 크롤러 차단/허용에 직접 작동
`sitemap.xml`	존재하는 URL 목록 안내	검색 크롤러	표준(sitemaps.org)	색인 발견을 도울 뿐, 인용 보장 아님
`canonical` (`rel="canonical"`)	중복 URL 중 대표본 지정	검색엔진	표준(권고)	중복 정리로 색인 품질↑(간접)
`llms.txt`	LLM용 사이트 요약 제공	LLM	비표준 제안	효과 불확실(실험적)

핵심 차이를 한 문장씩 요약하면 이렇다.

**robots.txt는 "들어와도 되는가"**를 다룬다. 가장 강력하고 확실한 통제 수단이다.
**sitemap.xml은 "어떤 페이지가 있는가"**를 알려준다. 차단이 아니라 발견을 돕는 안내서다.
**canonical은 "같은 내용 중 어느 URL이 진짜인가"**를 지정한다. 중복 콘텐츠로 인한 색인 분산을 막는다.
**llms.txt는 "LLM아, 우리 사이트 요약은 이거야"**라고 제안하는 실험적 보조 파일이다.

Google은 분명히 안내한다. AI 기능(AI Overviews 등)에 노출되기 위해 특수 마크업이나 별도 AI 전용 파일이 필요하지 않다. 기반은 어디까지나 표준 SEO + 구조화 데이터다. 즉 "AI 시대니까 새 파일을 만들어야 한다"는 전제 자체가 대체로 과장이다.

학습 옵트아웃 vs 검색 노출 — 트레이드오프

많은 운영자가 "AI가 내 콘텐츠를 가져가는 게 싫다"며 GPTBot·Google-Extended를 막는다. 충분히 이해되는 선택이지만, 막기 전에 따져야 할 트레이드오프가 있다.

옵트아웃의 대가는 "AI 답변 안에서의 가시성 포기"일 수 있다. 특히 검색/답변용 크롤러(OAI-SearchBot, PerplexityBot 등)까지 막으면, 사용자가 AI에게 질문했을 때 당신의 사이트가 인용원으로 등장할 기회 자체가 줄어든다. AI 검색이 트래픽 유입의 새 통로가 되어가는 흐름을 생각하면 가볍게 볼 일이 아니다.

반대로 인용이 곧 트래픽은 아니다라는 점도 직시해야 한다. Pew Research(2025)는 검색 결과에 AI 요약이 있을 때 사용자가 출처 링크를 덜 클릭하는 경향을 보고했다. 즉 AI 답변에 인용되더라도 그 인용이 방문으로 이어지는 비율은 기대보다 낮을 수 있다. "인용 = 트래픽"이라는 등식은 깨졌다.

그래서 현실적인 판단 기준은 이렇게 나뉜다.

브랜드·콘텐츠 노출이 목표인 미디어/블로그 → 학습은 막더라도 검색/답변 참조는 열어두는 쪽이 보통 유리하다.
독점 데이터·유료 콘텐츠가 자산인 사이트 → 학습 옵트아웃(GPTBot·Google-Extended 차단)을 적극 고려한다.
민감/사내 문서 → 그냥 인증 뒤로 보내거나 noindex 처리하는 게 맞다. robots.txt는 "공개되어 있되 수집만 막는" 수단이지, 보안 수단이 아니다.

학습 옵트아웃이 검색 색인을 끄지 않는다는 점(Google-Extended ≠ Googlebot)을 다시 떠올리면, 이 둘은 별개의 레버라는 게 분명해진다.

실무 권장안 — 무엇을 먼저 할까

우선순위를 흐리지 않는 게 핵심이다. 효과가 확실한 것부터, 불확실한 것은 나중에.

표준 SEO와 구조화 데이터를 먼저 갖춘다. Article 등 기본 구조화 데이터, 명확한 제목 구조, 의미적으로 깔끔한 본문. Google이 말하는 "AI 노출의 기반"이 바로 이것이다. AI 전용 파일보다 100배 중요하다.
robots.txt로 AI 크롤러 정책을 "의도적으로" 정한다. 막을지 열지는 사업 목표에 따라 결정하되, 학습용/검색용/사용자동작용을 구분해 명시한다. 기본값(아무것도 안 적음)도 하나의 선택임을 기억한다.
sitemap.xml과 canonical을 정리한다. 새 글이 빠르게 발견되도록 sitemap을 최신으로 유지하고, 중복 URL은 canonical로 대표본을 지정한다.
측정 체계를 붙인다. robots.txt를 어떻게 설정했든, 실제 AI 유입이 어떻게 변하는지 봐야 의사결정이 가능하다. GA4·Search Console로 AI 엔진 유입을 분리해 보는 방법은 AI 검색 성과 측정에서 자세히 다룬다.
(선택) llms.txt를 실험한다. 위 1~4가 끝났고 여유가 있다면, 자동 생성 파이프라인을 붙여 llms.txt를 만들어 본다. 단 "효과가 보장된다"고 기대하지 말고, 낡지 않게 유지할 수 있을 때만.

이 순서를 지키면, 불확실한 트렌드(llms.txt)에 시간을 먼저 쏟고 확실한 기본기(표준 SEO·robots.txt)를 빠뜨리는 흔한 실수를 피할 수 있다.

흔한 오해

"llms.txt를 만들면 ChatGPT가 우리 글을 더 인용한다." → 보장되지 않는다. 비표준 제안이고 주요 엔진의 실제 사용 증거가 불확실하다.
"AI 시대엔 robots.txt가 무용지물이다." → 반대다. AI 크롤러 제어의 가장 확실한 1차 수단이 robots.txt다.
"robots.txt로 막으면 보안이 된다." → 아니다. robots.txt는 "수집하지 말아 달라"는 요청일 뿐, 접근 자체를 차단하지 못한다. 비공개 콘텐츠는 인증/접근제어로 보호해야 한다.
"Google-Extended를 막으면 검색에서 사라진다." → 아니다. Google-Extended는 학습 옵트아웃 토큰이며, 일반 검색 색인(Googlebot)과 분리되어 있다.
"AI에 노출되려면 특수 마크업/AI 전용 파일이 필요하다." → Google은 필요 없다고 안내한다. 기반은 표준 SEO + 구조화 데이터다.
"AI가 인용해 주면 트래픽이 따라온다." → 꼭 그렇지 않다. AI 요약이 있을 때 출처 클릭이 줄어든다는 보고(Pew, 2025)가 있다. 인용과 방문은 별개로 측정해야 한다.

결론

AI 크롤러 시대의 핵심은 "새로운 파일을 만드는 것"이 아니라 "기존 표준을 의도적으로 운용하는 것"이다. robots.txt로 AI 크롤러를 학습용/검색용/사용자동작용으로 구분해 제어하고, sitemap·canonical로 색인 품질을 다지고, 표준 SEO와 구조화 데이터로 의미를 명확히 하는 것이 확실한 길이다. llms.txt는 흥미로운 실험이지만 효과가 입증되지 않은 보조 수단일 뿐, 우선순위를 앞당길 이유는 없다. 확실한 것부터 차근차근 하고, 실제 유입은 측정으로 확인하자.

AI에게 물어볼 때 (프롬프트 팁)

AI 크롤러 정책을 직접 설계하거나 검토할 때, 막연히 "robots.txt 짜줘"라고 하면 일반론만 돌아온다. 사업 목표·구분 기준·검증 방법을 함께 주면 훨씬 쓸 만한 답이 나온다.

역할: 너는 기술 SEO 컨설턴트다.
맥락: 우리는 AI 프롬프트 관련 콘텐츠 블로그(AdSense 수익 모델)다.
목표: AI 학습용 수집은 막되, AI 검색/답변에는 인용되어 노출되고 싶다.
요청:
1) GPTBot/Google-Extended/Applebot-Extended(학습)와
   OAI-SearchBot/PerplexityBot/ChatGPT-User(검색·사용자)를 구분한 robots.txt를 작성해줘.
2) 각 규칙이 "학습 옵트아웃"인지 "검색 노출"인지 한 줄 주석으로 표시해줘.
3) 이 설정이 일반 Googlebot 검색 색인에 주는 영향도 명시해줘.

llms.txt 도입을 검토 중이다. 다음을 균형 있게 정리해줘.
- llms.txt의 현재 표준 지위와, 주요 AI 엔진의 실제 사용 여부(확실/불확실 구분)
- 도입 시 얻을 수 있는 것과 이중 관리 비용
- robots.txt·sitemap.xml·canonical과 역할이 어떻게 다른지 표로
- "지금 당장 할 일"과 "여유 되면 할 일"로 우선순위 분리
근거가 불확실한 주장은 "불확실"이라고 솔직히 표시해줘.

이런 프롬프트가 왜 더 좋은 답을 끌어내는지 점수로 확인하고 싶다면 Prompt Architect 프롬프트 분석기에서 직접 검증해 보자.