Back to articles

인덱스 가능성 충돌: 귀하의 사이트가 Google에게 떠나라고 말할 때

SEOReport Team·
indexabilitynoindexrobots-txtcanonical-tagstechnical-seoseo-audit

49 감사에서, 42.9% 사이트는 자체 사이트맵을 홍보하면서 페이지를 차단, 리디렉션 또는 noindex 처리합니다. 4 충돌 패턴과 이를 해결하는 순서.

우리가 수행하는 모든 감사는 사이트가 중요하다고 선언한 페이지—홈페이지와 자체 사이트맵에 나열된 URL—에 대해 검색 엔진이 선언대로 인덱스할 수 있는지에 대해 직설적인 질문을 합니다? 5월 5와 August 15, 2026 사이, 21의 49 감사 사이트가 그 질문에 실패했습니다. 이는 42.9%가 크롤러에게 건너뛰라고 지시한 페이지를 게시, 연결 및 나열하는 데 노력을 기울인 샘플의 비율입니다.

실패는 한 가지 서명을 공유합니다: 이 사이트들 중 하나는 인간에게 완벽하게 작동합니다. 페이지가 렌더링되고, 링크가 해결되며, 브라우저에 하위 지시문이 검색 엔진을 떠나게 한다는 힌트가 없습니다. 인덱스 가능성 충돌은 우리 데이터에서 가장 자가 유발된 범주입니다—경쟁자가 원인이 아니고, 알고리즘 업데이트가 트리거하지 않으며, 팀의 누구도 봇처럼 사이트를 가져오지 않으면 볼 수 없습니다.

데이터 세트

중요 페이지 인덱스 가능홈페이지 또는 사이트맵에 나열된 페이지가 선언대로 인덱스될 수 없음21/49 (42.9%)
중요 페이지에 noindex가 있음사이트맵에 나열된 페이지에 noindex 지시문이 있음7/49 (14.3%)
사이트 수준 신호 일관성robots.txt가 크롤러를 차단하거나 홈페이지 자체에 noindex가 있음5/49 (10.2%)
robots.txt가 일반 봇을 허용함robots.txt에 모든 봇에 대해 Disallow: /가 포함됨3/49 (6.1%)

방법론: 현재 체크셋에서 각 도메인별로 최신 완료된 감사 스냅샷, 5월 5 – August 15, 2026 — 49 감사된 사이트, 익명화됨. 체크당 분모는 46에서 49까지 다양하며, 입력이 존재할 때만 체크가 실행되기 때문입니다 — 도달 가능한 사이트맵이 없는 사이트는 사이트맵-페이지 판정이 없습니다. 샘플은 자체 선택된 — 감사를 실행한 소유자들 — 이며 소규모에서 중간 규모로 편향되어 있으므로 해당 세그먼트에 대한 비율을 방향성으로 간주하십시오.

Indexability Conflict Failures Across 49 Audited Sites

리다이렉트와 정규화는 noindex보다 더 많은 실패를 유발합니다

첫 번째 2 행 사이의 격차는 발견입니다. 페이지가 선언된 대로 인덱싱될 수 없는 이유는 4가지입니다: robots.txt에 의해 차단되었거나, noindex 지시어를 포함하거나, 다른 URL로 리다이렉트하거나, 다른 곳을 가리키는 정규화를 선언하는 경우입니다. noindex 문제가 있었던 사이트는 7곳뿐입니다 — 이는 대부분의 21 실패 사이트에서 비인덱스 페이지가 noindex를 전혀 포함하지 않음을 의미합니다. 그들은 sitemap이 약속한 URL에서 벗어나 리다이렉트하거나 Google에게 정규화가 다른 주소에 있음을 알립니다.

그 분포는 팀이 잘못된 원인을 찾도록 하기 때문에 중요합니다. 모든 사람이 아는 단어는 noindex이므로 그 단어가 grep됩니다 — 그리고 결과는 깨끗합니다. 실제 충돌은 보통 구조적입니다: CMS 데이터베이스에서 생성된 sitemap이 라이브 URL이 새로운 경로 체계로 마이그레이션되었거나, 정규화 태그가 실제로 제공되지 않는 URL 변형에 템플릿화된 경우.

무해한 경우는 계산되지 않습니다: 도메인 그대로의 주소에서 www 변형으로 이동하는 것처럼 올바른 인프라인 리다이렉트, 그리고 noindex를 가져야 하는 유틸리티 페이지입니다. 21 실패는 이러한 경우를 제거한 후 남은 것입니다.

데이터에서 4 충돌 패턴

출시된 스테이징 noindex. 7 사이트는 sitemap에 noindex 지시어가 포함된 페이지를 나열합니다 — 메타 robots 태그 또는 X-Robots-Tag 응답 헤더에. 이는 고전적인 출시 잔여물입니다: 스테이징 환경을 올바르게 숨긴 지시어가 템플릿, 플러그인 설정 또는 플랫폼 토글 내부에서 프로덕션으로 이동합니다. WordPress의 "이 사이트를 검색 엔진이 색인화하지 않도록 권장" 체크박스가 대표적인 예입니다 — 단일 설정, 사이트 전체 noindex, 눈에 보이는 차이가 없습니다.

robots.txt가 모든 것을 외치는 경우. 3 사이트는 모든 봇에 대해 Disallow: /를 포함한 robots.txt를 제공합니다 — 사이트 전체의 가라앉히는 표시 — 그리고 5는 더 넓은 일관성 검사를 실패합니다. robots.txt 차단 또는 홈페이지 noindex가 랭크하려는 명백한 의도와 모순됩니다. 이 패턴의 미묘한 함정: robots.txt와 noindex는 반대 작업을 수행하며, 결합하면 더 강력한 것이 취소됩니다. robots.txt에 의해 차단된 페이지는 크롤링할 수 없으므로 그에 noindex를 적용해도 읽히지 않습니다 — 이는 URL이 "Indexed, though blocked by robots.txt" 상태에 있게 되는 방식이며, 결과에 Google가 가져오기를 금지한 순수 링크로 표시됩니다.

정규화 모순. 정규화 태그가 자체적으로 noindex를 포함하는 대상에 가리키면 Google는 동시에 충족할 수 없는 2가지 지침을 받게 됩니다: 이 페이지로 신호를 통합하고, 이 페이지를 인덱스에서 제외. 따라서 대상은 깨끗해야 합니다: noindex된 페이지, 리다이렉트, 또는 자체적으로 다른 정규화를 지정하는 페이지에 도달하는 정규화는 모순입니다. 동일한 모순은 단일 페이지 내에서도 발생합니다. 페이지가 noindex와 다른 곳으로 가는 정규화를 모두 포함하면 Google가 잊도록 지시된 페이지를 통해 권한을 이전하도록 요구합니다.

지시어가 금지하는 것을 홍보하는 sitemap. sitemap은 그 안의 모든 URL가 인덱싱을 받을 자격이 있다는 기계 가독성 주장을 합니다. robots.txt가 차단하거나 noindexes 지시문이 있는 URL를 나열하면 사이트가 스스로와 논쟁을 벌이고, 그 논쟁은 매 사이클마다 크롤링 예산을 소모합니다. 우리는 이 패턴을 우리의 사이트맵 위생 보고서에서 독자적으로 측정했습니다.

충돌을 해결하는 순서: 의도, 그 다음 하나의 메커니즘, 그 다음 증거

인덱스 가능성 충돌은 고정 신호마다 수정이 적용되기 때문에 지속됩니다 — 누군가 여기서 noindex를 패치하고, 거기서 robots.txt를 편집하지만, 각 페이지 클래스가 실제로 무엇을 위한 것인지 아무도 결정하지 않습니다. 지속적인 해결책은 한 방향으로 실행됩니다.

graph TD A[페이지 클래스별로 의도를 결정합니다] --> B{이 페이지는 무엇을 해야 합니까?} B -->|순위 매기기| C[사이트맵에, 자체 canonical, 지시문 없음] B -->|통합| D[기본에 canonical, 크롤링 가능, 사이트맵 제외] B -->|비공개 유지| E[noindex, 크롤링 가능, 사이트맵 제외] B -->|크롤링 예산 절약| F[robots.txt Disallow, 사이트맵 제외] C --> G[봇 가져오기로 확인합니다] D --> G E --> G F --> G

1. 페이지 클래스별로 의도를 결정합니다. 순위 매길 수 있는 콘텐츠, 중복 변형, 개인 유틸리티 페이지, 무한 매개변수 공간은 각각 하나의 의도를 가집니다 — 아무도 구성 파일을 건드리기 전에.

2. 각 의도를 하나의 메커니즘으로 표현합니다.

  • Rank: 사이트맵에 나열, 자체 canonical을 가리키며, robots 지시문 없음.
  • 중복 통합: <link rel="canonical" href="https://example.com/primary/" /> 변형에서, 이는 크롤링 가능하고 사이트맵을 떠납니다. Canonical은 힌트일 뿐 — Google의 자체 문서는 다른 신호가 불일치할 때 다른 canonical을 선택할 수 있다고 말하며, 이는 대상이 깨끗해야 하는 정확한 이유입니다: 인덱스 가능, 200, 자체 canonical.
  • 결과에서 제외: 페이지에 noindex meta robots 태그, 또는 PDF 및 기타 비-HTML 응답에 대한 X-Robots-Tag: noindex 응답 헤더. 페이지는 크롤링 가능해야 합니다 — robots.txt 블록 뒤의 지시문은 존재하지 않는 지시문입니다.
  • 크롤링 예산 절약: robots.txt에서 User-agent: * 아래에 Disallow: /search/를 두고, URL이 무제한인 공간을 예약합니다. robots.txt는 크롤링을 제어하고, 인덱싱을 방지합니다 — 이미 인덱싱된 항목은 삭제되지 않습니다.

플랫폼마다 noindex 의도는 한 줄로 표현됩니다: robots: { index: false }은 Next.js 라우트의 metadata export에, WordPress의 "Search engine visibility" 토글에 — 환경마다 의도적으로 체크되며, 스테이징에서 상속되지 않으며, 또는 add_header X-Robots-Tag "noindex" always;은 nginx의 location 블록에 범위 지정됩니다.

3. 페이지 클래스별로 봇으로 확인합니다. 브라우저는 여기서 아무것도 증명하지 않으며, 크롤러가 하는 방식으로 가져옵니다:

curl -sI -A "Googlebot" https://example.com/page/ | grep -i "x-robots-tag\|location"
curl -s -A "Googlebot" https://example.com/page/ | grep -i "robots\|canonical"

페이지 클래스별 대표 URL 하나면 충분합니다, 단계 1에서 결정한 의도와 비교해 확인합니다. Search Console의 URL Inspection은 권위 있는 두 번째 의견을 제공하며, 실제로 선택된 canonical Google를 포함합니다. 유료 SEOReport 진단은 모든 보고서에서 전체 루프를 실행하고, 각 충돌 쌍을 발견된 페이지와 함께 나열합니다.

42.9%의 실패율은 인덱스 가능성 충돌을 우리 데이터에서 가장 흔한 심각한 발견 중 하나로 놓습니다, 우리의 가장 실패한 검사 순위의 헤더 격차와 같은 등급에 속하며, 차단된 페이지는 아무리 좋더라도 아무것도 얻지 못한다는 더 가혹한 결과가 있습니다. 통과한 사이트는 인덱싱 의도가 한 번 결정되고, 페이지 클래스별로 한 메커니즘에 기록되며, 크롤러가 확인하는 방식으로 체크된 경우입니다. 이 실패 범주에 대한 모든 것은 사이트 소유자의 통제 하에 있습니다 — 이것이 데이터셋에서 가장 수리 가능한 42.9%인 이유입니다.

사이트의 완전한 진단을 받으세요

근거 기반 보고서와 우선순위 실행 계획을 월간 크레딧 요금제로 받으세요.