검색엔진최적화 noindex 복구는 원인 설정 제거가 먼저입니다

발행일 2026-11-01 · 넥스트티
검색엔진최적화 noindex 복구는 원인 설정 제거가 먼저입니다

배포 뒤 사이트 전체에 noindex가 남아 있었다면, noindex 복구는 그 규칙을 넣은 설정을 찾아 지우는 일에서 시작합니다. 다음으로 robots.txt가 사이트를 막고 있지 않은지 확인합니다. 이어 Search Console URL 검사의 실시간 테스트로 제거 여부를 검증합니다. 그 뒤 사이트맵으로 재크롤링을 알리고, 페이지 색인 생성 보고서에서 회복 과정을 추적합니다.

robots.txt가 막혀 있으면 Google은 noindex 제거를 볼 수 없습니다. 검색엔진최적화 복구에서 이 순서를 지켜야 하는 이유입니다.

복구 순서와 끝났다고 볼 기준은 무엇인가요

단계마다 끝났다고 볼 기준을 먼저 정해야 합니다. 그래야 담당자가 바뀌어도 같은 판단을 내릴 수 있습니다. 아래 표가 전체 흐름입니다.

순서할 일끝났다고 보는 기준
1. 출처 제거템플릿, 서버 설정, CMS 옵션에서 noindex를 넣는 곳을 찾아 지웁니다유형별 표본 페이지의 원본 HTML과 응답 헤더 어디에도 noindex가 남지 않음
2. robots.txt 확인스테이징용 전체 차단 규칙이 함께 배포되었는지 확인합니다운영 robots.txt에 사이트 전체 차단 규칙이 없음
3. Google 화면 확인URL 검사에서 실시간 테스트를 실행합니다크롤링 허용 여부(Crawl allowed?)와 색인 생성 허용 여부(Indexing allowed?)가 모두 허용으로 표시
4. 재크롤링 알림사이트맵을 다시 제출하고 핵심 URL은 색인을 요청합니다사이트맵 보고서에 처리 오류가 없고 Google이 읽은 날짜가 수정 이후로 표시
5. 회복 추적페이지 색인 생성 보고서에서 수정 검증을 시작합니다검증 상태가 통과(Passed)로 바뀜

noindex는 어디에서 들어왔는지 어떻게 찾나요

Google 문서는 noindex를 넣는 방법을 두 가지로 설명합니다. 하나는 페이지 head의 로봇 메타 태그입니다. 다른 하나는 HTTP 응답의 X-Robots-Tag 헤더입니다. 두 방법은 효과가 같습니다. 헤더 방식은 서버 설정으로 사이트 전체에 한꺼번에 걸 수 있습니다. PDF·이미지 같은 파일에도 적용됩니다.

그래서 HTML 소스만 보고 끝내면 헤더로 걸린 noindex를 놓칠 수 있습니다. 실무에서는 아래 위치를 하나씩 확인하는 방법을 권합니다.

  • 공통 레이아웃·헤더 템플릿의 로봇 메타 태그
  • 웹 서버·CDN 설정에서 전역으로 붙는 X-Robots-Tag 헤더
  • CMS의 검색엔진 노출 차단 옵션과 환경별 설정값
  • 자바스크립트가 나중에 메타 태그를 추가하거나 바꾸는 코드

규칙이 여러 개 겹친 경우도 따져야 합니다. Google 문서에 따르면 규칙이 충돌하면 더 제한적인 쪽이 적용됩니다. 예를 들어 일반 태그는 index인데 Googlebot 전용 태그에 noindex가 남아 있으면, Googlebot은 noindex로 처리합니다. 일반 태그만 고치면 복구되지 않는 이유가 여기에 있습니다.

자바스크립트로 해결하려는 방식도 위험합니다. Google 문서는 noindex를 만나면 렌더링과 스크립트 실행을 건너뛸 수 있다고 설명합니다. 원본 코드에 남은 noindex를 스크립트로 지우는 방식은 예상대로 동작하지 않을 수 있습니다. 서버가 처음 내려주는 HTML에서 제거해야 합니다.

확인 표본은 페이지 유형별로 고릅니다. 예를 들어 가상의 쇼핑몰이라면 홈, 카테고리, 상품 상세, 공지 글, 다운로드용 PDF를 하나씩 정하는 식입니다. 템플릿이 다른 페이지마다 출처가 다를 수 있기 때문입니다. 원본 HTML은 브라우저의 소스 보기나 명령줄 요청으로 확인하고, 응답 헤더도 같은 요청에서 함께 확인합니다.

robots.txt까지 막혀 있었다면 무엇을 먼저 고치나요

스테이징 환경을 통째로 옮기는 배포라면 robots.txt의 전체 차단 규칙이 함께 올라갔을 수 있습니다. Google 문서에 따르면 경로 값 슬래시(/)는 루트와 그 아래 모든 URL에 해당합니다. 즉 User-agent: * 그룹에 Disallow: / 가 있으면 모든 크롤러에 대해 사이트 전체가 크롤링에서 막힙니다. 특정 크롤러용 그룹이 따로 있다면 그 크롤러는 해당 그룹의 규칙을 따르므로, 그룹별로 모두 확인합니다.

이 상태에서는 noindex를 지워도 Google이 그 변화를 볼 수 없습니다. Google 문서는 robots.txt로 막힌 페이지의 메타 태그와 X-Robots-Tag는 읽히지 않는다고 설명합니다. URL 검사에서도 크롤링이 막힌 페이지는 색인 생성 허용 여부가 항상 허용으로 표시됩니다. 이 표시만 보고 복구되었다고 판단하면 안 됩니다.

반영 시간도 고려해야 합니다. Google 문서에 따르면 Google은 robots.txt 내용을 보통 최대 24시간 캐시합니다. 실무에서는 noindex 제거와 robots.txt 수정을 같은 배포에 묶는 방법을 권합니다. 한쪽만 먼저 고치면 확인 결과가 엇갈려 판단이 늦어집니다.

수정이 반영되었는지 Google 화면에서 어떻게 확인하나요

URL 검사 도구의 기본 화면은 Google이 색인한 버전을 보여 줍니다. 이 버전은 현재 페이지보다 오래된 것일 수 있습니다. 수정 결과는 실시간 테스트로 확인해야 합니다. 아래 순서로 진행합니다.

  1. 앞에서 고른 유형별 표본 URL을 하나씩 URL 검사에 입력합니다.
  2. 실시간 테스트를 실행하고 크롤링 허용 여부가 허용인지 확인합니다.
  3. 색인 생성 허용 여부가 허용인지 확인합니다.
  4. 테스트한 페이지 보기에서 HTML과 추가 정보(More info)의 HTTP 응답 헤더를 열어 noindex 문자열이 없는지 확인합니다.
  5. 결과 화면을 캡처해 날짜와 함께 복구 기록에 붙입니다.

Google 문서는 실시간 테스트가 모든 색인 문제를 확인하지는 않는다고 설명합니다. 수동 조치, 콘텐츠 삭제 요청, 일시적으로 차단된 URL 등은 이 테스트에 반영되지 않습니다. 이 단계는 차단이 풀렸다는 사실을 확인하는 단계로 보면 됩니다.

어떤 페이지부터 Google에 다시 알려야 하나요

Google 문서는 재크롤링 요청 방법을 두 가지로 안내합니다. 개별 URL은 URL 검사의 색인 생성 요청을 쓰고, 많은 URL은 사이트맵 제출을 씁니다. 색인 생성 요청에는 속성별 하루 할당량이 있습니다. 같은 URL을 여러 번 요청해도 크롤링이 빨라지지 않는다고 문서는 밝힙니다.

그래서 사이트 전체 사고에서는 사이트맵이 주된 수단입니다. 실무에서는 아래처럼 나누는 방법을 권합니다.

  • 매출·문의와 직결되는 핵심 페이지만 모은 작은 사이트맵을 따로 만듭니다.
  • 그 가운데 상위 몇 개 URL만 색인 생성 요청을 보냅니다.
  • 나머지는 기존 전체 사이트맵을 다시 제출해 맡깁니다.

사이트맵의 lastmod(최종 수정일) 값은 실제로 바뀐 페이지에만 정확하게 적습니다. Google 문서는 lastmod가 꾸준히 정확할 때만 사용한다고 설명합니다. 저작권 연도 변경처럼 작은 수정은 의미 있는 업데이트로 보지 않습니다. 복구를 서두르려고 모든 페이지 날짜를 오늘로 바꾸는 방식은 피하는 편이 안전합니다.

사이트맵 제출은 Search Console 사이트맵 보고서에서 하거나, robots.txt에 Sitemap 줄을 넣어 알릴 수 있습니다. 다만 Google은 사이트맵 제출을 힌트로만 본다고 설명합니다.

회복은 무엇으로 추적하고 언제 끝났다고 보나요

페이지 색인 생성 보고서의 색인되지 않음 항목에는 noindex로 표시된 URL 사유가 따로 나옵니다. 수정을 마쳤다면 이 사유의 상세 화면에서 수정 검증(Validate fix)을 누릅니다. 검증이 끝나기 전에는 다시 누르지 않습니다.

Google 문서에 따르면 수정 검증을 누르면 먼저 일부 페이지를 바로 확인합니다. 표본에 문제가 없으면 검증이 시작됨 상태로 이어집니다. 확인 중 문제가 남은 URL이 하나라도 발견되면 검증은 멈춥니다. 검증은 보통 약 2주까지 걸리고, 경우에 따라 훨씬 길어질 수 있습니다. 실패하면 남은 URL을 찾아 고친 뒤 검증을 다시 시작합니다.

보고서 위쪽의 사이트맵 필터도 활용할 수 있습니다. Google 문서는 사이트맵 필터를 적용한 상태에서 검증을 요청하면, 요청 시점에 그 사이트맵에 있던 항목에만 검증이 적용된다고 설명합니다. 영향받은 URL 일부만 대상으로 한 검증은 전체 대상보다 빨리 끝날 수 있다고도 설명합니다. 앞 단계에서 만든 핵심 페이지 사이트맵이 여기서 쓰입니다.

Google 문서는 크롤링에 며칠에서 몇 주가 걸릴 수 있다고 설명합니다. 그 기간에는 아래 양식으로 매일 같은 항목을 기록하면 팀 안에서 진행 상황을 공유하기 쉽습니다.

기록 항목적는 내용 예시
확인 일시수정 배포 후 경과일과 확인 시각
표본 URL 실시간 테스트유형별 5개 중 허용으로 표시된 개수
noindex 사유 URL 수페이지 색인 생성 보고서의 해당 사유 수치
검증 상태시작됨, 통과, 실패 가운데 현재 상태
다음 조치실패 URL 원인 확인, 검증 재시작 등

공유 문안은 다음처럼 쓰면 됩니다. 「○월 ○일 배포에서 noindex 출처를 제거했습니다. 표본 5개 모두 실시간 테스트에서 색인 허용을 확인했습니다. 핵심 사이트맵 기준으로 수정 검증을 시작했고 결과를 매일 공유합니다.」

다음 배포에서 같은 일을 막으려면 무엇을 바꾸나요

사이트 전체 noindex는 개발·스테이징 환경의 설정이 운영 배포에 함께 넘어갈 때 생길 수 있습니다. 실무에서는 아래 장치를 권합니다.

  • noindex와 robots.txt 차단을 코드에 직접 쓰지 않고 환경별 설정값으로 분리합니다.
  • 배포 직후 홈과 대표 페이지의 응답 헤더와 HTML에서 noindex 문자열을 검사하는 단계를 배포 절차에 넣습니다.
  • 운영 robots.txt 내용을 배포 전후로 비교합니다.
  • 네이버 서치어드바이저를 함께 쓰는 사이트라면 같은 날 그 도구의 사이트맵 제출 상태도 확인합니다.

배포 승인 문서에 「운영 환경 색인 허용 확인」 항목을 한 줄 추가하면 확인 책임이 분명해집니다.

정리

  1. 템플릿, 서버 헤더, CMS 옵션, 스크립트에서 noindex 출처를 찾아 원본 HTML과 헤더에서 지웁니다.
  2. robots.txt의 전체 차단 규칙을 같은 배포에서 제거하고, 최대 24시간의 캐시를 감안합니다.
  3. 유형별 표본 URL을 URL 검사 실시간 테스트에 넣어 크롤링·색인 허용을 확인합니다.
  4. 핵심 페이지 사이트맵을 제출하고, 상위 URL만 색인을 요청합니다.
  5. 페이지 색인 생성 보고서에서 수정 검증을 시작하고, 통과할 때까지 매일 기록합니다.

참고 자료

목록으로