robots.txt 문제를 체계적으로 디버깅하기

robots.txt는 간단한 텍스트 파일이지만, 잘못되면 크롤러가 중요한 페이지를 무시해버린다. 문제는 보이지 않는 부분에서 발생하기 때문에 디버깅이 까다롭다.

먼저 파일이 실제로 반환되는지 확인한다

curl로 서버에서 정말 robots.txt를 받을 수 있는지 확인한다. 이게 가장 기본인데도 자주 빠진다.

curl -i https://example.com/robots.txt
curl -i https://example.com/robots.txt.bak  # 잘못된 경로도 확인

status code가 200인지 404인지 확인한다. 또한 Content-Type이 text/plain인지도 본다. 크롤러는 Content-Type을 무시하기도 하지만, 웹서버 설정을 점검하는 좋은 신호다.

파일 내용을 확인한다

응답이 200이면 실제 내용을 본다. 일반적인 실수:

• User-agent: * 다음에 주석이 혼입됨
• Disallow 경로 뒤에 공백이 있음
• Sitemap URL이 절대 경로가 아님

예시로 자주 보는 문제:

User-agent: *
Disallow: /admin # 이 주석은 파서가 무시하지 않을 수 있다
Disallow: /private/

정확한 형식으로 작성해야 한다.

실제 크롤러 입장에서 테스트한다

Google Search Console이나 다른 robots.txt 검증 도구를 사용한다. 이들은 Google 크롤러 입장에서 파일을 해석한 결과를 보여준다.

• 허용된 경로 목록
• 차단된 경로 목록
• Sitemap 인식 여부

로컬에서 파일은 맞는데 크롤러가 읽지 못하는 경우가 있다. 보통 이런 이유다:

1. robots.txt가 DNS 변경 전 구버전 서버에서 반환됨
2. 캐시된 이전 버전을 크롤러가 사용함
3. 보안 설정이 크롤러 접근을 차단함

배포 후엔 시간을 두고 확인한다

robots.txt는 크롤러가 한 번 읽으면 시간 동안 캐시된다. 변경해도 바로 반영되지 않는다.

• 변경 직후: 로컬과 staging 환경에서 curl로 확인
• 변경 1시간 후: 크롤러 시뮬레이터로 재확인
• 변경 1주일 후: 크롤러가 실제로 새 규칙을 따르는지 Search Console에서 확인

급할 때도 있지만, robots.txt 변경은 시간을 갖고 확인해야 제대로 반영됐는지 알 수 있다.