robots.txt 설정 가이드: Google·네이버·AI 크롤러를 목적별로 제어하는 법
robots.txt는 크롤링 요청을 관리하는 파일입니다. 색인 제외·비공개·AI 학습 거부를 같은 규칙으로 처리하지 말고 크롤러와 목적별로 분리해야 합니다.
robots.txt의 역할은 검색로봇이 어떤 URL을 요청해도 되는지 알려주는 것입니다. 검색 결과에서 페이지를 지우는 도구나 비밀 문서를 보호하는 보안 장치는 아닙니다.
한 파일에 모든 봇을 일괄 차단하면 검색 수집, 이미지 노출, 광고 검증, 링크 미리보기까지 예상 밖으로 멈출 수 있습니다. 먼저 허용할 검색로봇과 제한할 자동 수집기를 구분하고, URL 패턴이 실제 사이트 구조와 맞는지 작은 범위에서 확인해야 합니다.
크롤러 제어 목적부터 네 가지로 나눕니다
| 목적 | 적합한 수단 | 주의할 점 |
|---|---|---|
| 검색로봇의 불필요한 URL 수집 감소 | robots.txt의 Disallow | 차단 URL은 meta robots를 읽지 못할 수 있음 |
| 검색 결과에서 페이지 제외 | meta robots noindex 또는 X-Robots-Tag | 크롤러가 지시를 읽을 수 있어야 함 |
| 회원 전용·민감 정보 보호 | 로그인·인증·접근 제어 | robots.txt에 경로를 적는 것만으로 보호되지 않음 |
| 특정 AI 크롤러 정책 적용 | 해당 사업자가 공개한 user-agent 규칙 | AI 검색 노출과 학습 수집이 같은 개념인지 확인 |
같은 URL에 robots.txt 차단과 noindex를 동시에 걸면 크롤러가 noindex를 확인하지 못할 수 있습니다. 이미 검색에 나타난 URL을 제외하려면 접근을 허용한 상태에서 noindex를 읽히거나, 콘텐츠를 삭제하고 올바른 상태 코드를 반환하는 방식이 더 명확합니다.
사이트 루트와 응답 상태를 먼저 확인합니다
robots.txt는 일반적으로 호스트의 루트 경로인 https://example.com/robots.txt에서 제공해야 합니다. www와 비www, HTTP와 HTTPS, 서브도메인은 서로 다른 호스트이므로 실제 대표 호스트에서 파일이 200 응답과 일반 텍스트로 열리는지 확인합니다.
워드프레스 플러그인이나 CDN이 파일을 동적으로 만들 수 있습니다. 관리자 화면의 입력값만 보지 말고 외부 네트워크에서 최종 응답을 확인하세요. 리디렉션, 캐시된 구버전, HTML 오류 페이지가 섞이면 작성한 규칙과 실제 제공 파일이 달라집니다.
curl -i https://example.com/robots.txt
curl -i https://www.example.com/robots.txtUser-agent 그룹은 좁고 명확하게 작성합니다
User-agent: *는 별도 그룹이 없는 크롤러에 적용되는 기본 규칙입니다. Googlebot, 네이버 Yeti, 공개된 AI 크롤러를 다르게 운영하려면 각각의 공식 user-agent 이름과 정책 문서를 확인한 뒤 독립된 그룹으로 작성합니다.
운영자가 이름을 추측해 만든 user-agent는 아무 효과가 없을 수 있습니다. 또한 요청 헤더의 user-agent는 위조될 수 있으므로 서버 보안이나 과금 통제는 robots.txt가 아니라 방화벽·인증·요청 제한으로 처리해야 합니다.
User-agent: *
Disallow: /internal-search/
Disallow: /preview/
Sitemap: https://example.com/sitemap.xmlURL 패턴은 실제로 생성되는 주소를 기준으로 설계합니다
관리자 경로, 내부 검색 결과, 장바구니 단계처럼 검색 가치가 낮은 URL을 먼저 목록화합니다. 단순히 폴더 이름만 보고 차단하지 말고 서버 로그와 크롤링 보고서에서 어떤 쿼리 문자열과 경로가 반복 요청되는지 확인합니다.
한 줄의 Disallow: /는 해당 그룹에 사이트 전체 차단을 뜻합니다. 배포 전에는 스테이징 호스트에서 테스트하고, 운영 반영 후에는 대표 페이지·이미지·CSS·JavaScript가 계속 접근 가능한지 URL 단위로 검증합니다.
Google과 네이버 도구에서 각각 검증합니다
Google Search Console의 robots.txt 보고서와 URL 검사 도구는 Googlebot 관점의 접근 가능성을 확인하는 데 사용합니다. 네이버는 Search Advisor의 robots.txt 수집·검증 기능에서 Yeti가 규칙을 해석하는지 별도로 확인합니다.
두 검색엔진이 같은 표준을 참고하더라도 지원 범위와 수집 도구는 다를 수 있습니다. 한쪽에서 성공한 테스트를 다른 쪽 결과로 간주하지 말고, 주요 URL 표본을 검색엔진별로 점검합니다.
변경은 로그·색인·서버 부하를 함께 보며 평가합니다
robots.txt 변경 직후 크롤 요청이 즉시 사라진다고 가정하지 마세요. 파일 재수집 시점과 기존 큐에 따라 변화가 늦을 수 있습니다. 변경 전후 2~4주의 서버 로그에서 차단 대상 요청 수, 중요한 URL의 발견 속도, 4xx 비율을 비교합니다.
검색 노출 감소가 나타났다면 크롤 차단 때문인지, noindex·canonical·내부 링크 변경이 함께 배포됐는지 분리해야 합니다. 규칙을 한 번에 크게 바꾸지 않고 경로 그룹별로 적용하면 롤백 원인을 찾기 쉽습니다.
안전한 배포와 롤백 절차를 남깁니다
배포 전 현재 파일을 저장하고 변경 이유, 대상 user-agent, 예상 효과, 확인할 URL을 기록합니다. 실수로 전체 차단이 발생하면 즉시 이전 파일로 되돌리고 CDN 캐시를 비운 뒤 검색엔진 도구에서 다시 수집을 요청합니다.
robots.txt는 짧을수록 좋다는 규칙보다 유지관리 가능성이 중요합니다. 주석을 적절히 사용하고, 더 이상 존재하지 않는 경로 규칙과 중복 그룹을 정기적으로 정리하세요.
robots.txt 변경 이력을 운영 자산으로 남깁니다
변경 전에는 현재 robots.txt 원문, 대표 user-agent별 허용·차단 URL 20개, 서버 로그의 크롤 요청 수와 4xx 비율을 같은 표에 저장합니다. 기준값이 없으면 이후 변화가 수정 효과인지 계절성·수요·배포 환경 차이인지 구분하기 어렵습니다. 표본 URL과 수집 시각, 사용한 도구 버전까지 남겨 다른 담당자가 같은 결과를 재현할 수 있게 합니다.
배포 기록에는 변경한 규칙·배포 시각·CDN 캐시 무효화 시각·검증 도구 결과을 적고, 관찰 단계에서는 중요 URL의 크롤 유지, 차단 대상 요청 감소, CSS·JavaScript 접근 오류와 전체 차단 여부을 함께 비교합니다. 한 가지 수치만 좋아졌다고 완료하지 말고 사용자 경험·검색 접근·사업 목적 사이의 부작용을 확인합니다.
완료 기준은 검색 대상 URL은 계속 접근 가능하고 불필요한 경로 요청만 줄어든 상태입니다. 반대로 Googlebot·Yeti의 핵심 문서 접근이 막히거나 robots.txt가 HTML·5xx를 반환하면 즉시 이전 파일로 복구합니다. 롤백 판단을 담당자의 감에 맡기지 말고 배포 전에 임계값과 연락 순서를 정하세요.
책임자는 SEO 담당자와 서버·CDN 운영자입니다. 월별 또는 분기별 검토에서 오래된 가정, 소유자가 없는 규칙, 더 이상 존재하지 않는 URL과 도구 의존성을 제거합니다. 이 기록은 장애 대응뿐 아니라 다음 콘텐츠·기술 개선의 우선순위를 정하는 근거가 됩니다.
- 대표 호스트별 robots.txt 백업
- 크롤러별 테스트 URL 표본 고정
- 운영 배포 전 스테이징 검사
- 배포 뒤 외부 HTTP 응답 저장
- 검색엔진별 URL 검사 결과 기록
- 30일 뒤 불필요 규칙 정리
robots.txt 변경 전에 함께 확인할 진단
세 문서를 함께 보면 파일 생성 오류, URL별 색인 상태, 검색엔진 발견 경로를 분리해 판단할 수 있습니다.
공식 자료와 확인 도구
크롤러 이름과 지원 지시문은 바뀔 수 있으므로 운영에 적용하는 날 각 사업자의 현재 문서를 다시 확인하세요.
자주 묻는 질문
robots.txt로 페이지를 검색 결과에서 완전히 없앨 수 있나요?
아닙니다. robots.txt는 크롤링을 제한합니다. 검색 제외가 목적이면 크롤러가 읽을 수 있는 noindex, 삭제 상태 코드, 접근 인증 등 목적에 맞는 수단을 사용해야 합니다.
사이트맵 주소는 robots.txt에 꼭 적어야 하나요?
필수는 아니지만 여러 검색엔진이 사이트맵 위치를 발견하는 데 도움이 됩니다. Search Console과 Search Advisor에도 대표 사이트맵을 별도로 제출하고 응답 상태를 확인하는 편이 좋습니다.
AI 크롤러를 모두 차단하면 AI 검색에도 나오지 않나요?
AI 학습 수집, 검색 색인, 사용자 요청 기반 가져오기는 서비스마다 주체와 정책이 다릅니다. 특정 user-agent 차단이 모든 AI 기능을 통제한다고 단정하지 말고 각 서비스 문서를 확인해야 합니다.
정리: 크롤러 이름을 나열하는 것보다 목적을 크롤링·색인·보안·AI 정책으로 나누고, 실제 응답과 로그로 검증하는 운영 절차가 중요합니다.