색인 생성 안 될 때 점검 기준

색인 생성 안 될 때 점검 기준

웹페이지가 검색엔진에 보이지 않을 때 많은 운영자는 곧바로 검색 등록 실패를 의심합니다. 그러나 실제로는 크롤링, 색인, 대표 URL 선택, 품질 판단이 서로 다른 단계로 작동합니다. 따라서 색인 생성 문제를 해결하려면 단순히 “등록했는가”를 보는 것이 아니라, 검색엔진이 페이지에 접근할 수 있는지, 색인을 막는 신호가 있는지, 다른 URL을 대표본으로 선택했는지, 기술적으로 읽기 어려운 구조인지 순서대로 확인해야 합니다. (Google for Developers)

색인 생성의 의미

색인 생성은 검색엔진이 페이지를 발견한 뒤 내용을 이해하고, 제목·본문·이미지·메타데이터를 처리해 검색용 데이터베이스에 저장하는 단계입니다. 구글은 크롤링 이후에 페이지를 분석하면서 중복 여부와 canonical을 판단하고, 그 결과를 색인에 저장할 수 있다고 설명합니다. 중요한 점은 크롤링이 되었더라도 색인이 보장되지는 않는다는 사실입니다. 페이지 품질이 낮거나, robots 메타 규칙이 색인을 막거나, 사이트 설계가 검색엔진이 내용을 이해하기 어렵게 만들면 색인 생성이 이뤄지지 않을 수 있습니다. (Google for Developers)

검색 등록과 색인 생성은 같은 일이 아니다

사이트맵 제출이나 색인 요청은 검색엔진에 URL을 알리는 데 도움이 되지만, 그 자체가 검색 결과 포함을 보장하지는 않습니다. 구글은 사이트맵이 크롤링 효율을 높일 수 있다고 설명하면서도, 사이트맵에 들어 있는 모든 URL이 크롤링·색인된다는 보장은 없다고 명시합니다. 또한 수정된 페이지는 URL 검사 도구 등을 통해 재크롤링을 요청롤링을 요청할 수 있지만, 이 역시 실제 색인 여부와 시점을 강제로 결정하는 기능은 아닙니다. 색인 생성은 요청만으로 끝나는 절차가 아니라, 접근 가능성·중복 상태·품질 판단까지 통과해야 하는 과(Google for Developers)

robots.txt 차단 여부 확인

robots.txt는 크롤러가 어떤 URL에 접근할 수 있는지 알려 주는 파일입니다. 문제는 이 파일이 검색 제외 장치가 아니라 크롤링 제어 장치라는 점입니다. 중요한 본문 페이지나 필수 리소스가 실수로 차단되면 검색엔진이 페이지를 충분히 읽지 못할 수 있습니다. 더구나 구글은 robots.txt로 막힌 페이지도 외부 링크를 통해 URL 자체를 알 수 있으며, 이 경우 설명문 없는 형태로 검색 결과에 나타날 수 있다고 안내합니다. 따라서 색인 생성이 되지 않을 때는 먼저 해당 URL이나 상위 경로가 robots.txt에서 막혀 있지 않은지 확인해야(Google for Developers)

robots.txt는 차단 신호일 뿐 비공개 보호 수단이 아니다

robots.txt는 서버 과부하를 줄이거나 중요하지 않은 URL의 크롤링을 피하는 데 주로 쓰입니다. 구글은 비공개 페이지를 검색에서 숨기려면 noindex나 비밀번호 보호 같은 다른 방법을 사용하라고 설명합니다. 따라서 로그인 페이지, 테스트 폴더, 필터 조합 URL처럼 크롤링 효율을 낮추는 주소를 선별적으로 막는 것은 가능하지만, 검색 노출이 필요한 본문 페이지를 robots.txt로 막아 두고 색인 생성이 안 된다고 판단하는 방식은 잘못된 진(Google for Developers)

noindex 설정 확인

noindex는 검색엔진에 해당 페이지를 색인하지 말라고 지시하는 규칙입니다. HTML의 메타 태그나 HTTP 헤더의 X-Robots-Tag로 적용할 수 있으며, HTML이 아닌 파일에도 헤더 방식이 쓰일 수 있습니다. 색인 생성이 안 될 때는 의도치 않게 noindex가 들어간 것은 아닌지 먼저 확인해야 합니다. 특히 CMS의 검색 노출 차단 옵션, 템플릿 공통 head, 테스트용 배포 설정에서 noindex가 남는 일이 자주 발생합니다. 이런 경우 페이지는 정상 접속되더라도 검색 결과에는 포함되지 (Google for Developers)

noindex는 크롤링 가능해야 작동한다

구글은 noindex를 확인하려면 먼저 페이지를 크롤링할 수 있어야 한다고 설명합니다. 즉 robots.txt가 같은 URL을 막고 있으면 구글은 페이지 안의 noindex 태그를 읽지 못합니다. 또 noindex를 제거하거나 새로 추가한 뒤에는 Googlebot이 다시 방문해야 변경 사항이 반영됩니다. 수정 후에는 URL 검사 도구로 라이브 페이지를 테스트하고, 필요하면 재크롤링을 요청하는 방식이 더 정확합니다. 색인 생성 문제를 진단할 때 robots.txt와 noindex를 반드시 함께 봐야 하는 이유가 여기에 (Google for Developers)

canonical 설정 점검

canonical 문제는 색인 생성이 안 되는 것처럼 보이지만, 실제로는 다른 URL이 대표본으로 선택된 경우가 많습니다. 구글은 중복 또는 매우 유사한 페이지 묶음에서 canonical URL을 정하고, 그 대표 URL을 검색 결과에 사용할 수 있다고 설명합니다. rel="canonical"은 강한 신호이지만 절대 규칙은 아니며, 리다이렉트는 더 강한 신호이고 사이트맵 포함은 약한 신호에 가깝습니다. 따라서 주소 체계가 여러 개이거나 파라미터 URL, HTTP와 HTTPS, www와 비 www가 섞여 있으면 원하지 않는 URL이 대표본으로 선택될 수 (Google for Developers)

canonical 불일치는 오류가 아닐 수도 있다

Search Console의 페이지 색인 보고서는 ‘적절한 canonical이 지정된 대체 페이지’, ‘사용자가 선택한 canonical 없이 중복됨’, ‘사용자가 지정했지만 Google이 다른 canonical을 선택함’ 같은 상태를 보여 줍니다. 이 가운데 일부는 실제 오류라기보다 중복 URL 정리 결과일 수 있습니다. 구글도 중복 페이지는 검색 결과에 그대로 모두 노출하지 않으며, URL 검사 도구로 Google이 선택한 canonical을 확인하라고 안내합니다. 따라서 색인 생성이 안 된 URL이 반드시 문제라는 전제부터 버리고, 먼저 다른 URL이 대표로 색인되었는지를 확인해야(구글 도움말)

사이트맵 제출 상태 확인

사이트맵은 검색엔진이 사이트의 중요한 URL을 더 효율적으로 발견하도록 돕는 파일입니다. 특히 새 사이트, 내부 링크가 약한 사이트, 페이지 수가 많은 사이트에서는 사이트맵의 도움이 더 큽니다. 다만 사이트맵은 발견을 돕는 수단일 뿐이며, 포함된 모든 URL의 색인 생성을 보장하지 않습니다. 또한 canonical 관점에서는 사이트맵에 실어 둔 URL이 대표 URL 선호 신호로 작용할 수 있으므로, 중복 주소보다 우선 노출시키고 싶은 URL만 정리해 넣는 편이 적(Google for Developers)

제출만 끝내지 말고 보고서 상태를 봐야 한다

Search Console의 사이트맵 보고서는 제출 이력과 함께 파싱 오류, 읽기 실패 같은 문제를 보여 줍니다. 따라서 사이트맵 제출 후에는 성공 여부만 볼 것이 아니라, 파일이 실제로 읽혔는지와 오류가 없는지를 확인해야 합니다. 사이트맵이 잘못 작성되었거나 현재 속성과 다른 프로토콜·호스트 기준으로 제출되면 URL 발견 단계부터 혼선이 생길 수 있습니다. 색인 생성이 늦는 페이지가 많다면 사이트맵 파일 자체, 제출 대상 속성, 포함 URL 형식을 함께 검토하는 편이 안(구글 도움말)

기술 문제와 품질 문제 구분

색인 생성 실패는 항상 기술 설정 오류로만 발생하지 않습니다. 구글은 색인이 페이지의 콘텐츠와 메타데이터에도 의존하며, 콘텐츠 품질이 낮거나 사이트 설계가 내용을 이해하기 어렵게 만들면 색인되지 않을 수 있다고 설명합니다. 반대로 기술 문제는 좀 더 직접적입니다. Search Console의 페이지 색인 보고서에는 401 인증 요구, 403 차단, 기타 4xx, 5xx 서버 오류, 리다이렉트 오류 같은 상태가 별도 이유로 표시됩니다. 자바스크립트 의존 페이지라면 필수 콘텐츠가 렌더링되지 않아 검색엔진이 본문을 충분히 읽지 못하는 경우도 생길 수 (Google for Developers)

보고서 상태를 읽을 때 주의할 점

‘Crawled - currently not indexed’는 구글이 페이지를 읽었지만 아직 색인하지 않았다는 뜻이며, 이후에도 색인되지 않을 수 있습니다. 반면 ‘Discovered - currently not indexed’는 URL은 발견했지만 아직 크롤링하지 않았고, 보통 서버 부담 등을 예상해 크롤링을 뒤로 미룬 상태로 설명됩니다. 또 중복 관련 상태는 대표 URL 선택 결과일 수 있어 모두 수정 대상은 아닙니다. 따라서 기술 문제는 접근·응답·차단 신호에서 찾고, 품질 문제는 내용 차별성 부족·유사 문서 과다·대표 URL 경쟁 같은 관점에서 따로 봐야 정확한 판단이 가(구글 도움말)

수정 후 확인 절차

수정 뒤에는 즉시 검색 결과만 보지 말고 Search Console에서 현재 상태를 단계적으로 확인해야 합니다. 먼저 URL 검사 도구에서 해당 페이지의 색인 상태를 확인하고, 라이브 테스트로 현재 버전이 접근 가능한지 봅니다. 구글은 이 도구가 현재 색인 상태, 라이브 테스트, 요청 색인, 로드된 리소스와 렌더링 정보를 제공한다고 설명합니다. 다만 라이브 테스트는 중복·canonical 관련 모든 판단을 예측하지는 못하므로, 색인된 데이터와 라이브 데이터를 함께 봐야(구글 도움말)

재확인 순서는 단순할수록 좋다

실무에서는 순서를 고정해 두는 편이 효율적입니다. 먼저 200 응답 여부와 인증 차단 여부를 확인합니다. 그다음 robots.txt 차단, noindex 존재, canonical 지정, 사이트맵 포함 여부를 순서대로 봅니다. 이후 URL 검사 도구의 라이브 테스트로 현재 페이지를 확인하고, 수정이 실제로 반영되었다면 재크롤링을 요청합니다. 이때 구글은 변경된 페이지에 대해 재색인을 요청할 수 있다고 안내하지만, 크롤링과 색인 반영에는 시간이 걸릴 수 있습니다. 따라서 같은 URL을 반복 요청하기보다 원인 수정과 상태 확인을 먼저 끝내는 편이 더 정(구글 도움말)

맺음말

색인 생성이 안 될 때 가장 중요한 점은 원인을 한 가지로 단정하지 않는 것입니다. robots.txt, noindex, canonical, 사이트맵, 서버 응답, 자바스크립트 렌더링 같은 기술 요소를 먼저 점검해야 하지만, 그다음에는 중복 처리와 콘텐츠 품질 문제도 함께 봐야 합니다. Search Console의 페이지 색인 보고서와 URL 검사 도구를 기준으로 원인을 구분하면, 불필요한 재제출보다 실제 수정이 필요한 지점을 더 빠르게 찾을 수 있습니다. 색인 생성 문제는 등록 여부보다 신호의 일관성과 접근 가능성을 점검하는 방식으로 접근하는 편이 훨씬 안정(Google for Developers)