robots.txt가 검색 노출을 막는지 확인하는 방법

반드시 대표 호스트의 루트 파일을 확인한다

robots.txt는 호스트와 프로토콜 범위에 따라 적용됩니다. https://example.com/의 페이지를 조사하면서 다른 하위 도메인이나 http 주소의 파일만 보면 안 됩니다. 문제 페이지의 정확한 호스트 뒤에 /robots.txt를 붙여 로그인 없이 열고, HTML 오류 페이지가 아니라 텍스트 규칙인지 확인합니다.

파일이 없거나 404라고 해서 모든 페이지가 색인된다는 뜻은 아닙니다. noindex, 접근 인증, 서버 오류, canonical과 콘텐츠 품질은 별도 신호입니다.

Google Search Central: robots.txt 소개와 적용 범위 · 문서 확인 2026-10-02

규칙은 User-agent와 경로를 한 세트로 읽는다

문제 URL의 경로를 적고 Googlebot에 적용되는 그룹을 찾습니다. Allow와 Disallow가 함께 있다면 더 구체적인 경로 규칙이 우선될 수 있으므로 일부 문자열만 보고 판단하지 않습니다. 별표와 달러 기호 같은 패턴도 실제 경로에 어떻게 맞는지 확인합니다.

예를 들어 /private/ 차단은 /articles/robots-check에 적용되지 않습니다. 반대로 Disallow: /처럼 루트 전체를 막는 규칙은 공개 사이트에 큰 영향을 줄 수 있습니다. 수정 전 파일 전체와 변경 이유를 보관하고, 필요한 공개 경로만 최소한으로 조정합니다.

1. 문제 URL의 scheme, host, path를 그대로 기록합니다.
2. 해당 호스트의 robots.txt에서 Googlebot 또는 * 그룹을 찾습니다.
3. Allow와 Disallow 중 경로에 가장 구체적으로 맞는 규칙을 확인합니다.
4. Search Console URL 검사와 robots.txt 관련 테스트 결과를 함께 기록합니다.

robots.txt는 검색 결과 삭제 도구가 아니다

robots.txt로 크롤링을 막아도 다른 페이지의 링크를 통해 URL 자체가 검색 결과에 나타날 수 있습니다. 검색 결과에서 제외하려면 Google이 noindex를 읽을 수 있어야 하므로, 같은 URL을 robots.txt로 차단한 상태에서는 noindex 확인이 방해될 수 있습니다. 민감한 정보는 robots.txt가 아니라 인증으로 보호해야 합니다.

긴급 삭제 도구는 일시적인 검색 결과 숨김에 쓰일 수 있지만 공개 원인을 제거하는 영구 조치와 다릅니다. 공개 여부, noindex, 인증과 삭제 목적을 먼저 정한 뒤 적합한 방법을 선택합니다.

Google Search Central: 공개 범위와 색인 제어 방법 · 문서 확인 2026-10-02

CSS와 JavaScript 차단도 렌더링에 영향을 준다

공개 본문은 허용하면서 테마의 CSS나 JavaScript 경로를 차단하면 Google이 페이지를 사용자가 보는 방식으로 렌더링하기 어려울 수 있습니다. 오래된 보안 규칙이 /wp-content/ 전체를 막고 있지 않은지, 필요한 리소스 요청이 실패하는지 URL 검사와 렌더링 화면에서 확인합니다.

관리자·로그인 경로를 차단하는 규칙과 공개 리소스를 차단하는 규칙을 구분합니다. 보안 플러그인이나 CDN이 별도로 User-Agent를 막는 경우 robots.txt가 정상이어도 접근할 수 없으므로 실제 HTTP 응답과 서버 로그 확인이 필요합니다.

수정 뒤에는 파일과 문제 URL을 다시 본다

새 robots.txt가 200 텍스트로 열리고 의도한 Sitemap 행을 유지하는지 확인합니다. 문제 URL을 로그아웃 상태에서 열어 200 본문, canonical, robots 메타를 확인한 뒤 Search Console의 live test로 현재 접근 상태를 다시 봅니다. 변경이 Google의 재크롤링과 색인을 즉시 보장하지는 않습니다.

기록에는 변경 전후 규칙, 영향을 받는 경로, 확인한 User-agent, 실제 HTTP 상태와 미확인 항목을 남깁니다. 크롤링 허용과 색인 완료를 같은 PASS로 합치지 않습니다.