크롤링됨 - 현재 색인이 생성되지 않음에 JS 파일이 많을 때 할 일

서치콘솔 페이지 색인 생성 보고서를 열었을 때 "크롤링됨 - 현재 색인이 생성되지 않음" 건수가 크게 늘어 있으면, 먼저 글에 문제가 생겼다고 생각하게 됩니다. 그런데 항목을 눌러 URL 목록을 열어 보면 대부분이 .js나 .css 파일 주소입니다.

Next.js로 만든 한 사이트에서는 색인되지 않은 페이지가 249건까지 올라갔고, 그 가운데 "크롤링됨 - 현재 색인이 생성되지 않음"이 155건이었습니다. 목록을 내려받아 열어 보니 155건 가운데 144건이 페이지가 아니었습니다. JS 파일과 CSS 파일, 폰트, 파비콘, 사이트맵, RSS 주소가 목록의 대부분을 차지하고 있었습니다. 이 기록은 특정 사이트만의 문제가 아니라, 프레임워크로 만든 사이트라면 어디서나 생길 수 있는 항목입니다.

서치콘솔의 "크롤링됨 - 현재 색인이 생성되지 않음"에 쌓이는 URL은 대부분 페이지가 아니라 사이트를 구성하는 JS 파일과 CSS 파일입니다. 이 기록은 오류가 아니라, 구글이 페이지를 화면에 그려 보려고 파일을 받아 간 흔적입니다.

위 그림은 구글 서치 센트럴 공식 문서에 실린 처리 과정입니다. 크롤러가 HTML을 받아 온 뒤 렌더링 대기열과 렌더러를 한 번 더 거치는 단계가 있고, 이 단계에서 JS 파일과 CSS 파일 요청이 일어납니다.

JS 파일이 많이 잡혔을 때 가장 먼저 할 일

결론부터 적으면 고칠 것은 거의 없습니다. 다만 아래 세 가지는 순서대로 확인해야 합니다.

URL 목록을 내려받아 정적 파일과 페이지를 나눕니다. 요약 화면의 건수만으로는 무엇이 잡혔는지 알 수 없습니다.
남은 페이지 주소만 하나씩 확인합니다. 지금 살아 있는 본문 페이지인지, 이미 리디렉트를 걸어 둔 옛 주소인지부터 나눕니다.
정적 파일 경로는 robots.txt로 막지 않습니다. 목록에서는 사라지지만 다른 손해가 생깁니다.

아래는 실제 목록의 앞부분에서 사이트 주소와 파일 이름을 가린 것입니다. 형태만 봐도 페이지가 아니라 파일 요청 기록이라는 점이 드러납니다.

https://●●●●●●●●●●/_next/static/chunks/●●●●●●●●●●●●●●●●.js?dpl=dpl_●●●●●●●●●●●●,2026-07-25
https://●●●●●●●●●●/_next/static/chunks/●●●●●●●●●●●●●●●●.js?dpl=dpl_●●●●●●●●●●●●,2026-07-25
https://●●●●●●●●●●/_next/static/css/●●●●●●●●●●●●●●●●.css?dpl=dpl_●●●●●●●●●●●●,2026-07-24
https://●●●●●●●●●●/_next/static/media/●●●●●●●●●●●●.woff2,2026-07-23
https://●●●●●●●●●●/insights/●●●●●●●●●●●●●●,2026-07-25
https://●●●●●●●●●●/tags/DOM,2026-04-13

앞의 네 줄은 화면을 그리는 데 쓰이는 파일이고, 뒤의 두 줄만 실제 페이지입니다. 확인이 필요한 것은 이 가운데 페이지 주소뿐입니다.

"크롤링됨 - 현재 색인이 생성되지 않음"에 JS 파일이 많다는 것은 사이트에 문제가 생겼다는 신호가 아닙니다. 목록에서 정적 파일을 걸러내고 남은 페이지 주소만 확인하면 됩니다.

'크롤링됨 - 현재 색인이 생성되지 않음'의 구글 공식 정의

이 항목의 이름만 보면 문제가 생긴 페이지 목록처럼 읽힙니다. 실제 정의는 다릅니다.

구글 서치 콘솔 도움말은 이 항목을 "Google에서 페이지를 크롤링했지만 색인은 생성되지 않았습니다. 이후에 색인이 생성될 수도 있고 생성되지 않을 수도 있습니다"라고 설명합니다. 오류라는 말은 정의에 들어 있지 않습니다.

한 가지 더 중요한 전제가 있습니다. 페이지 색인 생성 보고서는 구글이 해당 사이트에서 인식하는 모든 URL의 색인 상태를 보여줍니다. 사이트맵에 제출한 주소만 모아 둔 화면이 아니라, 구글이 어떤 경로로든 알게 된 주소가 전부 들어옵니다.

페이지 색인 생성 보고서는 사이트맵에 제출한 주소만 보여주는 화면이 아닙니다. 구글이 인식하는 모든 URL이 대상이므로, 사이트 운영자가 페이지라고 생각하지 않는 주소도 함께 집계됩니다.

Q. 이 항목에 건수가 많으면 사이트에 문제가 있는 것인가요? A. 건수만으로는 판단하기 어렵습니다. 앞의 사례에서는 155건 가운데 실제 페이지 주소가 11건이었고, 그마저도 대부분 이미 처리를 마친 옛 주소였습니다. 나머지는 전부 파일 요청 기록이었습니다.

이 항목에 JS 파일과 CSS 파일이 함께 잡히는 이유

렌더링이라는 말은 크롤링에 비해 상대적으로 낯설 수 있습니다. 쉽게 말하면 구글이 브라우저처럼 페이지를 한 번 실제로 그려 보는 단계입니다. 이 단계에서 어떤 파일이 함께 요청되는지 순서대로 살펴보겠습니다.

요즘 사이트는 HTML 한 장만으로 화면이 완성되지 않습니다. 화면을 이루는 파일은 크게 셋으로 나뉩니다.

폰트 파일: 글자 모양을 결정합니다.
CSS 파일: 요소의 배치와 색을 잡아 줍니다.
JS 파일: 목록 접기나 탭 전환 같은 동작을 맡습니다.

구글이 사람과 같은 화면을 보려면 이 파일들을 함께 받아야 합니다. 그래서 다음 두 가지가 동시에 일어납니다.

크롤링은 일어납니다: 렌더링에 필요하므로 구글이 실제로 요청하고 받아 갑니다.
색인은 되지 않습니다: JS 파일과 CSS 파일은 검색 결과에 내보낼 문서가 아니기 때문입니다.

크롤링은 됐고 색인은 되지 않은 상태, 이 두 조건을 그대로 만족하는 칸이 "크롤링됨 - 현재 색인이 생성되지 않음"입니다.

Q. 그러면 이 파일들을 색인되게 만들어야 하나요? A. 그럴 필요가 없습니다. JS 파일이 검색 결과에 노출되는 것은 사이트 운영에 도움이 되지 않습니다. 구글이 파일을 받아 간 것은 렌더링이 제대로 진행됐다는 신호에 가깝습니다.

배포할 때마다 건수가 늘어나는 구조

건수가 계속 늘어나는 이유는 파일 개수만으로 설명되지 않습니다. 앞의 목록을 실제로 세어 보면 구조가 드러납니다.

구분	개수
서로 다른 JS 파일과 CSS 파일 이름	19개
목록에 등장한 배포 식별자	16개
항목에 집계된 정적 파일 URL	139건

파일 이름은 19개인데 URL은 139건입니다. 같은 파일이 배포할 때마다 다른 주소로 집계됐기 때문입니다. 원인은 주소 뒤에 붙는 배포 식별자입니다.

해당 사이트는 Vercel에 올라가 있고, Vercel은 Skew Protection이라는 기능으로 정적 파일 주소 뒤에 ?dpl= 형식의 배포 식별자를 붙입니다. 배포 직후에도 이전 화면을 열어 둔 방문자가 자기 화면과 짝이 맞는 파일을 받도록 만드는 장치입니다. Vercel 공식 문서는 이 값을 쿼리 문자열이나 헤더로 전달해 같은 배포로 요청을 연결한다고 설명합니다.

위 화면은 Vercel 공식 문서에 실린 Skew Protection 설정 항목입니다. 이 기능이 켜져 있으면 배포할 때마다 값이 바뀌고, 검색엔진은 쿼리 문자열이 다른 주소를 서로 다른 URL로 봅니다. 파일 내용이 그대로여도 배포 횟수만큼 URL이 새로 생깁니다.

이 항목의 건수는 페이지 수를 따라 늘어나지 않습니다. 정적 파일 개수와 배포 횟수를 곱한 값에 가깝게 늘어나므로, 자주 배포하는 사이트일수록 숫자가 크게 보입니다.

같은 구조는 다른 환경에도 있습니다. 워드프레스는 스타일과 스크립트 주소 뒤에 ?ver= 형식의 버전 값을 붙이고, 코어나 플러그인을 업데이트하면 이 값이 바뀝니다. 캐시를 새로 받게 하려고 붙이는 값은 형태가 달라도 결과가 같습니다.

Q. 배포를 줄이면 건수가 줄어드나요? A. 이미 집계된 URL은 그대로 남습니다. 시간이 지나면서 오래된 주소는 목록에서 빠지지만, 배포를 아끼는 방식으로 이 숫자를 관리할 이유는 없습니다. 이 숫자는 사이트 상태를 보여주는 집계일 뿐, 줄이는 것 자체가 목표가 되지는 않습니다.

robots.txt로 정적 파일을 막으면 안 되는 이유

목록에서 정적 파일을 지우는 가장 빠른 방법은 robots.txt로 해당 경로를 막는 것입니다. 이 방법은 쓰지 않는 편이 좋습니다.

구글 서치 센트럴 문서는 차단된 파일에 들어 있는 자바스크립트를 구글 검색이 렌더링하지 않는다고 밝히고 있습니다. 파일을 막으면 구글은 그 파일이 없는 상태로 화면을 그리게 됩니다. 배치가 무너진 화면이나 내용이 비어 있는 화면을 기준으로 사이트가 평가될 여지가 생깁니다.

정적 파일 경로를 robots.txt로 막으면 보고서의 건수는 줄어들지만, 구글이 보는 화면이 실제 방문자의 화면과 달라집니다. 보고서를 정리하려고 평가 기준을 흔드는 선택이 됩니다.

X-Robots-Tag 헤더로 정적 파일에 noindex를 붙이는 방법도 권하지 않습니다. 파일을 받아 가는 동작은 그대로이고, 보고서에서 분류만 "'NOINDEX' 태그에 의해 제외되었습니다"로 옮겨 갑니다. 손이 더 가는데 얻는 것이 없습니다.

앞의 사례에서도 robots.txt에 정적 파일을 막는 규칙은 넣지 않았습니다. 폰트가 들어 있는 경로까지 막으면 글자 모양이 빠진 화면으로 평가될 여지가 있어서, 항목 건수보다 렌더링 정확도를 택한 것입니다.

정상 기록과 진짜 문제를 구분하는 확인 순서

요약 화면만 봐서는 구분이 되지 않습니다. 서치콘솔에서 URL 목록을 받아야 판단할 수 있습니다.

페이지 색인 생성 보고서에서 "크롤링됨 - 현재 색인이 생성되지 않음" 행을 눌러 상세 화면으로 들어갑니다. 요약 화면에서 바로 내보내면 건수만 담긴 파일이 나옵니다.
상세 화면 오른쪽 위의 내보내기로 CSV를 받습니다. 파일에는 URL과 최종 크롤링 날짜가 들어 있습니다.
정적 파일 경로가 들어간 줄을 걸러내고 남은 주소만 봅니다.

터미널에서는 아래 한 줄로 정적 파일을 걸러낼 수 있습니다.

grep -v "/_next/static/" 테이블.csv

남은 주소는 아래 기준으로 나눕니다.

목록에 있는 주소	판단	해야 할 일
JS 파일, CSS 파일, 폰트, 파비콘	정상 기록	없음
sitemap.xml, rss.xml	정상 기록	없음
이미 리디렉트를 걸어 둔 옛 주소	리디렉트 적용 전의 오래된 기록	최종 크롤링 날짜만 확인
현재 살아 있는 본문 페이지	확인 대상	내용과 내부 링크 점검
항목이 적은 목록 페이지나 태그 페이지	확인 대상	색인 대상에서 뺄지 판단

Q. 최종 크롤링 날짜는 왜 같이 봐야 하나요? A. 이 보고서는 마지막으로 크롤링한 시점의 상태를 그대로 보여줍니다. 앞의 목록에도 1월과 4월에 크롤링된 옛 주소가 남아 있었는데, 그 뒤에 리디렉트를 걸어 둔 주소였습니다. 날짜가 조치 시점보다 앞서면 이미 해결된 항목입니다.

프레임워크별로 확인해야 할 정적 파일 경로

경로 이름만 알면 걸러내는 작업은 금방 끝납니다. 널리 쓰이는 환경의 정적 파일 위치를 정리하면 다음과 같습니다.

환경	정적 파일 경로	주소에 붙는 값
Next.js	`/_next/static/`	Vercel 배포 시 `?dpl=`
Nuxt	`/_nuxt/`	파일 이름에 해시
Vite, 리액트 단독 빌드	`/assets/`	파일 이름에 해시
Angular	루트의 `main.[해시].js` 형식	파일 이름에 해시
워드프레스	`/wp-includes/`, `/wp-content/`	`?ver=`

파일 이름에 해시가 들어가는 방식은 파일이 바뀔 때만 주소가 바뀌므로 증가 폭이 완만합니다. 쿼리 문자열로 버전을 붙이는 방식은 내용이 그대로여도 주소가 새로 생겨서 숫자가 빨리 늘어납니다.

이 항목에서 실제 조치가 필요한 URL의 특징

정적 파일을 걸러낸 뒤 남는 주소는 세 가지 성격으로 나뉩니다.

현재 살아 있는 본문 페이지: 진짜 확인 대상입니다. 내용이 짧거나 내부 링크가 거의 없으면 색인이 미뤄지기 쉽습니다.
이미 정리한 옛 주소: 리디렉트나 삭제를 마친 뒤 재크롤링이 되지 않아 남아 있는 기록입니다. 조치는 끝났고 시간이 지나면 분류가 바뀝니다.
항목이 적은 목록 페이지: 태그 페이지처럼 모아 보여주는 페이지에 항목이 몇 개 없으면 색인이 미뤄질 수 있습니다.

앞의 사례에서 남은 페이지 주소도 마찬가지였습니다. 본문 글 한 편은 며칠 뒤 재크롤링되면서 색인이 끝났고, 옛 주소들은 리디렉트를 걸기 전에 크롤링된 기록이었습니다. 콘텐츠가 다섯 편뿐인 태그 페이지 하나만 확인 대상으로 남았습니다. 항목 이름이 주는 인상과 달리 손볼 것은 많지 않았습니다.

정적 파일을 걸러내는 순간 확인해야 할 주소의 수가 크게 줄어듭니다. 앞의 사례에서는 155건이 열 건 남짓으로 줄었습니다.

3줄 요약

서치콘솔 "크롤링됨 - 현재 색인이 생성되지 않음"에 잡히는 URL은 대부분 페이지가 아니라 구글이 렌더링에 쓰려고 받아 간 JS 파일과 CSS 파일입니다.
배포할 때마다 주소 뒤 배포 식별자가 바뀌므로, 건수는 페이지 수가 아니라 정적 파일 개수와 배포 횟수를 곱한 값에 가깝게 늘어납니다.
robots.txt로 정적 파일을 막으면 구글이 실제와 다른 화면으로 사이트를 평가하므로, 막는 대신 URL 목록을 내려받아 정적 파일과 페이지를 분리해 확인합니다.