URL이 'NOINDEX'로 표시됨: 고칠 때와 그대로 둘 때

'URL이 'NOINDEX'로 표시됨'은 Google이 페이지를 크롤링하다가 색인하지 말라는 지시를 발견했고, 그 지시를 따랐다는 뜻입니다. 대부분의 사이트에서 이 상태의 URL은 대부분 올바르게 분류된 것입니다. 결제 페이지, 계정 페이지, 사이트 내부 검색결과는 원래 Google에 나오지 않아야 합니다. 문제가 되는 것은 검색에 나오기를 원하는 페이지가 목록에 있을 때, 또는 귀하의 XML 사이트맵이 Google에 오지 말라고 말하는 페이지를 제출하고 있을 때입니다.

이 상태의 의미와 예전 이름

Google의 페이지 색인 생성 보고서 문서(2026년 10월 확인)는 'URL이 'NOINDEX'로 표시됨'을 페이지의 색인이 생성되지 않은 이유 중 하나로 들고, 한 줄로 설명합니다. "Google에서 페이지의 색인을 생성하려고 할 때 'noindex' 지시어가 발견되어 색인을 생성하지 않았습니다." 같은 문서는 페이지가 색인되기를 원하지 않는다면 아무것도 바꿀 필요가 없고, 원한다면 지시어를 제거하라고 말합니다.

이 지시어는 2가지 위치에서 Google에 전달될 수 있습니다.

• HTML 안의 robots 메타 태그: <meta name="robots" content="noindex">, 또는 Google에만 적용되는 <meta name="googlebot" content="noindex">.
• HTTP 응답의 헤더: X-Robots-Tag: noindex. Google은 none 값도 인정하며 이를 noindex, nofollow로 처리합니다. X-Robots-Tag: googlebot: noindex처럼 특정 크롤러 하나만 대상으로 할 수도 있습니다.

Google은 읽을 수 있는 규칙만 따를 수 있습니다. robots.txt로 차단된 페이지는 아예 가져오지 않으므로, 그 페이지의 noindex도 절대 보이지 않습니다. 이는 다른 상태이며 robots.txt와 크롤링 접근 가이드에서 다룹니다.

'‘NOINDEX’ 태그에 의해 차단됨'(Excluded by 'noindex' tag)으로 검색하셨다면, 같은 상태를 예전 이름으로 보고 계신 것입니다. Google이 2022년에 보고서를 개편하기 전, 즉 색인 생성 범위 상태 보고서 시절에는 이 상태가 "Excluded" 그룹에 '‘NOINDEX’ 태그에 의해 차단됨'으로 있었고, 사이트맵으로 제출된 noindex 페이지는 '제출된 URL이 'NOINDEX'로 설정됨'이라는 별도의 오류로 다뤘습니다. 문제 분류 개편에 관한 Google 도움말 페이지는 각 '제출된' 오류가 그에 대응하는 제외 항목과 합쳐져 하나의 문제가 되었다고 설명합니다.

문제인가요? 고칠지, 둘지, 지켜볼지

무엇이든 바꾸기 전에 각 URL의 용도부터 정하십시오.

flowchart TD
    A["URL이 'NOINDEX'로 표시됨"] --> B{"이 페이지가 Google에 나와야 하나요?"}
    B -->|아니요| C{"XML 사이트맵에 들어 있나요?"}
    C -->|아니요| D["그대로 둠. 상태가 올바름"]
    C -->|예| E["사이트맵에서 제거"]
    B -->|예| F{"실시간 테스트에 아직 noindex가 보이나요?"}
    F -->|아니요| G["이미 수정됨. 색인 생성을 요청하고 재크롤링 대기"]
    F -->|예| H{"어디에서 감지되었나요?"}
    H -->|robots 메타 태그| I["템플릿, CMS 설정, 플러그인 수정"]
    H -->|X-Robots-Tag 헤더| J["서버, CDN, 호스팅 규칙 수정"]

noindex는 어디서 오는가

1. 의도적으로 넣은 경우. 검색 가치가 없는 페이지, 비공개 페이지, 중복 보기는 설계상 noindex가 지정됩니다. 정상적인 사이트라면 이 보고서의 URL 대부분이 여기에 해당합니다.

2. 스테이징 설정이 출시 후에도 남은 경우. noindex 상태로 개발한 사이트는 템플릿, 환경 파일, 테마 옵션이 그대로 운영 환경에 넘어가면 noindex도 함께 유지됩니다. 방문자는 아무것도 눈치채지 못하는 사이, 페이지는 다시 크롤링되는 대로 Google에서 빠져나갑니다.

3. 사이트 전체에 적용되는 CMS 설정. WordPress에는 설정 > 읽기 아래에 '검색 엔진이 이 사이트를 색인하지 않도록 합니다' 체크박스가 있습니다. WordPress 문서에 따르면 버전 5.3부터 이 옵션은 사이트 페이지의 head에 noindex,nofollow robots 메타 태그를 추가하며, 현재 버전은 작은따옴표로 <meta name='robots' content='noindex, nofollow' />를 출력합니다. 스테이징 사본에서 체크해 둔 상자 하나가 데이터베이스 가져오기로 운영 환경에 넘어가는 것만으로 충분히 문제가 생깁니다.

4. 플러그인과 테마의 기본값. SEO 플러그인과 테마는 태그 아카이브, 작성자 아카이브, 미디어 첨부파일 페이지, 페이지로 나뉜 목록처럼 콘텐츠 유형별로 색인 여부를 제어하는 경우가 많습니다. 업데이트, 설정 가져오기, 기본값 변경 하나로 URL 그룹 전체가 한꺼번에 noindex로 바뀔 수 있으며, 그래서 수치가 서서히 늘기보다 갑자기 뛰는 경향이 있습니다.

5. 아무도 보지 못하는 X-Robots-Tag 헤더. 이 헤더는 웹 서버, CDN, 호스팅 플랫폼에서 설정되므로 페이지 소스에는 나타나지 않습니다. 흔한 출처는 PDF용으로 만든 헤더 규칙이 모든 경로에 일치하는 경우, 운영 호스트에 남은 스테이징 규칙, 미리보기 배포에 X-Robots-Tag: noindex를 자동으로 붙이는 호스팅 플랫폼입니다. 페이지 소스는 깨끗한데 Search Console이 계속 noindex를 보고한다면 헤더를 확인하십시오.

6. JavaScript로 제거하려는 경우. 일부 싱글 페이지 애플리케이션은 초기 HTML에 noindex를 넣어 보낸 뒤 로드 후 JavaScript로 제거합니다. Google의 JavaScript SEO 문서는 Google이 noindex를 보면 렌더링과 JavaScript 실행을 건너뛸 수 있으므로, 제거 코드가 아예 실행되지 않을 수 있다고 경고합니다. 제공된 HTML과 렌더링된 HTML 사이의 더 넓은 차이는 JavaScript 렌더링 가이드에서 다룹니다.

심각한 경우: 사이트맵이 제출하는 noindex 페이지

사이트맵은 색인되기를 원하는 URL 목록이며, 그중 하나에 noindex가 있다면 정반대를 말하는 셈입니다. Google은 noindex를 따르며, 이 모순은 그 페이지에 대해 귀하의 시스템끼리 의견이 다르다는 것을 보여 줍니다.

2026년 5월부터 10월 사이에 SEOReport가 사이트맵 페이지를 가져온 외부 웹사이트 29곳 중 4곳(14%)은 자체 XML 사이트맵에 noindex가 지정된 페이지를 하나 이상 넣어 두었습니다. 우리가 본 패턴은 쇼핑몰의 장바구니, 결제, 계정 페이지가 사이트맵에 남아 있는 경우였습니다. 같은 감사에서 홈페이지는 깨끗했습니다. 2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 홈페이지 45곳 중 메타 태그나 X-Robots-Tag 헤더에 noindex가 있는 곳은 한 곳도 없었습니다. 찾아볼 가치가 있는 noindex 문제는 사이트 더 깊은 곳에 있습니다.

Search Console에서 이 부분만 보려면 페이지 색인 생성 보고서를 열고 차트 위의 필터를 '알려진 모든 페이지'에서 '제출된 모든 페이지'로 바꿉니다. 귀하가 제출했거나 robots.txt에 나열한 사이트맵에 들어 있는 URL은, Google이 링크를 통해서도 찾았더라도 제출된 URL로 집계됩니다. 이 필터를 켠 상태에서 'URL이 'NOINDEX'로 표시됨' 아래에 남는 URL은 모두 결정이 필요합니다. noindex를 제거하거나, 사이트맵에서 URL을 빼십시오. 자동 생성 사이트맵에 색인 가능한 URL만 들어가게 하는 방법은 XML 사이트맵 가이드에서 설명합니다.

표준 태그나 대체 언어 링크가 noindex 페이지를 가리킬 때도 같은 모순이 생깁니다. 사이트 전체에서 나타나는 이런 조합은 색인 생성 가능성 충돌 분석에서 다룹니다.

어떤 원인인지 확인하는 방법

URL 검사부터 시작합니다. 결과의 페이지 색인 생성 섹션에 있는 '색인 생성 허용 여부' 필드가 이유를 알려 줍니다. 예를 들어 "'robots' 메타 태그에서 'noindex'가 감지됨" 또는 "'X-Robots-Tag' http 헤더에서 'noindex'가 감지됨"과 같습니다. 이 한 줄로 HTML을 봐야 할지 서버 설정을 봐야 할지 알 수 있습니다.

날짜를 확인합니다. 기본 결과는 Google이 마지막으로 크롤링한 버전이며, '마지막 크롤링' 필드가 그 시점을 보여 줍니다. 그 날짜 이후에 페이지를 바꿨다면 결과는 이전 페이지를 설명하고 있는 것입니다.

실시간 테스트를 실행합니다. '실시간 URL 테스트'를 선택한 다음 '테스트한 페이지 보기'를 엽니다. 실시간 테스트는 Google이 지금 받는 HTML과 HTTP 응답 헤더를 보여 주며, 브라우저에는 절대 표시되지 않는 헤더도 포함됩니다. 사이트맵이나 참조 페이지는 확인하지 않으며, 이는 색인된 결과에서 확인합니다.

터미널에서 재현합니다. 다음 2개의 명령은 어떤 URL이든 헤더와 메타 태그를 보여 줍니다. WordPress는 작은따옴표로 태그를 쓰기 때문에, 두 번째 패턴은 작은따옴표와 큰따옴표를 모두 찾습니다.

# Response headers only: look for x-robots-tag
curl -s -D - -o /dev/null https://www.example.com/pricing/ | grep -i "x-robots-tag"

# Robots meta tags in the HTML the server returns
curl -s https://www.example.com/pricing/ | grep -i -o -E "<meta[^>]*name=[\"']?(robots|googlebot)[\"' >][^>]*>"

두 명령 모두 아무것도 출력하지 않는다면 서버가 curl에 noindex를 보내지 않았다는 뜻입니다. 그런데도 Search Console 결과가 다르다면 curl -s 뒤에 -A "Googlebot"을 추가해 두 명령을 다시 실행하십시오. 일부 서버와 CDN은 크롤러 사용자 에이전트에 다르게 응답합니다.

결과는 함께 읽습니다.

원인별로 고친 뒤 확인하기

• CMS 설정: 운영 사이트에서 '검색 엔진이 이 사이트를 색인하지 않도록 합니다'를 해제하고, 스테이징을 운영 환경으로 복사할 때마다 다시 확인합니다.
• 플러그인 또는 테마 설정: 해당 콘텐츠 유형이나 아카이브를 다시 색인 가능으로 설정한 뒤, 샘플 URL 1개에서 서버가 반환하는 HTML에 태그가 사라졌는지 확인합니다.
• 템플릿 또는 환경 변수: 운영 환경을 기본값으로, noindex를 예외로 두어, 설정 하나가 빠졌다고 운영 사이트가 숨겨지는 일이 없게 합니다.
• X-Robots-Tag 헤더: 웹 서버, CDN, 호스팅 플랫폼에서 규칙을 찾아, 스테이징 호스트 이름이나 색인을 원하지 않는 PDF 파일처럼 필요한 경로로만 범위를 좁힙니다.
• JavaScript로 제거하는 경우: 색인되기를 원하는 페이지의 초기 HTML에서 noindex를 뺍니다.
• 사이트맵에 들어 있는 의도된 페이지: noindex는 유지하고 사이트맵에서 URL을 뺍니다.

삭제하고 싶은 페이지에 robots.txt Disallow를 추가하지 마십시오. Google이 noindex를 볼 수 없게 되고, 페이지는 여전히 검색결과에 나타날 수 있습니다.

그다음 이 순서로 확인합니다. 먼저, 실시간 테스트를 다시 실행해 '색인 생성 허용 여부'가 이제 '예'로 표시되는지 확인합니다. 둘째, 가장 중요한 수정 페이지에 '색인 생성 요청'을 사용합니다. Search Console에는 이 요청의 일일 한도가 있으며, Google의 URL 검사 문서에 따르면 색인 생성에는 보통 하루 정도 걸리지만 훨씬 더 오래 걸릴 수도 있습니다. 셋째, 페이지 색인 생성 보고서에서 해당 문제의 '수정 결과 확인'을 선택합니다. Google 문서에 따르면 확인에는 보통 최대 약 2주가 걸리며 때로는 훨씬 더 오래 걸립니다.

한 가지 주의할 점이 있습니다. 확인 절차는 문제 아래 나열된 URL을 다시 검사하며, 남아 있는 사례를 발견하면 Google이 확인을 중단합니다. 목록에 의도적으로 noindex를 유지하는 페이지도 들어 있다면 확인은 통과하지 못합니다. 그럴 때는 수정한 URL을 URL 검사에서 하나씩 추적하며 색인됨으로 옮겨 가는지 지켜보십시오.

Search Console은 Google이 어떤 URL을 제외했는지, 그리고 URL 1개씩 어디서 규칙을 찾았는지 보여 줍니다. SEOReport 전체 진단은 사이트맵에 나열된 페이지를 읽어 robots 메타 태그에 noindex가 있는 페이지를 모두 짚어 내며, 살펴본 페이지 수도 함께 알려 줍니다. 홈페이지에서는 메타 태그와 X-Robots-Tag 헤더를 모두 읽고, 홈페이지의 표준 태그가 noindex 페이지를 가리키는지 확인하며, noindex 페이지를 가리키는 대체 언어 링크도 표시합니다. 그 결과 의도한 것과 실수인 것으로 나눌 목록 1개를 얻게 됩니다. URL을 하나씩 확인하는 것은 AI 세션 하나로 웹사이트 전체를 감사할 수 없는 이유에서 설명한 것과 같은 규모의 문제입니다.

자주 묻는 질문

noindex를 쓰면 Google이 페이지를 크롤링하지 않나요?

아닙니다. Google은 규칙을 읽으려면 페이지를 크롤링해야 합니다. Google이 특정 섹션을 가져오지 못하게 하는 것은 robots.txt로 결정할 일이며, Google이 반드시 봐야 하는 noindex와 함께 써서는 안 됩니다.

noindex를 제거하면 페이지가 돌아오기까지 얼마나 걸리나요?

Google이 페이지를 다시 크롤링하기 전까지는 아무것도 바뀌지 않으며, Google 문서에 따르면 덜 중요한 페이지는 그때까지 몇 달을 기다릴 수도 있습니다. '색인 생성 요청'은 URL 1개의 재크롤링을 요청하지만, 페이지가 색인된다고 보장하지는 않습니다.

페이지 소스에는 noindex가 없는데 Search Console은 왜 noindex를 표시하나요?

대개 3가지 이유 중 1가지입니다. 결과가 페이지를 고치기 전의 크롤링에서 나왔거나, noindex가 페이지 소스에는 보이지 않는 X-Robots-Tag 헤더로 전달되거나, 서버나 CDN이 Google 크롤러와 귀하의 브라우저에 다르게 응답하는 경우입니다. Google이 지금 받는 HTML과 헤더를 보여 주는 실시간 테스트로 판가름할 수 있습니다.

태그, 카테고리, 작성자 아카이브에 noindex를 지정해야 하나요?

아티클 자체가 주지 못하는 무언가를 검색 사용자에게 주지 못한다면 그렇게 하십시오. 아카이브 유형별로 한 번만 결정하고, 그 결정은 설정 1개로 적용하며, noindex를 지정한 아카이브는 사이트맵에서 빼십시오.