robots.txt란? 크롤링은 막아도 색인은 못 막는 이유

robots.txt는 사이트 루트에 두는 텍스트 파일로, 검색엔진 크롤러에게 사이트의 어떤 URL에 접근해도 되고 어떤 URL에는 접근하지 말아야 하는지 알려 주는 규칙 파일입니다. 크롤링을 조절하는 파일이지 검색 결과에서 페이지를 빼는 파일이 아니라는 점이 가장 자주 헷갈리는 부분입니다.

robots.txt 뜻

robots.txt는 1994년 마르테인 코스터(Martijn Koster)가 처음 정의한 로봇 배제 규약(Robots Exclusion Protocol)을 따르는 파일이고, 2022년 9월 IETF가 RFC 9309로 표준 문서를 냈습니다. 크롤러는 사이트에 들어오기 전에 https://도메인/robots.txt를 먼저 읽고, 거기 적힌 규칙에 따라 어느 경로를 가져갈지 정합니다.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap.xml

위 예시는 “모든 크롤러(*)는 /wp-admin/ 아래로 들어오지 말되, admin-ajax.php는 가져가도 된다. 사이트맵은 여기 있다”는 뜻입니다. 구글 검색 센터 문서는 robots.txt의 주된 용도를 “요청이 너무 많아 사이트에 과부하가 걸리는 것을 막는 것”이라고 설명합니다. 즉 크롤링의 교통정리 도구입니다.

파일이 없어도 사이트는 정상입니다. 구글은 robots.txt가 404 같은 4xx 응답을 돌려주면 제한이 없는 것으로 보고, 네이버 서치어드바이저도 루트에 파일이 없으면 모든 콘텐츠를 수집해도 되는 것으로 간주한다고 밝힙니다.

robots.txt로 막을 수 있는 것과 막을 수 없는 것

robots.txt가 막는 것은 규칙을 지키는 크롤러의 방문뿐이고, 색인·노출·사람의 접근은 막지 못합니다. 구글 문서는 이 점을 분명히 적습니다. robots.txt는 “웹 페이지를 구글에서 빼기 위한 수단이 아니며”, 차단된 페이지라도 다른 사이트에서 링크되면 색인될 수 있고, 그때는 설명 없이 URL만 검색 결과에 나올 수 있다는 것입니다.

가장 흔한 함정은 검색에서 빼려고 robots.txt와 noindex를 함께 거는 경우입니다. 크롤러가 페이지에 들어오지 못하면 페이지 안의 noindex도 읽지 못하므로, 색인에서 빼고 싶다면 크롤링은 허용한 채 noindex를 읽게 해야 합니다. 구글은 robots.txt 안에 noindex를 적는 비공식 규칙도 2019년 9월 1일부터 지원하지 않습니다. 자세한 차이는 인덱싱(색인) 글에서 다룹니다.

보안 도구도 아닙니다. RFC 9309는 robots.txt 규칙이 “접근 권한 부여의 한 형태가 아니며”, 파일에 경로를 적으면 그 경로가 공개되어 오히려 찾기 쉬워진다고 경고합니다. 네이버도 링크 미리보기 생성 같은 특수 용도의 로봇은 규칙을 완벽하게 따르지 않을 수 있으니, 노출되면 안 되는 콘텐츠는 로그인 같은 다른 방법으로 보호하라고 안내합니다.

robots.txt 작성 방법

robots.txt는 UTF-8 일반 텍스트 파일로 만들어 사이트 최상위 경로에 올립니다. 구글의 robots.txt 사양 문서에 따르면 규칙은 파일이 있는 호스트·프로토콜·포트에만 적용됩니다. https://example.com/robots.txt는 https://blog.example.com이나 http://example.com에는 적용되지 않으므로, 서브도메인마다 파일을 따로 둬야 합니다.

쓸 수 있는 줄은 네 가지

구글은 이 네 필드만 지원하고 crawl-delay 같은 다른 필드는 무시합니다. 경로에는 와일드카드 두 개를 쓸 수 있습니다. *는 글자 0개 이상, $는 URL의 끝을 뜻합니다.

# 파라미터가 붙은 정렬 페이지는 크롤링하지 않음
User-agent: *
Disallow: /*?sort=

# PDF 파일만 막기 ($ 는 URL 끝)
Disallow: /*.pdf$

# 개발 중 전체 차단 (오픈 전에 반드시 지울 것)
# User-agent: *
# Disallow: /

규칙이 겹칠 때

구글은 URL과 일치하는 규칙 중 경로가 가장 길게 일치하는, 즉 가장 구체적인 규칙을 따르고, 길이가 같아 충돌하면 덜 제한적인 규칙을 따릅니다. 또 크롤러는 자기 이름이 적힌 그룹이 있으면 * 그룹을 보지 않고 그 그룹만 따릅니다. User-agent: Googlebot 그룹을 따로 만들었다면 *에 적은 공통 규칙을 그 그룹에도 다시 적어야 합니다.

AI 크롤러는 따로 막을 수 있나

따로 막을 수 있고, 같은 회사 안에서도 학습용과 검색용이 나뉘어 있어 하나만 골라 막을 수도 있습니다. 각 회사가 공식 문서에 밝힌 이름과 용도는 다음과 같습니다(2026년 9월 확인).

출처는 OpenAI 크롤러 문서, Anthropic 고객센터, 구글 크롤러 문서입니다. OpenAI는 robots.txt를 고친 뒤 검색 쪽에 반영되기까지 약 24시간이 걸릴 수 있다고 적었습니다.

# 학습용 수집만 거부하고 AI 검색 노출은 유지
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Allow: /

Google-Extended는 오해가 많은 이름입니다. 구글 문서에 따르면 이것은 별도의 크롤러가 아니라 robots.txt에서만 쓰는 제어용 이름이고, 실제 수집은 기존 구글 크롤러가 합니다. 그리고 막아도 AI 오버뷰에서 빠지지 않습니다. 구글의 AI 기능 문서는 AI 오버뷰를 포함한 검색 노출은 Googlebot에 대한 robots.txt와 nosnippet, noindex 같은 검색용 제어로 관리한다고 설명합니다. AI 오버뷰에서 빠지려고 Googlebot을 막으면 일반 검색에서도 함께 사라집니다.

실제로 얼마나 막고 있을까요. HTTP Archive의 Web Almanac 2025가 2025년 7월 약 1,621만 개 사이트의 robots.txt를 집계한 결과, 데스크톱 기준으로 Googlebot을 이름으로 적은 사이트가 6.22%였고, AI 크롤러는 GPTBot 4.5%, ClaudeBot 3.6%, CCBot 3.5%, Google-Extended 3.4%였습니다. 이름을 적었다는 뜻이지 모두 차단했다는 뜻은 아닙니다. 국내 사이트만 따로 본 공개 조사는 아직 없습니다.

학습용을 막을지는 사이트의 판단입니다. 다만 검색용(OAI-SearchBot, Claude-SearchBot)과 사용자 요청용까지 한꺼번에 막으면 AI 답변에 인용될 기회도 함께 사라진다는 점은 알고 정해야 합니다. AI 답변 인용을 다루는 방법은 GEO 글에 정리했습니다.

제대로 적용됐는지 확인하는 법

먼저 브라우저에서 https://내도메인/robots.txt를 직접 열어 봅니다. 텍스트로 보이고 상태 코드가 200이면 그다음은 검색엔진이 실제로 읽은 내용을 봅니다.

• 구글 서치 콘솔 robots.txt 보고서: 설정 메뉴에 있습니다. 고객센터 문서에 따르면 사이트 상위 20개 호스트에서 구글이 찾은 robots.txt, 마지막 크롤링 시간, 경고와 오류를 보여 주고, 중요한 차단을 푼 뒤 재크롤링을 요청할 수 있습니다.
• URL 검사: 특정 페이지가 robots.txt에 막혔는지는 URL 검사로 확인합니다.
• 네이버 웹마스터도구 robots.txt 도구: 수정한 파일의 수집을 요청하고, 설정한 규칙으로 특정 페이지의 수집 가능 여부를 테스트할 수 있습니다. 간단 생성 기능도 있습니다.

고친 내용이 바로 반영되지 않는 것은 정상입니다. 구글은 robots.txt를 보통 최대 24시간 동안 캐시하므로, 급하면 위 보고서에서 재크롤링을 요청합니다.

robots.txt가 안 먹힐 때 확인할 것

• 파일이 루트가 아닌 곳에 있습니다. /blog/robots.txt처럼 하위 폴더에 두면 크롤러는 읽지 않습니다.
• 서브도메인이나 http 주소를 빠뜨렸습니다. 규칙은 호스트·프로토콜마다 따로 적용됩니다.
• robots.txt가 HTML로 응답합니다. 네이버는 이 경우 유효한 규칙이 있어도 파일이 없는 것(모두 허용)으로 해석할 수 있다고 밝힙니다.
• 서버가 5xx 오류를 냅니다. 구글은 처음 12시간 동안 크롤링을 멈추고, 이후 30일까지는 마지막으로 캐시한 파일을 씁니다. 그 뒤에도 오류가 이어지면, 사이트가 대체로 접속되는 한 파일이 없는 것처럼 동작합니다.
• CSS·자바스크립트까지 막았습니다. 렌더링에 필요한 파일을 막으면 검색엔진이 페이지를 사람과 다르게 봅니다.
• 파일이 너무 큽니다. 구글은 500KiB를 넘는 부분을 무시합니다.
• 개발 서버의 전체 차단 파일이 그대로 배포됐습니다. 오픈 직후 색인이 전혀 안 된다면 가장 먼저 볼 곳입니다.

네이버에서는

네이버 검색로봇의 이름은 Yeti이고, 서치어드바이저의 robots.txt 가이드는 표준 규약을 따른다고 밝힙니다. 네이버만 허용하려면 다음처럼 씁니다.

User-agent: *
Disallow: /
User-agent: Yeti
Allow: /

기본 문법은 같지만 서버 응답을 해석하는 방식에 차이가 있습니다. 특히 5xx 오류가 나면 네이버는 곧바로 “모두 허용하지 않음”으로 해석합니다. 서버 장애가 네이버 수집에 더 빨리 영향을 준다는 뜻입니다.