robots.txt에 봇 이름을 적으면 공통 규칙이 빠진다: User-agent 그룹 규칙과 네이버·다음

2026년 10월 13일7분 분량devrives

핵심 요약

봇은 자기 이름이 적힌 그룹만 따르고, User-agent: * 그룹은 맞는 그룹이 없을 때만 읽어요. 같은 이름 그룹끼리는 합쳐지지만 * 그룹과는 합쳐지지 않아요.
옛 devrives.com robots.txt를 Google 공식 파서(RFC 9309 기준)로 검사하니 이름을 적은 Googlebot, Bingbot, GPTBot은 /api/가 허용됐고, 이름을 빠뜨린 네이버 Yeti와 다음은 차단됐어요.
네이버는 robots.txt가 HTML로 오면 규칙이 있어도 '모두 허용'으로 볼 수 있고, 5xx 응답은 '모두 허용하지 않음'으로 해석해요. text/plain과 200 응답을 확인하세요.
특정 봇 그룹을 꼭 써야 한다면 그 그룹에 공통 Disallow를 전부 다시 적어야 해요.

robots.txt에 User-agent: Googlebot 그룹을 하나라도 만들면, Googlebot은 User-agent: * 그룹에 적어 둔 규칙을 하나도 읽지 않아요. 크롤러는 자기에게 맞는 그룹 하나만 고르고, 봇 이름 그룹과 * 그룹은 합쳐지지 않기 때문이에요.

저희 devrives.com이 실제로 이 상태였어요. 흔히 돌아다니는 "SEO 최적화 robots.txt" 템플릿을 그대로 쓴 결과, 크롤링이 잘 되라고 이름을 적어 준 봇들만 차단 규칙에서 빠져 있었어요.

옛 devrives.com robots.txt에서 벌어진 일

2025년 12월판 파일은 94줄이었고, User-agent 줄이 18개였어요. 공통 그룹 하나와 봇별 그룹 17개예요. 구조만 줄이면 이래요.

User-agent: *
Allow: /
Disallow: /api/
Disallow: /unsubscribe/*
Disallow: /verify/*
Disallow: /reset/*
# (그 밖에 /.env, /.git/, /admin/ 등)

User-agent: Googlebot
Allow: /
Crawl-delay: 0

User-agent: Bingbot
Allow: /
Crawl-delay: 0

User-agent: GPTBot
Allow: /
# (Slurp, Twitterbot, anthropic-ai 등 14개 더)

템플릿의 의도는 "모두 허용하되 /api/와 계정 관련 경로만 막고, 주요 봇은 확실히 허용"이었어요. 이 파일을 Google이 공개한 robots.txt 파서(google/robotstxt, Googlebot과 같은 규칙 해석 코드)로 2026년 10월 13일에 직접 빌드해서 검사했어요.

봇 (토큰)	따른 그룹	`/api/x`	`/unsubscribe/abc`	`/reset/abc`
Googlebot	Googlebot 그룹	허용	허용	허용
Bingbot	Bingbot 그룹	허용	허용	허용
GPTBot	GPTBot 그룹	허용	허용	허용
Yeti (네이버)	`*` 그룹	차단	차단	차단
Daum (다음)	`*` 그룹	차단	차단	차단

표의 판정은 Google 파서의 결과예요. Bing, OpenAI, 네이버, 다음은 각자의 파서를 써서 세부 동작은 다를 수 있어요. 다만 그룹 선택은 표준(RFC 9309)의 핵심 규칙이고 네이버는 표준을 따른다고 밝히고 있어서, 같은 결과를 예상할 수 있어요. 실제 출력은 이런 형태예요.

user-agent 'Googlebot' with URI 'https://devrives.com/api/x': ALLOWED
user-agent 'Yeti' with URI 'https://devrives.com/api/x': DISALLOWED

이름을 적어 준 세 봇은 막으려던 경로가 전부 열려 있었어요. 반대로 템플릿에 이름이 없던 네이버와 다음 봇만 의도대로 막혔어요. 국내 검색엔진을 빠뜨린 덕에 오히려 그쪽만 제대로 동작한 셈이에요.

지금 파일은 User-agent: * 그룹 하나뿐이고, 같은 파서로 검사하면 다섯 봇 모두 /api/x가 차단돼요.

크롤러가 그룹을 고르는 규칙과 우선순위

robots.txt 표준인 RFC 9309는 그룹 선택을 이렇게 정해요.

크롤러는 자기 제품 토큰(Googlebot, Yeti 같은 이름)과 맞는 User-agent 줄을 찾아요. 이름 비교는 대소문자를 가리지 않아요.
같은 이름의 그룹이 여러 개 있으면 그 그룹들의 규칙을 하나로 합쳐요.
User-agent: * 그룹은 맞는 그룹이 하나도 없을 때만 따라요.
고른 그룹 안에서는 경로가 가장 길게 일치하는 규칙이 이겨요. 같은 경로의 Allow와 Disallow가 부딪히면 Allow를 쓰도록 권장해요(Google도 덜 제한적인 규칙을 따라요).

Google 문서도 같은 내용을 명시해요. "특정 크롤러에게 유효한 그룹은 하나뿐"이고, "봇 이름 그룹과 전역 그룹(*)은 합쳐지지 않는다"고 적혀 있어요(Google 검색 센터).

헷갈리기 쉬운 지점은 2번과 3번의 차이예요. User-agent: Googlebot 그룹을 파일 위와 아래에 두 번 쓰면 둘이 합쳐지지만, * 그룹은 거기에 끼지 못해요. 그래서 위 표에서 Googlebot이 따른 규칙은 Allow: /와 Crawl-delay: 0 두 줄뿐이었어요.

네이버 Yeti와 다음은 어떻게 읽을까

네이버

네이버 서치어드바이저의 robots.txt 가이드는 검색로봇이 "로봇 배제 표준을 준수하는 규칙을 해석"한다고 밝혀요. 그룹 선택 방식을 문장으로 따로 설명하지는 않지만, 표준을 따른다고 했으니 위의 1~4번이 그대로 적용된다고 보는 게 자연스러워요.

이 가이드에는 "네이버 로봇만 허용"하는 예시로 User-agent: * + Disallow: /와 User-agent: Yeti + Allow: /가 나와요. 다만 이 예시는 그룹을 합치든 대체하든 결과가 같아요. 같은 경로(/)의 Allow와 Disallow가 만나면 Allow가 이기기 때문이에요. 그러니 이 예시를 근거로 Yeti의 그룹 처리 방식을 단정하지는 마세요.

네이버만의 처리 기준은 Google과 다른 부분이 있어서 따로 챙겨야 해요.

상황	네이버 Yeti	Google
`robots.txt`가 4xx	모두 허용	파일이 없는 것으로 보고 제한 없음 (429 제외)
`robots.txt`가 5xx	모두 허용하지 않음 (이전에 받은 규칙을 잠시 쓸 수 있음)	처음 12시간은 사이트 크롤링을 멈추고 `robots.txt`를 다시 시도
`robots.txt`가 HTML로 반환	규칙이 있어도 '없음(모두 허용)'으로 볼 수 있음	HTML에서 규칙을 뽑아 보려고 시도
리디렉트	5회까지 따라가고, 넘으면 모두 허용	5회 이상 따라가고, 그래도 안 되면 404로 처리 (제한 없음)

서버가 잠깐 5xx를 내면 네이버는 사이트 전체를 수집하지 않는 쪽으로 해석해요. 그리고 SPA처럼 없는 경로에 index.html을 돌려주는 서버는 robots.txt 요청에도 HTML을 줄 수 있어요. 두 경우 모두 robots.txt 내용과 상관없이 결과가 달라져요.

규칙은 호스트 단위로 적용돼요. 네이버 가이드는 http://www.example.com/robots.txt가 https://example.com/에는 적용되지 않는다고 적어요. 서브도메인마다 robots.txt를 따로 둬야 해요.

다음(카카오)은 robots.txt 그룹 처리에 대한 공식 문서를 찾지 못했어요. 위 검사에서는 다음 검색로봇의 User-Agent 문자열(Daum/4.1)에 들어 있는 Daum을 토큰으로 넣었어요.

다음 웹마스터도구에서 사이트 소유를 확인할 때는 robots.txt에 #DaumWebMasterTool:... 한 줄을 넣어요. #로 시작하는 주석이라 어느 그룹에도 속하지 않고 규칙에도 영향을 주지 않아요. 기존 규칙은 그대로 두고 파일 끝에 붙이면 돼요. 저희 네 사이트(devrives.com/robots.txt, cctv.devrives.com/robots.txt, tickmark.devrives.com/robots.txt, safelife.devrives.com/robots.txt) 모두 이렇게 넣었어요.

특정 봇만 다르게 다루고 싶다면

방법은 두 가지예요.

* 그룹 하나만 쓴다. 모든 봇에게 같은 규칙이면 이게 가장 안전해요. "주요 봇 허용"을 위해 Allow: /만 있는 봇 그룹을 만드는 건 얻는 것 없이 공통 규칙만 지워요.

봇 그룹에 공통 규칙을 다시 적는다. 예를 들어 GPTBot은 막고, ClaudeBot은 허용하되 요청 간격을 두고 싶다면 이렇게 써요.

User-agent: *
Disallow: /api/

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Crawl-delay: 1
Disallow: /api/

GPTBot 그룹은 사이트 전체를 막으니 /api/를 다시 적을 필요가 없어요. ClaudeBot 그룹은 Crawl-delay 때문에 만든 그룹이라 Disallow: /api/를 반드시 다시 적어야 해요. 빠뜨리면 ClaudeBot에게 /api/가 열려요. Anthropic은 공식 안내에서 비표준 확장인 Crawl-delay를 지원한다고 밝혀요. 반면 Google은 이 필드를 무시해요.

봇 이름도 공식 문서에서 확인해야 해요. Anthropic이 현재 안내하는 토큰은 ClaudeBot, Claude-User, Claude-SearchBot 세 가지예요. 저희 옛 파일의 anthropic-ai, Claude-Web 그룹은 이 목록에 없는 이름이라, Anthropic이 안내하는 크롤러에는 아무 효과가 없었어요.

같은 파일에서 함께 정리한 것들

Crawl-delay: 0, Host:: Google이 지원하는 필드는 user-agent, allow, disallow, sitemap 네 가지예요. 나머지 줄은 Google에게 아무 효과가 없어서 지웠어요.
Disallow: /.env, /.git/, /admin/: robots.txt는 누구나 읽을 수 있는 공개 파일이에요. 숨기고 싶은 경로를 적으면 오히려 목록을 알려주는 꼴이 돼요. Google도 robots.txt는 페이지를 검색에서 빼는 수단이 아니라고 설명해요(robots.txt 소개). 이런 경로는 서버에서 접근 자체를 막아야 해요.
검색에서 빼고 싶은 페이지: robots.txt로 막으면 크롤러가 페이지 안의 noindex를 읽지 못해요. 다른 곳에서 링크되면 설명 없이 URL만 검색에 나올 수도 있어요. 그래서 저희는 개인정보처리방침 같은 페이지를 robots.txt로 막지 않고 noindex를 붙였어요.

올리기 전에 확인하는 방법

응답부터 본다. 네이버 기준에서 상태 코드와 Content-Type이 결과를 바꾸니까 가장 먼저 확인해요.

curl -sI https://example.com/robots.txt | grep -iE '^(HTTP|content-type|location)'
curl -s -o /dev/null -w '%{num_redirects} %{http_code}\n' -L http://example.com/robots.txt

10월 13일에 저희 다섯 호스트(devrives.com, www.devrives.com, cctv.devrives.com, tickmark.devrives.com, safelife.devrives.com)를 확인했어요. 모두 최종 200에 text/plain이었고, http에서 시작하면 리디렉트가 1회(www는 2회)였어요.

Google 파서로 경로별 결과를 본다. 위 표를 만든 방법이에요.

git clone https://github.com/google/robotstxt.git && cd robotstxt
mkdir c-build && cd c-build
cmake .. -DROBOTS_BUILD_TESTS=OFF && make robots-main
./robots /path/to/robots.txt Googlebot https://example.com/api/x

Python 표준 라이브러리로는 검사하지 않는다. urllib.robotparser는 가장 긴 규칙이 아니라 먼저 나온 규칙을 적용해요(Python 3.12 Entry.allowance 소스 기준). 옛 파일은 * 그룹 첫 줄이 Allow: /라서, 이름이 없는 봇에게도 /api/x를 허용으로 판정했어요. Google 파서는 같은 경우를 차단으로 판정해요. 결과가 정반대예요.

검색엔진 도구로 마무리한다. Search Console의 설정 메뉴에 있는 robots.txt 보고서는 Google이 찾은 파일, 마지막 크롤링 시각, 오류를 보여주고 다시 크롤링을 요청할 수 있어요. 네이버 서치어드바이저의 robots.txt 도구는 수집 요청과 함께 URL별 수집 가능 여부를 테스트해 줘요.

출처

RFC 9309: Robots Exclusion Protocol 2.2.1(그룹 선택), 2.2.2(규칙 우선순위)
Google 검색 센터: robots.txt 해석 방식: 그룹 선택, 지원 필드, 상태 코드 처리
Google 검색 센터: robots.txt 소개
Search Console 도움말: robots.txt 보고서
네이버 서치어드바이저: robots.txt 설정하기: 상태 코드별 처리, HTML 반환, 리디렉트, 호스트 범위
Anthropic: 크롤러와 차단 방법
google/robotstxt: 검사에 쓴 파서 (2026-10-13 빌드)
검사 대상: devrives.com robots.txt 2025-12-18판(2026-10-05 교체)과 현재 파일

자주 묻는 질문

robots.txt를 고치면 언제 반영되나요?

Google은 보통 robots.txt를 최대 24시간 캐시하고, RFC 9309도 24시간 넘게 캐시본을 쓰지 말라고 권해요. 급하면 Search Console robots.txt 보고서에서 다시 크롤링을 요청하거나, 네이버 robots.txt 도구에서 수집 요청을 누르세요.

경로도 대소문자를 가리지 않나요?

아니요. 봇 이름(User-agent)은 대소문자를 가리지 않지만, Google은 Disallow와 Allow의 경로를 대소문자 구분해서 비교해요(RFC 9309도 구분하도록 권장). Disallow: /API/는 /api/를 막지 못해요.

블로그로 돌아가기