`Crawled - currently not indexed`는 Search Console 상태 중에서도 가장 애매한 편이다. Google이 페이지에는 도달했는데, 아직 색인에는 넣지 않았다는 뜻이기 때문이다. 진행과 실패가 동시에 있는 것처럼 느껴진다.

그래서 많은 팀이 첫 반응부터 잘못 잡는다. crawl error, sitemap error, robots 문제처럼 바로 fetch 실패로 읽는다. 하지만 실제로는 전혀 다른 종류의 상태일 수 있다.

이 글은 이 상태를 운영 기준으로 해석하는 방법을 다룬다. 목표는 라벨 하나에 과하게 반응하는 것이 아니라, 이 페이지가 실제로 index-worthy한지, indexable한지, 그리고 사이트 전체가 그 페이지를 충분히 밀고 있는지 차례대로 보는 것이다.

1. 사람들이 자주 틀리는 지점은 이 상태를 fetch 실패처럼 읽는 것이다

이 페이지는 이미 crawled 상태다. 이건 중요하다. Google이 URL에 도달했다면 첫 질문은 더 이상 “가져올 수 있었는가”가 아니라 “왜 아직도 색인으로 올리지 않았는가”가 된다.

이 차이가 점검 방향을 바로 바꾼다. transport 문제를 먼저 보는 대신, 신호, 지원, 페이지 가치 쪽으로 넘어가게 된다.

2. 가장 좋은 해석은 crawl 성공과 index 준비 상태를 분리해서 보는 것이다

여기가 핵심이다. crawl success는 이 페이지가 도달 가능했다는 뜻일 뿐, 색인에 들어갈 준비가 충분하다는 뜻은 아니다.

기술적으로는 열리는데 색인 관점에서는 약하게 보이는 페이지가 있다. 콘텐츠 가치가 얇거나, internal link 지원이 약하거나, canonical 신호가 혼합돼 있거나, indexability 규칙이 의도와 완전히 맞지 않는 경우다.

그래서 이 상태는 단일 버그처럼 보기보다 운영 checkpoint처럼 읽는 편이 맞다. Google은 페이지를 봤다. 이제 질문은 사이트 전체가 이 페이지를 색인 쪽으로 밀고 있는가로 바뀐다.

많은 팀이 여기서 하나의 명확한 기술 결함만 찾으려 한다. 하지만 더 흔한 현실은 soft failure다. 페이지는 crawlable하지만, 아직 충분히 강하지도 명확하지도, 사이트 안에서 잘 지지되지도 않은 상태다.

3. 먼저 볼 네 가지 기준

• internal links: 사이트가 이 페이지를 사용자와 크롤러 모두에게 실제로 밀고 있는가
• canonical signals: 어떤 버전을 색인해야 하는지 혼합 신호가 없는가
• indexability controls: noindex, robots, 다른 제어가 조용히 반대로 작동하고 있지 않은가
• content strength: 주변 페이지와 비교했을 때 충분히 다르고 유용한가

4. 예시 하나만 봐도 라벨이 왜 헷갈리는지 보인다

예를 들어 sitemap에는 들어 있고 브라우저에서도 정상적으로 열리는데, internal link가 거의 없고 사이트 안 다른 페이지와 내용이 매우 비슷한 페이지가 있다고 하자. 이런 경우 fetch는 완전히 성공했어도 Search Console에는 `Crawled - currently not indexed`가 뜰 수 있다.

이때 진짜 문제는 접근이 아니라 지원 부족과 차별성 부족이다.

5. 라벨 하나만으로 행동을 결정하면 안 된다

어떤 페이지는 지원을 더 받아야 하고, 어떤 페이지는 수정이 필요하고, 어떤 페이지는 그냥 시간이 더 필요하다. 점검의 목적은 이 셋 중 무엇인지를 판단하는 것이다.

페이지가 새롭고 신호가 깨끗하다면 기다리는 게 맞을 수 있다. 반대로 오래됐고, internal link가 약하고, canonical 신호가 섞여 있다면 직접 손보는 편이 맞다.

무엇부터 시작할까

영향받는 페이지 하나를 골라 internal links, canonical, indexability controls, content strength 순서로 점검해라. 네 가지가 모두 깨끗하면 기술 실패보다 timing issue로 먼저 보는 편이 맞다.