makeshop이 검색·AI 검색에 안 나올 때 볼 4가지
makeshop이 검색·AI 검색에 안 나올 때 볼 4가지
- Tips
- 11분 분량 일본 EC 플랫폼별 검색·AI 검색 가이드
makeshop은 크리에이터 모드의 상품 상세 페이지에서 JSON-LD를 자동 출력합니다. 거기에 독자 구조화 데이터를 더하면 이중 출력이 되고, 블로그의 위치와 사이트맵, 글의 구조에 따라서도 검색과 AI 검색에서 보이는 방식이 달라집니다. 먼...
- URL
- searchos.io/ko/blog
- Copyright
- © 2026 Search OS
makeshop 숍에서 들어오는 상담은 크게 둘로 나뉩니다. 상품 페이지에 JSON-LD를 추가했더니 리치 리절트 테스트에서 Product가 2개 잡히며 오류가 났다는 것과, 블로그를 매주 갱신하는데도 ChatGPT나 Google AI Mode에서 회사 이름이 나오지 않는다는 것입니다. 앞의 것은 구조화 데이터의 이중 출력, 뒤의 것은 블로그 운영(표준 기능 또는 WordPress 연동)과 숍이 이어지는 방식의 문제입니다.
둘 다 makeshop의 기능이 막고 있는 것은 아닙니다. 표준 출력의 내용을 확인하지 않고 더한다, 블로그의 위치와 사이트맵을 정하지 못했다, 글이 상품으로 이어지는 형태가 아니다, 같은 운영 쪽 확인 부족에 원인이 모여 있습니다. 이 글에서는 먼저 볼 4가지를 순서대로 정리합니다. 수치와 사양은 각 주제의 개별 글에 적은 것만 사용합니다.
1. 상품 페이지의 구조화 데이터가 이중으로 나오고 있지 않은가
makeshop은 크리에이터 모드의 상품 상세 페이지에서 JSON-LD를 표준으로 출력합니다. 거기에 크리에이터 모드로 독자 JSON-LD를 추가하면 같은 페이지에 같은 유형이 두 번 나옵니다. 검증 도구는 어느 쪽이 맞는지 판단하지 못해 오류나 경고를 내고, 오류가 있으면 블록 전체가 무시되기도 하므로 넣기 전보다 나쁜 결과가 됩니다. 같은 유형이 2개 있는 페이지는 하나도 없는 페이지보다 다루기 어려우므로, 더하기 전에 빼는 것부터 시작합니다.
확인은 두 가지입니다. 상품 페이지 URL을 리치 리절트 테스트에 돌려 감지된 유형 목록을 보는 것과, 페이지 소스에서 application/ld+json 을 검색해 나오는 곳이 2곳 이상은 아닌지 보는 것입니다. 표준 출력이 템플릿 어디에서 나오는지는 크리에이터 모드의 템플릿 안에서 ld+json 을 검색하면 알 수 있습니다. 카테고리 페이지와 톱페이지에서도 같은 확인을 합니다.
상황 | 대처 |
|---|---|
표준으로 Product가 출력됨 + 크리에이터 모드에서 Product를 추가 | 추가분을 삭제합니다. 표준을 남깁니다 |
표준으로 Product가 출력됨 + 표준의 값이 화면과 어긋남 | 추가가 아니라 상품 데이터 쪽을 고칩니다 |
표준으로 BreadcrumbList가 출력되지 않음 | 크리에이터 모드에서 추가해도 됩니다 |
표준으로 Article이 출력되지 않음(콘텐츠 페이지) | 크리에이터 모드에서 추가해도 됩니다 |
표준으로 Organization이 출력됨 | 추가하지 않습니다. 전체 페이지에 넣지 않습니다 |
대부분은 표준을 남기고 추가분을 지우는 것이 정답입니다. 표준은 상품 추가에 자동으로 추종하고 makeshop 측이 유지보수하기 때문입니다. 표준 값이 화면과 어긋난다면 JSON-LD를 덮어쓰지 않고 원래의 상품 데이터(가격·재고·상품명)를 고칩니다. 표준 Product에 브랜드명이나 품번이 없는 식으로 속성이 부족하다면 Product를 통째로 추가하지 않고, 표준 출력을 끄고 자신의 JSON-LD로 일원화하거나, 표준을 남기고 부족한 속성은 포기하는 것 중 하나를 고릅니다. 스위치는 「ショップ構築 / 設定 / SEO・SNS・マーケティング / アクセス解析用のタグの設定」에 있습니다. 부족한 유형을 더할 때는 값을 크리에이터 모드의 독자 태그로 동적으로 채우고, 추가한 뒤 상품 페이지 3종(일반·품절·옵션 있음)에서 다시 검증합니다.
2. 블로그를 숍 하위에 두고 있는가
WordPress로 글을 쓰는 경우 가장 먼저 정해지는 것은 블로그를 숍 하위에 둘지 별도 도메인에 둘지입니다. 검색 엔진은 도메인 단위로 평가를 쌓으므로, 별도 도메인 블로그에서 좋은 글이 인용돼도 그 평가는 블로그 도메인에 쌓이고 숍 도메인으로는 잘 흘러가지 않습니다. 하위에 두면 글의 평가와 상품 페이지의 평가가 같은 도메인에 쌓이고, AI 검색도 같은 도메인 안의 글과 상품을 연결 짓기 쉬워집니다.
배치 | 예 | 평가의 축적 | 난이도 | 판단 |
|---|---|---|---|---|
서브디렉터리 | shop.example.jp/blog/ | 숍과 동일 도메인에 축적 | 높음(연동 설정이 필요) | ◎ |
서브도메인 | blog.example.jp | 거의 동일 도메인으로 취급되지만 엄밀히는 분리 | 중간 | ○ |
별도 도메인 | example-blog.jp | 블로그에만 축적. 숍으로 흘러가기 어려움 | 낮음 | △ |
makeshop의 WordPress 연동 옵션에서 고를 수 있는 배치는 공식 사양으로 확인하고, 고를 수 있는 것 중 숍에 가장 가까운 배치를 택합니다. 서브도메인은 엄밀히는 별도의 호스트명이지만, 내부 링크를 촘촘히 두면 서브디렉터리에 가까운 효과를 노릴 수 있습니다. 이미 별도 도메인으로 운영 중이고 글이 많고 백링크가 있다면 옮길 때 URL 리다이렉트가 필요하므로, 먼저 내부 링크를 촘촘히 하고 그래도 효과가 부족하면 이전을 검토합니다.
3. 블로그와 숍이 하나의 사이트로 읽히는 상태인가
배치가 무엇이든 블로그와 숍을 하나의 사이트로 취급받기 위한 요건은 같습니다. WordPress 쪽 글이 makeshop 사이트맵에 들어가는지는 연동 사양에 따라 다르므로, 들어가지 않는다는 전제로 Search Console에 따로 등록합니다.
항목 | 내용 |
|---|---|
글 → 상품 내부 링크 | 본문 중과 말미에 해당 상품·카테고리로 가는 링크 |
상품 → 글 내부 링크 | 상품 설명 말미에 "선택 방법은 여기로" |
헤더·푸터 공유 | 같은 내비게이션으로 블로그와 숍이 하나의 사이트로 보이는 상태 |
사이트맵 | WordPress 쪽 사이트맵을 별도로 Search Console에 등록(makeshop 사이트맵에는 포함되지 않음) |
canonical | 블로그 글의 canonical이 자기 자신을 가리킵니다. 숍 쪽과 중복되는 페이지를 만들지 않습니다 |
구조화 데이터 | WordPress 쪽에서 Article을 출력. Organization은 숍 메인 페이지에만 |
글에는 Article을 넣습니다. 상품 구조화 데이터는 상품 페이지 쪽에 있으므로 글에는 넣지 않고, 글에서 상품 페이지로 링크하면 충분합니다. 블로그를 여러 구조로 운영한다면 같은 내용을 양쪽에 두지 않습니다. 중복은 평가를 갈라놓습니다. 공지와 선택 가이드처럼 역할을 정해 둡니다.
4. 글이 "상품으로 이어지는 답"이 되어 있는가
AI 검색(ChatGPT, Perplexity, Gemini, Google AI Mode)은 갱신 빈도나 글자 수로 인용 출처를 고르지 않습니다. 보는 것은 질문에 바로 답하는 단락이 있는지, 그 단락을 기계가 정확하게 잘라낼 수 있는 구조인지, 글이 사이트 안의 상품·카테고리와 분명하게 이어져 있는지입니다. 글 제목이 질문형이라면 첫 H2 바로 아래에 답을 쓰고, 기존 글도 맨 앞에 3~4문장만 더하면 구조가 바뀝니다. 비교나 선택 기준 질문에는 표가 가장 인용되기 쉬운 형식이지만, 표를 이미지로 붙이면 AI에게는 그림 한 장일 뿐입니다. HTML 표로 본문에 두고, FAQ는 실제 고객 질문을 짧은 문답으로 3~5개 나열합니다.
확인 항목 | 확인 방법 | 영향 |
|---|---|---|
글의 첫 H2 바로 아래에 답이 있는가 | 상위 10개 글을 열어 확인 | 인용 블록의 유무를 좌우 |
각 글에서 상품·카테고리로 가는 링크가 있는가 | 글마다 링크 대상을 목록화 | 인용이 구매 동선으로 이어지는가 |
표·FAQ가 HTML로 존재하는가 | 본문 소스를 확인 | 비교·선택 기준 질문에 대한 대응 |
JSON-LD가 유효한가 | 리치 리절트 테스트 | 기계 가독성의 기초 |
봇이 글을 실제로 수집하고 있는가 | 서버 로그 또는 봇 로그 | 인용의 전제 조건 |
5개 항목 중 마지막 하나만은 makeshop 관리 화면에서 보이지 않습니다. 봇이 글을 실제로 가져가는지는 로그로만 확인되기 때문입니다. JSON-LD 자동 출력은 크리에이터 모드의 상품 상세 페이지가 대상이므로, 글 쪽의 Article·BreadcrumbList는 직접 리치 리절트 테스트에 돌려 검증합니다. 글을 모두 다시 쓸 필요는 없고, 상품에 가까운 상위 10~20개 글로 좁혀 맨 앞의 답 단락과 내부 링크를 더하는 데서 시작합니다.
Search OS는 추가한 것이 오늘도 맞는지 계속 지켜보는 층입니다
Search OS는 makeshop을 포함한 기존 숍의 구조화 데이터 출력 상태를 계속 검증합니다. 이중 출력, 화면과의 불일치, 템플릿 변경 후의 파손을 찾아 수정 대상으로 정리하고, 봇 로그로 검색 엔진과 AI 크롤러가 실제로 페이지를 가져가는지 확인합니다. makeshop과 WordPress처럼 여러 구조로 이뤄진 사이트에서는 메타데이터·구조화 데이터·사이트맵·canonical을 별도 층으로 제공하고, 내부 링크 끊김이나 중복을 수정 대상으로 정리합니다. 추가 작업을 대신하는 것도, 블로그를 대체하는 것도 아닙니다.
담당자가 먼저 볼 질문
상품 페이지를 리치 리절트 테스트에 돌렸을 때 Product는 하나만 감지되는가
페이지 소스에서 application/ld+json 은 몇 곳에 나오는가. 각각 표준 템플릿과 추가분 중 어디에서 온 것인가
표준 출력 Product의 가격·재고·상품명은 화면 표시와 일치하는가
블로그는 숍과 같은 도메인 하위에 있는가. 별도 도메인이라면 내부 링크는 촘촘한가
WordPress 쪽 사이트맵은 makeshop 사이트맵과 별도로 Search Console에 등록되어 있는가
상품에 가까운 상위 10개 글의 첫 H2 바로 아래에 질문에 대한 답이 있는가
템플릿을 바꾼 날과 마지막으로 다시 검증한 날 중 어느 쪽이 최근인가
결론
makeshop의 표준 출력은 상품 페이지의 출발점으로 충분하며, 더하기 전에 뺀다는 것이 구조화 데이터의 원칙입니다. 블로그는 하위에 두고, 사이트맵을 따로 등록하고, 글을 상품으로 이어지는 답으로 만듭니다. 고권위 도메인에서 81페이지를 30일간 추적한 실험에서는 ChatGPT 검색의 인용 커버리지가 최대 42%였고, Google AI Mode는 첫 주 59%에서 30일째 26%까지 떨어졌으며, 품질이 같아도 구조에 따라 인용되는 페이지와 되지 않는 페이지로 갈렸습니다. 글 수를 늘리기 전에 위의 4가지를 한 번 점검합니다.