robots.txt 파일은 웹마스터의 도구 중 가장 오래되고 강력한 것 중 하나입니다. 모든 도메인의 루트에 위치하는 이 일반 텍스트 파일은 크롤러에게 사이트의 어떤 부분에 접근할 수 있고 어떤 부분은 접근하지 말아야 하는지를 알려줍니다. 단순함에도 불구하고 robots.txt는 웹에서 가장 자주 잘못 구성되는 파일 중 하나이기도 합니다. 단 하나의 잘못된 규칙이 전체 사이트를 검색 엔진으로부터 숨기거나, 비공개로 유지하려던 섹션을 노출시킬 수 있습니다.

이 가이드는 기본 구문부터 고급 패턴까지 모든 것을 다루므로, 자신감을 가지고 robots.txt 규칙을 작성할 수 있습니다.

robots.txt의 위치와 크롤러가 찾는 방법

모든 규격 준수 크롤러는 도메인의 다른 URL을 요청하기 전에 먼저 루트에서 /robots.txt를 가져옵니다:

https://example.com/robots.txt

파일 자체에 관한 주요 규칙:

• 정확한 경로 /robots.txt에서 제공되어야 합니다 — /Robots.txt도 아니고 하위 디렉토리 내부도 아닙니다.
• text/plain 콘텐츠 유형과 함께 200 상태 코드를 반환해야 합니다. 서버가 404를 반환하면 크롤러는 모든 것이 허용된 것으로 간주합니다. 5xx 오류는 대부분의 크롤러가 파일이 사용 가능해질 때까지 크롤링을 일시 중지하게 합니다.
• 파일은 오리진별(스킴 + 호스트 + 포트)로 적용됩니다. https://example.com/robots.txt의 규칙은 https://blog.example.com이나 http://example.com을 관할하지 않습니다.
• Google이 인정하는 최대 파일 크기는 500 KiB입니다. 그 이상은 무시됩니다.

기본 구문

robots.txt 파일은 하나 이상의 규칙 그룹으로 구성됩니다. 각 그룹은 하나 이상의 User-agent 줄로 시작하고, Disallow 및/또는 Allow 지시어가 뒤따릅니다:

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

User-agent 줄은 뒤따르는 규칙이 적용되는 크롤러를 지정합니다. 와일드카드 *는 자체 특정 블록이 없는 모든 크롤러에 매칭됩니다. 크롤러는 사용 가능한 가장 구체적인 User-agent 블록에 자신을 매칭합니다. User-agent: *와 User-agent: Googlebot이 모두 존재하면, Googlebot은 Googlebot 전용 블록만 사용하고 와일드카드 블록은 완전히 무시합니다.

Disallow

Disallow: /path/는 매칭된 크롤러에게 /path/로 시작하는 URL에 접근하지 말라고 지시합니다. 경로 없는 빈 Disallow:는 아무것도 차단하지 않음을 의미하며, 전체 접근을 허용하는 것과 같습니다.

Allow

Allow: /path/는 더 넓은 Disallow가 차단하더라도 패턴에 매칭되는 URL에 대한 접근을 명시적으로 허용합니다. 예외를 만드는 데 필수적입니다.

와일드카드와 패턴 매칭

원래 1994년 robots.txt 명세에는 와일드카드가 포함되지 않았지만, Google, Bing 및 대부분의 최신 크롤러는 두 가지 중요한 패턴 매칭 문자를 지원합니다:

별표: *

빈 문자열을 포함한 모든 문자 시퀀스에 매칭됩니다. 예시:

• Disallow: /*.pdf — 경로의 어디에든 .pdf가 포함된 모든 URL을 차단합니다.
• Disallow: /directory/*/page — /directory/anything/page와 같은 URL을 차단합니다.

달러 기호: $

URL의 끝에 매칭을 고정합니다. $ 없이는 패턴이 접두사로 매칭됩니다. 예시:

• Disallow: /*.pdf$ — .pdf로 끝나는 URL을 차단하지만, URL이 .pdf에서 끝나지 않는 /file.pdf?view=1은 허용합니다.
• Allow: /page$ — 정확히 /page만 허용하고 /page/subpage나 /page?q=1은 허용하지 않습니다.

Allow vs Disallow: 어느 것이 우선인가?

URL이 Allow와 Disallow 규칙 모두에 매칭될 때, 해결은 구체성(경로 길이)에 따라 달라집니다. Google의 구현은 다음 논리를 따릅니다:

1. 더 긴 매칭 경로를 가진 규칙이 우선합니다.
2. 두 규칙의 길이가 같으면, Allow가 우선합니다.

예시:

User-agent: *
Disallow: /directory/
Allow: /directory/public/

여기서 /directory/public/page.html은 /directory/public/(20자)이 /directory/(11자)보다 길기 때문에 허용됩니다. 그러나 /directory/secret.html은 여전히 차단됩니다.

이는 혼란의 흔한 원인입니다. 항상 robots.txt 테스터로 규칙을 테스트하여 특정 URL에 대한 결과를 확인하세요.

Crawl-delay 지시어

Crawl-delay는 크롤러에게 연속 요청 사이에 지정된 초 수만큼 대기하도록 요청합니다:

User-agent: Bingbot
Crawl-delay: 10

중요한 주의사항:

• Google은 Crawl-delay를 완전히 무시합니다. Googlebot의 크롤링 속도를 제어하려면 Google Search Console의 크롤링 속도 설정을 사용하세요.
• Bing은 이를 준수합니다. 값이 10이면 Bingbot은 요청 사이에 10초를 대기합니다.
• Yandex, Baidu 및 일부 다른 크롤러도 이를 준수하지만, 구현 방식은 다양합니다.
• 과도하게 높은 값(예: 60)을 설정하면 사실상 크롤링이 중단됩니다. 서버가 실제로 부하를 감당할 수 없는 경우에만 제한적으로 사용하세요.

Sitemap 지시어

robots.txt에서 직접 사이트맵을 선언할 수 있습니다:

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

주요 사항:

• Sitemap 지시어는 어떤 User-agent 블록에도 연결되지 않습니다. 파일의 상단이나 하단에 배치하세요—전역적으로 적용됩니다.
• URL은 완전히 정규화(스킴이 포함된 절대 URL)되어야 합니다.
• 여러 사이트맵을 나열할 수 있습니다.
• 이것은 발견 힌트이지 보장이 아닙니다. Search Console이나 Bing Webmaster Tools를 통해 사이트맵을 제출하는 것이 더 신뢰할 수 있습니다.

크롤링을 망가뜨리는 흔한 실수

1. CSS와 JavaScript 차단

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

최신 검색 엔진은 콘텐츠와 레이아웃을 평가하기 위해 페이지를 렌더링합니다. 렌더링에 필요한 리소스를 차단하면 크롤러는 깨진 페이지를 보게 되고—등급을 낮추거나 건너뛸 수 있습니다. 공개 콘텐츠 렌더링과 진정으로 관련 없는 리소스만 차단하세요.

2. 페이지를 색인에서 제외하기 위해 Disallow 사용

Disallow는 크롤링을 방지하지, 색인을 방지하지 않습니다. 다른 페이지가 차단된 URL로 링크하면, Google은 여전히 색인할 수 있습니다—다만 표시할 콘텐츠가 없어 모호한 목록이 됩니다. 페이지를 인덱스에서 완전히 제거하려면 noindex 메타 태그 또는 X-Robots-Tag 헤더를 사용하고 크롤러가 페이지를 볼 수 있도록 허용하세요.

3. 후행 슬래시 빠뜨리기

Disallow: /private   # /private, /private.html, /privately 등을 차단
Disallow: /private/  # /private/ 디렉토리 내부의 경로만 차단

첫 번째 패턴은 대부분의 사람들이 의도하는 것보다 더 넓습니다. 후행 슬래시가 필요한지 항상 고려하세요.

4. 와일드카드와 특정 블록의 충돌

User-agent: * 블록과 봇별 블록이 있고, 특정 블록이 비어 있으면 해당 봇에 전체 접근 권한을 효과적으로 부여합니다—와일드카드 블록이 제한적이더라도. 이는 설계상 의도된 것이지만, 규칙이 누적된다고 가정하는 사람들을 놀라게 합니다.

5. 리다이렉트 뒤에서 robots.txt 제공

/robots.txt가 301이나 302를 반환하면 대부분의 크롤러는 리다이렉트를 따릅니다. 그러나 체인 리다이렉트, 리다이렉트 루프, 또는 text/plain이 아닌 응답으로의 리다이렉트는 크롤러가 파일을 사용 불가능한 것으로 처리하게 합니다. 간단하게 유지하세요: 루트에서 200 응답으로 직접 파일을 제공하세요.

6. AI 크롤러를 고려하지 않음

robots.txt에 User-agent: * 블록만 있다면, 명시적으로 차단하지 않은 AI 크롤러는 Googlebot과 동일한 접근 권한을 갖게 됩니다. GPTBot, ClaudeBot, PerplexityBot, Bytespider 같은 봇에 대한 특정 규칙을 추가하는 것을 고려하세요.

robots.txt 테스트하기

테스트 없이 robots.txt 변경 사항을 배포하지 마세요. 사용 가능한 도구는 다음과 같습니다:

• Google Search Console — robots.txt 테스터는 Google이 특정 URL에 대해 규칙을 어떻게 해석하는지 보여줍니다.
• Bing Webmaster Tools — Bingbot을 위한 유사한 테스트 기능입니다.
• Spider.es — 검색 엔진, AI 봇, SEO 도구 등 어떤 크롤러가 도메인의 모든 URL에 접근할 수 있는지, 각 판정을 제어하는 특정 규칙과 함께 확인합니다.
• 명령줄 도구 — Python의 urllib.robotparser 같은 라이브러리로 CI/CD 파이프라인에서 테스트를 자동화할 수 있습니다.

견고한 기본 템플릿

# 검색 엔진: 전체 접근
User-agent: Googlebot
Allow: /

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

# AI 크롤러: 선택적
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# 기본: 제한적 허용
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

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

필요에 맞게 조정하세요. 원칙은 간단합니다: 허용하는 것에 대해 명시적으로, 차단하는 것에 대해 신중하게, 배포 전에 테스트하세요.

마치며

robots.txt는 기만적으로 단순합니다. 몇 줄의 텍스트가 수백만 명의 사람들이 검색 엔진과 AI 도구를 통해 콘텐츠를 발견할 수 있는지를 제어합니다. 사이트의 보안 구성과 동일한 주의를 기울이세요. 정기적으로 감사하고—특히 새로운 AI 크롤러가 등장할 때—Spider.es 같은 도구를 사용하여 의도한 정책이 현실과 일치하는지 확인하세요.