문서와 리소스 목록을 함께 준비합니다
문제가 있는 페이지를 익명 브라우저로 열고 본문 생성에 필요한 스크립트·스타일·공개 데이터 경로를 기록합니다. 단순히 파일 확장자가 js나 css라는 이유만으로 모두 중요한 것은 아니므로 어떤 화면 기능에 쓰이는지도 적습니다. 본문 없이도 동작하는 광고 위젯과 핵심 설명을 생성하는 파일을 구분하면 우선순위를 정하기 쉽습니다.
실제 호스트의 robots 파일을 읽습니다
저장소의 파일뿐 아니라 배포된 호스트의 /robots.txt 응답을 확인합니다. 루트와 www 또는 미리보기 호스트의 설정이 다를 수 있으므로 검사 주소를 명시합니다. 광범위한 디렉터리 차단이 정적 자산 폴더까지 포함하는지 살피고 특정 사용자 에이전트용 그룹이 별도로 있는지도 확인합니다. 규칙을 일부만 복사해 평가하면 적용 범위를 잘못 판단할 수 있습니다.
차단을 바꿀 때의 검토 순서
- 해당 규칙을 만든 이유와 보호하려는 경로를 확인합니다.
- 필요한 공개 자원이 같은 디렉터리에 섞여 있는지 찾습니다.
- 디렉터리 구조를 분리하거나 필요한 허용 범위를 좁혀 표현합니다.
- 바뀐 규칙과 실제 리소스 URL을 테스트하고 본문 렌더링을 다시 확인합니다.
설명용으로 /assets/ 아래에 공개 스크립트와 내부 문서가 함께 있다면 무조건 전체 허용을 선택하지 않습니다. 내부 문서의 접근 통제를 먼저 확인하고 자원의 배치·권한 정책을 분리합니다. 공개 스크립트가 읽히게 됐다는 사실은 내부 자료가 보호된다는 증거가 아니므로 두 검증을 별도 보고합니다.
수정 결과의 확인
이전과 같은 페이지·브라우저 조건으로 주요 본문이 나타나는지 확인합니다. 리소스 요청이 정상이어도 실행 오류가 남을 수 있어 콘솔과 화면을 함께 확인합니다. 검색도구의 검사 기능을 사용할 수 있으면 해당 URL의 결과를 저장하되 전체 사이트를 검사했다고 표현하지 않습니다. robots 파일의 배포 시각과 검사 시각을 남겨 캐시된 이전 결과와 구분합니다.
색인 제외 목적의 혼동을 막습니다
크롤링 차단, 페이지의 색인 지시, 실제 접근 권한은 각자 역할이 다릅니다. 어떤 문서를 검색에서 제외하려는 목적이라면 리소스 허용 문제와 별도의 정책으로 다룹니다. 차단 규칙을 한 줄 삭제한 뒤 노출 수가 즉시 바뀔 것이라고 기대하지 않고 접근 가능성과 이후 검색 상태를 나눠 관찰합니다.
자주 묻는 질문
- 관리 폴더를 robots.txt로 막으면 보안이 확보되나요?
- robots 규칙을 접근 권한 관리로 사용하지 않습니다. 민감한 문서와 API는 인증·권한 등 서버 측 통제로 보호하고 공개 리소스의 크롤링 정책은 별도로 결정합니다.
- 모든 경로를 허용해도 되나요?
- 문제를 해결하려고 전역 허용으로 바꾸기 전에 차단의 목적을 확인합니다. 공개 페이지의 표현에 필요한 자원과 관리·테스트·개인 자료를 구분해 최소 범위로 수정합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.