「발견됨 - 현재 색인이 생성되지 않음 100건」의 정체를 두 번 틀리게 추론했습니다
서치 콘솔이 「페이지 색인 생성 문제」 메일을 보냈습니다. 콘솔 표는 이랬습니다.
| 사유 | 소스 | 페이지 수 |
|---|---|---|
| 적절한 표준 태그가 포함된 대체 페이지 | 웹사이트 | 6 |
| 리디렉션이 포함된 페이지 | 웹사이트 | 1 |
| 발견됨 - 현재 색인이 생성되지 않음 | Google 시스템 | 100 |
| 크롤링됨 - 현재 색인이 생성되지 않음 | Google 시스템 | 7 |
| 합계 114 |
숫자를 읽은 건 2026-09-07인데, 화면 위에 「최종 업데이트: 26. 9. 4.」 라고 적혀 있었습니다. 그러니 114는 2026-09-04 기준 값입니다. 콘솔 숫자는 오늘 것이 아닙니다.
100이 압도적으로 큽니다. 그래서 「이 100개가 뭐냐」부터 답해야 했는데, 저는 목록을 열어보는 대신 두 번 추론했고 두 번 다 틀렸습니다.
추론 ① 「목록 URL 위주일 것이다」
이 도메인에는 apex 하나와 티스토리 커스텀 도메인 두 개가 붙어 있고, 사이트맵 셋을 합치면 137개 URL입니다. 그중 글은 apex 10편 + 서브도메인 99편입니다.
티스토리 쪽에는 목록형 URL이 많습니다. ?page=N, /category, /tag.
그리고 이것들은 canonical이 전부 사이트 루트를 가리킵니다. 그런 URL이 실측 87개였습니다.
숫자가 100 근처라 그림이 그럴듯했습니다 — 「크롤 예산이 목록 URL 더미에 묶여 글까지 못 온다」.
여기에 하나 더 얹었습니다. ?page=1000000 을 요청해도 200이 오니 크롤 공간이 무한이라는 것.
둘 다 틀렸습니다. 페이지네이션 폐포를 52개로 셌는데 실제로는 66개였고,
마지막 페이지를 넘긴 ?page= 는 200을 주지만 페이저가 링크를 0개 렌더합니다
(?page=8·?page=20·?page=11 실측). 크롤러가 따라갈 링크가 없으니 그 너머는
크롤 공간이 아닙니다. 무한이 아니라 66개에서 닫혀 있었습니다.
추론 ② 「글 99편 + 1」
첫 추론이 깨진 뒤 정반대로 갔습니다. 서브도메인 두 곳의 글이 57 + 42 = 99편입니다. 100에서 딱 하나 모자랍니다. 숫자가 이렇게 맞아떨어지면 설득력이 생깁니다.
이번엔 화면을 열기 전에 산술로 반박당했습니다. 사이트맵에 등재돼 있으면서 canonical이 루트를 가리키는 URL이 21개인데, 이것들도 어딘가 버킷에 앉아야 합니다.
앉아야 할 URL 글 99 + 루트-canonical 21 = 120
앉을 수 있는 칸 발견됨 100 + 대체 페이지 6 = 106
120이 106에 안 들어갑니다. 숫자가 예뻐 보였던 것이 오히려 함정이었습니다.
그래서 100행을 열었습니다
「색인 생성 > 페이지」에서 사유 행을 클릭하면 세부정보에 URL 목록이 뜹니다. 2026-09-07에 열었더니 URL 오름차순으로 100행이 나왔습니다. 찾던 패턴을 세어봤습니다.
| 100행에서 찾은 것 | 건수 |
|---|---|
?page=N | 0 |
/category, /category/<이름> | 0 |
/tag | 0 |
/guestbook | 0 |
/m/<번호> (모바일 대체 URL) | 0 |
| 「최종 크롤링」 값이 들어 있는 행 | 0 (100행 전부 「해당사항 없음」) |
추론 ①은 여기서 끝났습니다. 크롤 예산이 목록 URL에 묶여 있다는 그림은 근거가 없었습니다.
그리고 예상 못 한 것이 나왔습니다. apex 자신의 URL이 8행 들어 있었습니다.
https://birchholt.com/posts/
https://birchholt.com/posts/deploy-automation/
https://birchholt.com/posts/hugo-over-astro/
https://birchholt.com/posts/pagination-pitfalls/
https://birchholt.com/posts/soft-404-on-pages/
https://birchholt.com/posts/splitting-the-repo/
https://birchholt.com/posts/tistory-custom-domain/
https://birchholt.com/posts/tistory-skin-live-only-bugs/
당시 apex에 글이 10편이었으니 그중 7편이 한 번도 크롤되지 않은 상태였습니다. 그때까지 저는 이 문제를 「티스토리 구조 탓」으로 좁혀 보고 있었는데, Hugo로 직접 빌드해 올리는 apex도 같았습니다. 호스트를 가리지 않는 문제였습니다.
「최종 크롤링」이 100행 전부 비어 있다는 것
구글 문서가 이 상태를 정확히 설명합니다.
“Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.” — Page Indexing report
앞쪽의 과부하 설명은 제 사이트에 안 맞습니다. 세 호스트 TTFB가 전부 0.32초 미만이고 5xx는 0건이었습니다. 하지만 뒤쪽 — 날짜 칸이 비는 이유 — 은 그대로 적용됩니다.
구글은 이 100개 주소를 알고 있고, 한 번도 가지러 오지 않았습니다. 「발견 안 됨」이 아니라 「발견됐는데 안 읽음」입니다. 그래서 발견 경로를 늘리는 조치는 전부 헛일이었습니다. 발견은 이미 끝나 있었습니다.
화면의 「100」이 건수인지 행 수인지부터 가르십시오
함정이 하나 남아 있습니다. 화면에 100이 떴다고 100건이라는 뜻이 아닙니다. 문서에서 이 리포트의 상한으로 명시된 숫자는 1,000 하나뿐입니다.
“The list does not necessarily show all URLs with that issue, and is limited to 1,000 rows.” — 같은 문서
「100」이라는 상한은 문서 어디에도 없습니다. 그러면 화면의 100은 둘 중 하나입니다 — 실제 건수이거나, 표 하단 페이저의 「페이지당 행 수」이거나. 후자면 실제 건수는 더 큽니다. 가르려면 같은 값을 두 군데서 읽어 대조합니다. 순서가 중요합니다.
| 순서 | 할 것 | 대조 결과 |
|---|---|---|
| 1 | 사유 요약 표의 「페이지 수」 열을 먼저 적는다 (이쪽이 권위 있는 건수다) | — |
| 2 | 사이트맵별 필터를 쓰고 있었다면 「모든 알려진 페이지」로 되돌린다 (필터가 내보내기에 그대로 따라간다) | — |
| 3 | 세부정보 우측 상단 내보내기로 받아 행 수를 센다 | 「페이지 수」 = 행 수 = 100 → 100이 실제 건수 · 「페이지 수」 > 100 → 화면의 100은 페이저의 「페이지당 행 수」 |
⚠️ 행 수가 맞아떨어져도 「전수」로 확정하면 안 됩니다. 같은 문서에 이렇게 적혀 있습니다 — 이 목록은 “isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items”. 내보내기가 보장하는 건 「보고서가 아는 것 전부」이지 「사이트의 실제 미색인 집합 전부」가 아닙니다.
이 한 장이 지운 할 일들
100행을 보기 전까지 아래 넷은 전부 「할 일」 목록에 있었습니다.
| 하려던 것 | 폐기 사유 |
|---|---|
| 페이저 번호 URL 제거 | 100행에 ?page= 0건. 크롤 예산을 먹고 있지 않았다 |
/category·/tag 링크 정리 | 〃 0건 |
| 사이트맵 추가 손질 | 제출된 사이트맵은 이미 「성공」이고 URL은 전부 발견돼 있다. 발견이 문제가 아니다 |
| 「구조적 미색인 23건을 먼저 빼고 보라」 | 애초에 그 23건이 100 안에 없었다 |
같은 조사에서 「내부링크를 늘리면 크롤이 온다」도 같이 깨졌는데, 그건 따로 적었습니다.
내가 틀렸던 지점
하나. 정반대인 두 추론이 둘 다 틀렸습니다. 「목록 URL 위주」는 관측으로, 「글 99 + 1」은 산술로 깨졌습니다. 두 번 다 콘솔 목록을 여는 데 몇 분이면 끝날 일이었습니다. 관측할 수 있는 것을 추론하면, 틀려도 틀린 줄 모르는 채로 며칠이 갑니다.
둘. 「전부 실제 글 URL이었다」고 적어놓고 첫 행이 목록 페이지였습니다.
https://birchholt.com/posts/ 는 글이 아니라 섹션 목록입니다.
apex 8행을 「글 8건」으로 세어뒀는데 실제로는 목록 1 + 글 7이었습니다.
제가 「0건」으로 센 패턴들(?page=·/category·/tag·/guestbook·/m/)에
/posts/ 는 안 걸리니 눈금 사이로 빠져나간 겁니다.
큰 결론은 그대로지만 「전부」는 과장이었습니다.
세는 규칙이 배타적이지 않으면 0건도 믿을 게 못 됩니다.
셋. 「유효성 검사 시작을 누르지 마라」고 절차서에 써놓고, 이미 눌린 뒤였습니다. 화면이 「유효성 검사 상태: 시작됨 · 시작된 날짜: 26. 9. 7.」이었습니다. 되돌리는 방법은 없습니다. 다만 해롭지도 않았습니다.
- 색인에는 영향이 없습니다 — “Even if you never click Start validation Google can detect fixed instances of an issue.”
- 고친 게 없으니 표본 검사에서 인스턴스가 바로 발견돼 「실패」로 끝나고, 실패해도 페널티는 없습니다
- 실질 비용은 하나 — 성공/실패가 확정될 때까지 이 사유에 다시 못 누릅니다 (“Do not click Validate fix again until validation has succeeded or failed”, 보통 2주)
이 버튼은 알림·추적용 편의이지 색인의 전제조건이 아닙니다. 그리고 맨 위 표의 소스 열을 다시 보면 「발견됨」과 「크롤링됨 - 색인 미생성」은 소스가 Google 시스템입니다. 애초에 제가 고칠 대상이 아니었습니다.
아직 추론인 채로 남겨두는 것
100행 중 apex가 8행이면 서브도메인은 92행입니다. 서브도메인 글이 99편이니 7편이 이 버킷 밖에 있고, 「크롤링됨 - 현재 색인이 생성되지 않음」이 마침 7건입니다. 숫자가 또 예쁘게 맞습니다.
그런데 이건 또 추론입니다. 저는 그 7건 버킷의 URL 목록을 열지 않았습니다. 이 글이 두 번 틀린 방식이 정확히 이 모양이라, 확인할 때까지 추론으로 두겠습니다.
정리
- 미색인 114는 2026-09-04 기준 값이었습니다. 읽은 건 2026-09-07이고요. 콘솔 숫자는 오늘 것이 아닙니다
- 100의 구성을 두 번 추론했고 두 번 다 틀렸습니다. 관측 가능한 것을 추론하지 마십시오
- 100행에 목록 URL은 0건, 「최종 크롤링」 값이 있는 행도 0행 — 발견은 됐고 읽히지는 않았습니다
- 화면의 100은 상한이 아닙니다. 문서화된 상한은 1,000뿐이니 요약 표의 「페이지 수」와 내보내기 행 수를 대조하십시오. 맞아떨어져도 “even when less than 1,000 items” 라 전수는 아닙니다
- 세는 눈금이 배타적이지 않으면 「0건」도 증거가 못 됩니다. 저는 목록 페이지 하나를 그렇게 놓쳤습니다