Crawlability vs Indexability, 상품 페이지가 빠지는 원인은 어디에 있을까요?

세 줄 요약

• Crawlability는 검색봇이 페이지에 도착해 읽을 수 있는지, Indexability는 읽은 페이지가 색인 후보가 될 수 있는지를 뜻합니다.

• 서버·방화벽·렌더링은 Crawlability, noindex·canonical·중복 신호는 Indexability 쪽에서 먼저 확인합니다.

• 기존 사이트에서 정상 URL과 누락 URL을 같은 템플릿끼리 비교하면 개별 제출을 반복하지 않고 원인을 찾을 수 있습니다.

먼저 무엇이 다른지 볼까요?

새로 만든 상품이나 지역 페이지가 한두 개가 아니라 수백 개씩 검색에서 빠졌다면 URL을 하나씩 제출해도 해결되지 않습니다. 공통 템플릿이 검색봇에게 막혔는지, 페이지는 열리지만 noindex나 canonical 때문에 색인 후보에서 빠지는지부터 갈라야 합니다. 크롤러빌리티와 인덱서빌리티는 이런 반복 오류를 사이트 설정 수준에서 설명할 때 쓰는 말입니다.

Crawlability와 Indexability를 이름만으로 고르지 않습니다. 실제 업무 한 건에서 noindex와 canonical를 나란히 적어 보면 어느 단계에 먼저 손대야 하는지 드러납니다. 담당자와 재검사 날짜까지 같은 기록에 남겨야 다음 수정이 추측으로 흐르지 않습니다.

한 번 잘 나온 화면은 Crawlability나 Indexability의 성과 증거가 되기 어렵습니다. canonical와 템플릿 오류, 확인 날짜를 보존한 뒤 같은 조건에서 재현되는지를 봐야 실제 개선으로 판단할 수 있습니다.

크롤링과 렌더링을 함께 보면

• Crawling vs Indexing

• SSR vs CSR

• Canonical vs 301

크롤링과 인덱싱은 검색 시스템이 한 URL을 발견하고 저장하는 처리 단계입니다. 크롤러빌리티와 인덱서빌리티는 사이트가 그 처리를 받을 조건을 갖췄는지 설명하는 속성에 가깝습니다. 같은 템플릿의 여러 URL에서 문제가 반복될 때 이 구분이 개발 범위를 정하는 데 도움이 됩니다.

크롤러빌리티에는 URL 발견, 서버 응답, 로그인 요구, robots.txt, 내부 링크와 렌더링 자원 같은 접근 조건이 들어갑니다. 인덱서빌리티 쪽에는 noindex, canonical, 중복 또는 빈 콘텐츠, HTTP 헤더의 색인 지시가 놓입니다. 어느 쪽도 Google이 제공하는 공인 점수나 합격 판정은 아닙니다.

언제 Crawlability를 먼저 볼까요?

같은 상품 템플릿이 5xx를 내거나 특정 경로 전체가 robots.txt에 막혀 있다면 개별 본문을 고쳐도 상황은 달라지지 않습니다. 자바스크립트 페이지는 초기 HTML뿐 아니라 렌더링 뒤에 핵심 텍스트와 링크가 남는지도 검사합니다. 일반 사용자와 검색봇에게 서로 다른 응답을 내는 CDN·방화벽 규칙도 경로 전체를 막을 수 있습니다.

robots.txt를 모두 여는 것이 목표는 아닙니다. 장바구니 매개변수나 내부 검색 결과처럼 검색에 필요 없는 대량 URL은 의도적으로 수집 범위를 제한할 수 있습니다. 공개 콘텐츠로 운영할 경로를 정한 다음, 신규·기존·종료 상태의 표본 URL이 같은 방식으로 열리는지를 대조합니다.

판단하기 전 확인할 항목

접근 가능한 템플릿도 렌더된 HTML에 noindex가 남거나 모든 항목이 하나의 URL을 canonical로 가리키면 색인 후보에서 빠질 수 있습니다. CMS 화면은 색인 허용으로 보이는데 배포 템플릿이나 HTTP 헤더가 반대 지시를 내보내는 경우도 있습니다. 새 글, 품절 상품, 페이지네이션과 다국어처럼 상태가 다른 URL을 함께 검사해야 예외가 드러납니다.

인덱서빌리티 조건을 갖췄다는 말이 이미 색인됐거나 곧 노출된다는 뜻은 아닙니다. Google은 기술 요구사항을 충족한 페이지도 크롤링, 색인과 게재를 약속하지 않는다고 안내합니다. 실제 상태와 Google이 선택한 대표 URL은 URL 검사와 페이지 색인 생성 보고서에서 따로 확인합니다.

템플릿 오류는 어떻게 찾을까요?

상품·지역·글 템플릿마다 신규 URL, 오래된 URL, 품절·종료 상태와 다국어 URL을 골라 접근 조건과 색인 지시를 나란히 적습니다. 한 번의 설정 오류가 어디까지 번졌는지 알 수 있고, 수정 뒤 같은 표본으로 다시 검사할 수 있습니다. 일부 페이지만 우연히 열린 상태를 전체 해결로 오해할 가능성도 줄어듭니다.

Google AI 개요와 AI 모드로 범위를 한정하면 참고 링크 후보 페이지에는 Google 색인과 스니펫 표시 자격이 필요합니다. 그렇다고 이 조건이 AI 답변의 언급이나 출처 링크를 약속하지는 않습니다. OpenAI는 ChatGPT 검색용 OAI-SearchBot과 잠재적 학습용 GPTBot을 따로 안내하므로, Google 밖의 서비스는 각자 공개한 크롤러 정책과 실제 접근 결과를 확인해야 합니다.

개발 요청에 “검색에 안 나옴”이라고만 쓰면 담당자는 원인 조사부터 다시 해야 합니다. 영향을 받는 템플릿, 정상·오류 표본 URL, 깨진 접근 조건이나 색인 지시를 함께 적으면 서버, 렌더링과 CMS 설정 중 어느 부분을 고칠지 정하기 쉬워집니다.

Crawlability와 Indexability 병행 운영의 실제 판단

실무에서는 Crawlability와 Indexability 관련 설정을 한꺼번에 바꾸기보다 실제 업무 한 건을 골라 URL 발견, 서버 응답, 렌더링 항목을 나란히 기록하는 편이 빠릅니다. 현재 공개 URL과 운영 기록을 대조하면 콘텐츠 수정으로 끝날 일과 시스템 설정이 필요한 일을 분리할 수 있습니다.

Crawlability와 Indexability 보고서에서는 noindex 항목도 하나의 종합 점수로 합치지 않습니다. 검색 유입이 늘었어도 답변에 오래된 정보가 남을 수 있고, AI 인용이 생겨도 전환 페이지가 약할 수 있습니다. 관련 URL·질문·확인일을 보존하고 같은 조건에서 다시 확인해야 다음 투자의 근거가 남습니다.

참고 자료

• Google 검색 기술 요구사항

• Google 크롤링·인덱싱 문서 모음

• Google robots 메타 태그 사양

• Google URL Inspection API

• Google 검색의 크롤링·색인·게재 과정

• Google 생성형 AI 기능과 웹사이트

• OpenAI: Publishers and Developers FAQ

같이 보면 좋은 글

• 크롤러빌리티

• 인덱서빌리티

• 크롤링

• 인덱싱

• robots.txt

• `noindex`

• 캐노니컬 태그

• 동적 렌더링

자료 확인일: 2026년 8월 9일. 크롤러빌리티와 인덱서빌리티는 이 글의 운영 정의이며, 실제 상태 판정은 Google의 최신 공식 보고서와 공개된 페이지 응답을 기준으로 해야 합니다.

기존 사이트에서 무엇부터 비교할까요?

정상 URL과 빠진 URL을 한두 개씩 문의에 남기면 이 운영 방식이 서버 응답, 렌더링, robots 지시, canonical와 실제 색인 상태를 대조합니다. 그 결과를 바탕으로 SEO·GEO 수정 범위를 URL 한 개가 아니라 템플릿과 담당 영역 단위로 정리합니다.

대량 미색인 문제 상담하기

Crawlability와 Indexability 비교 이후의 Search OS 운영

Search OS 적용의 출발점은 사이트 교체가 아닙니다. Crawlability와 Indexability 비교에서 확인할 렌더링, noindex 항목을 현재 웹사이트 위에서 측정하고 콘텐츠·기술·외부 정보 가운데 막힌 부분만 손봅니다.

내부 성과 집계 기준으로 Search OS 적용 고객사는 SEO와 AI 검색 노출이 평균 88% 이상 증가했습니다. 이후에는 Crawlability와 Indexability 비교에 사용한 검색과 AI 답변을 같은 주기로 다시 읽습니다. 좋아진 상태를 기준선으로 삼고 이탈이 생긴 URL을 먼저 고쳐 최상의 노출 상태가 이어지도록 관리합니다.