MakeShop移行で売上が下がる企業の共通点と成長を続ける乗り換え設計の判断基準とは
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
MakeShop移行で売上が下がる企業の共通点
ECサイトをMakeShopへ移行したのに、売上が30%近く落ちてしまう企業が増えています。プラットフォーム自体の問題ではなく、移行プロセスの設計が間違っているケースがほとんどです。
MakeShop移行による売上低下とは、既存サイトの「売れる構造」を新しいプラットフォームに正確に移行できず、ユーザーの購買導線や信頼設計が崩れてしまう現象である。
多くの企業は「新しい機能が増える」「カスタマイズの自由度が上がる」という理由でMakeShopへの移行を判断します。 しかし実際には移行直後のアクセス数低下、直帰率上昇、CVR低下という3つの構造的な問題が同時に発生します。 管理画面でアクセスを確認すると、前月比で20~50%の流入減少が見られるケースがほとんどです。
MakeShop移行で売上を維持するとは何か

MakeShop移行で売上を維持するとは、既存サイトの「集客構造」「商品訴求構造」「エンティティ構造」の3つの売上生成要素を、新しいプラットフォーム上に完全に再現することである。
重要なのは「新しい機能を追加する」ことではなく「古い機能の売上構造を理解して、新しいプラットフォームで再現する」ことです。MakeShop移行による失敗の多くは、移行作業を「技術的な引っ越し」だと考えることから始まります。
実際には、URL構造の変化、内部リンク設計の再構築、構造化データの再設定、カテゴリページの導線変更、商品ページのレイアウト変更など、SEO的な要素とUX的な要素の両方を同時に設計し直す必要があります。
MakeShop移行は5つの段階で判断される
企業がMakeShop移行で失敗するかどうかは、以下の5つの段階で決まります。 各段階で判断を間違うと、後続のすべての段階で売上低下を引き起こします。
- 移行前の売上構造分析:現在のサイトがなぜ売れているのかを理解しているか
- プラットフォーム選定の基準:MakeShopが本当に必要な判断基準は何か
- 移行タイミング:売上が高い時期と低い時期のどちらで移行するべきか
- 移行期間の売上補填:移行中の流入減少をどう補うのか
- 移行後の検証と最適化:新サイトで何を改善すべきかの判断基準
段階1:現在のサイトの売上構造が理解できていない

MakeShop移行で失敗する企業の最初の問題は、現在のサイトがなぜ売れているのかを分析していないことです。
一般的には「古いプラットフォームだから」「カスタマイズができないから」という理由で移行を判断しますが、本当の問題は「売上が生まれている理由が不明確なまま移行する」ことにあります。
福岡ECサイト株式会社が支援した事例では、月商800万円のMakeShopサイトをShopify移行の相談を受けましたが、実際に売上構造を分析すると以下のポイントが判明しました。
- 全売上の40%が「特定のカテゴリページからの流入」で発生していた
- そのカテゴリページは、Google検索で「商品名+〇〇」というロングテール検索から流入していた
- 元のMakeShopサイトのURL構造が、その検索キーワードに最適化されていた
- 移行時にURL構造を変更すると、Google検索での表示順位が低下する可能性があった
移行前にこの「なぜ売れているのか」を理解していれば、新しいプラットフォームでもURL構造を維持する、内部リンク戦略を同じに設計するなどの対策が可能です。しかし移行後に「あ、この流入源が消えた」と気づくのでは手遅れです。
判断基準は明確です。移行前に「現在のサイトの売上の60%以上がどのページから、どのキーワードから来ているのか」を特定できていない場合は、移行判断を一度保留すべきです。
段階2:MakeShop選定の基準が機能要件だけになっている
次の失敗パターンは、MakeShop選定の判断基準が「新しい機能」「自由度の高さ」「カスタマイズ性」といった機能要件だけになっていることです。
実際には、MakeShopへの移行判断は以下の順番で判断すべきです。
- 現在のプラットフォームで対応できないビジネス課題があるか:「売上が伸びない」「管理が複雑」「在庫連携ができない」など、具体的な経営課題があるのか
- その課題がMakeShopで本当に解決するのか:同じ課題を持つ企業がMakeShopで実際に解決した実績があるのか
- 移行コストと期待できる売上向上が見合うのか:構築費用+移行期間の売上低下+運用スタッフの学習時間を、期待できる売上向上で回収できるのか
- 移行期間に別の集客施策で補填できるのか:SNS・広告・AI検索対策など、移行期間の売上減少をカバーする施策があるのか
多くの企業は1番目の段階で判断を誤ります。「売上が伸びない」という漠然とした課題感で、「MakeShopなら解決するかもしれない」という期待だけで移行を決めてしまうのです。
実際には、売上が伸びない理由は以下のいずれかです。
- サイトへのアクセスが不足している(集客構造の問題)
- サイトへのアクセスはあるが購入に至っていない(CVR改善の問題)
- 商品が消費者のニーズに合っていない(商品企画の問題)
- ブランド認知度が不足している(信頼設計の問題)
これらの問題のうち、MakeShopへの移行で解決するのは非常に限定的です。むしろ移行作業に時間とコストを使う間に、本当の原因への対策が遅れるリスクが高いです。
判断基準:現在のプラットフォームで対応できない「具体的な機能不足」を3つ以上挙げられない場合、MakeShop移行は見送るべきです。
段階3:売上が高い時期に移行してしまう

移行タイミングの判断も重要です。多くの企業は「今がいいタイミング」と判断した時期が、実は最も危険なタイミングであることに気づきません。
MakeShop移行では、必ず以下の現象が起きます。
- 移行直後の1~2週間は、旧サイトと新サイトが両方稼働する期間がある
- Googleが新サイトをクロール&インデックスするまで、検索からのアクセスが減少する(通常2~4週間)
- 新サイトのUI/UXが旧サイトと異なるため、既存ユーザーの直帰率が一時的に上がる
- 新プラットフォームのシステム最適化が完了していない初期段階では、ページ読み込み速度が遅くなる可能性がある
この期間のアクセス減少は「通常20~50%」と言われています。月商500万円のサイトを移行する場合、1~2ヶ月間で100万~250万円の売上低下が発生する可能性があるということです。ここが一番怖いところですよね。
福岡ECサイト株式会社が支援した別の事例では、季節商品を扱うECサイトが、繁忙期直前にMakeShop移行を実施してしまい、移行期間の売上低下がそのまま年間実績に大きく響きました。事前に移行スケジュールを分析していれば、閑散期への移行をお勧めしていました。
判断基準:移行予定時期の過去3年間の売上データを確認し、その時期が「年間売上の30%以上を占める繁忙期」である場合、移行時期を延期すべきです。
段階4:移行期間の売上補填戦略がない
移行期間は必ず売上が低下します。この低下を「仕方がない」と受け入れるのか、「別の施策で補填する」のかで、通年の売上は大きく変わります。
多くの企業は、移行作業に集中するあまり、移行期間の集客施策を何もしていません。結果として「サイト移行+集客機能停止」のダブルパンチになってしまうのです。
移行期間に取るべき施策は以下の通りです。
- Google広告の強化:オーガニック流入が減少する期間、有料広告で補填する。移行前月比で30~50%の予算増加を想定する
- SNS集客の活性化:Instagram・TikTok・Xなど、SEOに依存しない流入源を強化する。「新サイトリリースキャンペーン」として企画する
- メールマーケティングの実行:既存顧客に対して「新サイトリリース」「移行記念セール」などのメール施策を打つ
- AI検索対策の先行実施:新サイトリリース時に、ChatGPT・Gemini・Perplexityなどで引用されやすいコンテンツを同時掲載する
判断基準:移行期間(予想3~8週間)の売上低下分を補填する施策と予算が、事前に用意されていない場合、移行スケジュールを見直すべきです。
段階5:移行後の検証基準が「アクセス数」だけになっている
移行から1ヶ月後、企業が最初に確認することは「アクセス数が戻ったか」という数字です。しかしこれだけで判断すると、別の重要な問題を見落とします。
移行後に確認すべき5つのメトリクスは以下の通りです。
- 流入:検索・SNS・広告など流入源別のセッション数
- 行動:ページビュー数・平均セッション時間・スクロール深さなど、ユーザーのサイト内行動
- CVR:流入ユーザーのうち、実際に購入に至った割合
- 顧客品質:購入後のリピート率・平均購入金額・解約率など
- SEO:特定キーワードの検索順位・インプレッション数・CTR
よくあるパターンは「アクセスは戻った。でもCVRが落ちている」という状況です。実際の現場では、このパターンで悩む企業が非常に多いです。新サイトのUIが旧サイトと大きく異なり、ユーザーが購入手順を見つけられていない、もしくは商品情報の配置が変わっているために判断に時間がかかっている可能性があります。
GA4で直帰率を確認していると、商品ページ到達後のすぐ離脱が増えていることが見えます。これは「新しいレイアウトで商品情報が見つからない」という現場の課題そのものです。
判断基準:移行後30日時点で「流入は80%以上戻ったが、CVRが移行前の70%未満」である場合、サイトUIの緊急改善が必要です。
MakeShop移行で売上を維持する設計の3つのポイント
MakeShop移行で売上を維持するには、以下の3つの構造をすべて新しいプラットフォーム上に「完全に再現する」必要があります。
ポイント1:集客構造の移行設計
現在のサイトがどのキーワードで検索流入し、どのページが売上を生み出しているかを、移行前に完全に把握する必要があります。
具体的には、Search ConsoleでMakeShop移行前の3~6ヶ月分のデータを確認し、以下を整理します。
- 売上貢献度の高い順に、検索キーワード・表示回数・クリック数・ランキング順位を記録する
- 各キーワードに対応する現在のURL構造を記録する
- 移行時に「このURLを絶対に変えない」というリストを作成する
- URLが変わる場合は、301リダイレクトの設計図を事前に作成する
福岡ECサイト株式会社が支援する企業では、移行前にこの「売上キーワード分析」を4~6週間かけて実施し、移行時に90%以上のURL構造を維持することで、検索順位低下を最小限に抑えています。
ポイント2:商品訴求構造の移行設計
新しいプラットフォームでは、商品ページのレイアウト・画像配置・テキスト表現が大きく変わる可能性があります。
重要なのは「デザインを新しくする」ことではなく「売上を生み出していた要素を確実に保持する」ことです。
具体的には、売上が高い商品ページ(月間の売上上位10~20%の商品)を対象に、以下の要素を新サイトでも同じ配置・同じ表現で再現します。
- 商品メイン画像の配置
- 価格表示の位置と表現
- 購入ボタンのサイズ・色・配置
- 商品説明文の順序と文量
- レビュー・口コミセクションの表示位置
- 関連商品・クロスセル商品の推奨ロジック
MakeShopの標準テンプレートをそのまま使うと、これらの要素がすべて変わってしまう可能性があります。結果として「前は何も考えずに買えたのに、新サイトは情報が多すぎて迷う」という状況が発生し、CVRが低下します。
ポイント3:エンティティ構造の移行設計
ECサイトの信頼性を示す要素(会社情報・実績・レビュー・メディア掲載・認定マーク)も、新しいサイトで確実に表示されているか確認が必要です。
特に以下のポイントを確認します。
- 会社情報ページが新サイトで正しく表示されているか
- 製品・サービスの実績数字が新サイトでも同じタイミングで更新されるか
- 第三者認定(ISO・著名な賞など)の表記が新サイトの各ページに保持されているか
- お客様レビュー・口コミが新サイトで引き継がれているか
- 構造化データ(schema.org)が新サイトでも正しく実装されているか
これらの要素は、ユーザーの「このサイトは信用できるか」という判断に直結し、購入決定に大きく影響します。
MakeShop移行と現在のプラットフォームの比較
| 観点 | 現在のプラットフォーム維持 | MakeShop移行 |
|---|---|---|
| 初期費用 | 0円(既に投資済み) | 30~150万円 |
| 移行期間の売上リスク | なし | 20~50%の一時的な低下(1~3ヶ月) |
| 運用学習コスト | 既に習熟 | 1~3ヶ月の学習期間が必要 |
| SEOへの影響 | なし(現状維持) | URLリダイレクト設計に依存・不備で50~80%のランキング低下リスク |
| 新機能の実装スピード | 遅い・カスタマイズに外部ベンダーが必要 | 速い・MakeShop提供の機能が豊富 |
| メリットが活きる条件 | 現状の売上構造を維持したい企業 | 移行後に「新しい機能で新しい売上施策」を実行できる企業 |
MakeShop移行で失敗する企業の2つの失敗パターン
失敗パターン1:移行を「技術的な引っ越し」と考える企業
このタイプは、「プログラマーに任せれば完成する」という感覚で移行を進めます。結果として、SEO・UX・信頼設計のいずれもが新サイトで正確に再現されません。
売上構造を理解していない技術者が主導すると、「技術的には完璧に移行された」という状況が、「ビジネス的には完全に失敗している」という結果になります。このギャップが現場で最も深刻な問題として表れてきます。
失敗パターン2:移行を「機能追加の機会」と考える企業
このタイプは、「どうせ移行するなら、この機会に色々な新機能を追加しよう」という判断をします。その結果、プロジェクト規模が膨大になり、移行期間が延びて、新サイトでのテストと最適化に時間が足りなくなります。
実際には、移行後に「最初は最小限の機能」で安定稼働させてから、「順次新機能を追加する」という段階的なアプローチが正解です。焦って全部を一気に実装すると、問題の原因特定が困難になってしまいます。



