'발견됨 - 현재 색인이 생성되지 않음' 내부 링크로 풀릴까: 2주 실측 결과
Search Console '발견됨 - 현재 색인이 생성되지 않음'은 Google이 주소만 알고 아직 크롤링하지 않은 상태입니다. 내부 링크를 고친 뒤 2주를 재 보니 요청 안 한 43개는 0개, 요청한 13개는 모두 색인됐습니다. 확인·점검·재측정 순서를 정리했습니다.

Search Console 페이지 색인 생성 보고서에 "발견됨 - 현재 색인이 생성되지 않음"이 줄줄이 쌓여 있다면, Google이 주소만 알고 아직 페이지를 읽으러 오지 않은 상태입니다. 저는 내부 링크를 원인으로 보고 aicreatorlab.com의 링크를 고쳤는데, 2주 뒤 다시 재 보니 결과가 예상과 달랐습니다. 이 글에는 그 숫자를 그대로 적고, 내 사이트에서 이 상태를 확인하고 손보는 순서를 정리했습니다.
2026년 9월 23일 aicreatorlab.com은 사이트맵의 URL 80개 중 39개만 색인돼 있었고 34개가 이 상태였어요. 블로그 목록 페이지가 28편 중 12편만 링크하고 있어서 그날 목록과 허브 페이지를 고쳤습니다. 일주일 뒤인 9월 30일에 다시 재 보기로 했는데 실제로 다시 잰 건 10월 8일입니다.
결론부터 적으면, 링크를 고친 뒤에도 색인 생성 요청을 넣지 않은 URL 43개는 하나도 색인되지 않았습니다. 요청을 넣은 13개는 모두 색인됐어요. 그래서 처음 세운 "사이트맵보다 내부 링크"라는 가설을 버리고 순서를 다시 정했습니다.
Search Console 첫 등록과 사이트맵 제출은 홈페이지 검색 등록: Search Console·네이버 첫 설정에 따로 정리했고, 이 글은 등록을 마친 뒤의 이야기입니다. 공식 문서는 2026년 10월 8일에 다시 확인했습니다.
'발견됨 - 현재 색인이 생성되지 않음'은 무슨 뜻인가요
Google 페이지 색인 생성 보고서 도움말은 이렇게 설명합니다.
발견됨 - 현재 색인이 생성되지 않음: Google에서 페이지를 발견했지만 페이지가 아직 크롤링되지 않았습니다. 일반적으로 Google에서 URL을 크롤링하려고 했지만 이로 인해 사이트가 과부하 상태가 될 수 있기 때문에 Google에서 크롤링 일정을 변경한 경우입니다. 그렇기 때문에 보고서에 마지막 크롤링 날짜가 비어 있는 것입니다.
쉽게 말하면 Google이 주소록에 이 URL을 적어 두긴 했는데 아직 방문은 하지 않은 상태입니다. 페이지 내용을 읽지 않았으니 품질을 판단받은 것도 아니에요. 그래서 URL 검사에서 마지막 크롤링 날짜가 비어 있습니다.
비슷해 보이는 상태가 하나 더 있습니다.
| 상태 | 공식 설명 | 풀어 쓰면 |
|---|---|---|
| 발견됨 - 현재 색인이 생성되지 않음 | 발견했지만 아직 크롤링하지 않았다. 사이트 과부하를 우려해 크롤링 일정을 바꾼 경우가 일반적이다. | 주소만 알고 아직 안 와 봤다. |
| 크롤링됨 - 현재 색인이 생성되지 않음 | 크롤링했지만 색인하지 않았다. 나중에 색인될 수도, 안 될 수도 있고 다시 제출할 필요는 없다. | 와서 읽었지만 아직 검색 결과에 넣지 않았다. |
| Google에는 아직 알려지지 않은 URL입니다 | (URL 검사 도구 도움말) Google이 이전에 이 URL을 본 적이 없다. | 주소 자체를 모른다. |
두 "현재 색인이 생성되지 않음"은 해야 할 일이 다릅니다. "크롤링됨"은 Google이 페이지를 읽은 뒤의 판단이라 내용과 중복 여부를 봐야 하고, "발견됨"은 아직 읽기 전이라 Google이 이 페이지를 먼저 가져갈 이유를 만들어 주는 쪽이 맞습니다.
같은 도움말은 모든 URL이 색인될 거라고 기대하지 말라고도 적고 있습니다. 중복이거나 의미 있는 정보가 없는 URL도 있으니 핵심 페이지가 색인됐는지만 확인하라는 거예요. 페이지가 500개보다 적은 사이트라면 이 보고서를 쓰지 않아도 될 가능성이 크고, 먼저 site:내도메인 검색으로 주요 페이지를 확인하라고 안내합니다.
9월 23일에 본 숫자와 의심한 원인
9월 23일에 사이트맵의 URL 80개를 하나씩 URL 검사 데이터로 확인했습니다.
| 상태 | URL 수 |
|---|---|
| 색인됨 | 39 |
| 발견됨 - 현재 색인이 생성되지 않음 | 34 |
| Google에는 아직 알려지지 않은 URL | 7 |
이때 /blog 목록 페이지 HTML을 열어 보니 글 링크가 12개뿐이었습니다. 나머지 16편은 "더 보기" 버튼을 눌러야 화면에 나타나는 구조였는데, 버튼을 누르기 전 HTML에는 그 링크가 아예 없었어요. 사이트맵에는 28편이 모두 들어 있었지만, 사이트 안에서 링크를 따라 그 16편에 닿는 길은 좁았습니다.
Google 공식 문서도 링크를 발견 경로로 봅니다. 링크 권장사항은 Google이 링크를 새 페이지를 찾는 데 쓰며, 일반적으로 href 속성이 있는 <a> 요소만 크롤링할 수 있다고 적습니다. 사이트맵 개요는 페이지가 제대로 링크돼 있으면 Google이 대부분을 찾을 수 있고, 사이트맵은 발견을 돕지만 모든 항목의 크롤링과 색인을 보장하지는 않는다고 설명합니다. 그래서 "사이트맵은 있으니 링크를 채우면 된다"고 판단했습니다.
그날 고친 세 가지
9월 23일에 Claude Code로 세 번에 나눠 고치고 배포했습니다(PR #110~#112).
- 블로그 목록 전체 링크. 12편 뒤의 글도 HTML에 링크로 남기고 화면에서만 접히게 바꿨습니다. "더 보기"를 누르지 않아도 HTML 소스에 모든 글의
<a href>가 있습니다. - 글과 용어 사전 사이 링크. 블로그 글 본문 아래에 그 글에 실제로 나오는 용어 사전(/guide) 링크를 달고, 용어 페이지에는 거꾸로 "이 용어가 나오는 글"을 달았습니다. 들어오는 링크가 한두 개뿐이던 용어 페이지는 이웃 용어의 관련 항목에 넣었습니다.
- 주제별 허브 페이지. /topics 아래에 Claude Code, 홈페이지·앱, 업무 자동화 세 주제로 글을 읽는 순서대로 묶은 페이지를 만들었습니다(다음 날 고객 확보 주제 하나를 더했습니다).
같은 날 사이트맵을 다시 제출하고 색인 생성 요청도 시도했는데, 1건이 들어간 뒤 할당량 초과가 떴습니다.
2주 뒤 다시 재 보니
10월 8일에 같은 방식으로 사이트맵 전체를 다시 검사했습니다. 그사이 새 글과 허브가 늘어 URL은 96개가 됐습니다. 9월 25일에 한 번 더 잰 중간 기록도 같이 적습니다.
| 측정일 | 사이트맵 URL | 색인됨 | 발견됨 | 알려지지 않음 |
|---|---|---|---|---|
| 9월 23일 | 80 | 39 | 34 | 7 |
| 9월 25일 | 95 | 50 | 40 | 5 |
| 10월 8일 | 96 | 52 | 36 | 8 |
9월 25일 이후 13일 동안 색인된 URL은 2개 늘었습니다. 9월 23일에 "80개 중 60개 이상"을 목표로 적어 뒀는데 지금 비율로는 54%(96개 중 52개)라 목표에 못 미쳤어요.
그래서 URL을 두 무리로 나눠 봤습니다. 9월 23~25일에 URL 검사에서 직접 색인 생성 요청을 넣은 페이지와 넣지 않은 페이지입니다.
| 무리 | URL 수 | 10월 8일 색인됨 |
|---|---|---|
| 색인 생성 요청을 넣은 URL (9월 23~25일) | 13 | 13 |
| 9월 25일에 색인되지 않았고 요청도 넣지 않은 URL | 43 | 0 |
요청을 넣은 13개는 10월 8일 기준 모두 색인돼 있습니다. 그중 11개는 9월 25일 측정 때 이미 색인돼 있었고, 나머지 2개(what-is-vibe-coding, /topics/ai-work-automation)는 그 뒤에 색인됐어요. 요청하지 않은 43개는 하나도 색인되지 않았습니다. 이 43개는 모두 블로그 목록, 용어 사전 목록, 주제 허브, 푸터 중 한 곳 이상에서 HTML 링크로 연결돼 있습니다.
요청할 페이지는 새 글과 허브처럼 중요한 것부터 골랐으니 공정한 실험은 아닙니다. 그래도 내부 링크를 고친 것만으로는 2주 안에 색인으로 이어지지 않았다는 건 분명합니다.
구역별로 보면 색인되지 않은 44개가 어디에 몰려 있는지 보입니다.
| 구역 | 색인됨 / 전체 |
|---|---|
| 블로그(/blog 목록 포함) | 26 / 39 |
| UI 용어 사전(/guide/ui/*) | 5 / 24 |
| 바이브 코딩 용어 사전(/guide/vibe-coding/*) | 6 / 14 |
| 주제 허브(/topics/*) | 2 / 4 |
| 나머지(홈·소개·강의·용어 사전 첫 화면·약관·지원·부트캠프 등) | 13 / 15 |
URL 검사 결과에서 하나 더 눈에 띈 건 "참조 페이지"였습니다. 10월 8일에 "발견됨"인 36개 중 26개가 참조 페이지로 /blog나 /guide/ui가 아니라 /sitemap.xml을 보여 줬어요. 공식 도움말에 따르면 참조 페이지는 Google이 이 URL을 발견하는 데 "사용했을 가능성이 있는" 페이지이고, 값이 비어 있어도 참조 페이지가 없다는 뜻이 아니라 검사 시점에 그 정보를 가져오지 못했다는 뜻입니다. 이 값만으로 단정할 수는 없지만, 이 페이지들은 사이트맵으로 이미 발견된 상태였습니다. 발견은 끝났고 막힌 건 그다음 단계인 크롤링이었던 셈이에요.
이상한 변화도 있었습니다. 9월 25일에 "발견됨"이던 URL 6개가 10월 8일에는 "Google에는 아직 알려지지 않은 URL"로 바뀌었습니다. 공식 정의대로라면 "본 적이 없다"는 상태라 앞뒤가 맞지 않는데, 이유는 확인하지 못했습니다.
검색 성과도 봤습니다. 9월 9일~10월 6일 28일 동안 사이트 전체는 클릭 266회, 노출 12,655회였고, 요청을 넣어 색인된 13개 URL이 그중 클릭 37회, 노출 2,461회를 차지했습니다.
이 결과로 바꾼 생각
처음 제목은 "사이트맵보다 내부 링크"였습니다. 2주 데이터를 보고 생각을 고쳤어요.
내부 링크는 Google이 페이지를 찾을 수 있게 하는 조건입니다. 목록이 12편만 링크하던 건 분명한 결함이었고 고치는 게 맞았습니다. 다만 이미 사이트맵으로 주소를 알고 있는 페이지라면, 링크를 더 다는 것만으로 크롤링 순서가 당겨지지는 않았습니다.
Google 크롤링 예산 문서는 Googlebot의 크롤링 수요가 다른 사이트와 비교한 사이트의 크기, 업데이트 빈도, 페이지 품질, 관련성에 따라 달라진다고 설명합니다. 인터넷에서 더 인기 있는 URL이 더 자주 크롤링되는 경향이 있다고도 적고 있어요. 이 문서는 주로 페이지가 아주 많은 사이트를 위한 것인데 대상에 "전체 URL 중 상당수가 '발견됨 - 현재 색인이 생성되지 않음'인 사이트"도 넣어 두었습니다. 우리 사이트도 Google 입장에서는 서둘러 읽을 이유가 적었을 거라고 생각합니다. 측정한 게 아니라 문서를 근거로 한 추정입니다.
남은 44개 중 19개가 UI 용어 사전 페이지라는 점도 다음에 볼 부분입니다. 한 화면짜리 짧은 설명이 많은 구역이라, 내용을 보강하거나 비슷한 항목을 합칠지 검토할 생각입니다. 아직 하지 않았고 효과도 모릅니다.
내 사이트에서 따라 하는 순서
순서는 ① 어떤 페이지가 '발견됨'인지 확인 ② 내부 링크 점검 ③ 핵심 페이지만 색인 생성 요청 ④ 같은 URL 목록으로 재측정입니다. 링크 점검은 발견 경로를 막는 결함을 없애는 단계이고, 이미 발견된 페이지의 크롤링을 당기는 데는 우리 경우 요청이 더 직접적이었습니다.
1. 어떤 페이지가 '발견됨'인지 확인합니다
- Search Console 왼쪽 메뉴에서 색인 생성 > 페이지를 엽니다.
- 색인이 생성되지 않은 이유를 보여 주는 표에서 발견됨 - 현재 색인이 생성되지 않음 행을 누르면 예시 URL 목록이 나옵니다. 예시는 최대 1,000개이고, 그보다 적어도 해당 URL이 전부 나온다는 보장은 없습니다.
- 목록에서 중요한 페이지 몇 개를 골라 위쪽 검색창(URL 검사)에 넣습니다. 페이지 색인 생성 항목을 펼치면 사이트맵, 참조 페이지, 최근 크롤링 날짜가 보입니다.
먼저 그 페이지가 "발견됨"인지 "크롤링됨"인지 확인합니다. "크롤링됨"은 Google이 이미 읽은 페이지라 공식 도움말도 다시 제출할 필요가 없다고 적고 있어요. 이 경우에는 링크나 요청보다 페이지 내용을 먼저 들여다보는 편이 맞습니다.
2. 내부 링크를 점검합니다
브라우저 화면이 아니라 서버가 보내는 HTML을 봐야 합니다. 주소창에 view-source:https://내도메인/blog를 넣고 /blog/로 찾아보면 목록이 실제로 몇 편을 링크하는지 셀 수 있어요. 화면에는 30편이 보여도 소스에 12개뿐이면 나머지는 버튼이나 스크립트로 붙은 것입니다.
확인할 것은 세 가지입니다.
- 글 목록 페이지가 모든 글을
<a href>링크로 담고 있는가. "더 보기"나 무한 스크롤을 쓰면 접혀 있는 글의 링크도 HTML에 남아 있는가. - 홈에서 링크를 몇 번 따라가면 중요한 페이지에 모두 닿는가. 사이트맵 개요는 홈에서 링크를 따라 중요한 페이지를 모두 찾을 수 있는 사이트를 "내부적으로 긴밀히 연결된 사이트"라고 부릅니다.
- 들어오는 링크가 하나도 없는 페이지가 있는가. 이런 페이지는 주제별 허브나 관련 글 목록에 넣습니다.
Claude Code나 Codex에게는 이렇게 맡길 수 있습니다.
이 사이트의 내부 링크를 점검해 줘. 코드는 아직 고치지 말고 보고만 해 줘.
1. https://[내 도메인]/sitemap.xml 의 URL 목록을 받아 줘.
2. 홈과 목록 페이지(/blog 등)를 curl로 받아서, 자바스크립트를 실행하지 않은 HTML에
들어 있는 <a href> 링크만 모아 줘.
3. 사이트맵 URL마다 "사이트 안에서 이 URL로 링크하는 페이지 수"를 세서
0개, 1개인 URL을 표로 보여 줘.
4. 목록 페이지가 버튼·무한 스크롤로 링크를 숨기고 있는지 코드에서 찾아 줘.
비밀값이나 .env 내용은 출력하지 마.
3. 색인 생성 요청은 핵심 페이지에만 씁니다
우리 데이터에서 9월 25일 이후 새로 색인된 페이지는 모두 URL 검사에서 색인 생성 요청을 넣은 페이지였습니다. 이 버튼은 Search Console 속성의 소유자나 전체 권한 사용자만 쓸 수 있습니다. 문제는 하루에 넣을 수 있는 수가 적다는 점이에요. Google 문서는 "개별 URL을 제출하는 데는 할당량이 있으며, 동일한 URL에 재크롤링을 여러 번 요청하더라도 더 빨리 크롤링되지는 않습니다"라고만 적고 정확한 숫자는 밝히지 않습니다(재크롤링 요청 문서).
aicreatorlab.com 한 속성에서 제가 겪은 한도는 날마다 달랐습니다. 아래는 "할당량 초과"가 뜰 때까지 들어간 수를 기록해 둔 날만 모은 것입니다.
| 날짜 | 들어간 요청 수(그 뒤 할당량 초과) |
|---|---|
| 9월 11일 | 2 |
| 9월 17일 | 11 |
| 9월 23일 | 1 |
| 9월 25일 | 9 |
기록한 네 번 중 두 번은 911건, 두 번은 12건이었습니다. 그래서 요청할 페이지를 먼저 고릅니다. 새로 발행한 글, 검색으로 들어왔으면 하는 핵심 글, 주제 허브처럼 다른 페이지로 링크를 많이 내보내는 페이지가 우선입니다. 같은 URL을 매일 다시 넣지는 않습니다. 요청해도 크롤링까지 며칠에서 몇 주가 걸릴 수 있고 색인이 보장되지도 않습니다.
4. 같은 URL 목록으로 다시 잽니다
한두 주 뒤에 같은 URL 목록을 다시 검사해서 비교합니다. 보고서 그래프는 집계가 늦게 반영되기도 해서 저는 URL 하나하나의 상태를 표로 남겼어요. 비교할 때는 위에서처럼 "요청한 URL"과 "요청하지 않은 URL"을 나눠야 무엇이 효과가 있었는지 보입니다.
URL이 수십 개를 넘으면 URL Inspection API로 한 번에 받을 수 있습니다. 사용 한도 문서 기준으로 속성당 하루 2,000회, 분당 600회까지 검사할 수 있습니다. 이 API는 상태를 읽기만 하고 색인 생성 요청은 넣지 못합니다. 요청은 Search Console 화면에서 해야 합니다.
Search Console URL Inspection API로 내 사이트맵 URL 전체의 색인 상태를 표로 만들어 줘.
- 인증은 서비스 계정 JSON 파일([파일 경로])을 쓰고, 범위는 읽기 전용
https://www.googleapis.com/auth/webmasters.readonly 로 해 줘.
키 내용과 토큰은 화면이나 파일에 출력하지 마.
- 속성은 [Search Console에 등록한 속성 주소], 사이트맵은 https://[내 도메인]/sitemap.xml.
- 응답의 inspectionResult.indexStatusResult 안에 있는 coverageState, lastCrawlTime,
referringUrls, sitemap 을 URL마다 JSON 파일로 저장하고
coverageState별 개수를 출력해 줘.
- 이전 결과 파일([이전 파일 경로])이 있으면 상태가 바뀐 URL만 따로 보여 줘.
서비스 계정을 쓰려면 Search Console의 설정 > 사용자 및 권한에 그 서비스 계정 이메일을 사용자로 추가해야 합니다. 이 단계가 번거로우면 URL 검사 화면에서 핵심 페이지 몇 개만 직접 확인해도 충분합니다.
자주 묻는 질문
사이트맵을 다시 제출하면 '발견됨'이 줄어드나요?
이미 발견된 URL이라면 기대하기 어렵습니다. "발견됨"은 주소는 알고 있다는 뜻이니까요. 우리 사이트도 9월 23일에 사이트맵을 다시 제출했지만 요청하지 않은 URL 43개는 2주 동안 하나도 색인되지 않았습니다.
내부 링크는 그럼 소용없나요?
그렇지 않습니다. 사이트맵에 없는 페이지나 새로 만든 페이지는 링크가 있어야 발견됩니다. Google도 링크로 새 페이지를 찾는다고 공식 문서에 적고 있어요. 우리 경우는 이미 사이트맵으로 발견된 페이지가 많아서 링크 수정만으로 크롤링이 당겨지지 않았던 것입니다.
'발견됨' 페이지를 지우거나 noindex를 넣어야 하나요?
noindex는 답이 아닙니다. 크롤링 예산 문서는 중복이거나 중요하지 않은 URL이 많으면 크롤링 시간이 낭비된다고 하면서 대응으로 중복 콘텐츠 통합, robots.txt 차단, 영구 삭제한 페이지의 404·410 응답을 듭니다. noindex는 Google이 계속 요청한 뒤에 버리기 때문에 크롤링 시간을 아끼지 못한다고 적고 있어요. 사이트맵에는 크롤링되길 바라는 콘텐츠를 모두 넣으라고 합니다. 검색에 나오길 원하는 페이지라면 지우기보다 내용을 보강하고 핵심 페이지부터 색인 요청을 넣는 편이 낫습니다.
다음 단계
- Search Console과 네이버 서치어드바이저 첫 등록은 홈페이지 검색 등록: Search Console·네이버 첫 설정에 정리했습니다.
- ChatGPT 같은 AI 검색이 내 사이트를 읽게 하는 방법은 AI 검색이 읽는 사이트: llms.txt·구조화 데이터를 보세요.
- 홈페이지로 고객을 만나는 글은 주제별 안내: 홈페이지로 고객 만나기에 모아 두었습니다.
출처와 확인 (2026-10-08)
- Google Search Console 도움말: 페이지 색인 생성 보고서 (발견됨·크롤링됨 정의, 모든 URL 색인을 기대하지 말 것, 500페이지 미만 사이트의
site:확인, 예시 목록 1,000개 제한) - Google Search Console 도움말: URL 검사 도구 (알려지지 않은 URL, 참조 페이지의 의미, 최근 크롤링)
- Google Search Central: 링크 권장사항 (크롤링 가능한
<a href>링크) - Google Search Central: 사이트맵 개요 (사이트맵이 필요한 경우, 색인 비보장, 내부적으로 긴밀히 연결된 사이트)
- Google Search Central: Google에 재크롤링 요청 (요청 권한, 할당량, 반복 요청, 크롤링 소요 기간)
- Google Crawling Infrastructure: 크롤링 예산 최적화 (크롤링 수요 요인, 대상 사이트, 중복 통합·robots.txt·404/410, noindex)
- Search Console API: urlInspection.index.inspect
- Search Console API: 사용 한도 (URL 검사 속성당 하루 2,000회·분당 600회)
- aicreatorlab.com 측정값: Search Console URL Inspection API(2026-09-23, 09-25, 10-08)와 검색 실적 API(2026-09-09~10-06), 읽기 전용



