本記事は、特定のお客様の導入実績や改善数値を示すものではありません。小売業がECサイトを立ち上げる際によく検討される課題と施策を、架空の小売店を想定したモデルケースとして整理したものです。実際の当社の制作・開発事例は、本文後半の「当社の制作・開発事例」からご確認いただけます。
実店舗を中心に営業してきた小売店がECサイト(ネット通販)を始めるとき、「サイトを作ること」と「検索で見つけてもらうこと」を別々に考えると、公開後に集客の仕組みを作り直すことになりがちです。本記事では、ECサイトの構築とSEO(検索エンジン最適化)を一体で進めるための考え方を、商品登録、決済・配送、在庫連携、商品ページのSEO、構造化データ、アクセス解析とKPI設計、AI活用の注意点の順に解説します。
商品・在庫・決済・
配送を整える
商品ページSEOと
サイト構造を整える
KPIを計測して
改善を続ける
ECサイト構築とSEOを同時に考える理由
ECサイトは公開しただけでは、検索結果やSNSで見つけてもらえるとは限りません。一方で、公開後にSEOを始めようとしても、商品ページの情報が少ない、カテゴリ構成が検索のされ方と合っていない、URLや画像の扱いを後から変えにくい、といった構築時の決定が足かせになることがあります。
そのため、構築の段階から次の点を合わせて決めておくと、公開後の改善が進めやすくなります。
- 誰が、どんな言葉で探すか:実店舗の常連客なのか、店を知らない遠方の人なのかで、必要なページや情報が変わります
- どの商品をECで売るか:送料と梱包の手間に見合う商品か、在庫を実店舗と共有するかを決めます
- ページの役割分担:商品ページ、カテゴリページ、購入前の疑問に答える記事を、それぞれ何のために作るかを決めます
- 何を計測するか:公開前にGoogle Search ConsoleとGoogleアナリティクス(GA4)を設定し、比較の起点となるデータを残します
なお、SEOは広告出稿を必須としない集客方法ですが、無料で成果が出るわけではありません。商品情報の整備や記事の作成には時間と費用がかかり、検索順位や流入の増加は保証されません。広告やSNS、既存顧客への案内と組み合わせて考えるのが現実的です。
【モデルケース】小売店がECを始めるときの前提と制約
ここからは、説明のために次のような架空の小売店を想定します。実在の企業や当社のお客様ではなく、ECを始める小売店によくある条件を組み合わせたものです。
| 項目 | 想定する条件 |
|---|---|
| 業態 | 実店舗で雑貨・インテリア用品を販売している小売店 |
| 商品 | 取扱商品が多く、写真や説明文が揃っていない商品も多い |
| 体制 | ECの担当者は店頭業務と兼務。専任のWeb担当者はいない |
| 在庫 | 実店舗とECで同じ在庫を販売したい |
| 予算 | 初期費用を抑え、売れ行きを見ながら機能を追加したい |
このような条件では、最初から全商品を登録し、すべての機能を作り込むのは現実的ではありません。以下のフェーズに分け、優先度の高いものから進める方法を考えます。
フェーズ1:商品・在庫・決済・配送を整備する
ECサイトの構築方式を選ぶ
ECサイトの構築方式は、大きく次の3つに分けられます。どれが適しているかは、商品数、必要な機能、社内の運用体制、既存システムとの連携の有無によって変わります。
| 構築方式 | 主な例 | 向いているケース | 注意点 |
|---|---|---|---|
| SaaS型(ネットショップ作成サービス) | Shopify、BASEなど | 早く始めたい。標準機能で足りる | 料金体系はサービスやプランにより異なり、月額費用や販売ごとの手数料がかかる。独自要件をどこまで実現できるかは、サービスのAPI・アプリ・契約プランなどの制約を受ける |
| オープンソース・パッケージ型 | EC-CUBE、WooCommerceなど | 購入条件や管理画面を業務に合わせて調整したい | サーバーの管理、セキュリティ更新、保守を自社または委託先で行う必要がある |
| 個別開発(フルスクラッチ) | — | 既存の基幹システムと深く連携させたい。標準の仕組みでは業務に合わない | 初期費用と開発期間が大きくなりやすい |
料金、手数料、使える機能はサービスやプランによって異なり、改定されることもあります。比較する際は、各サービスの公式サイトで最新の条件を確認してください。
商品登録は絞り込んで始める
取扱商品が多い場合でも、最初は売れ筋や、写真・説明文を揃えやすい商品から登録を始めると、公開までの期間を短くできます。商品ページには、次のような購入判断に必要な情報を揃えます。
- 仕様・サイズ・重さ・素材
- 使い方や使用シーン、組み合わせの例
- お手入れの方法や使用上の注意
- 色や質感が分かる複数の写真
- 配送方法・送料・お届けまでの目安
スタッフが撮影する場合は、背景、明るさ、撮る角度を揃える簡単な撮影ルールを作っておくと、ページごとの見た目のばらつきを抑えられます。
決済手段を選ぶ
クレジットカード、コンビニ決済、QRコード決済、後払いなど、どの決済手段を使えるかは、ECサービスや決済代行会社、契約プラン、時期によって異なります。手数料、入金サイクル、審査の有無も含め、各社の公式情報で最新の条件を確認したうえで選びます。
配送と送料を設計する
配送は、商品のサイズと重さ、梱包資材、配送業者の料金体系によって費用が大きく変わります。配送費や梱包資材費、決済手数料の負担によっては、売上があっても利益が残らないことがあります。商品原価(仕入原価)を含めて売上総利益を把握したうえで、店舗が負担する送料・梱包資材費・決済手数料なども考慮し、注文単位の採算を確認しておきましょう。出荷量が増えた段階で、配送業者や契約条件を見直すことも検討します。
実店舗とECの在庫をどう扱うか決める
実店舗とECで同じ在庫を販売する場合は、POSレジやEC側の在庫をどう共有するかを構築時に決めておきます。在庫連携は二重販売(売り越し)のリスクを減らすための仕組みですが、方式によってはリスクが残ります。詳しくは後述の「実店舗とECの在庫連携で失敗しやすい点」で解説します。
フェーズ2:商品ページSEO・カテゴリ設計・構造化データ・記事と内部リンク
どんな言葉で、何を知りたくて検索されるかを整理し、ページの役割を決める
仕様・素材・サイズ・用途・注意点など、購入判断に必要な情報と正確なaltを整える
Product・Offerを実データと一致させる。検索結果での表示は保証されない
カテゴリ構成を整え、購入前の疑問に答える記事から商品ページへつなぐ
キーワードと検索意図を整理する
まず、商品やカテゴリがどんな言葉で検索されているか、その検索をする人が何を知りたいのかを整理します。このとき、ツールごとに分かることが違う点に注意が必要です。
- Google 広告のキーワードプランナー:キーワードの月間検索ボリュームの見積もりや関連キーワードの候補が分かります。広告の計画用ツールで、値は推定値です
- Google Search Console の検索パフォーマンス:自社サイトがGoogle検索で表示された回数、クリック数、クリック率(CTR)、平均掲載順位、表示されたときの検索語句が分かります。自社サイトの実績データなので、公開してデータが貯まるまでは使えません
Search Consoleのクリック数とキーワードプランナーの検索ボリュームは、測っているものが違います。前者は自社サイトの実績、後者は検索全体の推定値として、分けて扱います。Search Console について詳しくは「Search Consoleでお宝キーワードを見つける方法」で解説しています。
商品ページの情報と画像のaltを整える
商品ページでは、キーワードを詰め込むのではなく、購入を検討している人が知りたい情報を、その店ならではの説明で揃えることが基本です。仕様や素材に加えて、使い方、他の商品との組み合わせ、選んだ理由、注意点などを書くと、他のサイトと同じ説明文になりにくくなります。
画像のalt(代替テキスト)は、画像を見られない人や、画面読み上げを使う人に向けて、画像の内容を正確に説明するためのものです。Googleも画像検索のガイドラインで、altにキーワードを羅列することは避けるよう案内しています。「木製の小物入れを正面から撮った写真」のように、写っている内容をそのまま説明します。
構造化データ(Product・Offer)を確認・整備する
構造化データは、ページの内容を検索エンジンに伝えるための記述です。商品ページでは、商品名、価格、在庫状況などを Product や Offer として記述します。
Product・Offer等の構造化データを正しく整備すると、価格や在庫情報などを伴う検索表示の対象となる可能性があります。ただし表示やクリック率向上は保証されないため、検索パフォーマンスを計測して評価します。Googleの構造化データに関する一般的なガイドラインでも、正しくマークアップしても表示されるとは限らないと明記されています。
整備にあたっては、次の点を確認します。
- 実際のデータとの一致:構造化データの価格や在庫状況が、ページに表示されている内容と一致し、変更時に同時に更新されるようにします
- 評価・レビュー:星の評価を記述できるのは、実際のレビューがある場合だけです。評価を作ったり、ガイドラインに沿わない形で記述したりしてはいけません
- 重複の確認:ECサービスのテーマやプラグインが、すでに構造化データを出力していることがあります。追加する前に現状を確認し、同じ商品の記述が重複・矛盾しないようにします。追加のJSON-LDが常に必要なわけではありません
- 対象となるページ:Googleの販売者のリスティングに関するガイドラインでは、対象はそのページで商品を購入できるページとされています
- 検証:リッチリザルト テストやSearch Consoleのレポートでエラーを確認します
カテゴリ設計と記事から商品ページへの内部リンク
カテゴリは、店側の分類ではなく、お客様の探し方(用途、部屋、素材、贈り物の予算など)に合わせて設計すると、検索とサイト内の回遊の両方で使いやすくなります。
購入前の人が持つ疑問(「贈り物に何を選べばよいか」「部屋に合う色の選び方」など)に答える記事を作り、関連する商品ページやカテゴリページへリンクする方法もあります。ただし記事作成は継続的な手間がかかるため、更新できる体制と、記事から商品ページへの遷移を計測する方法を決めてから始めます。
フェーズ3:公開後のKPIを計測して改善する
公開後は、どの施策が何に影響したのかを判断できるよう、指標ごとに見る場所を分けて計測します。Googleも、Search ConsoleとGoogleアナリティクスを組み合わせて分析する方法を案内しています。Search Consoleは検索結果からサイトに来るまで、GA4はサイトに来た後の行動を中心に把握するツールです。
| 指標 | 主に見る場所 | 分かること・注意点 |
|---|---|---|
| 表示回数・クリック数・CTR・平均掲載順位 | Search Console | Google検索での見え方。順位やCTRは検索語句・ページごとに見る |
| 指名検索・非指名検索のクリック傾向 | Search Console(取得できた検索語句を分類) | 店名・ブランド名を含む検索と、商品名などを使った検索のクリック傾向を比較する。検索語句の一部は非表示となるため、全検索・新規顧客の割合を示すものではない |
| 自然検索からの訪問と購入 | GA4 | 検索から来た人が購入まで進んでいるか |
| 商品別の購入数・購入率(CVR) | GA4・EC管理画面 | どの商品ページを改善すべきか |
| 売上・売上総利益(粗利)・注文単位の採算 | EC管理画面・会計 | 商品原価を差し引いた売上総利益と、店舗が負担する送料・決済手数料・梱包資材費なども考慮した注文単位の採算を分けて確認する |
| 欠品率・売り越しの件数 | 在庫管理・POS | 在庫連携の運用に問題がないか |
Search Consoleでは、プライバシー保護のため検索回数の少ない検索語句が表に表示されません(Search Console ヘルプ:データの不一致)。そのため、検索語句を分類した合計は全体のクリック数と一致しないことがあります。新規の利用者を分析したい場合はGA4の新規ユーザーなどの指標を別に使い、検索語句の分類と混同しないようにします。なお、GA4の新規ユーザーは新規購入者と同じ意味ではありません。
GA4で購入や商品別のデータを確認するには、ECサービスの連携機能やタグ設定を通じて、purchase などのeコマースイベントが正しく送信されている必要があります。eコマースイベントはGA4に自動では収集されません(アナリティクス ヘルプ:eコマース購入レポート)。決済ページが別ドメインになる場合は、その間の計測も確認します。商品別の購入率は指標の定義・分母も確認し、EC管理画面の受注データと照合してください。
数値を比較する際は、次の点に注意します。
- いつ何を変えたかを記録し、施策の前後で比較する
- 季節やセール、広告、SNSの投稿など、同じ時期の他の要因も合わせて記録する
- 季節の影響がある商品は、前年の同じ時期とも比較する
- 売上の変化を、SEOや構造化データなど一つの施策だけの成果と決めつけない
GA4の設定については「GA4初期設定ガイド」、ECサイトで見るべきデータについては「ECサイトの売上が伸びない原因と改善方法」も参考にしてください。
実店舗とECの在庫連携で失敗しやすい点
在庫連携は、実店舗とECの在庫情報を共有して、二重販売(売り越し)のリスクを減らすための仕組みです。ただし、同期の方式やタイミングによっては、売り越しを完全には防げません。たとえば1日1回の同期では、同期と同期の間に店頭とECで同じ商品が売れると、在庫数が実態とずれます。
| 同期の方式 | 特徴 | 検討しやすいケース |
|---|---|---|
| CSVによる手動・日次の更新 | 仕組みが簡単で費用を抑えやすい。更新の間に在庫がずれる | 商品数が少なく、同じ商品が短時間に何度も売れることが少ない |
| 定期的な自動同期(数十分〜数時間ごと) | ずれる時間を短くできる。連携の失敗に気づける仕組みが必要 | 販売頻度が中程度で、在庫に少し余裕を持たせられる |
| イベント連携・リアルタイム連携 | 注文や販売のたびに在庫を更新する。費用や開発の難しさが上がる | 一点物や在庫の少ない商品が多い。販売頻度が高い |
どの方式でも、次の点を事前に決めておきます。
- 基準とする在庫データ:POS、EC、在庫管理システムのどれを正とするか
- 在庫の引当のタイミング:カートに入れた時点か、注文が確定した時点か。予約商品の扱い
- 在庫のバッファ:ECに表示する在庫を実在庫より少なめにして、ずれに備えるか
- 同時更新への対応:店頭とECでほぼ同時に売れた場合に、どちらを優先するか
- 連携が失敗したとき:自動で再試行するか、誰に通知するか
- 売り越しが起きたとき:お客様への連絡、キャンセルや入荷待ちの案内の手順
在庫管理の仕組みについては「在庫管理システム導入ガイド」、サービス同士の連携方法については「SaaS連携・iPaaSの選び方」でも解説しています。
AIの活用範囲と人による確認
生成AIなどのツールは、EC運営の一部の作業を手伝う手段として検討できます。ただし、出力をそのまま公開するのではなく、人が確認する前提で使います。
- 商品説明文の下書き:仕様や素材を入力して説明文の下書きを作ることはできます。公開前に、仕様・サイズ・素材・原産地の正確さ、法令で求められる表示、著作権や商標、誇張した表現や不適切な比較がないかを人が確認します
- 入力する情報:お客様の個人情報や、公開前の商品情報を外部のAIサービスに入力する前に、そのサービスの利用規約やデータの扱いを確認します
- 検索ニーズの分析:AI機能を持つSEOツールで、キーワードの候補や記事の企画案を出すことはできます。データの更新頻度はツールによって異なるため、提案は候補として扱い、Search Consoleなどの実データと照らして人が判断します
- おすすめ商品の表示(レコメンド):購入履歴がある程度貯まってから検討できる機能です。導入する場合は、効果を計測できるようにしてから始めます
生成AIで文章を作る際の確認体制については「生成AIでコンテンツマーケティングを効率化する方法」で解説しています。
当社の制作・開発事例
ここまでのモデルケースとは別に、当社が公式サイトで公開している実際の制作・開発事例を紹介します。
【i4 衣都の工房様】オリジナルグッズ製作サイトの構築:WordPressのカスタム投稿で商品情報を登録できるようにし、ロット数や納期による商品の絞り込みと、条件を選ぶと金額が分かる簡易見積の機能を構築しました。なお、この事例はネットショップ(ECサイト)の構築ではなく、本記事のモデルケースのような売上の数値を示すものでもありません。
その他の事例は「導入事例・実績」でご覧いただけます。
まとめ
ECサイトの構築とSEOは、別々に進めるよりも、構築の段階から「誰がどう探すか」「どのページで何を伝えるか」「何を計測するか」を合わせて決めておくと、公開後の改善が進めやすくなります。
- 商品・在庫・決済・配送は、最小限の構成で始め、売れ行きを見ながら広げる。売上総利益と注文単位の採算は分けて確認する
- 商品ページは、キーワードよりも購入判断に必要な情報を優先する
- 構造化データは実データと一致させる。表示やクリック率の向上は保証されない
- 在庫連携は、同期の方式に応じて売り越しが起きたときの運用まで決めておく
- Search Console・GA4・EC管理画面で指標を分けて計測し、一つの施策の成果と決めつけない
- AIの出力は下書きや候補として扱い、公開前に人が確認する
株式会社アイ・エス・プライムでは、EC-CUBE・WooCommerceなどを使ったWeb・ECサイトの制作や既存ECサイトのカスタマイズ・在庫連携、GA4・Search Consoleを使ったウェブ解析・改善のご相談を承っています。「ECを始めたいが、何から決めればよいか分からない」という段階からお問い合わせください。





