- 두 상태의 차이「발견됨」은 아직 크롤링하지 않은 페이지입니다. 「크롤링됨」은 크롤링했지만 색인하지 않은 페이지입니다.
- 우선 확인할 곳「발견됨」은 서버 응답과 URL 수를, 「크롤링됨」은 페이지 내용과 중복 여부를 점검합니다.
- 하지 않을 일같은 URL의 색인 생성 요청을 되풀이해도 빠른 색인은 보장되지 않습니다. 원인을 고친 뒤 중요한 페이지만 요청합니다.
서치 콘솔 페이지 색인 생성 보고서에는 「색인이 생성되지 않은 이유」 표가 있습니다. 이 표에서 자주 함께 보이는 두 줄이 있습니다. 「크롤링됨 - 현재 색인이 생성되지 않음」과 「발견됨 - 현재 색인이 생성되지 않음」입니다. 이름은 비슷하지만 멈춘 단계가 다르고, 그래서 점검할 부분도 다릅니다. 이 글은 Google 공식 도움말을 바탕으로 두 상태의 차이와 점검 순서를 정리합니다.
「크롤링됨」과 「발견됨」은 무엇이 다를까요? 🔍
두 상태는 Google이 멈춘 단계가 다릅니다. 「발견됨」은 주소만 알고 아직 페이지를 가져가지 않은 상태입니다. 「크롤링됨」은 페이지를 가져가 읽었지만 색인에 넣지 않은 상태입니다.
Search Console 도움말은 「발견됨」을 이렇게 설명합니다. Google이 크롤링하려 했지만 사이트에 부담이 될 것으로 보여 일정을 다시 잡은 경우가 일반적입니다. 「크롤링됨」은 앞으로 색인이 생성될 수도, 생성되지 않을 수도 있는 상태로 설명합니다.
Google 검색은 크롤링·색인 생성·검색결과 게재 세 단계로 진행됩니다. 「발견됨」은 크롤링 앞에서, 「크롤링됨」은 색인 생성 앞에서 멈춘 상태입니다.
링크·사이트맵
크롤링 대기
페이지 가져오기
색인 보류
검색결과 게재 후보
| 구분 | 발견됨 | 크롤링됨 |
|---|---|---|
| 멈춘 단계 | 크롤링 전 | 색인 생성 전 |
| Google이 페이지 내용을 봤는가 | 아직 보지 않음 | 이미 봄 |
| 공식 설명의 요지 | 서버 부담 예상으로 크롤링 일정 연기 | 이후 색인 여부 미정 |
| 우선 확인할 곳 | 서버 응답·URL 수·내부 링크 | 내용 품질·중복·표준 URL |
| 다시 제출 | 원인 정리 후 사이트맵 갱신 | 재제출 불필요(영문 도움말) |
정리하면 「발견됨」은 «수집 단계의 문제», 「크롤링됨」은 «색인 판단 단계의 문제»입니다. 아래에서 각각의 점검 순서를 정리합니다.
「발견됨」이 많으면 무엇부터 확인할까요? 🛠️
「발견됨」이 많으면 서버가 크롤링을 감당하는지와 불필요한 URL이 많은지를 우선 확인합니다. Google은 서버에 과부하를 주지 않는 범위에서 크롤링량을 정하기 때문입니다.
Google 크롤링 예산 문서는 이 한도를 «크롤링 용량 한도»라고 부릅니다. 여기에 사이트 규모·인기도·갱신 빈도에 따른 «크롤링 수요»가 더해져 실제 크롤링량이 정해집니다.
1. 서버 응답부터 확인
크롤링 통계 보고서에서 호스트 상태와 평균 응답 시간을 봅니다. robots.txt·DNS·서버 연결 문제가 있으면 이것부터 고칩니다.
2. 불필요한 URL 줄이기
필터·정렬 매개변수처럼 같은 내용을 여러 주소로 만드는 URL을 정리합니다. 크롤링을 원하지 않는 URL은 robots.txt로 막습니다. 다만 canonical로 통합할 중복 주소는 막지 않습니다.
3. 사이트맵 갱신
색인을 원하는 페이지만 사이트맵에 넣습니다. 내용이 바뀐 페이지에는 lastmod 날짜를 정확히 적습니다.
4. 내부 링크 연결
새 페이지를 메뉴·목록·관련 글에서 링크합니다. 링크가 없는 페이지는 사이트맵에만 의존하게 됩니다.
- 크롤링 통계 보고서는 1,000페이지 미만 사이트에는 필요 없을 수 있습니다(도움말 안내).
- 이 경우 서버 응답보다 내부 링크와 사이트맵을 먼저 확인합니다.
- 새 글을 올린 직후의 「발견됨」은 크롤링 대기일 수 있어 일정 기간 지켜봅니다.
「크롤링됨」이 많으면 무엇부터 확인할까요? 📄
「크롤링됨」이 많으면 페이지 내용과 중복 여부를 점검합니다. Google이 이미 페이지를 읽었으므로 접근 문제보다 색인할 가치 판단 쪽에 원인이 있을 가능성이 큽니다.
Google 검색 작동 방식 문서는 처리한 모든 페이지가 색인되지는 않는다고 밝힙니다. 색인 단계의 문제로는 낮은 콘텐츠 품질, 색인을 막는 robots 메타 규칙, 어려운 사이트 구조를 듭니다.
URL 검사 도구로 한 페이지씩 확인하면 원인을 좁힐 수 있습니다.
| 확인 항목 | 보이는 신호 | 조치 |
|---|---|---|
| 표준 URL | Google 선택 표준이 다른 주소 | 중복 페이지 통합·canonical 정리 |
| 내용 깊이 | 같은 주제의 짧은 글 여러 편 | 한 편으로 합쳐 보강 |
| 색인 차단 | noindex(보통 별도 상태로 분류) | 의도한 설정인지 확인 |
| 사이트 구조 | 내부 링크 거의 없음 | 목록·관련 글에서 연결 |
- Search Console 영문 도움말은 이 상태의 URL을 다시 제출할 필요가 없다고 적습니다.
- 내용을 고치지 않고 다시 요청하면 같은 판단이 나올 수 있습니다.
- 보강할 가치가 없는 페이지는 통합이나 삭제를 검토합니다.
목록에 있는 페이지는 모두 색인되어야 할까요? ⚖️
아니요. 모든 페이지가 색인될 필요는 없습니다. 보고서 도움말은 모든 URL이 아니라 표준 페이지만 색인된다고 기대하라고 안내합니다.
그래서 두 상태의 숫자가 크다는 것만으로 문제라고 볼 수 없습니다. 목록의 URL이 «검색에 나와야 하는 페이지»인지 먼저 구분합니다.
| 페이지 유형 | 목록에 있을 때 판단 |
|---|---|
| 서비스·제품 소개 | 원인 확인 필요 |
| 정보성 글 | 내용·중복 점검 |
| 태그·사이트 내 검색결과 | 대부분 정상 |
| 필터·정렬 주소 | 정상일 수 있음 |
| 인쇄용·임시 주소 | 색인 불필요 |
서비스 소개나 대표 글이 목록에 있다면 바로 원인을 확인합니다. 태그·필터 주소만 쌓여 있다면 크롤링을 원하는지부터 정합니다. 크롤링 예산 문서는 크롤링을 원하지 않는 URL을 noindex보다 robots.txt로 막도록 권합니다. noindex 페이지는 Google이 계속 요청하기 때문입니다. robots.txt는 이미 색인된 페이지를 지우는 수단이 아닙니다.
색인 생성 요청은 언제 써야 할까요? 📮
색인 생성 요청은 원인을 고친 뒤 중요한 페이지에만 씁니다. URL 검사 도구의 요청에는 하루 제출 한도가 있고, 요청해도 색인이 보장되지 않습니다.
요청 버튼은 «고친 결과를 빨리 다시 보게 하는 수단»입니다. 원인을 고치는 수단이 아닙니다.
페이지가 많으면 하나씩 요청하는 대신 사이트맵을 갱신해 제출합니다. URL 검사 도구 도움말도 여러 페이지는 사이트맵이 효과적이라고 안내합니다.
요청 전에는 «실제 URL 테스트»를 먼저 실행합니다. 지금 서비스 중인 페이지를 기준으로 색인 가능 여부를 보여 주므로, 수정이 반영됐는지 확인할 수 있습니다.
두 상태를 어떤 순서로 점검할까요? ✅
점검은 «어느 상태인가 → 검색에 나와야 하는 페이지인가 → 원인 수정 → 재확인» 순서로 진행합니다. 이 순서를 지키면 같은 요청을 되풀이하는 일을 줄일 수 있습니다.
한 번에 모든 URL을 보지 않고, 검색에 나와야 하는 페이지부터 확인합니다.
발견됨·크롤링됨
서버·URL 또는 내용·중복
두 상태의 URL은 따로 내려받아 페이지 유형별로 기록합니다. 고친 뒤에는 같은 보고서에서 상태 변화를 다시 확인합니다.
참고 자료 📚
- Google Search Console 도움말 — 페이지 색인 생성 보고서
- Google Search Console 도움말 — URL 검사 도구
- Google Search Console 도움말 — 크롤링 통계 보고서
- Google 크롤링 인프라 문서 — 크롤링 예산 관리
- Google 검색 센터 — Google 검색의 작동 방식의 상세 가이드
