ECプラットフォームのSEO
Shopify、WooCommerce、Magento、BigCommerce、Salesforce Commerce Cloud、Shopware、OpenCart、Ecwid、Wix、Squarespace、PrestaShopのSEO。各プラットフォームが自動処理する項目、制約、自然検索に影響する固有の注意点を解説します。
このページには証拠シグナルが1件あります
- 関連するライブツールFaceted Navigation Auditor
どのECプラットフォームも、商品を一つ登録する前からストアのSEOに関わる判断を行います。ShopifyはURL構造を固定する一方、canonicalとサイトマップを自動処理します。WordPress上のWooCommerceはプラグインで細かく制御できます。Magentoは柔軟ですが、多くのSEO設定に開発作業が必要です。BigCommerceはShopifyより柔軟で、Magentoほど開発負担が大きくありません。ただし、プラットフォーム自体に順位上の優位性はありません。商品、カテゴリ、バリエーション、フィード、多言語対応、運用要件に基づいて選び、実装が実際に出力する内容を検証してください。
この主張の根拠 Regardless of platform, Google needs crawlable product links and consistent product data. 対象範囲: Search-engine requirements independent of platform. 信頼度: 高 · 検証日: Google Search Central: Ecommerce site structure この主張の根拠 Platform automation varies; Shopify, for example, automatically generates canonical tags and sitemap files but still exposes merchant-controlled SEO fields. 対象範囲: Shopify-specific example, not a search-engine rule. 信頼度: 高 · 検証日: Shopify Help: SEO overview要点 — ECプラットフォームはHTTPS、サイトマップ、canonicalタグなど、一部のSEOを自動処理します。しかし、各製品固有の仕様を知らないと問題になります。代表例は、複数コレクションに属する商品から生じる重複URL(Shopify)、内容の薄いカテゴリページ(全製品)、インデックスさせたくない大量のパラメータURLを生むファセットナビゲーションです。順位において本質的に優れたプラットフォームはありません。商品、カテゴリ、バリエーション、運用要件に合うものを選び、実際の出力を検証してください。
ECプラットフォームのSEOが異なる理由
一般的なサイトにはページがあります。ECストアにはページに加えて、商品、カテゴリ、バリエーション、コレクション、フィルタ、ページネーションがあります。それぞれがURLを生成しますが、すべてをインデックスさせるべきではありません。
ここで扱うプラットフォームは、標準の処理方法が異なります。
- Shopify — URL構造(
/products/、/collections/)を固定し、重複するコレクション内の商品URLを自動でcanonical化し、サイトマップを生成します。標準プランではrobots.txtの編集が制限されます。 - WooCommerce — WordPress上で動くため、YoastやRank MathなどのSEOプラグインで細かく制御できます。柔軟な分、設定項目も増えます。
- Magento(Adobe Commerce) — 大規模向けで高い設定自由度がありますが、多くのSEO設定に開発者の関与が必要です。
- BigCommerce — Shopifyより柔軟で、Magentoより開発負担が小さく、標準のSEO設定も堅実です。
以下では主にこの4製品を比較します。ページ下部の詳細ガイドでは、Salesforce Commerce Cloud、Shopware、OpenCart、Ecwid、Wix eCommerce、Squarespace Commerce、PrestaShopも扱います。
EC特有のSEO課題
プラットフォームを問わず、すべてのECストアに次の課題があります。
商品の構造化データ — 価格、在庫状況、レビューを含むSchema.orgのProductマークアップによって、Googleの拡張表示の対象になれる場合があります。表示は保証されません。自動で挿入する製品もあれば、プラグインやテーマが必要な製品もあります。宣伝文句ではなく、実際のページ出力を確認してください。
ファセットナビゲーション — フィルタパラメータ(?color=red&size=M)は、内容がほぼ同じURLを何千件も作ることがあります。多くはインデックス対象外にするか、基点となるカテゴリページへcanonical化する必要があります。
バリエーションによる重複URL — サイズや色が10通りある商品を、10ページすべてインデックスさせる必要はありません。canonicalタグやパラメータ処理で重複を抑えます。
在庫切れ・販売終了商品 — 商品がなくなったときに404、カテゴリへの301、在庫状況の構造化データを付けて維持、のどれを使うかは、リンク評価とユーザー体験に直接影響します。
ページネーション — カテゴリ一覧は複数ページに分かれます。/collections/shoes/の2ページ目は1ページ目より内容が薄くなりがちで、処理方法はプラットフォームによって異なります。
この主張の根拠 Regardless of platform, Google needs crawlable product links and consistent product data. 対象範囲: Search-engine requirements independent of platform. 信頼度: 高 · 検証日: Google Search Central: Ecommerce site structure この主張の根拠 Platform automation varies; Shopify, for example, automatically generates canonical tags and sitemap files but still exposes merchant-controlled SEO fields. 対象範囲: Shopify-specific example, not a search-engine rule. 信頼度: 高 · 検証日: Shopify Help: SEO overview要点 — 大規模なECサイトでは、大量URLのcanonical処理、構造化データの網羅性、自動または手動設定、robots.txtとサイトマップの制御性、ファセットナビゲーションの方針が重要です。Shopifyは標準仕様の主張が最も強く、WooCommerceは制御範囲が広く、Magentoは強力ですが設定コストも高くなります。これは順位上の優位性ではなく、設定作業を誰が担うかの違いです。Googleが評価するのはCMS名ではなく、実装が生成するページ、リンク、データです。
プラットフォームの選定方法
機能一覧や「SEOに最適」という順位表ではなく、ストアの実要件に照らして選びます。検索順位において本質的に優れたECプラットフォームはありません。アーキテクチャは実装可能な範囲を決めますが、成果を決めるのは個々の実装のクロール可能性、構造化データの正確性、レンダリング結果、速度、コンテンツ、継続運用です。比較前に次を確認してください。
- 商品データ — 商品、価格、在庫、レビューのデータがページへどう届き、自動、テーマ依存、プラグイン/モジュール依存のどれか。
- カテゴリとファセットの構造 — ナビゲーションからカテゴリ、商品へクロール可能なリンクがあり、絞り込みURLをどう処理するか。
- バリエーション構造 — 商品ごとに1つのcanonical URL、バリエーションごとの個別URL、または両方を扱えるか。
- 多言語対応とフィード — 複数地域・言語への対応と、商品フィードからストアへの同期方法。
- 公開とリリース工程 — テンプレート、robots.txt、リダイレクトを誰がどの速さで変更できるか。
- 運用責任 — 商品ライフサイクル、カテゴリ管理、リダイレクト、サイトマップの鮮度、リリーステスト、障害対応を誰が担当するか。
制御権の分布は、ホスト型製品、プラグイン、テーマ、モジュール、独自コードで異なります。設定自由度が高いほど実装と保守の責任が増えるのであって、SEO能力が本質的に高まるわけではありません。機能を説明するときは、ベンダー、エディション、プラン、テーマ、アプリ/モジュール、バージョン、確認日を明記してください。標準仕様は変わり、プランやアプリで上書きされます。
プラットフォーム比較
| 項目 | Shopify | WooCommerce | Magento | BigCommerce |
|---|---|---|---|---|
| URL構造 | 固定(/products/、/collections/) | WordPressで設定可能 | 高い設定自由度 | 一部設定可能 |
| robots.txt | 標準プランでは固定 | 完全に制御可能 | 完全に制御可能 | 一部制御可能 |
| サイトマップ | 自動生成 | プラグイン(Yoast/Rank Math) | 標準搭載・設定可能 | 自動生成 |
| 商品スキーマ | テーマ依存 | プラグイン | モジュール | 標準搭載(基本機能) |
| ファセットナビゲーション | URLパラメータ。処理が必要 | プラグインまたは独自実装 | 標準のレイヤードナビ設定 | 標準ファセット。設定可能 |
| canonicalタグ | 自動(コレクション→商品URL) | プラグイン | 標準搭載 | 標準搭載 |
| リダイレクト管理 | 標準マネージャー | プラグイン(Redirection) | 標準搭載・設定可能 | 標準搭載 |
| 開発者の必要度 | 低 | 低〜中 | 高 | 中 |
バリエーション構造: 1つのURLか複数か
Googleの商品構造化データは、バリエーションについて複数の方法を文書化しており、必須のURL数は1つではありません。すべての色・サイズを1つのcanonical商品URLに置き、ProductGroupデータで表現する方法も、バリエーションごとにURLを作り、グループとして結び付ける方法もあります。どちらも文書化された設計ですが、内部リンク先、グループの宣言方法、各バリエーションページの要件が異なります。プラットフォームと商品点数が適切に支えられる方法を選び、公開マークアップが選択した設計と一致することを確認してください。テーマやアプリの出力が標準設定どおりとは限りません。
コレクション/商品の重複URL問題
代表的なcanonical問題は、同じ商品へ複数URLから到達できることです。
-
Shopify:
/products/blue-shirtと/collections/summer/products/blue-shirt。Shopifyはコレクション側を/products/へ自動でcanonical化します。標準で正しく動きますが、内部リンクは/products/だけを指すべきです。 -
WooCommerce: カテゴリ基点でも同様です(例:
/product-category/shirts/blue-shirtと/shop/blue-shirt)。YoastまたはRank Mathがcanonicalを設定します。重複を減らすようパーマリンク構造を確認してください。 -
Magento: レイヤードナビゲーションのフィルタが重複URLの主因です。絞り込みページのcanonicalを設定するか、robots.txtでパラメータをブロックします。
-
BigCommerce: 商品URLが複数カテゴリ配下に現れることがあります。商品ごとの「Canonical URL」設定で優先パスを制御します。
プラットフォーム別のファセットナビゲーション処理
製品の仕組みより先に検索意図を決めます。インデックス可能な独立ランディングページに値する絞り込みと、クロール対象を増やすだけの組み合わせを分けてください。Googleの案内は、ファセットURLのクロールをブロックするか、インデックス価値のあるURLを最適化するかという選択として整理されています。どちらでもURL数は膨らみ得るため、方針を決めてから製品の機能へ割り当てます。
- Shopify: 一部テーマではクエリパラメータ(
?filter.p.m.color=red)が標準でインデックスされます。絞り込みページにrobotsメタnoindexを使うか、Search ConsoleのURLパラメータツールへ追加します。 - WooCommerce: WOOCSやフィルタ系プラグインがパラメータURLを生成します。絞り込みページの
noindexとRank Math/YoastのURLパラメータ設定を組み合わせます。 - Magento(Adobe Commerce): 標準の「Layered Navigation」はカタログ属性からフィルタURLを生成します。カタログ権限とURL書き換えで細かく制御でき、カテゴリ単位でcanonicalを設定できます。別ライセンスのLive Searchは独自のファセットを使用し、標準機能とは挙動が異なります。「Magento」という名称だけで判断せず、エディションと追加機能を含め、どちらが設定されているか確認してください。
- BigCommerce: Store Settings → Searchの標準設定で、ファセット検索URLを基点カテゴリへcanonical化できます。
ECプラットフォームのSEOには、通常のテクニカルSEOに加えて、商品の構造化データ、ファセットナビゲーションのパラメータ処理、商品バリエーションやコレクションによる重複URL、在庫切れ商品の方針、ページネーションという複雑さがあります。順位において本質的に優れた製品はありません。商品、カテゴリ、バリエーション、フィード、多言語、公開、運用要件で選び、テーマ、アプリ、モジュール、プラン、バージョンを含む実装の出力を確認してください。
Shopify: URL構造(/products/、/collections/、/pages/、/blogs/)は固定です。サイトマップとcanonicalを自動生成し、コレクション経由の商品重複URLも自動canonical化します。標準プランではrobots.txtが固定され、Shopify Plusではカスタマイズできます。商品スキーマはテーマ依存です。
WooCommerce: WordPressベースで、SEOプラグインによる完全な制御が可能です。Yoast SEOやRank Mathがメタデータ、サイトマップ、canonical、リダイレクト、スキーマを扱います。4製品中で最も柔軟ですが、設定も多く必要です。商品URL構造はWordPressのパーマリンク設定に依存します。
Magento(Adobe Commerce): 大規模向けの柔軟性があり、URL書き換え、canonical、レイヤードナビゲーション設定を標準搭載します。多くのSEO設定に開発者または管理画面での作業が必要です。大規模運用に強い一方、初期設定の負担は大きくなります。
BigCommerce: Shopifyの使いやすさとMagentoの機能性の中間です。自動サイトマップ、canonical、リダイレクト管理、基本的な構造化データを備え、URL構造も一部変更できます。ファセット検索はStore Settingsで設定できます。
全製品に共通するのは、商品の構造化データ、フィルタ/バリエーションURLのcanonical、サイトマップでの商品・カテゴリ網羅、販売終了商品のリダイレクトです。コレクション内の商品重複では、/products/slugと/collections/name/products/slugの両方が存在し得るため、canonicalと内部リンク先を確認します。バリエーションには、ProductGroupを使う1つのcanonical商品URLと、グループ化した個別URLという複数の文書化済み設計があります。ファセット方針は検索上の独立価値から決め、製品機能へ割り当てます。Adobe Commerceの標準レイヤードナビゲーションと別ライセンスのLive Searchでは挙動が異なるため、利用構成を明示してください。
ECプラットフォームSEO監査チェックリスト
全プラットフォーム
- XMLサイトマップにすべての商品とカテゴリが含まれ、フィルタ/パラメータURLが除外されている
- すべての商品・カテゴリページにcanonicalタグがある
- ファセットナビゲーションURLがブロック、noindex、またはcanonical化されている
- 商品構造化データに価格、在庫状況、レビューが含まれる
- 販売終了やslug変更を含む商品URL変更にリダイレクトを設定する
- 2ページ目以降をインデックスする価値と固有性があるか確認する
- 在庫切れ商品を404、維持・更新、リダイレクトのどれで処理するか確認する
Shopify固有
- 内部商品リンクは
/collections/.../products/ではなく/products/を指す - テーマの商品スキーマ出力をリッチリザルトテストで確認する
- URL変更にはShopifyのリダイレクト管理を使う
- Shopify Plusではrobots.txtを調整し、内容の薄いURLをブロックする
WooCommerce固有
- SEOプラグインはYoastかRank Mathのどちらか1つだけを使う
- WooCommerceの商品パーマリンク構造を設定する
- プラグインの商品スキーマ設定を構成する
- shopやproduct-categoryなど、内容の薄いアーカイブをnoindexにする
Magento固有
- レイヤードナビゲーションURLのcanonicalを設定する
- URL書き換え規則を確認し、不要な重複を除く
- クロール不要なパラメータURLをrobots.txtでブロックする
- Magento標準のHTMLサイトマップとXMLサイトマップを有効にする
BigCommerce固有
- 商品設定で商品ごとのcanonical URLを指定する
- ファセット検索設定(Store Settings → Search)を確認する
- Search Consoleへのサイトマップ送信を確認する
- URL変更には標準のリダイレクト管理を使う
ECプラットフォームをテストするツール
- ファセットナビゲーション監査 — フィルタの組み合わせがクロール可能またはインデックス可能なURLを生成するか確認します。
- PDP SEOチェッカー — 実際の出力を使い、商品ページのメタデータ、構造化データ、canonical、コンテンツシグナルを確認します。
- XMLサイトマップバリデーター — 公開済みの商品・カテゴリURLが1回だけ現れ、canonicalかつ成功するURLを指すか検証します。
- HTTPステータス/リダイレクトチェッカー — 商品廃止、カテゴリ変更、移行にチェーンや無関係な転送先がないか確認します。
プラットフォーム別の詳細ガイド
- Shopify SEO
- WooCommerce SEO
- Magento SEO
- BigCommerce SEO
- Salesforce Commerce Cloud SEO
- Shopware SEO
- OpenCart SEO
- Ecwid SEO
- Wix eCommerce SEO
- Squarespace Commerce SEO
- PrestaShop SEO(Ecommerce Platformsクラスター内)
関連記事
各プラットフォームで実際に起きる誤り
Shopifyでコレクション接頭辞付きの商品URLへ内部リンクする
内部リンク、ナビゲーション、関連商品が/products/blue-shirtではなく/collections/summer/products/blue-shirtを指す状態です。
問題の理由 — Shopifyは通常、コレクション接頭辞付きURLを商品URLへ自動canonical化するため、インデックス重複は避けられます。しかし長いURLへの各リンクは、最初からcanonicalページを指さず、クロールとリンク評価を別URLに費やします。
代わりに行うこと — コレクションの文脈ではなく商品ハンドルからテーマリンク(/products/{{ product.handle }})を作り、canonical URLへ直接リンクします。
WooCommerceでSEOプラグインを2つ同時に使う
「多いほど安心」と考え、Yoast SEOとRank Mathなどを同時に導入する状態です。
問題の理由 — 両方がサイトマップ、canonical、メタ情報を生成します。同じ項目を複数プラグインが管理すると、canonicalの競合や重複サイトマップが生じます。
代わりに行うこと — 1つを選び、もう一方を完全に無効化し、ページソースにcanonicalとメタディスクリプションが1つずつ出力されることを確認します。
ファセットナビゲーションを完全にクロール・インデックス可能にする
4製品のいずれでも、フィルタ(?color=red&size=M)にnoindex、canonical、robots.txt制御がない状態です。
問題の理由 — 少数の属性でも、内容がほぼ同じパラメータURLが何千件も生成されます。クローラーが商品やカテゴリではなくそれらに時間を使う、代表的なECインデックス問題です。
代わりに行うこと — 絞り込みURLを基点カテゴリへcanonical化するか、広告やUXのためクロール可能にする必要があるならnoindexにします。ブロック方針の前に、Search Consoleで実際に確認されているパラメータを調べます。
リダイレクト計画なしで商品を廃止する
「在庫切れだから」と商品を削除し、URLを404にする状態です。
問題の理由 — URLが得た被リンクと順位履歴が失われ、ユーザーもリンク評価も行き先を失います。
代わりに行うこと — 再入荷するなら在庫切れの構造化データを付けて維持し、戻らないなら最も近い代替商品または親カテゴリへ301し、どこからもリンクされなくなった場合にだけ404を検討します。
商品スキーマが自動だと思い込む
「プラットフォームが処理する」と考え、Schema.orgのProductマークアップを確認しない状態です。
問題の理由 — Shopifyはテーマ依存、WooCommerceはプラグイン、Magentoはモジュールが必要で、BigCommerceの標準機能は基本範囲だけです。価格や在庫データが拡張表示から消えても気付けません。
代わりに行うこと — 宣伝文句ではなく実際の商品ページをリッチリザルトテストで確認し、ページ単位ではなくテーマ/プラグイン側で不足を修正します。
Magentoのレイヤードナビゲーションを未設定のまま使う
色、サイズ、ブランドのファセットを有効にし、生成URLのcanonicalやインデックス規則を設定しない状態です。
問題の理由 — フィルタの組み合わせが急増し、Magentoでは重複URLの最大要因になります。未設定だと商品数よりはるかに多いクロール可能URLを作ります。
代わりに行うこと — カタログが大きくなる前にカテゴリ単位のcanonicalを設定し、クロール不要なパラメータの組み合わせをブロックします。
変更履歴
2026年9月1日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年8月2日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月18日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。