robots.txt 역할과 설정 기준

robots.txt 역할과 설정 기준

웹사이트 운영에서 robots.txt는 자주 언급되지만, 실제 역할은 생각보다 좁고 분명합니다. 이 파일은 검색엔진 크롤러가 어떤 URL에 접근할 수 있는지 알려 주는 규칙 파일입니다. 핵심 목적은 크롤링 범위를 조정하는 데 있으며, 비공개 정보 보호나 검색 결과 완전 차단을 대신하는 장치는 아닙니다. 따라서 robots.txt를 다룰 때는 “무엇을 숨길 것인가”보다 “무엇을 크롤링하지 않게 할 것인가”라는 관점으로 이해하는 편이 정확합니다. (Google for Developers)

robots.txt의 역할

robots.txt의 가장 기본적인 역할은 크롤러 트래픽을 관리하는 데 있습니다. 구글은 이 파일이 주로 서버 요청 부담을 줄이거나, 중요도가 낮은 페이지와 비슷한 페이지의 크롤링을 피하기 위해 사용된다고 설명합니다. 또 이미지·동영상·오디오 같은 미디어 파일에는 검색 노출 제어의 일부 수단으로 쓰일 수 있지만, 일반적인 HTML 페이지를 검색 결과에서 완전히 숨기는 용도로 이해하면 오류가 생깁니다. 즉 robots.txt는 검색엔진에게 “여기는 보지 않아도 된다”는 운영 규칙을 전달하는 문서에 가깝습니다. (Google for Developers)

robots.txt와 noindex의 차이

가장 많이 혼동되는 부분은 robots.txt와 noindex의 차이입니다. robots.txt는 크롤링을 막는 방식이고, noindex는 색인을 막는 방식입니다. 구글은 페이지를 검색 결과에서 제외하려면 noindex나 비밀번호 보호를 사용하라고 안내합니다. 특히 페이지가 robots.txt로 막혀 있으면 크롤러가 그 페이지를 읽지 못하므로, 페이지 안에 넣어 둔 noindex 지시도 확인할 수 없습니다. 그래서 검색 제외가 목적이라면 무조건 robots.txt부터 넣는 방식은 오히려 문제를 키울 수 있습니다. (Google for Developers)

검색엔진이 robots.txt를 참고하는 방식

검색엔진은 페이지를 요청하기 전에 해당 사이트의 robots.txt 규칙을 먼저 참고합니다. 구글 문서에 따르면 Googlebot은 URL을 가져오기 전에 robots.txt를 읽고, 허용되지 않은 URL이면 HTTP 요청 자체를 건너뜁니다. 이 규칙 파일은 사이트 루트에 위치해야 하며, 프로토콜과 호스트 조합마다 별도로 적용됩니다. 다시 말해 https://example.com/robots.txt와 https://m.example.com/robots.txt는 서로 다른 파일이며, 한쪽 규칙이 다른 서브도메인에 자동 상속되지는 않습니다. (Google for Developers)

크롤링과 색인은 같은 단계가 아니다

검색엔진이 robots.txt를 참고한다고 해서, 차단된 URL이 검색 결과에 절대 나타나지 않는 것은 아닙니다. 구글은 다른 페이지의 링크를 통해 막힌 URL을 발견할 수 있으며, 이 경우 내용을 읽지 못한 상태에서도 URL 자체를 검색 결과에 표시할 수 있다고 설명합니다. 이런 결과는 설명 문구가 없거나 정보가 제한된 형태로 나타날 수 있습니다. 따라서 robots.txt는 “접근 제한”에는 효과가 있지만, “검색 결과 완전 제거”와는 다른 수단이라는 점을 구분해야 합니다. (Google for Developers)

차단해도 되는 영역

robots.txt로 차단해도 되는 영역은 대체로 검색 가치가 낮고, 크롤링만 늘리는 주소들입니다. 구글은 동적 검색 결과 URL, 정렬과 필터가 붙는 목록형 주소, 세션 ID가 포함된 주소, 무한히 생성될 수 있는 달력형 URL 같은 문제성 패턴을 예시로 듭니다. 이런 주소는 실제 콘텐츠보다 변형 조합이 많아 크롤러 자원을 낭비하기 쉽습니다. 또한 페이지 의미를 이해하는 데 큰 영향이 없는 장식용 이미지나 중요하지 않은 스크립트·스타일 파일은 제한적으로 차단할 수 있습니다. 다만 이 경우에도 페이지 해석에 영향이 없다는 전제가 필요합니다. (Google for Developers)

대표적인 차단 대상

초보 운영자가 먼저 검토할 대상은 내부 검색결과 페이지, 필터·정렬·페이징으로 끝없이 조합되는 목록 URL, 세션 파라미터가 붙는 주소입니다. 이런 패턴은 검색엔진에 노출할 핵심 문서라기보다 사이트 내부 탐색 과정에서 파생되는 변형 주소인 경우가 많습니다. 구글도 이러한 문제성 URL에 robots.txt 적용을 고려하라고 설명합니다. 따라서 차단 대상은 “운영자가 보기 싫은 페이지”가 아니라 “검색엔진이 굳이 반복 수집할 필요가 없는 주소”라는 기준으로 고르는 편이 정확합니다. (Google for Developers)

차단하면 안 되는 영역

반대로 검색엔진이 읽어야 하는 핵심 페이지와 필수 자원은 robots.txt로 막으면 안 됩니다. 대표적인 예가 실제 검색 노출을 원하는 본문 페이지, CSS와 JavaScript 같은 렌더링 자원, 구조화 데이터가 포함된 페이지입니다. 구글은 리소스 파일이 막혀 있으면 페이지 이해가 떨어질 수 있다고 밝히고, JavaScript가 필요한 페이지의 경우 차단된 파일에서는 렌더링도 진행되지 않는다고 설명합니다. 즉 화면은 사람이 보기에는 정상이어도, 검색엔진은 불완전한 페이지로 해석할 수 있습니다. (Google for Developers)

noindex를 써야 하는 페이지는 열어 두어야 한다

검색 결과에서 제외하고 싶은 페이지라도 noindex를 사용할 예정이라면, 그 페이지는 크롤러가 실제로 접근할 수 있어야 합니다. 구글은 robots.txt에 막힌 페이지에서는 noindex 규칙을 읽을 수 없다고 명시합니다. PDF나 이미지처럼 HTML이 아닌 파일도 색인 제외가 필요하면 X-Robots-Tag 같은 별도 방식이 필요합니다. 이 점을 모르고 robots.txt와 noindex를 동시에 걸어 두면, 운영자는 “막아 두었으니 검색에서 사라지겠지”라고 생각하지만 실제로는 URL만 남는 불완전한 상태가 이어질 수 있습니다. (Google for Developers)

잘못 설정했을 때 생기는 문제

robots.txt를 잘못 설정하면 가장 먼저 중요한 페이지가 크롤링되지 않는 문제가 생깁니다. 그다음으로는 검색 결과 설명이 사라지거나, 구조화 데이터가 읽히지 않거나, 모바일 페이지와 데스크톱 페이지의 규칙이 달라 검색 해석이 흔들리는 문제가 이어질 수 있습니다. 또 robots.txt는 보안 장치가 아니므로, 민감한 파일 경로를 적어 두는 방식이 오히려 위치를 노출하는 결과가 될 수도 있습니다. 존중하는 크롤러는 규칙을 따르더라도, 모든 자동화 클라이언트가 동일하게 따르는 것은 아니라는 점도 함께 기억해야 합니다. (Google for Developers)

점검 방법

점검은 복잡하지 않습니다. 먼저 브라우저에서 사이트 루트의 /robots.txt 주소를 직접 열어 파일이 정상 응답하는지 확인해야 합니다. 다음으로 Search Console의 URL 검사 도구에서 해당 페이지의 Crawl allowed? 상태를 보면, robots.txt에 의해 막혔는지 확인할 수 있습니다. 추가로 Search Console의 robots.txt 보고서는 구글이 어떤 robots.txt 파일을 찾았는지, 마지막 크롤링 시점과 경고·오류가 무엇인지 보여 줍니다. 중요한 수정이 있었다면 보고서에서 재크롤링 요청도 가능하지만, 이는 반영을 앞당기는 요청일 뿐 즉시 처리 보장은 아닙니다. (구글 도움말)

어디를 기준으로 확인해야 하는가

robots.txt는 경로 전체가 아니라 프로토콜과 호스트 기준의 루트에 존재해야 합니다. 따라서 특정 페이지가 어떤 robots.txt의 영향을 받는지 확인하려면, 그 페이지 URL에서 호스트까지만 남기고 /robots.txt를 붙여 확인하면 됩니다. 예를 들어 이미지가 images.example.com에 있다면 확인 대상도 images.example.com/robots.txt입니다. 이 기준을 놓치면 메인 도메인 규칙만 보고 서브도메인 문제를 지나치기 쉽습니다. (구글 도움말)

초보자용 운영 기준

초보 운영자에게 가장 안전한 기준은 “기본 허용, 선택 차단”입니다. 우선 검색 노출이 필요한 본문 페이지와 렌더링 자원은 열어 둡니다. 그다음 내부 검색결과, 정렬·필터 조합, 세션 파라미터, 무한 달력처럼 크롤링만 늘리는 주소를 선별해 막습니다. 검색 결과 제외가 목적이면 robots.txt 대신 noindex나 비밀번호 보호를 사용합니다. 모바일과 데스크톱이 함께 운영되는 사이트라면 robots 규칙도 가능한 한 일관되게 유지하는 편이 좋습니다. 사이트맵 경로를 robots.txt에 함께 적어 두면 구글이 다음 크롤링 때 이를 발견할 수 있다는 점도 운영상 도움이 됩니다. (Google for Developers)

맺음말

robots.txt는 검색엔진에게 접근 범위를 알려 주는 크롤링 제어 파일입니다. 중요한 점은 이 파일이 검색 제외, 비공개 보호, 보안 설정을 모두 대신하지 않는다는 사실입니다. 차단해야 할 대상은 반복적이고 비핵심적인 URL이어야 하며, 열어 두어야 할 대상은 실제로 검색엔진이 이해해야 하는 페이지와 자원입니다. robots.txt를 단순 차단 도구로 보지 않고, 크롤링 효율을 조정하는 운영 문서로 이해할 때 설정 오류도 줄고 검색 관리도 더 안정적으로 이루어집니다. (Google for Developers)