테마

인기 도구

robots.txt 테스터

판정 과정까지 보여 주는 robots.txt 테스터입니다. URL을 판정한 규칙과 그 줄 번호, 크롤러가 실제로 읽은 그룹과 나머지 그룹이 무시된 이유, 그리고 파일의 상태 코드가 사이트 전체에 무엇을 뜻하는지까지, robots.txt 확인에 필요한 것을 한 번에 보여 줍니다.

알려진 크롤러 31개와 각 운영사가 robots.txt에 대해 밝힌 내용 · 판정을 내린 규칙과 그 줄 · RFC 9309와 Google 자체의 해석 · robots.txt는 한 번만 읽고, 이후 테스트하는 모든 URL은 브라우저에서 대조
한 번 읽고, 이 페이지에서 대조

도메인을 입력하면 파일을 읽고, example.com/admin/ 같은 전체 URL을 입력하면 그 경로도 테스트합니다.

  • 가져오기GET /robots.txt
  • 읽기그룹, 규칙, 사이트맵
  • 그룹크롤러가 따르는 규칙
  • 판정크롤러별로 크롤링할 수 있는 범위
예시

Google robots.txt 테스터 종료 후, robots.txt를 확인하고 테스트하는 방법

위에 도메인을 입력하고 “robots.txt 확인”을 선택하세요. 우리 서버에서 파일을 한 번 가져온 뒤, 입력하는 URL을 고른 크롤러별로 브라우저 안에서 테스트합니다. Google의 robots.txt 테스터가 폐지되기 전까지 하던 바로 그 일입니다.

Google은 2023년 11월 15일에 이 변경을 발표했습니다. “이번 업데이트의 일환으로 robots.txt 테스터를 종료합니다.” 기존 테스터는 2023년 12월에 사라졌고, 그 자리를 대신한 Search Console의 robots.txt 보고서는 전혀 다른 종류의 도구입니다.

이 보고서는 소유권을 확인한 속성의 상위 20개 호스트에 대해 Google이 이미 가져온 파일을, 확인 시각, 바이트 단위 크기, 문제 수와 함께 보여 줍니다. 규칙에 대해 URL을 테스트할 수도, Google이 아닌 크롤러를 테스트할 수도, 내가 소유하지 않은 사이트를 볼 수도 없습니다. 이 페이지는 그 세 가지를 모두 합니다.

Search Console robots.txt 보고서가 보여 주는 것과, 테스터가 하는 일
Search Console robots.txt 보고서소유권을 확인한 속성만robots.txt 테스터모든 사이트, 모든 크롤러, 모든 URL
  • Google이 마지막으로 가져온 파일
  • 파일 크기와 확인 시각
  • 파싱 문제 수
  • 이 URL이 이 크롤러에 허용되나요?
  • 어떤 규칙이 어느 줄에서 판정했는지
  • Google이 아닌 크롤러
  • 내가 소유하지 않은 사이트

Google은 2023년 11월 15일에 이 변경을 발표했고, 2023년 12월에 테스터를 없앴습니다.

robots.txt 테스터 결과 화면: 파일의 판정, Googlebot에 대해 /admin/public/ 경로를 판정한 규칙과 그룹, 지적 사항robots.txt 테스터 결과 화면: 파일의 판정, Googlebot에 대해 /admin/public/ 경로를 판정한 규칙과 그룹, 지적 사항결과의 의미상태 코드 그 자체가 아니라, 그것이 사이트 전체에 무엇을 뜻하는지 보여 줍니다. 여기서 404라면 모든 크롤러가 모든 것을 가져갈 수 있고, 503이라면 표준을 따르는 크롤러는 아무것도 가져가지 않습니다.판정을 내린 규칙이 크롤러에 대해 이 URL을 판정한 규칙을, 그 줄 번호와 그 규칙이 이긴 규칙과 함께 보여 줍니다. 가장 길게 일치하는 규칙이 이기고, 길이가 같으면 Allow가 이깁니다.선택된 그룹크롤러가 실제로 읽은 그룹과, 나머지 그룹이 무시된 이유입니다. 다른 도구들이 빠뜨리는 단계입니다.지적 사항모든 문제를 파일의 해당 줄에 표시하고, 해결 방법을 함께 알려 줍니다.
가상의 사이트를 확인한 결과입니다. 상태 코드가 뜻하는 바, 판정을 내린 규칙과 선택된 그룹을 보여 주는 URL 테스터, 그리고 파일의 해당 줄에 붙은 지적 사항이 보입니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

Google은 크롤러에 적용할 그룹을 어떻게 고르나요?

크롤러가 따르는 규칙 묶음은 정확히 하나입니다. 먼저 User-agent 줄에 자신의 제품 토큰이 적힌 그룹을 찾고, 그런 그룹이 없을 때만 * 그룹으로 넘어갑니다. * 그룹은 대체용이지, 추가분이 아닙니다.

RFC 9309는 분명하게 말합니다. “크롤러는 제품 토큰과 일치하는 그룹을 찾을 때 대소문자를 구분하지 않고 비교해야 한다(MUST)”, 그리고 “일치하는 그룹이 없으면, 크롤러는 값이 *인 user-agent 줄을 가진 그룹이 있을 경우 그 그룹을 따라야 한다(MUST).” Google도 자체 문서에서 같은 내용을 이렇게 씁니다. “특정 크롤러에 하나의 그룹만 유효합니다.”

여기서 두 가지가 따라 나오고, 이 둘이 혼란의 대부분을 만듭니다. 같은 토큰을 지정한 여러 그룹은 하나로 합쳐지므로, User-agent: Googlebot 블록이 두 개 있으면 둘 다 적용됩니다. 하지만 이름을 지정한 그룹과 * 그룹은 결코 합쳐지지 않습니다. Googlebot 그룹이 있으면 * 아래의 Allow: /는 Googlebot에 아무 효과가 없습니다. Googlebot-Image를 비롯한 Googlebot-* 크롤러는 googlebot 그룹을 대신 따르는데, 이것은 크롤러가 규칙 매칭 위에 덧붙인 동작이며 Google의 오픈소스 매처에는 구현되어 있지 않습니다.

크롤러가 읽는 그룹과, 나머지가 무시되는 이유
robots.txt
  1. 1# www.example.org
  2. 2User-agent: *
  3. 3Allow: /
  4. 4Disallow: /cart/
  5. 5
  6. 6User-agent: Googlebot
  7. 7Disallow: /admin/
  8. 8Allow: /admin/report.pdf
  9. 9
  10. 10Sitemap: https://www.example.org/sitemap.xml
  1. 1이 크롤러의 토큰을 지정한 그룹이 있나요?그 그룹을 읽습니다. * 그룹은 쓰지 않습니다.
  2. 2여러 그룹이 지정하나요?하나의 그룹으로 합쳐 읽습니다.
  3. 3* 그룹이 있나요?* 그룹을 읽습니다.
  4. —적용되는 규칙이 없습니다. 모든 것을 크롤링할 수 있습니다.
같은 파일, 두 크롤러
Googlebot6번째 줄전용 그룹. * 아래의 Allow: /는 읽히지 않습니다.
GPTBot2번째 줄지정한 그룹이 없어서 *를 읽습니다.
예시 파일은 가상의 사이트 www.example.org의 것입니다. 실제 robots.txt를 고장 난 예로 보여 주지 않습니다.

Allow와 Disallow: 가장 길게 일치하는 규칙이 이깁니다

하나의 URL에 규칙이 여러 개 일치하면, 종류와 상관없이 경로가 가장 긴 규칙이 이깁니다. Allow와 Disallow의 길이가 같으면 Allow가 이깁니다.

RFC 9309: “가장 구체적인 일치를 사용해야 한다(MUST). 가장 구체적인 일치란 옥텟 수가 가장 많은 일치를 말한다”, 그리고 “allow 규칙과 disallow 규칙이 동등하면 allow 규칙을 사용해야 한다(SHOULD).” Google도 같은 동작을 설명하며, 규칙이 충돌하면 “가장 제한이 적은 규칙”을 사용한다고 씁니다.

세는 단위는 문자가 아니라 옥텟(바이트)입니다. 한글이나 악센트가 붙은 글자, %2F가 들어간 경로는 퍼센트 인코딩을 거친 뒤 비교되는데, 단순한 도구들은 바로 여기서 틀립니다. 비교 대상은 경로와 쿼리뿐이고, 첫 글자부터 비교하며, 지시어 이름과 달리 대소문자를 구분합니다. Disallow: /File.pdf는 /file.pdf에 아무 영향도 주지 않습니다.

한 URL에 규칙 두 개가 일치: 경로가 긴 쪽이 이깁니다
/admin/report.pdf
  • Disallow: /admin/7자
  • Allow: /admin/report.pdf17자

Allow가 이깁니다. 경로와 더 많이 일치하기 때문입니다.

완전히 같은 길이
Disallow: /files/7자Allow: /files/7자

길이가 같으므로 Allow가 이깁니다. Google의 표현으로는 “가장 제한이 적은 규칙”입니다.

예시 파일은 가상의 사이트 www.example.org의 것입니다. 실제 robots.txt를 고장 난 예로 보여 주지 않습니다.

와일드카드는 `*`와 `$` 두 개뿐

*는 임의의 문자열을, $는 URL의 끝을 나타냅니다. 그 밖에는 없습니다. 정규 표현식도 없고, ?, ., [, +에도 특별한 의미가 없으며 모두 평범한 문자입니다.

$가 없는 규칙은 접두어 일치이므로, Disallow: /admin은 /administrator와 /admin-tools도 차단합니다. 폴더를 뜻한다면 끝에 슬래시를 붙이고(/admin/), 정확히 그 URL만 뜻한다면 $를 붙이세요. Disallow: /*.pdf$는 모든 PDF를, Disallow: /*?는 쿼리 문자열이 있는 모든 URL을 차단합니다.

위의 “URL 테스터”는 판정을 낸 것과 같은 매처로, 그 규칙이 함께 잡아내는 경로도 보여 줍니다. 의도보다 넓게 걸리는 규칙을 공개하기 전에 알아챌 수 있습니다.

*와 $, 각 패턴이 실제로 잡아내는 것
패턴일치불일치
/admin/admin/ · /administrator · /admin-tools/wp-admin
/admin//admin/users/administrator
/*.pdf$/files/report.pdf/report.pdf?v=2
/*?/search?q=x/search

?, ., [, +는 평범한 문자입니다. robots.txt에는 정규 표현식이 없습니다.

robots.txt 상태 코드는 무엇을 뜻하나요?

같은 고장 난 파일이라도 4xx와 5xx는 정반대 결과를 낳습니다. 4xx는 파일이 없는 것처럼 읽히므로 크롤러가 모든 것을 가져갈 수 있습니다. 5xx는 파일이 정의되지 않은 상태라는 뜻이므로, 표준을 따르는 크롤러는 아무것도 가져가면 안 됩니다.

RFC 9309 §2.3.1.3: 상태 코드가 파일이 “크롤러에게 사용할 수 없는 상태임을 나타내면, 크롤러는 서버의 어떤 리소스에도 접근할 수 있다(MAY)”. §2.3.1.4: “서버 또는 네트워크 오류로 인해 도달할 수 없으면… 크롤러는 완전한 차단을 가정해야 한다(MUST).” Google 크롤러는 “429를 제외한 모든 4xx 오류를 유효한 robots.txt 파일이 없는 것처럼 처리”하므로, 429는 5xx 쪽에 들어갑니다.

Google은 여기에 자체 단계를 두어 5xx의 경우를 누그러뜨립니다. 처음 12시간 동안은 크롤링을 멈추고, 이어지는 30일 동안은 마지막으로 정상이던 사본을 쓰며, 그 뒤에는 사이트의 나머지 부분이 정상이면 robots.txt가 아예 없는 것처럼 동작합니다. Google은 리다이렉트를 적어도 다섯 번 따라간 뒤 멈추고, “이를 robots.txt 파일의 404로 처리”합니다. 즉, 자유롭게 크롤링합니다. 그리고 DNS에서 찾을 수 없는 이름은 누군가를 차단하는 사이트가 아닙니다. 파일도 없고, 판정도 없습니다.

GET /robots.txt에 대한 각 응답이 사이트 전체에 뜻하는 것
서버 응답그러면 크롤러는
200파일의 규칙을 따릅니다.
301, 302리다이렉트를 적어도 다섯 번 따라간 뒤 멈춥니다. 그러면 Google은 파일을 404로 읽습니다.
403, 404파일이 없는 것처럼 모든 것을 크롤링합니다.
429아무것도 크롤링하지 않습니다. Google은 이를 4xx가 아니라 5xx 쪽으로 셉니다.
500, 503표준에 따라 아무것도 크롤링하지 않습니다.
존재하지 않는 이름읽을 사이트가 없으므로 판정도 없습니다.
5xx를 받은 Google의 대응, 시간 순서대로
  1. 1처음 12시간사이트 크롤링을 멈추고 파일을 계속 다시 요청합니다
  2. 230일까지마지막으로 정상이던 robots.txt 사본을 씁니다
  3. 330일 이후사이트가 정상이면 robots.txt가 없는 것처럼 동작합니다

robots.txt로 페이지를 Google 검색에서 뺄 수 있나요?

아니요. robots.txt는 크롤러에게 페이지를 가져가지 말라고 요청할 뿐, 검색엔진에게 목록에 올리지 말라고 요청하지 않습니다. Google은 크롤링이 허용되지 않는 페이지를 읽을 수 없지만, 다른 페이지가 그 페이지에 링크하면 “여전히 URL의 색인을 생성하여 스니펫 없이 검색 결과에 표시할 수 있습니다”.

그것이 Search Console의 상태 “robots.txt로 인해 차단되었으나 색인이 생성됨”입니다. “Google에서는 페이지를 요청하고 크롤링하지 않지만 차단된 페이지로 연결되는 페이지의 정보를 사용하여 색인을 생성할 수는 있습니다.” Google이 직접 제시하는 해결책은 “robots.txt 차단을 해제한 후 noindex를 사용하세요”입니다.

그래서 robots.txt에서 가장 흔한 실수는 한 줄이 아니라 한 쌍입니다. 여기서 차단되어 있으면서, 동시에 noindex가 붙은 URL입니다. Google은 분명히 말합니다. “robots.txt 파일로 페이지가 차단되거나… 크롤러는 noindex 규칙을 절대 확인하지 않으며 페이지가 검색 결과에 계속 표시될 수 있습니다.” 둘 중 하나를 고르세요. 크롤링을 차단하거나, 크롤러를 들여보낸 뒤 색인하지 말라고 알리거나입니다.

차단된 페이지가 Google에 여전히 나타나는 이유와, 그 noindex가 읽히지 않는 이유
  1. 크롤러
  2. robots.txt를 읽음
  3. URL이 차단되어 있음
  4. 페이지를 가져오지 않음
페이지 자체<meta name="robots" content="noindex">읽히지 않음
다른 사이트가 링크함
검색 색인설명 없이 URL만
Search Console의 표시robots.txt로 인해 차단되었으나 색인이 생성됨

페이지를 빼려면: 크롤러를 들여보내고 noindex를 쓰거나, 로그인을 요구하세요.

ChatGPT, Claude 같은 AI 크롤러는 어떻게 차단하나요?

평범한 그룹을 하나씩 쓰면 됩니다. AI 회사들도 검색엔진과 똑같이 제품 토큰을 공개하며, 대부분 크롤러를 여러 개 운영합니다. 학습용, 질문에 답하면서 출처 링크를 다는 답변용, 그리고 사람이 요청해서 페이지를 가져오는 크롤러입니다.

이 셋은 구분해 둘 만합니다. 학습용 크롤러를 차단하면 페이지가 모델에 들어가지 않습니다. 답변용 크롤러를 차단하면 그 서비스가 보여 주는 인용 출처에서도 빠집니다. 위의 “크롤러” 보기에는 각 크롤러의 목적, 토큰, 운영사 자체 문서가 밝히는 준수 여부가 있으므로, AI 답변에서 사라지지 않고 학습만 거부할 수 있습니다.

어떤 운영사는 한 사람을 대신해 페이지를 가져오는 크롤러가 robots.txt를 무시할 수 있다고 대놓고 말합니다. 크롤링하는 것이 아니라 사용자를 대신해 움직이기 때문이라는 것입니다. 표에는 그런 크롤러가 표시되어 있습니다. 또 점점 더 많은 사이트가 공개하는 Cloudflare의 Content-Signal 줄은 크롤링 규칙이 아니라 콘텐츠를 어디에 써도 되는지에 대한 선언입니다. 이 페이지는 그 줄을 오류로 처리하지 않고, 그대로 두고 설명합니다.

AI 크롤러의 세 가지 역할과, 각 운영사가 robots.txt에 대해 밝힌 내용
운영사학습AI 답변사용자 요청
OpenAIGPTBot준수OAI-SearchBot준수ChatGPT-User무시할 수 있음
AnthropicClaudeBot준수Claude-SearchBot준수Claude-User준수
Perplexity해당 크롤러 없음PerplexityBot준수Perplexity-User무시할 수 있음
GoogleGoogle-Extended토큰만해당 크롤러 없음해당 크롤러 없음
AppleApplebot-Extended토큰만해당 크롤러 없음해당 크롤러 없음
Metameta-externalagent준수meta-webindexer준수meta-externalfetcher무시할 수 있음
AmazonAmazonbot준수해당 크롤러 없음Amzn-User무시할 수 있음
  • 학습모델 학습용으로 페이지를 수집합니다.
  • AI 답변질문에 답하기 위해 페이지를 가져오며, 보통 사이트로 돌아오는 링크를 함께 답니다.
  • 사용자 요청누군가 요청해서 페이지 하나를 가져옵니다. 이 크롤러는 robots.txt를 무시할 수 있다고 밝힌 운영사도 있습니다.

Crawl-delay, Clean-param, Host, Content-Signal: 누가 무엇을 읽나요?

Google이 읽는 필드는 user-agent, allow, disallow, sitemap 네 가지뿐입니다. robots.txt의 나머지는 다른 누군가가 읽거나 아무도 읽지 않습니다. 그리고 알 수 없는 줄은 결코 오류가 아닙니다.

Google은 네 가지 필드를 나열하면서 “crawl-delay와 같은 다른 필드는 지원되지 않음”이라고 덧붙입니다. Bing은 Crawl-delay를 지원하며, Bing 자체 블로그에 따르면 “crawl-delay 지시어는 양의 정수만 값으로 받습니다”. Clean-param은 Yandex의 것이고, 다른 곳은 쓰지 않습니다. Host는 표준에도 Google의 목록에도 없습니다.

어느 것도 파일을 망가뜨리지 않습니다. RFC 9309는 다른 레코드의 파싱이 “명시적으로 정의된 레코드의 파싱을 방해해서는 안 된다(MUST NOT)”고 요구하므로, 크롤러는 모르는 줄을 건너뜁니다. 정말로 수명이 다한 지시어는 robots.txt 안의 noindex와 nofollow 두 가지입니다. Google은 2019년에 이를 처리하던 코드를 폐지했고, 지금의 Google에서는 아무 효과가 없습니다.

어느 검색엔진이 어느 지시어를 읽는가
지시어GoogleBingYandex
User-agent읽음읽음읽음
Allow읽음읽음읽음
Disallow읽음읽음읽음
Sitemap읽음읽음읽음
Crawl-delay무시읽음확인 안 됨
Clean-param무시무시읽음
Host무시무시확인 안 됨
noindex무시확인 안 됨확인 안 됨
Content-Signal무시확인 안 됨확인 안 됨
  • Google은 user-agent, allow, disallow, sitemap 네 가지 필드를 지원한다고 명시합니다.
  • Crawl-delay는 Bing 자체 블로그에서 확인됩니다. 현재 Bing 도움말 페이지를 1차 출처로 읽을 수 없었기 때문에, 값의 범위나 단위는 싣지 않습니다.
  • Google이 2019년에 폐지했으며, 표준에 포함된 적도 없습니다.
  • Cloudflare의 Content Signals Policy: 콘텐츠를 어떻게 써도 되는지에 대한 선언이며, 크롤링 규칙이 아닙니다.

500 KiB 한도와, 그 뒤로 넘어간 부분

Google은 robots.txt의 처음 500키비바이트만 읽고, 그 뒤는 어디에도 오류를 남기지 않고 모두 무시합니다. RFC 9309는 500 KiB를 크롤러 파싱 한도의 하한으로 정하고, Google은 이를 상한으로 명시합니다.

Google: “Google은 robots.txt 파일 크기를 500키비바이트(KiB)로 제한합니다. 최대 파일 크기를 넘는 콘텐츠는 무시됩니다.” 아무것도 경고해 주지 않습니다. 600 KiB 파일이 무효가 되는 것은 아닙니다. 마지막 100 KiB가 Googlebot에게는 그냥 존재하지 않을 뿐이고, 거기에 적힌 Disallow는 아무것도 보호하지 못합니다.

생각보다 많은 사이트가 이 한도에 닿습니다. 캠페인 파라미터마다, 패싯 필터마다, 오래된 스테이징 폴더마다 규칙을 하나씩 쓰다 보면 그렇습니다. 위의 검사는 파일을 이 선과 비교해 얼마나 넘는지 알려 줍니다. 긴 목록은 패턴(Disallow: /*?filter=)으로 바꾸고, 중요한 규칙은 맨 위에 두세요.

640 KiB짜리 robots.txt: 마지막 140 KiB는 Google에게 존재하지 않습니다
Google이 읽음경고 없이 무시
Disallow: /cart/ · 12번째 줄따름
Disallow: /private/ · 9,412번째 줄읽히지 않음

파일은 여전히 200을 응답하고 여전히 파싱됩니다. 나머지가 잘려 나갔다고 알려 주는 곳은 어디에도 없습니다.

흔한 robots.txt 실수와 찾는 방법

고장 난 robots.txt 파일은 대부분 여섯 가지 중 하나로 고장 나며, 무언가로 테스트하기 전까지는 어느 것도 드러나지 않습니다. 파일은 여전히 200을 응답하고, 여전히 파싱되며, 여전히 멀쩡해 보이기 때문입니다.

누구나 아는 것은 스테이징에서 운영으로 사이트를 공개할 때 남겨진 Disallow: /입니다. 나머지 다섯 가지는 이렇습니다. /administrator까지 잡아내는 Disallow: /admin처럼 의도보다 넓게 걸리는 규칙, 이름을 지정한 그룹 때문에 조용히 무시되는 * 아래의 Allow: /, 전체 주소가 아니라 경로로 적은 Sitemap: 줄, 앞에 슬래시가 없어 아무것에도 일치하지 않는 경로, 그리고 Google이 2019년에 읽기를 멈춘 noindex 줄입니다.

위에서 검사를 실행한 뒤 “문제” 보기를 읽으세요. 모든 지적 사항이 파일의 해당 줄에 붙어 있고, 해결 방법도 함께 있습니다. 감사가 아니라 파일 편집이 목적이라면, robots.txt 생성기가 바로 이 검사기로 이미 읽어 본 파일을 만들어 줍니다.

출처

robots.txt 실수 여섯 가지와, 각각이 실제로 일으키는 일
적힌 그대로의 줄실제로 일어나는 일
Disallow: /스테이징의 흔적: 운영 중인 사이트 전체가 모든 크롤러에 닫혀 있습니다.
Disallow: /admin/administrator와 /admin-tools도 차단합니다. 끝에 슬래시를 붙이세요.
User-agent: * 아래의 Allow: /파일 어디에든 전용 그룹이 있는 크롤러는 읽지 않습니다.
Sitemap: /sitemap.xmlSitemap 줄은 호스트가 포함된 전체 주소여야 합니다.
Disallow: admin경로는 /에서 시작합니다. 이 규칙은 아무것에도 일치하지 않습니다.
noindex: /private/2019년부터 무효입니다. 페이지는 계속 크롤링되고 색인될 수 있습니다.

robots.txt 테스터: 자주 묻는 질문

Google의 robots.txt 테스터는 어떻게 되었나요?

Google이 폐지했습니다. 2023년 11월 15일 Google 검색 센터가 Search Console의 robots.txt 보고서를 발표하면서 테스터 종료를 알렸고, 테스터는 그해 12월에 작동을 멈췄습니다. 이 보고서는 소유권을 확인한 사이트에 대해 Google이 가져온 파일을 크기, 문제 수와 함께 보여 주지만, 규칙에 대해 URL을 테스트할 수는 없습니다. 내 페이지가 차단되었는지는 URL 검사 도구로 알 수 있지만, 다른 사이트나 임의의 크롤러, 공개하려는 규칙을 확인하려면 별도의 테스터가 필요합니다.

User-agent: * 아래의 Allow: /가 무시되는 이유는 무엇인가요?

크롤러는 정확히 하나의 그룹만 따르기 때문입니다. 파일에 그 크롤러의 토큰을 지정한 그룹이 있으면 크롤러가 읽는 것은 그 그룹뿐이고, * 그룹은 완전히 건너뜁니다. 그 그룹은 대체용이지 추가분이 아닙니다. 그룹이 합쳐지는 것은 여러 그룹이 같은 토큰을 지정할 때뿐입니다. 위의 URL 테스터에서 크롤러별로 어느 그룹이 선택되었고 나머지는 왜 선택되지 않았는지 볼 수 있습니다.

robots.txt로 페이지의 색인을 막을 수 있나요?

아니요. robots.txt가 제어하는 것은 크롤링이지 색인이 아닙니다. Google은 한 번도 가져오지 않은 차단된 URL도, 그 URL에 링크하는 페이지의 텍스트를 이용해 목록에 올릴 수 있으며, 이때는 설명 없이 표시됩니다. Search Console은 이를 “robots.txt로 인해 차단되었으나 색인이 생성됨”이라고 부릅니다. 페이지를 검색 결과에서 빼려면 크롤러가 페이지를 가져가게 하고 noindex meta 태그나 X-Robots-Tag 헤더를 제공하거나, 페이지를 로그인 뒤에 두세요.

noindex가 작동하지 않는 이유는 무엇인가요?

가장 흔한 원인은 같은 URL이 robots.txt에서도 차단되어 있는 것입니다. 페이지를 가져가지 말라는 지시를 받은 크롤러는 noindex를 포함해 그 페이지의 어떤 내용도 보지 못하므로, 다른 곳의 링크를 통해 페이지가 계속 검색 결과에 나타날 수 있습니다. Google도 이를 분명히 말합니다. noindex가 효과를 내려면 페이지가 “robots.txt 파일로 차단되어서는 안 됩니다”. Disallow 줄을 지우고 noindex는 그대로 두세요.

robots.txt의 404는 무엇을 뜻하나요? 500은요?

정반대입니다. 404를 비롯한 4xx는 파일이 없는 것처럼 읽히므로, 크롤러는 사이트의 무엇이든 가져갈 수 있습니다. 이것이 RFC 9309 §2.3.1.3입니다. 500번대 응답은 파일이 없는 것이 아니라 도달할 수 없다는 뜻이며, §2.3.1.4에 따르면 크롤러는 그때 완전한 차단을 가정하고 아무것도 가져가서는 안 됩니다. Google은 429를 서버 오류 쪽에 넣고, 마지막으로 정상이던 사본을 30일 동안 쓴 뒤에야 그 사본을 버립니다.

Allow와 Disallow가 둘 다 일치하면 어느 쪽이 이기나요?

경로가 더 긴 쪽입니다. RFC 9309는 가장 구체적인 일치를 써야 한다고 정하고 그것을 옥텟으로 재며, Google도 같은 규칙을 설명합니다. 두 규칙이 정확히 같은 길이로 일치할 때에만 규칙의 종류가 결정하며, 그때는 Allow가 이깁니다. Google의 표현으로는 “가장 제한이 적은 규칙”입니다. 위의 테스터는 이긴 규칙과 진 규칙을 각각의 줄 번호와 함께 보여 줍니다.

robots.txt에서 쓸 수 있는 와일드카드는 무엇인가요?

두 가지뿐입니다. *는 임의의 문자열을, $는 URL의 끝을 나타냅니다. 나머지는 모두 글자 그대로입니다. ?, ., [, ], +는 그 문자 자체와 일치하고, 정규 표현식은 없습니다. $가 없는 규칙은 접두어 일치이므로 Disallow: /admin은 /administrator도 잡아냅니다. 경로는 대소문자를 구분하지만, Disallow 같은 지시어 이름은 구분하지 않습니다.

Google은 Crawl-delay를 지원하나요?

아니요. Google은 지원하는 필드로 user-agent, allow, disallow, sitemap 네 가지를 들고, crawl-delay 같은 필드는 지원하지 않는다고 분명히 밝힙니다. Bing은 읽습니다. Bing 자체 블로그에 따르면 이 지시어는 양의 정수만 받습니다. Crawl-delay 줄은 해가 없지만 Googlebot을 느리게 하지는 못하며, Search Console에도 이제 크롤링 속도 설정이 없습니다.

robots.txt 파일은 얼마나 커도 되나요?

Google은 처음 500키비바이트만 읽고 그 뒤는 아무 알림 없이 무시합니다. 오류도, Search Console의 경고도 없습니다. RFC 9309는 500 KiB를 크롤러가 반드시 파싱해야 하는 최소한으로 정하고, Google은 이를 자신의 최대치로 밝힙니다. 파일이 한도에 가깝다면 개별 URL의 긴 목록을 패턴으로 바꾸고, 중요한 규칙을 맨 위로 옮기세요. 이 검사기는 파일을 그 한도와 비교합니다.

GPTBot이나 ClaudeBot 같은 AI 크롤러는 어떻게 차단하나요?

검색엔진에 하듯이, 크롤러마다 전용 그룹을 만들고 Disallow: /를 적으세요. 대부분의 AI 회사는 역할이 다른 크롤러를 여러 개 운영합니다. 학습용, 질문에 답하면서 사이트로 돌아오는 링크를 다는 답변용, 그리고 한 사람을 대신해 페이지 하나를 가져오는 크롤러입니다. 위의 “크롤러” 보기에는 각 토큰과 목적, 운영사가 밝힌 준수 여부가 있으므로, AI 인용에서 빠지지 않고 학습만 거부할 수 있습니다.

robots.txt 확인 도구와 유효성 검사기는 같은 것인가요?

겹치는 부분이 있습니다. 유효성 검사기는 파일 자체만 봅니다. 구문, 알 수 없는 지시어, 잘못된 경로, 전체 주소가 아닌 Sitemap 줄 같은 것입니다. 확인 도구는 실제로 궁금한 질문에도 답합니다. 이 크롤러가 이 URL을 가져갈 수 있는지, 그리고 어느 규칙이 그렇게 정하는지입니다. 이 페이지는 둘 다 하며, 파일만으로는 알 수 없는 두 가지를 더합니다. 상태 코드가 뜻하는 바, 그리고 파일 중 얼마가 500 KiB 선을 넘는지입니다.

robots.txt는 보안 위험인가요?

robots.txt는 보안 장치가 아닙니다. 파일은 공개되어 있어 누구나 읽을 수 있으므로, Disallow: /admin-backup/ 같은 줄은 숨기고 싶었던 바로 그것을 가리키는 이정표가 됩니다. 그 안의 어떤 내용도 접근을 막지 못하며, 크롤러가 따르는 것은 운영사가 그렇게 하기로 정했기 때문일 뿐입니다. 비공개 경로는 인증이나 방화벽 규칙으로 보호하세요. 이 검사기는 파일 안에서 초대장처럼 읽히는 경로를 짚어 줍니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

크롤링과 색인에 관한 더 많은 도구