Wixサイトを別のホストに移動することはできません。それで終わりです。Wixはサイトをその独自のサーバー上でホストおよび運用される必要があると述べているため、移動は転送ではなく再構築です。サイトの周辺のビジネスデータは異なります。実体店の製品と連絡先はドキュメント化されたCSVエクスポートがありますが、ブログ投稿にはネイティブエクスポートルートがありません。
どのルートがどの状況に適しているか
10のブランド名のリストではなく、状況から始めてください。ほとんどのラウンドアップは勝者で終わります。それは整理されています。実際の質問が何を再構築する必要があるかである場合、あまり役に立ちません。
条件付き評価としてランキングではなく、私はそれをこのようにフレーミングします：
- 小規模なサイト、編集プロセスが機能している場合: Wix にとどまるのは正当な判断です。
- ビジュアルマーケティングチーム: 自分たちのページで別のビジュアルビルダーをテストしてください。
- ストア: コマースプラットフォームを最初に評価し、ページビルダーは次に評価します。
- 構造化されたコンテンツと開発サポート: ヘッドレスのルートをテストしてください。
候補リストがこれより広い場合、CMS選択肢の概要でより広い判断をカバーしています。
| サイトまたはジョブ | テストするルート | 編集モデル | 運用責任 | リビルドまたは検証 |
|---|---|---|---|---|
| 小規模なパンフレットサイト、編集がすでに機能している | Wix にとどまる | Wix エディタ、変更なし | Wix がホスティングと更新を行い、コンテンツ、プラン、ドメイン更新はあなたの責任です | 特定の問題を修正し、プランとドメイン接続が維持されることを確認します |
| テンプレート主導のマーケティングサイト | Squarespace | ホストされたテンプレートエディタ | プラットフォームがホスティングを行い、チームがコンテンツとページ構造を所有します | すべてのページとテンプレート、フォーム、リダイレクト、メタデータ |
| デザイン主導の CMS 付きマーケティングサイト | Webflow または Framer | ビジュアルキャンバスプラス CMS コレクション | プラットフォームがホスティングを行い、チームがコレクションをどのようにモデル化するかを所有します | デザインを再作成、コレクションを構築、エディタは実ページを公開します |
| ストア | Shopify | ストア管理画面 | プラットフォームがホスト。チームがカタログ、チェックアウト設定、フルフィルメントを管理 | 商品CSV編集、デジタル商品、顧客アカウント、チェックアウト、注文メール |
| コンテンツサイト。チームがホスティングを管理 | WordPress | ブロックエディタ + プラグイン | チームがホスティング、更新、プラグインのライフサイクルを管理 | テーマとスタイル。ブログはバッチで管理。パーマリンク、フォーム、バックアップ |
| 構造化されたコンテンツ。開発者によるサポート付き | ヘッドレスCMSを使ったAstro | エディタ向けのCMS、フロントエンド向けのコード | 開発者とチームがビルド、ホスティング、CMS保守を共有 | テンプレート、プレビュー、フォーム、検索、リダイレクト、公開ワークフロー |
この表はテスト計画として扱ってください。機能一覧でもプライシング表でもなく、そのように作られていません。
Wixから離脱することの実際の意味
Wix自身のヘルプページは明確です。サイトはWixの技術で構築され、Wixの言葉を借りれば「Wixのサーバー上でホスト・運用される必要があります」(Wixサポート)。理由とされているのは、SaaSアーキテクチャがWixの独自技術とサービスに依存しているため、別のホストではそれを実行できないということです。またWixは、構築したコンテンツはあなたのものだと言っています。両方の主張は同時に成り立ちます。自分の言葉や画像を所有することは、ポータブルで動作するサイトを所有することと同じではないのです。
つまり離脱とは別のプラットフォーム上で再構築し、その後、エクスポートのルートがあるデータを運ぶことを意味します。その違いを明確に保ってください。早めに潰しておく価値のある誤読が3つあります:
- 別のプロバイダーでホスティングを契約してもサイトは移動しません。そのホストが実行するものは何もないのです。
- ドメインは別の決定です。Wixは別のプロバイダーでドメインを購入・管理し、Wixサイトに接続できると述べています。ただし接続には有料プランが必要です。ドメインを維持することは、ページがどこに置かれているかについて何も言いません。
- iframeは移行ではありません。Wixは埋め込まれたサイトをサポートできず、表示方法や機能についてはもはや管理下にはなく、Google Analyticsと検索エンジンが埋め込みで正常に機能しない可能性があると警告しています。
もう1点: データタイプごとにエクスポート戦略が異なります。ページ、商品、連絡先、投稿は同じドアから出ません。第5章でそれぞれ取り上げます。
Wixに留まるのが正解のケース
かなりの数のWixサイトはそのままにしておくべきです。再構築する前に、実際の問題を挙げてください: 訪問者を混乱させるナビゲーション、薄いコンテンツ、1つの大きすぎるヒーロー画像、もはや適さなくなった1つのアプリ、誰も従わない編集プロセス。これらはすべてプラットフォーム変更なしで解決できます。再構築はそれらを新しい場所に移すだけです。
速度が理由として挙げられている場合、行動する前に証拠を集めてください。まず測定してください。適切なパフォーマンス評価により、原因がプラットフォーム、画像、アプリ、ページ設計のいずれかが判明します。フォーラムスレッドで読んだ数字を繰り返さないでください。
次に、すでに機能しているものを数えます。予約ルール、支払いフロー、確認メール、フォームルーティング、メンバーアクセスはすべて誰かの努力で正しく機能するようになりました。これらを再構築するには時間がかかり、予約フォームが送信されても誰にも通知されないなど、初日に静かに失敗するリスクがあります。セットアップ次第なので数字は出しませんが、新しいサブスクリプション料金の隣に台帳に記録しておきましょう。
切り替えは検証された要件によって正当化されます。Wixが表現できないコンテンツモデル、カバーしていないストア操作、またはチームが実行できないワークフローです。「Wixはランク付けできない」「Wixは遅い」という一括的な主張は要件ではなく、ムードです。
ショートリストを実際の仕事で比較する
以下の各ルートは、1つの適合、1つのトレードオフ、1つのテストを備えています。適合は私の評価であり、ベンダーの保証ではありません。
Squarespace
適合: テンプレート化されたホスト型パブリッシングワークフローを望み、テンプレートの構造内で作業することに満足しているビジネス。トレードオフ: すべてのページを再構築する必要があり、異常なレイアウトには妥協が必要な場合があります。テスト: エディターに、ショートリストされたテンプレートから、画像付きの実際のサービスページとブログ投稿を公開させます。
Webflow または Framer
適合: 異なるビジュアルデザインとCMSワークフローを望むチーム。WebflowはCMSをビジュアルコンテンツとデザイン作業の周りで説明し、FramerはCMSをコレクションの周りで説明しています。トレードオフ: コレクションに構築した構造はチームが維持する必要があり、どちらのソースもどちらのツールがあなたのニーズに対してWixより有能であるかを証明していません。テスト: ケーススタディなどの1つの実際のコンテンツタイプをモデル化し、エディターがヘルプなしでエントリを追加させます。
Shopify
適合: カタログ、チェックアウト、ストア操作が決定を左右します。トレードオフ: ブロシュアサイトが必要としなかったストア設定を引き受け、Shopifyのヘッドレスストアフロントルートのドキュメンテーションは開始点ではなく後の決定です。テスト: 注文を処理する人が、バリアントを持つ製品を使用して、カートから配送メールまで、1つの完全な注文を実行します。
WordPress
適合: ホスティングとプラグインライフサイクルを所有する準備ができているチーム。それが提供する制御のためです。プロジェクトの機能ページが開始地点です。トレードオフ: アップデート、バックアップ、プラグインの選択があなたの責任になります。テスト: 6か月目に誰がアップデートを適用するかを尋ね、エディターにブロックエディターでページを公開させます。WordPress代替案で他のオプションと比較しており、ここではWordPress実装のピッチをしていません。
ヘッドレスCMSを使ったAstro
適合: 開発者がサポートするコンテンツ配信。Astroのドキュメントはサーバーファースト型レンダリングを伴うコンテンツ駆動型サイトを想定しています。トレードオフ: Astroはフレームワークであり、すぐに使えるビジュアルビルダーではありません。CMSを選択し、パブリッシングワークフローを設計する必要があります。ヘッドレスもメンテナンスフリーではありません。これらの設計目標はサイトやSEOのより良い結果を証明していません。テスト: エディターがドラフト作成とプレビューができ、コードエディターを開かずに公開できますか? ヘッドレス実装がエディターに含まれるものは、フレームワーク名より重要です。
Wixから離れるもの、別に処理が必要なもの
ここが「トラップされた」という主張が崩れ落ちるところです。ドキュメント化されたルートを持つデータもあります。そうでないものもあります。この2つの考えを分けておきましょう。
- 物理店舗の製品: Wix Storesは製品とそのデータをCSVにエクスポートします。制限は1ファイルあたり最大5,000行で、すべてをエクスポートするか、フィルター処理されたカテゴリまたは選択されたアイテムをエクスポートできます。デジタル製品のエクスポートは現在サポートされていません。
- 連絡先: Wix Contactsは最大50,000の連絡先を一度にCSVにエクスポートでき、Regular、GoogleまたはOutlook形式です。サイトオーナーのみが実行できます。Google形式では、ラベルはエクスポートされず、一部のフィールドはGoogleカスタムフィールドとして到着します。Google CSVは連絡先ごとに5つのメール、電話、住所エントリと16個のカスタムフィールドに制限されています。
- ブログ投稿: Wixの機能要求ページには、現在、ブログ投稿を他のプラットフォームにエクスポートすることは不可能であると記載されています。このページは2026年11月4日にチェックされており、Wixは計画された機能は変更される可能性があることに注意しています。
その最後の行は、ドキュメント化されたネイティブワークフローについて説明しています。これは、手動抽出、API、またはカスタムマイグレーションが不可能であることの証拠ではありません。サードパーティのガイドは回避策について説明しています。WordPress.comはWixがRSSフィードを提供していると述べており、最新の20個の投稿を取り込むことができます(WordPress.com)。Codeableは大規模なブログでは20個の繰り返しバッチが必要であると述べています(Codeable)。WordPress.comはそのWixインポーターが静的ページ、画像、サイトタイトル、メニューを処理すると述べています。テーマはWixの正確なデザインを再作成しません。
製品メディアは、HighLevelガイドによれば別のステップとして提供され、ShopifyのWixマイグレーションガイドは製品CSVをインポート前に編集する必要があると述べています。
したがって、メディア、ページコンテンツ、ブログ分類法、メタデータ、フォーム、予約、メンバーシップ、支払い、アプリデータ、権限を個別に監査します。製品または連絡先CSVは機能するサイトをもたらしません。ドキュメント化されたエクスポートに記載されていないため、認証されたメンバーアカウントももたらしません。宛先がそうでなければ別途ドキュメント化されない限り、メンバーが再度サインアップまたは招待されるよう計画します。
移行範囲を構築してからツールを選択する
スコープを最初に決めます。ツール選択はその後であり、インベントリを持つと簡単になります。以下を記述します:
- すべてのページとそのテンプレート
- 各コンテンツタイプ(投稿、サービス、チームプロフィール、ケーススタディ)
- 統合とメールおよびDNS依存関係
- 予約ルール、店舗運営、フォーム送信先
- チームの権限と公開可能な人物
- アナリティクス、トラッキング、同意設定
その後、候補に挙がったプラットフォームそれぞれで2つのテストを実行します。編集者に実在する画像とフォームを含む代表的なページを公開するよう依頼してください。リード、予約、注文の責任者に1つの実際のワークフローを最初から最後まで実行するよう依頼します。リードの場合はリードが到着すること、予約の場合は予約が確認されること、注文の場合は注文が履行されることです。どちらかの人物が時間がかかったり混乱したりしたら、機能リストでは決して分からない何かを学んだということです。
ビジュアル機能の横に責任者を記載します。プラットフォームやプラグインを更新する人物の名前を明記してください。ドメインを更新する人物と、フォームの送信が停止したときにアラートを受け取る人物を記録してください。見た目は素敵だが保守の責任者が決まっていないプラットフォームは、将来の問題になります。
切り替え前後の検証チェックリスト
これが私が確認するリストです。メタデータのコピーがランキングを保持することを約束するものではありません。誰もそれを約束することはできません。
- インデックスされたURLと既知のバックリンクをインベントリして、何かを変更する前に記録します。
- 実用的な範囲でアドレスを同じままにしておき、変更されたアドレスはすべて永続的なリダイレクトでマップします。
- ページコンテンツ、ダウンロード可能ファイル、画像の所有権とコピー、代替テキスト、メタデータ、カノニカル、構造化データをチェックします。
- フォームとその確認メッセージ、同意バナーをテストします。
- 予約、カート、チェックアウト（該当する場合）、メンバーアクセスをテストします。
- トラッキングとメール配信をチェックします。
- ソースと宛先のコンテンツ数を比較します。
- モバイルとキーボードのみでテストします。
- 切り替え前にDNSとメール変更を確認してください。DNSの変更はメール配信を中断する可能性があります。
- 検証が完了するまでWixサイトを保持し、切り替え後は検索結果とトラフィックを監視します。
Wix URLと保持する必要があるフォーム、予約、店舗ワークフローを持参してください。これにより、再構築前にスコープを確定できます。
FAQ
デザインは同じままでWixサイトを他の場所でホストできますか？
いいえ。Wixではサイトは自社のサーバーで実行される必要があり、別のプラットフォーム上での再設計されたサイトは新しいサイトです。ドメインはどのプロバイダーでも保持でき、任意の場所をポイントできます。
製品と連絡先を持ち出せますか？
物理製品と連絡先の両方に、上記で説明した制限付きのドキュメント化されたCSVエクスポートがあります。デジタル製品はWix Storesエクスポートでサポートされていません。ファイルを新しいプラットフォームにインポートする前に編集することを想定してください。
Wixブログにはネイティブエクスポート機能がありますか？
2026年11月時点のWixの機能リクエストページによるとありません。第三者が説明するRSSベースの回避策は1回のインポートで20投稿をカバーするため、投稿数、画像、分類法の後で確認してください。
カスタムフロントエンドが正当化される場合はいつですか？
構造化されたコンテンツモデルが定義され、ビルドを保守する開発者がいて、実際のエディタでテストされた編集ワークフローがある場合。これらのいずれかが当てはまらない場合、ホステッドビルダーは通常、保守負荷が低い選択肢です。
ここで最も重要な事実は、Wixサイトは別のホストに移動できないため、すべてのルートが再構築になり、製品と連絡先はCSVで移動し、ブログ投稿は別途対応が必要という点です。再構築の範囲を慎重に検討してください。実際のワークフローをテストしてから、価格を比較してください。