robots.txt 파일을 제대로 설정했는데도 구글이 차단된 페이지를 자꾸 크롤링한다거나, 검색 결과에 떠야 할 페이지가 안 나타나는 경험을 해본 적 있을까. 대부분의 웹 개발자들은 robots.txt를 단순한 텍스트 파일 정도로 생각해서 규칙을 써놓고 끝낸다. 다만 검색 엔진이 실제로 그 지시를 따르지 않는 경우가 상당히 많다는 걸 모르는 경우가 많다. 이번에는 robots.txt가 무시되는 실제 원인 5가지를 정확히 파악하고, 각각을 어떻게 해결하는지 완벽하게 정리해서 소개하겠다.
robots.txt의 가장 큰 오해부터 풀어야 한다. 이 파일은 검색 엔진에 대한 요청사항일 뿐, 법적 구속력이 있는 명령이 아니다. 구글, 네이버, 빙 같은 검색 엔진이 자발적으로 따르는 국제 표준(Robots Exclusion Standard)일 뿐이다. 따라서 악의적인 크롤러나 보안 스캐너는 이 파일을 무시하고 당신의 사이트에 접근할 수 있다. 구글이 '차단된 리소스도 색인할 수 있다'고 명시한 이유도 여기 있다.
robots.txt는 반드시 도메인 루트(/) 에 위치해야 한다. 예를 들어 example.com/robots.txt는 맞지만, example.com/public/robots.txt는 인식되지 않는다. 서브도메인이 있다면 각각 따로 필요하다. subdomain.example.com 에 크롤링 규칙이 필요하면, subdomain.example.com/robots.txt 파일을 따로 만들어야 한다.
✗ 잘못된 것: /public/robots.txt 또는 /admin/robots.txt 경로에 파일 배치
✓ 올바른 것: 웹 서버의 문서 루트 바로 아래에 배치. Nginx라면 /var/www/html/robots.txt, Apache라면 DocumentRoot 지정 디렉토리 바로 아래
robots.txt 파일 자체가 존재하더라도, 서버가 HTTP 404(Not Found)나 410(Gone) 상태 코드를 반환하면 구글은 그 파일을 인식하지 않는다. 또한 HTTP 401(Unauthorized)이나 403(Forbidden)으로 응답하면, 구글은 파일이 존재하지만 접근할 수 없다고 판단해 모든 크롤링을 막는다. 가장 흔한 실수는 robots.txt를 실수로 .htaccess 또는 Nginx 설정에서 차단해두는 것이다.
<FilesMatch "robots\.txt">
Deny from all
</FilesMatch>✗ 잘못된 것: Apache에서 robots.txt를 명시적으로 차단
<Files robots.txt>
Allow from all
</Files>✓ 올바른 것: robots.txt는 모든 방문자가 읽을 수 있어야 함. 반드시 Allow 설정
Nginx 사용자라면 로그를 확인해서 robots.txt 요청이 정말 200으로 응답되는지 점검하자.
tail -f /var/log/nginx/access.log | grep robots.txtrobots.txt에 대한 요청이 200이 아닌 다른 상태 코드를 반환하면, 구글 Search Console의 '크롤링 통계'에 404 에러가 기록된다.
robots.txt는 엄격한 포맷을 따른다. 띄어쓰기, 대소문자, 줄바꿈 하나가 틀려도 그 줄 전체가 무시될 수 있다. 구글은 문법 오류가 있는 줄은 단순히 스킵하고 진행한다. 따라서 실제로는 당신이 의도한 차단 규칙이 작동 안 할 수 있다.
✗ 잘못된 것:
User-agent: Googlebot
Disallow: /admin (앞에 공백 있음 - 무시됨)
Disallow: /private (User-agent 지정 없음 - 모든 봇에 적용되지만 위의 Googlebot 규칙이 먼저 끝났으므로 새 규칙으로 시작)
✓ 올바른 것:
User-agent: Googlebot
Disallow: /admin
Disallow: /private
User-agent: *
Disallow: /temp
각 지시사항(User-agent, Disallow, Allow, Crawl-delay)은 정확히 한 줄에 하나씩, 앞에 공백 없이 써야 한다. 여러 Disallow 규칙을 쓸 때는 각각 새 줄에 한 개씩 입력한다.
드물지만, 당신의 웹 서버 또는 방화벽이 검색 엔진 크롤러의 robots.txt 요청을 차단하는 경우가 있다. 특히 DDoS 방어 솔루션이나 WAF(Web Application Firewall)를 사용하는 경우, 크롤러의 robots.txt 요청이 의심 트래픽으로 낙인찍혀 403 Forbidden이나 429 Too Many Requests로 응답될 수 있다.
✗ 잘못된 것: Cloudflare 또는 AWS WAF에서 robots.txt 요청을 우호적이지 않은 요청으로 분류해 차단
✓ 올바른 것: 방화벽 설정에서 robots.txt 경로를 화이트리스트에 추가하고, User-Agent가 Googlebot/Bingbot/Yeti 등인 요청은 항상 통과되도록 설정
구글 Search Console의 '크롤링 통계' 또는 'URL 검사' 도구에서 robots.txt 파일이 정상 크롤링되는지 확인할 수 있다. 서버 로그에서도 검색 엔진 User-Agent의 robots.txt 요청이 기록되는지 점검하자.
robots.txt에서 특정 크롤러만 차단하거나 허용하려면 User-agent를 정확히 지정해야 한다. 대소문자를 구분하지 않지만, 크롤러 이름 자체를 잘못 입력하면 규칙이 적용되지 않는다. 예를 들어 Googlebot-Image는 일반 웹 페이지용 Googlebot과 다른 크롤러다.
✗ 잘못된 것:
User-agent: googlebot-image
Disallow: /images
이렇게 쓰면 일반 Googlebot(웹 페이지 크롤러)은 영향을 받지 않고, Googlebot-Image만 /images를 차단하는 규칙이 된다.
✓ 올바른 것:
User-agent: Googlebot
Disallow: /admin
Disallow: /private
User-agent: Googlebot-Image
Disallow: /images/temp
User-agent: *
Disallow: /staging
User-agent: * 는 모든 크롤러를 대상으로 하는 catch-all 규칙이다. 보통 맨 마지막에 배치해서 모든 크롤러에게 적용할 기본 규칙을 정의한다. 특정 크롤러에 대한 규칙은 그 전에 배치하면, 더 구체적인 규칙이 먼저 적용된다.
구글 Search Console의 '로봇.txt 테스터' 도구를 사용하면, 실제로 당신의 robots.txt 파일이 특정 URL과 User-Agent에 대해 어떤 규칙을 적용하는지 실시간으로 확인할 수 있다. 파일이 존재하지 않거나 문법 오류가 있으면 즉시 알려준다.
또한 서버 로그를 정기적으로 확인해서 검색 엔진이 robots.txt를 요청할 때 정말 200 상태 코드를 받는지, 혹은 404나 403 같은 오류를 받는지 모니터링하자. 다음 명령으로 최근 robots.txt 접근 기록을 확인할 수 있다.
grep "robots.txt" /var/log/nginx/access.log | tail -20마지막 확인사항은 sitemap.xml이다. robots.txt의 맨 아래에 다음과 같이 사이트맵 위치를 명시하면, 구글이 크롤링 효율을 높일 수 있다.
User-agent: *
Disallow: /admin
Sitemap: https://example.com/sitemap.xml
robots.txt는 검색 엔진 크롤링을 제어하는 가장 기본적인 도구다. 파일 위치, HTTP 상태 코드, 문법, 크롤러 접근성, User-agent 지정 같은 작은 디테일 하나하나가 모여서 당신의 사이트가 검색 결과에 노출되는 방식을 결정한다. 이 글의 5가지 원인을 하나씩 체크리스트처럼 점검하고, 구글 Search Console의 robots.txt 테스터로 검증하면, 당신의 사이트가 의도한 대로 크롤링되고 색인될 수 있을 것이다.