llms.txt는 2024년 9월 Jeremy Howard(Answer.AI/fast.ai)가 제안한 파일 규약으로, 웹사이트 루트에 마크다운 형식의 콘텐츠 인덱스를 배치해 LLM 크롤러가 사이트 구조를 파악하는 데 활용하도록 설계됐다. W3C·IETF 공식 표준이 아니며, Google·OpenAI·Anthropic 어느 쪽도 이 파일을 AI 답변 인용 신호로 사용한다고 공식 확인하지 않았다. 그럼에도 "GEO 필수 요소"로 회자되는 이유는 RAG 파이프라인이 HTML 파싱 노이즈 없이 구조화된 마크다운을 처리하는 방식과 실질적으로 맞닿아 있기 때문이다. 이 글은 효과 여부를 단정하는 대신 현재 확인 가능한 기술 근거만으로 판단 기준을 제시한다.
llms.txt의 기술 구조: robots.txt와 무엇이 다른가
llms.txt는 크롤러 제어 파일이 아니라 콘텐츠 파일이다. robots.txt는 크롤러가 페이지를 가져오기 전 HTTP 수준에서 처리되는 프로토콜이지만, llms.txt는 루트에 존재하는 마크다운 파일에 불과하며 크롤러가 먼저 확인해야 한다는 표준 프로토콜이 존재하지 않는다. 공식 명세(llmstxt.org)가 정의하는 구조는 다음과 같다.
- H1 — 사이트명: 단일 제목으로 사이트 전체를 식별한다. LLM이 세션 컨텍스트를 초기화할 때 첫 번째로 읽는 신호다.
- blockquote — 사이트 요약: 100자 내외 설명. RAG 파이프라인에서 쿼리 관련성 판단 전 사전 필터 역할을 한다.
- H2 섹션 — 카테고리별 링크 목록: 각 항목은
[제목](URL): 설명형식. 크롤러가 어느 페이지를 우선 탐색할지 힌트를 제공한다. - llms-full.txt (선택): 전체 본문을 단일 파일로 연결한다. 토큰 한도 내에서 크롤러가 선택적으로 사용하며, 권장 상한은 128K 토큰 이하다.
# Citeon Tech Blog
> AI 마케팅·GEO·SEO 기술 분석을 다루는 Citeon의 엔지니어링 블로그.
> 대상 독자: 검색엔진 최적화 실무자, 프론트엔드/백엔드 엔지니어.
## GEO 가이드
- [AEO vs GEO 차이 완전 정리](https://citeon.io/blog/aeo-geo): 답변엔진최적화와 생성형엔진최적화의 신호 차이, 구현 우선순위 비교
- [Google AI Overviews 인용 메커니즘](https://citeon.io/blog/ai-overviews): 인용 후보 콘텐츠의 파싱·랭킹 파이프라인 분석
## 기술 구현
- [JSON-LD 스키마 실전 가이드](https://citeon.io/blog/jsonld): FAQPage·Article·HowTo 스키마 코드와 GSC 측정법
- [robots.txt로 LLM 크롤러 제어하기](https://citeon.io/blog/robotstxt-llm): Google-Extended·GPTBot·PerplexityBot 차단·허용 설정 예시
## Optional
- [llms-full.txt](https://citeon.io/llms-full.txt)
공식 지원 현황: 확인된 것과 추정의 경계
| 시스템 | User-Agent | llms.txt 처리 여부 | 근거 출처 |
|---|---|---|---|
| Perplexity | PerplexityBot | 지원 공식 선언 | Perplexity 공식 블로그 2024-10 |
| Anthropic Claude | ClaudeBot | 미확인 (자사 배포는 존재) | anthropic.com/llms.txt 존재, 크롤링 정책 미공개 |
| Google AI Overviews | Google-Extended | 미지원 (확인 불가) | Mueller "콘텐츠 품질 우선" 반복 강조, 신호 미확인 |
| OpenAI ChatGPT | GPTBot | 미확인 | 공식 문서 없음 |
Perplexity는 llms.txt를 사이트 인덱싱 힌트로 활용한다고 명시했다. 그러나 이것이 답변 인용 우선순위에 얼마나 반영되는지는 공개된 정량 데이터가 없다. Google AI Overviews는 전통 PageRank 파이프라인과 별개의 콘텐츠 추출 모델로 추정되며, llms.txt를 독립 신호로 처리한다는 근거가 현재 없다.
구현 시 놓치기 쉬운 기술 체크리스트
- 루트 접근 가능 여부 확인 —
https://yourdomain.com/llms.txt로 직접 HTTP GET이 가능해야 한다. CDN 캐시 규칙이나 WAF가 루트 텍스트 파일을 차단하는 사례가 있으므로, 배포 후 반드시 curl로 응답 코드를 확인한다. - Content-Type 헤더 — 서버가
text/plain; charset=utf-8을 반환해야 한다.text/html로 반환되면 마크다운이 브라우저에서 렌더링되고, 일부 크롤러가 파싱을 건너뛸 수 있다. - robots.txt 충돌 점검 — llms.txt를 배포하면서 동시에 해당 크롤러를
Disallow: /로 전면 차단하면 파일 자체에 접근이 불가능하다. Google-Extended를 허용할 경우/llms.txt와/llms-full.txt경로가 차단 규칙에 포함되지 않았는지 확인한다. - 링크 동기화 — 페이지 삭제·URL 변경 시 llms.txt도 동기화한다. 죽은 링크가 포함된 파일은 크롤러 신뢰도를 낮출 수 있다(추정, 정량 근거 없음).
흔한 오해: "llms.txt를 배포하면 AI 답변에 인용된다"
가장 흔한 오해는 llms.txt가 인용 트리거라는 가정이다. llms.txt가 실제로 할 수 있는 것은 크롤러에게 "어떤 페이지가 중요하고 어떤 카테고리에 속하는지"를 구조화된 형태로 전달하는 것뿐이다. 인용 여부는 여전히 쿼리 관련성, 콘텐츠의 E-E-A-T 신호, 문장 수준의 사실 밀도가 결정한다.
올바른 처리법: llms.txt는 콘텐츠 접근성(discoverability)을 높이는 보조 수단으로 위치시킬 것. 효과를 측정하려면 배포 전후로 Perplexity에서 브랜드·핵심 주제 쿼리를 검색해 인용 빈도를 수동 추적하거나, 서버 로그에서 PerplexityBot·ClaudeBot의 /llms.txt 접근 빈도를 확인하는 방법이 현재 가능한 가장 직접적인 측정 수단이다.
llms.txt와 sitemap.xml은 무엇이 다른가?
sitemap.xml은 크롤러에게 URL 목록과 메타데이터(마지막 수정일, 우선순위)를 전달하는 XML 프로토콜로, Google·Bing이 공식 지원하며 색인 속도에 직접 영향을 준다. llms.txt는 Markdown 기반이며, LLM이 페이지를 방문하기 전 사이트 맥락을 이해하도록 돕는 콘텐츠 파일이다. 두 파일은 역할이 다르므로 중복이 아니며 병행 배포가 권장된다. 단, sitemap.xml이 색인 신호로 확립된 것과 달리 llms.txt는 표준 지원 증거가 Perplexity 외에는 제한적이다.
Google Search Console에서 llms.txt 효과를 측정할 수 있는가?
직접 측정은 불가능하다. GSC는 전통 Googlebot 기반 색인·클릭 데이터만 제공하며, Google AI Overviews의 인용 데이터는 별도 노출되지 않는다. 간접 지표로는 ①서버 액세스 로그의 Google-Extended User-Agent 크롤 빈도 변화, ②AI Overviews 인용 여부 수동 추적(쿼리별 화면 캡처), ③Perplexity에서 인용 빈도를 활용할 수 있다. GSC의 "AI 개요" 필터(2024년 말부터 일부 계정 순차 출시)로 AI Overviews 노출 자체는 확인 가능하나, llms.txt와의 인과관계는 현재 검증 수단이 없다.
참고 자료
이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.