발견되었으나 현재 인덱스 미등록: 원인 및 확인 사항

Google이 보는 방식으로 단일 URL 확인하기

단일 주소부터 시작하세요. 원인 테이블은 현재 보고 있는 페이지를 설명하는 행을 알 때만 유용합니다.

커버리지 상태부터 시작하세요

Search Console에서 페이지의 검사 보고서를 열고 다른 작업 전에 상태 줄을 읽으세요. 발견됨과 크롤링됨은 다른 판단이며, 각각 다른 해결책을 가리킵니다.

Google이 크롤링하지 않은 페이지를 위해 일주일 동안 링크 작업을 하지 마세요. 상태 줄이 달라질 때까지 그 노력은 다른 곳에 써야 합니다.

날짜와 함께 검사 결과를 저장하세요. 커버리지 상태는 Google이 다시 크롤링함에 따라 변하므로, 지난주의 기록은 당시의 상황을, 최신 검사는 현재 상황을 알려줍니다.

원시 HTML과 렌더링된 페이지 비교하기

cURL로 URL을 가져와서 응답에 본문 텍스트가 있는지 확인하세요. 단어가 스크립트 실행 후에만 나타나면 문제는 링크 그래프가 아닌 렌더링입니다.

원시 응답에서 제목이 없거나 본문이 빈약한 것은 빠른 신호이며, 사람들이 가장 자주 간과하는 부분입니다.

목록을 순서대로 확인하세요. 첫 번째 항목의 실패가 나머지 문제를 설명하는 경우가 많으므로, 수정할 때까지 다른 항목을 확인할 필요가 없습니다.

• 응답에 주요 제목이 있음
• 본문 텍스트가 몇 문장보다 김
• 일반적인 앵커로 내부 링크가 있음
• 올바른 주소를 가리키는 canonical 태그

사이트맵과 robots 파일이 일치하는지 확인

URL을 나열하는 사이트맵이 robots.txt에서 차단하면 혼합 신호를 보냅니다. 다른 호스트에서 제공되는 사본이 다른 내용을 말할 수 있으므로, canonical 호스트에서 두 파일을 모두 확인하세요.

이러한 불일치는 전체 사이트를 망가뜨리지는 않지만, 다른 모든 확인을 더 어렵게 만듭니다.

sitemap에 lastmod 값이 있는 경우 해당 값도 확인하세요. 변하지 않거나 빌드 날짜와 일치하는 날짜는 Google에게 새로운 것이 무엇인지 거의 알려주지 않습니다.

백링크의 역할

다른 사이트의 링크는 발견 경로입니다. Google이 이를 따라가면 페이지가 발견 대기열에서 더 빨리 제거될 수 있습니다.

링크가 인덱싱 스위치가 되는 것은 아닙니다. 내부 링크가 없고 외부 백링크가 하나만 있는 페이지는 여전히 인덱싱 후보로 약하며, Google은 발견한 모든 것을 인덱싱하지 않는다고 명시적으로 말했습니다.

toppages를 사용하여 어떤 URL이 링크를 유도하는지 확인한 후, 해당 URL이 인덱싱되었는지 확인하세요. 링크되었으나 인덱스에 누락된 것은 하루 작업 가치가 있는 신호입니다.

확신이 서지 않을 때는 막힌 URL로 링크된 페이지를 확인하세요. 그중 당신의 페이지가 없다면, 문제는 외부 링크보다는 내부 구조일 가능성이 높습니다.

아무도 읽지 않는 페이지에서의 링크

크롤링되지 않는 페이지에서의 링크는 Google이 따라갈 것이 거의 없습니다. 발견 경로로 세우기 전에 링크된 페이지 자체가 인덱싱되어 있는지 확인하세요.

오래된 페이지에서의 죽은 링크는 주소가 목록에 남아 있게 할 수 있지만, 단독으로 판단을 바꾸기는 어렵습니다.

내부 링크가 주요 역할을 함

사이트 자체 페이지의 대부분 발견은 사이트 내부에서 일어납니다. 메뉴, 카테고리 목록 및 사이트맵은 외부 링크 하나보다 새로운 페이지에 더 많은 도움을 줍니다.

페이지에 내부 경로가 없다면 외부 링크는 구조적 공백을 덮는 패치일 뿐이며, 공백이 수정해야 할 부분입니다.

링크 깊이와 품질 구분하기

발견되었으나 크롤링되지 않은 페이지는 보통 우선순위 문제입니다. Google은 주소를 알고 있지만 서두를 이유가 거의 없습니다. 이는 내부 경로가 적기 때문입니다.

크롤링되었으나 인덱스 미등록인 페이지는 판단의 결과입니다. Google이 읽었으나 원하지 않았으므로, 링크를 더 많이 추가한다고 해서 빈약하거나 중복된 텍스트가 해결되지 않습니다.

프레임워크는 세 번째 원인을 추가합니다. Next.js 및 React 사이트는 때때로 JavaScript 실행 후에만 텍스트가 나타납니다. cURL로 원시 HTML을 가져와서 텍스트가 포함되어 있는지 확인하세요. 없다면 서버 사이드 렌더링 또는 프리렌더링이 해결책이며, 스택 변경 시 URL 안정성을 유지하는 레시피가 적용됩니다.

Bing과 Yandex는 자체 대기열을 가지고 있으므로, 문제가 당신만의 것이라고 가정하기 전에 Bing Webmaster Tools를 확인하세요.

유용한 테스트는 같은 페이지를 두 가지 관점에서 보는 것입니다. 내부 링크 수가 적고 텍스트가 빈약하다면 원인이 둘 다일 수 있으며, 기다리기 전에 둘 다 수정해야 합니다.

제외된 URL의 급증이 매개변수 또는 사이트맵 문제일 때

제외된 URL의 갑작스러운 증가는 보통 기계적 원인입니다. 작업은 각 주소를 쫓는 것이 아니라 생성자를 찾는 것입니다.

매개변수 및 계층형 경로

갑작스러운 증가는 종종 새로운 주소를 생성하기 시작한 필터 또는 정렬 매개변수로 거슬러 올라갑니다. 보고서에서 dozen을 샘플링하고 쿼리 문자열을 읽으세요.

변형이 동일한 콘텐츠를 표시한다면 문제는 중복입니다. 해결책은 더 많은 링크가 아닌 canonical 또는 매개변수 규칙입니다.

존재해야 하는 페이지를 주의 깊게 관찰하세요. 사람들이 실제로 그 조합을 검색한다면 필터가 자체 주소를 가질 수 있습니다. 규칙은 모든 매개변수를 차단하는 것이 아니라, 어떤 조합이 주소를 얻을 가치가 있는지 결정하는 것입니다.

잘못된 호스트를 나열하는 사이트맵

사이트의 http 버전이나 이제 리디렉션되는 호스트를 위해 구축된 사이트맵은 Google이 신뢰하지 않을 목록을 제공합니다. 파일을 열고 첫 열 개의 주소를 canonical 호스트와 비교하세요.

목록을 먼저 수정하세요. 깔끔한 사이트맵은 게시하는 데 비용이 들지 않으며, 조사에서 하나의 변수를 제거합니다.

호스팅 및 봇 차단 함정

Hostinger, Cloudflare 및 유사한 레이어는 때때로 인간에게는 완벽하게 서비스를 제공하면서 Googlebot에 속도 제한을 적용합니다. 사이트는 당신에게는 잘 보이지만 크롤러에게는 불안정해 보입니다.

Googlebot을 포함하는 사용자 에이전트에 대한 403, 429 및 5xx 응답에 대한 원시 액세스 로그를 읽으세요. 많은 스크레이퍼가 이름을 속이기 때문에 역방향 DNS로 해당 접속을 확인하세요.

AI 크롤러는 별도의 결정 사항입니다. robots.txt에서 GPTBot 또는 ClaudeBot을 차단하면 Googlebot에는 영향을 미치지 않지만, 부주의한 와일드카드 규칙은 영향을 미칠 수 있습니다. 각 편집 후 파일을 테스트하세요.

스테이징 사본은 주의가 필요합니다. 하나가 문제라면 비밀번호 뒤에 두고 Search Console에서 제거를 요청하세요. noindex 태그만으로는 한 번의 배포로 무효화될 수 있습니다. 호스트를 통합하기 전에 리디렉션 레시피를 참조하세요.

속도 제한은 종종 바쁜 시간에만 나타납니다. 자정에 실행된 확인은 깨끗해 보일 수 있지만 오후 로그는 다른 이야기를 할 수 있으므로, 결정하기 전에 여러 시간대를 샘플링하세요.

변경한 모든 방화벽 규칙을 기록하세요. 하나의 스크레이퍼를 차단하기 위해 추가된 규칙이 크롤러도 차단할 수 있으며, 그 증상은 나중에 커버리지의 조용한 감소로만 나타날 수 있습니다.