서치콘솔 '발견됨'과 '크롤링됨' 색인 안 됨의 차이와 처방

결론부터

서치콘솔에 "색인이 생성되지 않음"이 많은데, 이유 줄이 "발견됨"과 "크롤링됨" 두 가지로 갈려 있습니다. "발견됨"은 구글이 주소만 알고 와 보지도 않은 것이고, "크롤링됨"은 읽어 보고 넣지 않기로 한 것입니다. 크롤링됨이 많으면 비슷한 글을 합치고 줄이고, 발견됨이 많으면 글을 더 늘려도 소용없으니 사이트 신뢰를 쌓는 쪽으로 갑니다.

"색인이 안 된다" 한마디에 두 문제가 섞였다

서치콘솔 왼쪽 메뉴 "색인생성"에서 "페이지"를 열면 아래쪽에 "페이지 색인이 생성되지 않는 이유" 표가 나옵니다. 여기 숫자가 크면 흔히 "색인이 안 된다"로 뭉뚱그려 말합니다. 그런데 이 표 안의 두 줄은 원인이 정반대라, 섞어서 보면 처방도 반대로 갑니다.

같이 놀라게 되는 숫자도 둘 있었습니다. "NOINDEX 태그로 제외됨"이 글 수보다 컸고, 서버 접속 기록에는 구글봇이 403을 받은 줄이 있었습니다. 둘 다 차단 문제처럼 보였지만, 열어 보니 문제가 아니었습니다.

두 줄의 뜻은 정반대다

보고서 표시 뜻 주된 원인 처방
발견됨 - 현재 색인이 생성되지 않음 주소는 아는데 와 보지도 않았다 크롤을 적게 받는다. 새 사이트, 방문자가 적은 사이트에 쌓인다 글을 더 늘려도 소용없다. 외부 링크, 기존 글 강화
크롤링됨 - 현재 색인이 생성되지 않음 읽어 보고 넣지 않기로 했다 품질, 중복. 같은 대상을 표기만 바꾼 글이 여기 쌓인다 합치고 줄인다. 새 글을 더 쓰면 더 쌓인다

제가 본 보고서는 발견됨이 154, 크롤링됨이 4였습니다. 구글이 주소는 알면서 거의 와 보지도 않은 경우입니다. 이럴 때 글을 더 써서 올리면 발견됨 숫자만 같이 늘어납니다. 반대로 크롤링됨 쪽이 큰 보고서라면, 구글이 이미 와서 읽고 넣지 않기로 한 글이 쌓인 것이라 글을 고치거나 합치는 쪽이 먼저입니다.

구글 도움말은 발견됨을 "사이트에 부담을 줄 것 같아 크롤을 미뤘다"고 설명합니다. 저는 여기에 더해 크롤 예산과 사이트 신뢰도로 읽었는데, 이것은 제 대조에서 나온 해석이고 구글이 밝힌 기준은 아닙니다.

NOINDEX 숫자가 글 수보다 큰 이유

"NOINDEX 태그로 제외됨"이 공개한 글 수보다 많이 잡혀 있었습니다. 열어 보니 태그 목록 페이지와 작성자 페이지였습니다. SEO 플러그인이 일부러 follow, noindex로 둔 것이라 정상입니다. 짐작하지 말고 실제 머리글을 받아 봅니다.

curl -sL "https://example.com/tag/<슬러그>/" | grep -io '<meta name="robots"[^>]*'

태그 페이지가 noindex이고 글 본문이 index, follow면 문제가 없습니다. 다만 태그를 글마다 많이 만드는 사이트라면 이 숫자는 글이 늘수록 계속 커집니다. 숫자가 커졌다고 걱정할 일은 아니지만, 글 본문 쪽에 noindex가 섞이지 않았는지는 한 번씩 확인합니다.

구글봇이 받은 403은 대개 가짜 구글봇이다

접속 기록에서 구글봇 이름으로 403을 받은 요청을 보면 /.env.old, /@fs/root/.aws/credentials 같은 주소였습니다. 구글봇인 척한 공격 요청입니다. 반대로 404는 사라진 글 주소처럼 진짜 내 쪽 문제인 경우가 많았습니다.

cat /var/log/nginx/example.com.access.log | grep -a Googlebot \
  | awk '$9==403 || $9==404 {print $9, $7}' | sort | uniq -c | sort -rn

구글봇인지 확실히 가리려면 주소 모양만 보지 말고 구글 문서가 권하는 두 단계를 거칩니다. 먼저 IP를 거꾸로 조회해 이름이 googlebot.com이나 google.com으로 끝나는지 보고, 그 이름을 다시 정방향으로 조회해 처음 IP와 같은지 봅니다. 둘 다 맞아야 진짜입니다.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

구글봇 방문 횟수 자체도 신호입니다. 글이 백 편을 넘는데 진짜 구글봇이 하루 네댓 번만 온다면, 구글이 사실상 관심을 두지 않는 상태로 읽었습니다.

판정 순서를 지킨다

  1. 직접 조치부터 봅니다. 한국어 서치콘솔에서는 "수동 조치"가 아니라 "보안 및 직접 조치" 아래 "직접 조치"입니다. "감지된 문제 없음"이면 알고리즘 판정이라 고칠 수 있습니다.
  2. 발견됨 대 크롤링됨 비율을 봅니다. 크롤을 못 받는 문제인지, 읽히고 버려지는 문제인지 가립니다.
  3. 서버 로그의 구글봇 방문 횟수를 봅니다. 1번과 2번의 해석을 받쳐 줍니다.
  4. 글별 노출과 클릭률을 봅니다. 노출이 많은데 클릭이 0에 가깝다면 제목과 검색 의도가 어긋났거나 같은 말을 여러 편에 나눠 쓴 것입니다.

사이트맵이 제대로 읽히지 않으면 발견조차 늦어집니다. 이 부분은 서치콘솔 사이트맵이 안 읽힐 때에서 다뤘습니다.

처방이 맞았는지 보는 법

서치콘솔 대부분의 숫자는 API로도 읽을 수 있지만, 직접 조치 화면과 이유별 URL 목록 두 가지는 화면에서 봐야 했습니다. 정비한 뒤에는 같은 이유 줄의 숫자가 어느 쪽으로 움직이는지 봅니다. 글 하나하나는 URL 검사로 확인하는데, 주소를 잘못 넣으면 전부 "모름"으로 나오는 함정이 있어 URL 검사가 전부 unknown일 때에 따로 적었습니다.

확인한 환경

항목 값
도구 구글 서치콘솔 한국어 화면, nginx 접속 기록
확인한 날짜 2026년 9월 23일

이 글의 내용은 2026년 10월 5일에 마지막으로 확인했습니다. 틀린 곳을 발견하시면 연락처로 알려 주세요.