색인 65개·미색인 182개, 진짜 문제는 47개였다
2026-09-10 · 글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle)
Search Console에 미색인 182개가 보여도 182개가 모두 고장 난 페이지는 아닙니다. 사유를 나눠 보니 우리가 먼저 고칠 대상은 크롤링 후 제외 29개와 404 18개, 합계 47개였습니다.
미색인 총합부터 보면 판단이 틀어진다
2026년 8월 14일 트렌드 가챠 레이더의 페이지 색인 화면에는 색인됨 65, 색인되지 않음 182가 표시됐습니다. 처음 보면 사이트 대부분이 실패한 것처럼 보입니다.
하지만 미색인은 하나의 원인이 아닙니다. 대표 주소로 합쳐진 중복 URL, 다른 곳으로 정상 이동한 옛 주소, 아직 크롤링 순서를 기다리는 주소, Google이 내용을 본 뒤 제외한 페이지가 한 숫자에 섞입니다. 그래서 총합보다 사유별 URL을 먼저 봐야 합니다.
| Search Console 사유 | 건수 | 이번 판단 |
|---|---|---|
| 발견됨 - 현재 색인 생성되지 않음 | 56 | 크롤링 대기와 내부 연결 확인 |
| 리디렉션이 포함된 페이지 | 51 | 목적지가 맞으면 색인 대상에서 빠지는 것이 정상 |
| 크롤링됨 - 현재 색인 생성되지 않음 | 29 | 콘텐츠·중복·검색 가치 재검토 |
| 적절한 표준 태그가 포함된 대체 페이지 | 26 | 대표 URL로 통합됐다면 정상 |
| 찾을 수 없음(404) | 18 | 잘못된 링크인지 의도적 삭제인지 확인 |
182개 중 리디렉션 51과 대체 페이지 26은 원래 대표 URL 하나로 모으려는 주소가 대부분이었습니다. 발견됨 56은 서버 오류라기보다 아직 크롤링 우선순위를 받지 못한 상태였습니다. 당장 손댈 묶음은 Google이 이미 읽고도 제외한 29개와 404 18개였습니다.
크롤링됨 29개는 무엇을 봐야 하나
크롤링됨 - 현재 색인 생성되지 않음은 페이지를 가져오는 데 성공했지만 색인에는 넣지 않았다는 뜻입니다. 버튼을 반복해서 누르기보다 페이지가 기존 글과 얼마나 다른지, 검색자가 얻을 답이 충분한지, 대표 URL이 일관적인지 봐야 합니다.
우리는 연구소 글 47편의 목표 키워드가 모두 레드오션이라는 사실도 같은 날 확인했습니다. 기술적으로 읽을 수 있어도 이미 비슷한 답이 많고 새 정보가 적다면 우선순위가 낮을 수 있습니다. 직접 계산 결과, 실제 실패 수치, 비교 전후처럼 우리만 줄 수 있는 내용을 보강하는 편이 날짜만 바꾸는 것보다 낫습니다.
관련 글에서 문맥에 맞는 링크를 걸어 고립 페이지를 없애고, 사이트맵에는 색인시키고 싶은 대표 URL만 넣습니다. 사이트맵 lastmod도 실제로 내용이 크게 바뀐 날짜만 적어야 합니다.
404 18개는 하나씩 열어 봤다
404 목록에는 서로 다른 세 종류가 섞여 있었습니다.
- 옛 슬러그와
.html주소: 실제 새 글이 있으므로 새 주소로 301 이동시켰습니다. - 잘못 만들어진 카테고리 경로: 카드의 상대 링크가
/blog/category/<글슬러그>로 풀린 오류였습니다. 링크를 고치고 이미 발견된 옛 주소는 새 글로 연결했습니다. - 의도적으로 삭제한
/story/: 대체 콘텐츠가 없으므로 404를 유지했습니다. 홈으로 보내면 사용자는 기대한 내용을 못 찾고, 검색엔진에는 소프트 404가 될 수 있습니다.
404를 전부 없애는 것이 목표가 아닙니다. 이동한 글은 301, 실제로 없어진 글은 404, 일시 장애는 5xx처럼 상태를 의미에 맞게 주는 것이 목표입니다.
51개 리디렉션과 26개 대체 페이지는 왜 생겼나
내부 링크에 .html 주소와 확장자 없는 주소가 섞였고, www와 루트 도메인이 동시에 200으로 열렸습니다. canonical은 루트 도메인을 가리켰지만 Google은 두 호스트를 각각 크롤링했고 일부 계산기는 www 주소로 색인했습니다.
내부 링크·canonical·사이트맵을 확장자 없는 루트 도메인 주소로 통일했습니다. www는 Cloudflare에서 루트 도메인으로 301 이동시켰습니다. 이 뒤에도 Search Console의 과거 숫자는 바로 사라지지 않습니다. Google이 다시 방문해 새 상태를 처리할 시간이 필요합니다.
우리가 실제로 한 점검 순서
- 사유별 보고서에서 URL 예시를 내보냈습니다.
- 브라우저 표시만 보지 않고 응답 상태와 최종 도착 주소를 확인했습니다.
- 공개 글은 200, 이동한 옛 글은 301, 없어진 글은 404인지 나눴습니다.
- canonical·내부 링크·사이트맵이 같은 주소를 가리키게 맞췄습니다.
- 소수의 중요 URL만 URL 검사에서 먼저 볼 4가지 순서로 검사했습니다.
자주 묻는 질문
미색인 182개면 182개 모두 색인 요청해야 하나요?
아닙니다. 리디렉션과 대체 페이지는 대표 URL로 통합되는 과정일 수 있습니다. 먼저 사유와 대표 URL을 확인하고, 공개할 가치가 있는 중요 페이지만 검사하세요.
404는 모두 홈페이지로 보내면 되나요?
안 됩니다. 같은 내용의 새 주소가 있을 때만 그 주소로 301 이동시키세요. 대체할 콘텐츠가 없으면 404를 유지하는 것이 정확합니다.
수정한 뒤 유효성 검사를 바로 눌러야 하나요?
예시 URL이 실제로 고쳐졌는지 먼저 확인하세요. 의도적 404가 같은 묶음에 남아 있으면 일괄 검증이 다시 실패할 수 있습니다. 중요한 주소는 URL 검사로 현재 상태를 확인하고 재크롤링을 기다립니다.
참고 자료
- Google Search Console, URL 검사 도구
- Google 검색 센터, 중복 URL 통합
- Google 검색 센터, HTTP 상태 코드와 네트워크 오류
글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle) · 글감 찾다 지쳐서 직접 도구를 만든 콘텐츠 운영자. 소개 보기