구조와 기술 요소

llms.txt란 AI 에이전트용 사이트 안내서, 작성과 게시 순서

llms.txt는 사이트 소개와 주요 페이지 링크를 마크다운으로 정리해 루트에 두는 파일입니다. Google 검색 순위와는 관계가 없습니다. 위치 정하기부터 작성, 게시 후 확인까지 순서대로 설명합니다.

llms.txt란 AI 에이전트용 사이트 안내서, 작성과 게시 순서

llms.txt는 사이트 소개와 주요 페이지 링크를 정리해 도메인 루트에 두는 파일입니다. 형식은 마크다운(기호로 제목과 목록을 표시하는 텍스트 형식)입니다. 꼭 있어야 하는 요소는 사이트 이름을 적은 제목 한 줄뿐입니다. 여기에 요약, 설명, 링크 목록을 순서대로 붙여 완성합니다.

Google은 검색에 이 파일이 필요하지 않다고 설명합니다. 검색 노출이나 순위에도 영향을 주지 않는다고 밝힙니다. 따라서 검색 순위나 AI 인용을 올리는 장치로 보지 않습니다. AI 에이전트와 개발 도구에 사이트를 안내하는 파일로 보고 작성합니다.

llms.txt는 누가, 언제 읽는 파일인가요?

llms.txt는 2024년 9월 3일 제러미 하워드가 제안한 형식입니다. 제안 문서의 목적은 LLM(대규모 언어 모델)이 읽기 쉬운 형태로 사이트 정보를 제공하는 것입니다. 에이전트가 복잡한 HTML을 일일이 해석하지 않고, 정리된 입구 하나로 사이트를 파악하게 하려는 것입니다.

제안자는 이 파일이 학습보다 추론에 주로 쓰일 것으로 예상했다고 적습니다. 추론은 모델이 질문을 받고 답을 만드는 시점을 말합니다.

다른 파일과의 관계도 문서에 정리되어 있습니다. 제안 문서는 llms.txt가 robots.txt가 허용한 콘텐츠에 맥락을 더해 보완한다고 설명합니다. 사이트맵은 llms.txt를 대신할 수 없다고 봅니다. 사이트맵에는 LLM이 읽기 좋은 사본 주소가 빠져 있는 경우가 많기 때문입니다.

이 파일을 다루는 곳은 다음과 같습니다.

  • AI 회사 개발자 문서: 제안 문서는 OpenAI, Anthropic, Gemini 같은 AI 연구소가 자체 개발자 문서용 llms.txt를 공개한다고 소개합니다.
  • Chrome Lighthouse: Chrome 문서는 Agentic Browsing 범주의 Discoverability 영역에 llms.txt 항목을 둡니다. 도메인 루트에 기계가 읽을 수 있는 요약이 있는지 확인하는 항목입니다. 이 범주는 제안 단계 표준에 기반한 실험 기능입니다. 문서는 시험하려면 Chrome 150 이상이 필요하다고 안내합니다.
  • Google 검색: 생성형 AI 검색 최적화 안내서는 Google 검색에서는 llms.txt 같은 AI용 텍스트 파일 만들기를 무시해도 된다고 설명합니다. 이런 파일을 만들고 관리하는 것은 괜찮으며, 해가 되지도 도움이 되지도 않는다고 덧붙입니다. Google은 2026년 6월 15일 업데이트 기록에서도 이 안내를 명확히 했습니다.

실무에서는 기대 효과를 검색 성과로 잡지 않는 방법을 권합니다. 에이전트와 개발 도구가 회사 정보를 정확한 이름과 경로로 찾도록 돕는 것을 목표로 정합니다.

1·2단계: 파일 위치와 담을 페이지는 어떻게 정하나요?

1단계: 파일 위치와 관리 책임 정하기

제안 문서는 파일을 사이트 루트뿐 아니라 하위 경로에도 둘 수 있다고 설명합니다. 이때 파일은 그 경로 아래 페이지를 다룹니다. 여러 파일이 겹치면 에이전트는 가장 구체적인 파일을 써야 한다고 정합니다.

예를 들어 가상의 ○○소프트라는 기업이라면 회사 전체 안내는 루트에 둡니다. 개발자 문서는 문서 경로 아래에 별도 파일로 둘 수 있습니다. 그러면 문서 경로의 페이지에는 더 구체적인 하위 파일이 적용됩니다.

파일을 둘 경로, 담당 부서, 다시 고칠 계기(사이트 개편·신제품·가격 변경)를 한 줄씩 적었다면 다음 단계로 넘어갑니다.

2단계: 담을 페이지 고르기

llms.txt는 사이트의 모든 주소를 나열하는 파일이 아닙니다. 질문에 답할 때 먼저 봐야 할 페이지를 골라 짧게 묶는 작업입니다.

구분해당 페이지 예넣기 전에 확인할 것
본문 링크 목록회사 소개, 제품·서비스 안내, 가격과 이용 정책, 고객 지원, 문의 방법공개 페이지이며 회사명·제품명 표기가 사이트 전체와 같은지
Optional 목록(건너뛰어도 되는 보조 링크 모음)보도자료 목록, 블로그 글 목록, 과거 버전 안내빠져도 회사를 설명하는 데 지장이 없는지
제외로그인이 필요한 화면, robots.txt로 막은 경로, 종료된 이벤트, 내부 시험 페이지목록에 남은 주소가 하나도 없는지

제안 문서는 llms.txt를 robots.txt가 허용한 콘텐츠의 보완으로 설명합니다. 실무에서는 차단 경로를 함께 올리면 두 파일의 의도가 어긋나 보일 수 있다고 판단합니다. 그래서 robots.txt로 막은 경로는 목록에서 빼는 방법을 권합니다.

표의 세 구분에 페이지가 모두 배치되고, 본문 목록의 페이지가 로그인 없이 열리면 작성으로 넘어갑니다.

3단계: 파일 안은 어떤 순서로 채우나요?

제안 문서가 정한 순서는 제목, 요약, 세부 설명, 링크 목록, Optional 목록입니다. 아래 표는 가상의 ○○소프트를 예로 든 따라 쓸 문안입니다.

순서요소따라 쓸 문안 예확인할 점
1H1 제목(샵 기호 하나로 시작하는 가장 큰 제목)# ○○소프트한 줄이며 사이트 표기와 같은 이름
2인용 블록 요약(줄 앞에 꺾쇠 기호)> ○○소프트는 중소 제조사용 재고관리 소프트웨어를 만드는 회사입니다.무엇을 하는 회사인지 한두 문장, 홍보 형용사 없음
3세부 설명(제목 없는 문단·목록)제품명은 ○○재고로 표기합니다. 이전 이름은 ○○스톡입니다.제목 기호 없이 표기 규칙과 주의점만 담음
4H2 링크 목록(샵 기호 둘)첫 줄에 ## 제품, 다음 줄부터 링크 항목모든 항목에 링크와 한 줄 설명이 있음
5Optional 목록첫 줄에 ## Optional, 다음 줄부터 보조 링크 항목이 절을 빼고 읽어도 핵심 정보가 남음

링크 항목 한 줄은 다음 네 부분으로 씁니다.

  1. 줄 맨 앞에 하이픈과 빈칸을 둡니다.
  2. 대괄호 안에 페이지 이름을 적습니다. 예를 들면 ○○재고 기능 안내입니다.
  3. 닫는 대괄호 바로 뒤에 빈칸 없이 괄호를 열고, 그 안에 페이지 주소를 적습니다.
  4. 필요하면 쌍점과 설명을 붙입니다. 예를 들면 입출고와 재고 실사 기능 설명입니다.

제안 문서에서 필수 요소는 H1 제목 하나입니다. 링크 항목에서는 이름과 주소로 된 링크가 필수이고, 쌍점 뒤 설명은 선택입니다. 다만 요약과 링크 목록이 없으면 안내서 역할을 하기 어렵습니다.

제안 문서는 Optional이라는 이름의 H2 절을 관례상 보조 정보에 쓴다고 설명합니다. 에이전트가 짧은 맥락이 필요할 때 건너뛸 수 있는 링크를 모으는 자리입니다.

실제 공개 파일은 형식이 조금씩 다릅니다. 확인일 기준 Anthropic 개발자 문서의 llms.txt는 요약을 인용 블록이 아닌 일반 문장으로 씁니다. 링크는 H2 절 아래 H3 제목으로 다시 묶었습니다. 설명은 쌍점 대신 하이픈 뒤에 붙이며, 설명이 없는 항목도 많습니다.

실무에서는 페이지 이름이 비슷한 회사 사이트라면 항목마다 설명을 붙여 구분하는 방법을 권합니다.

4단계: 페이지별 마크다운 사본은 언제 준비하나요?

이 단계는 선택입니다. 제안 문서는 에이전트가 볼 만한 페이지에 깔끔한 마크다운 사본을 두도록 제안합니다.

사본 주소는 원래 주소 끝에 .md를 붙이거나, 확장자를 .md로 바꿔 만듭니다. 파일 이름이 없는 주소는 index.html.md나 index.md를 씁니다.

페이지와 사본을 잇는 표시도 문서에 있습니다. rel="alternate"와 type="text/markdown"은 그 페이지의 마크다운 사본을 가리킵니다. rel="describedby"는 그 페이지를 다루는 llms.txt를 가리킵니다. 이 표시는 HTML의 link 요소나 HTTP 응답의 Link 헤더 가운데 하나로 넣습니다.

사본이 원본과 어긋나면 오히려 혼선을 만듭니다. 실무에서는 원본 페이지와 같은 원천에서 사본을 자동으로 만드는 방법을 권합니다. 부담이 크다면 사본 없이 원본 HTML 주소로 링크 목록을 채워도 됩니다.

사본 주소를 열어 본문이 원본과 같은지 보고, 링크 목록이 사본이나 원본 중 한 규칙으로 통일되어 있으면 게시로 넘어갑니다.

5·6단계: 게시한 뒤 무엇을 확인하고 기록하나요?

5단계: 게시와 응답 확인

  1. 주소창에 도메인 뒤에 /llms.txt를 붙여 입력하고, 로그인 없이 파일 내용이 보이는지 확인합니다.
  2. 브라우저 개발자 도구의 네트워크 탭에서 상태 코드가 200이고 다른 주소로 넘어가지 않는지 확인합니다.
  3. 한글이 깨져 보이면 파일을 UTF-8로 다시 저장하고, 서버가 같은 문자 인코딩으로 보내는지 확인합니다.
  4. 링크 목록의 주소를 하나씩 열어 오류 페이지나 로그인 화면이 없는지 확인합니다.
  5. Chrome 150 이상에서 Lighthouse를 실행하고, Agentic Browsing 범주의 llms.txt 항목 결과를 봅니다. 실험 기능이므로 결과는 참고용으로 기록합니다.

6단계: 관리 기록 남기기

llms.txt는 한 번 쓰고 끝나는 파일이 아닙니다. 페이지 주소나 제품명이 바뀌면 파일 속 링크와 표기가 먼저 낡습니다. 아래 양식의 기록 예는 자리 표시이므로 실제 값으로 바꿔 씁니다.

기록 항목기록 예
파일 위치루트, 하위 경로가 있으면 그 경로
게시일·담당YYYY-MM-DD, 담당 부서
마지막 링크 점검YYYY-MM-DD, 링크 n개 중 오류 n개
Lighthouse 결과Agentic Browsing 범주 llms.txt 항목의 통과 여부와 확인일
다시 고칠 계기사이트 개편, 신제품 출시, 가격·정책 변경

성과를 기록할 때는 Google 검색 지표 변화를 llms.txt 효과로 해석하지 않습니다. Google이 이 파일은 검색 노출과 순위에 영향을 주지 않는다고 밝혔기 때문입니다.

5단계 항목을 모두 통과하고 기록표의 다섯 칸이 채워졌다면 게시 작업을 마무리합니다.

정리

llms.txt는 추론 시점의 AI 에이전트를 위한 사이트 안내서이며, Google 검색 순위와는 관계가 없습니다. 형식은 H1 제목, 요약, 설명, 링크 목록, Optional 목록의 순서를 따릅니다.

  1. 파일을 둘 경로와 담당 부서, 다시 고칠 계기를 한 줄씩 정합니다.
  2. 공개 페이지를 본문 목록, Optional 목록, 제외 대상으로 구분하고 robots.txt로 막은 경로는 뺍니다.
  3. H1 제목부터 Optional 목록까지 순서대로 쓰고, 링크마다 한 줄 설명을 붙입니다.
  4. 게시 후 200 응답, 한글 표시, 링크 오류, Lighthouse 결과를 확인합니다.
  5. 관리 기록표를 만들고, 사이트 개편이나 제품명 변경 때마다 파일을 함께 고칩니다.

이 글은 일반적인 정보 제공을 위한 것이며, 글 속 수치와 사례는 인용한 출처 기준입니다.

최근 글

읽은 내용을 내 사이트에 대어 보십시오

20문항 자가 진단으로 여섯 영역 가운데 어디부터 손볼지 확인할 수 있습니다.