상품 URL이 200을 반환하고 내 브라우저에서 잘 보여도, Googlebot이 같은 상품 정보를 받았다고 볼 수는 없습니다. 여기서는 Google Search Console을 기준으로 원인을 구분합니다. 다른 검색엔진의 판정 방식까지 같다고 단정하지는 않습니다.
핵심 요약
상품 URL의 존속 여부를 먼저 정한 뒤, 요청 URL → 응답 헤더·초기 HTML → 렌더링된 상품 데이터 → 최종 robots·canonical 순서로 대조하세요. 200은 색인 보증이 아닙니다.
200 OK만으로 정상 상품 페이지라고 판단할 수 있을까요?
soft 404는 성공 응답을 받았지만 콘텐츠가 없는 페이지, 오류 화면, 실질적으로 빈 페이지처럼 보인 결과입니다. 특정 오류 문구 하나만으로 판정할 수는 없습니다. 반면 ‘크롤링됨-현재 색인되지 않음’은 크롤링 후 현재 색인하지 않았다는 상태이며, API 실패를 뜻하는 오류 코드가 아닙니다.
진단에서는 ‘계속 제공할 상품 URL인가’, ‘서버가 무엇을 반환했나’, ‘Google이 어떤 콘텐츠와 색인 지시를 보았나’를 나눠야 합니다. 상품 관리 데이터의 판매·재고 상태와 웹 응답도 같은 시각 기준으로 대조하세요. 그렇지 않으면 의도된 품절 안내와 기술 장애를 혼동하기 쉽습니다.
최초 응답과 렌더링 결과를 세 단계로 대조하기
브라우저 개발자 도구의 최종 화면만 보지 말고, 다음 자료를 순서대로 확보합니다.
- 응답 헤더와 초기 HTML: 상품 URL을 직접 요청해 상태 코드와 HTTP 헤더의 X-Robots-Tag를 확인합니다. 초기 HTML에서는 robots 메타의 noindex와 대표 URL을 지정하는 canonical을 봅니다. 상품 본문이 있는지, 화면 뼈대인 앱 셸만 있는지도 구분합니다.
- 렌더링된 상품 콘텐츠: URL 검사의 반환 HTML과 렌더링 화면에서 상품명·가격·설명·대표 이미지가 생성되는지 확인합니다. 필요한 JavaScript와 상품 API에 접근할 수 있는지도 살핍니다. 구조화된 데이터가 있어도 사용자에게 보이는 본문이 비어 있다면 정상 렌더링의 대체 증거가 아닙니다.
- 최종 색인 지시: 렌더링 후 문서인 DOM에서 robots와 canonical을 다시 봅니다. 최초 응답과 달라졌는지 확인하고, URL 검사에서 제공되는 사용자 선언 canonical과 Google 선택 canonical도 대조합니다. 최종 DOM만 보면 최초의 차단 지시를 놓칠 수 있습니다.
핵심 포인트
색인이 필요한 URL에서 초기 noindex를 JavaScript로 나중에 제거하는 구현은 피하는 편이 안전합니다. robots.txt의 크롤링 차단은 noindex와 별개이며, 차단 때문에 Google이 noindex를 읽지 못할 수도 있습니다. 복수 지시가 충돌하면 더 제한적인 규칙이 적용될 수 있습니다.
관련 지시의 범위는 robots 메타 및 HTTP 헤더 안내를 참고할 수 있습니다.
빈 로딩 화면이나 오류 문구는 렌더링 실패의 단서이지, API 타임아웃의 증명은 아닙니다. 해당 시각의 API 응답 코드, 브라우저 콘솔, CDN·WAF·애플리케이션 로그를 대조해야 합니다. 렌더링 지연, 인증·쿠키 의존, 지역 제한, 보안 장비 차단, JavaScript 예외를 구분하세요. 검사 화면이 정상이어도 간헐 장애는 로그로 따로 확인해야 합니다.
클라이언트 라우팅과 상품 API 실패를 구분하는 교차 시험
같은 상품 URL을 새 탭에서 직접 열었을 때와 목록에서 앱 내부 이동으로 열었을 때를 비교합니다. 로그인·캐시·쿠키 덕분에 개인 브라우저에서만 성공할 수 있으므로 익명 세션에서도 시험하고, 모바일 크롤러와 브라우저의 조건을 가능한 한 맞춥니다.
직접 진입은 빈 셸이나 오류인데 내부 이동만 정상이라면, 서버의 상품 경로 연결, 첫 화면 데이터 전달, 라우터의 주소 복원 문제를 우선 살핍니다. 다만 이것도 원인 후보를 좁히는 결과입니다. 각 경로에서 실제로 발생한 API 요청과 응답을 확인해야 합니다.
| 시험할 URL | 비교 목적 |
|---|---|
| 정상 재고 상품 | 정상 콘텐츠와 응답의 비교 기준 확보 |
| 일시 품절 상품 | 상품 본문을 유지하며 품절만 표시하는지 확인 |
| 영구 단종 상품 | 정해 둔 보존·삭제·이동 정책과 실제 응답 비교 |
| 임의의 존재하지 않는 상품 ID | 없는 상품도 같은 앱 셸과 200을 받는지 확인 |
각 URL마다 상태 코드·헤더, 초기 HTML, 렌더링 DOM, 핵심 API 응답, 최종 robots·canonical을 같은 열에 기록합니다. 직접 진입과 내부 이동뿐 아니라 문제 발생 시각과 정상 시각도 비교하세요.
모든 경로에 같은 index.html과 200을 주는 catch-all 설정은 없는 상품까지 정상 응답처럼 만들 수 있습니다. 이는 soft 404 후보이지 판정 보증은 아닙니다. 정상 상품과 없는 ID의 최종 화면이 같은지, API 응답은 다른데 화면이 같아지는지까지 봐야 라우팅과 데이터 처리 문제를 나눌 수 있습니다.
품절과 단종은 어떤 응답 정책으로 나눠야 할까요?
재고가 없다는 사실과 URL의 가치가 없다는 판단은 다릅니다. 상품의 판매 상태를 먼저 확인하되, 응답 정책은 그 주소에서 계속 제공할 정보와 대체 페이지의 동등성을 기준으로 정합니다.
| 상품·페이지 상태 | 응답 방향 | 적용 조건 |
|---|---|---|
| 일시 품절 | 일반적으로 200 유지 | 상품 실체가 유지되고 재입고 가능성이 있으며 본문을 계속 제공 |
| 영구 단종이나 정보 가치가 남음 | 200 보존 가능 | 검색 수요, 설명서·호환 정보·리뷰·후속 모델 안내 등의 독립적 가치가 남음 |
| 페이지를 실제 제거함 | 404 또는 410 | 해당 URL에서 더 이상 콘텐츠를 제공하지 않음 |
| 명확히 동등한 후속 상품으로 이동 | 해당 URL로 301 | 단순한 관련 상품이 아니라 대체 페이지의 동등성이 명확함 |
일시 품절 페이지는 상품명·설명·이미지를 유지하고 가격 표시 정책, 품절 상태, 재입고 또는 대체 탐색 정보를 제공합니다. 본문 전체를 ‘품절입니다’ 한 줄로 바꾸지 마세요. OutOfStock 구조화 데이터도 실제 화면과 일치해야 하지만, 그 표기만으로 색인이 보장되지는 않습니다. 실제 재입고 계획과 무관하게 일시 품절로 장기간 방치하는 것도 피해야 합니다.
영구 단종이라고 무조건 삭제할 필요는 없습니다. 반대로 보존 가치가 없어 제거했다면 200 오류 템플릿을 남기지 않는 것이 우선입니다. 404와 410 중 무엇을 택할지보다 실제 제거 상태를 응답에 반영하는지가 중요합니다. 관련성이 약한 카테고리나 인기 상품으로 일괄 리디렉션하지 마세요. 후속 모델을 안내할 수 있다는 사실만으로 301의 동등성 조건이 충족되지는 않습니다.
진단 결과별 다음 조치
확인할 사항
- 상품 URL의 보존·삭제·이동 정책과 실제 응답이 일치하나요?
- 초기 응답의 색인 지시와 렌더링 후 지시가 달라지나요?
- 직접 진입과 내부 이동의 상품 데이터·API 응답이 다른가요?
- 보고서의 수집 시각과 현재 시험 시각을 구분했나요?
Google URL 검사 안내를 참고하되, 저장된 검사 결과와 현재 라이브 테스트는 시점이 다를 수 있음을 고려해야 합니다. 라이브 테스트 성공은 색인 보증이 아니며, ‘크롤링됨-현재 색인되지 않음’을 그대로 재현하는 시험도 아닙니다.
본문이 비면 렌더링 자료와 로그를, 직접 진입만 실패하면 경로 처리와 초기 데이터를 우선 확인하세요. 렌더링과 지시가 정상이라면 중복·대표 URL 선택·고유 가치 등 색인 단계의 가능성을 살펴야 합니다. 특정 원인은 실제 URL의 응답과 해당 시각의 로그를 확보한 뒤 판단하는 것이 안전합니다.
- URL Inspection tool (support.google.com)
- Robots Meta Tags Specifications (developers.google.com)
