llms.txt란? 만드는 방법과 AI 크롤러가 실제로 읽는지 확인한 결과

llms.txt 파일은 표준이 아니라 제안이며, 언어 모델과 AI 에이전트를 위한 사이트 설명과 가장 중요한 주소의 목록입니다. AI 에이전트는 사용자를 대신해 작업을 수행하는 프로그램으로, 예를 들어 문서에서 정보를 찾습니다. Google은 자사 검색이 이런 파일을 쓰지 않는다고 씁니다. rogala.pro에는 2026년 10월 8일부터 llms.txt가 있고, 모든 페이지의 마크다운 버전도 따로 있으며, 서버 로그에서 누가 이를 가져가는지 확인합니다. 배포 후 열흘 동안 llms.txt를 요청한 알려진 AI 크롤러는 없었습니다. 같은 기간에 페이지의 마크다운 버전을 가져간 것은 ClaudeBot, OAI-SearchBot, Applebot이라고 밝히는 크롤러였습니다.

llms.txt 파일이란 무엇입니까?

llms.txt는 사이트의 루트 디렉터리에 두는 텍스트 파일로, 몇 줄로 사이트를 설명하고 가장 중요한 페이지의 주소를 알려 줍니다. 간단한 텍스트 형식인 마크다운으로 쓰며, 줄 맨 앞의 #은 제목이 되고 링크는 [제목](주소) 형태입니다. 제레미 하워드(Jeremy Howard)가 2024년 9월 3일에 제안했습니다(llmstxt.org). 목적은 AI 에이전트가 메뉴와 HTML 코드를 거치지 않고 사이트가 무엇으로 이루어져 있는지 빨리 이해하게 하는 것이었습니다. 2026년 8월에 저자는 사이트들이 2년 동안 이 파일을 쓰면서 배운 것을 바탕으로 두 번째 버전을 공개했습니다. 여전히 채택된 표준이 아니라 의견을 받는 열린 제안이라고 부릅니다.

llms.txt는 아무것도 막지 않고 모델 학습을 결정하지도 않습니다. robots.txt 파일은 AI 크롤러에게 접근 규칙을 전달하지만, 이를 따르는 크롤러에게만 작동합니다. 접근은 서버, 방화벽, CDN 설정, 즉 중개 서버 네트워크에서도 제한합니다. 이를 어떻게 확인하는지는 SEO 진단 글에서 설명했습니다.

llms.txt는 페이지의 마크다운 버전과 무엇이 다릅니까?

llms.txt와 페이지의 마크다운 버전은 서로 다른 것인데, llmstxt.org의 제안은 둘 다 설명합니다. llms.txt는 사이트 전체 또는 일부를 위한 하나의 파일로, 짧은 설명이 붙은 가장 중요한 주소의 목록입니다. 마크다운 버전은 메뉴, 스크립트, HTML 코드 없이 간단한 형식으로 쓴 한 페이지의 콘텐츠입니다. llms.txt의 링크는 이런 버전으로 이어져야 하지만, 둘 중 하나는 다른 하나 없이도 작동합니다(llmstxt.org).

크롤러가 마크다운 버전에 도달하는 방법은 세 가지이고, llmstxt.org의 제안은 그중 두 가지를 설명합니다.

• 고정된 주소로. 제안은 페이지 주소 뒤에 .md를 붙인 마크다운 버전, 예를 들어 page.html.md를 권하고, 파일 이름이 없는 주소에는 index.md를 권합니다.
• 태그나 헤더로. 페이지 코드의 <link rel="alternate" type="text/markdown"> 태그가 마크다운 버전을 가리킵니다. <link rel="describedby"> 태그는 그 페이지를 설명하는 llms.txt 파일을 가리킵니다. 제안의 두 번째 버전은 같은 것을 HTTP Link 헤더, 즉 서버의 응답에서도 허용합니다(llmstxt.org).
• 콘텐츠 협상으로. 프로그램이 Accept: text/markdown 헤더를 보내 마크다운을 직접 요청하면, 서버가 일반 주소에서 HTML 대신 마크다운을 돌려줍니다. llmstxt.org의 제안은 이 방법을 설명하지 않습니다. 아래에서 측정을 설명하는 Cloudflare의 기능이 예를 들어 이렇게 작동합니다.

rogala.pro에서는 세 방법이 모두 작동하고, llms.txt는 마크다운 버전으로 이어지는 별도의 파일입니다. 모든 페이지에는 같은 콘텐츠의 마크다운 버전이 자기 주소 뒤에 index.md를 붙인 주소에 있습니다. 페이지 코드에서는 rel="alternate" 태그가 이 버전을, rel="describedby" 태그가 llms.txt를 가리킵니다. Accept: text/markdown 헤더에는 서버가 일반 주소에서 마크다운을 돌려줍니다. 로그에서는 이 둘이 별개임이 보입니다. AI 크롤러는 마크다운 버전을 가져갔지만 llms.txt를 요청한 알려진 AI 크롤러는 없었습니다. 2026년 7월에 제 포트폴리오의 도메인 10개를 확인했을 때 마크다운 버전이 있는 곳은 한 곳도 찾지 못했습니다.

llms.txt 파일은 어떻게 생겼습니까?

형식은 단순합니다. 제목, 짧은 설명, 제목 아래에 묶인 링크 목록입니다. 필수 요소는 사이트 이름이 들어간 제목 하나뿐입니다. 제안은 요소의 순서를 이렇게 설명합니다(llmstxt.org).

1. 사이트나 프로젝트 이름의 1단계 제목. 마크다운으로 # 이름입니다.
2. 인용 블록, 즉 >로 시작하는 줄의 짧은 설명.
3. 제목 없는 맥락 문단, 선택 사항.
4. 2단계 제목(## 섹션)의 섹션들. 각 섹션에는 - [제목](주소): 설명 형태의 링크 목록.
5. 관행적으로 “Optional”이라는 섹션에 덜 중요한 자료의 링크를 둡니다. 첫 버전에서는 파일 전체가 에이전트가 한 번에 처리하는 텍스트 분량에 들어가지 않을 때 에이전트가 이 섹션을 건너뛸 수 있었습니다. 두 번째 버전은 이 섹션을 관행으로만 남깁니다(llmstxt.org).

서비스 회사를 위한 가장 단순한 파일은 다섯 줄입니다.

• # 예시 회계 사무소
• > 크라쿠프의 회계 사무소: 2010년부터 1인 기업과 법인의 회계를 맡고 있습니다.
• ## 서비스
• - [가격표](https://example.com/cennik/): 1인 기업과 법인의 회계 가격
• - [연락처](https://example.com/kontakt/): 사무소의 주소, 전화, 근무 시간

rogala.pro에서는 파일의 이름과 설명이 영어이고, 마크다운 버전에 대한 문단 하나와 섹션 세 개가 있습니다. “Profile” 섹션은 저에 대한 페이지로, “Blog”는 폴란드어와 영어 블로그로, “Optional”은 블로그의 나머지 25개 언어 버전으로 이어집니다. 모든 링크는 페이지의 마크다운 버전으로 이어지고, 콜론 뒤의 설명은 페이지의 설명 태그(meta description)와 같은 텍스트입니다. 2026년 10월에 파일은 약 40 KB였습니다.

문서가 있는 일부 사이트는 모든 콘텐츠를 한 파일에 담은 llms-full.txt 파일도 공개합니다. llmstxt.org의 제안은 이런 파일을 설명하지 않습니다. Anthropic 문서의 llms-full.txt 파일은 약 45 MB이고, Cloudflare 문서의 파일은 약 69 MB입니다(2026년 10월 18일 확인).

Allegro, Empik, Morele의 llms.txt 파일은 어떻게 생겼습니까?

폴란드의 대형 쇼핑몰에는 이미 llms.txt가 있지만, 제가 확인한 세 파일 중 제안을 온전히 따르는 것은 없었습니다. Allegro, Empik, Morele의 파일은 2026년 10월 18일에 받았습니다. llmstxt.org의 형식과 이 글에서 설명하는 점검 기준으로 평가합니다. 세 파일 모두 마크다운 버전이 아니라 일반 HTML 페이지로 이어집니다.

Allegro는 에이전트에게 실용적인 정보를 가장 많이 제공하지만, 구조 일부를 제목 대신 굵은 글씨로 썼습니다. 파일에는 갱신 날짜, 선호하는 브랜드 이름, 본사 주소, 문의 양식이 있습니다. 검색, 필터, 다음 결과 페이지의 주소 패턴도 설명해서, 에이전트가 제품 목록의 주소를 직접 만들 수 있습니다. 모델에 주는 안내는 가격과 재고를 제품 페이지에서 확인해야 한다고 말하고, 종료된 프로그램의 이름을 적어 둡니다. “주요 카테고리”와 “기타 페이지와 서비스” 같은 그룹은 ## 제목 대신 굵은 글씨입니다. 그래서 형식대로 파일을 읽는 프로그램은 서비스 목록을 필터링 섹션에 붙이게 됩니다. 링크 설명은 콜론이 아니라 하이픈 뒤에 있고, 13개 주요 카테고리에는 설명이 없습니다.

Allegro 파일에 있는 페이지는 제 스크립트에 403 코드를 돌려주었지만, 파일 자체는 문제없이 받아졌습니다. 스크립트는 User-Agent 헤더에 자기 이름과 제 사이트 주소를 넣었고, 파일의 처음 주소 여덟 개를 확인했습니다. AI 크롤러가 같은 응답을 받는지는 모르는데, 그것은 Allegro의 로그만 보여 주기 때문입니다. 모든 파일에서 해 볼 만한 점검의 예입니다. llms.txt의 주소를 파일을 받은 같은 프로그램이 받을 수 있는지입니다.

Empik은 형식을 가장 충실히 따르지만, 브랜드 설명이 광고 문구처럼 읽힙니다. 파일에는 1단계 제목, 인용 블록의 설명, ## 섹션, 콜론 뒤에 설명이 붙은 링크 목록이 있습니다. 모델에 주는 안내는 구체적입니다. 가격과 재고는 제품 페이지에서 가져와야 하고, 반품 조건은 판매자마다 다르다고 합니다. 브랜드 설명에는 “선도적인”과 “사랑받는 브랜드”라는 표현이 있는데, 이 글에서는 사실을 쓰라고 권합니다. 모델이 설명을 페이지와 비교할 수 있기 때문입니다. 파일에는 갱신 날짜가 없습니다. 제목과 일부 레이블은 나머지가 폴란드어인데도 영어입니다. 파일의 주소 35개 중 34개는 코드 200으로, 하나는 리디렉션으로 응답했습니다.

Morele는 카테고리와 가이드 목록이 좋지만, 파일이 형식을 따르지 않아서 프로그램이 읽지 못할 수 있습니다. 파일은 보이지 않는 BOM 문자로 시작하고, 첫 줄 #Morele.net에는 # 뒤의 공백이 없습니다. 마크다운에서 이런 줄은 제목이 아니고, 이름이 들어간 제목은 유일한 필수 요소입니다. 파일에는 인용 블록의 설명이 없고 1단계 제목이 여러 개 있습니다. 주소 116개 중 마크다운 링크인 것은 없고, 대부분 “이름 - 주소”라는 일반 텍스트로 적혀 있습니다. 카테고리 옆에는 태그와 “자주 검색되는 검색어”, 즉 모델을 위한 키워드 목록과 광고 문구가 있습니다. 주소 116개 중 113개는 코드 200으로 응답했고, 3개는 새 주소의 기사로 리디렉션되었습니다.

세 사이트 모두 에이전트에게 페이지의 마크다운 버전을 주지 않으므로, 파일을 읽은 에이전트는 어차피 전체 HTML 페이지를 가져옵니다. Empik과 Morele는 Accept: text/markdown 헤더에 HTML을 돌려주고, .md가 붙은 주소는 404 코드를 돌려줍니다. Allegro는 같은 시도에 403 코드로 응답했습니다. 어느 사이트에도 rel="describedby" 태그나 rel="alternate" type="text/markdown" 태그가 없습니다.

Google은 llms.txt를 사용합니까?

아니요. Google은 검색에 나타나기 위해 AI용 텍스트 파일이나 마크다운 버전을 만들 필요가 없다고 씁니다. AI 기능 최적화에 대한 Google의 가이드는 검색이 그런 파일을 건너뛴다고 덧붙입니다. 따라서 가시성에 도움이 되지도 해가 되지도 않습니다(Google Search Central, 2026년 7월 10일 갱신). 2025년 7월 Search Central Live 컨퍼런스에 대한 Search Engine Land의 보도에 따르면 개리 일리스(Gary Illyes)는 Google이 llms.txt를 지원하지 않는다고 말했습니다(Search Engine Land).

존 뮬러(John Mueller)는 llms.txt를 검색엔진이 쓰지 않는 키워드 메타 태그에 비유했습니다. 2025년 4월에 Reddit에서 이 파일은 사이트가 무엇에 관한 것인지에 대한 소유자의 선언이라고 썼습니다. AI 시스템은 대신 페이지 자체를 확인할 수 있습니다(Search Engine Journal). 서버 로그를 보면 AI 서비스가 파일이 있는지 확인조차 하지 않는다는 점도 덧붙였습니다.

Chrome과 Google 검색은 별개의 문제입니다. Chrome의 페이지 평가 도구인 Lighthouse에는 “Agentic Browsing”이라는 실험적 카테고리가 있고, 도메인 루트에 llms.txt가 있는지도 확인합니다(Chrome for Developers). 이 점검은 브라우저의 에이전트를 위한 사이트의 준비 상태를 평가합니다. 그 결과는 Google 검색의 순위에 대해 아무것도 말해 주지 않습니다.

AI 크롤러는 llms.txt를 읽습니까?

확인할 수 있는 데이터로는 AI 검색엔진의 크롤러는 llms.txt를 드물게 가져가고, GPTBot과 개발자용 어시스턴트인 Claude Code가 더 자주 가져갑니다. 제가 원문 게시물로 확인한 세 연구는 서로 다른 것을 측정합니다. llms.txt 파일 자체, Accept 헤더로 보낸 마크다운 버전, 별도의 마크다운 주소입니다.

• Ahrefs는 2026년 5월에 자사 트래픽 분석의 도메인 137,210개를 분석했습니다. 그중 28%에 llms.txt가 있었고, 이 파일 중 97%에는 5월에 요청이 한 건도 오지 않았습니다. 파일에 도달한 요청의 96%는 크롤러가 보냈습니다. OAI-SearchBot과 PerplexityBot 같은 AI 검색엔진의 크롤러는 합쳐서 233건, 전체의 1.1%를 보냈습니다. 이름이 있는 AI 도구 중에서는 GPTBot이 요청을 가장 많이 보냈고 두 번째는 Claude Code였습니다. GPTBot은 모델용 데이터를 수집하는 OpenAI의 크롤러이고, Claude Code는 Anthropic의 개발자용 어시스턴트입니다(Ahrefs, 2026년 6월 15일).
• Suganthan Mohanadasan은 Cloudflare에서 에이전트에게 마크다운을 주는 기능을 켠 뒤 44일 동안 Accept: text/markdown 헤더가 붙은 요청을 기록했습니다. 저자는 요청 1,421건이라고 하지만 그의 표를 합하면 1,373건입니다. 그중 639건은 헤드리스 브라우저가, 500건은 Anthropic의 인프라가 보냈습니다(저자에 따르면 ClaudeBot은 아님). 표에는 GPTBot도 PerplexityBot도 없습니다(Suganthan Mohanadasan, 2026년 4월 19일).
• Otterly는 14일 동안 HTML 페이지와, 푸터에 링크한 별도 주소의 마크다운 버전을 비교했습니다. HTML 페이지는 AI 크롤러 방문 137건이었고 마크다운 버전은 0건이었습니다. 어떤 AI 플랫폼도 마크다운 주소를 인용하지 않았습니다(Otterly, 2026년 4월 1일 갱신).

Ahrefs의 연구는 요청을 측정하는 것이지, 크롤러가 파일로 무엇을 했는지를 측정하는 것이 아닙니다. GPTBot이 llms.txt를 가져간다고 해서 파일이 ChatGPT의 답변을 바꾼다는 뜻은 아닙니다. Ahrefs는 자사 고객이 평균적인 사이트보다 기술에 밝고 SEO에 민감하다고도 밝힙니다. 그러므로 웹 전체에서 llms.txt가 있는 사이트의 비율은 아마 28%보다 낮을 것입니다.

배포 후 제 사이트의 로그는 무엇을 보여 주었습니까?

배포 후 열흘 동안 알려진 AI 크롤러 중 llms.txt를 요청한 곳은 없었고, 마크다운 버전은 이 파일을 묻지 않은 크롤러들이 가져갔습니다. 2026년 10월 8일에 rogala.pro에 llms.txt와 모든 페이지의 마크다운 버전을 공개했습니다(배포일 기준 주소 114개). 접속 로그는 호스팅에서 받고, 세 종류의 요청을 셉니다. llms.txt 요청, index.md 파일 요청(각 페이지의 별도 주소에 있는 마크다운 버전), 일반 페이지 주소에서의 마크다운 응답입니다.

일반 주소의 마크다운 응답은 간접적으로 알아보므로 그 수는 근사치입니다. 호스팅은 Accept 헤더를 저장하지 않으므로, 알려진 마크다운 버전의 크기와 같은 크기의 응답을 찾습니다. 콘텐츠를 바꾼 뒤에는 이전 크기를 모르기 때문에 일부 응답을 놓쳤을 수 있습니다. 크기가 우연히 일치할 수는 있지만, 바이트 단위로 센 크기에서는 가능성이 낮습니다.

제 자체 요청을 뺀 2026년 10월 8-17일의 결과입니다.

• llms.txt 요청은 5건이었고 그중 3건은 파일을 받는 것으로 끝났습니다. 한 번은 SEO 도구의 크롤러가, 두 번은 휴대전화 브라우저라고 밝힌 익명의 스캐너가 가져갔습니다. 이 파일을 요청한 알려진 AI 크롤러는 없었습니다.
• index.md 파일 요청은 ClaudeBot(123), OAI-SearchBot(35), Applebot(27)이 직접 보냈습니다. ClaudeBot은 Ahrefs 연구의 Claude Code와는 다른 프로그램으로, Anthropic의 색인용 크롤러입니다. 호스팅은 ClaudeBot의 요청 34건을 429 코드, 즉 “요청이 너무 많음”으로 거부했으므로, ClaudeBot의 요청 89건이 파일을 받는 것으로 끝났습니다.
• 일반 주소에서의 마크다운 응답은 ExaSearchBot의 요청 22건에서만 감지했고, 주로 메인 페이지였습니다. ExaSearchBot은 AI 애플리케이션을 위한 검색엔진의 크롤러입니다.
• Googlebot은 HTML 페이지를 169건 요청했고, 마크다운 응답은 감지하지 못했습니다. ChatGPT 사용자의 요청으로 페이지를 가져오는 ChatGPT-User는 HTML 페이지를 8건 요청했습니다.

로그는 크롤러가 마크다운 버전의 주소를 어떻게 알았는지는 보여 주지 않습니다. 그 기간에 그 크롤러 중 llms.txt를 요청한 곳은 없었습니다. HTML 페이지의 <link rel="alternate"> 태그가 마크다운 버전의 주소를 알려 주므로 가능한 경로이지만 유일한 경로는 아닙니다. 가져갔다고 해서 크롤러가 그 버전을 답변에 썼다는 뜻도 아니며, 그러려면 별도의 측정이 필요합니다.

제 자체 테스트는 크롤러의 트래픽과 쉽게 혼동됩니다. 10월 17일 배포를 점검할 때 제 스크립트가 Googlebot 식별자로 마크다운 파일을 가져가서, 제 IP 주소에서 “Googlebot”의 요청 115건이 나왔습니다. 제 주소를 빼지 않았다면 로그에는 Googlebot이 마크다운을 가져간 것으로 보였을 텐데, 진짜 Googlebot이 마크다운을 가져가는 것은 감지하지 못했습니다.

llms.txt는 언제 만들 만합니까?

llms.txt가 가장 의미 있는 곳은 개발자용 어시스턴트가 사이트를 읽는 곳, 즉 문서, API, 개발자 도구입니다. API는 프로그램이 데이터를 주고받는 인터페이스입니다. Ahrefs 연구에서 Claude Code는 파일 요청 수로 GPTBot 다음의 두 번째 AI 도구였습니다. 코드 편집기의 어시스턴트가 문서 주소를 받으면 내비게이션보다 링크 목록에서 올바른 페이지를 더 빨리 찾을 수 있습니다.

쇼핑몰이나 서비스 회사에서 llms.txt는 AI 트래픽을 만드는 방법이 아니라 저렴한 부가 작업입니다. 저는 파일이 트래픽이나 인용을 늘린다는 근거를 알지 못합니다. 만들기 전에 AI 크롤러가 애초에 사이트를 가져올 수 있는지 확인하십시오. 그다음 JavaScript를 실행하지 않아도 콘텐츠가 HTML에 보이는지 확인하십시오. 두 점검은 GEO 최적화와 AI SEO 글에서 설명했습니다.

크롤러용 버전은 사람이 보는 페이지와 콘텐츠가 같아야 하고, 형식만 다를 수 있습니다. Google은 클로킹, 즉 사용자와 다른 콘텐츠를 검색엔진에 보여 주는 것을 스팸 정책에서 설명합니다(Google Search Central). 같은 정보, 가격, 조건을 담은 마크다운 버전은 같은 페이지의 다른 형식이고, 내용이나 조건이 다른 버전에는 위험이 따릅니다. rogala.pro에서 마크다운 버전을 고르는 것은 크롤러 이름이 아니라 Accept 헤더입니다. Link 헤더에서 마크다운 버전은 HTML 페이지를 표준 주소, 즉 선호하는 페이지 버전으로 가리킵니다.

llms.txt 파일은 어떻게 만듭니까?

어떤 페이지가 중요한지 안다면 파일은 직접 만들 수 있습니다.

1. 귀하의 회사나 제품에 대해 묻는 사람이 알아야 할 페이지를 고르십시오. 서비스, 가격표, 문서, 연락처, 가장 중요한 글입니다. 사이트맵 전체를 붙여 넣지 마십시오.
2. 이름이 들어간 제목과, 인용 블록에 한두 문장의 설명을 쓰십시오. 설명은 광고 문구가 아니라 회사에 대한 사실을 적어야 합니다. 모델이 페이지와 비교할 수 있기 때문입니다.
3. 링크를 2단계 제목 아래에 묶고, 링크마다 페이지에 무엇이 있는지 한 문장을 적으십시오.
4. 파일을 도메인 루트에 /llms.txt로 UTF-8 인코딩으로 저장하십시오. 이 주소가 코드 200, 즉 정상 응답과 일반 텍스트를 돌려주는지, 일부 시스템이 모르는 주소마다 보여 주는 HTML 페이지가 아닌지 확인하십시오. 귀하의 시스템이 루트에 파일을 올릴 수 없다면 쇼핑몰이나 호스팅 제공사에 문의하십시오.
5. 파일의 정보가 콘텐츠와 일치하도록 페이지와 같은 원본에서 파일을 생성하십시오. rogala.pro에서 llms.txt는 사이트를 빌드할 때마다 HTML과 같은 데이터로 만들어집니다.

llms.txt 생성기로 충분합니까?

생성기는 파일의 초안을 만들어 주지만, 페이지의 선택과 설명은 직접 확인해야 합니다. DataForSEO에 따르면 폴란드에서 “llms txt generator”는 월 약 70번, 미국에서 “llms.txt generator”는 월 약 480번 검색됩니다(12개월 중앙값). 생성기가 주소를 사이트맵이나 크롤러의 사이트 스캔에서 가져온다면, 귀하에게 어떤 페이지가 중요한지는 모릅니다. 공개하기 전에 다섯 가지를 확인하십시오.

• 파일에 보여 주고 싶은 페이지만 있는지, 로그인, 장바구니, 공사 중인 페이지는 없는지
• 모든 주소가 작동하고 코드 200을 돌려주는지
• 설명이 페이지의 현재 콘텐츠, 가격, 서비스와 일치하는지
• 페이지에 없는 정보가 파일에 없는지
• 페이지가 바뀐 뒤 파일이 어떻게 갱신되는지

크롤러가 llms.txt를 가져가는지 어떻게 확인합니까?

답은 AI 가시성 도구가 아니라 서버 로그에 있습니다. 호스팅 패널에서 원본 접속 로그를 받고 /llms.txt 주소와 마크다운 버전의 주소를 검색하십시오. 로그는 요청마다 IP 주소, 날짜, 응답 코드, 크기, 요청을 보낸 프로그램의 이름, 즉 User-Agent를 기록합니다.

크롤러 이름은 위조할 수 있으므로 중요한 요청은 IP 주소로 확인합니다. OpenAI는 자사 크롤러의 주소 목록을 공개하고, 제 로그에서 OAI-SearchBot의 주소 블록 4개 중 3개가 그 목록에 있었습니다. 같은 이유로 제 자체 테스트를 빼는데, 제 점검 스크립트가 Googlebot이라고 밝혔기 때문입니다.

로그는 호스팅이 오래 보관하지 않으므로 정기적으로 받으십시오. 제 호스팅은 로그를 14일 보관하므로, 한 달치 측정을 얻으려고 며칠에 한 번 아카이브를 받습니다. AI 답변에 브랜드가 나타나는 정도는 따로 측정합니다. 그 측정은 브랜드의 AI 가시성 글에서 설명했습니다.

llms.txt에 대해 자주 묻는 질문

어디서 시작하면 됩니까?

크롤러의 접근부터 시작하고 llms.txt는 마지막에 더하십시오. /robots.txt를 열어 AI 크롤러에 대한 규칙을 확인하십시오. 그다음 최근 며칠의 로그를 받아 어떤 크롤러가 어떤 응답 코드로 사이트를 방문하는지 보십시오. 문서나 개발자용 제품이 있다면 llms.txt와 마크다운 버전을 바로 추가하십시오. 쇼핑몰이나 서비스 회사에서 llms.txt는 이 두 점검 뒤의 부가 작업입니다. 함께 하고 싶다면 문의로 연락 주십시오.