구글 서치콘솔 색인 문제 해결: 크롤링됨-색인 미생성, 404, 리디렉션 오류
구글 서치콘솔을 열어 보면 “페이지 색인 생성” 보고서에 색인되지 않은 페이지가 수십, 수백 개씩 쌓여 있는 경우가 많다. 사유도 “크롤링됨 – 현재 색인이 생성되지 않음”, “찾을 수 없음(404)”, “리디렉션 오류”처럼 낯선 말들이다. 이 글은 서치콘솔 색인 보고서의 주요 사유가 무엇을 뜻하는지, 그리고 각각 어떻게 대처하면 되는지를 이 블로그를 정리하며 겪은 사례와 함께 정리한다. 404가 쌓였던 구체적인 원인은 한글 URL 리디렉션 404 문제 글에 따로 적어 두었다.

서치콘솔 색인 보고서 보는 법
서치콘솔 왼쪽 메뉴의 색인 생성 > 페이지로 들어가면 “색인이 생성됨”과 “색인이 생성되지 않음” 페이지 수가 그래프로 나온다. 아래쪽 “페이지의 색인이 생성되지 않은 이유” 표에는 사유별 페이지 수가 정리되어 있고, 사유를 누르면 해당 주소 목록을 볼 수 있다.

여기서 중요한 점은 “색인되지 않음”이 모두 문제는 아니라는 것이다. 옛 주소가 새 주소로 잘 리디렉션되고 있거나, 일부러 검색에서 뺀 페이지라면 색인되지 않는 것이 정상이다. 사유별로 나눠서 봐야 한다.
서치콘솔 색인 미생성 사유별 대처법
| 사유 | 뜻 | 할 일 |
|---|---|---|
| 크롤링됨 – 현재 색인이 생성되지 않음 | 구글이 읽어 갔지만 현재 색인되지 않은 상태 | 내용 보강, 중복 정리, 내부 링크 |
| 발견됨 – 현재 색인이 생성되지 않음 | 주소는 알지만 아직 읽어 가지 않음 | 사이트맵, 내부 링크, 서버 속도 점검 |
| 찾을 수 없음(404) | 주소에 페이지가 없음 | 옮긴 글이면 301 리디렉션, 지운 글이면 그대로 둠 |
| 리디렉션 오류 | 리디렉션이 너무 길거나 반복되거나 깨짐 | 한 번에 최종 주소로 가도록 수정 |
| 리디렉션이 포함된 페이지 | 옛 주소가 새 주소로 리디렉션됨 | 정상, 조치 불필요 |
| 대체 페이지(적절한 표준 태그 포함) | 다른 주소가 대표 페이지로 지정됨 | 정상, 조치 불필요 |
| noindex 태그에 의해 제외됨 | 검색 제외 설정이 되어 있음 | 의도한 것인지 확인 |
크롤링됨 – 현재 색인이 생성되지 않음
가장 흔하면서 가장 답답한 사유다. 구글이 페이지를 읽어 갔지만 현재 색인되지 않았다는 뜻이다. 이 상태 이름만으로 콘텐츠의 가치가 낮다거나 AI로 작성해서 제외됐다고 단정할 수는 없다. 향후 색인될 수도 있고 그렇지 않을 수도 있다. 내용의 중복·완성도, 표준 URL, 실제 응답과 렌더링을 각각 점검하자.
이 블로그도 티스토리 시절의 짧은 글과 이전하면서 본문이 사라진 글이 많았다. 그래서 오래된 글을 하나씩 다시 읽고, 내용이 부족한 글은 보강하고, 사라진 부분은 그 사실을 밝힌 뒤 다시 정리했다. 관련 글끼리 내부 링크도 연결했다. 이 과정은 AIOSEO 점수 90점 넘기는 법에 정리해 두었다. 색인은 결국 구글이 판단하는 것이라 결과가 바로 보이지는 않지만, 콘텐츠 보강과 함께 실제 수집 기록, 내부 링크, 표준 URL과 서버 상태도 확인해야 한다.
발견됨 – 현재 색인이 생성되지 않음
구글이 주소는 알고 있지만 아직 읽으러 오지 않은 상태다. 새 사이트나 글이 많은 사이트에서 흔하다. 사이트맵을 제출하고, 다른 글에서 링크를 걸어 주고, 서버 응답이 느리지 않은지 확인하면 된다.
찾을 수 없음(404)
주소에 페이지가 없다는 뜻이다. 일부러 지운 글이라면 그대로 둬도 괜찮다. 구글이 시간이 지나면 목록에서 뺀다. 하지만 주소만 바꾼 글이라면 옛 주소에서 새 주소로 301 리디렉션을 걸어야 한다. 이 블로그는 리디렉션 규칙이 있는데도 404가 나는 문제가 있었는데, 한글 주소의 퍼센트 인코딩 대소문자 차이 때문이었다. 자세한 내용은 한글 URL 리디렉션 404 원인에 있다.
리디렉션 오류
리디렉션이 여러 번 이어지는 체인, 서로를 가리키는 루프, 최종 목적지가 404인 경우가 여기에 들어간다. “숫자 주소 → 한글 주소 → 영문 주소”처럼 여러 번 거치는 규칙은 모두 최종 주소로 한 번에 가도록 고치는 것이 좋다.
실제 상태를 직접 확인하기
서치콘솔 보고서는 구글이 마지막으로 크롤링한 시점의 결과라 지금 상태와 다를 수 있다. 고친 뒤에는 터미널에서 직접 요청해 상태 코드와 리디렉션 목적지를 확인하자. 옵션 설명은 curl 사용법에 있다.
# 상태 코드와 리디렉션 목적지 확인
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" "https://example.com/old-url/"
# 구글봇과 같은 사용자 에이전트로 요청
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
"https://example.com/old-url/"301이 한 번만 나오고 그 목적지가 200이면 정상이다. 404나 여러 번의 301이 나온다면 리디렉션 규칙을 다시 봐야 한다.
서치콘솔 색인 요청과 수정 결과 확인
- URL 검사: 위쪽 검색창에 주소를 넣으면 구글이 알고 있는 상태가 나온다. “실제 URL 테스트”로 지금 상태를 다시 확인할 수 있다.
- 색인 생성 요청: 내용을 크게 고친 중요한 글은 URL 검사 화면에서 색인 생성을 요청한다. 하루에 요청할 수 있는 수가 제한되어 있으니 모든 글에 누르기보다 핵심 글 위주로 쓰자.
- 수정 결과 확인: 사유를 누른 상세 화면에서 이 버튼을 누르면 구글이 해당 주소들을 다시 검사한다. 결과가 나오기까지 몇 주가 걸릴 수 있으니 기다리는 수밖에 없다.
기능 설명은 서치콘솔 페이지 색인 생성 보고서 도움말과 URL 검사 도구 도움말에 자세히 나와 있다.
사이트맵 제출
워드프레스에서 AIOSEO를 쓰면 /sitemap.xml 주소로 사이트맵이 자동으로 만들어진다. 서치콘솔의 색인 생성 > Sitemaps에서 이 주소를 한 번 제출해 두면, 새 글과 수정한 글을 구글이 더 빨리 알아챈다. 사이트맵 개념은 구글 사이트맵 안내를 참고하자.
서치콘솔 색인 문제 예방 체크리스트
- 글 주소(슬러그)는 처음 정한 뒤 되도록 바꾸지 않는다.
- 주소를 바꿀 때는 옛 주소에서 301 리디렉션을 걸고, 실제로 요청해 확인한다.
- 리디렉션은 한 번에 최종 주소로 가게 만든다.
- 너무 짧거나 비슷한 글은 합치거나 보강한다.
- 관련 글끼리 내부 링크를 건다.
- 사이트맵을 제출하고, 큰 변경 뒤에는 수정 결과 확인을 눌러 둔다.
마무리
서치콘솔 보고서의 숫자는 고친 직후에 바로 바뀌지 않는다. 구글이 다시 크롤링해야 반영되기 때문이다. 조급하게 색인 요청을 반복하기보다, 사유별로 나눠 할 일을 끝낸 뒤 몇 주 지켜보는 것이 현실적이다. 콘텐츠의 완성도는 중요하지만, 이 보고서만으로 Google의 모든 선택 사유를 알 수 있는 것은 아니다. 이 블로그가 티스토리에서 워드프레스로 옮기며 겪은 일은 16년 운영한 티스토리에서 워드프레스로 옮긴 이유에 있다.
첫 댓글을 남겨보세요