futureshop이 검색·AI 검색에 안 나올 때 볼 4가지
futureshop이 검색·AI 검색에 안 나올 때 볼 4가지
| 카테고리 | 분량 | 주제 | 내용 | 출처 | 저작권 |
|---|---|---|---|---|---|
| Tips | 11분 분량 | 일본 EC 플랫폼별 검색·AI 검색 가이드 | futureshop은 구조화 데이터와 XML 사이트맵을 자동 출력하지만, commerce creator의 헤딩 무너짐, 복수 그룹 등록의 중복 URL, Article 누락, WordPress 글의 사이트맵 누락은 운영 쪽 확인이 필요합니다. 검색과 AI 검색에 나오지 않을 때... | searchos.io/ko/blog | © 2026 Search OS |
futureshop은 브레드크럼·상품·리뷰·사이트 내 검색의 구조화 데이터와 XML 사이트맵을 자동으로 출력합니다. 이 범위는 다른 ASP 카트보다 넓고, 상품 페이지만 보면 충분한 출발점입니다. 그래도 commerce creator로 만든 LP가 AI에 인용되지 않는다, Search Console에 '중복되었습니다'가 줄지어 나온다, WordPress 연동 글만 색인되지 않는다는 상담은 끊이지 않습니다.
원인은 futureshop의 기능 부족이 아니라 자동 출력 바깥에 있는 4곳에 모여 있습니다. 헤딩 구조, 상품 URL과 canonical, 구조화 데이터의 범위, 그리고 WordPress 글의 사이트맵입니다. 이 글에서는 이 4가지를 확인하는 순서대로 정리합니다. 수치와 사양은 각 주제의 개별 글에 적은 것만 사용합니다.
1. commerce creator 페이지의 헤딩이 목차로 읽히는가
commerce creator는 파츠를 쌓아 페이지를 만드는 도구입니다. 그래서 겉보기의 "큰 글자"와 HTML상의 헤딩(h1~h3)이 어긋난 페이지가 쉽게 만들어집니다. 검색 엔진과 AI 검색은 겉보기가 아니라 헤딩 태그로 구조를 읽으므로, 헤딩이 없는 페이지는 "긴 한 단락"으로 취급되어 어디가 답인지 판단되지 않습니다. 기준은 한 페이지에 h1은 1개, h2는 3~6개, h3는 h2 아래에만입니다. 페이지 템플릿이 이미 h1(숍 이름이나 페이지 제목)을 출력하고 있다면 페이지 안의 최상위 헤딩은 h2부터 시작합니다.
확인은 대상 페이지를 개발자 도구로 열어 h1·h2·h3만 위에서부터 순서대로 적고 읽어 보는 일입니다. 적은 목록이 "NEW" "추천" "더 보기"뿐이라면 무너진 상태입니다.
무너짐의 패턴 | 무슨 일이 일어나는가 | 고치는 법 |
|---|---|---|
h1이 없다 | 페이지의 주제가 전달되지 않는다 | 템플릿 또는 최상단의 헤딩 파츠를 h1으로 |
h1이 여러 개 | 주제가 분산된다 | 두 번째 이후를 h2로 |
h2가 없고 h3·h4만 | 계층을 읽을 수 없다 | 각 섹션의 첫머리를 h2로 |
장식용 큰 글자가 h2 | "공지" "NEW"가 헤딩이 된다 | 텍스트 파츠 + CSS로 변경 |
이미지에만 헤딩이 있다 | 헤딩이 존재하지 않는다 | 이미지 아래에 텍스트 헤딩을 둔다 |
각 파츠에서 헤딩 레벨을 지정할 수 있는지는 commerce creator의 파츠 사양으로 확인합니다. 지정할 수 없는 파츠는 헤딩 파츠와 조합해 씁니다. LP를 복제해 새 페이지를 만들 때는 이전 LP의 주제가 남으므로 헤딩을 그대로 두지 않습니다.
2. 복수 그룹에 등록한 상품의 canonical이 그룹을 포함하지 않는 URL을 가리키는가
futureshop에서는 상품을 여러 그룹에 등록할 수 있습니다. 그룹 계층을 거쳐 상품에 도달했을 때 URL에 그룹 정보가 붙는 구성이면, 같은 상품에 그룹 A 경유·그룹 B 경유·그룹을 경유하지 않는 3개의 URL이 생깁니다. 검색 엔진은 어느 것이 진짜인지 스스로 정하고, 백링크와 평가는 여러 URL로 나뉩니다. AI 검색도 같은 내용의 페이지가 여럿이면 인용 출처로 뽑기 어려워집니다.
우리 숍에서 일어나고 있는지는 같은 상품을 다른 그룹에서 열어 URL을 비교하면 알 수 있습니다. Search Console의 페이지 보고서에 "사용자가 선택한 표준이 없는 중복 페이지"가 나오지 않는지, 상품 페이지 소스에서 rel="canonical" 의 대상이 어디인지도 확인합니다.
상태 | 대처 |
|---|---|
상품 URL에 그룹 ID가 포함되어 그룹마다 다른 URL이 된다 | canonical을 그룹 없는 상품 URL로 향하게 한다. 내부 링크도 그 URL로 맞춘다 |
상품 URL은 하나지만 그룹 목록의 페이지네이션이 중복되어 있다 | 목록은 페이지마다 자기 참조 canonical. 1페이지로 모으지 않는다 |
canonical이 그룹 경유 URL을 가리키고 있다 | 대상을 수정. 전체 상품에서 확인 |
중복이 없다 | 아무것도 하지 않는다. Search Console의 "중복"을 월 1회 확인 |
canonical을 맞춰도 그룹 목록이나 관련 상품 파츠가 내보내는 링크가 그룹 경유 URL 그대로면 효과는 약해집니다. noindex는 색인하지 않는다는 지시일 뿐 평가를 합쳐 주지 않으므로, 통합은 canonical로 합니다. 상품을 등록하는 그룹은 의미 있는 분류로 한정하고, "세일" "신상품" 같은 일시적인 그룹은 태그나 특집 페이지로 다루며, 계층은 3단계까지로 합니다.
3. 자동 출력 구조화 데이터가 화면과 일치하고 Article까지 닿아 있는가
자동 출력의 범위는 "상품의 기본 정보"까지입니다. 콘텐츠 페이지용 Article은 자동 출력 대상이 아니고, 자동 사이트맵에 들어가는 것도 관리 화면에서 만든 페이지뿐입니다. 게다가 잘못된 구조화 데이터는 없는 것보다 나쁠 수 있습니다. 오류가 있으면 블록 전체가 무시되기도 하기 때문입니다. 상품 페이지·카테고리 페이지·특집 페이지·메인 페이지 4종류의 URL을 리치 리절트 테스트에 돌려, 검출된 유형과 오류·경고, Offer의 price와 availability가 화면의 가격·재고와 일치하는지를 기록합니다.
우선도 | 항목 | 이유 | 구현 위치 |
|---|---|---|---|
1 | 가격·재고·옵션의 정합 | 불일치는 AI의 상품 추천에서 빠지는 직접 요인 | 상품 데이터와 템플릿 |
2 | 콘텐츠 페이지의 Article + BreadcrumbList | 비교·고르는 법 글이 인용되기 위한 전제 | 템플릿의 head |
3 | FAQ·비교표를 가시 HTML로 둔다 | AI는 숨겨진 정보나 이미지 속 텍스트를 안정적으로 읽지 못한다 | 본문 |
4 | 검증의 지속 | 템플릿 업데이트나 앱 추가로 출력이 깨진다 | 운영 |
놓치기 쉬운 것은 판매 중인 상품에 템플릿에서 비롯된 "재고 없음" 텍스트가 남아 있는 경우입니다. AI가 그 상품을 추천 후보에서 빼기도 하며, 실제로 연매출 400억 원(약 40억 엔) 규모의 한국 EC 브랜드에서는 이 숨겨진 품절 텍스트를 지우는 것이 개선의 출발점이었습니다. FAQ는 Google이 FAQ 리치 리절트를 정부·의료 등 권위 있는 사이트 중심으로 제한했으므로, FAQPage 구조화 데이터보다 가시 HTML로서의 FAQ를 우선합니다. 템플릿을 바꿨다면 다음 날 리치 리절트 테스트에 돌립니다.
4. WordPress 연동 글이 사이트맵과 내부 링크로 숍에 이어져 있는가
futureshop이 자동 생성하는 사이트맵의 대상은 관리 화면에서 만든 페이지에 한정됩니다. WordPress로 쓴 글은 관리 화면 밖에 있으므로 사이트맵에 들어가지 않습니다. 검색 엔진은 내부 링크를 따라가면 글을 찾을 수는 있지만, 사이트맵에 없는 페이지는 발견이 늦고 갱신도 알아차리기 어렵습니다. 대처는 WordPress 쪽 사이트맵(WordPress 기본 /wp-sitemap.xml 또는 SEO 플러그인이 만든 것 중 한쪽)을 futureshop 사이트맵과는 별도로 Search Console에 등록하는 일입니다.
WordPress의 배치 | Search Console 속성 | 등록 |
|---|---|---|
숍과 같은 도메인의 서브디렉터리(/blog/) | 숍과 같은 속성 | 같은 속성에 WordPress 사이트맵을 추가 등록 |
서브도메인(blog.example.jp) | 도메인 속성이면 같음. URL 접두어 속성이면 다름 | 도메인 속성으로 통일하고 추가 등록 |
별도 도메인 | 별도 속성 | 별도 속성으로 등록 |
사이트맵은 발견을 도울 뿐 글과 상품의 관계까지는 전달하지 않습니다. 글 본문에서 상품 페이지·그룹 페이지로, 상품 페이지 설명 말미에서 관련 글로 링크하고, 헤더·푸터를 공통으로 둡니다. 글 쪽에서는 canonical이 자기 자신을 가리키는지, Article에 제목·공개일·갱신일·저자가 출력되는지, Organization은 숍의 최상위에만 있는지, 태그·날짜 아카이브가 빈약할 때 noindex인지를 확인합니다.
Search OS는 4가지가 오늘도 유지되는지 계속 지켜보는 층입니다
Search OS는 futureshop을 포함한 기존 숍을 지원합니다. commerce creator에서의 제작이나 자동 출력을 대체하지 않고, 페이지의 헤딩 구조·메타데이터·구조화 데이터·canonical·사이트맵 상태를 지속적으로 검증하며, 봇 로그로 검색 엔진과 AI 크롤러가 실제로 페이지를 가져가는지 확인합니다. 가시 텍스트와 어긋나는 곳, Article이 빠진 콘텐츠 페이지, canonical 대상의 오류, 내부 링크 끊김은 우선순위를 붙인 수정 대상으로 정리합니다.
담당자가 먼저 볼 질문
주력 LP의 헤딩만 뽑아냈을 때 목차로 읽히는가. 템플릿이 이미 h1을 출력하고 있지 않은가
같은 상품을 다른 그룹에서 열었을 때 URL이 같은가. 다르다면 canonical은 그룹을 포함하지 않는 URL을 가리키는가
주력 상품의 Offer의 price와 availability는 화면의 가격·재고와 일치하는가
특집 페이지·블로그 글에 Article과 브레드크럼이 출력되는가
WordPress 사이트맵은 futureshop 사이트맵과 별도로 Search Console에 등록되어 있는가
최근 글에서 관련 상품 페이지로, 상품 페이지에서 글로 링크가 있는가
템플릿을 마지막으로 바꾼 날과 마지막으로 리치 리절트 테스트를 돌린 날 중 어느 쪽이 최근인가
결론
futureshop의 자동 출력은 출발점으로 충분하지만, 헤딩 구조, canonical 대상, 가시 텍스트와의 일치, WordPress 글의 사이트맵은 운영 쪽 확인이 필요합니다. 고권위 도메인에서 81페이지를 30일간 추적한 실험에서는 Google AI Mode의 인용이 첫 주 59%에서 30일째 26%까지 떨어졌고, 첫 주에 인용되지 않은 페이지는 그 뒤에도 인용되는 일이 드물었습니다. 공개 직후 몇 주 안에 읽히는 상태인지가 이후를 좌우하므로, 4가지는 공개 전과 템플릿을 바꾼 다음 날에 확인합니다.