noindex 태그에 의해 제외됨은 구글 서치콘솔 색인 생성 보고서에 표시되는 상태 메시지로, 해당 페이지에 색인을 금지하는 robots 메타 태그가 붙어 있어 구글이 검색 결과에서 의도적으로 제외했다는 뜻입니다. 구글이 페이지를 못 찾은 것도, 품질이 낮다고 판단한 것도 아닙니다. 내 사이트가 구글에게 직접 "이 페이지는 색인하지 말라"고 지시한 상태입니다.
이 메시지가 다른 색인 오류와 결정적으로 다른 점은 원인이 100% 내 쪽에 있고, 따라서 100% 해결 가능하다는 것입니다. 콘텐츠 품질을 몇 달에 걸쳐 끌어올려야 하는 문제가 아니라 설정 한 줄을 찾아 지우면 되는 문제입니다. 문제는 그 한 줄이 어디에 숨어 있는지 찾기가 의외로 까다롭다는 데 있습니다. 이 글은 링크어소리티가 실제 진단 과정에서 반복적으로 마주친 발생 위치와 해제 절차를 순서대로 정리한 실무 가이드입니다. 색인 문제 전반의 지도가 필요하다면 구글 색인 안 됨 원인과 조치법을 먼저 훑어보시면 이 글의 위치가 더 명확해집니다.
noindex 태그에 의해 제외됨이란? 메시지의 정확한 의미#
이 상태는 구글이 페이지를 정상적으로 크롤링했고, 내용도 읽었지만, 페이지에 담긴 색인 금지 지시를 존중해 검색 데이터베이스에 등록하지 않았다는 뜻입니다. 다시 말해 크롤링은 성공, 색인은 자발적 거부입니다.
색인 관련 상태 메시지는 비슷해 보이지만 의미가 전혀 다릅니다. 아래 표에서 내 상황이 어디에 해당하는지 먼저 확인하세요.
| 상태 메시지 | 크롤링 | 색인 | 원인의 소재 |
|---|---|---|---|
| noindex 태그에 의해 제외됨 | 성공 | 거부 | 내 사이트의 명시적 지시 |
| robots.txt에 의해 차단됨 | 실패 | 불가 | 내 사이트의 크롤 차단 |
| 크롤링됨-현재 색인 생성 안 됨 | 성공 | 보류 | 구글의 품질 판단 |
| 발견됨-현재 색인 생성 안 됨 | 미실행 | 대기 | 크롤 우선순위 부족 |
표에서 보듯 noindex 제외는 구글의 판단이 개입하지 않는 유일한 항목입니다. 크롤링됨-현재 색인 생성 안 됨처럼 콘텐츠를 보강하며 몇 주를 기다려야 하는 문제와 달리, 원인만 찾으면 즉시 해소됩니다. 그래서 색인 진단을 할 때는 품질형 문제보다 이쪽을 먼저 확인하는 것이 시간을 아끼는 순서입니다.
이 오류가 순위 하락보다 치명적인 이유#
순위가 10위에서 30위로 밀리면 트래픽이 줄어들지만 페이지는 여전히 존재합니다. 반면 noindex로 제외되면 검색 결과에서 페이지가 통째로 사라집니다. 브랜드명으로 검색해도, 페이지 제목을 그대로 붙여넣어도 나오지 않습니다. 유입은 0에 수렴합니다.
더 위험한 것은 이 사고가 조용히 일어난다는 점입니다. 사이트는 정상 작동하고, 방문자는 페이지를 잘 보고, 서버 오류도 없습니다. 리뉴얼 후 몇 주가 지나 "요즘 문의가 없네"라고 느낄 때쯤에야 발견되는 경우가 많습니다. 실제로 사이트 리뉴얼 뒤 유입이 급감해 원인을 찾다 보면, 개발 단계에서 넣어 둔 색인 차단 설정이 운영 서버에 그대로 넘어간 사례가 반복해서 나옵니다. 구글도 색인 생성 차단 공식 문서에서 이 태그의 효력이 절대적임을 명시하고 있습니다.
조치가 필요한 제외와 정상적인 제외 구분하기#
여기서 많은 분들이 실수합니다. 서치콘솔에 빨간 숫자가 떠 있으니 전부 고쳐야 한다고 생각해, 원래 빼 두어야 할 페이지까지 색인시키려 드는 것입니다. noindex 제외 목록에 URL이 있다는 사실 자체는 문제가 아닙니다.
조치 전에 제외된 URL 목록을 두 부류로 나눠 보세요. 다음과 같은 페이지가 목록에 있다면 정상입니다.
- 로그인·회원가입·마이페이지·장바구니: 검색 유입 가치가 없고 개인정보 노출 위험만 있습니다.
- 사이트 내부 검색 결과 페이지: 무한히 생성되며 구글도 색인을 권장하지 않습니다.
- 태그·작성자·날짜 아카이브: 본문 없이 목록만 반복돼 중복 신호가 됩니다.
- 결제 완료·감사 인사 페이지: 단독으로 검색될 이유가 없습니다.
- 광고 랜딩 A/B 사본: 원본과 중복되므로 하나만 색인되면 충분합니다.
반대로 상품 상세, 서비스 소개, 블로그 글, 카테고리 허브가 목록에 들어 있다면 사고입니다. 이 페이지들은 검색 유입의 핵심이므로 즉시 조치해야 합니다. 특히 사이트 전체 URL이 통째로 제외 목록에 잡혔다면 개별 설정 문제가 아니라 사이트 단위 차단이 걸린 것이므로, 아래 원인 중 1번과 2번을 최우선으로 확인하세요.
이 분류 작업은 5분이면 끝나지만, 건너뛰면 며칠을 엉뚱한 곳에 씁니다. 제외 URL을 스프레드시트로 내려받아 "색인되어야 함"과 "제외가 맞음" 두 열로 나누는 것부터 시작하는 것이 실무에서 가장 빠른 길입니다.
noindex가 걸리는 6가지 원인#
조치 대상 URL을 추렸다면 이제 태그가 어디서 붙었는지 찾을 차례입니다. 원인은 대체로 아래 여섯 가지 안에 있습니다.
1. 개발·스테이징 설정이 운영에 그대로 배포됨#
가장 흔합니다. 개발 중인 사이트가 검색에 노출되면 곤란하니 색인 차단을 걸어 두는데, 오픈 시점에 이를 해제하는 절차가 배포 체크리스트에 없어 그대로 넘어갑니다. 코드 기반 사이트라면 환경변수로 분기해 둔 조건이 운영 환경에서도 참으로 평가되는 경우가 여기 해당합니다.
2. CMS의 검색엔진 차단 옵션#
워드프레스에는 설정 화면에 검색엔진 노출을 차단하는 체크박스가 있습니다. 제작 초기에 켜 두고 잊는 경우가 압도적으로 많습니다. 이 옵션 하나로 사이트 전체 페이지에 noindex가 붙습니다. 아임웹·윅스 같은 노코드 빌더에도 동일한 성격의 토글이 있습니다.
3. SEO 플러그인의 일괄 설정 오적용#
Yoast SEO나 Rank Math 같은 플러그인은 게시물 유형·분류 단위로 색인 여부를 일괄 지정할 수 있습니다. 특정 커스텀 포스트 타입 전체를 noindex로 잡아 두면, 그 유형에 속한 페이지가 한꺼번에 제외됩니다. 개별 글의 설정만 확인하고 "이상 없다"고 판단했다가 놓치는 대표적인 지점입니다.
4. 테마·템플릿에 하드코딩된 태그#
공통 head 템플릿에 robots 메타 태그가 직접 박혀 있는 경우입니다. 테마를 수정하거나 외주로 제작한 사이트에서 종종 발견되며, 관리자 화면 어디에도 관련 설정이 없어 찾기가 어렵습니다. 소스 보기로 태그는 확인되는데 설정 화면에서는 원인이 안 나온다면 이쪽입니다.
5. 서버·CDN 응답 헤더의 X-Robots-Tag#
HTML에는 태그가 전혀 없는데 색인이 차단되는 경우입니다. 다음 섹션에서 따로 다룹니다.
6. 자바스크립트가 렌더링 단계에서 주입#
초기 HTML에는 없지만 스크립트 실행 후 robots 태그가 추가되는 경우입니다. 소스 보기로는 안 잡히고 렌더링된 DOM에만 존재합니다. 서치콘솔의 게재된 페이지 테스트에서만 드러나므로 진단 난이도가 가장 높습니다. 이런 렌더링 계층 문제를 포함한 전반적인 기술 점검은 테크니컬 SEO 완벽 가이드에서 체계적으로 다룹니다.
플랫폼별 noindex 해제 방법#
원인을 좁혔다면 해제는 대개 몇 분입니다. 사용 중인 플랫폼에서 확인할 위치를 정리했습니다.
| 플랫폼 | 확인·해제 위치 |
|---|---|
| 워드프레스 | 설정 → 읽기 → 검색엔진 노출 차단 체크 해제, 이후 SEO 플러그인의 글·분류 단위 설정 확인 |
| Next.js·React | metadata의 robots 설정과 환경변수 분기, 프리뷰 전용 조건이 운영에 적용됐는지 점검 |
| 카페24·메이크샵 | SEO 설정 메뉴의 검색엔진 노출 허용 여부, 비공개 상품 분류의 개별 설정 |
| 아임웹·윅스 | SEO 설정의 페이지별 검색엔진 노출 토글, 사이트 공개 상태 확인 |
| Nginx·Apache | 응답 헤더에 X-Robots-Tag를 추가하는 규칙 제거, 경로·확장자 조건 범위 점검 |
| Cloudflare·CDN | 헤더 변환 규칙 확인, 원본 서버가 깨끗해도 엣지에서 덧붙을 수 있음 |
플랫폼과 무관하게 해제 후에는 반드시 검증해야 합니다. 관리자 화면에서 체크를 풀었다고 실제 출력이 바뀌었다는 보장은 없습니다. 캐시 플러그인이나 CDN이 이전 HTML을 계속 내보내는 경우가 흔하기 때문입니다. 캐시를 비운 뒤 시크릿 창에서 페이지 소스를 열어 robots 태그가 사라졌는지 직접 눈으로 확인하는 것이 확실합니다.
HTML에 태그가 없는데 제외되는 경우: X-Robots-Tag#
가장 많은 시간을 잡아먹는 유형입니다. 페이지 소스를 아무리 뒤져도 robots 태그가 없는데 서치콘솔은 계속 noindex로 제외됐다고 표시합니다. 이 경우 범인은 거의 확실히 HTTP 응답 헤더의 X-Robots-Tag입니다.
구글이 색인 금지 지시를 받는 경로는 두 개입니다. 하나는 HTML head의 메타 태그이고, 다른 하나는 서버가 페이지를 내려줄 때 함께 보내는 응답 헤더입니다. 둘의 효력은 동일하지만 가시성이 완전히 다릅니다.
- HTML 메타 태그: 페이지 소스 보기로 즉시 확인됩니다.
- X-Robots-Tag 헤더: 소스 보기에는 전혀 나타나지 않습니다. 브라우저 개발자도구를 열고 네트워크 탭에서 해당 문서 요청을 클릭한 뒤 응답 헤더 목록을 봐야 보입니다.
헤더 방식은 원래 PDF나 이미지처럼 HTML이 아닌 파일의 색인을 제어하려고 만들어졌습니다. 그런데 서버 설정에서 경로 조건을 넓게 잡거나, CDN의 헤더 변환 규칙이 예상보다 많은 요청에 적용되면서 멀쩡한 HTML 페이지까지 휩쓸리는 사고가 생깁니다.
진단 순서는 다음과 같습니다. 먼저 원본 서버에 직접 요청해 헤더를 확인하고, 깨끗하다면 CDN·엣지 레이어를 봅니다. 원본은 정상인데 엣지를 거치면 헤더가 붙는 구조라면 CDN 규칙이 원인입니다. 반대로 원본부터 헤더가 붙어 있다면 웹서버 설정 파일을 봐야 합니다.
한 가지 더 짚을 것은 관리하는 사람이 다를 수 있다는 점입니다. CMS는 마케팅팀이, 서버는 개발팀이, CDN은 인프라 담당이 관리하는 조직에서는 아무도 자기 영역에서 원인을 못 찾습니다. 세 계층을 한 사람이 순서대로 훑어야 해결됩니다.
noindex·robots.txt·canonical, 무엇을 언제 쓰나#
이 세 가지를 혼동해 잘못 조합하면, 태그를 지워도 색인이 돌아오지 않습니다. 각각이 무엇을 막는지 정확히 구분해야 합니다.
| 비교 항목 | noindex | robots.txt Disallow | canonical |
|---|---|---|---|
| 막는 대상 | 색인(등록) | 크롤링(방문) | 아무것도 막지 않음 |
| 크롤링 여부 | 허용해야 작동 | 차단됨 | 허용 |
| 적합한 상황 | 노출은 원치 않지만 페이지는 필요 | 크롤 자원 절약 | 중복 URL을 대표 하나로 통합 |
| 해제 시 반영 | 재크롤 후 수일~2주 | 비교적 빠름 | 재평가 후 반영 |
여기서 반드시 기억할 원칙이 하나 있습니다. noindex와 robots.txt Disallow를 같은 페이지에 함께 걸면 안 됩니다. 크롤링이 막히면 구글봇이 페이지에 접근하지 못하므로 noindex 태그를 읽을 수조차 없습니다. 그 결과 태그를 나중에 제거해도 구글은 변화를 알아채지 못하고, 색인은 계속 돌아오지 않습니다.
그래서 조치 순서가 중요합니다. 색인을 되살리려면 robots.txt의 Disallow를 먼저 풀고, 그다음 noindex를 제거해야 합니다. 반대로 특정 페이지를 검색에서 확실히 빼고 싶다면 크롤은 허용한 채 noindex만 사용하는 것이 정석입니다.
canonical은 성격이 다릅니다. 차단 도구가 아니라 중복 URL 중 무엇을 대표로 볼지 알려 주는 신호입니다. 색인에서 빼려고 canonical을 쓰는 것은 잘못된 사용이며, 구글은 이를 지시가 아닌 힌트로 취급합니다. 세 도구의 역할을 섞어 쓰지 않는 것만으로도 색인 사고의 상당수를 예방할 수 있습니다.
해제 후 재색인 요청과 복귀까지 걸리는 시간#
태그를 지웠다고 다음 날 검색에 나오지는 않습니다. 구글이 페이지를 다시 방문하고, 변경을 확인하고, 색인에 등록하는 과정이 필요합니다.
실무 기준으로 다음 순서를 그대로 따르면 됩니다.
- 해제 배포 직후: 서치콘솔 URL 검사 도구에서 게재된 페이지 테스트를 실행합니다. 실제로 구글이 지금 보는 HTML에서 태그가 사라졌는지 확인하는 단계로, 여기서 여전히 noindex가 잡히면 캐시나 다른 계층에 원인이 남아 있는 것입니다.
- 검증 통과 후 당일: 색인 생성 요청을 누릅니다. 한 번이면 충분합니다. 같은 URL을 반복 요청해도 속도는 빨라지지 않습니다.
- 3~7일: 재크롤이 발생합니다. 권위가 높은 페이지부터 순차적으로 처리됩니다.
- 1~2주: 색인이 복귀하기 시작하고 서치콘솔의 제외 URL 수가 줄어듭니다.
- 4~8주: 순위가 회복됩니다. 색인과 순위는 별개이므로 시간차가 있습니다.
페이지가 수백 개 이상이라면 개별 요청 대신 XML 사이트맵을 재제출하는 것이 정석입니다. lastmod 값을 갱신해 제출하면 구글이 변경된 페이지를 우선 확인합니다. 여기에 상위 권위 페이지에서 내부링크를 걸어 주면 크롤 경로가 강화돼 복귀가 빨라지는데, 구체적인 설계 방법은 내부 링크 최적화 전략에서 다룹니다. 외부에서 들어오는 신규 링크 역시 구글봇을 데려오는 유입 경로로 작용하므로, 복귀를 앞당겨야 하는 상황이라면 티어 링크 빌딩 서비스로 크롤 신호를 함께 보강하는 방법도 있습니다.
네이버 노출까지 함께 살려야 한다면 네이버 서치어드바이저에도 사이트와 사이트맵이 정상 등록돼 있는지 별도로 확인하세요. 검색엔진마다 수집 주기와 반영 방식이 달라, 구글만 조치하고 끝내면 절반만 해결한 셈이 됩니다.
재발을 막는 배포 체크리스트#
한 번 겪으면 다시 겪지 않도록 만드는 것이 진짜 조치입니다. noindex 사고는 예외 없이 배포·리뉴얼 시점에 발생하므로, 그 시점에 걸리는 장치를 만들어 두면 됩니다.
- 배포 체크리스트에 항목으로 넣기: "운영 배포 후 대표 페이지 3개의 robots 태그 확인"을 릴리스 절차에 명시합니다.
- 개발·운영 설정을 코드로 분리: 색인 차단을 사람이 켜고 끄는 체크박스가 아니라 환경변수로 관리해, 운영 환경에서는 구조적으로 켜질 수 없게 만듭니다.
- 서치콘솔 이메일 알림 켜기: 색인 문제가 감지되면 통보받도록 설정해 두면 몇 주씩 방치되는 일을 막을 수 있습니다.
- 주 1회 색인 페이지 수 확인: 색인 수 추이는 사고를 가장 빨리 드러내는 지표입니다. 갑작스러운 감소는 대부분 기술 사고입니다.
- 리뉴얼 직후 2주간 집중 모니터링: 사고 발생 확률이 가장 높은 구간입니다.
서치콘솔의 보고서를 읽고 이상 신호를 조기에 잡는 방법 전반은 구글 서치 콘솔 활용 가이드에 정리돼 있습니다. 페이지 단위의 메타 요소와 색인 설정을 한 번에 정비하고 싶다면 온페이지 SEO 서비스로 전수 점검을 진행할 수 있고, 페이지 수가 수천 단위로 많아 개별 관리가 어려운 사이트라면 프로그래매틱 SEO 방식으로 색인 규칙을 템플릿 레벨에서 통제하는 편이 안전합니다. 색인 제어 태그의 정확한 문법과 지원 값은 구글 로봇 메타 태그 공식 문서에서 확인하시고, 색인 진단 사례는 Ahrefs 블로그의 기술 SEO 자료도 참고할 만합니다.
정리: noindex 태그에 의해 제외됨, 찾으면 끝나는 문제#
noindex 태그에 의해 제외됨은 색인 오류 중 유일하게 원인과 해법이 명확한 항목입니다. 구글의 품질 판단을 기다릴 필요도, 몇 달에 걸쳐 권위를 쌓을 필요도 없습니다. 순서만 지키면 됩니다. 제외 URL 중 정말 색인되어야 할 페이지를 골라내고, HTML 메타 태그와 HTTP 응답 헤더 두 경로를 차례로 확인하고, 플랫폼에 맞게 해제한 뒤, robots.txt 차단이 없는지 점검하고, 색인 생성을 요청하면 됩니다.
가장 흔한 실패는 두 가지입니다. 소스 보기에 태그가 없다는 이유로 X-Robots-Tag를 놓치는 것, 그리고 noindex와 robots.txt Disallow를 함께 걸어 둔 채 태그만 지우고 기다리는 것입니다. 이 두 함정만 피하면 대부분 2주 안에 색인이 돌아옵니다.
혼자 원인을 좁히기 어렵거나 리뉴얼 이후 유입이 급감한 상태라면 링크어소리티가 서치콘솔 데이터와 응답 헤더를 함께 열어 색인 차단 지점을 정밀 진단해 드립니다. 무료 SEO 진단을 신청하시면 noindex 태그에 의해 제외됨을 포함한 색인 문제 전반의 원인과 복구 순서를 정리해 드립니다.