EC-CUBEが検索に出ないとき、まず見る5つ

EC-CUBE 2系で10年運営してきたサイトを4系に移行したところ、検索順位が広く落ちた。EC-CUBE 4でサイトを作り、Search Consoleにサイトマップを登録しようとしたら /sitemap.xml が404になる。SEOプラグインを入れているが、これで十分なのか、構造化データは自分たちで実装したほうがよいのか分からない。制作会社に「SEOも考慮してほしい」と伝えて「対応します」と返ってきたが、その一言に何が含まれるのかが見えない。EC-CUBEを使うショップから届く相談は、この4つに集中しています。

共通するのは、EC-CUBEが「自分で用意する」前提のカートだという点です。ASPカートの多くが自動で作るサイトマップも、EC-CUBE 4系では標準にありません。構造化データはプラグインかテンプレートで出しますが、出力が正しいかを確かめ続ける機能は持ちません。この記事では、個別の記事で整理してきた内容を「まず見る5つ」の順番にまとめ直します。数値と手順は各記事のものをそのまま使い、詳しい作業は記事末尾のリンク先に譲ります。

1. 2系から4系への移行なら、「サイト移転」として4資産の引き継ぎ表を確かめる

2系から4系への移行は、バージョンアップではなくサイト移転です。URL構造が変わり、テンプレートも作り直しになります。2系で使っていたプラグインやカスタマイズは、4系では動きません。10年分の評価は旧URLにたまっているため、新URLへ引き継がなければ失われます。同じEC-CUBEだから引き継がれるものは、商品データだけです。検索エンジンから見たサイトはURLとHTMLの集合で、それはすべて作り直されます。

引き継ぎ表ができるまで、切り替えは待ちます。移行前に、検索流入のあるURL数、主力ページの順位、構造化データの型を記録しておきます。移行1週間後に旧URLの404とリダイレクトエラーがほぼないこと、主力ページのURL検査で新URLが索引済みでcanonicalが新URLになっていること、1か月後にサイトマップの検出数が商品数と近いこと、1〜3か月後に検索流入が移行前の水準に戻ることを順に見ます。移行と同時にドメインも変えると原因の切り分けが難しくなるため、バージョン移行を先に行い、安定してからドメインを変えます。

2. /sitemap.xml が404なら、プラグイン・自作・外部生成の3択から選ぶ

EC-CUBE 4系は、XMLサイトマップを標準では作りません。2系にあったsitemap.phpが4系ではなくなったため、移行で「なくなった」と感じるショップが多くあります。ASPカートの多くは自動で作りますが、EC-CUBEでは自分で用意します。選択肢は、プラグインを入れる、自作する、外部ツールで生成する、の3つで、どれを選ぶかは商品数、更新頻度、開発体制で決まります。

商品1万点未満ならプラグイン、それ以上か要件が特殊なら自作、外部生成は一時しのぎです。プラグインを選ぶなら、使っているバージョン(4.0/4.1/4.2/4.3)への対応と最終更新日を確かめます。対応バージョンが古いプラグインは、EC-CUBE本体のアップデートで動かなくなることがあります。用意したあとは、URL数が公開中の商品数・カテゴリ数と近いか、非公開・販売終了の商品が含まれていないか、lastmodが商品ごとに異なる値になっているか、Search Consoleで「成功しました」になるか、robots.txtに Sitemap: 行があるかを見ます。プラグインと自作を併用すると、同じURLを別のlastmodで伝えて矛盾するため、1つに絞ります。

3. SEOプラグインの構造化データは、出力の有無ではなく「今日も正しいか」を見る

EC-CUBEのSEOプラグインは、メタタグ・OGP・サイトマップの範囲なら十分に頼れます。構造化データは少し違います。プラグインは出力しますが、出力が正しいかを確かめ続ける機能は持ちません。EC-CUBE本体やプラグインの更新、テンプレートの変更で構造化データが壊れても、誰も気づかない。これがいちばん多い失敗です。無効な構造化データは、無い状態より悪い場合があります。エラーがあると、ブロック全体が無視されます。

プラグインの出力は「EC-CUBEの標準テンプレートに沿った商品構造」を前提に設計されています。そのため、規格(サイズ・色)ごとに価格や在庫が異なる商品、カスタマイズしたテンプレート、本体・プラグインの更新の3点でずれやすくなります。表の失敗が自分のサイトで起きていないか、商品ページをひとつリッチリザルトテストにかけるところから始めます。

4. 構造化データを自前で持つかどうかは、5つの条件を数えて決める

「プラグインか自前か」の二択より前に、「出力が正しいことを継続的に確かめる仕組みがあるか」が判断の中心です。仕組みがなければ、どちらで実装しても同じ失敗を繰り返します。そのうえで、次のうち2つ以上に当てはまるなら、構造化データはテンプレート側で自前実装し、プラグインの出力は止めます。

• 規格ごとに価格・在庫が変わる商品が全体の3割以上ある

• テンプレートを標準から大きくカスタマイズしている

• コンテンツページ(特集・読み物)があり、Articleを出したい

• 本体・プラグインの更新を年に複数回行う

• 過去に構造化データが壊れた経験がある

当てはまるのが1つ以下なら、プラグインの出力を使い続けて問題ありません。ただし、どちらの場合も検証の仕組みは要ります。更新のたびに商品・カテゴリ・コンテンツページを1つずつリッチリザルトテストにかけ、週次で構造化データの価格・在庫と画面表示の一致を抽出確認し、月次でSearch Consoleの拡張レポートのエラー・警告数を見ます。ボットが商品ページを取得できているかは、サーバーログまたはボットログで常時確認します。商品数が数百までは手作業で回りますが、数千を超え、規格が多く、更新頻度が高いサイトでは、この運用自体が負担になります。

5. 制作会社に頼むなら、6領域の要件書を構築前に渡し、納品時に同じ表で検収する

制作会社にとってSEOは範囲があいまいな言葉で、titleを設定できる状態にしただけで「対応済み」になることもあります。項目ごとに「何を」「どこに」「どう確認するか」を書いた要件書があれば、見積もりに入っているかがはっきりし、納品のときも同じ表で検収できます。書かれていないものは含まれない、が前提です。

要件のうち、EC-CUBEで特に落ちやすいものは4つです。XMLサイトマップの自動生成は、EC-CUBE 4に標準がないため明記します。構造化データは、プラグインとテンプレートで同じ型を二重に出さないこととし、ソースで ld+json の数を確認します。商品名・価格・説明・構造化データは、JavaScriptなしでHTMLに含めます。robots.txtでは管理画面・カート・マイページをDisallowにし、AIクローラー(GPTBot等)の扱いを方針として決めて記載します。要件書の末尾には「上記の各項目は、納品時に右列の方法で検収します。対応しない項目がある場合は、見積もり段階で明記してください」の一文を添えます。要件書を渡して見積もりが上がるのは正常で、入っていなかった項目が見えるようになっただけです。

Search OSは、移行と納品のあとに崩れる状態を見続ける層です

要件書で担保できるのは納品時の状態まで、引き継ぎ表で担保できるのは切り替え時の状態までです。その後にプラグインを追加し、本体をアップデートし、キャンペーンページを増やすたびに、リダイレクトの漏れ、再実装した構造化データのずれ、サイトマップの生成停止が後から見つかります。Search OSは、EC-CUBE本体やプラグインを変えません。検索エンジンとAIクローラー向けのメタデータ・構造化データ・canonical・サイトマップを別の層として提供し、可視テキストとの一致を継続的に検証します。ボットログで、GooglebotやGPTBotが商品ページを実際に取得できているかも確認し、壊れた出力、欠けているArticle、取得に失敗しているURL、移行で失われたメタデータを修正対象として整理します。移行の作業や制作会社の作業を置き換えるものではなく、納品後に見落とされた穴を見つけ続ける層です。

担当者が先に見る質問

• 2系から4系への移行なら、旧URLと新URLの1対1の対応表と301リダイレクトはあるか

• 移行前の主力ページのtitle・description・構造化データの型を、比較できる形で記録してあるか

• /sitemap.xml は開くか。URL数は公開中の商品数と近く、lastmodは商品ごとに異なる値になっているか

• サイトマップのプラグインは、使っているEC-CUBEのバージョンに対応し、更新が続いているか

• 商品ページをリッチリザルトテストにかけたとき、価格・在庫は画面表示と一致しているか

• 同じページに、同じ型のJSON-LDが二重に出ていないか

• 制作会社との保守契約に「SEO要件の維持」は入っているか。納品後に誰が見続けるかは決まっているか

結論

EC-CUBEのショップが検索に出ないときは、移行・サイトマップ・構造化データ・要件書の4つの入口のどこで抜けているかを先に決めます。移行なら4資産の引き継ぎ表、サイトマップなら3択のどれかと用意したあとの確認、構造化データなら「今日も正しいか」の検証、制作会社への依頼なら6領域の要件書です。どれもEC-CUBEでは「言わなければ入らない」「用意しなければ無い」項目で、一度そろえても本体とプラグインの更新で崩れます。ここまでが設定の話で、その先は更新のたびに同じ状態を保ち続ける運用の話です。

あわせて読みたい

• EC-CUBE 2系から4系への移行で失われるSEO資産: URL・メタ・構造化データの引き継ぎ

• EC-CUBE 4にはXMLサイトマップが標準でない: プラグイン・自作・外部生成の3択

• EC-CUBEのSEOプラグインはどこまで頼れるか: 構造化データを自前で持つ判断基準

• EC-CUBEの制作会社にSEO・AI検索の要件を伝えるための要件書テンプレート

参考資料

• Google Search Central: Site moves with URL changes

• Google Search Central: Redirects and Google Search

• Google Search Central: Build and submit a sitemap

• Google Search Central: Product structured data

• Google Search Central: Rich result status reports

• Google Search Central: Ecommerce best practices