makeshopが検索・AI検索に出ないとき見る4つ

makeshopが検索・AI検索に出ないとき見る4つ
Tips 10分で読める 日本ECプラットフォーム別 検索・AI検索ガイド
- makeshopはクリエイターモードの商品詳細ページでJSON-LDを自動出力します。そこに独自の構造化データを足すと二重出力になり、ブログの置き場所やサイトマップ、記事の構造でも検索とAI検索の見え方が変わりま...
- URL
- searchos.io/ja/blog
- Copyright
- © 2026 Search OS
makeshopのショップから寄せられる相談は、大きく2つに分かれます。商品ページにJSON-LDを追加したらリッチリザルトテストでProductが2つ検出されてエラーになった、というものと、ブログを毎週更新しているのにChatGPTやGoogle AI Modeで自社の名前が出てこない、というものです。前者は構造化データの二重出力、後者はブログ運用(標準機能またはWordPress連携)とショップのつながり方の問題です。
どちらも、makeshopの機能が妨げているわけではありません。標準出力の中身を確認せずに足している、ブログの置き場所とサイトマップを決めきれていない、記事が商品につながる形になっていない、という運営側の確認不足に原因が集まります。この記事では、先に見る4点を順に整理します。数値や仕様は、各テーマの個別記事に書いたものだけを使います。
1. 商品ページの構造化データが二重に出ていないか
makeshopは、クリエイターモードの商品詳細ページでJSON-LDを標準で出力します。そこにクリエイターモードで独自のJSON-LDを追記すると、同じページに同じ型が二重に出ます。検証ツールはどちらが正かを判断できないためエラーや警告を出し、エラーがあるとブロック全体が無視されることもあり、追加する前より悪い結果になりかねません。同じ型が2つあるページは、1つもないページより扱いにくいので、追加する前に引き算から始めます。
確認は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. ブログとショップが、1つのサイトとして読まれる状態か
配置がどれでも、ブログとショップを1つのサイトとして扱ってもらうための要件は同じです。WordPress側の記事がmakeshopのサイトマップに含まれるかは連携の仕様しだいなので、含まれない前提で別途Search Consoleに登録します。
項目 | 内容 |
|---|---|
記事 → 商品の内部リンク | 本文中と末尾に、該当商品・カテゴリへのリンク |
商品 → 記事の内部リンク | 商品説明の末尾に「選び方はこちら」 |
ヘッダー・フッターの共有 | 同じナビゲーションで、ブログとショップが1つのサイトに見える状態 |
サイトマップ | 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項目のうち、最後の1つだけはmakeshopの管理画面からは見えません。ボットが記事を取得できているかは、ログでしか分からないからです。JSON-LDの自動出力はクリエイターモードの商品詳細ページが対象なので、記事側のArticle・BreadcrumbListは自分でリッチリザルトテストにかけて検証します。記事をすべて書き直す必要はなく、商品に近い上位10〜20記事に絞って、先頭の答え段落と内部リンクを足すところから始めます。
Search OSは、追加したものが今日も正しいかを見続ける層です
Search OSは、makeshopを含む既存のショップに対して、構造化データの出力状態を継続的に検証します。二重出力、画面との不一致、テンプレート変更後の破損を検出して修正対象に整理し、ボットログで検索エンジンとAIクローラーが実際にページを取得しているかを確認します。makeshopとWordPressのように複数の仕組みで構成されたサイトでは、メタデータ・構造化データ・サイトマップ・canonicalを別の層として一体で提供し、内部リンク切れや重複を修正対象に整理します。追加する作業を代行するのでも、ブログを置き換えるのでもありません。
担当者が先に見る質問
商品ページをリッチリザルトテストにかけたとき、Productは1つだけ検出されるか
ページのソースで application/ld+json は何か所に出るか。それぞれ標準テンプレートと追記のどちらから来ているか
標準出力のProductの価格・在庫・商品名は、画面の表示と一致しているか
ブログはショップと同じドメインの配下にあるか。別ドメインなら、内部リンクは密か
WordPress側のサイトマップは、makeshopのサイトマップとは別にSearch Consoleへ登録されているか
商品に近い上位10記事の最初のH2直下に、質問への答えがあるか
テンプレートを変えた日と、最後に再検証した日は、どちらが新しいか
結論
makeshopの標準出力は商品ページの出発点として十分で、足す前に引く、というのが構造化データの原則です。ブログは配下に置き、サイトマップを別途登録し、記事を商品につながる答えにします。高権威ドメインで81ページを30日間追跡した実験では、ChatGPT検索の引用カバレッジは最大でも42%、Google AI Modeは初週59%から30日目に26%まで下がり、品質が同じでも構造によって引用されるページとされないページに分かれました。記事数を増やす前に、上の4点を一度通します。