Salesforce Commerce Cloud SEO完全ガイド

要点 — Salesforce Commerce Cloud（B2C Commerce、SFCC、旧称Demandware）は、 エンタープライズ向けのホスティング型ECプラットフォームです。robots.txtの編集、 サイトマップの自動生成、テンプレートによるページタイトル生成、検索に配慮した 商品バリエーション処理など、堅実なSEO機能を備えています。ただし、サイト固有の 設定とレンダリング結果の検証は、プラットフォームを理解した担当者が行う必要があります。

「Salesforce Commerce Cloud SEO」とは

Salesforce Commerce Cloudは、大規模ブランドや小売事業者向けのホスティング型（SaaS） ECプラットフォームです。WordPressとWooCommerceのように自社サーバーへ導入するのではなく、 Salesforceがホスティングします。正式名称はB2C Commerce、旧称はDemandwareで、 業界では一般にSFCCと呼ばれます。ShopifyやBigCommerceと同じ領域に属しますが、 規模、価格、複雑さはいずれも一段上です。

SEOを含むほぼすべての設定は、Business Managerという管理画面で行います。 つまりSalesforce Commerce Cloud SEOの実務は、各SEO要素をどの画面で制御するかを理解し、 正しく設定することです。

SFCCに標準搭載されている機能

• 編集可能なrobots.txt。 Shopifyとは異なり、Business Managerでサイトごとの robots.txtを直接記述できます。
• サイトマップの自動生成。 指定したスケジュールでXMLサイトマップを生成するため、 ファイルを手作業で作る必要はありません。
• テンプレートベースのページタイトルと説明。 Meta Tag Rulesを使えば、 「カテゴリ名 | ブランド」のような式を1つ作り、カタログ全体のタイトルへ展開できます。
• 検索に配慮した商品バリエーション。 色やサイズ違いを1つの「マスター商品」と 「バリエーション商品」として扱い、個別ページをマスターへ集約して重複を避けられます。

自分たちで実装する必要があるもの

• 多言語／多国向けタグ（hreflang）。 自動付与はされません。サイトマップ設定の チェックボックスを有効にするか、開発者がタグを追加します。
• 絞り込みページ（ファセットナビゲーション）。 色、サイズ、価格などの絞り込みに対し、 検索向けの整ったURLは標準では生成されず、カスタム開発が必要です。
• リッチリザルト／schema。 星評価や商品リッチリザルトに使う構造化データは、 管理画面のスイッチではなく、開発者がストアのテンプレートへ実装します。
• ヘッドレス（PWA KitまたはStorefront Next）のクロール可能性。 これらのフロントエンドを 使う場合、Googleがコンテンツを実際に取得できるか確認する必要があります。詳しくは Advancedタブを参照してください。

多くの人が誤解していること

「Salesforce Commerce CloudではSEOができない」という見方は正しくありません。 プラットフォームには強力な機能がありますが、求められるのはプラットフォームを理解した人です。 「hreflangを追加する」「絞り込みURLを整理する」といった一般論は方向性として正しくても、 SFCCでは固有の画面とルールがあるため、一般的な方法をそのまま適用できない場合があります。 制約はプラットフォームそのものではなく、それへの不慣れです。

URL RulesとAliases、マスター／バリエーションのcanonical戦略、hreflang設計、 ヘッドレスストアのクロール検証まで知りたい場合は、Advancedタブへ進んでください。

要点 — SFCC（B2C Commerce、旧Demandware）には、Business Managerで編集できる サイト別のrobots.txt、定期ジョブで自動生成されるXMLサイトマップ、カタログ全体の タイトルと説明を生成するルールベースのMeta Tag Rules、Googleの ProductGroup／hasVariant／isVariantOf schemaとほぼ1対1で対応する、canonicalを 前提としたマスター／バリエーション商品モデルなど、強力な標準SEO基盤があります。 一方、規模が大きくなるほど重要になるhreflang（B2C専用機能はなく、サイトマップの “Include Alternate URLs”またはカスタム<link>タグで実装）、ファセット／絞り込みURL （カスタム開発）、構造化データ（設定スイッチではなくテンプレート実装）、PWA Kitまたは Salesforceの新しいStorefront Nextでのヘッドレス環境のクロール可能性は、自分たちで 対応する必要があります。SSRだけでは不十分です。PWA Kitでは?__server_onlyで検証し、 Storefront Nextでは同等の方法を確認してください。さらに、多地域ブランドを複数ロケールの 1サイトで構成するか、複数サイトで構成するかという最大の設計分岐が、同期すべきSEO設定面の 数を決定します。

全体像：強力な標準機能と、高度なプラットフォーム知識

SFCCのSEO解説は、内容の薄い代理店の宣伝か、SEOの視点を欠いた開発者ドキュメントの どちらかに偏りがちです。実態はその中間です。SFCCには競合プラットフォームの多くを上回る、 管理画面から設定可能な標準SEO機能があります。しかし、意図的に設定しなければ十分に機能せず、 放置すると悪影響を及ぼす初期設定もあります。 各作業を「標準の構成要素」と「自分たちで 実装するもの」に分けると、プラットフォームの全体像が見えやすくなります。

まず理解すべき点は次の3つです。

1. SEOの設定はBusiness Managerに集約されています。 中心となる場所は Merchant Tools → サイト → SEOで、Canonical URL tags、URL Redirects、Sitemaps、Robots、 Meta Tag Rules、URL Rules／Aliasesがそれぞれ独立した画面とルールを持ちます。
2. マスター／バリエーション商品モデルが全体を左右します。 1つのマスター商品が、 色やサイズごとの複数のバリエーション商品を持ちます。このモデルがSEO設計の中心であり、 Googleが推奨するバリエーションのマークアップとも対応します。詳しくは後述します。
3. 修正方法を決める前に、ストアフロントのアーキテクチャを特定します。 現在の Salesforce Commerce Cloudには、SEO上の挙動が異なる少なくとも4世代のストアフロントが あります。旧来のSiteGenesisパイプライン、現行のSFRA（Storefront Reference Architecture）、実績のあるヘッドレス構成のPWA Kit（Composable Storefront）、そして 2026年のB2C Commerceリリースサイクルで登場した新しいReactフレームワーク Storefront Nextです。管理画面のパス、カートリッジの挙動、レンダリング方式はそれぞれ 異なるため、1つで確認した修正が別の構成へ自動的に適用できるとは限りません。この記事の Business Manager画面はSFRA／SiteGenesisに広く当てはまり、後半のPWA Kit固有の手順は 適用範囲を明記しています。

標準の構成要素： サイト別に編集できるrobots.txt、任意のhreflangと最終更新日を含められる 定期自動生成XMLサイトマップ、ロケール対応の整ったURLを作るURL Rules + Hostname Aliases、 canonicalを前提としたバリエーション商品、ルールベースのMeta Tag Rules、Business Manager内の URL変更に伴う自動301、初回読み込み時のPWA Kit SSR。

自分たちで実装するもの： hreflang、ファセット／絞り込みURL、構造化データ、複数ロケールに 対応するrobots.txt、H1テンプレート、ヘッドレス構成におけるすべてのページ内タグ管理。

全体を左右する設計分岐：サイトとロケール

SEO画面を設定する前に、多地域ブランドを複数ロケールを持つ1サイトとして構成するのか、 それともロケールまたは地域ごとの複数サイトとして構成するのかを決めます。SFCCの多地域 ストアフロントは、Business Manager内で個別のサイトとして構築されることが一般的です。 重要なのは、各サイトが完全に独立したSEO設定面を持つことです。サイトマップジョブ、 robots.txt、Meta Tag Rules、URL Rulesがサイトごとに存在します。10サイトなら、10組すべてを 手作業で同期し続けなければなりません。この判断は記事内のあらゆる設定作業を暗黙に増やすため、 早い段階で明示してください。

URL構造：URL RulesとHostname Aliasesの比較

SFCCには2つの設定方法があり、どちらを選ぶかはロケール構成の複雑さによって決まります。

• URL Rules（Merchant Tools → サイト → SEO → URL Rules）は、ロケール、カテゴリ、商品パスの セグメントをパターンへ割り当てます。比較的単純ですが柔軟性は低く、ロケールのルーティングには 代替ホスト名、URLパラメーター、パスのいずれか1つを選びます。
• Hostname Aliases（Merchant Tools → サイト → SEO → Aliases）は、より多機能なJSONエイリアス ファイルです。同じサイト内で、一部のロケールにccTLD形式のホスト名、別のロケールに サブフォルダー形式を使うような混在構成にも対応できます。混在ルーティングが必要な場合は、 エイリアスファイルを使う必要があります。

押さえておくべき仕組みは次のとおりです。

• 小文字へ統一する。 SFCCのURL設定ガイドは、同じ文字列で大文字・小文字が異なる複数のURLを 生成しないよう、Lower Caseを選択するよう案内しています。実務家も、一般にクローラーには 小文字が好まれると指摘しています。
• 空白にはハイフンを使う。 空白はURLエンコード（%20）するか、プラス、アンダースコア、 マイナス、ピリオドへ置換できます。SalesforceのSEO URLガイドでは、検索エンジンはハイフンを 区切り文字として扱う一方、アンダースコアを結合文字として扱うため、アンダースコアでつないだ 2語は1語として解釈されると説明しています。したがって、ハイフン（マイナス）が最も明快です。 NOVOSも、初期値の%20よりハイフンを推奨しています。
• categoryとcategory-pathを使い分ける。 2〜3階層を超えるサイトでは、通常は category-pathではなくcategoryを使います。ただし、異なる親カテゴリの下に同名カテゴリが ある場合は、区別するためにcategory-pathを使います。
• 商品IDは自動で付加される。 ルールに商品IDを追加する必要はありません。B2C Commerceが .html拡張子とともに必ず自動付加します。実務家によれば、カスタム開発なしに.htmlを 削除する方法はありません。
• 商品はカテゴリパスではなくドメインへ割り当てる。 商品は複数カテゴリへ割り当てられるため、 カテゴリ由来のURLセグメントは不安定になります。NOVOSは、重複と複雑さを減らすために商品を ドメインへ割り当てることを推奨しています。
• Salesforce公式ガイドが示す一般的なURL衛生： URLは読みやすく短く保ち、フォルダー数を できるだけ減らし、パラメーターを避け、キーワードを組み込みます。また、ページ種別を示す文字列、 独自のsc.html拡張子、demandwareという語をURLに含めないようにします。

典型的な落とし穴： Default-StartとHome-Showパイプラインをマッピングしないと、 wwwとnon-wwwのホスト名で重複するホームページが生成されます。必ず明示的にマッピングし、 wwwの有無による重複を防いでください。もう1つ、実務家が繰り返し指摘する注意点として、 エイリアスファイルにはversion 1を 宣言する必要があります。宣言がなければ、システムはファイル全体を無視します。

プリセットのURL構造を選び、ドロップダウンでプレフィックスを削除できるBigCommerceや、 /products/と/collections/が固定されるShopifyと比べ、SFCCのURL層ははるかに柔軟です。 その分、正しく設定する作業そのものが独立した重要タスクになります。

XMLサイトマップ

サイトマップ生成は、手作業で保守する静的ファイルではなく、Business Managerの定期ジョブです。 App Launcher → Merchant Tools → サイト → SEO → Sitemapsから開き、Jobタブでスケジュールを 設定します。SalesforceはCPUとメモリの急増を避けるため、早朝などアクセスの少ない時間帯に設定し、 ステージングから日次データをレプリケーションした後に実行するよう案内しています。

つまずきやすい点は3つあります。

• インスタンスタイプごとに設定する。 サイトマップ設定はStaging、Production、Development間で レプリケーションできません。各インスタンスで個別に設定します。多くのサイト設定とは逆の挙動です。
• changefreq／priorityの調整に価値はない。 Googleはサイトマップ内のこれらの値を無視すると 明言しています。調整に開発工数を使わないでください。一方、生成したサイトマップへ自動付与される lastmodは正確に保ちます。再クロール対象を示す実用的なシグナルだからです。
• hreflangはチェックボックスで追加できる。 **“Include Alternate URLs”**を選ぶと、標準の サイトマップ内にhreflang注釈を埋め込めます。ただし、ロケール数が増えるとファイルごとのリンク数 上限を超える可能性があります。その場合は、ソリューションアーキテクトとカスタムサイトマップを 構築する必要があります。

ヘッドレスでは仕組みが異なります。 PWA Kitストアフロントについて、Salesforce公式の 「Improve SEO with a Sitemap」ガイドは、サイトマップが*“provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.”* (翻訳) 検索クローラーに、インデックス登録するページとサイト階層に関する指示を 与え、SEO順位の向上につながる可能性があります。と明記しています。ルートをBusiness Managerで 設定している場合は、そこでサイトマップを生成します。それ以外の場合は、SCAPIの uploadCustomSitemapAndTriggerSitemapGenerationエンドポイントからアップロードします。 接続にはvanity domain（組み込みCDNまたはseo.example.comのようなサブドメイン）、対応する hostname alias、example.com/sitemap_index.xmlで取得できるサイトマップが必要です。PWA Kitでは ssr.jsにapp.get('/sitemap_index.xml', runtime.serveStaticFile('static/sitemap_index.xml'))を追加し、 アプリ設定のssrSharedでファイルを公開します。

Robots.txt

実装方法は明確に2つあり、混同すると実際のデプロイ不具合につながります。

1. Business Managerのサイト設定（推奨される標準ルート）。 App Launcher → Merchant Tools → サイト → SEO → Robotsで、サイトごとのrobots.txtを記述できます（上限5万文字）。サイト設定として 保存され、インスタンス間でレプリケーションできます。
2. カートリッジ単位の静的ファイル（カスタムストアフロント／SFRA）。 カスタムカートリッジの cartridge/static/defaultにrobots.txtを置き、UX Studioで管理します。staticディレクトリは サイト固有ではなくカートリッジ固有なので、このファイルをインスタンス間で移動できるのは コードレプリケーションだけです。

注意点は2つあります。

• キャッシュの無効化。 キャッシュが有効な場合、カートリッジ単位の新しいrobots.txtを 配信するには、静的コンテンツのキャッシュを無効化する必要があります。
• robots.txtはサブフォルダー単位ではなくドメイン単位。 複数ロケールをサブフォルダーで 運用する場合、ドメインルートにある1つのrobots.txtですべてのロケールの要件を満たす必要が あります。全ロケールをカバーするルールを設計してください。

私も賛同する実務上の原則は、robots.txtを最小限に保つことです。検索結果への掲載は canonicalタグとnoindexで制御します。robots.txtが制御するのはクロールであり、 インデックス登録ではありません。過度に依存することこそアンチパターンです。開発／ステージングは デプロイ済みカートリッジの初期設定でクロール不可に保ち、本番は意図的に設定します。 （プラットフォーム共通の仕組みはクロール と canonicalization を参照してください。）

Canonical URLとマスター／バリエーション商品モデル — SFCCの差別化点

ここは、SFCCのデータモデルとGoogle公式ガイドがほぼ完全に一致する部分であり、多くのSFCC解説が 十分に踏み込めていない部分でもあります。

SFCCでは、色やサイズの違いを1つのマスター（ベース）商品と、その子である バリエーション商品として表現します。Salesforceは、順位を維持または改善するため、 バリエーション商品URLをマスター商品へcanonical化することを推奨しています。つまり、色やサイズ ごとの各PDPのrel="canonical"をベース商品へ向け、ランキングシグナルを1つのURLに集約します。

では、まさにこの*“one product, many variations”* (翻訳) 「1商品に複数のバリエーションがある」状況について、Googleの推奨を確認します。 Googleの商品バリエーションガイドは、“use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” (翻訳) このようなバリエーションをグループ化するには、variesBy、hasVariant、productGroupIDの 各プロパティとともにProductGroupクラスを使用します。と説明しています。 これはSFCCのマスター／バリエーションモデルと概念的に一致します。

• マスター商品はGoogleのProductGroupに当たります。
• バリエーション商品はhasVariantの構成要素です。「separate」パターンでは、各Productが isVariantOfを使ってグループの@idを参照します。
• Googleは、nestedパターン（ProductGroup.hasVariant — “the most compact and natural representation of a product group” (翻訳) 商品グループを最も簡潔かつ自然に表現する 方法です。）と、separateパターン（Product.isVariantOf — “might be easier for some content management systems (CMSes) to generate” (翻訳) 一部のコンテンツ管理システム （CMS）では生成しやすい場合があります。）の両方を示しています。独立したPDPをまたいで バリエーション商品をテンプレート化するSFCCには、separateパターンが自然に適合します。

1ページ内でバリエーションを選択する構成について、Googleは*“only one distinct canonical URL for the overall ProductGroup”* (翻訳) ProductGroup全体に対して、明確に区別された canonical URLを1つだけ設定します。としています。これはSFCCがすでに推奨している 「バリエーション → マスター」のcanonicalルールそのものです。

Googleはcanonical化のシグナルを一貫させるよう明記しているため、両者を一致させます。重複URLの 統合ガイドでは、rel="canonical"を*“a strong signal that the specified URL should become canonical,”* (翻訳) 指定したURLをcanonicalにするべきだという強いシグナルです。、 サイトマップへの掲載を*“a weak signal,”* (翻訳) 弱いシグナルです。と位置づけ、 “these methods can stack and thus become more effective when combined.” (翻訳) これらの 方法は積み重ねられるため、組み合わせるとより効果的になります。と説明しています。ただし、 指定を矛盾させてはいけません。Googleは*“Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel="canonical").”* (翻訳) 異なる canonical指定手法を使って、同じページに別々のURLをcanonicalとして指定しないでください （たとえば、サイトマップではあるURLを指定し、同じページのrel="canonical"では別のURLを 指定しないでください）。と警告しています。SFCCでは、バリエーション商品のrel="canonical"、 サイトマップ、hreflang、内部リンクのすべてが同じマスターURLを示す必要があります。さらに、 “when linking within your site, link to the canonical URL rather than a duplicate URL” (翻訳) サイト内でリンクする際は、重複URLではなくcanonical URLへリンクしてください。 という原則に従い、内部ナビゲーションは特定のバリエーションURLではなくマスター商品へ向けます。

（バリエーションschemaの詳細は商品バリエーションSEO、canonicalの仕組みは canonicalization を参照してください。）

Meta Tag Rules

タイトルと説明には2つの実装方法があります。オブジェクトごとに手動で入力する方法 （Category／Product → Page Title／Page Descriptionフィールド）と、Meta Tag Rules （Merchant Tools → サイト → SEO → Meta Tags）を使い、ページ種別全体へ式を適用して ルールベースで動的生成する方法です。

• 基本的な動的ルール： ${Category.Name} | Example Brandのようなカテゴリタイトル。
• 上書きとフォールバックの併用： ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name}を使うと、ルールをカタログ全体の初期値として保ちながら、マーチャンダイザーが 特定ページだけを上書きできます。このパターンを標準にしてください。ルールは大規模運用に適しますが、 個別の例外はこの併用構文を使うか、汎用ルールを継承する必要があります。
• 接続語をローカライズする。 ローカライズしたルールでは、|区切りの前後に置く語などの 接続語も翻訳し、言語または言語・国レベルで設定します。
• H1には制約がある。 タイトルや説明とは異なり、H1タグを動的にテンプレート化する標準の Meta Tag Rules構文はありません。H1のテンプレート化にはカスタム開発が必要です。

リダイレクト

SFCCには、標準の自動リダイレクト動作と手動設定ツールがあります。

• 自動301は、Business Manager内でカテゴリまたは商品のURLを上書きしたときに作動します。 また、基になる商品IDが正しければ、SFCCは入力を誤ったPDPのURLを自動修正します。
• 3つの手動ツール： 1対1の対応にはURL Redirects、従来のURLパターンを静的リソースへ リダイレクトする場合はStatic Mappings、複雑なワイルドカードパターンには Dynamic Mappingsを使います。
• ステータスコード： 恒久的な移転には301（カスタム開発で変更する場合は308）、一時的な移転には 307を使います。（選び方の背景はAhrefsの11種類のリダイレクト と 301と302の違い を参照してください。）
• ハードコードしたパスではなくオブジェクトIDを指定する。 転送先URLが後で変わったときの エラーやリダイレクトループを防ぐため、NOVOSはURL文字列ではなくオブジェクト種別／IDを 転送先にすることを推奨しています。

優先順位のルールは重要です。開発者ドキュメントには、“If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.” (翻訳) SEO用の URLリダイレクトとURLルールが競合する場合は、URLリダイレクトが優先されます。と明記されています。

移行の観点： SFRAを再公開するとき、順位を維持するうえで最も重要なSEO要素はリダイレクト戦略 です。AcxiomのSalesforceチームは、これがローンチ時のSEO作業の60–70%を占めるとしています。 これは、Webサイト移行を成功させるにはチェックリストだけでは足りない という、より広い教訓とも一致します。

構造化データ／schema — 機能差を正確に捉える

多くの解説が省いている重要な事実があります。SFCCのBusiness Managerには、Meta Tag Rulesや canonical処理に相当する、商品schemaを有効にする標準スイッチはありません。JSON-LDの商品 schemaを標準搭載するBigCommerceのCornerstoneテーマとは異なり、SFCCのschemaは テンプレート／開発者の責任です。SFRAのリファレンスストアフロントには、テンプレートコードに 商品やパンくずのschemaが一部含まれますが、これは開発者が実装したものであり、管理画面の機能では ありません。schemaはチェックボックスではなく開発タスクとして扱い、canonical節で説明した ProductGroup／バリエーションのパターンを目標形にします。実装環境で可能なら、Googleが推奨する JSON-LD形式を使ってください。

特にヘッドレス構成では、レンダリング上の制約も設計に含めます。Googleは、構造化データを クライアント側のhydration時だけに挿入するのではなく、サーバーレンダリングされたHTMLに含める よう案内しています。PWA Kitストアでは、JSON-LDをSSR出力に含める必要があります。詳しくは ヘッドレスの節を参照してください。

Hreflangと複数サイト／ロケールの設計

まずB2BとB2Cを区別します。 Salesforceのわかりやすい専用hreflang機能 “Alternate Language Links”はB2B Commerceの機能であり、B2C Commerceには専用画面として 存在しません。検索結果や一部の代理店ブログでさえ、この2つのCloudを混同しています。B2C Commerceの hreflangは、専用の代替言語管理画面ではなく、前述したサイトマップの**“Include Alternate URLs”** チェックボックスで設定します。

現実的な実装方法は2つです。

1. サイトマップへ埋め込むhreflang： “Include Alternate URLs”を使います。単純ですが、 大規模環境ではサイトマップ1ファイル当たりのサイズ上限を超える可能性があります。
2. カスタム<link rel="alternate" hreflang="x">タグ： ページの<head>へ直接出力します。 ロケールとURLの組み合わせが多すぎてサイトマップ方式では収まらない場合に必要です。

標準的なhreflangの運用ルールも適用されます。Googleのローカライズ版ページに関するガイドでは、 各ページの<head>に、そのページ自身を含むバリエーションごとの<link>要素を一式入れ、 すべてのバージョンで同じ組み合わせを維持し、該当する言語がない場合のx-defaultも加えるよう 説明しています。Googleは、<head>内の<link>要素とXMLサイトマップのどちらでもhreflangを 宣言できるとしています。これはSFCCで使える2つの方法と一致します。

Bingに関する注記： Bingは歴史的にGoogleと同じ方法ではhreflangをサポートせず、代わりに HTMLのcontent-languageシグナルを参照してきました。そのため、サイトマップのチェックボックス だけでhreflangを実装したSFCCサイトでは、Bingが求める言語シグナルを渡せていない可能性があります。 ただしBingの公式見解には一貫しない報告もあるため、厳格なルールとして扱う前に現在の挙動を確認して ください。

複数サイト構成が深くなるほど、負担はさらに増えます。各サイトは独自のサイトマップジョブと robots.txtを持つため、新しいサイトとしてロケールを追加することは、言語ファイルを1つ増やす だけではなく、完全に新しいSEO設定面を増やすことです。（国際SEOの仕組みは hreflangクラスターを参照してください。）

ファセットナビゲーション／絞り込みURL

SFCCは、SEOに適したフィルター／絞り込みURLを標準では生成しません。ファセットナビゲーションで 整ったURLと適切なインデックス登録を実現するには、カスタム開発が必要です。絞り込みの組み合わせに 対する標準のcanonical／noindex動作もないため、判断基準を自分たちで構築します。次の切り分けは、 SFCCの絞り込み機能へ応用できる実務的な枠組みです。BigCommerceなど他のプラットフォームでも 有効です。クロール可能なフィルターURLが組み合わせ爆発を起こすという根本問題は共通だからです。

SFCCでも変わらない原則が2つあります。

• robots.txtがブロックするのはクロールであり、インデックス登録ではない。 DisallowしたURLも、 そこへリンクがあればインデックス登録される可能性があります。Googleはページを取得できないため、 canonicalやnoindexも読めません。パラメータールールとページ上のcanonical＋noindexを併用します。
• ページネーションへnoindexを付けない。 GoogleのECサイト向けガイドは、2ページ目以降を 1ページ目へ統合するのではなく、各ページに固有のcanonical URLを設定するよう案内しています。 noindexを使う対象はフィルター／並べ替えのバリエーションであり、ページネーションではありません。

（プラットフォーム共通の詳細は、Ecommerce SEOクラスターの ファセットナビゲーション を参照してください。）

PWA Kit（および後継のStorefront Next）におけるヘッドレスSEO

ヘッドレスのストアフロントは、SCAPI上に構築されManaged Runtimeへデプロイされる、Salesforceの 実績あるReactフレームワークPWA Kitか、2026年のB2C Commerceリリースサイクルで登場した 新しいStorefront Nextフレームワークで動作します。ここでのSEO課題は、ほぼ全面的に クロール可能性の問題であり、Salesforce公式ドキュメントもその観点から説明しています。

以下の手順を使う前に適用範囲を確認してください。 この節の?__server_onlyテスト、 app/ssr.jsのファイルパス、SSR／hydrationの具体的な接続方法は、従来のPWA Kit／Composable Storefront向けに書かれ、SalesforceのPWA Kit開発者ドキュメントで直接確認したものです。 Storefront Nextは別の構成です。PWA KitのReact Router 5に対し、React 19とReact Router 7の ファイルベースルーティング、fetch-then-renderのローダーモデルを採用しています。同じManaged Runtime上で動作しますが、独自のstreaming SSRからhydrationへの流れを持ちます。Salesforceは 「Migrate from PWA Kit to Storefront Next」 という専用ガイドを用意するほど、両者を明確に区別しています。Storefront Nextを使う場合は、 ?__server_onlyや以下のファイルパスがそのまま使えると考えないでください。この節をその構成の 絶対的な手順として扱う前に、Storefront Nextの公式ドキュメント で 同等のサーバーレンダリング検証手順を確認します。どちらでも根本原則は同じです。クローラーに 重要なコンテンツ（title、meta、canonical、主要本文、価格／在庫状況、JSON-LD）は、クライアント 専用のhydrationへ先送りせず、サーバーレンダリングまたはstreamingされたHTMLへ含める必要があります。

レンダリングの仕組み。 初回ページ読み込みでは、PWA Kitはサーバーサイドレンダリングを 使います。公式ドキュメントには、“For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” (翻訳) 重要な初回ページ 読み込みでは、パフォーマンス最適化に有効なキャッシュを利用できるため、サーバーサイドレンダリングを 使用します。とあります。SSRはExpressアプリ（app/ssr.js）を通じて実行され、“Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” (翻訳) Managed RuntimeのCDNキャッシュは、以前にレンダリングしたページを保存し、 即座にユーザーへ配信できます。と説明されています。初回読み込みは実際のHTMLなので、ここまでは クローラーにとって好都合です。

hydration境界がSEO上のリスクになります。 初回読み込み後は、“rendering duties are transferred from the server side to the client side through a process called hydration,” (翻訳) hydrationと呼ばれる処理を通じて、レンダリングの役割がサーバー側からクライアント側へ 移されます。その時点で*“your React app starts running in the user’s browser.”* (翻訳) Reactアプリがユーザーのブラウザー上で動作し始めます。コードは、サーバーとクライアントの両方で 安全に動くisomorphicなものでなければなりません。window.locationはクライアント専用、 req／resはサーバー専用です。さらに重要なのは、Salesforceが一部のコンテンツを意図的に クライアント専用としていることです。“Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” (翻訳) パーソナライズされたコンテンツや頻繁に変わるコンテンツなど、一部のコンテンツは最善の パフォーマンスを得るためにクライアント側でのみレンダリングする必要があります。ここにSEO上の 緊張関係があります。クローラーに重要なtitle、meta、canonical、主要本文、価格／在庫状況、 JSON-LDをこのクライアント専用領域へ入れると、クローラーから見えない可能性があります。

検証方法はSalesforce自身が示しています。 PWA Kitのベストプラクティスチェックリストは、 ホーム、PLP、PDPなどの入口ページに?__server_onlyを付け、“confirm that your server-rendered pages have enough data for crawlers and that the layout shift between server and client is small (ideally non-existent). This can help to improve your SEO ranking.” (翻訳) サーバーレンダリング されたページにクローラー向けの十分なデータがあり、サーバーとクライアント間のレイアウトシフトが 小さい（理想的には発生しない）ことを確認します。これはSEO順位の向上に役立つ可能性があります。 と案内しています。これはSFCCのヘッドレスSEOで最も有用な確認方法であり、開発者でなくても実行 できます。URLに?__server_onlyを付け、title、meta、canonical、主要本文、商品schemaがすべて 存在することを確認してください。

SCAPIでURLロジックを同期します。 getUrlMappingエンドポイントにより、ヘッドレス ストアフロントは*“support localized, user-friendly URLs based on URL rules and URL redirects set up in Business Manager”* (翻訳) Business Managerで設定したURLルールとURLリダイレクトに 基づいて、ローカライズされた使いやすいURLをサポートします。商品、カテゴリ（カテゴリの 絞り込みを含む）、コンテンツアセットのURLを解決し、ロケールが渡されなければサイトの初期ロケールへ フォールバックします。Salesforceは長いTTLを推奨しており、初期値は12時間です。これにより、 ヘッドレスフロントエンド用に別のURLシステムを保守せず、Business Managerで設定した同じURL Rulesと URL Redirectsを利用できます。

埋めるべき機能差。 Salesforce公式のPWA Kitドキュメントは、SEOをほぼSSR／クロール可能性の 問題として扱い、PWA Kitにおけるmetaタグ、canonical、hreflang、schemaにはほとんど触れていません （サイトマップには別の専用ドキュメントがあります）。ページ内タグは、実装チームのhead管理層 （React Helmetまたは同等の仕組み）が担います。担当者がいなければ、技術的にはクロールできる PWA Kitストアでも、title、canonical、schemaが欠けたまま公開されかねません。 （ヘッドレス共通の仕組みはJavaScript SEO と ヘッドレスCMS SEO を参照してください。）

SFCCと他プラットフォームの率直な比較

Shopify、BigCommerce、Magento、WooCommerce、PrestaShopと比較すると、SFCCはエンタープライズ 領域に位置します。ホスティング型プラットフォームの中でも、サイト別に編集できるrobots.txt、 URL Rules + Aliases、canonicalを前提としたバリエーション、ルールベースのmetaタグなど、標準の SEO設定自由度は特に高い一方、使いこなすには最も深いプラットフォーム知識が求められます。 ShopifyがURLプレフィックスを固定し、robots.txtをテンプレートの背後へ隠し、BigCommerceが プリセットのURL構造と標準JSON-LDを提供するのに対し、SFCCは素材となる設定手段を渡し、 Business Managerを理解していることを前提とします。「初期状態でSEOが良好」なプラットフォーム ではなく、「意図的に設定すれば優れたSEOを実現できる」プラットフォームです。その基準で評価して ください。

AI要約

Advanced版の要点は次のとおりです。

• Salesforce Commerce Cloudはエンタープライズ向けのホスティング型SaaS ECです。正式名称は B2C Commerce、旧称はDemandware、通称はSFCC。SEO設定のほぼすべては Business Manager（Merchant Tools → サイト → SEO）にあります。
• ストアフロントは1種類ではなく4世代あります。 旧来のSiteGenesis、現行のSFRA、 ヘッドレスのPWA Kit（Composable Storefront）、新しいStorefront Next（2026年リリース サイクルでGA）です。管理パスやレンダリング方式が異なるため、修正前に構成を特定します。
• 標準機能： サイト別に編集できるrobots.txt（上限50k chars＝約5万文字）、定期ジョブによるXML サイトマップ、ロケール対応URL用のURL Rules + Hostname Aliases、canonical前提の マスター／バリエーション商品、Meta Tag Rules、BM内URL変更時の自動リダイレクト、PWA Kit SSR。
• 設計上の分岐： 1サイトに複数ロケールを持たせるか、複数サイトに分けるか。 各サイトはサイトマップ、robots.txt、メタルール、URLルールを持つ独立したSEO設定面です。
• canonicalが差別化点： バリエーション商品URLをマスターへcanonical化します。これはGoogleの ProductGroup／hasVariant／isVariantOfとほぼ1対1で対応します。canonical、サイトマップ、 hreflang、内部リンクの参照先を同じマスターURLにそろえます。
• 個別実装： hreflang（B2C専用画面はなく、サイトマップの”Include Alternate URLs”か カスタム<link>タグを使用）、ファセット／絞り込みURL、構造化データ、ドメイン単位の 複数ロケール向けrobots.txt、H1テンプレート。
• サイトマップ： インスタンスタイプごとに設定し、StagingからProductionへ複製できません。 Googleはchangefreq／priorityを無視するため、lastmodを正確に保ちます。
• リダイレクト： URL Redirectsは競合時にURL Rulesより優先されます。SFRA再公開では、 リダイレクト戦略がローンチ時SEO作業の~60–70%を占めます。
• PWA KitとStorefront Next： SSRは必要ですが十分ではありません。クライアント専用コンテンツは クロールされない可能性があります。PWA Kitでは**?__server_onlyで入口ページを検証し、 React Router 7を使う別フレームワークのStorefront Nextでは同等の手順を確認します。 URLロジックはSCAPIのgetUrlMapping**で同期します。
• 誤解： 「SFCCではSEOができない」は誤りです。プラットフォームは強力で、制約になるのは その扱いへの不慣れです。

公式ドキュメント

SalesforceとGoogleの一次資料です。

Salesforce — B2C Commerce（ヘルプ／Business Manager）

• B2C CommerceのSEOと検出可能性 — canonical、リダイレクト、サイトマップ、robots、metaタグ、URL構文を扱うSEO設定の中心ページ。
• B2C CommerceのSEOベストプラクティス。
• B2C CommerceのSEO URLを設定する — URL Rulesの仕組み。
• B2C CommerceのCanonical URL Tagsを作成する — バリエーション → マスターのcanonicalに関する推奨。
• B2C Commerceの商品種別とバリエーション — マスター／バリエーションのデータモデル。
• B2C Commerceのサイトマップ — 定期サイトマップジョブ。
• Business ManagerでRobots.txtファイルを生成する。
• B2C CommerceのHostname Aliases。

Salesforce — 開発者ドキュメント（PWA Kit／SCAPI、直接確認済み）

• PWA Kitのレンダリング（SSR／hydration） — 初回読み込みのSSR、hydration境界、isomorphicコード。
• PWA Kit／Composable Storefrontのベストプラクティスチェックリスト — ?__server_onlyによるクロール可能性テストとURL／リダイレクト移行計画。
• サイトマップでSEOを改善する（Composable Storefront） — ヘッドレスのサイトマップ機構とSCAPIアップロードエンドポイント。
• URL Mapping／getUrlMapping（SCAPI） — ヘッドレスのURL解決と「URL Redirectsが優先される」というルール。
• Storefront Next：はじめに と PWA KitからStorefront Nextへ移行する — Salesforceの新しいヘッドレスReactフレームワーク（React 19／React Router 7）。2026年リリースサイクルでGA。PWA Kitの手順がそのまま使えると考える前に、SEOに重要な仕組みをここで確認してください。

Salesforce — Trailhead（静的な学習モジュール）

• SEO URLを理解する（ベストプラクティス）。
• SEO URLを設定する — 小文字、空白の区切り文字、カテゴリ／商品パターン。
• Hostname Aliasesを設定する。

Google

• 重複URLを統合する（canonicalization） — シグナルの強さ、併用、指定を矛盾させないというルール。
• 商品バリエーションの構造化データ（ProductGroup） — variesBy／hasVariant／isVariantOf、nestedとseparateのパターン。
• ページのローカライズ版（hreflang） — <link>とサイトマップ、相互参照、x-default。
• 構造化データの概要 — 推奨形式としてのJSON-LD。

出典からの引用

Salesforceの開発者ドキュメントとGoogleによる公式見解を、引用箇所へのディープリンクとともに 掲載します。SalesforceのJavaScriptでレンダリングされるヘルプ／Business Manager画面にある URL Rulesの仕組み、canonicalの推奨、robots.txtの挙動、Meta Tag Rulesについては、自動検証が 難しいため、Advancedタブでは引用ではなく要約しています。逐語的な記述として扱う前に、 実際のBusiness Managerまたはレンダリング済みドキュメントで正確な文言を確認してください。

Salesforce — PWA Kit Rendering（開発者ドキュメント）

• “For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” (翻訳) 重要な初回ページ読み込みでは、パフォーマンス最適化に有効なキャッシュを利用できるため、サーバーサイドレンダリングを使用します。 引用箇所へ移動
• “Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” (翻訳) Managed RuntimeのCDNキャッシュは、以前にレンダリングしたページを保存し、即座にユーザーへ配信できます。 引用箇所へ移動
• “After the first page load, rendering duties are transferred from the server side to the client side through a process called hydration.” (翻訳) 初回ページ読み込み後、hydrationと呼ばれる処理を通じて、レンダリングの役割がサーバー側からクライアント側へ移されます。 引用箇所へ移動
• “Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” (翻訳) パーソナライズされたコンテンツや頻繁に変わるコンテンツなど、一部のコンテンツは最善のパフォーマンスを得るためにクライアント側でのみレンダリングする必要があります。 引用箇所へ移動

Salesforce — PWA Kit Best Practices Checklist（開発者ドキュメント）

• ?__server_onlyを使ったクロール可能性のテストについて：“confirm that your server-rendered pages have enough data for crawlers and that the layout shift between server and client is small (ideally non-existent). This can help to improve your SEO ranking.” (翻訳) サーバーレンダリングされたページにクローラー向けの十分なデータがあり、サーバーとクライアント間のレイアウトシフトが小さい（理想的には発生しない）ことを確認します。これはSEO順位の向上に役立つ可能性があります。 引用箇所へ移動

Salesforce — Improve SEO with a Sitemap（開発者ドキュメント）

• “Sitemaps provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.” (翻訳) サイトマップは検索クローラーに、インデックス登録するページとサイト階層に関する指示を与え、SEO順位の向上につながる可能性があります。 引用箇所へ移動

Salesforce — URL Mapping／SCAPI（開発者ドキュメント）

• “If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.” (翻訳) SEO用のURLリダイレクトとURLルールが競合する場合は、URLリダイレクトが優先されます。 引用箇所へ移動

Google — canonical化

• “Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel=“canonical”).” (翻訳) 異なるcanonical指定手法を使って、同じページに別々のURLをcanonicalとして指定しないでください（たとえば、サイトマップではあるURLを指定し、同じページのrel=“canonical”では別のURLを指定しないでください）。 引用箇所へ移動
• “When linking within your site, link to the canonical URL rather than a duplicate URL.” (翻訳) サイト内でリンクする際は、重複URLではなくcanonical URLへリンクしてください。 引用箇所へ移動

Google — 商品バリエーションの構造化データ

• “use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” (翻訳) このようなバリエーションをグループ化するには、variesBy、hasVariant、productGroupIDの各プロパティとともにProductGroupクラスを使用します。 引用箇所へ移動

Salesforce Commerce Cloud（SFCC）SEOチェックリスト

優先順位を付け、各項目を制御するBusiness Manager画面ごとに整理しています。 上の項目ほど大きな効果が見込めます。

影響度：高

• バリエーション → マスターのcanonicalを確認 — すべてのバリエーション商品PDPが マスター（ベース）商品へcanonical化され、サイトマップと内部リンクも同じマスターURLを 指している。手法ごとに指定を矛盾させない。
• ファセット／絞り込みURLに対応 — パラメーターの切り分けに従い、絞り込みの組み合わせへ canonical＋noindexを設定する。SFCCの標準機能ではないため、カスタム開発が必要。
• PWA Kitのクロール可能性を検証（ヘッドレスのみ）— ホーム、PLP、PDPを ?__server_only付きで読み込み、title、meta、canonical、主要本文、価格、JSON-LDが すべてSSR出力に含まれることを確認。
• 移行時のリダイレクトマップ（SFRA再公開／ヘッドレス移行）— 完成済みで、ハードコードした パスではなくオブジェクトIDを参照している。これはローンチ時のSEO作業の60–70%を占める。

Business Managerの設定（Merchant Tools → サイト → SEO）

• URL Rules／Aliases — 小文字へ統一し、空白の区切りにはハイフン（マイナス）を使用。 階層に応じてcategoryとcategory-pathを選び、商品はカテゴリパスではなくドメインへ 割り当てる。エイリアスファイルでversion 1を宣言する。
• Default-Start／Home-Showパイプラインをマッピングし、www／non-wwwの重複する ホームページを生成しない。
• サイトマップジョブを定期実行 — 日次レプリケーション後のアクセスが少ない時間帯に設定。 インスタンスタイプごとに個別設定（Staging／Production／Development）し、lastmodを正確に 保つ。Googleが無視するchangefreq／priorityは調整しない。
• Robots.txtを最小限かつ意図的に設定。Business Managerのサイト設定とカートリッジの 静的ファイルのどちらを使うか把握し、カートリッジ単位の変更後は静的キャッシュを無効化する。 サブフォルダー単位ではなくドメイン単位であることも考慮する。
• Meta Tag Rulesで上書きとフォールバックを併用する構文 （${IF Category.pageTitle THEN … ELSE …}）を設定。接続語を言語／国ごとにローカライズし、 H1のテンプレート化にはカスタム開発が必要であることを忘れない。
• リダイレクト — 用途ごとにURL Redirects／Static Mappings／Dynamic Mappingsを選ぶ。 競合時はURL RedirectsがURL Rulesより優先される。

構造化データ（開発者／テンプレート層）

• Product／ProductGroup／パンくずのJSON-LDをテンプレートへ実装する（BMの標準スイッチはない）。 hydration時だけに挿入せず、サーバーレンダリングされたHTMLに含める。

国際対応（複数サイト／複数ロケールのみ）

• hreflangを実装 — サイトマップの”Include Alternate URLs”またはカスタム<link>タグを 使用。相互参照を設定し、各ページ自身とx-defaultを含む一式をすべてのページへ揃える。
• B2B Commerceの”Alternate Language Links”機能をB2Cと混同しない （B2Cにはhreflang専用画面がない）。
• 歴史的にGoogleと同じ方法ではhreflangを使わないBing向けに、content-languageシグナルを検討する。
• 各サイトのサイトマップジョブ、robots.txt、Meta Tag Rulesを同期する。

5つの思考モデル

1. 標準の構成要素か、自分たちで実装するものか。 SFCCのSEO作業は、Business Managerで設定できる構成要素（robots、サイトマップ、URL Rules、 canonical対応のバリエーション、Meta Tag Rules、自動リダイレクト）か、自分たちで実装するもの （hreflang、ファセットURL、schema、H1テンプレート、ヘッドレスのページ内タグ）に分かれます。 どちらに属するかが分かれば、管理画面を設定すべきか、開発者へ要件を渡すべきか判断できます。

2. サイトかロケールか = SEO設定面の数。 複数ロケールを持つ1サイトか、複数サイトか。各サイトは、サイトマップジョブ、robots.txt、 Meta Tag Rules、URL Rulesを持つ完全に独立したSEO設定面です。この判断がほかのすべての設定作業を 増減させるため、最初に決めます。

3. マスター／バリエーション = ProductGroup。 SFCCのマスター商品はGoogleのProductGroup、バリエーション商品はhasVariant／isVariantOfの 構成要素です。バリエーションをマスターへcanonical化し、ProductGroupとしてマークアップし、 canonical、サイトマップ、hreflang、内部リンクのすべてを同じマスターURLへ揃えます。 1つのモデル、2つのシステム、1つの優先URLです。

4. robots.txtはクロールを制御し、canonical／noindexはインデックス登録を制御する。 robots.txtは最小限に保ちます。インデックス登録の制御に過度に依存するのはアンチパターンです。 robots.txtがブロックするのはクロールだけであり、ドメイン単位なので特定ロケールのサブフォルダーを 正確に狙えません。インデックス登録の判断にはcanonicalとnoindexを使います。

5. PWA Kitでは、SSRは必要だが十分ではない。 ヘッドレスのクロール可能性で問うべきは「SSRを使っているか」ではなく、「SEOに重要なコンテンツが SSR出力にあるか、クライアント専用にされていないか」です。?__server_onlyテストが決定的です。 title、canonical、価格、JSON-LDが出力にないなら、クローラーにも見えません。

Salesforce Commerce Cloud SEOチートシート

Business Manager内の設定場所（Merchant Tools → サイト → SEO → …）

URL Rulesの要点

• Lower Caseを有効にし、空白には%20やアンダースコアではなく**ハイフン（マイナス）**を使う。
• 深い階層にはcategory、異なる親の下でカテゴリ名が重複する場合はcategory-pathを使う。
• 商品ID＋.htmlは自動付加される（カスタム開発なしには削除できない）。
• 商品はカテゴリパスではなくドメインへ割り当てる。
• URLにsc.html、ページ種別を示す文字列、demandwareという語を含めない。

Meta Tag Rulesの構文

• 基本：${Category.Name} | Example Brand
• 上書き＋フォールバック：${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name}
• H1のテンプレート化：ルールでは非対応。カスタム開発が必要。

リダイレクト

• 恒久的な移転は301（カスタム開発では308）、一時的な移転は307。
• 競合時はURL RedirectsがURL Rulesより優先される。
• ハードコードしたパスではなくオブジェクトIDを指定する。

PWA Kit（ヘッドレス）

• 入口ページを**?__server_only**付きでテストし、クローラーから見えるコンテンツを確認する。
• SEOに重要なコンテンツをクライアント専用領域へ入れない。
• getUrlMapping（SCAPI）でBMのURL Rules／URL Redirectsを再利用する。TTLは長くし、初期値は12h。

避けること

• Googleが無視するchangefreq／priorityの調整をToDoに残さない。
• B2Bの”Alternate Language Links”をB2Cのhreflang機能と混同しない（B2Cには専用画面がない）。
• インデックス削除や特定ロケールのサブフォルダー制御をrobots.txtだけに頼らない。
• SSRを使っているという理由だけでPWA KitのSEOは安全だと思い込まない。
• Default-Start／Home-Showのマッピングを省略しない（ホームページが重複する）。

Salesforce Commerce Cloud SEOで避けるべき失敗

Googleが無視するsitemapフィールドの調整

問題点： Googleはchangefreqとpriorityの両方を無視するため、調整に時間を使っても Googleのクロールは改善しません。代わりに行うこと： lastmodを正確に保ち、レプリケーション後に 生成を実行し、節約した時間でサイトマップに実際に掲載されるcanonical URLを確認します。

B2Bのhreflang画面をB2Cの機能だと考える

問題点： B2C Commerceには、B2B Commerce専用のAlternate Language Links機能がありません。 別製品の手順に従うと、B2Cストアに有効なhreflangが実装されません。代わりに行うこと： B2Cの サイトマップにあるInclude Alternate URLsを使うか、相互参照する<link rel="alternate">タグを 実装します。

robots.txtをインデックス削除ツールとして使う

問題点： Disallowが制御するのはクロールであり、インデックス登録ではありません。さらに、 クローラーがページ単位のcanonicalやnoindexを確認できなくなります。複数ロケールでドメインを 共有する場合、特定の1ロケールだけを対象にもできません。代わりに行うこと： robots.txtを 最小限に保ち、インデックス状態の判断にはcanonicalまたはnoindexを使います。

SSRを使うPWA Kitは必ずクロールできると思い込む

問題点： PWA Kitでも、価格、本文、metadata、JSON-LDがクライアント専用層に残ることがあります。 代わりに行うこと： 代表的なホーム、PLP、PDPのURLに?__server_onlyを付け、クローラーに 重要な要素がすべて存在することを確認します。

Default-StartとHome-Showを未マッピングのままにする

問題点： これらのパイプラインにより、ホスト名のバリエーションごとに重複したホームページが 公開される可能性があります。代わりに行うこと： 両方のパイプラインを明示的にマッピングし、 各ホスト名をクロールして1つのホームページへ統合されることを確認します。

PWA Kitのレンダリング変更が機能したことを証明する

デプロイ後にサーバー専用レスポンスを比較する

実施するテスト： 変更したホーム、PLP、PDPのURLを?__server_only付きで開き、返された ソースにtitle、meta description、canonical、主要本文、価格または在庫状況、JSON-LDがあるか 確認します。

期待される結果： リリースの影響を受けたSEO上の重要要素が、hydrationを待たずにすべて サーバーレスポンスへ含まれています。

失敗時の解釈： 欠けている要素は依然としてクライアント側だけで取得またはレンダリングされるか、 サーバー側のデータ依存関係が失敗しています。

監視期間： デプロイ直後に実施し、リリースに対応するManaged Runtimeのキャッシュが 更新された時点でもう一度実施します。

ロールバック条件： リリース前には存在したcanonical、主要コンテンツ、商品の在庫状況、 構造化データブロックのいずれかがサーバー専用レスポンスから消えた場合は、変更を戻します。

Googleが同じ重要コンテンツを受信することを確認する

実施するテスト： 同じ代表URLをGoogle Search ConsoleのURL Inspectionで調べ、テスト済みHTMLを 確認します。

期待される結果： 検査したHTMLに、?__server_onlyレスポンスと同じ重要コンテンツとタグが 含まれています。

失敗時の解釈： Googleが、直接テストしたものとは異なる、キャッシュ済み、ブロック済み、 またはその他の別レスポンスを受け取っています。

監視期間： すぐにライブテストを実施します。インデックス登録結果を判断する前に、通常の 再クロールに必要な時間を確保します。

ロールバック条件： リリース前には存在したインデックス可能なコンテンツまたはcanonical シグナルがライブテストで繰り返し失われる場合は、変更を戻します。

Salesforce Commerce Cloud SEO向けツール

• Business Manager — プラットフォーム標準の管理画面です。URL Rules、Aliases、Sitemaps、 Robots、Meta Tag Rules、URL Redirects、canonicalなど、すべてのSEO設定がMerchant Tools → サイト → SEOにあります。
• ?__server_only URLパラメーター — Salesforce標準のヘッドレス向けクロール可能性テストです。 PWA Kitの任意のページへ付けると、hydration前にサーバーが何をレンダリングしたか正確に確認できます。 SFCCのヘッドレスSEOで最も重要なツールであり、無料で標準搭載されています。
• Google Search Console — サイトマップの送信、PWA Kitページのレンダリング済みHTMLを確認する URL Inspection、hreflang用のInternational Targeting、Crawl Statsを提供します。Googleが実際に どう処理しているかを確認する基準です。
• Bing Webmaster Tools — 2つ目のサイトマップ送信先であり、クロール制御にも使えます。 BingはGoogleと同じ方法ではhreflangを使わないため、content-languageの処理もここで確認します。
• Screaming Frog／Ahrefs Site Audit — ストアをクロールし、絞り込みURLの急増、マスターへ canonical化されていないバリエーションPDP、リダイレクトチェーン、未マッピングのパイプラインに よる重複ホームページを検出します。SFCC固有の問題を見つけるための手段です。
• URL Inspection（GSC） — PWA Kitページのレンダリング済みHTMLにtitle、canonical、価格、 JSON-LDが実際に含まれるかを確認します。?__server_onlyと同じ観点をGoogle側から検証できます。
• Rich Results Test／Schema Markup Validator — ProductGroup／バリエーションのJSON-LDを検証します。 SFCCのschemaは開発者が実装し、信頼できる標準スイッチがないため、出力そのものを確認します。

時間を使う価値のあるリソース

サイト内の関連記事

• ファセットナビゲーション — SFCCで最も重要な個別実装課題を、プラットフォームに 依存しない形で掘り下げています。SFCCの絞り込みURLにはカスタム開発が必要です。
• Canonicalization — バリエーション → マスターというルールの仕組み。
• 商品バリエーションSEO — SFCCのマスター／バリエーションモデルと対応する ProductGroup／hasVariant／isVariantOfパターン。
• hreflang — hreflangを自動生成しないSFCCで必要となる国際SEOの仕組み。
• ヘッドレスCMS SEO — PWA Kitの SSR／hydration節に直接関係する解説。

Salesforce公式

• B2C CommerceのSEOと検出可能性 — Business Manager内のSEO設定ハブ。
• PWA Kit Rendering と PWA Kit Best Practices Checklist — SSR／hydrationと?__server_onlyテスト。
• Improve SEO with a Sitemap と URL Mapping／getUrlMapping（SCAPI）。

Google公式

• 商品バリエーションの構造化データ と 重複URLを統合する。
• ページのローカライズ版（hreflang）。

筆者の関連記事

• Webサイト移行を成功させるにはチェックリストだけでは足りない — SFRAの再公開やPWA Kitへの移行にも直接当てはまります。
• 11種類のリダイレクトとSEOへの影響 と SEOにおける301と302の違い — 前述した301／307／308の使い分け。
• JavaScript SEOの問題とベストプラクティス — PWA Kitのレンダリング面を解説。

業界の参考資料（SFCC固有の実務解説。実際のドキュメントでも確認してください）

• Resignal — SFCC SEO Masterclass Part 1：ホスト名とURL構造 — URL RulesとAliases、Default-Start／Home-Showの落とし穴、version 1の注意点を詳しく扱う第三者資料。
• Resignal — SFCC SEO Masterclass Part 2：クロールとリダイレクトツール — サイトマップの自動生成、changefreq／priorityの廃止、3つのリダイレクトツール。
• Resignal — SFCC SEO Masterclass Part 3：ページ内SEO — Meta Tag Rulesの構文、上書きとフォールバックの併用、H1の制約。
• NOVOS — Salesforce eCommerce SEO完全ガイド — 商品をドメインへ割り当てるURL設計と、オブジェクトIDを使うリダイレクトのベストプラクティス。
• Eskimoz — Salesforce Commerce CloudでSEOは可能か — 制約はプラットフォームではなく、不慣れさにあるという捉え方。
• Acxiom — SFCC SEO：SFRA公開前の重要事項 — リダイレクト戦略がローンチ作業の60–70%を占めるという見方。

理解度チェック：Salesforce Commerce Cloud SEO

Salesforce Commerce CloudのSEOに関する5問です。各問の答えを選び、結果を確認してください。

変更履歴