Robots.txt 파서

robots.txt를 붙여넣고 크롤러의 방식으로 읽으세요. RFC 9309(2022년 표준화된 Robots 배제 프로토콜) 기준: 사용자 에이전트 그룹, Allow/Disallow 규칙, 사이트맵, 알 수 없는 지시자가 모두 펼쳐지고, 고전적 실수(빈 disallow 줄, 알 수 없는 지시자, 과대 파일)에 대한 감사가 따릅니다. 매처가 진짜 질문에 답합니다. 사용자 에이전트와 경로를 붙여넣으면 결정한 정확한 규칙과 함께 허용/거부 판정을 얻습니다 — 최장 일치, 와일드카드 *, 끝 앵커 $, 그룹 병합이 표준이 규정한 대로. 모든 것이 브라우저에서 실행됩니다.
아직 파싱된 것이 없습니다. 위에 robots.txt를 붙여넣고 파일 파싱을 누르거나 샘플을 불러오세요.
매처는 위 상자에 현재 있는 텍스트로 작동합니다(먼저 파싱을 누를 필요 없음). 사용자 에이전트는 RFC 9309가 정의하는 방식으로 일치합니다. 파일의 User-agent 값은 여기 입력한 것의 대소문자 무관 부분 문자열이어야 합니다 — 그래서 ExampleBot/1.0을 입력하면 ExampleBot으로 선언된 그룹과 일치합니다. 전체 URL이 경로로 받아들여집니다.
사용자 에이전트 (실제 UA 문자열도 됩니다) 경로 또는 전체 URL
아직 판정이 없습니다. 허용 검사를 누르세요.
파일을 가져오는 방법:열기https://your-domain.example/robots.txt브라우저에서 모두 선택, 복사하고 여기에 붙여넣으세요 — 또는curl -s https://your-domain.example/robots.txt터미널에서. 이 페이지는 스스로 아무것도 가져오지 않습니다. 붙여넣은 것만 읽습니다. 파일을 실어 나른 응답 헤더를 검사하려면 그것들을HTTP 헤더 파서.
셀프테스트
RFC 9309 참조 사례에 대해 파서와 매처를 다시 실행합니다.* 그룹 폴백, 경로와 사용자 에이전트의 대소문자 구분, 와일드카드, $앵커,/robots.txt 퍼센트 인코딩 정규화, 사이트맵 추출, 부정 경로. 아무것도 전송되지 않습니다.
robots.txt란 무엇인가?
한 문장으로: robots.txt는 사이트 루트의 일반 텍스트 파일로, 예의 바른 크롤러에게 어느 경로를 가져올 수 있는지 알려 줍니다 — 2022년 RFC 9309로 표준화된 자발적 관례이며 모든 주요 크롤러가 존중합니다.
파일의 형태

파일은 레코드의 나열입니다. 그룹은 하나 이상의 User-agent 줄로 시작하고, 그 크롤러들에 적용되는 Allow와 Disallow 규칙이 뒤따릅니다. 규칙 뒤에 나오는 새 User-agent 줄은 새 그룹을 시작하며, 연속된 여러 User-agent 줄은 하나의 그룹을 공유합니다(이름이 두 개인 크롤러에게 필요합니다). Sitemap 같은 독립 레코드는 어디에나 올 수 있습니다. #는 줄 어디에서든 주석을 시작합니다. 필드 이름은 대소문자를 구분하지 않지만, 경로는 구분합니다.

줄의미
User-agent: foobot아래 규칙은 이름에 foobot를 포함하는 크롤러에 적용됩니다
User-agent: *아래 규칙은 더 구체적인 그룹이 없는 모든 크롤러에 적용됩니다
Disallow: /private//private/로 시작하는 경로를 가져오지 마세요
Allow: /private/public/이 경로들에 대해 위의 disallow를 이기는 예외(길어서)
Disallow: (빈 값)아무것도 금지되지 않습니다 — 고전적인 "모두 허용" 관용구
Sitemap: https://…/sitemap.xml사이트맵이 있는 곳. 크롤러가 여러 개를 수집할 수 있습니다
Crawl-delay: 30RFC 9309에 없음 — 구형 확장. 주요 크롤러가 무시합니다
판정이 이루어지는 방법 (RFC 9309 §2.2.2)

1. User-agent 값이 크롤러 이름의 부분 문자열인 그룹을 찾고, 일치하는 모든 그룹을 병합하세요. 없으면 * 그룹을, 그것도 없으면 모든 것이 허용됩니다. 2. 모든 규칙에 대해 경로를 검사합니다. 일치는 접두사 기반이고 대소문자를 구분하며 */$가 와일드카드로 작동합니다. 3. 가장 긴 일치 규칙이 이기고, 길이가 같으면 Allow가 Disallow를 이깁니다. 일치하는 규칙이 없으면 허용입니다. 그리고 규칙이 무엇을 말하든 /robots.txt 자체는 암묵적으로 허용됩니다 — 그렇지 않으면 크롤러가 규칙을 읽을 수 없습니다.

흔한 실수
  • robots.txt가 접근을 막는다고 믿기. 예의 바른 크롤러에 대한 요청이지 벽이 아닙니다. 무법 스크래퍼는 완전히 무시하고, 브라우저가 열 수 있는 것에도 영향이 없습니다. 진짜 보호에는 인증을 쓰고, 검색엔진 조율만이라면 robots.txt가 옳은 도구입니다.
  • Disallow: /가 검색 결과에서 페이지를 제거하리라 기대기. 크롤링을 멈추는 것이지 색인이 아닙니다. 다른 페이지에서 사이트로 링크하면 검색엔진이 URL을 (설명 없이) 여전히 나열할 수 있습니다. 제거 도구는 noindex 메타 태그나 응답 헤더입니다.
  • 길이 대신 순서에 의지하기. 첫 일치 규칙이 이기는 것이 아니라 가장 구체적인(가장 긴) 것이 이깁니다. 동작을 "고치려고" 줄을 재배열하는 것은 아무 효과가 없습니다. 의도한 규칙을 더 길게 만드세요.
  • CSS와 JS 차단. /*.css$와 /*.js$를 Disallow하는 것은 흔한 "최적화"였습니다. 렌더러는 이제 방문자처럼 페이지를 보기 위해 그 파일들이 필요하고, 반쯤 렌더링된 페이지는 순위가 낮아질 수 있습니다.
  • 하나의 큰 그룹을 문서로 취급. 그룹 안의 주석 줄은 괜찮지만, 첫 User-agent 줄 앞에 # 없이 산문 한 단락이 있으면 파싱 오류로 관대한 파서를 혼란스럽게 할 수 있습니다.
FAQ

모든 크롤러가 Allow, *, $를 지원하나요? 주요 크롤러는 모두 지원하며, RFC 9309도 세 가지를 모두 표준화했습니다. 일부 작거나 오래된 크롤러는 Disallow만 인식하고 *를 문자 그대로 취급합니다 — 규칙을 단순하게 쓸 수 있으면 그렇게 쓰라는 이유 중 하나입니다.

빈 Disallow:는 무엇을 의미하나요? "아무것도 금지하지 않음" — 해당 그룹은 모든 것을 명시적으로 허용합니다. 누군가 템플릿을 고치면서 경로는 지우고 지시자는 남겨 둘 때 흔히 나타납니다; 검사에서 이런 줄이 표시됩니다.

파일은 얼마나 클 수 있나요? RFC 9309는 파서에게 최소 500 KiB를 처리할 것을 요구합니다; 그 이상에서는 크롤러가 읽기를 멈추고 나머지를 금지로 간주할 수 있습니다. 이 값보다 훨씬 작게 유지하세요; 파일이 이미 비대하다면 크롤링 제어를 페이지 응답 헤더로 옮겨야 하는지 생각해 볼 때입니다.

왜 매처가 /robots.txt가 Disallow: / 아래에서도 허용된다고 말하나요? 표준이 그렇게 못 박고 있기 때문입니다: robots 파일 자체는 암묵적으로 허용됩니다. Python의 urllib.robotparser 같은 구현은 이 예외를 구현하지 않았습니다 — 이것이 바로 이 페이지의 자체 테스트가 기록한, 실제 파서들 사이의 미묘한 차이 중 하나입니다.

Disallow 경로는 대소문자를 구분하나요? 예. /Private/와 /private/는 서로 다른 경로입니다. 필드 이름 disallow는 대소문자를 가리지 않지만, 값은 URL과 정확히 일치해야 합니다.