robots.txt 작성법: 문법·예제·흔한 실수

robots.txt는 검색엔진 크롤러에게 “이 경로는 가져가지 마라”고 알려주는 평문 텍스트 파일이다. 문법 자체는 몇 줄이면 끝나지만, 실무에서는 세 가지에서 사고가 난다. (1) 파일을 엉뚱한 위치에 두거나, (2) 최장 일치·와일드카드 규칙을 오해해서 의도와 다른 URL이 차단되거나, (3) “robots.txt로 막으면 검색결과에서 사라진다”는 잘못된 믿음으로 색인 제거에 쓰다가 오히려 URL만 남은 반쪽짜리 검색결과를 만든다.

이 가이드는 robots.txt의 정확한 문법(User-agent 그룹, Disallow/Allow, *와 $, 최장 일치 규칙)을 정리하고, 사이트 유형별로 바로 복사해 쓸 수 있는 예제와 함께 실제 규칙 4줄을 URL 4개에 대입해 어떤 게 차단되는지 한 줄씩 따라간다. 직접 손으로 쓰기 번거로우면 robots.txt 생성기로 만들고, 배포 후에는 robots.txt 검사기로 특정 URL이 실제로 허용/차단되는지 검증하면 된다.

파일 위치: 호스트당 하나, 반드시 루트에

robots.txt는 호스트(도메인+프로토콜+포트)마다 정확히 하나이고, 반드시 루트 경로에 있어야 한다. 크롤러는 오직 https://example.com/robots.txt만 확인하며, /seo/robots.txt처럼 하위 폴더에 둔 파일은 존재하지 않는 것과 같다.

• https://example.com/robots.txt — example.com에만 적용
• https://blog.example.com/robots.txt — 서브도메인은 별도 파일이 필요하다. 본 도메인의 파일이 상속되지 않는다.
• http://와 https://도 원칙적으로 별개 호스트다. https로 통합 리다이렉트를 걸었다면 https 쪽 파일만 관리하면 된다.
• 파일은 UTF-8 평문이어야 하고, 구글은 500KiB까지만 읽는다(넘치는 부분은 무시).

응답 코드도 중요하다. robots.txt가 404면 “제한 없음”으로 간주해 전부 크롤링하지만, 5xx가 지속되면 구글은 사이트 전체 크롤링을 보수적으로 줄일 수 있다. 파일이 없더라도 200으로 빈 파일을 주거나 깔끔한 404를 반환하는지 확인하자.

문법: User-agent 그룹, Disallow/Allow, 와일드카드

robots.txt는 그룹 단위로 읽는다. 하나 이상의 User-agent 줄이 그룹을 시작하고, 그 아래 Disallow/Allow 줄이 그 그룹의 규칙이 된다. 크롤러는 자신과 가장 구체적으로 일치하는 그룹 하나만 따른다 — 예를 들어 User-agent: Googlebot 그룹이 있으면 Googlebot은 User-agent: * 그룹을 완전히 무시한다.

User-agent: *
Disallow: /admin/

User-agent: Googlebot
Disallow: /beta/

위 파일에서 Googlebot에게 적용되는 규칙은 Disallow: /beta/ 하나뿐이다. /admin/은 Googlebot에게 열려 있다 — 두 그룹이 합쳐질 거라 기대하면 안 된다. Googlebot도 막고 싶으면 Googlebot 그룹에 Disallow: /admin/을 한 줄 더 써야 한다.

• Disallow: 값으로 시작하는 경로를 크롤링 금지. Disallow:처럼 값이 비면 “아무것도 막지 않음”.
• Allow: Disallow의 예외를 뚫는 용도. 구글·빙이 지원한다.
• *: 0개 이상의 아무 문자와 일치. Disallow: /*.pdf는 경로 어딘가에 .pdf가 들어가는 모든 URL과 일치한다.
• $: 경로의 끝을 고정. Disallow: /*.pdf$는 .pdf로 끝나는 URL만 막는다(/file.pdf?v=2는 쿼리까지 포함해 매칭하므로 주의).
• 최장 일치(longest match) 규칙: Allow와 Disallow가 동시에 걸리면 일치한 경로 문자열이 더 긴 규칙이 이긴다. 길이가 같으면 구글은 덜 제한적인 쪽(Allow)을 택한다. 규칙을 쓴 순서는 무관하다.

최장 일치가 핵심이다. Disallow: /admin/(7자)과 Allow: /admin/help/(12자)가 함께 있으면, /admin/help/faq는 더 긴 Allow가 이겨서 크롤링이 허용된다. 이 계산을 머릿속으로 하기 어려우면 robots.txt 검사기에 규칙과 URL을 넣고 판정 결과를 바로 확인하는 편이 안전하다.

바로 쓰는 예제 모음 + Sitemap 지시어

Sitemap: 지시어는 그룹과 무관하게 파일 어디에 두어도 되고, 여러 줄 써도 된다. 값은 반드시 절대 URL이어야 하며(Sitemap: /sitemap.xml처럼 상대 경로 금지), robots.txt는 크롤러가 가장 먼저 읽는 파일이므로 사이트맵을 알리는 가장 확실한 통로다. 등록한 사이트맵이 실제로 유효한 XML인지, URL이 전부 200을 반환하는지는 사이트맵 검사기로 확인하자.

실전 예시: 규칙 4줄을 URL 4개에 대입해 보기

다음 규칙이 배포돼 있다고 하자.

User-agent: *
Disallow: /admin/
Allow: /admin/help/
Disallow: /*.pdf$
Disallow: /search

마지막 행이 가장 흔한 실수다. /search 페이지 하나만 막을 생각이었다면 Disallow: /search$(정확히 그 경로) 또는 Disallow: /search/(하위 디렉터리만)로 써야 한다.

치명적 오해: robots.txt는 색인을 지우지 못한다

robots.txt는 크롤링(가져오기)을 막을 뿐, 색인(검색결과 등록)을 막지 않는다.다른 사이트가 그 URL로 링크를 걸면 구글은 페이지 내용을 읽지 못한 채로 URL만 색인할 수 있다. 그 결과 검색결과에 제목도 설명도 없는 “이 페이지에 대한 정보가 없습니다” 형태의 항목이 남는다.

1. 검색결과에서 빼고 싶다면: 페이지에 <meta name="robots" content="noindex">(또는 X-Robots-Tag 헤더)를 달고, robots.txt에서는 그 페이지를 차단하지 말아야 한다. 차단하면 크롤러가 noindex 태그 자체를 못 읽는다.
2. 긴급 제거: Search Console의 URL 삭제 도구를 병행한다.
3. robots.txt가 맞는 용도: 크롤링 예산 절약(무한 필터·정렬 파라미터, 내부 검색 결과), 서버 부하가 큰 엔드포인트 보호. 비밀 보호 용도가 아니다 — robots.txt는 누구나 열람할 수 있어서 오히려 숨기고 싶은 경로의 목록표가 된다.

그 밖의 함정 두 가지. 첫째, 경로는 대소문자를 구분한다 — Disallow: /Admin/은 /admin/을 막지 못한다. 둘째, 위에서 본 대로 슬래시 유무로 의미가 달라진다(/admin은 접두사, /admin/은 디렉터리). 규칙을 고친 뒤에는 robots.txt 검사기로 대표 URL 몇 개를 넣어 판정을 확인하고, 처음부터 안전한 템플릿이 필요하면 robots.txt 생성기에서 옵션만 골라 내려받는 것이 실수를 줄이는 지름길이다.