AI 크롤러 차단용 robots.txt를 붙여 넣다가 기존 규칙을 풀 수 있습니다

AI 요약

robots.txt 검사기를 만들며 여러 사이트의 설정을 살펴본 작성자는 AI 크롤러 차단 예시를 복사해 붙일 때 반복되는 두 가지 실수를 발견했습니다. 파일은 오류 없이 읽히지만, 작성자가 의도하지 않은 기존 규칙이 조용히 사라질 수 있습니다.

봇 전용 그룹이 와일드카드 규칙을 가립니다

기존 파일에 User-agent: *와 함께 /wp-admin/, /checkout/을 차단하는 규칙이 있다고 가정해 보겠습니다. 여기에 User-agent: GPTBot과 빈 Disallow:를 추가하면 GPTBot에는 이름이 더 구체적인 그룹이 적용됩니다. RFC 9309에 따르면 크롤러는 토큰에 가장 구체적으로 일치하는 그룹을 따르며, 일치하는 이름 지정 그룹이 없을 때만 * 그룹으로 돌아갑니다. 따라서 GPTBot에는 /wp-admin/과 /checkout/ 차단 규칙이 적용되지 않습니다. 봇을 명시하는 것만으로 와일드카드 그룹의 규칙을 이어받지 않기 때문입니다.

허용하려는 봇까지 이름 지정 그룹에 넣는 예시라면 같은 문제가 생깁니다. 해당 봇에도 기존 * 그룹의 제한을 유지하려면 새 그룹에 필요한 Disallow 규칙을 다시 적어야 합니다. 작성자는 현재 운영 중인 파일을 읽고, 바꾸려는 줄만 직접 수정하라고 권합니다.

같은 봇 그룹은 RFC 규칙에 따라 결합합니다

작성자는 같은 사용자 에이전트를 대상으로 그룹을 중복 작성하면 파서마다 처리 방식이 달라질 수 있다고 설명합니다. 댓글에서 이를 바로잡은 독자는 RFC 9309 2.2.1절에 따라 같은 사용자 에이전트 토큰에 일치하는 그룹의 규칙을 결합해야 한다고 지적합니다. 따라서 규격을 따르는 파서에서는 단순히 첫 번째 그룹이나 오래된 그룹만 선택하는 것이 아닙니다. 경로가 여러 규칙과 일치하면 2.2.2절의 가장 구체적인 경로 규칙을 적용합니다. 예를 들어 두 ExampleBot 그룹에 각각 Disallow: /private/와 Allow: /private/help/가 있으면 규칙을 합쳐 /private/data는 차단하고 /private/help/는 허용합니다. 특정 크롤러가 다르게 동작한다면 규격과 구현 차이를 구분해 기록할 필요가 있습니다.

검사기와 생성기

작성자는 무료 도구 두 개도 소개합니다. AI Crawler Checker는 실시간 robots.txt를 읽어 각 AI 크롤러가 접근할 수 있는지, 어떤 규칙이 판정을 결정했는지 보여줍니다. AI Robots.txt Generator는 기존 파일에서 AI 그룹만 다시 작성하고 나머지 바이트는 그대로 둡니다. 변경한 내용과 유지한 내용도 나눠 보여줍니다.

댓글에서 작성자는 생성기를 만들며 흔히 떠올리는 User-agent: GPTBot과 Allow: / 조합도 위험하다는 점을 확인했다고 답합니다. 이 설정은 GPTBot에 /wp-admin/ 같은 경로도 열 수 있습니다. 대신 기존 와일드카드 그룹의 Disallow 규칙을 새 그룹에 복사하고, 모든 경로를 허용하는 Disallow: /는 넣지 않는 방식을 설명합니다. 검사기도 봇별로 적용 그룹을 표시하며, 이름 지정 그룹이 와일드카드 규칙을 가릴 때 적용되지 않는 규칙을 함께 나열하도록 개선했다고 밝혔습니다.

댓글에서는 크롤링 허용 여부를 정하기 전에 목적을 구분하자는 지적도 나왔습니다. 모델 학습 차단, 검색·답변을 위한 검색 및 실시간 가져오기, 이미 학습된 데이터의 삭제는 서로 다른 문제라서 하나의 Disallow 규칙으로 모두 해결할 수 없습니다. Google-Extended는 학습뿐 아니라 grounding에도 관여하고, AI Overviews에는 별도 토큰이 없어 Google Search에서 빠져야 하는 상황이 생길 수 있다는 설명도 나왔습니다. robots.txt를 바꾸기 전에는 어떤 크롤러와 사용 목적을 막으려는지 먼저 확인해야 합니다.

Indie Hackers 반응

• @nortise — Google은 Googlebot이 사용하는 파서를 오픈소스로 공개합니다. robotstxt 저장소의 robots_main 바이너리에 robots.txt 파일, 사용자 에이전트, URL을 넘기면 허용 또는 차단 판정을 받을 수 있습니다. Googlebot과 Google-Extended에서 검사기 판정을 비교하고, 중복 그룹이나 * 그룹이 가려지는 경우도 시험할 수 있습니다.
• @rcaiptv — 좋은 발견입니다. 많은 사람이 robots.txt 예시를 복사하면서 기존 규칙을 덮어쓰는지 확인하지 않습니다. 새 규칙을 추가하면서 기존 규칙을 잃지 않는 안전한 방법을 찾았나요?
• @m_montazeri — 중복 그룹에 관해 한 가지 바로잡겠습니다. RFC 9309 2.2.1절은 같은 사용자 에이전트 토큰에 일치하는 그룹의 규칙을 결합하도록 합니다. 규격을 따르는 파서에서는 첫 번째 그룹이나 오래된 그룹이 단독으로 이기는 방식이 아닙니다. 2.2.2절은 가장 구체적인 경로 규칙을 적용합니다. 두 ExampleBot 그룹에 Disallow: /private/와 Allow: /private/help/가 각각 있으면 합쳐서 /private/data는 차단하고 /private/help/는 허용해야 합니다. 검사기에 좋은 회귀 테스트가 될 수 있습니다. 특정 크롤러가 다르게 동작한다면 규격 결과와 구현 차이를 구분해 보여주면 좋겠습니다.
• @AmandaBrown — 이름 지정 그룹이 와일드카드를 가리는 동작은 사람들이 매번 놓치는 부분입니다. RFC 9309에는 맞지만 직관과는 다릅니다. 대부분은 이름 지정 항목이 와일드카드 규칙에 더해진다고 생각합니다. 중복 그룹은 실제 파일에서 더 복잡합니다. 오래된 차단 규칙과 최근에 붙인 규칙이 쌓이면 봇마다 다른 결과를 얻을 수 있습니다. Allow 경로를 Disallow 맥락에서 쓰는 사이트도 고려해 보세요. 이름 지정 그룹을 추가하면서 와일드카드에 있던 허용 예외가 사라질 수 있습니다.
• @sniper8192 — 붙여 넣은 규칙 하나로 서로 다른 세 가지 목적을 막는 경우가 더 큰 문제일 수 있습니다. GPTBot은 학습 크롤러입니다. Google-Extended는 Gemini 학습을 거부하지만 AI Overviews는 막지 않습니다. Perplexity 같은 답변 엔진은 사이트를 직접 가져오지 않고 제삼자 검색 색인에서 답하기도 합니다. 그래서 포괄적인 차단은 AI 답변의 인용을 줄이면서 이미 학습된 콘텐츠에는 아무 영향도 주지 않을 수 있습니다. robots.txt를 바꾸기 전에 학습, 검색·답변, 실시간 가져오기 중 무엇을 막으려는지 정해야 합니다.
  • @Passcite — 동의합니다. 도구에서는 각 토큰을 학습용인지 답변용인지 구분합니다. 학습 데이터에서 빼 달라는 요청과 답변에서 인용해 달라는 요청은 서로 반대라서 Disallow 하나로 표현할 수 없습니다. Google-Extended는 학습과 grounding을 함께 다루며 AI Overviews 전용 토큰은 없습니다. 이미 학습된 콘텐츠에는 크롤링 규칙이 아니라 삭제 요청이 필요합니다.
• @ylynbuilds — 각 봇 토큰에 실제로 적용되는 그룹과 와일드카드 대체 적용을 보여주고, 이름 지정 그룹이 기존 * 그룹을 가리는 상황을 표시하면 배포 전에 회귀 문제를 알아보기 쉽겠습니다.
  • @Passcite — 그룹 표시 기능은 있었지만 와일드카드 규칙을 가리는지 보여주는 기능은 없었습니다. 검사기가 / 경로만 평가했기 때문입니다. 사라지는 규칙은 /wp-admin/이나 /checkout/에 있을 수 있습니다. 이름 지정 그룹이 봇을 차지하면 적용되지 않는 * 규칙도 표시하도록 수정했습니다.
• @jessie_geo — 크롤러를 막으면 단호한 조치처럼 느껴지지만, 인용에 도움이 되는 크롤러까지 막았다는 사실을 뒤늦게 알 수 있습니다. 저는 robots.txt 변경을 변경 기록처럼 다룹니다. 한 번에 허용 또는 차단 하나만 바꾸고, 일주일 뒤 ChatGPT와 Perplexity에 같은 질문을 해 결과가 달라졌는지 확인합니다.
• @brianainews — 이름 지정 그룹이 와일드카드 규칙을 가리는 점은 robots.txt 변경을 불안하게 만드는 조용한 실패입니다. 배포 전에 봇마다 실제 적용 규칙을 보여주면 유용하겠습니다.
  • @Passcite — 두 기능을 모두 추가했습니다. 검사기는 각 봇에 적용된 그룹과 그 봇에서 효력을 잃은 * 그룹 규칙을 보여줍니다. 생성기는 배포 전 변경 내용을 확인하는 기능입니다.

원문: Indie Hackers / 번역·요약: Trawling