숍서브가 검색에 나오지 않을 때 먼저 볼 5가지
숍서브가 검색에 나오지 않을 때 먼저 볼 5가지
- 카테고리
- Tips
- 분량
- 12분 분량
- 주제
- 일본 EC 플랫폼별 검색·AI 검색 가이드
숍서브 숍이 검색과 AI 검색에 나오지 않을 때 확인할 순서를 5가지로 정리합니다. 3초 표시 지연을 봇이 읽지 못하는 문제로 보는 이유, 원인 분해와 대처 순서, 3가지 도구의 역할, 컨설팅 후 월 1회·15분으로 보는 4개 영역, 무너졌을 때 맡길 곳...
- URL
- searchos.io/ko/blog
- Copyright
- © 2026 Search OS
숍서브 숍에서 상품 페이지가 뜨는 데 3초 넘게 걸리고, 이탈률이 오르는 것이 체감으로도 느껴집니다. 이 상태가 SEO 평가에도 영향을 주는지는 알 수 없습니다. 컨설팅으로 SEO 초기 설정을 받았지만, 앞으로 무엇을 스스로 봐야 하는지 모르겠습니다. 숍서브를 쓰는 숍에서 들어오는 문의는 이 두 가지에 몰려 있습니다.
둘 다 화면상으로는 문제가 없어 보인다는 점이 같습니다. 표시 지연은 사람에게는 이탈로 나타나지만, 크롤러에게는 상품 정보를 읽지 못하는 형태로 나타나고 화면에는 아무것도 보이지 않습니다. 컨설팅으로 정비한 상태도 상품을 추가하고 템플릿을 손대는 사이에 무너지는데, 무너진 것을 알아차리는 체계가 없으면 반년 뒤에는 초기 설정 효과가 남지 않습니다. 이 글에서는 개별 글에서 정리한 내용을 "먼저 볼 5가지" 순서로 다시 묶습니다. 수치와 절차는 각 글의 내용을 그대로 쓰고, 자세한 작업은 글 끝의 링크로 넘깁니다.
1. 3초 표시 지연은 순위보다 "봇이 읽지 못한다"는 문제로 본다
표시에 3초 넘게 걸리는 상태는 사람과 검색 엔진 양쪽에 영향을 줍니다. 다만 나타나는 방식이 다릅니다. 사람에게는 이탈로 나타납니다. 검색 엔진과 AI에게는 순위가 바로 떨어지는 방식이 아니라, 크롤러가 렌더링을 기다리지 못해 상품 정보를 읽지 못하거나 수집 횟수를 줄이는 형태로 나타납니다. "3초" 자체가 특별한 경계선은 아닙니다. Google이 공개한 Core Web Vitals 기준은 따로 있어서, 가장 큰 콘텐츠가 그려지는 시간(LCP)은 2.5초 이내, 조작에 대한 응답(INP)은 200밀리초 이내, 레이아웃 이동(CLS)은 0.1 이내입니다. 3초를 넘는다면 LCP가 "개선 필요"나 "나쁨" 범위일 가능성이 높습니다.
영향 대상 | 무엇이 일어나는가 | 드러나는 방식 |
|---|---|---|
사람 | 표시를 기다리지 못하고 이탈한다 | 이탈률·반송률 상승으로 분석 도구에 나타난다 |
검색 엔진 | 페이지 경험 평가가 떨어진다. 다만 관련성이 낮은 요인 | 순위 변동으로는 작다 |
크롤러 | 렌더링 완료 전에 수집을 중단하거나 수집 빈도를 낮춘다 | Search Console이나 로그로만 보인다 |
AI 검색 | 상품 정보를 읽지 못해 추천 후보에서 제외된다 | 인용되지 않는다는 결과로만 알 수 있다 |
순위에 주는 영향은 작아도 크롤러가 상품 정보를 읽지 못하는 영향은 큽니다. 표시 속도는 SEO 요인이기 전에 봇이 페이지를 읽을 수 있는지의 전제 조건입니다. 3초 아래로 내려도 순위에 주는 직접 효과는 제한적이고, 효과는 색인의 안정과 이탈률 개선에서 나옵니다. 순위보다 "읽고 있는가"를 먼저 확인합니다.
2. 원인을 외부 스크립트·이미지·렌더링 의존·서버 응답으로 나누고, 이 순서로 대처한다
같은 원인인데 사람과 봇에게 다른 결과가 나옵니다. 외부 스크립트 로딩 대기에서 사람은 흰 화면을 기다리지만, 봇은 기다리지 않고 수집을 끝냅니다. 큰 이미지에서 사람은 이미지가 차례로 뜨기를 기다리지만, 봇은 이미지를 읽지 않고 렌더링이 끝나기만 기다립니다. JavaScript 렌더링 후에만 나오는 상품 정보는 사람은 결국 볼 수 있지만, 봇은 렌더링 전 HTML만 읽고 "정보가 없다"고 판단하기도 합니다. 세 번째가 가장 심각한데, 사람 눈에는 멀쩡해 보여서 운영자가 알아차리지 못합니다.
원인 | 전형적인 예 | 확인 방법 | 대처 |
|---|---|---|---|
외부 스크립트 | 리뷰, 채팅, 추천, 측정 태그, 광고 | 브라우저 개발자 도구에서 로딩 순서와 시간을 확인 | 불필요한 것을 제거한다. 남기는 것은 지연 로딩 |
이미지 | 압축되지 않은 상품 이미지, 한 페이지에 수십 장 | PageSpeed Insights의 "이미지 최적화" 항목 | 압축, 차세대 형식, 지연 로딩 |
렌더링 의존 | 상품 설명·가격·재고가 JavaScript로 나중에 삽입된다 | Search Console의 URL 검사로 수집된 HTML을 확인 | 초기 HTML에 상품 정보를 포함한다 |
서버 응답 | 응답 시작까지 시간이 걸린다 | PageSpeed Insights의 "서버 응답 시간" | 플랫폼 측의 제약을 확인 |
숍서브에서 운영자가 직접 손댈 수 있는 것은 주로 외부 스크립트와 이미지입니다. 렌더링 의존과 서버 응답은 템플릿과 플랫폼의 영역이라 확인은 하되 대처는 제한적입니다. 대처 순서는 외부 스크립트 전수 조사, 이미지 압축과 화면 밖 이미지의 지연 로딩, URL 검사로 Google이 가져간 HTML에 상품명·가격·설명이 있는지 확인, 봇의 수집 상황 확인입니다. 쓰지 않는 태그와 효과 없는 위젯을 지우는 것만으로 1초 이상 빨라지는 예는 드물지 않습니다. 매출에 보탬이 되는 스크립트는 남기되, 로딩을 늦춰서 첫 화면을 방해하지 않게 합니다.
3. 3가지 도구로 서로 다른 것을 재고, 봇 로그는 별도 수단으로 마련한다
PageSpeed Insights, Search Console의 URL 검사, 서버 로그·봇 로그는 각각 보이는 것이 다릅니다. 3가지를 합쳐야 비로소 "사람이 기다리고 있는가" "Google이 읽고 있는가" "AI 봇이 읽고 있는가"가 보입니다.
도구 | 보이는 것 | 보이지 않는 것 |
|---|---|---|
PageSpeed Insights | 실제 사용자의 경험 데이터와 랩 측정, 개선 항목 | 봇이 무엇을 읽었는지 |
Search Console의 URL 검사 | Google이 수집한 HTML과 스크린샷 | AI 측 봇의 수집 상황 |
서버 로그·봇 로그 | Googlebot, GPTBot, PerplexityBot의 수집 횟수·응답·오류 | 사용자 경험 |
숍서브 관리 화면에서는 봇 로그가 보이지 않습니다. 세 번째는 별도 수단을 마련합니다. AI 봇은 속도 그 자체보다 수집이 성공했는지, 렌더링 전 HTML에 정보가 있는지를 봅니다. 느린 페이지는 수집이 끊기거나 빈도가 떨어집니다. 속도는 한 번 고치고 끝나지 않습니다. 외부 스크립트는 캠페인이나 앱을 추가할 때마다 늘고 상품 이미지는 등록할 때마다 쌓이므로, 고친 다음 달에 원래대로 돌아가기 쉬운 성질이 있습니다.
4. 컨설팅 뒤에는 월 1회·15분으로 4개 영역×3개 항목의 무너짐을 본다
컨설팅으로 정비한 것은 그날의 상태입니다. 컨설팅의 가치는 "무엇을 해야 하는지"를 정해 준 데 있고, 정한 것이 지금도 지켜지는지 보는 일은 점포 쪽에서만 할 수 있습니다. 필요한 것은 전문 지식이 아니라 월 1회·15분으로 무너지지 않았는지 확인하는 정해진 절차입니다.
영역 | 보는 곳 | 무너짐의 징후 |
|---|---|---|
색인 | Search Console 페이지 보고서 | 색인됨이 줄어든다, 제외 이유가 늘어난다 |
속도 | PageSpeed Insights(주력 3페이지) | LCP가 4초를 넘는다, CLS가 빨간색 |
구조화 데이터 | 리치 리절트 테스트(상품 1·카테고리 1) | 오류, 타입의 소실 |
콘텐츠 | 자기 숍의 주력 페이지 | 오래된 가격·재고·캠페인이 남아 있다 |
색인은 색인된 페이지 수가 지난달보다 크게 줄지 않았는지, "크롤됨 - 현재 색인이 생성되지 않음" "중복"이 늘지 않았는지, 사이트맵 상태가 "성공" 그대로이고 발견 수가 상품 수와 가까운지를 봅니다. 속도는 주력 3페이지(톱·주력 카테고리·주력 상품)를 매월 같은 페이지로 재고, LCP 2.5초 이내(4초 초과는 대응 필요), CLS 0.1 이하, INP 200ms 이하를 기준으로 삼습니다. 구조화 데이터는 상품 페이지 1개와 카테고리 페이지 1개를 리치 리절트 테스트에 넣어, 지난달 감지되던 타입(Product, BreadcrumbList 등)이 이달에도 감지되는지, 가격·재고가 화면 표시와 일치하는지를 봅니다. 콘텐츠는 종료된 캠페인과 오래된 가격, "재고 있음" 그대로인 품절 상품, 배송비 안내가 모든 페이지에서 같은지를 봅니다. AI 검색은 오래된 정보를 인용하지 않고, 숍 안에 서로 다른 말이 있으면 인용 출처로 뽑히기 어렵습니다.
5. 무너졌을 때 "누구에게 맡길지"를 월 1회 확인과 한 세트로 정해 둔다
체크리스트로 무너진 것을 알아도 맡길 곳이 없으면 그대로 방치됩니다. 확인은 찾아내는 데까지이고, 고치는 일은 별도 작업입니다. 수치가 줄거나 늘었다면 상품 삭제, 템플릿 변경, URL 변경처럼 그달에 무엇을 바꿨는지 확인하고, 바꾼 시기와 변동 시기가 겹치는지 맞춰 봅니다.
무너짐의 종류 | 스스로 고칠 수 있는가 | 맡길 곳 |
|---|---|---|
오래된 가격·재고·캠페인 | ○ | 본인 |
이미지가 무겁다·크기 미지정 | ○(이미지 재저장) | 본인 |
구조화 데이터 오류 | △ | 템플릿을 손댄 사람, 또는 숍서브 지원팀 |
색인 수의 급감 | △ | 원인을 모르면 상담 |
외부 도구로 인한 속도 악화 | △ | 도구 제공사 |
맡길 곳은 월 1회 확인과 한 세트로 한 줄씩 적어 둡니다. 상품 수가 수백 개까지라면 월 1회로 충분하고, 큰 캠페인이나 템플릿 변경 직후에는 그 주에 한 번 더 확인합니다. 문제가 없었다는 사실도 확인한 날짜와 결과를 함께 기록해 둡니다. 다음에 문제가 생겼을 때 언제부터인지 아는 것이 원인을 찾는 지름길입니다. Search Console은 컨설팅 때 설정되어 있는 경우가 많지만, 로그인할 수 있는 계정을 점포 쪽에서 갖고 있는지 확인하고 없다면 소유권 추가를 요청합니다.
Search OS는 월 1회 확인으로는 보이지 않는 부분을 계속 지켜보는 층입니다
위 4개 영역을 매월 15분씩 보면 초기 설정 상태는 꽤 오래 유지됩니다. 다만 AI 검색 봇(GPTBot 등)이 숍을 수집하는지는 Search Console에도 PageSpeed Insights에도 나오지 않습니다. Search OS는 숍서브 숍을 포함한 기존 사이트에 검색 엔진과 AI 크롤러가 읽기 쉬운 구조와 메타데이터를 별도 층으로 제공합니다. 사람용 화면은 그대로 둡니다. 봇 로그로 Googlebot과 GPTBot의 수집 상황·응답 시간·오류를 지속적으로 확인하고, 색인·메타데이터·구조화 데이터·봇의 접근 상태가 무너지면 감지해 수정 대상으로 정리합니다. 컨설팅에서 정한 방침을 대신하지는 않으며, 그 방침이 오늘도 지켜지는지 점포 대신 계속 지켜보는 층입니다.
담당자가 먼저 볼 질문
주력 상품 페이지를 PageSpeed Insights에 넣었을 때 LCP가 2.5초 이내인가. 4초를 넘지 않는가
Search Console의 URL 검사에서 Google이 가져간 HTML에 상품명·가격·설명이 들어 있는가
리뷰, 채팅, 추천, 측정 태그, 광고 가운데 효과 없는 것이 남아 있지 않은가
상품 이미지는 압축되어 있고, 화면 밖 이미지는 지연 로딩으로 되어 있는가
Search Console에 로그인할 수 있는 계정을 점포 쪽에서 갖고 있는가
지난달 감지되던 구조화 데이터 타입(Product, BreadcrumbList 등)이 이달에도 감지되는가
배송비·재고·캠페인 안내는 모든 페이지에서 최신이고 같은가
결론
숍서브 숍이 검색에 나오지 않을 때는 먼저 표시 속도를 순위 문제가 아니라 "봇이 읽고 있는가"의 문제로 봅니다. 원인을 외부 스크립트·이미지·렌더링 의존·서버 응답으로 나눠 운영자가 손댈 수 있는 외부 스크립트와 이미지부터 대처하고, PageSpeed Insights·URL 검사·봇 로그 3가지로 서로 다른 것을 잽니다. 컨설팅 뒤에는 월 1회·15분으로 색인·속도·구조화 데이터·콘텐츠 4개 영역을 보고, 무너졌을 때 맡길 곳을 미리 정해 둡니다. 여기까지가 설정과 절차의 문제이고, 그 다음은 상품과 스크립트가 늘 때마다 같은 상태를 유지하는 운영의 문제입니다.