EC-CUBE SEOプラグインはどこまで頼れるか
EC-CUBEにSEOプラグインを入れているショップから、これで十分なのか、構造化データは自分たちで実装したほうがよいのか、という相談が寄せられます。構造化データは、ページの内容を機械が読める形で書いておく記述です。
EC-CUBEを使う中堅ECの開発担当者から、よく受ける質問です。答えは、範囲によって変わります。メタタグ・OGP・サイトマップの範囲なら、プラグインは十分に頼れます。構造化データは少し違います。「プラグインか自前か」の二択より前に、「出力が正しいことを継続的に確かめる仕組みがあるか」が判断の中心です。仕組みがなければ、どちらで実装しても同じ失敗を繰り返します。
この記事では、プラグインが扱う範囲と、プラグイン依存で起きる失敗を整理します。自前実装を選ぶ判断基準と、検証を続ける運用もまとめます。EC-CUBEは、バージョンによってプラグインの対応状況が異なります。使用中のバージョンで、必ず確認してください。
結論: メタ・サイトマップはプラグインで十分。構造化データは「検証の仕組み」が先
領域 | プラグインに任せる | 自前で持つ | 判断の軸 |
|---|---|---|---|
title・meta description・OGP | ◎ | 不要 | 商品ごとに固有の値を入れられるか |
sitemap.xml | △ | 4系は標準でXMLサイトマップを持たない。プラグインか自前生成が必須 | 分割・lastmodの精度、更新時の互換性 |
canonical | ○ | 規格・絞り込みURLが多いなら自前 | 重複URLの構造 |
構造化データ(Product/Offer) | △ | 価格・在庫・規格が動的なら自前 | 商品データとの同期 |
構造化データ(Article/BreadcrumbList) | △ | テンプレートで持つほうが安定 | コンテンツページの有無 |
出力の検証 | × | 必須 | プラグインは検証しない |
表の最後の行が本題です。プラグインは出力しますが、出力が正しいかを確かめ続ける機能は持ちません。EC-CUBE本体やプラグインの更新、テンプレートの変更で構造化データが壊れても、誰も気づかない。これがいちばん多い失敗です。
重要な考え方: 無効な構造化データは、無い状態より悪い場合があります。エラーがあると、ブロック全体が無視されます。「入れたつもり」が「何も入っていない」より扱いにくい結果を招きます。検証の仕組みがあるかどうかを、先に確かめてください。
プラグインが担う範囲
EC-CUBEのSEO系プラグインは、一般に次を提供します。使用中のプラグインで確認してください。
ページ種別ごとのtitle・meta descriptionのテンプレート設定
OGPタグ
sitemap.xmlの生成(EC-CUBE 4系は2系にあったsitemap.phpが無くなり、標準ではXMLサイトマップを出力しません。サイトマップはプラグインか自前実装が前提です)
一部プラグインでの構造化データ出力
これらは、「EC-CUBEの標準テンプレートに沿った商品構造」を前提に設計されています。標準から外れるほど、プラグインの出力と実際のページ内容がずれます。
ずれやすいのは、次の3点です。
規格(サイズ・色)ごとに価格や在庫が異なる商品。 どの規格の価格・在庫を構造化データに書くかは、プラグインの実装しだいです。
カスタマイズしたテンプレート。 見出し構造や商品情報の位置を変えると、プラグインの想定と食い違います。
本体・プラグインの更新。 更新後に出力が変わっても、検証しなければ気づけません。更新の直後に出力を確認してください。
プラグイン任せで起きる失敗
失敗 | 起きる状況 | 検知の難しさ |
|---|---|---|
構造化データの価格が画面と違う | セール価格・規格別価格 | 画面上は正常なので気づけない |
在庫ありの商品が構造化データで在庫なし | 規格別在庫、予約商品 | AIの推薦候補から静かに外れる |
更新後に構造化データが出力されなくなる | 本体・プラグイン・テンプレート更新 | リッチリザルトが消えて初めて気づく |
同じ商品に複数のJSON-LDブロック | プラグインとテンプレートの二重出力 | 検証ツールで警告が出る |
WordPressのプラグイン環境でも、同じ型の失敗が繰り返し報告されています。プラグイン同士の競合やテーマ更新で、構造化データが無効になる問題です。EC-CUBEも構造は同じです。表の失敗が自分のサイトで起きていないか、商品ページをひとつ検証してください。
自前で持つかどうかの判断基準
次のうち2つ以上に当てはまるなら、構造化データはテンプレート側で自前実装します。プラグインの出力は止めるほうが安定します。
規格ごとに価格・在庫が変わる商品が全体の3割以上ある
テンプレートを標準から大きくカスタマイズしている
コンテンツページ(特集・読み物)があり、Articleを出したい
本体・プラグインの更新を年に複数回行う
過去に構造化データが壊れた経験がある
当てはまるのが1つ以下なら、プラグインの出力を使い続けて問題ありません。ただし、どちらの場合も検証の仕組みは要ります。サイズ・色ごとに在庫が動くアパレルのような商材は、自前寄りの判断になります。上の項目に印を付けて、数えてみてください。
検証を続ける運用
構造化データの正しさは、実装した日ではなく、今日の状態で決まります。最低限、次を運用に組み込んでください。
頻度 | 作業 | 方法 |
|---|---|---|
更新のたび | 商品・カテゴリ・コンテンツページを1つずつ検証 | リッチリザルトテスト |
週次 | 構造化データの価格・在庫と画面表示の一致を抽出確認 | 対象URLをサンプリング |
月次 | Search Consoleの拡張レポートでエラー・警告数を確認 | 商品・パンくずの項目 |
常時 | ボットが商品ページを取得できているか | サーバーログまたはボットログ |
商品数が数百までは、手作業で回ります。数千を超え、規格が多く、更新頻度が高いサイトでは、この運用自体が負担になります。自分のサイトの商品数と更新頻度で、手作業を続けられるかを見積もってください。
「プラグインか自前か」の外側に、答えがあります
EC-CUBEのように、サイトごとにカスタマイズの度合いが違う環境では、構造化データを「入れる」方法より「一致を保つ」方法のほうが結果を左右します。
データポイント: 年商400億ウォン(約40億円)規模の韓国ECブランドでは、原本のコードを変えずに別レンダリング層で基盤を整え、3か月でOrganic購入売上を約9,206万ウォンから約1.66億ウォン(+80%)に伸ばしました。(事例記事)
Search OSは、EC-CUBE本体やプラグインを変えません。検索エンジンとAIクローラー向けのメタデータ・構造化データ・canonical・サイトマップを、別の層として提供します。可視テキストとの一致を、継続的に検証します。ボットログで、GooglebotやGPTBotが商品ページを実際に取得できているかも確認します。壊れた出力、欠けているArticle、取得に失敗しているURLを、修正対象として整理します。本体更新のたびに検証し直す負担を、運用の層に移せるかどうかが分かれ目です。
よくある質問
プラグインと自前実装を併用しても問題ありませんか
同じページに同じ型のJSON-LDが二重に出ると、検証ツールで警告が出ます。どちらが正しいのかが、あいまいになります。併用するなら型ごとに担当を分け、重複しないようにしてください。
構造化データを入れればAI検索に引用されますか
引用の前提条件の1つですが、それだけでは足りません。可視テキストとの一致、質問に直接答える本文、ボットが取得できる状態。この3つが揃って、初めて候補になります。
EC-CUBE 2系のサイトでも同じ考え方ですか
考え方は同じですが、プラグインの対応状況が大きく異なります。まず使用中のバージョンで、利用できるプラグインを確認してください。テンプレートでの追記可否も、あわせて見ておきます。
あわせて読みたい
参考資料
Google Search Central: Product structured data
Google Search Central: General structured data guidelines
Google Search Central: Rich result status reports
EC-CUBE: 公式サイト