Magento向けSEO

TL;DR — Magento SEOは、Magentoストアを検索で上位表示させるためのものです。 まず、バージョンを確認しましょう。Magento 1はサポート終了（2020年6月以降アップデートなし）、 Magento 2には有料版（Adobe Commerce）と無料版（Magento Open Source）があります。 MagentoのSEOを最も壊すのは、フィルターシステム（「レイヤードナビゲーション」）で、 何千もの重複ページアドレスを生成する可能性があります。作業のほとんどは、それらを管理下に置くことです。

Magentoとは（そして、どのバージョンを使っているか）

Magentoはオンラインストアを構築するためのプラットフォームです。Shopifyのように会社がすべてをホストしてくれるのとは異なり、Magentoは自分（または開発者）がインストールして自分で運用するものです。これにより、多くのコントロールが得られますが、同時に多くの責任も伴います。

何をするにしても、まず自分がどのMagentoを使っているかを確認しましょう。

• Magento 1 — 旧バージョン。2020年6月にサポート終了となり、セキュリティアップデートは提供されていません。もしこちらを使っているなら、本当のSEOプロジェクトはMagento 2への移行です（リダイレクトを設定して慎重に行ってください）。
• Magento 2 — 現在のバージョン。Adobe Commerce（有料のエンタープライズ版）とMagento Open Source（無料のコミュニティ版）があります。コアコードは同じなので、SEOのアドバイスも同じです。
• Adobe Commerce as a Cloud Service (ACCS) — 新しい、別のSaaS製品（2025年6月にローンチ）で、異なるインフラストラクチャ上で動作し、クラシックなLumaテーマをまったくサポートしていません。ストアがACCS上にある場合は、「通常の」Magento向けに書かれたテーマ/スキーマのアドバイスは、直接の一致ではなく、出発点として扱ってください。

これらを混同しないでください。オンラインの古い「Magento SEO」チュートリアルの多くはMagento 1向けに書かれており、メニューや設定がもはや一致しません。

最大の問題：フィルター

買い物客がカテゴリページ（たとえば「ランニングシューズ」）に着くと、Magentoはサイドにフィルター（サイズ、色、ブランド、価格）を表示します。この機能はレイヤードナビゲーションと呼ばれ、買い物客にとっては素晴らしいものです。

SEOの問題は、誰かがクリックした各フィルターが通常、新しいウェブアドレス（/running-shoes?color=blue&size=10など）を生成することです。色×サイズ×ブランド×価格帯を掛け合わせると、単一のカテゴリから何千ものわずかに異なるページが生まれます。これらはすべて基本的に同じ製品を表示しています。検索エンジンはほぼ重複したページの山を見て、どれを表示すべきか混乱し、実際の製品ではなくジャンクをクロールする時間を無駄にします。

修正方法は、検索エンジンに「これらのフィルターページは重要ではない。クリーンなカテゴリページが重要だ」と伝えることです。これには正規タグ（メインバージョンへのポインタ）を使用し、価値の低いフィルターページをnoindex（検索結果に含めない）に設定します。Magentoにはこれらの設定があり、SEO拡張機能を使うと簡単になります。

その他の設定項目

• フレンドリーURL。 Magentoは、長いコードの代わりに/running-shoes/nike-pegasus/のようなクリーンなアドレスを生成できます。「検索エンジンフレンドリーなURL」設定がオンになっていることを確認してください。
• タイトルと説明。 すべての製品とカテゴリには、ページタイトルとメタディスクリプションのフィールドがあります。Magentoのデフォルトのままにせず、入力してください。
• 構造化データ（スキーマ）。 これは、Googleの結果に表示される価格や星評価を支えるコードです。Magentoはこれを自動的に追加しません。そのため、拡張機能や開発者に追加してもらう必要があります。
• 製品バリエーション。 製品に複数のサイズや色がある場合、Magentoは通常、各組み合わせを親にリンクされた独自の「シンプル製品」として保存します。そのままにしておくと、これらが別々のほぼ重複したページとしてインデックスされる可能性があります。代わりに、正規タグで親製品に戻すようにしてください。

詳細で技術的なバージョン（正確な設定、URLリライトテーブル、大規模なフィルターの処理方法）が必要ですか？詳細タブに切り替えてください。

TL;DR — Magento SEOは、2つの重複コンテンツ生成要因に支配されています。 レイヤードナビゲーションがパラメータ付きURLを大量に生成し、設定可能/シンプルな 製品バリアントがほぼ同一のSKUページを大量に生成します。両方をクリーンな親（カテゴリまたは設定可能な製品）に正規化し、価値の低い組み合わせにはnoindexを設定します。検索需要が実際にあるフィルタやバリアントにのみインデックス可能なページを予約します。まずバージョン問題を解決してください — Magento 1はEOL（2020年6月）です。Magento 2はAdobe Commerce（有料、セルフホスト）、Magento Open Source（無料）、またはAdobe Commerce as a Cloud Service（ACCS — 2025年6月以降の別のSaaS製品で、Lumaを完全に廃止）として提供されます。 SEOフレンドリーなURLはurl_rewriteテーブルを通じて処理されます — これはHTTPリダイレクトとは異なり、Magentoは301として自動生成できます。構造化データの出力はストアフロントのテーマや拡張機能によって異なるため、カスタム作業を計画する前にレンダリングされたページを検査してください。

ステップゼロ：バージョンを正確に把握する

オンライン上の悪いMagento SEOアドバイスの半分は、間違ったバージョンを対象にしているため悪いのです。他の何よりも先にこれを確定させてください：

• Magento 1 は 2020年6月30日にサポート終了（EOL） となりました。セキュリティパッチもアップデートもありません。クライアントがまだそれを使用している場合、SEO作業 は Magento 2への移行です — 完全なリダイレクトマップとクロールベースのQAパスを含め、ランキング権威がかかっている他のプラットフォーム移行と同様に扱います。
• Magento 2 は現行のコードベースです。2つのエディションで提供されます：Adobe Commerce（有料；B2B機能、ページビルダー、ホスト型PaaSオプション）と Magento Open Source（無料；コミュニティエディション）。同じコア、同じSEOサーフェス領域です。Adobeのブランディング変更により、「Magento」、「Adobe Commerce」、「Magento Open Source」はすべて同じ基盤プラットフォームに対して表示されます — 名前によってSEOモデルが異なると誤解しないでください。
• Adobe Commerce as a Cloud Service（ACCS） は3番目の別製品です — 2025年6月にローンチされたSaaSデプロイメントで、従来のCommerce/LumaスタックではなくEdge Delivery Services上に構築されたストアフロントを備えています。LumaはACCSではまったくサポートされていないため、ストアがそれを使用している場合、以下のLuma固有のテーマとスキーマのメモは適用されません — そのレイヤーを微調整するのではなく、ゼロから再構築することになります。

以下はすべて、特にACCSが明記されていない限り、セルフホストのMagento 2（Adobe CommerceまたはMagento Open Source、LumaまたはHyvä上）を前提としています。

レイヤードナビゲーションがすべての鍵

Magentoストアで1つだけ修正するなら、レイヤードナビゲーションを修正してください。これはカテゴリページでのファセットフィルタリングを指すMagentoの用語で、デフォルトでは各フィルタ選択がクエリパラメータを追加します：

/running-shoes
/running-shoes?color=159
/running-shoes?color=159&size=42
/running-shoes?color=159&size=42&price=50-100
/running-shoes?size=42&color=159        ← same filters, different order = new URL

クロール/インデックス戦略をストアにコピーする前に1つ明確にしておきます：Adobeは標準レイヤードナビゲーションとLive Search（Adobe Commerceの有料のAI搭載ファセット機能）を、フィルタ/URL動作が異なる別個の実装として文書化しています。以下の正規化とnoindexのガイダンスは標準レイヤードナビゲーション向けに書かれています — ストアがLive Searchを実行している場合、同じルールが適用されると想定する前に、実際に生成されるURLパターンを確認してください。

組み合わせ爆発が問題です。数千SKUのカタログで、クロール可能でほぼ重複したURLが数万件生成される可能性があります。これは標準的なファセットナビゲーションの失敗モードであり、Gary IllyesはこれがGoogleにどれほどの問題を引き起こすかを数値で示しています — ファセットナビゲーションは、彼らが受け取るクロール無駄遣いの苦情の_最大の_単一原因です（Quotesタブを参照）。あなた側の損害：重複/ほぼ重複したコンテンツ、インデックスの肥大化、ジャンクに費やされるクロール予算、カテゴリページあたり数百のフィルタリンクに分散される内部PageRank。

URLパターンごとに決定は二択です：このフィルタリングされたページはインデックスに含める価値があるか、ないか？

含める価値がない約99%の場合（ほとんどの色/サイズ/価格/並び順の組み合わせには検索需要がありません）：

• 正規化 フィルタリングされたURLをクリーンなカテゴリURLに正規化します。Magento 2の 「カテゴリに正規リンクメタタグを使用」設定（ストア → 設定 → カタログ → カタログ → 検索エンジン最適化）は役立ちますが、それだけではカテゴリを それ自体 にポイントするだけで、フィルタリングされたバリアントを親にポイントするわけではありません。そのため、パラメータURLでは通常、SEO拡張機能やテンプレートロジックに頼って適切な正規化を出力します。
• noindex 価値の低いフィルターの組み合わせをインデックスから除外します。 Googleのルールを覚えておいてください：noindex はページがクロール可能であることを要求します。 同じURLで noindex とrobots.txtの Disallow を組み合わせないでください。Googlebotがタグを読み取れなくなります。
• クロール予算が深刻な問題である場合は、純粋に組み合わせ的なパラメータ空間に対して robots.txt の拒否を検討してください。ただし、これはクロールを制御するものであり、インデックスを制御するものではなく、すでにインデックスされたURLを削除しないことを理解してください。

需要がある少数派（例：「/running-shoes/nike/」のようなブランドフィルターが実際のクエリであるページ）については、それらをインデックス可能でクリーンなURLのランディングページに昇格させます — 独自のイントロコピー、自己参照の正規化、内部リンク、 sitemapへの包含。それがMagentoのファセットナビゲーションが負債からロングテールの資産に変わる場所です。（完全な扱いは ファセットナビゲーション ハブにあります。これはEコマース側でのこのトピックの正規のホームです。クロール側のメカニズムは URLパラメータ と クロール予算 にあります。）

URLリライトとSEOフレンドリーなURL

Magentoは URLリライト を通じてクリーンなURLを生成します。これは url_rewrite データベーステーブルに保存され、管理画面の マーケティング → SEO & 検索 → URLリライト で管理されます。Adobe自身のドキュメントは、緩く使われる2つの用語の間に明確な線を引いています：リライト はブラウザのアドレスバーに触れずに読み込まれる内容を変更するサーバー側のマッピングであり、リダイレクト はブラウザに別のURLに移動するよう指示するHTTPレスポンスを送信するものです — アドレスバーが更新されます。MagentoのURLキー変更時の自動301はリダイレクトです。url_rewrite テーブルには、訪問者に表示されない内部リライトも保存されます。ほとんどの作業を行う2つの設定があります：

• 「Webサーバーリライトを使用」（ストア → 設定 → 一般 → Web → 検索 エンジン最適化）はURLから index.php を削除します。
• URLサフィックス / URL内のカテゴリパス。 Magentoは製品URLにカテゴリパスを含めることができます（/men/shoes/nike-pegasus）。意図的に行ってください：カテゴリパスを含めると、複数のカテゴリにある製品が複数のURLで解決され、重複が再作成されます — これがまさにMagentoが製品にも正規化オプションを追加する理由です（「製品に正規リンクメタタグを使用」）。多くのMagento SEO担当者は、これを完全に回避するために製品URLをカテゴリパス_なし_で設定します。

製品またはカテゴリのURLキーを変更すると、Magentoは url_rewrite テーブルに301を自動生成できます（「古いURLに恒久的なリダイレクトを作成」）。一括URL編集の前にそのトグルがオンになっていることを確認してください。そうしないと、インデックスされたURLが404で孤立します。ライブストアでカテゴリパスまたはサフィックスの設定を変更する前に、ストアビューごとの影響を受けるURLパターンを棚卸しし、トグルを切り替えて祈るのではなく、リダイレクト/正規化計画を段階的に準備してください — Adobe自身のドキュメントは、多くの製品が割り当てられたカテゴリのリライトを再生成することが、SEOだけでなく実際のパフォーマンスの低下になり得ると警告しています。

設定可能製品とシンプル製品：もう一つの重複コンテンツの原因

レイヤードナビゲーションだけが、Magentoカタログがほぼ重複したURLを大量に生成する方法ではありません。設定可能な製品（親 — 「ランニングシューズ」）が単純な製品（実際に購入可能なサイズ/色の組み合わせ）から構築される場合、カタログ規模で同じ障害モードが発生します。VervauntのPaul Rogersは、その計算をうまく説明しています。ファッションストアに3 000の親製品があり、それぞれが8サイズ×6色の場合、144 000の単純製品の組み合わせが生成される可能性があります。Magentoでは、これらの組み合わせはカタログの関係であり、インデックス作成の決定ではありません — 明示的な正規化ポリシーがない限り、Googlebotはそれらすべてを、ほぼ同一のコンテンツを指す個別のインデックス可能なURLとして見つけることができます。

実務者ガイドが一致する修正方法は、各単純製品を親の設定可能な製品に正規化し、カタログの表示設定だけに頼らないことです — 「個別に表示しない」に設定された単純製品でも、直接URL、サイトマップ、内部リンクから到達可能であり、サイト内ナビゲーションから隠れていてもGooglebotはインデックスできます。親を指す明示的な正規化タグが実際の修正であり、サーバーサイドでレンダリングされるため、JavaScriptに依存しません。

バリアントを単独でインデックスするのは、独自のコンテンツで差別化できる実際の独立した検索需要がある場合のみです — 名前で検索される特定の色/サイズの組み合わせであり、デフォルトですべてのSKUではありません。

ストア → 設定 → カタログ → カタログ → 検索エンジン最適化で「製品に正規リンクメタタグを使用」がオンになっているか確認し、次に — 設定だけでなく実際にレンダリングされたページで — 単純製品のURLが親への正規タグを保持していることを確認します。

JSON-LDのギャップ

これは、この規模のプラットフォームがスキーマを処理すると想定しているため、人々を悩ませます。Magento 2は、標準ではJSON-LD構造化データを生成しません。 一部のテーマは製品ページでマイクロデータを出力しますが、次の点に注意してください：

• Googleは、マイクロデータ/RDFaよりも実装形式としてJSON-LDを推奨しています（公式ドキュメントタブを参照）。
• 製品リッチリザルトの対象となるには、name、image、description、offers（価格、価格通貨、在庫状況）、そして — 星評価の場合 — 実際のレビューに基づくaggregateRating/reviewを含むProductスキーマが必要です。

したがって、Magentoでリッチリザルトを取得することは、拡張機能またはカスタム開発タスクです：専用の構造化データ拡張機能、スキーマ対応テーマ、またはJSON-LDを出力するテンプレート作業。追加する際は、重複スキーマを監査してください — テーマの残存マイクロデータと拡張機能のJSON-LDの両方が製品を記述している場合、競合する2つのProductブロックを配信する可能性があります。単一の情報源を選択してください。

残りの技術的側面

• 正規化タグ。 カテゴリ/商品以外にも、ホームページ（/ と ?___store= などのストアビューパラメータ）、ページネーション、Magento が追加するストアビュー/ロケールパラメータに注意してください。正規化 と 正規化タグ の詳細を参照してください。
• ページネーション。 Magento はカテゴリを ?p=2 でページ分割します。各ページに一意で自己参照的な正規化タグを設定してください。ページ 2 以降をページ 1 に正規化しないでください。また、シーケンスを noindex にしないでください（ページの奥深くにのみ掲載されている商品へのリンク equity を削る可能性があります）。rel=prev/next は廃止されています。それに依存しないでください。
• ストアビュー（多言語/マルチサイト）。 Magento のストアビューアーキテクチャは国際的な設定に強力ですが、重複コンテンツや欠落/不一致の hreflang の古典的な原因でもあります。1 つのカタログから複数のストアビューを運営する場合、hreflang は手作業であり、部分的な展開は何もしないより悪いです。
• 在庫切れおよび無効化された商品。 ポリシーを決定してください。在庫ステータスでランキングページを維持するか、404/410 + 恒久的に削除された SKU へのリダイレクトを行います。商品を静かに無効化して、インバウンドリンクがある URL を 404 のまま放置しないでください。
• Core Web Vitals。 セルフホスト型 Magento のパフォーマンスは完全にあなたのインフラストラクチャに依存します。フルページキャッシュ（Varnish）、CDN、画像最適化（WebP）、そして規律ある拡張機能/JS の衛生管理がレバーです。ここでは 2 つの異なるヘッドレスパスが混同されることがあるので、どちらを評価しているのか正確にしてください。PWA Studio は Adobe の古い React ベースのストアフロントで、既存の Commerce インフラストラクチャ上にレイヤーされます。一方、Adobe Commerce as a Cloud Service (ACCS) は Edge Delivery Services 上の別の SaaS 製品であり、Luma はまったくサポートされていません。どちらも CWV の上限を引き上げることができますが、両方とも独自のレンダリングとインデックスに関する考慮事項が追加されます。CWV のためのヘッドレス移行を計画する前に、ストアが実際にどちら（またはどちらでもない）を実行しているかを確認してください。

実際に優先すべきこと

ほとんどの Magento 監査では、影響の順序は次のとおりです。

1. レイヤードナビゲーション — パラメータ URL の正規化 + noindex 戦略。これは技術的 SEO 価値の最大のシェアです。
2. 設定可能/シンプルな商品の正規化 — シンプルな SKU を親の設定可能な商品に正規化します。管理画面の設定だけでなく、レンダリングされたページで確認してください。
3. URL リライトとリダイレクト — フレンドリーな URL をオンにし、変更時のリダイレクトをオンにし、孤立した 404 をなくします。
4. スキーマ — JSON-LD を追加します（ネイティブサポートなし）。重複ブロックを避けます。
5. タイトル/メタ + カテゴリコピー — フィールドを埋めます。カテゴリは空白で出荷されます。
6. パフォーマンス — キャッシュ、CDN、画像。

その他はすべて洗練です。Magento は完全なコントロールを提供します。つまり、Magento ストアのほとんどすべての SEO 問題は、修正できる設定の選択であり、ほとんどすべてがフィルタから始まります。

AIまとめ

Advancedバージョンの簡潔な見解:

• Magento SEOは、重複コンテンツを生み出す2つの要因に支配されています。 レイヤードナビゲーション（ファセットフィルタリング）は、カテゴリURLにフィルタパラメータを追加します。設定可能/シンプルな製品バリアントは、ほぼ同一のSKU URLを大量に生成します。どちらも同じ対処が必要です。クリーンな親（カテゴリまたは設定可能な製品）へのcanonicalと、価値の低い組み合わせへの**noindex**。検索需要が実際にあるフィルタ/バリアントのみをインデックス可能なページに昇格させます。
• バージョンが重要です: Magento 1はサポート終了（2020年6月） — 移行してください。Magento 2は、単一のコードベースからAdobe Commerce（有料、セルフホスト）とMagento Open Source（無料）として提供され、さらに別のSaaS製品である**Adobe Commerce as a Cloud Service（ACCS、2025年6月以降）**があり、Lumaテーマは完全に廃止されています。
• レイヤードナビゲーション vs. Live Search: Adobeは、標準のレイヤードナビゲーションと、有料のAI搭載Live Searchファセットを、URLの動作が異なる別個の実装として文書化しています。クロール/インデックスルールを適用する前に、ストアが実際にどちらを実行しているかを確認してください。
• 設定可能/シンプルな製品: シンプルなSKUを親の設定可能な製品にcanonical化します。カタログの表示設定だけでは、Googleがサイトマップや直接URL経由でそれらを発見してインデックスするのを防げません。
• URL: SEOフレンドリーなURLは**url_rewriteテーブル**（管理者 → マーケティング → SEO & 検索 → URL書き換え）を経由します。これはHTTPリダイレクトとは異なり、Magentoは301として自動生成できます。Webサーバーの書き換えとURL変更時のリダイレクトを有効にし、カテゴリパスやサフィックスの設定を変更する前に、影響を受けるURLパターンを棚卸ししてください。
• スキーマのギャップ: Magento 2はデフォルトではJSON-LDを出力しません（一部のテーマでのみmicrodata）。GoogleはJSON-LDを推奨しているため、リッチリザルトスキーマは拡張機能/カスタム開発のタスクです。また、重複するProductブロックに注意してください。
• その他の対応: ページネーション（自己参照の一意なcanonical、シリーズ全体へのnoindexはしない）、多言語ストアのストアビュー重複とhreflang、在庫切れポリシー、Core Web Vitals。PWA StudioとACCSは、互換性のない2つの異なるヘッドレスパスであることに注意してください。
• 優先順位: レイヤードナビゲーション → 設定可能/シンプルな製品のcanonical化 → URL書き換え/リダイレクト → スキーマ → タイトル/メタ/カテゴリコピー → パフォーマンス。

公式ドキュメント

一次情報のドキュメント。Magentoの公式ドキュメントはプラットフォーム設定をカバーし、Googleのドキュメントは、それらの設定が満たすべきSEOの動作をカバーしています。

Adobe / Magento

• Adobe Commerce / Magento Open Source — SEOベストプラクティス — 公式SEO設定ガイド（URL、メタデータ、サイトマップ、robots.txt）。
• URL書き換え — 管理者でのurl_rewriteシステムの仕組み。
• 検索エンジン最適化（設定リファレンス） — ストア → 設定の下にあるWebサーバー書き換え、URLサフィックス、SEO設定。
• レイヤードナビゲーション — Magento SEOの中核となるフィルタリング機能に関するAdobeのドキュメント。
• ソフトウェアライフサイクル / Magento 1のサポート終了 — バージョンサポートと2020年6月のMagento 1 EOL。

Google — Magento設定が満たすべき要件

• 商品の構造化データの概要 — 必須/推奨の Product フィールド。JSON-LD が推奨。
• eコマースサイト向けの構造化データ — Google がサポートする eコマースのスキーマタイプ。
• ページネーションとインクリメンタルページ読み込み — 一意の URL、自己カノニカルページ、フィルターには noindex（ページネーションには適用しない）。
• ファセットナビゲーション URL のクロール管理 — レイヤードナビゲーション問題に関する Google の公式ガイダンス。
• クロールバジェットを最適化する — 大規模サイトでパラメータの乱立が重要な理由。

ソースからの引用

Magento SEO の実際に効果のある部分（ファセットナビゲーション、構造化データ、ページネーション）に関連する公式発言。各リンクは、ソースが対応する場合、引用箇所にジャンプするディープリンクです。

Google — 構造化データ（Magento が自動で追加しないスキーマ）

• “Merchant listings: For pages where customers can purchase products from you. This markup has more options for specifying detailed product information, like apparel sizing, shipping details, and return policy information.” (翻訳) 「マーチャントリスティング：顧客があなたから商品を購入できるページ向け。このマークアップには、アパレルのサイズ、配送詳細、返品ポリシー情報など、詳細な商品情報を指定するためのより多くのオプションがあります。」 — Google Search Central、商品の構造化データの概要. 引用にジャンプ
• “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data.” (翻訳) 「ウェブページの構造化データと Merchant Center フィードの両方を提供することで、エクスペリエンスへの適合性が最大化され、Google がデータを正しく理解・検証するのに役立ちます。」 引用にジャンプ

Google — ページネーション（Magento の ?p= カテゴリページ）

• “Give each page a unique URL” — 各ページに独自のカノニカルを割り当て、すべてを1ページ目にポイントさせない。 — Google Search Central、ページネーションとインクリメンタルページ読み込み. 引用にジャンプ
• “Apply noindex meta tags to filter variations or alternative sort orders” — つまり、ファセットには適用するが、ページネーションされたシーケンス自体には適用しない。 引用にジャンプ

Gary Illyes（Google）— レイヤードナビゲーションが中核リスクである理由

• ファセット/パラメータ URL 空間について： “Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.” (翻訳) 「URL のセットを発見すると、その URL 空間の大部分をクロールしない限り、その URL 空間が良いかどうかを判断できません。」

  Search Engine Land の Search Off the Record 2025年末クロールレポートの報道経由。最終的な扱いにする前に、ソースのエピソードで確認してください。その報道によると、ファセットナビゲーションは Google が受け取るクロール問題レポートの最大の原因（約50%）です。

  報道を読む
• “Sometimes you might create these new fake URLs accidentally, exploding your URL space from a balmy 1000 URLs to a scorching 1 million, exciting crawlers that in turn hammer your servers unexpectedly.” (翻訳) 「時々、これらの新しい偽の URL を誤って作成し、URL 空間が穏やかな 1000 URL から灼熱の 100 万 URL に爆発し、クローラーを興奮させ、結果として予期せずサーバーを叩くことがあります。」

  Gary Illyes の LinkedIn 投稿（2024年8月）から Search Engine Journal 経由で伝達。

  報道を読む

実務者向け — 設定可能/シンプル製品の正規化

• “Canonical to the parent configurable product.” — Dan Taylor, Search Engine Journal, The Technical Guide to Common Magento (Adobe Commerce) SEO Issues. 引用にジャンプ
• “The canonical tag used on each of the simple products points back to the primary configurable version — to prevent duplicate variants of the product from being indexed by Google.” (翻訳) 「各シンプル製品に使用される正規タグは、主要な設定可能バージョンを指し示し、製品の重複バリアントが Google にインデックスされるのを防ぎます。」 — Paul Rogers (Vervaunt). 引用にジャンプ
• “…potentially generates 144,000 product combinations.” (翻訳) 「…潜在的に 144,000 の製品組み合わせを生成します。」 — Vervaunt、架空のファッションストアの例（3 000 の親製品 × 8 サイズ × 6 色）について、大規模な場合に明示的な正規ポリシーが重要である理由を示しており、普遍的なカタログサイズではありません。 引用にジャンプ

Magento SEO チェックリスト

影響度でおおよそ優先順位付け — 上位項目は Magento ストアの勝敗を分ける場所です。

バージョン & 基盤

• Magento 2 を使用していることを確認（サポート終了の Magento 1 の場合は移行）。
• エディション（Adobe Commerce、Magento Open Source、または ACCS）を把握し、 機能範囲を確認 — ACCS は Luma テーマを完全に廃止します。

レイヤードナビゲーション（重要項目）

• ストアが標準のレイヤードナビゲーションを使用しているか、有料の Live Search ファセットを使用しているかを確認 — Adobe はこれらを別々の実装として文書化しています。
• フィルタが生成するパラメータ URL の数を監査（サイトをクロールし、 site: カウントと GSC のインデックス済み vs 発見済みを確認）。
• フィルタされたカテゴリ URL をクリーンなカテゴリ URL に正規化。
• 価値の低いフィルタの組み合わせを noindex にし（タグが読まれるようにクロール可能に保つ — noindex と robots.txt の Disallow を同時に使用しない）。
• 実際の検索需要があるフィルタを特定し、インデックス可能でクリーンな URL の ランディングページを独自のコピーで構築。

設定可能 & シンプル製品

• 「製品に正規リンクメタタグを使用」を有効化（ストア → 設定 → カタログ → カタログ → 検索エンジン最適化）。
• レンダリングされたページで確認（設定だけでなく）— シンプル製品の URL が親の設定可能製品への正規タグを持つことを確認。
• 「個別に表示しない」だけに頼らない — 直接 URL、サイトマップ、内部リンクの インデックスをブロックしません。

URL & リダイレクト

• 「Web サーバーリライトを使用」を有効化（URL に index.php を含めない）。
• 製品とカテゴリに SEO フレンドリーな URL キーを設定。
• URL キーを編集する前に「古い URL の恒久リダイレクトを作成」を有効化。
• 製品 URL にカテゴリパスを含めるか決定（オフにすると複数 URL の重複を回避）。

構造化データ

• Product JSON-LD を追加（Magento 2 には標準搭載なし）— 拡張機能または開発で。
• 重複スキーマがないことを確認（テーマのマイクロデータ + 拡張機能の JSON-LD）。
• aggregateRating/review は実際のレビューのみから。

オンページ & インデックス

• 製品とカテゴリに一意のタイトルとメタディスクリプション。
• カテゴリの説明コピーを記入（デフォルトでは空白）。
• ページネーション: 一意の自己参照正規タグ; シリーズは noindex にしない。
• 在庫切れ / 販売終了製品のポリシーを決定（404 を放置しない）。

国際 & パフォーマンス

• ストアビューの重複を管理。多言語対応の場合はhreflangを完全かつ双方向に設定。
• Core Web Vitals対策として、フルページキャッシュ（Varnish）、CDN、WebP画像を導入。

Magento SEOチートシート

バージョン別概要

レイヤードナビゲーション — URLタイプ別の対応

主要な管理画面設定（Magento 2）

• ストア → 設定 → 一般 → Web → 検索エンジン最適化: Webサーバーリライトを使用 = はい.。
• ストア → 設定 → カタログ → カタログ → 検索エンジン最適化: 製品/カテゴリのURLサフィックス、カテゴリ/製品にカノニカルリンクメタタグを使用 = はい.。
• マーケティング → SEO & 検索 → URLリライト: url_rewrite マネージャー。
• 製品/カテゴリ編集 → 検索エンジン最適化: URLキー、メタタイトル、 メタ説明。古いURLに恒久的リダイレクトを作成 を有効にする。

重要な事実

• Magento 2はデフォルトでJSON-LDを出力しない（一部のテーマではマイクロデータのみ）。
• Googleはマイクロデータ/RDFaよりもJSON-LDを推奨している。
• noindexにはクロール可能なページが必要 — robots.txtのDisallowと組み合わせないこと。
• フレンドリーなURLは**url_rewrite**テーブルに格納される。

メンタルモデル

1. バージョンを最初に確認。 どの戦術よりも先に、Magento 1か2かを答える。1の場合、プロジェクトは移行であり、それで決まり。 2の場合、エディション（Adobe Commerce vs Open Source）は機能を変えるが、SEOの 基本は変わらない。

2. レイヤードナビゲーション = URLごとの二者択一の判断。 フィルターされたURLはそれぞれ、資産（実際の検索需要がある → インデックス可能なランディングページにする）か、負債（需要がない → カノニカルで無効化および/またはnoindex）のどちらか。 すべてのファセットを同じように扱わず、需要で分類し、適切なシグナルを適用する。

3. 「組み合わせてはいけない」3つのルール。

• 同じURLにnoindex + robots.txtのDisallow → タグが読み取られない。
• 同じURLにnoindex + カノニカル → 矛盾したシグナル。
• クロール予算のためのカノニカルのみ → ソースページは依然としてクロールされる。

4. URL空間を制御し、次にインデックスを制御する。 Magentoのurl_rewriteシステムとWebサーバーのリライトは、_どのURLが存在し、どこにリダイレクトされるか_を決定します。正規化/noindexは_インデックスに何が含まれるか_を決定します。まずURL生成を修正し（重複を生成しない）、その後インデックス管理を行います。

5. スキーマはここではオプトインです。 ほとんどのプラットフォームではスキーマは微調整ですが、Magentoではビルドです。JSON-LDを成果物として計画し、Productブロックが2つ配信されないように保護します。

Magento SEOのためのツール

• Magento管理画面 — URLリライト（マーケティング → SEO & 検索）— url_rewriteテーブルのネイティブマネージャー。フレンドリーなURLとリダイレクトの信頼できる情報源です。
• クローラー / サイト監査 — Screaming Frog SEO SpiderまたはAhrefs Site Auditを使用して、レイヤードナビゲーションが実際に生成するパラメータURLの数を測定し、重複タイトル/正規化を検出し、リダイレクトチェーンを見つけます。これがファセットナビゲーションの問題の規模を把握する方法です。
• Google Search Console — _ページのインデックス登録_レポート（検出済み/クロール済み — インデックス未登録はパラメータの乱立でしばしば膨張します）と_クロール統計_を使用して、フィルタURLに費やされたクロール予算を確認します。
• リッチリザルトテスト / スキーママークアップ検証ツール — 追加したJSON-LDが有効であり、競合するマイクロデータブロックがないことを確認します。
• Magento SEO拡張機能 — Mageworx、Mirasvit、Amastyなどは、JSON-LD、より細かい正規化制御、Magentoコアがユーザーに委ねているレイヤードナビゲーションのインデックス登録ルールを追加します。（重複スキーマの動作について評価してください。）
• ログファイル分析 — 大規模なカタログの場合、サーバーログはフィルタURLにどれだけのクロールが浪費されているかを正確に示します。

Magento SEOの健全性を測定する方法

これらはMagentoストアの継続的なKPIであり、一度きりのチェックではありません。定期的な頻度で追跡し、レイヤードナビゲーション、インデックス登録、スキーマが静かに乱雑な状態に戻らないようにします。

インデックス登録済みURLと検出済みURLの比率

これが示すもの: レイヤードナビゲーションがGoogleのサイトビューをどれだけ肥大化させているか。数百の製品があるカテゴリに、数万の検出済みURLがあってはなりません。

取得方法: Search Console → ページのインデックス登録レポート、具体的には「検出済み — 現在インデックス未登録」と「クロール済み — 現在インデックス未登録」のバケット。レポートのURL検査サンプルまたはクロールエクスポートを使用して、URLパターン（クエリ文字列のフィルタ）でセグメント化します。

ベンチマーク / 現実的な範囲: 普遍的な数値はありません — カタログサイズとフィルタ数に依存します。重要なシグナルは_トレンド_です。比率が月ごとに上昇している場合、レイヤードナビゲーションの正規化/noindex戦略が維持されていないことを意味します。

頻度: 毎月、またはレイヤードナビゲーションの設定変更後。

フィルタURLに費やされたクロール予算

これが示すもの: Googlebotが実際の製品ページやカテゴリページではなく、ほぼ重複したパラメータの組み合わせにクロール容量を浪費しているかどうか。

取得方法: Search Console → クロール統計レポート（応答別および目的別）を、?パラメータリクエストにフィルタリングしたサーバー/CDNログファイルと相互参照します。私のファセットナビゲーション監査ツールは、提供されたパラメータURLのリストを分類して、実際に生成されている組み合わせの規模を把握するのに役立ちます。

ベンチマーク / 現実的な範囲: カタログサイズとクロール頻度に依存します — 固定された「適切な」パーセンテージはありません。正規の製品/カテゴリURLと比較したパラメータURLへのクロールヒットの割合の増加を警告サインとして扱います。

頻度: 確立されたストアでは毎月。レイヤードナビゲーションの設定変更中および変更後は毎週。

正規化シグナルの一貫性

これが示すもの: フィルタリングおよびページネーションされたURLが、意図した正規化に実際に解決されているかどうか。テーマ/拡張機能の更新後に、自己参照やタグの欠落に静かに戻っていないかどうか。

取得方法: 私の正規化チェッカーでフィルタおよびページネーションURLをスポットチェックします — HTMLとHTTPの正規化シグナルを監査し、競合をフラグします。

ベンチマーク／現実的な範囲: 100% であるべきです — 抑制する予定のフィルタリングされた URL はすべて、クリーンなカテゴリページを指す canonical を持つべきであり、ページネーションされた各ページは自己参照 canonical を持つべきです。例外はバグであり、範囲ではありません。

頻度: テーマ、拡張機能、または階層ナビゲーション設定を変更するたびに実施。それ以外は四半期ごとにスポットチェック。

商品リッチリザルトの適合性

わかること: 追加した JSON-LD（Magento はデフォルトでは何も提供しません）が、価格／評価のリッチリザルトを獲得するのに実際に有効かつ十分に完全であるかどうか、また、残っているテーマのマイクロデータブロックがそれと競合していないかどうか。

取得方法: Search Console → 拡張機能 レポートの商品スニペット、または Google のリッチリザルトテストで個別の URL をスポットチェック。スキーマ自体の生の HTML 監査（重複ブロック検出を含む）には、私の PDP SEO チェッカー を使用してください。

ベンチマーク／現実的な範囲: カタログサイズとレビューカバレッジに依存します — すべての SKU が aggregateRating データを持つわけではありません。有効な項目とエラー／警告項目のトレンドを追跡し、絶対的な目標値ではありません。

頻度: 毎月、およびスキーマ拡張の更新やテーマ変更の直後に実施。

検証テスト: Magento SEO 修正が効果を発揮したことを証明する

この記事で扱う特定の変更に対する合格／不合格チェック — 変更を行った直後にそれぞれを実行し、その後は記載された監視頻度で再度実行します。

フィルタリングされたカテゴリ URL に追加された canonical

実行するテスト: フィルタリングされた URL（例: /running-shoes?color=blue）を私の 正規化チェッカー で読み込みます。

期待される結果: ツールが、フィルタリングされた URL にクリーンなカテゴリ URL（/running-shoes）を指す rel=canonical を報告し、競合する HTTP ヘッダーの canonical がないこと。

失敗の解釈: canonical がない、自己参照 canonical、または他の場所を指す canonical がある場合、「カテゴリに Canonical Link Meta Tag を使用」設定またはテンプレート／拡張機能のロジックがこの URL パターンに対してそれを出力していないことを意味します。

監視期間: タグ自体は即時。Search Console のページインデックスレポートで 2〜4 週間、Google が統合されたシグナルを認識するのを確認します。

ロールバックのトリガー: canonical の存在が確認されているのに、4 週間後にフィルターパターンのインデックス済み URL 数が増え続ける場合、シグナルが尊重されていません — 同じ URL に競合する noindex または robots.txt ブロックがないか確認してください。

低価値のフィルター組み合わせに適用された noindex

実行するテスト: フィルタリングされた URL のレンダリングされた HTML <head> を取得し（ソース表示または curl）、<meta name="robots" content="noindex,follow"> を確認します。次に、私の Google インデックスチェッカー で robots.txt のその URL パターンを確認します。

期待される結果: noindex タグが存在し、かつ URL が robots.txt で許可されていないこと — Google はクロール可能なページでのみタグを読み取れます。

失敗の解釈: robots.txt もそのパターンを禁止している場合、Googlebot はページを取得して noindex タグを確認できず、URL は履歴シグナルだけから無期限にインデックスされたままになる可能性があります。

監視期間: クロールがタグを取得するまで数日。URL が実際にインデックスから外れるまで 2〜8 週間（以前によくリンクされていたフィルターページではより長く）。

ロールバックのトリガー: noindex がクロール可能であることが確認されているのに、8 週間後も URL がインデックスされたままの場合 — 同じ URL で canonical が noindex と競合していないか確認してください（これらは矛盾するシグナルであり、Google は一方を無視する可能性があります）。

シンプル商品の canonical が設定可能な親を指す

実行するテスト: シンプル商品のバリアント URL（特定のサイズ／カラーの組み合わせ）を私の 正規化チェッカー で読み込みます。

期待される結果: ツールが、シンプル商品の URL に親の設定可能な商品の URL を指す rel=canonical を報告し、競合する HTTP ヘッダーの canonical がないこと。

失敗の解釈: 自己参照または欠落したcanonicalは、「製品にCanonical Link Meta Tagを使用」が有効になっていないか、バリアントが親の関係とは独立して表示可能/インデックス可能として扱われていることを意味します。

監視期間: タグ自体は即時、Search Consoleのページインデックスレポートで2〜4週間、バリアントURLが親の下に統合され、個別のインデックスページとして蓄積されないことを確認します。

ロールバックのトリガー: canonicalが存在することを確認した後、4週間経っても単純製品URLのインデックス数が増え続ける場合は、「個別に表示しない」がcanonicalタグの代わりに使用されていないか確認してください。カタログの表示設定は、直接URL、サイトマップ、内部リンクのクロールをブロックしません。

URL変更時のリダイレクトが古いURLを保護している

実行するテスト: 製品またはカテゴリのURLキーを変更した後、古いURLを直接リクエストします: curl -I https://yourstore.com/old-url-key。

期待される結果: 新しいURLへの単一の301リダイレクト（リダイレクトチェーンなし）。

失敗の解釈: 404は、「古いURLに恒久的リダイレクトを作成」がキー変更時にオフだったか、url_rewriteエントリが生成されなかったことを意味します。古いURLとそれが保持していたインバウンドリンクやランキングは孤立します。

監視期間: 即時 — これはステータスコードのチェックであり、待機は不要です。

ロールバックのトリガー: 以前ランキングがあったURLで404またはチェーンが発生した場合、url_rewriteエントリを復元するか、インデックスから落ちる前に手動リダイレクトを追加してください。

JSON-LD製品スキーマが有効で重複していない

実行するテスト: 製品ページを私のPDP SEOチェッカーで実行し、生のJSON-LDの必須フィールドと重複ブロックを監査し、Googleのリッチリザルトテストでリッチリザルトの適格性を確認します。

期待される結果: name、image、description、offers（価格、priceCurrency、在庫状況）、および星評価を主張する場合は実際のレビューに基づくaggregateRating/reviewを含む、有効なProductブロックが1つ。テーマのマイクロデータからの競合する2番目のブロックはありません。

失敗の解釈: 2つのProductブロック（テーマのマイクロデータ+拡張機能のJSON-LD）がある場合、通常Googleが任意に1つを選択するか、一貫性がないとして両方を破棄します。offersフィールドが欠落している場合、ページは価格スニペットの対象になりません。

監視期間: 有効性は即時、Search Consoleの機能強化レポートで2〜4週間、リッチリザルトが実際に表示され始めることを確認します。

ロールバックのトリガー: テーマまたは拡張機能の更新後、機能強化レポートで「無効なアイテム」が増加している場合、重複が解決されるまで新しいソースを無効にします。

時間をかける価値のあるリソース

Magento SEOを支配するトピック（このサイト）

• ファセットナビゲーション — レイヤードナビゲーションの問題とインデックスまたは抑制の決定フレームワークの正規の情報源。
• 正規化とcanonicalタグ — Magentoのパラメータ重複の主要な修正。
• 重複コンテンツ — フィルタとストアビューURLがシグナルを分割する理由。
• URLパラメータとクロール予算 — パラメータの乱雑さのクロール側のメカニズム。

関連する私の記事（Ahrefs）

• 技術SEOの初心者ガイド — これらのコントロールが全体像のどこに当てはまるか。
• ファセットナビゲーション：定義、例、SEOのベストプラクティス — 完全な決定フレームワーク（私はこの記事のレビュアーです）。
• URLパラメータ：SEOのための完全ガイド。

公式

• Adobe Commerce SEO のベストプラクティス — プラットフォーム自身のガイダンス。
• Google の ファセットナビゲーション URL のクロール管理。

その他の情報源

• r/TechSEO と Magento Stack Exchange — Magento 固有のクロール/インデックスに関する癖がデバッグされる場所。
• Magento の一般的な SEO 問題に関する技術ガイド (Search Engine Journal、Dan Taylor) — URL リライト、設定可能/シンプル製品の正規化、ファセットナビゲーションの制御を網羅した実践者向けの包括的ガイド。
• Magento における重複コンテンツの究極ガイド (Vervaunt、Paul Rogers) — 重複コンテンツの完全なソースマップと設定可能/シンプル製品の正規化戦略について最も引用されている情報源。
• Magento における設定可能製品とシンプル製品の SEO 考慮事項 (Paul Rogers) — シンプル SKU を設定可能な親製品に大規模に正規化する方法についての詳細な解説。
• 階層ナビゲーションで問題が発生？対処しよう (Scandiweb) — ファセットナビゲーションのクロール制御の主要手段として robots.txt の disallow を推奨する、現在の Google の指針に沿ったガイダンス。
• Magento 2 階層ナビゲーション SEO: 究極ガイド (Mageworx) — 具体的な URL 例を用いたパラメータ URL の増殖に関する詳細な解説。
• Adobe Commerce の製品スキーマ (Lumio) — Luma がほとんど JSON-LD を出荷しない理由を説明し、EAV モデルに対するカスタム JSON-LD モジュールの構築方法を解説。

変更履歴