robots.txt와 noindex를 함께 걸면 왜 반대로 동작하나

이커머스에서 가장 흔한 색인 사고가 여기서 납니다. robots.txt 파일은 검색 엔진 크롤러가 사이트의 어떤 페이지나 파일을 요청할 수 있고 없는지를 알려주는 텍스트 파일입니다. 반면 noindex는 페이지를 색인에서 빼라는 규칙으로 meta 태그 또는 X-Robots-Tag HTTP 헤더로 지정합니다.

구글은 noindex 규칙이 효력을 가지려면 그 페이지나 리소스가 robots.txt로 차단돼 있지 않아야 하고 크롤러가 접근할 수 있어야 한다고 명시합니다. robots.txt로 막으면 구글봇이 페이지를 가져올 수 없어 meta 태그나 헤더의 noindex를 읽지 못하고, 다른 사이트가 링크를 걸어둔 경우 색인에 남을 수 있습니다. 관리자 경로나 사이트 내 검색결과 경로를 robots.txt로 막으면서 동시에 noindex를 걸어둔 구성이 대표적인 사례이고, 둘 중 하나만 써야 의도대로 동작합니다.

기준은 목적입니다. 검색결과에서 빼는 것이 목적이면 noindex를 쓰고 robots.txt는 열어둡니다. 크롤 자원 낭비를 막는 것이 목적이면 robots.txt로 막되 그 URL이 색인에 남아도 상관없는 경로여야 합니다. 그리고 robots.txt는 제안에 가까워 모든 크롤러가 준수하지 않으므로, 민감한 콘텐츠 보호에는 비밀번호 같은 다른 수단을 함께 써야 합니다.

사이트맵에서 나는 실수는 무엇인가

sitemap.xml은 사이트의 모든 중요한 URL을 나열하고 각 URL의 마지막 업데이트 시간과 변경 빈도 같은 메타데이터를 제공하는 XML 파일입니다. 문제는 이 목록이 사이트의 실제 상태와 어긋날 때 생깁니다.

첫 번째 유형은 색인 대상이 아닌 URL이 실려 있는 경우입니다. noindex를 건 페이지, 파라미터가 붙은 비정규 URL, 이미 삭제한 상품 URL이 사이트맵에 남아 있으면 크롤러가 그것들을 계속 확인하러 옵니다. 두 번째 유형은 lastmod가 실제 수정 시점을 반영하지 않는 경우입니다. 전체 URL의 lastmod를 배포일로 일괄 갱신하는 구현이 여기 해당하는데, 그러면 무엇이 실제로 바뀌었는지 알리는 신호가 사라집니다.

사이트맵은 정규 URL 지정 수단으로 보면 상대적으로 약한 신호입니다. 그래서 사이트맵에 대표 URL을 실어두는 것만으로 중복 문제가 해결되지는 않고, 내부 링크와 캐노니컬이 같은 URL을 가리키도록 함께 맞춰야 합니다.

크롤 자원은 무엇이 갉아먹나

크롤링 예산은 구글이 특정 사이트에서 크롤링할 수 있고 크롤링하고 싶어하는 URL 집합을 뜻하며, 크롤 용량과 크롤 수요 두 요소로 구성됩니다. 크롤 용량은 서버 응답 시간과 성능에 따라 조정되고 서버 오류나 속도 제한 신호에 의해 줄어듭니다. 크롤 수요는 사이트 크기, 업데이트 빈도, 콘텐츠 인기도에 따라 결정됩니다.

구글이 안내하는 최적화 전략은 중복 콘텐츠 통합, robots.txt를 활용한 불필요한 URL 차단, 제거된 페이지에 404 또는 410 상태 코드 반환, 사이트맵 lastmod 태그 갱신, 페이지 로드 속도 개선, HTTP 304 응답 지원입니다. 이커머스에서는 필터와 정렬 조합으로 생긴 URL이 이 목록의 첫 두 항목에 그대로 걸립니다.

소프트 404도 크롤 자원을 갉아먹습니다. 소프트 404는 페이지가 없다는 메시지를 보여주면서도 HTTP 상태 코드는 200으로 응답하는 오류이고, 이런 URL이 많으면 실제 콘텐츠가 있는 페이지 대신 이들이 크롤링돼 크롤 커버리지를 잠식합니다. 품절 상품 페이지를 안내 문구만 남긴 채 200으로 유지하는 구현이 여기 해당하는데, 대체 상품이 있으면 301, 완전히 단종됐으면 404 또는 410으로 응답해야 합니다.

AI 검색 크롤러는 어떻게 구분해 다루나

robots.txt의 관리 대상이 검색엔진 크롤러만은 아니게 됐습니다. OpenAI는 목적이 다른 세 크롤러를 별도 user-agent로 운영합니다. GPTBot은 모델 학습용, OAI-SearchBot은 ChatGPT 검색 기능에 노출되기 위한 색인용, ChatGPT-User는 사용자 요청을 대신 수행하는 프록시입니다. 각각을 robots.txt에서 독립적으로 허용하거나 차단할 수 있어서, GPTBot은 차단하면서 OAI-SearchBot만 허용해 학습 데이터 제공은 막고 검색 노출 자격은 유지하는 설정이 가능합니다.

Perplexity는 두 종류를 운영합니다. PerplexityBot은 색인·학습용 크롤러로 robots.txt를 준수하고, Perplexity-User는 사용자를 대신해 실시간으로 페이지를 가져오는 에이전트입니다. 공식 문서는 PerplexityBot을 차단하면 학습 데이터 활용을 막을 수 있다고 안내하며, Perplexity-User는 봇이 아니라 에이전트라는 입장이라 robots.txt를 반드시 따르지는 않는다는 점이 업계에서 지적됩니다. 다만 이 해석은 커뮤니티 논의에서 나온 것이고 Perplexity가 무조건 무시한다고 명문화한 것은 아닙니다.

색인 누락을 어떤 순서로 점검하나

순서는 접근, 상태, 대상입니다. 첫째로 문제 URL이 robots.txt로 막혀 있는지 확인합니다. 둘째로 그 URL이 반환하는 상태 코드와 noindex 지정 여부를 확인합니다. 셋째로 크롤링은 됐는데 인덱싱이 안 된 상태인지 구분합니다. 인덱싱은 크롤링된 페이지의 콘텐츠를 분석해 데이터베이스에 저장하는 과정이고 크롤링된 페이지가 전부 인덱싱되지는 않으므로, 크롤링 여부와 인덱싱 여부는 따로 봐야 합니다.

세 단계 모두 서치 콘솔에서 확인합니다. URL 검사로 개별 URL의 크롤링 허용 여부와 색인 상태를 보고, 페이지 색인 생성 리포트에서 제외 사유별 건수를 봅니다. robots.txt에 의해 차단됨, noindex 태그에 의해 제외됨, 소프트 404 같은 사유는 처방이 서로 달라서 사유별로 나눠 처리해야 합니다. 사유별 건수가 배포 이후 늘었다면 원인은 콘텐츠가 아니라 그 배포에 있습니다.