홈페이지를 개편한 뒤 중요한 상품·예약 글이 검색에서 사라졌다면 콘텐츠를 다시 쓰기 전에 검색로봇 접근 설정부터 확인해야 한다. 2026년 9월 10일 Google 공식 문서를 확인하면 robots.txt는 크롤링을 관리하는 파일이지 검색결과에서 페이지를 숨기는 보안 장치가 아니다. 반대로 noindex는 검색 제외 지시지만, 크롤링까지 막으면 검색엔진이 그 지시를 읽지 못할 수 있다. 목적이 다른 두 설정을 함께 쓰는 실수가 누락을 길게 만든다.
핵심 요약: 공개 목적부터 정하고 차단 신호를 분리한다
① URL의 공개 목적을 정한다 ② 대표 고객 동선을 표본으로 고른다 ③ robots.txt 원문을 확인한다 ④ HTML과 응답 헤더의 noindex를 찾는다 ⑤ 크롤링·색인 상태를 따로 읽는다 ⑥ 한 가지 충돌만 고쳐 실제 URL을 검사한다 ⑦ 배포 후 기록하고 재발을 막는다. 개인정보나 관리자 화면은 robots.txt에 기대지 말고 로그인과 서버 권한으로 보호한다.
1. 페이지를 공개·제외·비공개 세 가지로 나눈다
상품, 서비스, 매장 안내, 유용한 글처럼 고객이 검색해도 되는 페이지는 ‘공개·색인 후보’다. 결제 완료, 장바구니, 필터 조합처럼 검색 가치가 낮지만 사용자가 접근해야 하는 화면은 ‘접근 가능·색인 제외’ 후보가 된다. 관리자, 고객 주문정보, 견적서처럼 외부인이 보면 안 되는 화면은 ‘인증 필요’다. 마지막 유형을 Disallow나 noindex만으로 보호하면 URL이나 내용이 다른 경로로 노출될 수 있으므로 반드시 로그인과 권한 검사를 적용한다.
2. 고객 동선 12개를 표본으로 고른다
홈, 핵심 서비스 3개, 인기 글 3개, 예약·문의 2개, 정책 3개처럼 12개 URL을 한 표에 적는다. 각 행에 의도한 공개 상태, HTTP 응답, robots 허용 여부, noindex 유무, canonical, 사이트맵 포함 여부를 기록한다. 전체 URL을 무작정 훑기보다 매출과 신뢰에 직접 닿는 동선부터 본다. 새 글만 정상이고 공통 템플릿을 쓰는 서비스 글이 모두 막혔다면 개별 문서가 아니라 배포 설정 문제일 가능성을 먼저 조사한다.
3. robots.txt는 루트 주소의 원문으로 확인한다
브라우저에서 도메인 뒤에 /robots.txt를 붙여 로그인 없이 열고 User-agent와 Disallow 경로를 읽는다. robots.txt는 게시된 프로토콜·호스트·포트 범위에 적용되므로 www와 비www, 하위도메인을 섞지 않는다. ‘User-agent: *’ 아래 ‘Disallow: /’는 전체 크롤링을 막고, 대소문자가 다른 경로는 별개로 해석될 수 있다. CSS·자바스크립트를 막아 검색로봇이 본문을 이해하기 어렵게 만들지 않았는지도 함께 확인한다.
4. noindex는 화면 코드와 응답 헤더를 모두 본다
페이지 원본의 head에서 robots 메타 태그를 찾고 개발자도구 Network에서 X-Robots-Tag 응답 헤더도 확인한다. CMS의 ‘검색엔진 표시 안 함’, 테스트 환경 복제, 템플릿 조건문이 전체 카테고리에 noindex를 남기는 경우가 있다. 공개 페이지라면 두 위치 모두 색인 금지 지시가 없어야 한다. PDF처럼 HTML head가 없는 파일은 응답 헤더가 적용될 수 있으므로 화면 소스만 보고 정상이라고 결론내리지 않는다.
5. 차단률과 영향도를 함께 계산한다
내부 점검용 차단률은 ‘의도와 다르게 막힌 URL ÷ 검사 URL × 100’으로 계산한다. 12개 중 서비스 2개와 예약 1개가 잘못 막혔다면 25%다. 이는 Google 점수나 순위 기준이 아니라 배포 전후 누락을 비교하는 수치다. 한 개뿐이어도 예약이나 문의 완료 페이지가 공개 검색에 노출됐다면 개인정보 위험을 우선 처리하고, 여러 글이 막혔더라도 원인이 같은 템플릿이면 한 번의 수정으로 검증 범위를 넓힌다.
6. 크롤링 허용과 색인 허용을 따로 검사한다
Search Console URL 검사에서 ‘크롤링 허용 여부’와 ‘색인 생성 허용 여부’를 각각 확인하고 실제 URL 테스트로 현재 배포본을 본다. noindex를 적용해 검색에서 빼려면 검색로봇이 페이지를 읽을 수 있어야 하므로 robots.txt 차단과 동시에 두지 않는다. 공개 복구는 잘못된 Disallow 또는 noindex 한쪽을 먼저 제거하고, 200 응답·대표 canonical·내부링크·사이트맵이 같은 URL을 가리키는지 확인한다. 검사 통과는 실제 검색 노출을 보장하지 않는다.
7. 수정 한 건마다 배포·검사·기록을 묶는다
운영 중인 전체 사이트에 바로 규칙을 바꾸지 말고 대표 URL 하나로 수정 결과를 확인한다. robots.txt 공개 응답, 페이지 소스, 응답 헤더, 실제 URL 테스트, 모바일 화면을 순서대로 기록한 뒤 같은 원인의 URL로 범위를 넓힌다. 수정한 파일·담당자·배포 시각·영향 URL·재확인일을 남기고 사이트맵은 색인하려는 표준 URL만 유지한다. 색인 요청을 반복하지 말고 재크롤링 시간을 기다리며 상태를 비교한다.
40분 실행표와 공개 중단 조건
첫 10분은 12개 URL을 세 가지 공개 상태로 분류하고, 다음 10분은 robots.txt·메타 태그·응답 헤더를 확인한다. 이어 10분은 차단률과 고객 영향을 계산하고 충돌 한 가지를 수정한다. 마지막 10분은 실제 URL 테스트, 내부링크, 사이트맵, 모바일을 재검사한다. 관리자·고객정보 화면이 인증 없이 열리거나, 전체 사이트 차단 규칙의 영향 범위를 모르거나, 수정 뒤 핵심 페이지가 200으로 열리지 않거나, 운영·테스트 환경 구분이 불명확하면 배포를 중단한다. 이 절차는 검색 노출·매출·애드센스 승인을 보장하지 않는다.