robots.txt 검증 방법: 무료 검사기 + 7가지 오류
robots.txt는 모든 크롤러가 사이트를 건드리기 전에 가장 먼저 읽는 파일이며, 조금도 봐주지 않습니다. 글자 하나만 잘못 써도 사이트 전체가 Google에서 사라질 수 있고, 규칙 하나가 엉뚱한 자리에 있으면 비공개 폴더가 GPTBot에 소리 없이 열립니다. 크롤러는 이 파일을 문자 그대로 해석할 뿐 문제를 알려주지 않으므로, 규칙이 의도대로 작동하는지 확인하려면 검증이 유일한 방법입니다. 이 가이드에서 다루는 내용: 구문 규칙, Allow와 Disallow 사이를 가르는 최장 일치(longest-match) 규칙, 빈 Disallow의 진짜 의미, AI 크롤러 규칙을 테스트하는 방법, 그리고 가장 흔한 일곱 가지 오류 — 모두 무료 Robots.txt Validator로 확인할 수 있습니다.
유효한 robots.txt란 정확히 무엇을 뜻하나요?
검증은 세 층위에서 이루어지며, 파일은 셋 모두를 통과해야 합니다:
- 구문(Syntax) — 모든 줄이 크롤러가 알아보는 지시어로 해석되어야 합니다. 깨진 줄은 아무 경고 없이 무시됩니다.
- 의미(Semantics) — 규칙이 의도한 결과를 만들어야 합니다. 해석은 완벽하게 되는 파일도 랜딩 페이지를 차단하거나, 막으려던 크롤러를 통과시킬 수 있습니다.
- 접근 가능성(Reachability) — 정확한 호스트와 프로토콜의 루트에 있는 소문자
robots.txt(https://example.com/robots.txt)가 일반 텍스트로 200을 반환해야 하며, 크기는 500 KiB 미만이어야 합니다 — Google의 크기 제한이며, 그 뒤의 내용은 무시됩니다. URL은 대소문자를 구분하므로(Robots.TXT는 404 = 전부 허용) 호스트마다 각각 필요합니다:example.com,www.example.com,blog.example.com에 하나씩 말입니다.
상태 코드는 내용만큼 중요합니다. 404는 오류가 아니고 401이나 403도 마찬가지입니다. Google은 429를 제외한 모든 4xx를 robots.txt가 아예 없는 것처럼, 즉 제약 없음으로 취급합니다. 그래서 Basic Auth가 걸려 401을 반환하는 스테이징 사이트는 차단된 게 아니라 규칙 자체가 없는 상태입니다. 위험한 쪽은 429와 5xx입니다. RFC 9309에 따라 크롤러는 이를 사이트 전체에 대한 완전한 임시 disallow로 취급하므로, 오류를 내는 robots.txt 하나가 크롤링 전체를 멈춰 세울 수 있습니다. 리다이렉트(http에서 https로, 도메인만 있는 주소에서 www로)는 따라갑니다 — 최소한 다섯 홉까지는요.
모든 robots.txt가 지켜야 할 구문 규칙
형식은 아주 작습니다. 한 줄에 지시어 하나, 지시어와 값 사이에는 콜론 하나. 인식되는 지시어는 User-agent, Allow, Disallow, Sitemap, Crawl-delay이며 그 외는 모두 무시됩니다. 깔끔한 파일 예시:
# Rules for all crawlers
User-agent: *
Disallow: /admin/
Disallow: /cart
Allow: /cart/help
Sitemap: https://example.com/sitemap.xml
해석이 제대로 되는지를 가르는 세부 사항:
- 규칙은 반드시
User-agent:줄 다음에 와야 합니다. 그 위에 있는 규칙은 통째로 무시됩니다. User-agent:줄은 다음User-agent:줄이 나오기 전까지 아래의 모든 규칙에 적용되며, 빈 줄이 그룹을 끝내지는 않습니다.- 연달아 놓인
User-agent:줄들은 아래 규칙을 공유하는 하나의 그룹이 됩니다 — GPTBot과 ClaudeBot에 정책 하나를 같이 적용하는 방법이 바로 이것입니다. - 지시어 이름은 대소문자를 구분하지 않지만 경로는 구분합니다.
Disallow: /Admin/은/admin/을 막지 못합니다. Sitemap:은 어느 위치에든 올 수 있지만, 값은 절대 URL이어야 합니다.
Allow와 Disallow의 상호작용: 최장 일치 규칙
대부분의 파일이 틀리는 지점이 바로 여기입니다. 규칙은 순서대로 적용되지 않고, 마지막 줄이 이기지도 않습니다. 매칭은 두 단계로 이루어집니다. 첫째, 접두사 매칭: 패턴을 URL의 첫 글자부터 비교하므로 Disallow: /cart는 /cartoons와 /cart/help도 막습니다. 둘째, 최장 일치: 매칭된 규칙 중 경로가 가장 긴 것이 이기며, 길이가 같으면 Allow가 이깁니다 — Google이 정하고 RFC 9309가 채택한 동률 처리 규칙입니다.
User-agent: *
Disallow: /search
Allow: /search/faq
Disallow: /*.pdf$
URL 세 개를 보세요:
/search/results?page=2—/search(7자)와 매칭됩니다. 차단됩니다./search/faq—/search(7자)와/search/faq(11자) 모두와 매칭됩니다: 더 긴 쪽이 이겨 허용됩니다./files/report.pdf—/*.pdf$와 매칭됩니다:*는 임의로 이어진 문자와 맞고$는 매칭의 끝을 고정합니다. 한 가지 함정: 매칭에는 쿼리 문자열도 포함되므로/*.pdf$는 URL이 .pdf로 끝나지 않는/report.pdf?utm_source=x를 여전히 놓칩니다.
그다음은 값이 비어 있는 경우입니다. 값 없는 Disallow:는 “이 user-agent에는 모든 것을 허용”을 뜻하는 유효한 패턴입니다 — Google 공식 예시도 그렇게 씁니다:
User-agent: *
Disallow: /private/
User-agent: GPTBot
Disallow:
다른 모든 크롤러는 /private/에 들어가지 못하지만 GPTBot에게는 모든 것이 명시적으로 허용됩니다 — 크롤러 하나의 차단을 푸는 표준적인 방법입니다. 반면 빈 Allow:는 아무 일도 하지 않습니다.
무료 검사기로 robots.txt 검증하는 방법
무료 Robots.txt Validator는 세 층위를 한 번에 검사합니다: 줄 번호가 붙은 구문 문제, 앞서 설명한 최장 일치 엔진으로 하는 의미 검사, 그리고 접근 가능성입니다.
1단계: 파일을 도구에 넣기
탭을 고르세요. Paste text는 초안용이고, Check URL은 실제 사이트에서 https://yoursite.com/robots.txt를 가져오므로 크롤러가 받는 그대로를 검증하게 됩니다. 404와 (잘못 설정된 404 핸들러가 내놓는) HTML 페이지는 모두 플래그가 붙습니다 — 위의 상태 코드 규칙도 그대로 적용됩니다: 401/403은 “규칙 없음”, 5xx는 “전부 차단”을 뜻합니다.
2단계: 검증 결과 읽기
통과, 경고, 오류 세 개의 카운터가 결과의 첫머리를 차지하고, 각 발견 사항은 줄 번호와 수정 제안이 붙은 한 줄로 표시됩니다. 오류는 겉보기에 하려는 일을 실제로 할 수 없는 줄입니다(콜론 없는 규칙, 절대 URL이 아닌 Sitemap URL, 공백이 들어간 경로). 나머지 줄은 여전히 해석됩니다. 경고는 유효하지만 위험한 패턴입니다(User-agent: * 블록 없음, Sitemap 지시어 없음, Googlebot이 무시하는 Crawl-delay). 오류 0개에 경고까지 검토를 마쳤다면 건강한 상태입니다.
3단계: 규칙에 실제 URL 테스트하기
결과 아래의 크롤 테스트 패널은 크롤러가 하듯 규칙을 적용합니다. 경로와 크롤러를 고르세요 — Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot이 기본 내장되어 있고, 파일에 있는 모든 user-agent가 목록에 나타나며, 파일에 User-agent: * 블록이 있으면 * (모든 기타 크롤러) 항목도 표시됩니다. *가 없으면 파일에 기본 그룹이 없는 것입니다. 전용 그룹 없는 크롤러는 어디에도 속하지 않아 결국 전부 허용으로 떨어집니다. 판정은 ALLOWED 또는 BLOCKED와 함께 적용된 규칙과 그 줄 번호를 보여줍니다. 수익 페이지, 관리자 경로, 방금 수정한 패턴을 테스트해 보세요.
4단계: 수정, 재검증, 배포
플래그가 붙은 줄을 고치고, 깨끗해질 때까지 다시 검증하고, 배포한 뒤 실제 파일을 대상으로 URL 검사를 실행하세요. 아예 새로 만들고 싶다면 무료 Robots.txt Generator가 깔끔한 구조를 만들어 주고, 같은 도구에서 다시 검증할 수 있습니다.
robots.txt에서 흔히 나오는 7가지 오류
1. User-agent 줄보다 앞에 있는 규칙
모든 User-agent: 줄보다 위에 있는 Disallow는 무시됩니다 — 보통 블록을 지우고 남은 규칙들입니다. 해결: User-agent: *로 시작하고 모든 규칙을 블록 안에 두세요.
2. 콜론 누락과 지시어 오타
disallow /admin/(콜론 없음), User agent: *(하이픈 자리에 공백), Dissalow:(오타)는 어디서도 보고되지 않습니다 — 줄이 건너뛰어지고 해당 경로는 열려 있는 채로 남습니다. 해결: 모든 줄은 지시어: 값 형식이어야 하며, 어긋나는 줄은 검사기가 플래그를 붙입니다.
3. Disallow에 절대 URL 쓰기
Disallow: https://example.com/admin/은 아무것도 매칭하지 못합니다: 경로는 언제나 호스트 기준 상대 경로이므로, 규칙은 소리 없이 실패하고 /admin/은 계속 크롤링됩니다. 해결: 경로만 쓰세요. 반면 Sitemap 줄은 반드시 절대 URL이어야 합니다.
4. 사이트 전체를 막는 Disallow: /
User-agent: * 아래의 Disallow: / 한 줄이면 사이트 전체가 검색에서 사라집니다. 전형적인 원인: 스테이징 파일을 운영 환경에 그대로 복사했거나, WordPress의 “검색 엔진이 사이트를 색인하지 못하도록 시도(Discourage search engines)” 설정을 오픈 후에도 켜두었거나. 이 설정은 가상 robots.txt를 내보내므로 지울 줄이 없습니다. 설정(Settings) → 읽기(Reading)에서 끄거나, 사이트 루트에 실제 robots.txt를 올려 가상 파일을 덮어쓰세요. 그런 다음 Search Console의 URL 검사(URL Inspection)로 주요 페이지의 재크롤링을 요청해 회복을 앞당기세요.
5. 의도와 정반대로 작동하는 빈 값
값 없는 Allow:는 아무 일도 하지 않고, 값 없는 Disallow:는 모든 것을 허용합니다. 해결: “아무것도 막지 않으려면” 빈 Disallow:를 올바른 그룹 안에 쓰고, 경로를 막으려면 경로를 추가하세요.
6. 경로 속 공백
RFC 9309의 문법에서 경로는 첫 공백에서 끝나므로 Disallow: /my folder/는 Disallow: /my로 취급되고, 모든 /my* URL을 소리 없이 과도하게 차단합니다. 해결: /my%20folder/처럼 퍼센트 인코딩하세요.
7. Sitemap 지시어 누락
해석 오류는 아니지만 낭비되는 기회입니다. Sitemap: https://example.com/sitemap.xml이 없으면 발견은 Search Console이나 Bing Webmaster Tools의 수동 제출, 또는 외부 링크에 의존하게 됩니다. 해결: 절대 URL을 추가하세요 — XML Sitemap Generator로 만들 수 있습니다. Crawl-delay는 해석은 되지만 Googlebot이 무시합니다. 신뢰할 수 있는 크롤 속도 조절 수단이 된 적은 없습니다.
AI 크롤러 규칙 테스트: GPTBot, ClaudeBot, PerplexityBot
robots.txt 파일이 다시 수정되는 이유가 바로 AI 크롤러인데, 여기에는 대부분이 놓치는 규칙이 하나 더 있습니다: 크롤러에게 자기 이름을 딴 그룹이 있으면 그 그룹만 적용되고, 그 크롤러에게 * 블록은 전적으로 무시됩니다. 크롤러는 자기 그룹을 어떻게 찾을까요? 부분 문자열로 찾습니다. Google은 그룹의 user-agent 값이 크롤러 자신의 토큰 안에 들어 있으면 그 그룹을 매칭하며, 가장 구체적인 매칭이 이깁니다. 그래서 Googlebot 그룹은 googlebot-news 그룹이 없을 때 Googlebot-News까지 다스리고, User-agent: Google은 모든 Googlebot 변형을 잡아냅니다 — 보통 의도보다 넓게요. 이 때문에 뜻밖의 실패 양상이 생깁니다:
User-agent: *
Disallow: /admin/
Disallow: /internal/
User-agent: GPTBot
Disallow: /internal/
“GPTBot이 /admin/ 차단을 물려받는다”라고 읽기 쉽습니다. 틀렸습니다. GPTBot은 자기 그룹에 매칭되어 * 규칙이 적용되지 않고, /admin/은 GPTBot에 열려 있습니다. 일반 제한을 물려받게 하려면 GPTBot 그룹 안에 제한을 그대로 반복해 쓰세요 — ClaudeBot, PerplexityBot, 그 밖의 이름 있는 에이전트도 마찬가지입니다.
크롤 테스트는 바로 이 확인을 위해 있습니다: 민감한 경로 하나를 두 번 실행하세요 — *로 한 번(파일에 * 블록이 있을 때 목록에 나타납니다), GPTBot으로 한 번 — 그리고 판정을 비교하세요. 의도치 않게 서로 다르다면 그룹을 합치세요. 운영 중인 사이트가 어떤 AI 크롤러를 들이고 있는지 감사하려면 검사기와 AI Crawler Checker를 함께 쓰세요.
자주 묻는 질문
제 robots.txt가 유효한지 어떻게 확인하나요?
파일을 무료 Robots.txt Validator에 붙여넣거나, 도메인을 입력해 실제 파일을 가져오게 하세요. 줄 번호와 수정 방법이 붙은 통과/경고/오류 카운트와 함께, 주어진 크롤러에게 URL이 허용되는지 차단되는지 보여주는 크롤 테스트 결과를 얻습니다. 오류가 0개면 파일이 제대로 해석된다는 뜻이고, 크롤 테스트가 의도대로 작동하는지 확인해 줍니다.
빈 Disallow는 무엇을 뜻하나요?
값 없는 Disallow:는 위에 명시된 user-agent(들)에게 모든 것을 허용하는 유효한 패턴입니다. 제한적인 파일 안에서 크롤러 하나의 차단을 푸는 표준적인 방법입니다. 반면 빈 Allow:는 아무 역할도 하지 않습니다.
페이지를 disallow하면 Google에서 사라지나요?
아니요. robots.txt는 가져오기(fetching)를 통제하지 색인을 통제하지 않습니다. 차단된 URL이라도 다른 곳에서 링크하면 Google은 여전히 검색 결과에 올릴 수 있습니다 — 내용을 읽지 못할 뿐입니다. 페이지를 색인에서 빼려면 크롤러가 가져가게 두고 noindex 태그나 헤더를 사용하세요. URL을 차단하면 Google이 noindex를 아예 보지 못합니다.
Crawl-delay가 Googlebot을 늦추나요?
아니요. Googlebot은 Crawl-delay를 지킨 적이 없습니다. Bingbot이나 Yandex 같은 일부 다른 크롤러만 지원합니다. 검사기가 Crawl-delay 줄에 경고를 붙이는 이유가 바로 이것입니다. Googlebot의 부하가 문제라면 해결책은 robots.txt가 아니라 Google Search Console의 크롤 속도 설정에 있습니다.
Google이 robots.txt 변경을 알아차리는 데 얼마나 걸리나요?
Google은 robots.txt를 최대 24시간 캐시하므로 수정이 반영되는 데 하루쯤 걸릴 수 있고, 재크롤링은 그 위에 더해집니다. 배포한 뒤가 아니라 하기 전에 초안을 검증하세요 — 무료 검사기는 파일이 운영 환경에 도달하기 전에 붙여넣은 내용부터 검사해 줍니다.