Search Console 색인 제외 리포트, 다 고쳐야 하는 건 아니다

색인 리포트를 열었더니 온통 "실패함"

블로그 SEO 상태를 점검하려고 Google Search Console의 "페이지 색인이 생성되지 않는 이유" 리포트를 열었다. 그런데 화면이 심상치 않았다.

사용자가 선택한 표준이 없는 중복 페이지 — 6건, 실패함
리디렉션이 포함된 페이지 — 2건, 실패함
크롤링됨, 현재 색인이 생성되지 않음 — 8건, 실패함
찾을 수 없음(404) — 4건
리디렉션 오류 — 1건
...

"실패함"이라는 빨간 표시가 줄줄이 떠 있으니 뭔가 큰일 난 것 같았다. 그런데 하나씩 뜯어보니 대부분은 정상이었고, 실제로 코드를 고칠 일은 하나도 없었다. 이 글은 그 진단 과정의 기록이다. 같은 리포트를 보고 겁먹는 분들에게, "빨간불 ≠ 버그"라는 걸 보여주고 싶다.

전제: 내 블로그 구조

진단 기준이 되는 내 블로그(backtodev) 구조부터. 이 구조에 따라 "정상"의 기준이 달라진다.

Next.js + next-intl 다국어 — 모든 페이지가 /ko/..., /en/... 쌍으로 존재
접두사 없는 URL(/posts/foo)로 들어오면 브라우저 언어에 따라 자동 리디렉션
영어 번역이 없는 글은 한국어로 fallback (이 경우 noindex 처리)
운영 초기에 테스트 포스트 몇 개를 만들었다 삭제한 이력 있음

항목별 진단 — 고칠 것 vs 놔둘 것

7가지 항목을 하나씩 판정한 결과다.

항목	건수	판정	이유
리디렉션이 포함된 페이지	2	✅ 정상	의도된 locale 자동 리디렉션
중복 페이지, Google이 다른 표준 선택	1	✅ 정상	fallback 페이지를 구글이 ko로 묶음
찾을 수 없음(404)	4	✅ 정상	삭제한 테스트 포스트
발견됨 - 색인 안 됨	0	✅ 무시	0건
크롤링됨 - 색인 안 됨	8	⏳ 대기	신생 블로그, 시간이 해결
사용자가 선택한 표준이 없는 중복 페이지	6	🔍 조사	↓ 아래 반전 참고
리디렉션 오류	1	🔍 조사	1건이라 후순위

✅ "리디렉션이 포함된 페이지" — 구조상 당연하다

/posts/foo 같은 접두사 없는 URL은 미들웨어가 /ko/posts/foo로 리디렉션한다. 구글 입장에서 이 URL은 "내용이 없고 다른 곳으로 보내는 페이지"이므로 색인하지 않는 게 맞다. 실제 콘텐츠는 /ko/..., /en/...에서 색인되면 된다. 여기 뜨는 건 문제가 아니라 설계 의도대로 동작한다는 증거다.

✅ "찾을 수 없음(404)" — 어떤 URL인지부터 보라

404는 겁먹기 전에 해당 행을 클릭해서 URL 목록을 확인하는 게 먼저다. 내 경우 4건 전부 블로그 세팅 초기에 만들었다 지운 hello-world 같은 테스트 포스트였다. 삭제한 페이지가 404를 반환하는 건 올바른 동작이고, 구글이 몇 번 재확인한 뒤 목록에서 알아서 사라진다.

만약 살아 있어야 할 페이지가 여기 떠 있다면 그때가 진짜 문제다. 판정 기준은 단순하다: "이 URL이 지금도 있어야 하는 페이지인가?"

⏳ "크롤링됨 - 현재 색인이 생성되지 않음" — 기다림의 영역

구글이 페이지를 읽고 갔지만 아직 색인에 넣지 않았다는 뜻이다. 신생 사이트에서 아주 흔하다. 사이트 신뢰도가 쌓이면 서서히 색인된다. 특히 나처럼 단기간에 포스트를 몰아서 발행하면(예약 발행으로 매일 1편) 구글이 소화하는 데 시간이 걸린다. 조치할 것 없음. 콘텐츠를 꾸준히 쌓는 게 유일한 답이다.

반전: "중복 페이지 6건"의 범인을 찾다가

문제는 "사용자가 선택한 표준이 없는 중복 페이지" 6건이었다. 다국어 사이트에서 이 항목은 보통 이렇게 해석된다.

ko/en 페이지가 서로 번역 관계라는 표시(hreflang)가 없어서, 구글이 둘을 "비슷한 중복 문서"로 보고 있다.

"아, hreflang을 빼먹었구나!" 싶어서 바로 코드를 고치려고 했다. 그런데 습관적으로 고치기 전에 현재 코드부터 확인했는데... 반전이 있었다.

// app/[locale]/posts/[slug]/page.tsx — 이미 다 있었다
alternates: {
  canonical: canonicalUrl,          // ✅ canonical
  languages: {                      // ✅ hreflang
    ko: `${BASE_URL}/ko/posts/${slug}`,
    en: `${BASE_URL}/en/posts/${slug}`,
    "x-default": `${BASE_URL}/ko/posts/${slug}`,
  },
},
// fallback 페이지엔 noindex 까지     // ✅
...(post.isFallback && { robots: { index: false, follow: false } }),

canonical, hreflang, noindex — 전부 이미 구현돼 있었다. 한 달 전 SEO 수정 작업 때 넣어둔 것이었다. 그럼 왜 리포트에 6건이 떠 있을까?

답은 크롤링 시점이다. Search Console의 리포트는 실시간이 아니다. 그 6건은 수정 배포 이전에 크롤링된 기록이 남아 있는 것이었다. "실패함"이라는 표시도 예전 유효성 검사가 실패했다는 이력일 뿐, 지금 코드가 틀렸다는 뜻이 아니다.

그래서 한 일: 코드 수정 0줄, 버튼 클릭 1번

결론적으로 내가 할 일은 코드가 아니라 Search Console에서 "유효성 검사 다시 시작" 버튼을 누르는 것뿐이었다. 구글이 다시 크롤링하면서 최신 코드(hreflang·canonical 적용본)를 보면 해소된다. 1~2주 뒤에도 그대로면 그때 다시 파면 된다.

이 경험에서 얻은 진단 순서

색인 리포트를 볼 때 이 순서로 접근하면 헛수고를 줄일 수 있다.

항목별로 "내 사이트 구조상 정상인가"부터 판정 — 리디렉션·locale 구조를 아는 건 나뿐이다. 구글은 그냥 사실을 나열할 뿐
URL 목록을 직접 확인 — 404든 중복이든, 행을 클릭해 실제 URL을 봐야 판단이 선다
고치기 전에 현재 코드 확인 — 리포트는 과거 크롤링 기준이다. 이미 고쳐진 문제일 수 있다
수정했다면(또는 이미 수정돼 있었다면) "유효성 검사 다시 시작" — 이걸 안 누르면 "실패함"이 계속 남아 있다
"크롤링됨 - 색인 안 됨"은 인내 — 신생 사이트의 통과의례

정리

Search Console의 빨간 "실패함"은 버그 목록이 아니라 관찰 기록이다
다국어 사이트라면 리디렉션 페이지·fallback 중복은 구조상 정상으로 뜬다
404는 URL을 확인해서 "죽어야 할 페이지"면 정상
리포트는 과거 크롤링 시점 기준 — 고치기 전에 지금 코드부터 볼 것
이미 해결된 항목은 **"유효성 검사 다시 시작"**을 눌러야 사라진다

이번에 가장 크게 배운 건 SEO 지식이 아니라 진단 태도였다. 리포트의 빨간불을 보고 바로 코드를 고쳤다면, 멀쩡한 hreflang 설정을 이중으로 만지며 오히려 꼬았을 거다. "고치기 전에, 지금 상태부터 확인한다" — 디버깅의 기본이 SEO에서도 그대로 통했다.