AI 감사에서 llms.txt가 없다는 경고는 무엇을 뜻할까
llms.txt가 없다는 사실을 AI 검색 문제로 판단하기 전에 감사가 확인한 정확한 URL, HTTP 응답과 검사 목적을 살펴보세요.
AI 감사에서 내 웹사이트에 빨간 경고 카드가 떴다고 가정해 보세요. “llms.txt가 없습니다.” 경고를 없애려고 파일을 추가하기 전에 해당 결과를 열어 어떤 URL과 검사에서 나온 것인지 확인하세요. 선택 사항인 색인이 없는 경우, HTML 오류 페이지가 성공 응답으로 반환된 경우, 서버 장애가 발생한 경우에는 각각 다른 판단이 필요합니다. 이런 관찰만으로 AI 답변이 내 사이트를 인용할지는 알 수 없습니다.
검사가 무엇을 측정하는지 확인하기
도구 이름과 버전, 날짜, 경고의 정확한 문구, 검사한 URL을 저장하세요. 해당 검사의 문서를 읽어보세요. 출처를 확인한 2026년 11월 9일 당시 Lighthouse의 llms.txt 문서는 서버 오류는 문제로 표시하고, 파일이 없어 404가 반환되면 ‘해당 없음’으로 처리한다고 설명했습니다. 파일은 선택 사항이라고 명시했습니다. 다른 도구는 단순히 파일을 찾았는지만 보고할 수도 있습니다. 빨간 표시가 그 요청이 실제로 반환한 내용을 바꾸지는 않습니다.
Google의 AI 개요와 AI 모드에 대해서는 Google이 새로운 AI 텍스트 파일이 필요하지 않다고 설명합니다. 이는 Google 검색에 표시될 자격에 관한 답입니다. 다른 모든 어시스턴트가 색인을 어떻게 처리하는지까지 알려주지는 않습니다. 무엇을 고칠지 정할 때 감사 기준과 플랫폼 요건을 구분하세요.
결과의 근거가 된 응답 읽기
감사가 검사한 정확한 URL을 여세요. Chrome에서 요청을 살펴보려면 네트워크 패널을 열고 URL을 새로고침한 뒤 해당 요청을 선택하세요. 요청 메서드, 리디렉션 후 최종 URL, 상태, 헤더와 Response 본문을 확인하세요. HEAD 요청이나 Content-Type 헤더만으로는 GET이 무엇을 반환했는지 알 수 없습니다.
가상의 문서 사이트 docs.example을 생각해 보겠습니다. /llms.txt는 404를 반환하지만 /docs/llms.txt는 Markdown 색인을 반환합니다. 현재 llms.txt 제안은 루트 또는 하위 경로에 파일을 두고 그 경로 아래의 페이지를 다루는 것을 허용합니다. 루트만 검사하는 감사는 문서 색인을 확인하지 않은 것입니다. 이는 검사 범위의 차이이며, 파일을 루트에도 복제해야 한다는 증거는 아닙니다. 위치를 바꾸기 전에 파일을 사용할 클라이언트가 어디에서 찾는지 확인하세요.
이번에는 /llms.txt가 HTTP 200을 반환하지만 본문은 사이트 디자인을 적용한 ‘페이지를 찾을 수 없음’ HTML 화면이라고 가정해 보겠습니다. 상태만 확인하는 검사는 이를 성공으로 판단할 수 있습니다. 실제 결과를 기록하세요. URL이 반환한 것은 의도한 Markdown 색인이 아니라 HTML 오류 페이지입니다. 라우팅 담당자에게 해당 응답의 조사를 요청하세요. 대신 홈페이지, 로그인 페이지 또는 접근 확인 화면이 반환되면 그 결과를 기록하세요. text/html 헤더만으로는 이들을 구별할 수 없습니다.
요청이 500을 반환하면 서버 오류로 기록하세요. 이것만으로 파일이 없다고 판단할 수는 없습니다. 읽을 수 있는 Markdown이 반환되더라도 내용과 링크를 함께 확인하세요. 제안에서는 프로젝트나 사이트 제목을 요구하지만, 제목만으로 색인이 현재 사이트를 설명하는지 또는 유용한 페이지로 연결되는지 알 수 없습니다.
누가 사용할 파일인지 정하기
계속 관리하는 문서 색인은 사람이나 에이전트가 관련 자료를 빠르게 찾도록 도울 수 있습니다. OpenAI도 개발자 문서용 색인을 공개합니다. 이는 공개된 색인이 존재한다는 것을 보여줍니다. 다른 웹사이트에도 이를 요구한다거나 ChatGPT Search가 그 사이트들의 파일을 가져간다는 증거는 아닙니다.
파일을 사용할 구체적인 클라이언트나 문서 작업 흐름이 있다면, 그것이 찾아야 할 페이지를 정하세요. 요약을 정확하게 유지하고 링크를 열어 대상 페이지가 최신 상태이며 읽을 수 있는지 확인하세요. 페이지가 이동할 때는 색인도 업데이트 과정에 포함하세요. 작은 사이트에도 이런 용도가 있을 수 있습니다.
목적이 단지 Google의 AI 기능이 이미 유용한 페이지를 찾도록 하는 것이라면, 파일이 없다는 경고만으로 새 요건이 생기지는 않습니다. 콘텐츠와 기술 기본 가이드에 따라 해당 페이지의 실제 접근 및 콘텐츠 문제를 확인하세요. 색인을 추가해도 링크된 페이지에 접근할 수 있다거나 그 주장이 명확하다는 사실이 입증되지는 않습니다.
관찰할 수 있는 증거로 수정 확인하기
가상의 사이트에서 /docs/llms.txt 안에 있던, 삭제된 설정 가이드로 향하는 링크를 수정했다고 가정해 보겠습니다. 색인을 다시 열고 수정한 링크를 따라가 예상한 가이드가 로드되는지 확인하세요. 같은 도구 버전으로 원래 감사를 다시 실행하고 시간을 기록한 뒤, 새 실행의 결과를 보고 있는지 확인하세요. 여전히 /llms.txt만 검사한다면 문서 링크를 고쳤더라도 결과는 그대로일 수 있습니다.
완료 기록을 정확히 남기세요. “문서 색인은 현재 설정 가이드로 연결됩니다. 루트 파일 검사는 여전히 해당 검사 자체의 결과를 보고합니다.” 이후 로그에 남은 요청은 그 기록이 포착한 사실만 보여주며, 모델이 내용을 사용했다는 증거는 아닙니다. 인용을 확인하려면 실제 답변을 관찰해야 합니다. 이 수정이 인용, 방문 또는 전환에 영향을 주었는지는 각 결과에 대한 증거가 생길 때까지 검증되지 않은 상태입니다.