robots.txt에서 Disallow: ''와 Disallow: /는 정반대 의미
robots.txt 한 줄을 잘못 써서 사이트 전체가 몇 주간 검색에서 사라지는 사고는 지금도 반복됩니다. 원인은 대부분 하나의 규칙, Disallow: 지시어에 값을 채우느냐 비워두느냐입니다. 겉보기엔 "거의 같은 표기"처럼 보이지만 실제로는 완전히 반대되는 명령이라, 배포 직전에 습관적으로 슬래시 하나를 더 눌렀다가 인덱스가 통째로 빠지는 일이 벌어집니다. 이 가이드는 왜 이 둘이 반대가 되는지, 그리고 왜 사람이 자꾸 이걸 헷갈리는지 구조적으로 짚어봅니다.
1. 문법적으로는 "빈 값"과 "슬래시"만 다르다
robots.txt의 Disallow 지시어는 Disallow: 경로 형태로, 콜론 뒤에 오는 값이 "이 경로부터 시작하는 모든 URL을 차단하라"는 접두어(prefix) 매칭 패턴입니다. 여기서 핵심은 접두어 매칭이 빈 문자열에 대해서는 성립하지 않는다는 점입니다. 모든 URL은 /로 시작하지만, 빈 문자열로 시작하는 URL이라는 개념 자체가 정의되지 않습니다. 그래서 표준 파서는 빈 값을 "매칭 대상 없음" = 아무것도 차단하지 않음으로 처리하도록 명시하고 있습니다. 반대로 /는 모든 경로가 반드시 포함하는 최상위 접두어이므로, /로 시작하는 모든 URL, 즉 사이트 전체가 매칭 대상이 됩니다.
Disallow: (뒤에 아무것도 없음) → 차단 규칙 자체가 성립하지 않음 → 전체 허용.Disallow: / → "모든 경로"라는 접두어 매칭 → 전체 차단.
2. 왜 사람은 이걸 반대로 예상하는가
이 혼동이 반복되는 이유는 일상 언어의 직관과 정반대이기 때문입니다. "값을 안 채웠다 = 아무것도 안 정했다 = 위험하게 다 열어둔 것 아닌가?"라는 직관이 먼저 작동하고, "슬래시 하나만 썼다 = 최소한만 지정한 것 = 별로 안 위험할 것"이라는 착각이 뒤따릅니다. 실제로는 그 반대입니다. 빈 값은 매칭 규칙이 존재하지 않는 것이고, /는 가장 강력하고 포괄적인 매칭 규칙입니다. 특히 임시로 사이트 전체를 막아뒀다가 배포 시 지우는 것을 깜빡하는 흔한 패턴(스테이징 서버 설정을 그대로 프로덕션에 복사)에서 Disallow: /가 그대로 살아남는 사고가 자주 발생합니다.
3. Google을 포함한 주요 크롤러의 실제 동작
Google, Bing 등 주요 검색엔진은 이 규칙을 표준(원조 1994년 로버츠 배제 표준 및 이후 RFC 9309)대로 해석합니다. 즉 이 문서에서 설명한 동작은 특정 도구의 자체 해석이 아니라 크롤러 생태계 전반의 합의된 문법입니다. Robots.txt 검증기로 직접 파싱 결과를 확인해보면, 빈 값 Disallow는 규칙 목록에서 disallow: (empty)로 표시되고 실제 URL 테스트에서 항상 허용으로 판정되는 반면, /는 어떤 경로를 넣어도 차단으로 판정되는 것을 바로 확인할 수 있습니다.
| robots.txt 줄 | 의미 | 테스트: /blog/post-1 결과 |
|---|---|---|
Disallow: | 차단 규칙 없음(전체 허용) | 허용 |
Disallow: / | 루트부터 전체 차단 | 차단 |
Disallow: /blog/ | /blog/ 하위 경로만 차단 | 차단 |
Allow: / + Disallow: /admin/ | /admin/만 차단, 나머지 허용 | 허용 |
4. 실전 사고 사례로 보는 예방법
가장 흔한 사고 패턴은 두 가지입니다. 첫째, 개발 환경 robots.txt를 프로덕션에 그대로 배포하면서 User-agent: * / Disallow: /를 지우지 않는 경우. 둘째, "전체 공개로 바꾸자"는 의도로 값을 지웠다가 오타로 슬래시가 남는 경우입니다. 둘 다 결과는 같습니다 — Google Search Console의 "제출된 URL이 robots.txt에 의해 차단됨" 경고가 뜨고, 인덱스에서 대량 이탈이 일어납니다.
- 배포 파이프라인에 robots.txt 내용을 diff로 비교하는 단계를 넣어,
Disallow: /같은 전체 차단 패턴이 새로 생기면 경고하도록 합니다. - 배포 직후 Robots.txt 검증기의 "URL 크롤링 허용 여부 테스트"로 대표 페이지 몇 개를 즉시 확인합니다.
- robots.txt를 처음부터 새로 만들 때는 손으로 치지 말고 Robots.txt 생성기로 규칙을 조립하면 빈 값/슬래시 혼동 자체가 발생하지 않습니다.
5. 부분 차단과 완전 차단을 구분해서 설계하기
실무에서는 "전체 차단"이 필요한 경우가 거의 없습니다. 관리자 페이지, 검색 결과 페이지, 장바구니처럼 크롤링 예산을 낭비하는 특정 경로만 Disallow: /admin/, Disallow: /search 식으로 지정하고, 나머지는 기본적으로 허용(Disallow 자체를 안 쓰거나 빈 값)하는 것이 정상적인 설계입니다. 사이트 전체를 의도적으로 막아야 하는 경우는 오픈 전 스테이징 환경 정도이며, 이때도 noindex 메타태그나 Basic Auth 등 이중 안전장치를 함께 쓰는 것이 안전합니다.
자주 묻는 질문
Q. Disallow 줄 자체를 아예 안 쓰면 어떻게 되나요?
Disallow 지시어 자체가 없는 User-agent 블록은 빈 값(Disallow:)과 동일하게 아무것도 차단하지 않는 것으로 해석됩니다. 결과는 같지만 명시적으로 빈 값을 써두면 "의도적으로 전체 허용했다"는 것이 코드리뷰 시 더 명확하게 드러납니다.
Q. Disallow: /와 Allow: /가 같이 있으면 어떻게 되나요?
Google 등 주요 크롤러는 더 구체적인(경로 길이가 긴) 규칙을 우선 적용합니다. 두 규칙의 경로 길이가 같다면(둘 다 "/") Allow가 우선 적용되어 전체 허용이 됩니다. 그러나 파서마다 우선순위 처리가 다를 수 있으므로 애매하게 두지 말고 의도를 명확히 쓰는 것이 안전합니다.
Q. robots.txt로 차단한 페이지는 검색 결과에서 완전히 사라지나요?
아닙니다. robots.txt 차단은 "크롤링(수집) 금지"이지 "인덱싱(색인) 금지"가 아닙니다. 이미 다른 곳에서 링크가 걸려 있으면 내용 없이 URL만 검색 결과에 노출될 수 있습니다. 완전히 검색에서 빼려면 noindex 메타태그를 쓰고 robots.txt로는 막지 않아야 합니다(막으면 크롤러가 noindex 태그를 아예 읽지 못합니다).
Q. 사고가 났는지 어떻게 빨리 알 수 있나요?
Google Search Console의 "설정 → robots.txt" 리포트에서 마지막으로 읽힌 robots.txt 내용을 확인할 수 있고, "페이지" 리포트에서 "robots.txt에 의해 차단됨" 항목이 급증하면 사고 신호입니다. 배포 직후 매번 Robots.txt 검증기로 셀프 체크하는 습관이 가장 빠른 예방책입니다.