13장. 사이트맵, robots.txt, noindex의 역할: 알릴 것과 막을 것을 구분하는 법
사이트맵, robots.txt, noindex는 같은 색인 버튼이 아닙니다. 사이트맵은 발견할 대표 URL의 목록, robots.txt는 크롤링 접근 규칙, noindex는 가져온 문서를 색인에서 제외하라는 지시입니다. 삭제 응답과 canonical도 또 다른 목적을 가집니다. 목표를 먼저 정하지 않고 세 도구를 함께 바꾸면 Google이 noindex를 읽지 못하거나 중요한 렌더링 자원을 막을 수 있습니다.
안전한 작업은 “이 URL을 발견시키려는가, 가져오지 못하게 하려는가, 검색 결과에서 빼려는가, 없어진 것으로 처리하려는가”를 먼저 답하는 데서 시작합니다. Blogger의 전역 설정은 여러 URL 유형에 번질 수 있으므로 백업과 표본 검사가 필수입니다.
발견 목록, 접근 규칙, 색인 제외 지시의 목적을 분리합니다. 변경은 한 번에 하나만 적용하고, 복구 완료는 다시 검사한 증거로 판단합니다.
URL별 목표를 포함, 제외, 삭제로 구분합니다
개별 게시물과 핵심 허브는 보통 발견·크롤링·색인을 허용할 후보입니다. 내부 검색 결과와 단순 자동 목록은 사용자 가치와 중복 정도를 보고 색인 제외를 검토할 수 있습니다. 영구히 없어진 문서는 noindex를 남기는 것보다 적절한 삭제 응답이나 관련 대체 문서로의 이동이 맞을 수 있습니다.
한 URL에 여러 목표를 섞지 않습니다. 크롤 비용을 줄이겠다고 robots로 막으면서 검색 결과에서도 빨리 없애려 하면 크롤러가 제외 지시를 읽지 못합니다. 먼저 URL 유형별 의도표를 만든 뒤 도구를 선택합니다.
사이트맵은 대표 URL 발견 목록으로 관리합니다
사이트맵에는 검색에 남기고 싶은 성공 응답의 대표 URL을 넣습니다. 리디렉션되는 주소, 삭제 주소, noindex 주소를 계속 실으면 “발견시키고 싶다”와 “제외하고 싶다”는 신호가 충돌합니다. Google 사이트맵 안내는 사이트맵이 색인을 보장하지 않는다는 점을 분명히 합니다.
Blogger가 제공하는 사이트맵 또는 피드 주소의 실제 내용을 확인하고 Search Console 속성과 호스트가 일치하는지 봅니다. 제출 성공은 파일을 읽었다는 뜻이지 모든 게시물을 선택했다는 뜻이 아닙니다. 빠진 글은 내부 링크, 공개 상태, 대표 URL, 콘텐츠 고유성까지 함께 진단합니다.
사이트맵 신호 충돌
관측 증거: 사이트맵에 리디렉션, 삭제, noindex 또는 교차 canonical URL이 섞여 있습니다. 먼저 각 항목의 최종 응답과 선언 대표를 수집하고, 검색에 남길 200·색인 허용 대표만 유지합니다. 이동 URL은 최종 목적지로 교체하고 삭제·noindex URL은 목록에서 뺍니다.
제출 성공은 색인 승인이 아니므로 재제출을 반복하지 않습니다. 호스트와 프로토콜이 Search Console 속성에 맞는지, 핵심 내부 링크가 같은 대표를 가리키는지 파일 전체와 표본 링크로 대조합니다. 발견되지 않은 대표만 사이트맵·허브 링크를 보강하고, 크롤링 이후 미색인은 응답·대표성·본문 고유성 진단으로 넘깁니다.
robots.txt는 요청 경로 규칙이지 삭제 도구가 아닙니다
robots.txt는 크롤러가 특정 경로를 요청해도 되는지 알려 줍니다. 차단된 URL은 본문을 가져오지 못하므로 메타 로봇 지시와 canonical을 확인할 수 없습니다. 다른 페이지의 링크 등으로 주소 자체가 알려질 수도 있어, 차단만으로 검색 결과 제거를 보장해서는 안 됩니다.
robots.txt 소개에 맞춰 경로 패턴과 적용 사용자 에이전트를 읽습니다. 규칙 문법을 추측하지 말고 Google의 테스트 또는 실제 URL 검사로 표본을 확인합니다. CSS, 이미지, 스크립트처럼 렌더링에 필요한 자원을 넓게 막는 규칙은 특히 피합니다.
robots 차단으로 검색 제거 기대
관측 증거: Disallow는 보이지만 주소가 검색 결과에 남거나 본문 지시를 확인할 수 없습니다. 판단 순서는 URL의 존속 여부, 검색 제외 필요, 크롤 제한 필요입니다. 존재하는 문서를 검색에서 빼려면 먼저 차단을 풀고 HTML 메타 또는 X-Robots-Tag의 noindex가 실제 응답에 있는지 확인합니다.
robots.txt는 요청 제어이지 삭제 명령이 아닙니다. 외부 링크로 주소만 알려질 수 있고 차단 상태에서는 noindex와 canonical을 읽지 못합니다. 긴급 숨김은 Search Console 삭제 도구를 임시 보조 수단으로 쓸 수 있지만, 영구 처리는 noindex, 404·410, 또는 실질 대체 문서로의 이동 가운데 URL 목적에 맞는 방식으로 닫습니다.
렌더링 자원 경로 차단
관측 증거: URL은 열리지만 Google 렌더링 화면이 브라우저와 다르거나 대표 이미지와 본문 요소가 빠집니다. 성능 최적화나 크롤 절약 실험을 중단하고 렌더링 결과의 차단 요청에서 CSS, 스크립트, 이미지의 실제 호스트와 경로를 식별합니다. 필요한 자원 범위부터 허용하며 추측으로 다른 디렉터리를 추가 차단하지 않습니다.
복원 뒤에는 모바일 렌더링 화면, 자원 응답 코드, robots 허용을 함께 확인합니다. 이미지 사이트맵이나 HTML의 이미지 주소는 차단을 상쇄하지 못합니다. CDN 호스트가 본문 호스트와 다를 수 있으므로 대표 이미지와 본문 이미지 표본을 따로 요청하고, 사용자 화면과 렌더링 결과가 일치할 때 기술 복구를 닫습니다.
noindex는 크롤링 가능한 응답에서 읽혀야 합니다
noindex는 검색 색인에 페이지를 남기지 말라는 직접 지시지만, Google이 응답을 가져와 지시를 읽을 수 있어야 합니다. robots 차단과 동시에 적용하면 제거가 지연되거나 의도를 확인하지 못할 수 있습니다. 중요한 게시물의 색인 누락에서는 HTML 메타와 HTTP 헤더 양쪽에 의도치 않은 제외가 없는지 봅니다.
noindex를 해제한 뒤에는 페이지가 성공 응답을 주고, robots에서 허용되며, 대표 URL이 자기 자신 또는 의도한 주소를 가리키는지 재검사합니다. 해제 자체가 즉시 색인이나 순위를 보장하지는 않습니다. 발견 경로와 내용 가치가 별도로 필요합니다.
삭제, noindex, canonical의 경계를 지킵니다
페이지가 존재하고 사용자에게는 필요하지만 검색에만 제외하려면 noindex가 후보입니다. 페이지가 영구 삭제되었다면 삭제 의미의 HTTP 응답이 더 명확합니다. 비슷한 여러 주소 중 대표만 정하려면 canonical 문제이며, 비대표 페이지를 검색에서 빼려는 편법으로 noindex와 canonical을 무작정 겹치지 않습니다.
오래된 글을 새 글로 이동시킬 때도 내용이 실질적으로 대응해야 합니다. 관련 없는 주소를 홈으로 보내는 것은 사용자에게도 혼란이고 soft 404로 해석될 수 있습니다. 목표가 무엇인지에 따라 하나의 주된 처리 방식을 선택합니다.
robots와 noindex 동시 적용
관측 증거: 제외하려는 URL이 robots에도 막혀 있어 Google이 최신 noindex를 읽지 못합니다. 대상 경로의 Disallow를 철회하고 라이브 검사에서 성공 응답, HTML 또는 HTTP 헤더의 noindex, 의도한 canonical을 차례로 확인합니다. 보고서가 과거 크롤 시각이면 새 규칙을 겹치지 말고 라이브 증거와 갱신 시각을 분리해 기록합니다.
URL이 계속 존재하고 noindex를 영구 제외 수단으로 쓴다면 Google이 최신 지시를 읽을 수 있도록 robots 접근도 계속 허용해야 합니다. 크롤 자체를 막아야 한다면 인증, 삭제 응답, URL 폐기처럼 목적에 맞는 처리로 전환하며 robots 차단을 noindex의 후속 단계로 사용하지 않습니다.
삭제 상태와 URL 삭제 도구 혼동
관측 증거: 없앤 문서가 빈 200으로 열리거나 삭제 도구 사용 뒤에도 사이트맵에 남아 있습니다. 실질적으로 대응하는 새 문서가 있으면 한 번의 영구 이동으로 연결하고, 없다면 사용자 안내가 있는 404 또는 410을 반환합니다. 관련 없는 홈 이동이나 빈 안내 200에 noindex를 덧대어 삭제 의미를 흐리지 않습니다.
Search Console 삭제 요청은 긴급하게 노출을 숨기는 임시 조치이지 서버 상태의 대체가 아닙니다. 사이트맵과 내부 링크에서 없어진 URL을 제거한 뒤 직접 요청으로 응답을 검증합니다. 임시 장애라면 삭제 처리 대신 5xx 의미를 유지하며, 복구 완료는 삭제 도구 화면이 아니라 지속되는 HTTP 상태와 발견 신호 정리로 판정합니다.
canonical 목적지가 noindex
관측 증거: 비대표 URL이 가리키는 목적지가 noindex, robots 차단, 오류 또는 리디렉션 상태입니다. 먼저 장기 대표 후보가 직접 200을 반환하고 크롤 가능하며 완전한 본문과 색인 허용 상태를 갖는지 확인합니다. 목적지를 검색에 남길 의도라면 noindex를 제거한 뒤 Google이 읽을 수 있게 접근을 유지합니다.
목적지의 제외가 의도라면 그 URL을 대표로 쓰지 말고 다른 장기 대표를 선택합니다. 이어 canonical, 사이트맵, 내부 링크를 같은 주소로 정렬합니다. noindex와 canonical을 비대표 제거 수단으로 함께 얹지 않으며, 대표 후보의 상태를 먼저 확정하고 나서 주변 신호를 바꾸는 순서를 지킵니다.
Blogger 자동 URL 유형을 표본으로 검사합니다
게시물, 독립 페이지, 라벨, 날짜 아카이브, 내부 검색, 피드, 모바일·추적 변형을 나눠 봅니다. 플랫폼 기본 처리를 전부 덮어쓰려 하지 말고, 각 유형의 현재 응답과 로봇 지시, 대표 URL을 먼저 확인합니다. 맞춤 테마의 조건문이 게시물까지 noindex로 만드는 사고가 흔한 고위험 지점입니다.
전역 맞춤 로봇 헤더와 맞춤 robots.txt는 적용 범위가 넓습니다. 특정 라벨 하나의 문제를 해결하려고 전체 검색·아카이브 규칙을 바꾸지 않습니다. Blogger 도움말에서 지원 범위를 확인하고, 저장 전 기존 값을 그대로 복사해 둡니다.
테마 변경은 미리보기나 별도 스테이징 표본에서 먼저 검사하되, 비공개 환경의 결과를 공개 배포 결과로 대신하지 않습니다. 공개 전에는 게시물·라벨·검색 URL의 예상 지시를 확인하고, 공개 직후에는 비로그인 상태에서 실제 robots.txt와 렌더링 HTML을 다시 읽어 저장값과 배포값이 같은지 확인합니다.
색인 누락 진단은 사이트맵 제출부터 시작하지 않습니다
URL 검사에서 Google이 주소를 아는지, 크롤링이 허용되는지, 마지막 응답과 색인 지시가 무엇인지 순서대로 봅니다. 발견되지 않았다면 링크와 사이트맵을, 차단됐다면 robots를, 제외 지시가 있다면 noindex를 확인합니다. 크롤링됨 이후 미색인이라면 대표성·중복·품질 검토로 넘어갑니다.
이 순서를 지키면 사이트맵을 재제출해 robots 차단을 고치려 하거나, noindex를 robots 규칙으로 제거하려는 오진을 막습니다. Search Console 보고서의 상태는 원인 전체가 아니라 관측된 결과일 수 있으므로 라이브 응답과 설정을 함께 봅니다.
보고서와 라이브 결과가 다르면 마지막 크롤 시각부터 비교합니다. 공개 robots.txt의 호스트·프로토콜, 실제 응답, 확인 시각을 함께 저장하고 과거 상태가 갱신되기 전에 새 수정을 겹치지 않습니다. 설정 화면의 저장 완료보다 외부에서 읽은 배포 결과를 우선 증거로 삼습니다.
변경 전 백업과 영향 범위를 고정합니다
현재 robots.txt 원문, Blogger 로봇 설정 화면, 테마, 사이트맵 제출 내역, 정상·문제 URL의 검사 결과를 저장합니다. 변경할 규칙이 어떤 URL 패턴에 맞는지 표본 목록을 만들고, 중요한 게시물이 포함되면 배포를 중단합니다.
하나의 변경 묶음에는 하나의 목적만 둡니다. robots 허용과 noindex 해제, URL 변경을 한꺼번에 하면 재크롤링 후 어떤 신호가 작동했는지 알 수 없습니다. 전역 규칙은 소수 URL의 불편보다 잠재 피해가 크므로 보수적으로 다룹니다.
Blogger 전역 규칙 사고
관측 증거: 라벨 하나를 고치려던 맞춤 robots.txt, 로봇 헤더 또는 테마 조건이 정상 게시물까지 차단하거나 noindex로 만듭니다. 추가 편집을 멈추고 저장 전 robots 원문·테마·설정값으로 되돌립니다. 개별 글을 하나씩 고치면 공통 원인을 숨기므로 전역 변경점을 먼저 복원합니다.
게시물, 독립 페이지, 라벨, 아카이브, 내부 검색, 피드에서 각각 표본을 골라 200 여부, robots 허용, noindex 부재를 확인합니다. 공개 /robots.txt를 비로그인 상태에서 읽어 설정 화면과 비교하고 사용자 에이전트 그룹과 경로 접두어를 점검합니다. 기본 출력이 정상인 뒤에도 꼭 필요한 최소 예외만 하나씩 배포합니다.
복구 절차는 먼저 읽게 하고 그다음 포함시킵니다
실수로 제외된 게시물은 robots 차단을 풀어 Google이 응답을 읽게 하고, 의도치 않은 noindex를 제거하며, 성공 응답과 대표 URL을 확인합니다. 이후 관련 허브 링크와 올바른 사이트맵 항목을 확인하고 URL 검사를 요청할 수 있습니다. 요청은 재처리 신호일 뿐 강제 명령이 아닙니다.
제외가 목적이었던 URL이 남아 있다면 반대 순서를 씁니다. 먼저 크롤링을 허용해 noindex를 읽을 수 있게 하고, 실제 제외 상태가 갱신되는지 확인합니다. 이후 불필요한 크롤링 관리가 정말 필요한지 별도로 판단합니다. 삭제 문서는 삭제 응답 검증으로 종료합니다.
롤백 조건은 정상 URL 피해와 렌더링 손상입니다
변경 후 정상 게시물이 차단되거나 noindex가 되고, 렌더링 자원이 실패하거나, 사이트맵에서 대표 게시물이 대량 누락되면 즉시 새 전역 설정을 되돌립니다. 설정 화면의 저장 성공만 믿지 말고 외부에서 제공되는 robots.txt와 표본 응답을 확인합니다.
롤백 후에는 이전 원문이 정확히 복원됐는지, 캐시된 검사 결과가 아닌 실시간 테스트에서 접근되는지 봅니다. 검색 보고서 회복에는 재처리가 필요할 수 있으므로 운영자가 임의의 고정 기간을 약속하지 않습니다.
롤백 후 정상화 미확인
관측 증거: 정상 URL 대량 제외, 렌더링 손상 또는 대표 게시물의 사이트맵 누락이 같은 배포 시점에 시작됐습니다. 즉시 최근 전역 로봇 설정과 테마를 백업본으로 되돌리고 개별 본문 수정과 재크롤 요청을 중단합니다. 사고 시작 시각, 변경값, 복원 시각을 남겨 보고서 지연과 새 장애를 구분합니다.
롤백은 저장 알림으로 끝나지 않습니다. 새 세션에서 공개 robots.txt를 읽고 핵심 게시물의 200, 접근 허용, noindex 부재, 렌더링 자원 로드를 확인합니다. 사이트맵의 대표 URL 집합도 이전 상태와 대조합니다. 라이브 결과가 정상이어도 과거 크롤 기반 보고서는 늦게 바뀔 수 있으므로 기술 정상화와 검색 노출 회복을 별도 항목으로 관찰합니다.
검증 매트릭스로 도구별 성공 조건을 닫습니다
사이트맵은 읽기 성공, 대표 URL 포함, 제외·이동 URL 부재를 봅니다. robots는 의도한 경로만 차단하고 핵심 본문과 렌더링 자원을 허용하는지 봅니다. noindex는 대상 응답에서 실제로 읽히고, 포함 대상에는 남지 않았는지 봅니다. HTTP 응답과 canonical은 별도 열로 기록합니다.
noindex로 색인 차단하기의 전제처럼 접근 가능성을 함께 검증해야 합니다. 각 신호가 제 역할을 할 때만 완료로 표시하며, 검색 노출 변화는 그 뒤의 별도 관찰 항목으로 둡니다.
운영 규칙은 최소화하고 문서화합니다
robots 규칙에는 경로, 목적, 추가일, 검증 URL, 롤백 방법을 남깁니다. noindex 조건에는 적용 URL 유형과 예외를 기록합니다. 사이트맵은 플랫폼 자동 생성 여부와 제출 속성을 문서화합니다. 담당자가 바뀌어도 왜 막았는지 설명할 수 없는 규칙은 장기 위험입니다.
최종 확인 질문은 세 가지입니다. Google이 알아야 할 대표 URL이 사이트맵과 링크에 있는가, 가져와야 할 자원을 robots가 허용하는가, 검색에서 제외할 문서의 noindex 또는 삭제 의미를 Google이 실제로 읽을 수 있는가. 이 답이 엇갈리면 발행보다 복구가 먼저입니다.
발행 전 체크리스트
- URL마다 발견, 접근 제한, 검색 제외, 영구 삭제 중 한 가지 주목표를 적었습니다.
- 검색 제외 URL은 먼저 robots 허용 상태에서 noindex를 읽을 수 있게 했습니다.
- 사이트맵에는 200 응답의 색인 가능한 대표 URL만 남겼습니다.
- 게시물·라벨·검색·아카이브와 CSS·스크립트·이미지를 전역 규칙 표본에 넣었습니다.
- 삭제 도구를 썼더라도 404·410 또는 관련 대체 문서로의 직접 이동을 별도로 확인했습니다.
- 공개 robots.txt, 원본·렌더링 HTML, HTTP 헤더를 저장값과 대조했습니다.
- 정상 게시물 차단이나 렌더링 손상이 나오면 즉시 되돌릴 백업을 확인했습니다.