robots.txt 생성기

Disallow는 "차단"이 아니라 "요청"입니다

robots.txt를 오해해서 생기는 사고가 가장 많습니다. 두 가지를 분리해서 기억해야 합니다.

첫째, Disallow는 "이 경로를 크롤링하지 말아 달라"는 요청이지 "검색결과에서 빼 달라"가 아닙니다. 크롤러가 페이지를 읽지 않을 뿐, 다른 사이트가 그 주소로 링크를 걸어 두면 구글은 내용 없이 주소만으로 검색결과에 노출할 수 있습니다. 서치 콘솔에 "robots.txt에 의해 차단되었지만 색인이 생성됨"이라고 뜨는 상태가 바로 이것입니다.

둘째, 여기서 진짜 사고가 납니다. 검색에서 빼고 싶어서 그 페이지에 noindex 메타 태그를 넣고, 동시에 robots.txt로도 막습니다. 그러면 크롤러가 페이지를 못 읽으니 noindex 태그도 못 읽습니다. 결과적으로 페이지는 영영 색인에서 안 빠집니다. noindex와 Disallow는 같이 쓰면 안 됩니다.

AI 크롤러 차단 — 무엇을 막고 무엇을 열어 둘지

AI 봇을 전부 막는 게 항상 정답은 아닙니다. 같은 회사 봇이라도 역할이 다르기 때문입니다. 학습용 수집만 막고 검색·인용용은 열어 두는 조합이 실제로 가장 많이 쓰입니다.

robots.txt는 강제력이 없습니다

robots.txt는 신사협정입니다. 지킬지 말지는 봇이 정합니다. 주요 업체(OpenAI·Anthropic·구글·네이버)는 자사 크롤러가 규칙을 지킨다고 공개했지만, 파일을 아예 안 읽는 봇, User-Agent를 위장하는 봇, 이름을 수시로 바꾸는 봇은 막히지 않습니다. 접속 로그에 특정 봇이 계속 찍힌다면 서버 단에서 막아야 실제로 차단됩니다.

# nginx — robots.txt를 무시하는 봇을 실제로 막는 방법
# 응답 없이 연결을 끊는 444 를 쓰면 대역폭도 아낍니다.
map $http_user_agent $bad_bot {
    default 0;
    ~*(GPTBot|CCBot|Bytespider|AhrefsBot|SemrushBot) 1;
}

server {
    # ... 생략 ...
    if ($bad_bot) { return 444; }
}

# 적용 전 문법 검사 → 무중단 반영
#   nginx -t && systemctl reload nginx

올리는 위치와 확인 방법

문법이 맞아도 위치가 틀리면 아무 의미가 없습니다. robots.txt는 반드시 도메인 최상위에 있어야 하고, 서브도메인은 각각 자기 파일을 가집니다.

1. 내려받은 파일을 사이트 루트에 올린 뒤, 브라우저로 https://내도메인/robots.txt 를 직접 열어 봅니다. 404나 HTML 페이지가 나오면 위치가 틀린 것입니다.
2. 구글 서치 콘솔의 robots.txt 보고서에서 구글이 읽은 최신 내용과 오류를 확인합니다.
3. 네이버 서치어드바이저의 robots.txt 검증 도구로 예티 기준도 확인합니다.

• https://example.com/blog/robots.txt → 무시됩니다. 하위 폴더에 두면 아무 효과가 없습니다.
• https://blog.example.com/ → example.com의 robots.txt가 적용되지 않습니다. 서브도메인마다 따로 올려야 합니다.
• 파일명은 소문자 robots.txt 그대로. http와 https도 별개로 취급되니 둘 다 서비스 중이면 양쪽 다 응답해야 합니다.