구글 색인 문제 진단: URL 이탈 지점을 추적하는 상태 모델

구글 색인 문제가 보이면 대개 발행한 페이지 수와 색인된 페이지 수로 색인률부터 계산합니다. 하지만 하나의 비율에는 서로 다른 상태가 섞여 있습니다. 검색 결과에 남길 필요가 없는 필터 URL, 아직 발견되지 않은 신규 페이지, 구글봇이 수집했지만 다른 URL의 중복으로 판정한 페이지가 모두 같은 분모에 들어갑니다.

이 숫자만으로는 개발팀에 무엇을 요청해야 할지 정하기 어렵습니다. 색인 문제를 다룰 때 필요한 것은 더 정교한 비율이 아니라 URL이 마지막으로 통과한 구간을 기록하는 방식입니다. 발견, 수집, 렌더링, 정규화, 색인을 서로 다른 상태로 분리하면 같은 서치콘솔 사유 안에서도 수정할 대상과 그대로 둘 대상을 가를 수 있습니다.

구글 색인 문제를 색인률 하나로 설명할 수 없다

구글은 검색 처리 과정을 크롤링, 색인 생성, 검색 결과 게재의 세 단계로 설명합니다. 크롤링 과정에는 페이지 발견과 자바스크립트 렌더링이 포함되고, 색인 과정에서는 본문과 주요 태그를 분석해 중복 여부와 대표 URL을 판단합니다. 모든 페이지가 각 단계를 통과하는 것은 아닙니다.

페이지 색인 생성 보고서도 100% 색인을 목표로 삼지 말라고 안내합니다. 중요한 canonical 페이지만 색인되어야 하며, 중복 페이지나 대체 페이지, 의도적으로 제외한 URL이 색인되지 않은 것은 정상입니다. 따라서 색인률의 분모는 크롤러가 발견한 전체 URL이 아니라 조직이 검색 결과에 남기기로 결정한 URL이어야 합니다.

이 결정은 기술 설정에서 자동으로 나오지 않습니다. 재고가 없는 상품을 계속 노출할지, 필터 조합 페이지에 독립적인 검색 수요가 있는지, 오래된 문서를 보존할지는 사업 규칙에 가깝습니다. 먼저 URL마다 should_index를 정하고 이유를 함께 기록해야 합니다.

url
template
should_index
decision_reason
published_at
last_significant_update_at

should_index가 비어 있는 상태에서 전체 색인률을 높이면 원하지 않는 페이지까지 사이트맵에 넣거나 얇은 페이지에 내부 링크를 추가하는 일이 생깁니다. 숫자는 좋아져도 검색엔진이 집중해야 할 집합은 더 흐려질 수 있습니다.

URL마다 마지막으로 확인된 상태를 기록한다

상태 모델의 목적은 구글 내부 처리 과정을 완벽하게 재현하는 데 있지 않습니다. 외부에서 확인 가능한 증거만으로 URL이 어디까지 도달했는지 일관되게 기록하는 데 있습니다. 이 글에서는 여섯 상태를 사용합니다.

1. 발행 의도

페이지가 운영 시스템에 존재하고 검색 결과에 남길 대상으로 승인된 상태입니다. 사이트맵에 있다는 사실만으로 이 의도를 대신하지 않습니다. 사이트맵 생성 로직이 실제 정책보다 넓거나 좁을 수 있기 때문입니다.

2. 발견 가능

선호 URL이 사이트맵에 포함되었거나, 이미 접근 가능한 페이지에서 크롤 가능한 링크를 받은 상태입니다. 구글은 사이트맵이 URL 발견을 돕지만 수집이나 색인을 보장하지 않는다고 설명합니다. 사이트맵은 결과가 아니라 사이트가 중요하다고 선언한 URL 집합으로 사용합니다.

3. 수집 확인

구글봇이 해당 URL을 실제로 요청한 증거가 있는 상태입니다. 가장 직접적인 자료는 서버나 CDN의 접근 로그입니다. URL 검사 API(URL Inspection API)의 lastCrawlTime도 마지막 수집 시각을 제공하지만, 값이 없다고 해서 로그 전체에서 요청이 없었다는 뜻으로 확대해서는 안 됩니다. API 결과와 로그는 관측 범위가 다릅니다.

4. 처리 가능

요청이 성공했고 색인 지시와 핵심 콘텐츠를 읽을 수 있는 상태입니다. HTTP 응답, robots.txt, robots meta, 원본 HTML과 렌더링 결과를 함께 봅니다. robots.txt로 수집을 막은 페이지에서는 구글이 페이지 안의 noindex를 읽을 수 없습니다. 수집 차단과 색인 제외를 같은 조치로 다루면 판정이 어긋나는 이유입니다.

자바스크립트 사이트라면 화면이 열린다는 확인만으로 충분하지 않습니다. 원본 HTML과 렌더링 DOM에서 제목, robots 지시, canonical, 핵심 본문, 내부 링크가 유지되는지 필드별로 비교합니다.

5. 대표 URL 정렬

사이트가 선언한 canonical과 구글이 선택한 canonical이 일치하는 상태입니다. 구글은 사이트맵, rel="canonical", 리다이렉트, 내부 링크 등 여러 신호를 함께 사용합니다. 공식 canonical 가이드는 같은 페이지에 대해 사이트맵과 canonical이 서로 다른 URL을 가리키지 않도록 권고합니다.

URL 검사 API에서는 userCanonical과 googleCanonical을 따로 확인할 수 있습니다. 두 값이 다르면 태그 하나를 다시 넣기 전에 중복 후보, 리다이렉트, 내부 링크와 사이트맵이 어느 URL을 지지하는지 군집 단위로 살펴야 합니다.

6. 색인 확인

구글이 선택한 대표 URL이 색인에 들어간 상태입니다. 여기까지 도달해야 비로소 검색 결과에 노출될 자격이 생깁니다. 색인은 순위나 실제 노출을 보장하지 않습니다. 색인 이후의 검색 수요와 품질 평가는 이 진단 모델의 다음 문제입니다.

네 데이터 소스를 URL 하나에 결합한다

페이지 색인 생성 보고서만 내려받아서는 전수 URL 장부를 만들기 어렵습니다. 보고서의 예시 목록은 상태별 최대 1,000개이며 전체 목록을 보장하지 않습니다. 먼저 자체 데이터로 기준 URL 집합을 만들고 서치콘솔 데이터를 붙이는 순서가 안전합니다.

기준 집합은 CMS나 상품 데이터베이스에서 should_index가 참인 URL을 추출해 만듭니다. 여기에 같은 시점의 사이트맵 포함 여부와 자체 크롤 결과를 붙입니다. 다음으로 분석 기간의 구글봇 로그를 정규화해 마지막 요청 시각과 응답 코드를 결합합니다. 마지막에 중요 URL 또는 대표 표본의 URL 검사 결과를 추가합니다.

inventory
  url, template, should_index, published_at

sitemap_snapshot
  url, in_sitemap, lastmod

crawl_snapshot
  url, status, robots, canonical, rendered_content_hash

googlebot_log
  url, last_googlebot_hit, response_status

url_inspection
  url, verdict, last_crawl_time, page_fetch_state,
  user_canonical, google_canonical

결합 키는 URL 문자열 그대로 두지 않습니다. 프로토콜, 호스트, 대소문자, 말미 슬래시, 추적 파라미터 처리 규칙을 먼저 고정합니다. 이 정규화에서 서로 다른 페이지를 하나로 합치면 canonical 충돌을 숨기게 되고, 같은 페이지를 여러 행으로 남기면 문제 규모가 부풀려집니다. 원본 URL과 분석용 정규 URL을 모두 보존하는 편이 좋습니다.

제외 사유보다 이탈 구간을 먼저 본다

서치콘솔의 제외 사유는 출발점으로 유용하지만, 그 문구만으로 수정 작업을 배정하면 서로 다른 원인이 한 티켓에 묶입니다. 상태 장부에서는 마지막으로 확인된 증거와 다음 증거의 부재를 먼저 봅니다.

발행 의도는 있지만 발견 가능 상태가 아니라면 사이트맵 생성 조건과 내부 링크 구조를 확인합니다. 이 URL은 canonical이나 콘텐츠 품질을 논하기 전에 검색엔진이 반복해서 찾을 경로가 있는지부터 확인해야 합니다.

발견 가능하지만 수집 증거가 없다면 서버 로그의 분석 기간, 구글봇 검증 방식, URL 패턴별 수집 분포를 살펴봅니다. 신규 URL과 오래된 URL을 섞지 않고 발행 후 경과 시간별로 나눕니다. 발행일을 기준으로 코호트를 만들고 첫 구글봇 요청까지 걸린 시간의 중앙값과 상위 구간을 비교하면 일시적인 대기와 반복되는 지연을 구분할 수 있습니다.

수집되었지만 처리 가능 상태에서 멈췄다면 응답 코드, robots 규칙, 렌더링 결과를 확인합니다. 같은 템플릿의 정상 URL과 실패 URL을 한 쌍으로 비교하면 공통 템플릿 문제와 개별 데이터 문제를 가르기 쉽습니다. 비교할 때는 응답 코드, robots 지시, canonical, 렌더링된 핵심 본문과 내부 링크를 같은 순서로 확인합니다.

처리 가능하지만 대표 URL이 정렬되지 않았다면 URL 하나가 아니라 중복 군집을 봅니다. 사이트맵은 A를, 내부 링크는 B를, canonical은 C를 지지하는 상태에서 C의 태그만 수정해도 다른 신호가 남습니다. 구글이 선택한 대표 URL과 사이트가 선언한 대표 URL의 차이를 군집별로 기록해야 합니다.

대표 URL까지 정렬되었지만 색인되지 않은 집합은 마지막에 검토합니다. 이 단계에서는 콘텐츠의 고유성, 페이지 역할, 사이트 안에서의 중요도처럼 단일 태그로 설명되지 않는 조건이 남을 수 있습니다. 확인된 기술 장애와 해석을 분리하고, 품질이라는 말로 앞선 단계의 데이터 누락을 덮지 않습니다.

전체 색인률 대신 상태 전환을 측정한다

상태 장부가 만들어지면 전체 비율보다 템플릿별 전환을 먼저 계산합니다. 상품 상세, 카테고리, 브랜드, 도움말 문서는 발견 방식과 갱신 주기가 다르므로 하나의 평균으로 묶을 이유가 없습니다.

지표는 상태 전환을 따라 다섯 개면 충분합니다. should_index 집합에서 사이트맵이나 내부 링크로 발견 가능한 URL의 비율을 먼저 계산하고, 그중 분석 기간에 구글봇 수집이 확인된 비율, 수집된 URL 중 처리 가능 조건을 통과한 비율을 차례로 잇습니다. 네 번째는 canonical 정렬입니다. 사이트가 선언한 값과 구글이 선택한 값이 일치하는지 보고, 마지막으로 대표 URL이 색인된 비율을 확인합니다.

전환율에는 시간을 함께 붙입니다. 발행 다음 날과 60일이 지난 URL을 같은 실패로 분류하면 신규 발견 지연과 구조적 이탈을 구분할 수 없습니다. 표본 수가 충분하다면 템플릿별로 발행 후 첫 구글봇 요청까지의 시간, 첫 요청 후 검사 시점까지의 상태를 따로 기록합니다.

결과는 템플릿별 상태 구성비와 중앙 체류시간으로 정리합니다. 표본이 적은 템플릿은 비율만 제시하지 않고 URL 수를 함께 기록해 변동 폭을 드러냅니다.

우선순위는 이탈 URL 수만으로 정하지 않습니다. 해당 템플릿의 검색 수요, 전환 기여, 문제가 영향을 주는 URL 수, 수정 난이도를 함께 봅니다. 다만 서로 다른 단위를 임의로 더해 정밀한 점수처럼 보이게 하기보다, 근거가 확인된 영향 범위와 구현 조건을 나란히 기록하는 편이 판단에 도움이 됩니다.

수정한 URL 집합을 같은 조건으로 다시 측정한다

배포 직후 자체 크롤이 통과했다고 색인 문제가 해결된 것은 아닙니다. 수정은 사이트가 통제할 수 있는 신호를 바꾼 것이고, 구글이 다시 수집하고 처리한 결과는 나중에 관측됩니다.

재측정에서는 수정 전 코호트를 고정합니다. 중간에 새로 발행된 URL을 분모에 넣지 않고, 같은 URL의 사이트맵 포함 여부, 구글봇 재방문, 응답과 렌더링, canonical 선택, 색인 상태가 어떻게 이동했는지 비교합니다. URL이 색인되었는지만 보지 않고 목표한 다음 상태로 이동했는지를 확인하면 기다려야 하는 일과 다시 수정할 일을 구분할 수 있습니다.

예를 들어 내부 링크 수정의 첫 성공 조건은 발견 가능 상태의 개선입니다. 그다음 구글봇 요청이 늘었는지 확인하고, 수집 이후 상태는 별도로 추적합니다. canonical 신호를 정렬했다면 구글 선택 canonical이 바뀌었는지가 먼저입니다. 모든 수정의 성과를 곧바로 검색 유입으로 판단하면 중간 단계의 개선이 보이지 않고, 반대로 검색 유입이 우연히 늘어난 것을 기술 수정의 효과로 잘못 읽을 수 있습니다.

색인은 하나의 초록불이 아닙니다. URL이 어디까지 도달했고 어떤 증거에서 멈췄는지를 기록한 장부에 가깝습니다. 이 장부가 있으면 “색인이 안 된다”는 큰 문제를 발견 경로, 수집 접근, 렌더링, canonical 군집, 색인 판단이라는 개발 가능한 단위로 나눌 수 있습니다. 그리고 수정 뒤에는 같은 URL이 실제로 다음 상태로 이동했는지 확인할 수 있습니다.

사이트 전체에서 이 장부를 만들려면 크롤 결과만으로는 부족합니다. 서버 로그, 서치콘솔, 렌더링 결과를 같은 기간과 URL 기준으로 결합해야 합니다. 이 과정이 필요한 범위와 산출물은 테크니컬 SEO 진단과 개선에서 확인할 수 있습니다.