Google Search Console 색인 안됨 확인: 알려지지 않은 URL 7개를 기술 문제와 발견 문제로 나누기
Google Search Console 색인 안됨 확인은 성과 보고서의 노출 0만 보고 시작하면 첫 단계부터 어긋날 수 있다. 2026년 7월 30일부터 8월 5일까지 노출이 없던 성숙 글 7개를 8월 7일 다시 검사하자, 그중 1개는 이미 색인돼 있었고 1개는 발견 후 처리 대기, 5개는 Google이 아직 모르는 URL로 갈렸다.
이 글은 Ubuntu 24.04, Python 3.12.3, curl 8.5.0 환경에서 Search Console URL Inspection API의 indexed-version 결과와 공개 WordPress 응답을 읽기 전용으로 대조한 기록을 바탕으로 한다. 색인 생성 요청, sitemap 제출, 내부 링크 수정은 실행하지 않았다. 따라서 여기서 확인할 수 있는 것은 현재 원인의 분류와 다음 행동이며, 링크 수정 후 색인 성공을 증명한 결과는 아니다.
20초 핵심 요약
- 무엇: 노출이 없던 URL 7개를 기술 차단, 발견 전, 처리 대기, 이미 색인 상태로 나눈다.
- 왜: 노출 0이나
알려지지 않음을 곧바로 robots·sitemap 고장으로 보면 정상 설정을 잘못 바꿀 수 있다. - 어떻게: URL Inspection의 indexed-version을 읽고 HTTP, robots, noindex, canonical, 재귀 sitemap, 내부 링크를 공개 상태와 대조한다.
노출 0인 7개가 네 가지 상태로 갈렸다
먼저 성과 보고서와 색인 상태를 분리해야 한다. 이번 표본은 발행 후 3일 이상 지난 공개 글 23개 가운데 Search Console 노출이 없던 7개였다. 같은 7개를 URL Inspection API로 검사한 핵심 출력은 다음과 같다. 실제 호출은 읽기 전용 인증을 사용했으며 인증정보와 속성 식별값은 출력에서 제외했다.
period=2026-07-30..2026-08-05 cutoff=2026-08-02
eligible=23 without_impressions_count=7
.../7월-next-js-보안-취약점-대응-공식-패치와-waf-완화책을-함께/ | NEUTRAL | Google에는 아직 알려지지 않은 URL입니다. | last_crawl=NONE
.../amazon-bedrock-openai-api-migration/ | NEUTRAL | Google에는 아직 알려지지 않은 URL입니다. | last_crawl=NONE
.../cloudflare-agents-ai-sdk-v7-regression-tests/ | PASS | 제출되고 색인이 생성되었습니다. | last_crawl=2026-07-29T15:37:52Z
.../dependabot-malware-alerts/ | NEUTRAL | Google에는 아직 알려지지 않은 URL입니다. | last_crawl=NONE
.../github-actions-workflow-approval/ | NEUTRAL | 발견됨 - 현재 색인이 생성되지 않음 | last_crawl=NONE
.../korea-gdp-q2-2026/ | NEUTRAL | Google에는 아직 알려지지 않은 URL입니다. | last_crawl=NONE
.../wordpress-rest-api-pagination/ | NEUTRAL | Google에는 아직 알려지지 않은 URL입니다. | last_crawl=NONE
exit=0
여기서 PASS인 Cloudflare Agents 글은 색인 수정 대상이 아니다. 노출이 없었다는 사실은 색인되지 않았다는 뜻이 아니기 때문이다. 나머지 6개도 하나의 원인으로 묶을 수 없다. 발견됨 - 현재 색인이 생성되지 않음은 Google이 URL의 존재를 아는 단계이고, Google에는 아직 알려지지 않은 URL입니다.는 indexed-version 기준으로 Google이 URL을 이전에 보지 못한 상태다.
이 구분이 첫 번째 분기점이다. 알려지지 않음에서 robots, page fetch, indexing 관련 필드가 UNSPECIFIED로 보이더라도 차단이 확인됐다고 해석하면 안 된다. 아직 찾거나 크롤링하지 않아 분석할 기록이 없는 상태일 수 있다. 기본 URL Inspection 결과는 현재 브라우저 응답을 실시간 검사한 결과가 아니라 Google 색인의 indexed-version 정보이며, live test는 별도다. Google Search Console URL 검사 도구와 단일 페이지 검사 도움말도 이 차이를 전제로 상태를 읽도록 안내한다.
기술 차단은 공개 URL에서 따로 확인한다
상태 문구만으로 원인을 확정하지 말고 현재 공개 URL의 기술 조건을 검사한다. 순서는 최종 HTTP 상태, robots 허용, noindex, canonical이다. Google의 최소 기술 요구사항은 Googlebot이 차단되지 않고, 페이지가 HTTP 200을 반환하며, 색인 가능한 콘텐츠를 제공하는 것이다. 이 조건은 색인 가능성을 열어 둘 뿐 실제 색인을 보장하지 않는다. Google 검색 기술 요구사항
| 관측 결과 | 1차 분류 | 먼저 할 일 |
|---|---|---|
| 404·5xx 또는 로그인 필요 | 기술 접근 문제 | 공개 대상인지 확인한 뒤 서버·공개 설정 수정 |
| robots.txt 차단 | 기술 크롤링 문제 | 의도하지 않은 규칙만 수정 |
noindex |
기술 색인 허용 문제 | 검색 노출 대상일 때 제거 후 재검증 |
| 다른 URL을 가리키는 canonical | 중복·표준화 문제 | 의도한 중복인지 확인하고 실수일 때만 정리 |
알려지지 않음, last crawl 없음 |
발견 전 문제 | sitemap과 크롤링 가능한 내부 링크 확인 |
발견됨 - 현재 색인이 생성되지 않음 |
발견 후 처리 문제 | 제출 반복보다 크롤링 상태와 시간 경과 확인 |
PASS, 성과 노출 0 |
색인 문제가 아님 | 검색 수요·의도와 성과 데이터를 별도로 분석 |
이번 7개는 공개 검사에서 모두 HTTP 200, 자기참조 canonical, noindex 없음으로 확인됐다. robots.txt도 Googlebot을 막지 않았다. 존재하지 않는 같은 도메인의 control URL은 404를 반환했으므로 검사 코드가 오류 페이지까지 200으로 세고 있지는 않았다.
SITEMAP children=4 locations=204
7 target URLs | recursive_sitemap=true (all)
PUBLIC_POSTS scanned=40
body_internal_referrers=2,0,2,2,1,2,0
7 target URLs | HTTP status=200 | self canonical | meta robots=max-image-preview:large
CONTROL /__research-index-control-not-found-20260807/ | status=404
exit=0
공개 curl·urllib 검사는 Googlebot 렌더링을 그대로 재현한 live test가 아니다. 그 한계를 감안해도 현재 응답에서 404·5xx, robots 차단, noindex, canonical 불일치 같은 명백한 기술 차단은 발견되지 않았다. 사이트 전체 설정을 추측으로 바꾸는 것보다 5개를 발견 전, 1개를 발견 후 처리 단계로 두는 판단이 관측에 더 잘 맞는다.
sitemap은 하위 XML까지 읽어야 한다
이 검사에서는 첫 sitemap 판정이 틀렸다. 루트 sitemap.xml에서 대상 URL 문자열만 찾았더니 7개 모두 sitemap=false로 나왔다. 하지만 루트 파일은 URL 목록인 <urlset>이 아니라 하위 sitemap 4개를 가리키는 <sitemapindex>였다. 하위 XML까지 재귀적으로 읽자 7개가 모두 포함돼 있었다.
사이트 상태가 바뀐 전후 비교가 아니다. 같은 시점의 같은 sitemap을 읽는 방법만 루트 문자열 검색에서 하위 XML 재귀 조회로 바꿨고, 판정이 7/7 누락에서 7/7 포함으로 바뀌었다. WordPress sitemap을 확인할 때는 URL부터 검색하기 전에 루트 요소가 <sitemapindex>인지 <urlset>인지 확인해야 한다.
현재 공개 sitemap에 URL이 있다는 사실과 URL Inspection API의 sitemap 배열이 비어 있다는 사실도 동시에 성립할 수 있다. API가 보여주는 것은 Google이 아는 indexed-version 정보이고, 공식 스키마는 sitemap 목록이 완전하다고 보장하지 않는다. 현재 사이트와 Google이 수집한 시점·지식이 다를 수 있으므로 빈 배열을 곧바로 “sitemap 누락”으로 번역하지 않는다. Search Console API UrlInspectionResult
더 중요한 한계도 있다. sitemap은 URL 발견을 돕지만 크롤링이나 색인을 보장하지 않는다. 이번 표본은 7개 모두 sitemap에 있었지만 6개는 미색인이었다. 이는 최소 기술 조건을 충족해도 색인이 보장되지 않는다는 Google 공식 설명과 실제 관측이 일치한 결과다. Google sitemap 개요
내부 링크는 개수보다 발견 시점과 문맥을 본다
공개 글 40개의 렌더링 본문에서 대상 URL로 향하는 <a href>를 센 결과는 URL별로 2, 0, 2, 2, 1, 2, 0개였다. “7개 모두 내부 링크가 없다”는 설명은 사실이 아니다. 내부 링크가 1~2개인 5개 중 4개도 미색인이었고, 이미 색인된 대조군은 2개를 받고 있었다.
이 결과만으로 내부 링크가 효과 없다고 결론 내릴 수도 없다. 본문 링크만 센 값이라 메뉴, 카테고리, 태그, 홈, 외부 링크까지 포함한 전체 링크 그래프가 아니다. 링크가 언제 추가됐는지, Google이 그 referrer를 추가 후 다시 크롤링했는지, 실제 렌더링과 탐색 문맥에서 링크를 읽었는지도 측정하지 않았다.
따라서 내부 링크가 0개인 Amazon Bedrock 글과 WordPress REST API pagination 글은 관련 문맥 링크 후보를 먼저 검토할 수 있다. 이미 1~2개가 있는 URL은 수만 늘리기 전에 referrer가 크롤링 가능한 공개 글인지와 링크 추가 시점을 확인하는 편이 낫다. “링크 한 개를 추가하면 색인된다”는 고정 공식은 없으며, 변경했다면 referrer URL과 변경 시각을 남기고 같은 URL의 indexed-version을 나중에 다시 봐야 한다.
URL별 다음 행동을 한 번에 결정하는 절차
- 성과 보고서의 노출 0을 미색인 판정으로 쓰지 않는다. 정확한 공개 URL을 URL Inspection으로 검사한다.
- indexed-version에서 verdict, coverage, last crawl, page fetch, indexing allowed, user canonical과 Google canonical을 읽는다.
알려지지 않음이면 일부 분석 필드가 비어 있을 수 있다. - 현재 공개 URL에서 최종 HTTP 200, robots 허용,
noindex없음, 의도한 canonical을 확인한다. 기술 차단이 있으면 이 단계에서 발견 문제와 분리한다. - sitemap 루트가 index인지 URL set인지 확인한다. index라면 하위 XML까지 따라가 정확한 canonical URL이 들어 있는지 찾는다.
- 이미 Google이 알 가능성이 높은 공개 페이지에서 대상 URL로 가는 관련 본문 링크를 확인한다. 링크 수만 늘리지 말고 삽입 시점과 크롤링 가능성을 함께 기록한다.
- 기술 차단이 있으면 수정 후 live test로 현재 상태를 확인한다. 차단이 없고 Google이 URL을 모르면 중요한 URL에 한해 색인 생성을 한 번 요청하고 기다리는 방안을 고려한다.
PASS면 색인 수정 절차를 멈춘다. 노출과 클릭 부족은 색인 문제가 아닌 별도 성과 문제로 넘긴다.
Google은 크롤링과 색인에 며칠에서 몇 주가 걸릴 수 있고, 같은 URL을 반복 요청해도 더 빨라지지 않는다고 설명한다. 요청 횟수나 고정 대기 일수를 성공 공식으로 만들지 말고 상태가 바뀌는지를 기록한다. Google에 재크롤링 요청
수정하지 말아야 할 조건과 되돌리기
이번 7개 때문에 robots.txt, noindex, canonical, permalink, sitemap 플러그인을 일괄 변경할 근거는 없다. 모두 현재 공개 기술 조건을 통과했고, 그중 하나는 이미 색인돼 있었다. 의도적으로 비공개이거나 중복인 URL, 저가치 아카이브라면 색인을 목표로 삼지 않는 판단도 필요하다.
내부 링크 보강을 승인받아 실행한다면 변경 전에 원문과 기존 링크 상태를 백업하고, 관련성이 분명한 글 본문에 한 건만 추가한다. 대상 URL, referrer URL, 변경 시각을 기록해야 이후의 상태 변화를 같은 조건으로 비교할 수 있다. 문제가 생기면 추가한 링크 한 건을 제거하고 백업한 원문으로 복구하는 것이 되돌리기 범위다.
다만 이번 읽기 전용 검사만으로 콘텐츠의 독창성·유용성, 중복 군집, soft 404, Googlebot 렌더링 결과, 직접 조치·보안 문제, 법적 삭제 같은 가능성까지 배제할 수는 없다. 기술 차단이 없다는 판정은 콘텐츠 품질이 충분하다는 보증이 아니다. 발견·처리 상태가 오래 유지된다면 이 미검증 영역을 별도 진단해야 한다.
현재 표본에서 먼저 할 일은 명확하다. PASS 1개는 색인 수정에서 제외하고, 발견됨 1개는 처리 상태를 관찰한다. 알려지지 않음 5개는 현재 발견 신호와 시점을 점검하되, 내부 링크가 0개인 2개부터 관련 링크 후보를 검토한다. 기술 차단 증거가 없는 URL의 사이트 설정을 한꺼번에 바꾸는 것은 이 순서에 포함되지 않는다.
기술 차단이 없고 내부 링크 보강이 필요한 URL이라면, 실제 수정에 앞서 WordPress 변경 전 내부 링크 백업·검증 절차를 확인한다.
진단 대상 글
이번 URL Inspection 비교에 사용한 실제 HuntLab 글이다.
