URL이 robots.txt에 의해 차단됨: 맞는 경우와 손해인 경우

'URL이 robots.txt에 의해 차단됨'(URL blocked by robots.txt)은 robots.txt 파일의 규칙이 URL을 허용하지 않아 Google이 크롤링하지 않았고, 그 URL이 색인에 없다는 뜻입니다. 대부분의 사이트에서 이 상태는 올바릅니다. 관리자 영역, 장바구니, 사이트 내부 검색, 매개변수 URL은 의도적으로 차단됩니다. 손해가 생기는 것은 규칙이 검색에 나오기를 원하는 페이지까지 잡아낼 때뿐이며, 할 일은 의도적으로 차단한 URL들 사이에서 그런 페이지를 찾아내는 것입니다.

2022년까지 Search Console의 색인 생성 범위 상태 보고서는 이 상태에 2가지 이름을 썼습니다. 제출한 사이트맵에 나열된 URL에는 '제출된 URL이 robots.txt에 의해 차단됨', 나머지에는 'robots.txt에 의해 차단됨'입니다. 독일어의 경우 현재 Google 도움말 문서는 이 상태를 "URL wird von der robots.txt-Datei blockiert"로 표시하며, 예전 이름은 "Durch robots.txt-Datei blockiert"였습니다. 보고서에 "Indexiert, obwohl durch robots.txt-Datei blockiert"('robots.txt로 인해 차단되었으나 색인이 생성됨')로 표시된다면 차단에도 불구하고 URL이 색인에 들어 있는 것이며, 그 상태는 별도 가이드에서 다룹니다.

Google이 설명하는 이 상태의 의미

Google의 페이지 색인 생성 보고서 문서(2026년 10월 확인)는 'URL이 robots.txt에 의해 차단됨'을 '색인이 생성되지 않음' 아래에 두고, 사이트의 robots.txt 파일이 페이지를 차단했다고 설명합니다. 같은 문서는 '색인이 생성되지 않음' 그룹 전체를 소개하면서 이 페이지들이 색인되지 않았지만 "반드시 오류 때문은 아니"라고 말합니다.

차단은 귀하의 결정에 2가지 영향을 줍니다.

• 차단은 크롤링을 막을 뿐, 색인 생성을 막지는 않습니다. Google 문서는 차단이 페이지가 색인에서 빠져 있으리라는 보장은 아니라고 덧붙입니다. 다른 페이지의 링크처럼 페이지를 불러오지 않고도 정보를 찾으면, 낮은 확률이지만 결국 색인되어 'robots.txt로 인해 차단되었으나 색인이 생성됨'으로 옮겨 갈 수 있습니다.
• Google은 페이지를 전혀 보지 못합니다. 제목도, 콘텐츠도, 페이지 안의 링크도, 표준 태그도, noindex도 보지 못합니다. 규칙이 있는 동안에는 페이지가 스스로에 대해 무엇을 말하든 보이지 않습니다.

문제인가요? 의도한 차단과 실수를 가려내기

페이지 색인 생성 보고서 상단의 필터부터 시작합니다. '알려진 모든 페이지'에서 '제출된 모든 페이지'로 바꾸십시오. '제출된 모든 페이지'에 나타나는 차단된 URL은 귀하가 제출한 사이트맵에 들어 있는 URL입니다. robots.txt로 크롤링을 금지하면서 Google에 색인을 요청하고 있는 셈입니다. 규칙의 의도가 무엇이었든 이 모순은 거의 언제나 실수입니다.

2026년 5월부터 10월 사이에 SEOReport 감사를 위해 제출되어 사이트맵 페이지를 가져온 외부 웹사이트 29곳 중 2곳(7%)은 자체 robots.txt가 허용하지 않는 URL을 사이트맵에 넣어 두었습니다. 가장 흔한 사이트맵 문제는 아니지만, 사이트가 이미 중요하다고 밝힌 페이지를 차단한다는 점에서 따로 볼 만한 문제입니다.

실수 패턴과 수정 전후

아래 패턴은 모두 작성된 그대로 작동했지만 의도보다 더 많이 차단한 규칙입니다.

1. 그대로 배포된 스테이징 파일. 개발 사이트는 전체가 차단되어 있고, 그 파일이 나머지 빌드와 함께 운영 환경으로 넘어갑니다.

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

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

2. 너무 짧은 접두사. Google은 URL 경로의 시작 부분부터 규칙을 일치시키므로, Disallow: /search는 /search?q=shoes뿐 아니라 실제 아티클인 /search-engine-basics/도 차단합니다.

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. 랜딩 페이지까지 잡아내는 와일드카드. *는 임의의 문자열과 일치하며, Google의 일치 판정에는 쿼리 문자열도 포함됩니다. Disallow: /*?는 매개변수가 있는 모든 URL을 차단하며, 여기에는 제품이 발견되도록 크롤링되기를 원할 수 있는 /shoes/?page=2 같은 페이지 나누기 카테고리 페이지도 포함됩니다.

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

파일 확장자에도 같은 함정이 있습니다. 페이지가 .php로 끝나는 사이트에서 Disallow: /*.php는 카탈로그 전체를 차단합니다.

4. 잊혀진 Googlebot 그룹. Google의 robots.txt 사양에 따르면 크롤러는 자신을 지칭하는 가장 구체적인 그룹 하나만 따르며, 구체적인 그룹과 * 그룹은 합쳐지지 않습니다. 몇 년 전 이전 작업 때 작성한 User-agent: Googlebot 그룹이 계속 Googlebot에 적용되는 동안, 팀은 * 그룹만 편집하면서 차단의 원인을 설명하지 못합니다.

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

해결책은 옛 그룹을 삭제하거나 현재 규칙을 그 그룹에 복사하는 것입니다. 같은 규칙이 AI 크롤러 정책의 흔한 부작용도 설명합니다. 특정 봇을 위한 이름 있는 그룹을 추가한 사이트는 공통 규칙을 그룹마다 반복해야 합니다. 검색 규칙과 AI 규칙을 분리해 두는 패턴은 robots.txt와 AI 크롤러 결정표에서 보여 줍니다.

5. 차단된 렌더링 리소스. Disallow: /assets/나 Disallow: /static/은 페이지가 불러오는 CSS와 JavaScript를 차단합니다. Google의 robots.txt 소개 문서는 중요하지 않은 리소스는 차단해도 되지만, 없을 때 Google이 페이지를 이해하기 어려워지는 리소스는 차단하면 안 된다고 말합니다. 이런 차단된 파일은 페이지 색인 생성 보고서에 페이지로 나타나는 경우가 드물므로, 페이지 쪽에서 찾아야 합니다. URL 검사에서 실시간 테스트를 실행하고 '테스트한 페이지 보기'에서 '추가 정보'를 열면 Google이 불러온 페이지 리소스를 볼 수 있습니다. 애셋 호스트도 확인하십시오. robots.txt는 호스트, 프로토콜, 포트별로 적용되므로 cdn.example.com에서 제공되는 파일은 그 호스트의 robots.txt를 따릅니다. 페이지 콘텐츠를 만드는 스크립트가 차단되는 문제는 브라우저에서 렌더링하는 사이트에서 가장 중요하며, 이는 JavaScript 렌더링 가이드에서 다룹니다.

robots.txt 규칙을 URL로 테스트하는 방법

Google의 결정을 예측하는 데 도구는 필요 없습니다. Google 사양에 따르면 4단계면 됩니다.

flowchart TD
    A["테스트할 URL"] --> B["같은 호스트와 프로토콜의 robots.txt 열기"]
    B --> C{"Googlebot용 그룹이 있나요?"}
    C -->|예| D["그 그룹만 사용"]
    C -->|아니요| E["* 그룹 사용"]
    D --> F["경로와 일치하는 Allow와 Disallow를 모두 나열"]
    E --> F
    F --> G{"일치하는 규칙이 있나요?"}
    G -->|아니요| H["허용됨"]
    G -->|예| I["경로가 가장 긴 규칙이 우선"]
    I --> J{"Allow와 Disallow의 길이가 같나요?"}
    J -->|예| H
    J -->|아니요| K["가장 긴 규칙 적용"]

1. 파일을 고릅니다. URL과 정확히 같은 호스트와 프로토콜의 /robots.txt를 엽니다. https://www.example.com/robots.txt는 https://shop.example.com/에 적용되지 않습니다.
2. 그룹을 고릅니다. Googlebot과 일치하는 가장 구체적인 User-agent 그룹을 사용합니다. User-agent 이름은 대소문자를 구분하지 않습니다.
3. 일치하는 규칙을 찾습니다. 규칙의 경로가 URL 경로와 쿼리의 시작 부분과 일치하면 그 규칙이 적용됩니다. *는 임의의 문자와 일치하고, $는 URL의 끝을 나타내며, 경로는 대소문자를 구분합니다. /Shop/은 /shop/과 일치하지 않습니다.
4. 우선하는 규칙을 고릅니다. 경로가 가장 긴 규칙이 우선합니다. Allow와 Disallow의 길이가 같으면 Google은 덜 제한적인 쪽, 즉 Allow를 사용합니다.

패턴 3의 '수정 후' 파일에 Disallow: /search를 더해 이 방법을 적용하면 다음과 같습니다.

귀하의 해석이 아니라 Google의 해석을 확인하려면 해당 URL로 URL 검사를 실행하십시오. 크롤링 세부정보의 '크롤링 허용 여부'는 robots.txt 규칙이 Google을 차단하는지 보여 주며, 실시간 테스트는 Google이 지금 가져올 수 있는 파일을 적용합니다. Google은 robots.txt 파서를 오픈소스 라이브러리로도 공개하고 있어, 개발자가 배포 전에 초안 파일로 실행해 볼 수 있습니다.

규칙을 고친 뒤 확인하기

크롤링되기를 원하는 페이지가 더 이상 일치하지 않도록 파일을 수정합니다. 넓은 Disallow를 좁히거나, 예외를 위해 더 긴 Allow를 추가하거나, 남아 있는 옛 그룹을 제거합니다. 그다음 다음을 진행합니다.

1. 실제 파일을 가져와 캐시된 사본이나 빌드 시점의 사본이 아니라 수정한 내용이 제공되는지 확인합니다: curl -s https://www.example.com/robots.txt.
2. Search Console의 robots.txt 보고서에서 robots.txt 재크롤링을 요청합니다. Google은 일반적으로 파일을 최대 24시간 동안 캐시하며, 보고서 도움말은 중요한 URL의 차단 해제를 재크롤링 요청 사유로 꼽습니다. 보고서에는 Google이 파일을 마지막으로 가져온 시점과 오류나 경고가 표시되며, 오류가 있는 줄은 무시됩니다.
3. 영향을 받은 URL 2개 또는 3개로 URL 검사의 실시간 테스트를 실행합니다. '크롤링 허용 여부'가 이제 '예'로 표시되어야 합니다. 가장 중요한 페이지에는 '색인 생성 요청'을 사용하십시오. Google 도움말에 따르면 색인 생성에는 최대 1~2주가 걸릴 수 있습니다.
4. '수정 결과 확인'을 클릭합니다. 규칙을 고친 뒤 페이지 색인 생성 보고서의 해당 문제에서 클릭하십시오. Google 문서에 따르면 확인에는 보통 최대 약 2주가 걸리며 훨씬 더 오래 걸릴 수도 있습니다.

재크롤링에 관한 Google 도움말에 따르면 크롤링에는 며칠에서 몇 주가 걸릴 수 있으므로, 수치는 서서히 줄어들 것으로 예상하십시오. 그 뒤에도 보고서에 남는 URL은 의도적으로 차단한 URL이어야 합니다.

몇 달 동안 숨겨져 있던 페이지의 차단을 풀기 전에, 크롤러가 볼 방식대로 상태 코드, robots 메타 태그, 표준 태그를 확인하십시오. 아무도 크롤링할 수 없었던 페이지에는 잊혀진 noindex가 남아 있을 수 있으며, 그러면 페이지는 곧바로 'URL이 'NOINDEX'로 표시됨'으로 옮겨 갑니다. 이런 신호의 상호작용은 색인 생성 가능성 충돌 분석에서 다룹니다.

Search Console은 어떤 URL이 차단되었는지 알려 줍니다. SEOReport 전체 진단은 사이트맵에 나열된 페이지를 robots.txt 규칙과 대조해, 검색엔진에 찾으라고 하면서 크롤링하지 말라고 하는 페이지를 짚어 냅니다. 사이트 전체 차단과 robots.txt 누락도 표시합니다. 모든 크롤러를 대상으로 작성된 규칙을 읽으므로, Googlebot 전용 그룹은 여전히 URL 검사로 확인해야 합니다.

자주 묻는 질문

차단된 URL이 많으면 사이트에 해가 되나요?

그 자체로는 아닙니다. 차단된 매개변수 URL이나 검색 URL이 수천 개라는 것은 robots.txt가 제 역할을 하고 있다는 신호입니다. 사이트맵에 나열된 차단 URL과 순위에 올리고 싶은 차단 페이지의 수를 세어 보십시오. 손해를 주는 것은 그것들뿐입니다.

robots.txt가 없거나 오류를 반환하면 어떻게 되나요?

Google 사양은 404 또는 기타 4xx 응답(429 제외)을 robots.txt가 없는 것으로 취급하므로, 아무것도 차단되지 않습니다. 5xx 오류는 다릅니다. Google은 처음 12시간 동안 사이트 크롤링을 멈춘 뒤, 최대 30일 동안 마지막으로 정상이었던 사본을 사용합니다. Google은 이 파일의 시간 초과와 DNS 오류도 같은 방식으로 처리하므로, 시간 초과가 나는 robots.txt는 차단 규칙이 전혀 없는 사이트의 크롤링도 멈추게 할 수 있습니다.

차단된 URL은 사이트맵에서 빼야 하나요?

예. 사이트맵은 색인을 원하는 URL 목록이므로 robots.txt가 차단하는 URL이 하나도 들어 있으면 안 됩니다. 의도적으로 차단한 URL은 사이트맵에서 빼고, 실수로 차단한 URL은 차단을 푸십시오. 이 파일에 무엇이 더 들어가야 하는지는 XML 사이트맵 가이드에서 다룹니다.

robots.txt로 페이지를 Google에서 삭제할 수 있나요?

아닙니다. robots.txt는 크롤링을 제어하며, Google은 다른 페이지가 링크하는 차단된 URL을 여전히 색인할 수 있습니다. 페이지를 검색에서 빼려면 Google이 크롤링하도록 허용하고 noindex를 추가하십시오. 어떤 도구가 어떤 일을 하는지는 robots.txt와 크롤링 접근 가이드에서 설명합니다.

하위 도메인이나 HTTP의 robots.txt가 기본 사이트에 영향을 주나요?

아닙니다. 호스트, 프로토콜, 포트의 조합마다 별도의 파일이 있으며, Google은 하위 디렉터리에 둔 robots.txt 파일은 읽지 않습니다. staging.example.com의 차단 파일은 www.example.com을 차단할 수 없지만, 애셋 호스트나 CDN 호스트의 robots.txt는 Google이 페이지가 불러오는 파일을 가져올 수 있는지를 실제로 결정합니다.