robots.txt 작성 기준 · 무엇을 막고 무엇을 열어야 하나

robots.txt는 사이트 루트에 두는 텍스트 파일로, 크롤러에게 어떤 경로를 요청해도 되는지 알려주는 접근 규칙이다. 막아야 할 것은 크롤링 자원을 낭비하는 경로다. 내부 검색 결과, 필터와 정렬 파라미터가 조합되며 무한히 늘어나는 URL, 장바구니와 로그인 같은 세션 경로, 그리고 스테이징 도메인 전체가 여기 해당한다. 열어야 할 것은 나머지 전부이고, 특히 CSS와 JS, 이미지처럼 페이지를 그리는 데 필요한 리소스와 sitemap은 반드시 열어야 한다. 검색 결과에서 페이지를 빼는 일은 robots.txt가 하는 일이 아니다. 그건 noindex 태그의 몫이고, robots.txt로 막힌 페이지는 오히려 noindex를 읽히지 못해 설명 없는 형태로 결과에 남는다.

robots.txt는 크롤링을 막지, 색인을 막지 않는다

이 문장을 정확히 이해하는 것이 나머지 모든 판단의 전제다. 크롤링과 색인은 다른 동작이다.

크롤링은 크롤러가 URL을 실제로 요청해서 내용을 가져오는 단계다. 색인은 가져온 내용을 검색 데이터베이스에 넣고 결과로 내보낼지 결정하는 단계다. robots.txt의 Disallow는 앞 단계에만 개입한다. "이 주소는 요청하지 마라"는 뜻이지 "이 주소를 결과에서 빼라"는 뜻이 아니다.

그래서 이런 일이 벌어진다. 외부 사이트나 내 사이트 안에서 그 URL로 링크가 걸려 있으면, 검색엔진은 내용을 못 읽은 채로도 그 주소가 존재한다는 사실은 안다. 결과 목록에 URL과 링크 텍스트만 덩그러니 뜨고 설명 자리에는 정보를 제공할 수 없다는 안내가 붙는다. 감추려던 페이지가 더 눈에 띄는 형태로 남는 셈이다.

결과에서 빼고 싶다면 순서가 반대다. 그 페이지를 크롤 가능하게 열어 두고, 페이지에 noindex 메타 태그를 넣거나 응답 헤더에 X-Robots-Tag를 넣는다. 크롤러가 페이지를 읽어야 noindex를 볼 수 있기 때문이다. 이미 색인된 페이지를 지우는 작업이라면 차단을 먼저 풀고, noindex가 반영된 것을 확인한 다음, 그 뒤에 필요하면 차단하는 순서로 간다.

파일은 어디에 있어야 하나

robots.txt는 호스트 루트에만 유효하다. https://example.com/robots.txt는 읽히지만 https://example.com/blog/robots.txt는 아무도 안 본다.

호스트가 다르면 파일도 다르다. www.example.com과 example.com은 별개이고, blog.example.com 같은 서브도메인도 별개다. 프로토콜과 포트가 다르면 역시 별개로 본다. 서브도메인 하나만 새로 띄우고 robots.txt를 안 올렸다면 그 호스트는 규칙이 없는 상태다.

형식은 UTF-8 평문이다. 실무에서 확인해야 할 것은 세 가지다. 응답 코드가 200인가, Content-Type이 text/plain인가, 본문이 실제 규칙인가.

세 번째가 특히 함정이다. SPA나 프레임워크의 catch-all 라우팅이 걸려 있으면 /robots.txt 요청에 200과 함께 HTML 페이지가 돌아온다. 브라우저로 열면 빈 화면처럼 보여서 잘 넘어가는데, 크롤러 입장에서는 규칙을 못 읽은 상태다. 200이 곧 파일 존재를 뜻하지 않는다.

파일이 아예 없어서 404가 나면 전체 허용으로 간주된다. 작은 사이트라면 그것도 정상 동작이다. 반대로 5xx가 계속 나면 크롤러는 규칙을 모르는 상태로 판단해 보수적으로 움직일 수 있으니, 서버 장애 중에 robots.txt만은 살아 있게 두는 편이 좋다.

지시어 레퍼런스: 무엇이 실제로 동작하나

문법은 짧다. 실제로 쓰이는 줄은 몇 종류가 전부다.

경로에는 두 가지 기호를 쓸 수 있다. *는 임의의 문자열, $는 URL의 끝을 뜻한다. Disallow: /*?sort=는 sort 파라미터가 붙은 모든 URL을 막고, Disallow: /*.pdf$는 .pdf로 끝나는 URL을 막는다.

경로는 대소문자를 구분한다. /Admin을 막았다고 /admin이 막히지 않는다. 그리고 규칙은 경로 앞부분 일치로 동작한다. Disallow: /pr은 /print도 /product도 같이 막는다. 의도한 게 아니라면 /pr/처럼 슬래시까지 붙여야 한다.

규칙 우선순위는 어떻게 결정되나

두 단계로 나뉜다. 먼저 어느 그룹을 볼지 정하고, 그다음 그룹 안에서 어느 줄을 따를지 정한다.

크롤러는 자기 이름이 적힌 그룹이 있으면 그 그룹만 읽는다. User-agent: *와 User-agent: Googlebot이 둘 다 있으면 Googlebot은 자기 그룹만 보고 * 그룹은 아예 무시한다. 그래서 공통 규칙을 *에만 적어 두고 특정 크롤러 그룹을 따로 만들면, 그 크롤러에게는 공통 규칙이 적용되지 않는다. 특정 그룹을 만들 때는 공통 규칙을 그 안에 복사해 넣어야 한다.

그룹 안에서는 더 구체적인 규칙이 이긴다. 구체성의 기준은 일치하는 경로 문자열의 길이다. 길이가 같으면 덜 제한적인 쪽, 즉 Allow가 이긴다.

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

이 설정에서 /reports/2026-q3/는 막히고 /reports/public/summary는 열린다. 두 번째 URL에는 두 규칙이 모두 걸리지만 Allow 쪽 문자열이 더 길기 때문이다. 순서는 상관없다. 위에 썼다고 먼저 적용되는 방식이 아니다.

개발용 Disallow 한 줄이 사이트를 지운다

robots.txt로 사이트가 통째로 사라지는 사고는 문법 실수에서 나오지 않는다. 스테이징에서 쓰던 파일이 그대로 프로덕션에 올라간 경우다.

User-agent: *
Disallow: /

두 줄이다. 이게 프로덕션에 올라가면 사이트 전체가 크롤 금지 상태가 된다.

무서운 점은 즉시 표가 안 난다는 것이다. 이미 색인된 페이지들은 한동안 결과에 남아 있다가 재크롤 주기를 따라 서서히 빠진다. 순위가 조금씩 내려가는 것처럼 보여서 콘텐츠 문제나 알고리즘 변동으로 오해하기 쉽다. 트래픽이 눈에 띄게 꺾여서 원인을 찾기 시작할 때는 이미 회복에 시간이 드는 상태다.

예방은 세 겹으로 건다. 첫째, robots.txt를 손으로 관리하는 정적 파일로 두지 말고 환경에 따라 생성한다. 둘째, 프로덕션 빌드 결과물에 Disallow: /가 있으면 빌드를 실패시킨다. 셋째, 배포 직후 스모크 체크에 robots.txt 응답 확인을 넣는다.

그리고 애초에 스테이징을 robots.txt로 가리는 것 자체가 약한 방법이다. robots.txt는 요청이지 잠금장치가 아니다. 스테이징은 basic auth나 IP 제한으로 막는 게 맞고, 그러면 robots.txt로 씨름할 일도 없다.

CSS와 JS를 막으면 렌더링이 깨진다

과거에는 정적 자원을 막는 게 크롤링 자원을 아끼는 요령처럼 이야기되던 시절이 있었다. 지금은 정반대다.

검색엔진은 페이지를 렌더링해서 판단한다. 사용자가 보는 화면과 같은 것을 봐야 콘텐츠 양, 레이아웃, 모바일 대응을 평가할 수 있다. /assets/, /static/, /_next/ 같은 경로를 통째로 막으면 크롤러는 스타일도 스크립트도 없는 상태로 페이지를 본다. 클라이언트에서 렌더링하는 화면이라면 본문 자체가 비어 보인다.

증상은 이렇게 나타난다. HTML 소스는 멀쩡한데 검색엔진 도구의 렌더링 미리보기에서 화면이 무너져 있거나 본문이 통째로 비어 있다. 이때 robots.txt부터 확인하면 대개 답이 나온다.

예외는 있다. 광고나 분석용 서드파티 스크립트는 본문 렌더링에 관여하지 않는 경우가 많다. 다만 그런 스크립트는 대부분 다른 도메인에 있어서 내 robots.txt로는 어차피 통제되지 않는다. 결론적으로 자기 도메인의 정적 자원은 그냥 열어 두는 게 맞다.

무엇을 막고 무엇을 열어야 하나

경로 유형별로 정리하면 판단이 빨라진다.

마지막 세 줄이 중요하다. robots.txt는 누구나 읽을 수 있는 파일이다. 숨기고 싶은 경로를 여기에 적는 것은 지도에 표시하는 것과 같다. 접근 통제는 서버에서 해야 한다.

AI 크롤러는 어떻게 다룰 것인가

지금 robots.txt를 다시 손보게 만드는 새 변수는 AI 크롤러다. 막았을 때 실제로 무엇이 사라지는지, 인용 여부를 어떻게 확인하는지는 AI 답변 인용 확인 기준에 정리했다. 여기서 먼저 나눠야 할 것은 학습용 수집과 실시간 인용용 수집이다.

학습용 크롤러는 모델 학습 데이터를 모은다. 막아도 오늘의 트래픽은 변하지 않는다. 실시간 인용용 크롤러는 사용자가 질문했을 때 답을 만들기 위해 그 자리에서 페이지를 가져간다. 이쪽을 막으면 AI 답변에 내 사이트가 인용되지 않고, 답변에 붙는 출처 링크에서 오던 유입도 사라진다.

아래 표는 각 사업자가 자사 문서에 공개한 토큰을 정리한 것이다. 이 글이 근거로 삼은 구글 문서의 범위 밖이므로, 그대로 신뢰하지 말고 확인 후 쓰는 것을 전제로 읽는 게 맞다.

크롤러 이름은 사업자가 바꾸거나 새로 추가한다. 표를 그대로 붙여넣기보다 각 사업자 문서에서 현재 토큰을 확인하고, 서버 로그에서 실제로 오는 User-Agent 문자열을 보는 편이 정확하다. 로그에 안 찍히는 크롤러를 막는 규칙은 아무 일도 하지 않는다.

판단 기준은 사업 모델이다. 콘텐츠가 유입을 만드는 자산이면 인용용 크롤러는 열어 두는 쪽이 이득이다. 콘텐츠 자체를 파는 사업이라면 학습용 수집을 막는 결정이 합리적이다. 이건 정답이 하나인 문제가 아니라서, 읽는 사람의 사업 구조를 모르면 대신 정해 줄 수 없다.

한 가지는 분명하다. robots.txt는 신사협정이다. 규칙을 지키는 크롤러만 지킨다. 정말 막아야 한다면 서버 단에서 User-Agent와 IP 기준으로 차단해야 한다.

Google-Extended를 막아도 검색 순위는 그대로다

이 부분이 가장 많이 오해된다.

Google-Extended는 구글의 AI 제품이 내 콘텐츠를 쓰는 것을 통제하는 토큰이다. 구글은 이것을 검색 색인·순위와 분리된 통제 수단으로 안내하고 있다. 이 토큰을 막는 일과 검색에서 내려가는 일은 별개의 사건이라는 뜻이다.

반대 방향도 마찬가지다. 이 토큰을 막았다고 검색 결과 안의 AI 요약 표면에서 자동으로 빠진다고 단정할 수는 없다. 그 표면은 검색 색인을 재료로 삼는 쪽에 가깝기 때문이다. 거기서까지 확실히 빼려면 검색 색인 자체에서 빠지는 선택이 필요한데, 그건 대부분의 사업에서 손해다. 다만 이 경계는 구글이 정책을 갱신하면 달라질 수 있는 영역이라, 차단을 결정하기 전에 현재 문서를 다시 확인하는 편이 안전하다.

정리하면 이렇다. Googlebot을 막는 것은 검색을 포기하는 결정이다. Google-Extended를 막는 것은 AI 학습 사용을 거절하는 결정이다. 두 줄은 이름이 비슷하지만 결과가 완전히 다르다.

sitemap은 robots.txt에서 선언한다

sitemap 줄은 그룹과 무관하게 전역으로 읽히므로 파일 맨 위나 맨 아래 어디에 둬도 된다. 여러 줄을 넣을 수도 있다.

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

실수는 거의 항상 URL 자체에서 난다. 상대 경로를 쓰거나, http로 적거나, www 유무가 실제 서비스 호스트와 어긋나는 경우다. 특히 www 불일치는 오류처럼 보이지 않은 채로 사이트맵의 URL이 처리되지 않는 형태로 넘어가기 쉽다. 선언한 주소를 브라우저가 아니라 curl로 직접 열어서 XML이 오는지 확인하는 게 확실하다.

증상별 흔한 실수

문제를 뒤에서부터 찾아 들어갈 때 쓰는 표다.

검증은 어떻게 하나

세 단계면 충분하다.

첫째, 파일이 제대로 서빙되는지 본다.

curl -sI https://example.com/robots.txt
curl -s https://example.com/robots.txt

헤더에서 200과 text/plain을 확인하고, 본문이 HTML이 아니라 규칙 텍스트인지 눈으로 본다.

둘째, 검색엔진이 어떻게 해석하는지 본다. 서치 콘솔의 robots.txt 리포트에서 마지막으로 가져간 버전과 파싱 결과를 볼 수 있고, URL 검사에서 개별 주소가 크롤 허용 상태인지 확인할 수 있다. 내가 의도한 해석과 도구의 해석이 다르면 도구가 맞다.

셋째, 실제 접근 로그를 본다. 규칙을 넣은 뒤 그 경로에 대한 크롤러 요청이 실제로 줄었는지 확인한다. 로그를 안 보면 오지도 않는 봇을 막아 놓고 만족하는 상태가 되기 쉽다.

여기에 하나 더 붙이면 좋다. 배포 파이프라인에 robots.txt 응답 확인을 넣어 두는 것이다. 사람이 기억으로 지키는 규칙은 언젠가 깨지고, robots.txt는 깨졌을 때 비용이 큰 축에 속한다.

규모별로 기본형은 어떻게 다른가

작은 사이트일수록 파일이 짧아야 한다. 막을 게 없는데 규칙만 늘리면 실수 확률만 올라간다.

페이지가 수십 개인 서비스나 블로그라면 sitemap 한 줄과 로그인 관련 경로 정도면 충분하다. 상품 목록에 필터가 붙는 커머스라면 파라미터 조합 차단이 실질적인 효과를 낸다. 콘텐츠가 자산인 미디어라면 AI 크롤러 정책을 명시적으로 정해 두는 편이 낫다.

공통으로 지킬 것은 두 가지다. 정적 자원은 열어 둔다. 그리고 Disallow: /는 프로덕션에 존재할 수 없는 문자열로 취급한다.

자주 묻는 질문

robots.txt가 아예 없으면 문제가 되나요?

기술적으로는 문제가 없습니다. 파일이 없으면 전체 허용으로 간주되므로 작은 사이트라면 그대로 두어도 정상 동작합니다. 다만 sitemap을 알리는 자리가 사라지고, 나중에 막을 경로가 생겼을 때 급하게 만들다가 실수하기 쉽습니다. sitemap 한 줄만 있는 최소 파일이라도 두는 편을 권합니다.

이미 색인된 페이지를 검색 결과에서 빼려면 어떻게 해야 하나요?

robots.txt로 막는 것은 잘못된 선택입니다. 크롤러가 페이지를 읽지 못하면 noindex도 읽지 못하기 때문에 오히려 결과에 더 오래 남습니다. 해당 페이지를 크롤 가능하게 열어 두고 noindex 메타 태그나 X-Robots-Tag 헤더를 넣은 뒤, 재크롤이 일어나 결과에서 빠지는 것을 확인하고 나서 필요하면 차단을 거는 순서로 진행합니다.

AI 크롤러를 전부 막으면 트래픽에 어떤 영향이 있나요?

학습용 크롤러만 막는 경우 당장의 검색 트래픽은 변하지 않습니다. 반면 실시간 인용용 크롤러까지 막으면 AI 답변에 인용되지 않고 거기서 오던 링크 유입이 사라집니다. 콘텐츠가 유입을 만드는 자산인지 판매 대상인지에 따라 답이 갈리므로, 상황을 모르는 상태에서 일괄 차단을 권하기는 어렵습니다.

robots.txt를 수정하면 언제 반영되나요?

즉시 반영되지 않습니다. 크롤러는 robots.txt를 가져가 캐시해 두고 주기적으로 다시 읽기 때문에, 수정 직후 얼마간은 이전 규칙으로 동작한다고 보는 편이 안전합니다. 급하게 차단을 풀어야 하는 상황이라면 서치 콘솔에서 최신 버전을 다시 가져가도록 요청하고, 그 사이에도 이전 규칙이 적용될 수 있다는 점을 감안해 일정을 잡으시기 바랍니다.

워드프레스나 노션처럼 파일을 직접 만들 수 없는 환경에서는 어떻게 하나요?

플랫폼이 robots.txt를 자동으로 생성하는 경우가 대부분이고, 관리자 화면에서 일부 항목만 편집하도록 열어 둔 경우가 많습니다. 먼저 자기 도메인의 robots.txt를 직접 열어 현재 내용을 확인하시고, 편집 기능이 없다면 개별 페이지의 noindex 설정이나 사이트 공개 범위 설정으로 같은 목적을 달성할 수 있는지 검토하시면 됩니다.

참고 자료

• robots.txt 소개 및 가이드 — 크롤링 제어와 색인 제외가 다른 동작이라는 점, 차단된 페이지가 결과에 남을 수 있다는 점을 설명한 공식 문서
• robots.txt 파일 작성 및 제출 — 지시어 문법, 파일 위치 요건, 가장 구체적인 규칙이 우선한다는 우선순위 규칙에 대한 공식 문서