ShopifyとWordPress連携の設計ガイド｜Buy Button・サブドメイン・ヘッドレスの選び方

「shopify wordpress 連携」で調べる人は、単にボタンの貼り付け手順を知りたいだけではないはずです。

既存WordPressに記事、ブランドページ、導入事例、LPがある。そこへEC機能を足したい。WooCommerceを使っているが、決済、在庫、プラグイン更新、注文管理が重くなってきた。Shopifyに寄せたいが、WordPressのSEO資産は捨てたくない。こういう状況が多いでしょう。

このときに失敗しやすいのは、「WordPressにShopifyの商品を表示できるか」から考え始めることです。

• WordPressの記事とShopify商品ページに似た説明があり、更新がズレる
• 在庫切れなのにWordPress側の購入導線が残る
• example.com と shop.example.com でGA4のセッションが分断される
• WooCommerceの商品URL、注文、顧客をいつShopifyへ寄せるか曖昧になる

Shopify公式のSell on WordPressページでは、WordPress EditorからShopifyの商品やコレクションを追加し、在庫や分析までShopifyで扱う流れが説明されています。公式App StoreのSell on WordPressでも、商品、注文、在庫を同期し、Shopify adminで管理する趣旨が示されています。

一方、Buy Buttonは、外部サイトやブログに商品写真、説明、価格、購入導線を埋め込むための販売チャネルです。Shopify公式ヘルプでは、Buy Button sales channelはShopify subscription plansに含まれ、注文はShopify adminから追跡できると説明されています。

手順の概要としては、Tsun社のShopifyとWordPressの連携方法ガイドや、BiNDecのBuy Buttonを使う設定手順も参考になります。ただし、この記事では手順よりも、実務で壊れにくい設計判断に絞ります。

ShopifyとWordPress連携は、WordPressを無理にEC本体へする作業ではありません。WordPressをCMS、Shopifyを商品・在庫・注文・決済のsystem of recordとして分ける設計です。

まず決める前提：WordPressはCMSか、EC本体か

最初に決めるべきなのは、どのプラグインを使うかではありません。WordPressが担う範囲と、Shopifyが担う範囲です。

領域	WordPressに寄せるもの	Shopifyに寄せるもの	曖昧にすると起きること
コンテンツ	記事、ブランドページ、導入事例、比較記事、LP	商品ページの販売情報、コレクション	同じ商品説明を2か所で更新する
商品データ	紹介文、用途説明、比較表	商品名、SKU、variant、価格、在庫、販売可否	WordPressに古い価格や在庫表示が残る
注文・決済	原則持たない	カート、チェックアウト、注文、決済、返金	WooCommerceとShopifyに注文が分散する
SEO・計測	記事URL、内部リンク、CTAクリック	商品URL、purchase、広告CV	検索流入と売上の突合が崩れる
保守	WordPress本体、テーマ、プラグイン、バックアップ	Shopify設定、販売チャネル、アプリ、決済、配送	障害時に誰が直すか決まらない

既存WordPressに検索流入があるなら、WordPressは残す価値があります。ただし、WooCommerceを残してShopifyも入れると、決済・注文・在庫の責任が二重になります。移行期間を除けば、ECの正本はShopifyへ寄せた方が管理しやすいです。

4方式比較：Buy Button・Sell on WordPress・サブドメイン・ヘッドレス

WordPressとShopifyの連携方式は、大きく4つに分けて考えます。

方式	何をするか	向いているケース	注意点
Buy Button	WordPressの記事やLPに、Shopifyの商品・コレクションの購入コードを埋め込む	少数商品、記事内CTA、テスト販売	商品公開と埋め込み台帳を管理する
Sell on WordPress	Shopify公式のWordPressプラグインと販売チャネルで商品を追加する	WordPress Editorから商品ブロックを使いたい	プラグイン、テーマ互換、access tokenを管理する
Shopifyサブドメイン	shop.example.com などにShopifyストアを置き、WordPressから送客する	Shopify標準テーマ、検索、カート、チェックアウトを早く安定させたい	DNS、内部リンク、GA4クロスドメインを整える
Headless/Storefront API	WordPressやNext.jsなどのフロントからStorefront APIで商品・カートを扱う	ブランド体験、独自検索、複数CMS統合が必要	API、カート、キャッシュ、監視を自前で持つ

Shopify公式のSales channelsでは、販売チャネルを接続すると商品、注文などをShopify adminから管理できると説明されています。つまり、WordPressに表示する場合でも、商品・注文・在庫の運用はShopify adminを中心に考えます。

Headless構成では、Shopify公式のStorefront API referenceにあるように、商品、コレクション、カート、チェックアウト導線をGraphQLで扱えます。ただし、これはBuy Buttonより自由な代わりに、キャッシュ、アクセストークン、カート状態、エラー監視を自分たちで設計する方式です。詳しくはShopify Storefront APIで作るヘッドレスEC設計で整理しています。

公式情報から見る実装前提

2026年7月3日時点で確認した公式情報を前提にすると、少なくとも次の点は実装前に押さえます。販売チャネル、アプリ、プラン条件は変わり得るため、本番導入前には対象ストアの管理画面と公式ヘルプで再確認します。

公式情報	設計への意味
Buy Buttonは外部サイトやブログに商品を置くための販売チャネルで、Shopify subscription plansに含まれる	WordPress記事内CTAには使いやすいが、EC本体のナビ、検索、回遊まで任せるものではない
Creating a Buy Buttonでは、商品またはコレクション用のコードを作成し、Webページやブログへ貼り付ける	どのWordPressページにどの商品コードを貼ったか台帳化する
Buy Buttonを作る前に、商品をShopify Adminに追加し、Buy Button sales channelで利用可能にする必要がある	Shopifyに商品があるだけではWordPress側に出ない
Connect Shopify to WordPressでは、Shopify access tokenをWordPress側プラグインに設定する	WordPress管理者がShopify tokenを扱うため、権限、保管、担当変更時の棚卸しが必要
Sell on WordPressは、商品、注文、在庫を同期し、Shopify adminで管理する趣旨の公式販売チャネル	WordPress側は表示面、Shopify側はcommerce system of recordとして分ける
Buy Button channelはShopify公式の無料アプリで、商品やコレクションを外部サイトやブログに追加できる	少額・少数商品から始めるには軽いが、長期運用では表示崩れ、計測、カートUXの検証が必要

Buy ButtonもSell on WordPressも「WordPress側にShopifyの販売導線を出す」仕組みです。商品・在庫・注文・決済の正本をWordPressへ移す仕組みではありません。

商品・在庫・注文データの所有権

WordPressとShopifyを併用するなら、商品・在庫・注文の所有権を明文化します。

データ	正本にする場所	WordPress側の扱い	Shopify側の扱い
商品名・SKU・variant	Shopifyまたは外部PIM	紹介文として扱い、正式値は持たない	商品マスタ、variant、販売可否を管理
価格・在庫	ShopifyまたはWMS	直書きは避ける。書くなら更新担当を決める	正式価格、割引、税、在庫、販売停止
商品説明	役割で分ける	用途、比較、導入文脈、SEO本文	購入判断に必要な仕様、配送、注意事項
注文・決済	Shopify	原則持たない	注文、決済、返金、キャンセル
顧客	Shopify、CRM、MAで役割分担	問い合わせ、会員記事、メルマガがあれば別設計	購入者、配送先、注文履歴、同意

WordPressに商品を表示しても、商品マスタの責任までWordPressへ戻してはいけません。正式な価格、在庫、注文、決済はShopify側で管理する前提にします。

商品データの外部連携や在庫・会計との同期が必要な場合は、Shopify API連携の設計方法も合わせて確認します。WordPress連携はフロントの話に見えますが、実際には受注後の出荷、会計、CRMまで影響します。

SEO・canonical・ドメイン・内部リンク設計

WordPressを残す最大の理由は、既存のSEO資産とコンテンツ運用です。だからこそ、Shopify連携ではURLとcanonicalを雑に扱わない方がよいです。

方式	URL/canonical	内部リンク	主な注意点
Buy Button	記事はWordPress URL。Shopify側商品ページとの重複を避ける	記事本文から商品CTA、関連記事、比較記事へつなぐ	商品説明を両方で重複させすぎない
Sell on WordPress	WordPressページ内に商品ブロックを置き、index対象をWordPress中心に決める	WordPress内のカテゴリ、タグ、記事群から商品へ送客	プラグイン表示とSEOプラグインの相性を確認する
Shopifyサブドメイン	www.example.comをWordPress、shop.example.comをShopifyにする	WordPress記事からShopify商品へ。Shopifyから記事へ戻す	GA4、Search Console、広告LP、リダイレクトを整える
Headless	生成URL単位でindex対象を決める	商品、記事、検索、カテゴリを同じ情報設計で作れる	sitemap、structured data、キャッシュ更新を自前で設計する

Shopifyサブドメインを使う場合、公式ヘルプのConnecting a third-party subdomain to Shopifyのように、DNSとShopify admin側で接続します。通常の運用では、WordPressとShopifyを同じルートドメインの同じパス配下に自然に共存させるより、サブドメインで分ける方が現実的です。

SEOで重要なのは、「WordPressとShopifyのどちらが強いか」ではありません。検索流入を受けるページと、購入を完了するページを分けることです。旧WooCommerce商品URLは、流入・被リンク・広告LPを見て、残す、リダイレクトする、noindexにする、のいずれかを決めます。

カート・チェックアウトUXとGA4計測

WordPressとShopifyを分けると、購入体験は「同じサイトに見えるか」よりも、「迷わずカートとチェックアウトを完了できるか」が重要になります。

方式	カート・チェックアウトUX	QAで見ること
Buy Button	WordPressページ上でカート追加、または直接Shopify checkoutへ遷移	variant、数量、在庫切れ、複数ボタン、スマホ表示
Sell on WordPress	WordPress Editorから商品を追加し、Shopify checkoutで購入	表示崩れ、商品説明の長さ、接続解除時の表示、token権限
Shopifyサブドメイン	Shopifyテーマのカート、商品検索、チェックアウトを使う	ヘッダー/フッター、パンくず、戻る導線、決済別表示
Headless	Storefront APIで独自カートを作り、checkoutUrlへ渡す	cart mutation、buyer identity、checkoutUrl、キャッシュ、エラー監視

計測では、WordPressとShopifyを別ドメインまたはサブドメインに分ける場合に、GA4の設計が重要になります。Google公式のGA4 cross-domain measurementは、複数ドメインにまたがる計測を扱うための設定です。WordPressからShopify checkoutへ移動する導線では、同じユーザーのセッションとして見えるか、自己参照が出ないか、purchaseが欠けないかを確認します。

計測対象	WordPress側で見ること	Shopify側で見ること	異常例
商品CTAクリック	記事、LP、比較表、CTA位置	遷移先商品、collection、checkout	クリックは多いがカートが増えない
checkout開始	Shopify checkoutへの遷移	begin_checkout、決済画面到達	サブドメイン遷移で参照元が自社ドメインになる
purchase	注文番号、金額、商品明細	Shopify注文、GA4 purchase、広告CV	Shopify注文よりpurchaseが多い、または少ない
記事貢献	記事閲覧、商品リンククリック	商品閲覧、注文	記事経由の売上が参照元分断で見えない

ShopifyのGA4設定は、Google & YouTubeアプリ、GTM、カスタムピクセル、広告タグが混在しやすい領域です。詳しくはShopifyのGA4設定を計測運用まで設計するで整理しています。WordPress連携では、特にクロスドメイン、purchase重複、広告CVの主/補助、UTM、内部リンククリックをセットで見ます。

WooCommerceからShopifyへ段階移行する

既にWooCommerceで販売している場合、いきなり全商品・全注文をShopifyへ切り替えると危険です。まずはWooCommerceを「移行元」、Shopifyを「新しいcommerce system of record」として段階移行します。

Shopify公式のMigrate from WooCommerceでは、商品、顧客、履歴注文、レビューなど、どのデータを移すかを決め、CSV、Store Migration app、第三者アプリ、移行専門家などの選択肢を検討する流れが説明されています。商品CSVでは、Shopify側の形式に合わせた編集、import後の確認、販売チャネルへの公開状態の確認も重要です。

フェーズ	やること	完了条件
0. 棚卸し	WooCommerceの商品、SKU、注文、顧客、レビュー、URL、プラグインを一覧化	移す/残す/捨てるデータが決まる
1. Shopify商品基盤	商品CSV、variant、画像、価格、在庫、collectionをShopifyへ取り込む	Shopify admin上で商品データが確認できる
2. 小さな販売導線	WordPress記事にBuy ButtonまたはSell on WordPressで一部商品を表示	テスト注文、在庫更新、通知、返金まで確認できる
3. 注文正本の切替	新規注文をShopifyへ寄せる	決済、配送、税、通知、会計連携がShopify前提になる
4. URLと旧機能整理	旧商品URL、canonical、リダイレクト、不要プラグイン停止を進める	WordPressをCMSとして保守できる

WooCommerceからShopifyへ移る理由が「プラグイン保守がつらい」なら、WordPress側に新しいECプラグインを増やしすぎると本末転倒です。WordPressは記事・LP・SEOコンテンツに絞り、販売の複雑さはShopify側に寄せる方が目的に合います。

セキュリティ、プラグイン、保守責任

Shopifyを使えば決済やチェックアウトの多くはShopify側へ寄せられます。ただし、WordPressの保守が不要になるわけではありません。むしろ、WordPressとShopifyの接続点が増えるため、責任分界を決めます。

領域	WordPress担当	Shopify担当	開発/保守担当
WordPress本体・テーマ	更新、バックアップ、脆弱性対応	対象外	更新前後の表示確認
Shopify plugin / Sell on WordPress	インストール、表示確認	sales channel、access token、商品公開	token保管、権限棚卸し、検証環境
Buy Buttonコード	記事・LP内の設置位置管理	商品、collection、button作成	埋め込み台帳、表示QA
商品・在庫・注文	直書き情報を避ける	商品マスタ、価格、在庫、注文、返金	外部連携があれば同期監視
GA4・広告	記事CTA、LP、内部リンク	purchase、商品イベント、広告CV	クロスドメイン、重複、Tag Assistant

Sell on WordPressでは、Shopify access tokenをWordPress側プラグインに貼り付けます。これは便利ですが、WordPress管理画面にアクセスできる人が、Shopify連携の重要情報に触れることを意味します。権限の強いWordPress管理者を増やしすぎない、退職・委託終了時にアクセスを棚卸しする、接続解除時に商品表示が消えることを把握する、といった運用が必要です。

Buy Buttonも、貼って終わりではありません。商品名や価格はShopify側の更新が反映されても、記事本文の説明、比較表、キャンペーン文言、スクリーンショット、構造化データはWordPress側に残ります。商品販売が終わったとき、WordPress側の導線を誰が確認するのかを決めます。

判断チェックリスト

最後に、どの方式を選ぶかをチェックリストにします。

質問	Yesの場合の第一候補	理由
既存WordPressに検索流入があり、記事を残したい	Buy Button、Sell on WordPress、またはサブドメイン	CMS資産を残し、購入処理だけShopifyへ寄せる
商品数が少なく、記事内CTAから売れればよい	Buy Button	設置が軽く、テスト販売しやすい
WordPress Editorから商品を追加したい	Sell on WordPress	ノーコード寄りに商品ブロックを使える
商品一覧、検索、カテゴリ、チェックアウトを標準で安定させたい	Shopifyサブドメイン	Shopifyテーマと標準EC機能を使える
ブランド体験や検索UIを完全に作り込みたい	Headless/Storefront API	自由度は高いが、API・監視・保守が必要
WooCommerceの保守負荷を減らしたい	Shopifyを注文・決済・在庫の正本にする	WordPress側へEC責任を戻さない

まとめ：WordPressはCMS、ShopifyはEC基盤として分ける

ShopifyとWordPressの連携は、購入ボタンを貼るだけの話ではありません。

WordPressは記事、ブランド、SEOコンテンツ、比較、導入事例のCMSとして使う。Shopifyは商品、SKU、在庫、注文、決済、返金、チェックアウト、販売チャネルの正本として使う。この分け方ができると、Buy Button、Sell on WordPress、Shopifyサブドメイン、Headless/Storefront APIのどれを選ぶべきかが見えてきます。

Buy Buttonは軽い販売導線に向きます。Sell on WordPressはWordPress EditorからShopify商品を扱いたい場合に候補になります。Shopifyサブドメインは標準EC機能を安定して使いやすく、WooCommerceからの移行先としても現実的です。Headlessは自由度が高い一方で、Storefront API、カート、キャッシュ、計測、監視、保守の設計が必要です。

Bitlightでは、WordPressを残すか、Shopifyへ寄せるかを表面的なCMS選定で決めません。既存記事のSEO、商品データ、在庫、注文、決済、GA4、WooCommerce移行、プラグイン保守、社内運用を棚卸しし、どの方式なら売上と保守が両立するかを設計します。

既存WordPressを活かしてShopifyでEC化したい場合は、まず「どの商品を、どのURLで、どのデータを正本にして、どの計測で評価するか」から整理するのが安全です。