크롤링됨 - 현재 색인이 생성되지 않음에 JS 파일이 많을 때 할 일
Search Console의 미색인 목록에 JS와 CSS 주소가 많을 때 파일과 본문 페이지를 먼저 구분합니다. 특정 사이트의 사례를 바탕으로 URL 목록을 읽고, 실제로 확인할 페이지를 고르는 순서를 설명합니다.

세 줄로 먼저 읽기
- 이 항목에는 본문 페이지뿐 아니라 구글이 화면을 그려 보려고 받아 간 JS 파일과 CSS 파일도 함께 쌓입니다.
- 한 사이트에서는 155건 가운데 144건이 파일이었고, 이럴 때는 건수보다 URL 목록을 내려받아 페이지만 골라내는 일이 먼저입니다.
- 정적 파일을 robots.txt로 막으면 구글이 자바스크립트를 렌더링하지 못해 방문자가 보는 것과 다른 화면을 기준으로 처리하게 됩니다.
Search Console은 Google 검색에서 내 사이트가 어떻게 수집되고 노출되는지 보여 주는 도구입니다. 페이지 색인 보고서에 "크롤링됨 - 현재 색인이 생성되지 않음"이 많아도 건수만으로는 글에 문제가 있는지 알 수 없습니다. 먼저 목록의 URL(웹 주소)이 무엇을 가리키는지 봐야 합니다.
크롤링은 Google이 주소에 접근해 자료를 받아 가는 일이고, 색인은 받아 간 내용을 검색에 쓸 수 있게 처리해 저장하는 일입니다. Google이 받아 간 자료가 모두 검색 결과에 나오지는 않습니다.
웹사이트를 만드는 프레임워크인 Next.js로 만든 한 사이트에서는 색인되지 않은 페이지가 249건까지 올라갔고, 그 가운데 "크롤링됨 - 현재 색인이 생성되지 않음"이 155건이었습니다. 목록을 내려받아 열어 보니 155건 가운데 144건이 페이지가 아니었습니다.
한 사이트의 미색인 목록을 열어 본 결과
249건색인되지 않은 페이지페이지 색인 보고서 전체
155건크롤링됨, 색인 안 됨이 글이 다루는 항목
144건페이지가 아닌 주소JS, CSS, 폰트 같은 파일
페이지가 아닌 144건에는 JS와 CSS, 글꼴 파일인 폰트, 브라우저 탭의 아이콘인 파비콘, 페이지 목록인 사이트맵, 새 글 정보를 내보내는 RSS 주소가 섞여 있었습니다. 그래서 미색인 주소를 고치기 전에 그 주소가 본문 페이지인지, 화면을 만드는 데 쓰는 파일인지부터 나눕니다.
HTML은 제목과 본문 같은 웹 문서의 구조를 표시하는 언어이고, 렌더링은 코드를 처리해 화면을 만드는 과정입니다. 아래 그림은 Google이 자료를 받아 간 뒤 화면 처리를 거쳐 색인하는 순서를 보여 줍니다.
구글 서치 센트럴 공식 문서에 실린 그림입니다. 크롤러가 HTML을 받아 온 뒤 렌더링 대기열과 렌더러를 한 번 더 거치는데, JS 파일과 CSS 파일 요청은 이 단계에서 일어납니다.
JS 파일이 많이 잡혔을 때 가장 먼저 할 일
JS는 자바스크립트로 된 실행 코드이고, CSS는 배치와 색 같은 화면 표현을 정하는 파일입니다. 정적 파일은 이런 코드나 글꼴처럼 웹페이지가 불러다 쓰는 파일을 가리킵니다. 정적 파일은 검색에 노출할 대상이 아니므로 색인되게 고칠 일이 없고, 정상으로 전달되는지만 확인합니다. 실제로 점검할 것은 목록에 섞인 페이지입니다.
- URL 목록을 내려받아 정적 파일과 페이지를 나눕니다. 요약 화면의 건수로는 무엇이 잡혔는지 알 수 없습니다.
- 남은 페이지 주소만 하나씩 봅니다. 지금 살아 있는 본문 페이지인지, 이미 리디렉트(옛 주소로 들어온 사람을 다른 주소로 보내는 처리)를 걸어 둔 옛 주소인지부터 가립니다.
- 정적 파일 경로는 robots.txt로 막지 않습니다. 막아도 목록에서 빠진다는 보장이 없고, 화면을 그리는 데 필요한 파일을 Google이 읽지 못하게 됩니다.
아래는 앞의 사이트에서 내려받은 실제 목록의 앞부분이고, 사이트 주소와 파일 이름은 가렸습니다. 주소 모양만 봐도 대부분 페이지가 아니라 파일 요청 기록입니다.
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앞의 네 줄은 화면을 그리는 데 쓰는 파일이고, 뒤의 두 줄만 실제 페이지입니다. 줄 끝의 날짜는 마지막으로 크롤링한 날입니다. ? 뒤는 주소에 추가 값을 붙이는 쿼리 문자열이라, 첫 줄은 ?dpl= 앞의 .js를 보고 파일 종류를 가립니다. 색인이 필요한지 따져 볼 대상은 뒤의 두 페이지이고, 파일 주소는 화면 전달에 문제가 없는지만 봅니다.
'크롤링됨 - 현재 색인이 생성되지 않음'의 구글 공식 정의
항목 이름만 보면 문제가 생긴 페이지 목록 같지만, Google 도움말은 이 항목을 수집은 했고 아직 색인하지 않은 상태로 정의합니다. 나중에 색인될 수도 있고 끝내 색인되지 않을 수도 있으며, 이 상태 자체가 오류 원인을 알려 주지는 않습니다.
크롤링됨과 색인됨의 차이
| 상태 | ||
|---|---|---|
| Google이 주소를 받아 감 | 제공 | 제공 |
| 검색 결과에 나올 수 있음 | 제공하지 않음 | 제공 |
| 상태 이름이 오류 원인을 알려 줌 | 제공하지 않음 | – |
보고서가 다루는 범위도 알아 둘 만합니다. 페이지 색인 생성 보고서는 사이트맵에 제출한 주소만 모은 화면이 아니라, Google이 그 사이트에서 알고 있는 모든 URL의 색인 상태를 보여 줍니다. 그래서 운영자가 페이지라고 생각하지 않는 파일 주소도 함께 집계됩니다. 상세 화면에서 볼 수 있는 URL 예시는 최대 1,000개입니다.
앞의 사례에서는 155건 가운데 실제 페이지 주소가 11건이었고, 그 대부분은 이미 처리를 마친 옛 주소였습니다. 나머지는 모두 파일 요청 기록이었습니다.
이 항목에 JS 파일과 CSS 파일이 함께 잡히는 이유
렌더링은 구글이 브라우저처럼 페이지를 실제로 한 번 그려 보는 단계입니다. 요즘 사이트는 HTML 한 장으로 화면이 완성되지 않아서, 구글도 사람과 같은 화면을 보려면 아래 파일을 함께 받아야 합니다.
구글이 화면 하나를 그리며 받아 가는 파일
1. HTML제목과 본문의
문서 구조
2. CSS 파일요소의
배치와 색
3. 폰트 파일글자 모양
4. JS 파일목록 접기, 탭 전환 같은
화면 동작
이 파일들은 렌더링에 필요해서 구글이 실제로 요청하고 받아 가므로 크롤링 기록이 남습니다. 하지만 JS와 CSS는 검색에 노출할 본문이 아니라 화면을 만드는 재료라 본문처럼 색인되지 않고, 그 결과 이 항목에 쌓입니다. 목록에 있다는 사실만으로는 구글이 무엇을 위해 받아 갔는지, 렌더링이 성공했는지까지 알 수 없습니다.
이 파일들을 색인되게 만들 이유도 없습니다. JS 파일이 검색 결과에 나와도 사이트 운영에 도움이 되지 않습니다.
배포할 때마다 건수가 늘어나는 구조
건수가 계속 늘어나는 이유는 파일 개수만으로 설명되지 않습니다. 앞의 사이트에서 목록을 집계한 결과는 다음과 같았습니다.
같은 파일이 여러 주소로 집계된 기록
19개서로 다른 JS, CSS 파일 이름
16개목록에 나온 배포 식별자
139건반복 배포와 관련된 파일 URL
파일 이름은 19개인데 관련 URL은 139건입니다. 같은 파일이 배포할 때마다 다른 주소로 집계됐기 때문이고, 그 원인은 주소 뒤에 붙는 배포 식별자입니다.
Vercel은 웹사이트를 배포하는 서비스입니다. 이 사이트는 Vercel에 올라가 있었고, Vercel의 Skew Protection 기능은 정적 파일 주소 뒤에 ?dpl= 형식의 배포 식별자를 붙입니다. Skew Protection은 새 버전을 배포한 직후에도 이전 화면을 열어 둔 방문자가 자기 화면과 짝이 맞는 파일을 받게 하는 장치입니다. Vercel 공식 문서는 이 값을 쿼리 문자열이나 헤더로 실어 보내 요청을 같은 배포에 연결한다고 설명합니다.
이 기능을 켜 두면 배포할 때마다 값이 바뀌고, 검색엔진은 쿼리 문자열이 다른 주소를 서로 다른 URL로 봅니다. 파일 내용이 같아도 배포 식별자가 달라지면 새 주소가 생기므로, 본문 글을 늘리지 않아도 수집된 URL 수가 늘어납니다.
다른 환경에서도 파일 이름이나 주소 뒤에 버전 값을 붙이는 경우가 있고, 값이 바뀐 주소가 모두 새 본문 페이지는 아닙니다. 건수를 줄이려고 배포를 미루거나 Skew Protection을 끄기보다, 어떤 종류의 주소가 늘었는지부터 봅니다.
robots.txt로 정적 파일을 막으면 안 되는 이유
robots.txt는 크롤러에게 수집 범위를 알려 주는 파일입니다. 여기에 정적 파일 경로를 차단하도록 적어도 그 주소가 검색이나 보고서에서 확실히 사라지지는 않습니다.
구글 서치 센트럴 문서는 차단된 파일에 들어 있는 자바스크립트를 구글 검색이 렌더링하지 않는다고 밝힙니다. 파일을 막으면 구글은 그 파일 없이 화면을 그리고, 배치가 무너지거나 내용이 비어 있는 화면을 기준으로 사이트를 처리할 수 있습니다.
정적 파일을 열어 둘 때와 막을 때
| 결과 | ||
|---|---|---|
| 구글이 JS를 실행해 화면을 그림 | 제공 | 제공하지 않음 |
| 구글이 보는 화면이 방문자 화면과 같음 | 제공 | 제공하지 않음 |
| 보고서에서 주소가 확실히 빠짐 | 제공하지 않음 | 제공하지 않음 |
noindex는 검색에 색인하지 말라는 지시입니다. 파일은 원래 검색에 노출되지 않으므로 모든 파일에 이 지시를 붙이지 않습니다. 차단이나 noindex 같은 조치는 보고서 분류를 바꾸려고 쓰지 않고, 실제 접근 문제가 확인됐을 때 정합니다.
정상 기록과 진짜 문제를 구분하는 확인 순서
요약 화면만으로는 정상 기록과 실제 문제를 구분할 수 없습니다. Search Console에서 URL 목록을 내려받아야 판단할 수 있습니다.
미색인 URL 목록을 내려받아 분류하는 순서
1. 보고서 열기사이트를 고르고
페이지 색인 보고서
2. 항목 누르기크롤링됨, 색인 안 됨 행을
눌러 상세 목록으로
3. 내보내기CSV나 스프레드시트로
URL과 마지막 크롤링 날짜
4. 분류 열 추가파일, 본문, 목록,
옛 주소, 미확인
권한이 없다면 운영자에게 이 상태의 URL 목록과 조회 날짜를 받습니다. 2단계에서 상세 목록으로 들어가지 않고 내보내면 요약 건수만 담긴 파일이 나옵니다. CSV는 표를 텍스트로 저장한 파일이고, 4단계에서는 원본 열을 그대로 두고 분류 열만 더합니다. 내려받은 행 수가 보고서 건수보다 적다면 상세 화면이 보여 주는 URL 예시가 최대 1,000개라는 점을 감안합니다.
터미널에 익숙하다면 파일을 저장한 폴더에서 아래 명령으로 /_next/static/가 없는 줄만 화면에 띄울 수 있습니다. 원본 파일은 바뀌지 않습니다.
grep -v '/_next/static/' '테이블.csv'내려받은 파일 이름이 다르면 테이블.csv를 그 이름으로 바꿉니다. 파일을 찾을 수 없다는 오류가 나면 저장 폴더와 파일 이름부터 봅니다. 이 명령은 특정 경로만 빼 주는 보조 수단이라 모든 정적 파일을 걸러내지는 못합니다. /_next/static/은 Next.js의 경로이고, 실제 경로는 프로젝트 설정에 따라 다릅니다.
확장자만 보고 판단하면 놓치는 주소도 있습니다. /files/guide.pdf 같은 PDF는 파일이지만 검색에 내보낼 안내서일 수 있고, /insights/how-to-use-css처럼 주소에 css라는 글자가 든 본문 페이지도 있습니다. 이런 주소는 직접 열어 보고 분류합니다. 남은 주소는 아래 기준으로 나눕니다.
| 목록에 있는 주소 | 판단 | 해야 할 일 |
|---|---|---|
| JS 파일, CSS 파일, 폰트, 파비콘 | 보통 본문 색인 대상이 아님 | 지금 페이지가 쓰는 파일이 열리는지 본다 |
| sitemap.xml, rss.xml | 페이지 목록이나 새 글 정보를 담은 파일 | 파일이 열리고 의도한 주소가 들어 있는지 본다 |
| 이미 리디렉트를 걸어 둔 옛 주소 | 조치 전의 상태가 남았을 수 있음 | 지금 이동 응답과 도착 페이지, 마지막 크롤링 날짜를 본다 |
| 지금 살아 있는 본문 페이지 | 확인 대상 | 내용과 내부 링크를 점검한다 |
| 항목이 적은 목록 페이지나 태그 페이지 | 확인 대상 | 그 페이지만의 정보가 있는지 본다 |
지금 페이지가 쓰는 파일이 열리지 않는다면 개발 담당자에게 알립니다. 예전 배포에서만 쓰던 파일은 없어진 상태가 정상이므로 그대로 둡니다.
중요한 본문 하나는 Search Console 상단의 URL 검사 입력란에 전체 주소를 붙여 넣어 봅니다. 먼저 나오는 저장된 색인 상태와 마지막 크롤링 날짜를 적어 두고, "실제 URL 테스트"로 지금 접근할 수 있는지도 봅니다. 실제 URL 테스트의 성공은 지금 Google이 그 주소에 접근할 수 있다는 뜻이며, 색인 여부는 저장된 색인 상태에서 봅니다. 같은 주소로 테스트를 되풀이하기보다 찾은 문제와 고친 내용을 기록합니다.
마지막 크롤링 날짜를 함께 보는 이유는 이 보고서가 마지막으로 크롤링한 시점의 상태를 보여 주기 때문입니다. 앞의 목록에도 1월과 4월에 크롤링된 옛 주소가 남아 있었는데, 그 뒤에 리디렉트를 걸어 둔 주소였습니다. 날짜가 조치한 날보다 앞서면 그 기록은 조치 전의 상태입니다. 실제로 해결됐는지는 지금 그 URL을 열어 원하는 페이지로 이동하는지 보고, 필요하면 담당자에게 응답 상태를 받아 봅니다.
이 항목에서 실제 조치가 필요한 URL의 특징
정적 파일을 걸러낸 뒤 남는 주소는 세 종류입니다.
- 지금 살아 있는 본문 페이지: 진짜 확인 대상입니다. 접근할 수 있는지, 본문이 보이는지, 다른 페이지와 내용이 겹치지 않는지, 내부 링크가 있는지를 봅니다. 글자 수만 늘린다고 해결되지 않습니다.
- 이미 정리한 옛 주소: 리디렉트나 삭제를 마친 뒤 아직 다시 크롤링되지 않아 남은 기록입니다. 조치가 지금도 제대로 동작하는지 본 뒤 보고서가 갱신되기를 기다립니다.
- 항목이 적은 목록 페이지: 태그처럼 글을 모아 보여 주는 페이지는 항목 수만 보고 지우거나 noindex를 붙이지 않습니다. 사람들이 그 페이지에서 얻는 정보가 있는지 먼저 봅니다.
앞의 사례에서 남은 페이지 주소도 이 세 종류였습니다. 본문 글 한 편은 며칠 뒤 다시 크롤링되면서 색인됐고, 옛 주소들은 리디렉트를 걸기 전에 크롤링된 기록이었습니다. 결국 글이 다섯 편뿐인 태그 페이지 하나만 확인 대상으로 남았습니다.
155건에서 실제로 확인할 주소까지
항목 이름이 주는 인상과 달리 이 사이트에서 고칠지 판단할 주소는 한 건이었습니다. 건수가 많다고 놀라기 전에 목록을 내려받아 파일부터 걸러내면 실제로 할 일이 보입니다.
자주 묻는 질문
목록에서 정적 파일을 지우려고 robots.txt로 막아도 되나요?
막지 않는 편이 좋습니다. 구글 서치 센트럴 문서는 차단된 파일 안의 자바스크립트를 검색이 렌더링하지 않는다고 밝히고 있어서, 막으면 구글이 보는 화면이 실제 방문자의 화면과 달라집니다. 차단해도 보고서에서 주소가 확실히 빠지지 않으므로, 필요한 파일은 열어 두고 실제 문제를 찾습니다.
Next.js가 아닌 워드프레스에서도 이 건수가 늘어나나요?
버전 값이 다른 파일 주소가 수집되는 일은 다른 환경에서도 생깁니다. 값이 붙는 방식은 환경과 설정마다 다르지만, 목록을 내려받아 파일과 페이지를 나누는 순서는 워드프레스에서도 같습니다.
정적 파일을 걸러낸 뒤 남은 페이지 주소는 무엇을 확인하나요?
각 주소를 직접 열어 보고 마지막 크롤링 날짜와 함께 기록합니다. 옛 주소는 실제 이동 응답과 도착 페이지를 봅니다. 검색에 필요한 본문은 URL 검사에서 저장된 상태와 지금 접근 상태를 나눠 보고, 오류가 있으면 고칩니다. 접근이 정상이어도 색인 여부는 Google이 정합니다.
Sources

제대로 이해했는지 한 문제로 확인해 볼까요?
답을 고르면 바로 풀이가 나와요.
서치콘솔 '크롤링됨 - 현재 색인이 생성되지 않음' 항목에 JS 파일이 다수 잡혔을 때 올바른 대응은 무엇일까요?

새 글과 AI 소식을 메일로 받아 보세요
AI가 바꾸는 일과 도구, 측정 실무 이야기를 매주 한 번 보내 드려요.
이 글이 도움이 되었나요?
AI 검색에 인용되려면 먼저 크롤링과 색인이 되어야 합니다. 그 순서를 다룹니다
코스 전체 보기 →