Wix／Squarespace 移行：いつ切り替え、どう成功させるか

Wix／Squarespace からの移行が本当に含むもの

Wix や Squarespace からの「移行」はボタン一つで終わるものではありません。いくつかのパーツを調整して移す作業で、あるものはそのまま移り、あるものは再構築が必要です。

「移行」に通常含まれるもの

コンテンツ: ページ、ブログ投稿、製品リスト、基本テキストは多くの場合エクスポートやコピーが可能ですが、フォーマットやブロックは 1:1 ではないことが多いです。

デザイン: 実際にはテーマをそのまま「移動」するのではなく、見た目や操作感（レイアウト、タイポグラフィ、コンポーネント）を再現することが一般的です。間取り図は同じで家を建て直すように考えてください。

ドメインとメール: ドメインは現在のレジストラに残すか移管するか選べますが、どちらにしても DNS の変更はローンチの一部です。メール（Google Workspace / Microsoft 365）は通常そのままですが、レコードは保持する必要があります。

SEO: URL、タイトル、メタディスクリプション、見出し、内部リンク、画像の alt テキスト、リダイレクトには計画が必要です。目的はサイトの下で構造が変わっても検索での可視性を維持することです。

機能と連携: フォーム、予約、会員エリア、e コマース、解析、CRM、カスタムスクリプトは新しいプラットフォーム上で再現（または改善）する必要があります。

簡単な意思決定フレームワーク

次の 2 つを自問してください:

1. 今何が問題になっているか？ 例：SEO 制御の制限、編集フローの遅さ、e コマースの制約、デザインの限界、維持が難しい統合など。

2. 切り替えで何が得られるか？ 例：パフォーマンス向上、高度なマーケティングツール、クリーンなコンテンツ管理、柔軟なデザイン、長期コストの低下。

現在の痛みが小さく、利点が不明瞭なら移行は時期尚早かもしれません。痛みが継続的で、新しいプラットフォームが直接それを解決するなら、労力に見合う価値があります。

よくある移行先（と理由）

多くの移行は WordPress（コンテンツの柔軟性）、Webflow（デザインコントロール、管理された感覚）、Shopify（e コマース中心）、あるいは カスタム構築（ユニークな要件）のいずれかへ向かいます。

正しい期待値を設定する

ある程度の再構築は通常です。すべてのウィジェットやテンプレート要素、アプリが正確に「移る」わけではありません。成功する移行は結果に集中します：同等（またはそれ以上）のコンテンツ、よりクリーンな構造、保持された SEO、そして初日から確実に動作する機能です。

切り替えのサイン

Wix や Squarespace からの移行は「新しいものが欲しいから」ではなく、業務を遅らせる摩擦を取り除くための判断であることがよくあります。以下のパターンに心当たりがあれば、プラットフォーム移行の方が回避策を積み重ねるより早いことがあります。

テンプレートの限界を超えてデザインコントロールが必要

変更するたびに回避策が必要（セクションのルールとの戦い、余白の調整、モバイルレイアウトの不具合）なら「テンプレート税」を払っている状態です。再利用可能なデザインコンポーネント、クリーンなページ構造、ページを量産しても都度デザインし直さない能力が必要になったら、Wix や Squarespace からの移行を検討すべきです。

機能の限界に何度も当たる

会員、詳細なフォーム、カスタムフィールド、予約ロジック、CRM/マーケティングスタックとの統合など、主要な機能が使えないか維持が困難なら切り替えの価値があります。複数のアプリに頼ってそれらがうまく連携しないなら、「サイト再構築 vs 移行」の判断は移行＋統合の整理に傾きます。

パフォーマンス目標が達成しにくい

画像を圧縮し、ページを整理し、不要なアドオンを外しても結果が頭打ちなら、プラットフォーム自体がボトルネックになっている可能性があります。パフォーマンス改善は単なるスコア向上ではなく、コンバージョン増につながることがあります。

SEO 要件が高度化している

URL、構造化データ、リダイレクト、コンテンツアーキテクチャを強く制御する必要が出てきたら移行が正当化されます。多くのランディングページやコンテンツライブラリを拡張する場合は特に、SEO 移行計画とウェブサイト移行チェックリストがランキングを守ります。

チームにより良いワークフローが必要

公開に一人に頼っている、権限・承認・ステージングがない、という状況なら成長が滞ります。権限が明確で編集プロセスが整ったプラットフォームはエラーを減らし、公開を速めます。

今は移行を見送るべきケース

移行が正しい判断のことは多いですが、必ずしも「今すぐ」行うべきとは限りません。現行の Wix や Squarespace サイトがビジネスを十分に支えているなら、切り替えはコストとリスクを追加するだけかもしれません。

サイトが既にビジネスを支えているなら保留

サイトが小規模で、読み込みも速く、安定してリードや売上を生んでいるなら、移行は気を散らす要因になり得ます。多くのビジネスはより柔軟なスタックではなく、より明確なメッセージ、良いページ、継続的な更新を必要とします。

頻繁な変更や新機能が不要なら保留

滅多にコンテンツを更新せず、大きな機能追加（会員、高度な SEO ツール、カスタム決済フロー、複雑な統合）を予定していないなら、現行プラットフォームであと 1 年はやれる可能性があります。

時間と予算が限られているなら保留

適切な移行は計画、主要テンプレートの再構築、コンテンツ移行、SEO の検証を伴います。繁忙期なら、ホームページの書き直し、サービスページの整理、速度改善など即効性のある改善を優先し、後で移行を検討する方が賢明です。

フィックスを先に検討する

多くの場合、問題はプラットフォームではなく実行です。次のことで痛みを解消できる場合があります：

• デザインやテンプレートのリフレッシュ
• コンテンツのクリーンアップ（古いページの削除、ナビゲーションの整理）
• コピーの改善と明確な CTA

アプリのロックインに注意

予約、フォーム、会員エリア、決済などプラットフォーム固有のアプリに依存している場合、移行先に同等のツールがあるかを確認してください。なければワークフローを一から作り直す必要が出ます。

移行を保留すると決めた場合でも、何がうまくいっていないかを記録しておいてください。そのリストが後の要件になり、将来の /blog/website-migration-checklist を実行しやすくします。

移行先プラットフォームの選び方

最適な移行先は「Wix と Squarespace のどちらが優れているか」よりも、サイトが今後何をする必要があるか（公開、販売、検索上位、カスタム機能のサポート）によります。

実務的な判断基準（本当に重要なこと）

次をチェックしてください：

• 編集のしやすさ: チームがレイアウトを壊さずに更新できるか
• 開発柔軟性: カスタムコードや統合、独自デザインシステムが必要か
• 総コスト: 月額料金、テンプレート、アプリ/プラグイン、有料フォーム、e コマース追加費用、保守費
• アプリ/プラグイン: 予約、会員、メールキャプチャ、解析など必要なツールが利用可能でサポートされているか
• SEO の基本: URL 構造の管理、301 リダイレクトの作成、sitemap/robots.txt（または sitemap とインデックス設定）ができるか

ユースケース別の比較

マーケティングサイト（リード獲得、サービス業）: Webflow または WordPress

ブログ／コンテンツ公開: WordPress または Ghost

オンラインストア: Shopify（または WordPress を使う場合は WooCommerce）

ポートフォリオ／軽量な案内サイト: Webflow、Framer、またはシンプルな WordPress テンプレート

「こういう場合はこれを選べ」ミニガイド

• WordPress を選ぶ: 最大限の柔軟性、豊富なプラグイン、強力なブログ機能が必要で、ホスティングを管理する（または外注する）前提がある場合。
• Webflow を選ぶ: デザインコントロールとクリーンなビジュアル編集が最優先で、プラグインのメンテが少ない方が良い場合。
• Shopify を選ぶ: e コマースがコアで、信頼性のあるチェックアウト、配送／税計算ツール、大きなアプリエコシステムが必要な場合。
• Ghost を選ぶ: 出版やニュースレターが中心で、軽量で高速なエディタを求める場合。

SEO が優先なら、リダイレクト対応と URL 制御を候補の上位に入れてください—この 2 点が移行でランキングを守れるか否かを左右することが多いです。

「長い開発を要さない」モダンなカスタム構築について

Wix／Squarespace を超えた要件がありつつ長期の従来型開発を避けたい場合、vibe-coding のような中間的な選択肢があります。例えば Koder.ai はチャットインターフェースでウェブアプリを作成し（React フロント、Go + PostgreSQL バックエンド）、ソースコードをエクスポート、デプロイ、スナップショット/ロールバックで反復できます。カスタムロジック（高度なフォーム、会員フロー、内部ツール）が移行に含まれる場合に有用です。

移行前監査: 完全なサイト在庫を作る

デザインや SEO 設定に触る前に、実際に何があるかを把握してください。多くの移行のトラブルは小さなもの（隠しランディング、古い PDF、フォーム統合）が再構築中に発見されることから始まります。

1) 訪問者がアクセスできるものをすべて棚卸しする

マスターリスト（スプレッドシートで十分）を作り、次を記録します：

• すべてのページ（プライバシー、サンクス、パスワード保護領域などのユーティリティページも含む）
• ブログ投稿、カテゴリ／タグ、著者ページ（該当する場合）
• 製品、コレクション、バリアント、デジタルダウンロード
• ギャラリー、ポートフォリオ、イベント、メニュー、ロケーションページ
• フォーム、ポップアップ、バナー、チャットウィジェット、リードマグネット

移行時にきれいに移らないため再作成が必要なもの（予約ツール、多言語構成、会員／ログイン、カスタムスクリプト、自動化）もリストアップしてください。

2) 現行の URL をすべて収集する（古いものも含む）

サイトをエクスポートまたはクロールして見つかるすべての URL を記録します：

• メインナビゲーションにない隠しページ
• 広告やメールで使われた古いキャンペーン/ランディング URL
• ブックマークされている可能性のある PDF やファイル URL

これが後のリダイレクトマップになり、SEO とユーザー体験を守ります。

3) ベースラインのパフォーマンス指標を取得する

移行後に後退していないかを確認するためのベンチマークを取得します：

• トラフィックとコンバージョンの多いページ
• Search Console のクエリ／ランディングページ（あれば）
• 主要なコンバージョンアクション（フォーム送信、購入、予約）

4) 資産とブランドの必需品をバックアップする

オリジナルの画像、動画、PDF、ロゴ、フォント、カラーコード、ウィジェット内のコピー（アナウンスバー、ポップアップ、フッター）をフォルダにまとめます。後で簡単にダウンロードできないものは「必ずバックアップするもの」として扱ってください。

SEO 計画: 移行中にランキングを守る

移行はビジネスにとって良い決断になり得ますが、Google がページを見つけられなくなってトラフィックが落ちると意味がありません。目標はシンプル：検索エンジンにとって新サイトが「見慣れた」ものに見えるようにすることです。

1) ビルド前に URL マップから始める

現在のサイトをエクスポートまたはクロールし、インデックス対象のすべての URL をリスト化します。次に各 URL が新サイトでどうなるかを決めます。

• 古い URL を新しい URL にマップ（可能なら構造を維持）
• 刈り取り、統合、改善するページを決める（薄いページや重複）

ページを削除する場合、すべてをホームページにリダイレクトしないでください。最も近い代替ページにリダイレクトするか、本当に代替がなければクリーンな 404 を返してください。

2) リダイレクトは納品物として計画する

リダイレクトは「Wix からの移行」が成功するか否かの違いを生みます。

• 301 リダイレクトを計画し、リダイレクトチェーンを避ける

古い URL → 新しい URL → 備考 の 3 列のスプレッドシートを作り、新しいプラットフォーム（またはサーバーレベル）でリダイレクトを実装します。まずステージングでテストしてください。

3) 既に機能しているオンページ要素を保持する

デザインが変わっても、実績のある SEO シグナルは可能な限り一貫して保ってください。

• タイトル、メタディスクリプション、見出し、alt テキストなどのオンページ要素を保持

特にトラフィックの多いページや投稿は注意深く扱ってください。サービスページをリデザインする場合でも、主題と意図を変えて汎用的なページにしないようにします。

4) ローンチ当日の技術的チェックを準備する

DNS を切り替える前に、新サイトがクロール可能で一貫していることを確認します。

• 準備する SEO チェック項目: sitemap、robots.txt、canonical タグ、schema

さらに確認すること：

• 新しいプロパティで解析 と Search Console が設定されている
• ステージングの「noindex」タグが残っていない
• 内部リンクが新しい URL を直接指している（リダイレクト先ではない）

慎重な SEO 移行計画は時間がかかりますが、再構築と成長の間にランキングを守る最もコスト効率の高い方法です。

コンテンツとメディア移行: 何がそのまま移るか

コンテンツは多くの場合、移行で最も時間がかかる部分です。理由はプラットフォームごとにコンテンツの保管方法が異なるためです。良いニュースは、主要な「コア」コンテンツの多くは移せるということです。

通常エクスポートできるもの

ブログ投稿と基本ページはテキストレベルでは移ることが多いです。Squarespace は一般的な CMS 形式へのエクスポートを提供しますが、Wix のエクスポートは制限が多いことがあります—構造化データをエクスポートしてからフォーマットを組み直す準備をしてください。

製品やストアデータは多くの場合 CSV（製品、バリアント、価格、SKU）でエクスポート可能です。これは Shopify、WooCommerce、その他のプラットフォームへの再インポートの良い出発点です。注文履歴や顧客アカウントは部分的であったり、別途エクスポートが必要なことがあります。

手動と自動の移行オプション

通常は次の選択肢のいずれかになります：

• 製品や一部のブログメタデータ、リダイレクト、リストに対する CSV のエクスポート/インポート
• レイアウトが高度にカスタマイズされている場合の コピペまたはページ再作成
• サポートされている場合にフィード／API 経由でコンテンツを引く 移行ツール（投稿や基本ページには有用だが複雑なレイアウトには信頼性が低い）

実務的なアプローチは「データベースは自動で、プレゼンテーションは手動で再構築する」ことです。これで速度と品質を両立できます。

画像とメディア: 気を付けること

メディアは完璧には移行しないことが多いです。計画として：

• 可能なら ファイル名を保持する（整理や SEO に有利）
• 画像を新しい メディアライブラリに再アップロードし、一貫したフォルダ/コレクションルールを設ける
• アップロード時（または事前）に 圧縮を行ってサイト速度を保つ
• alt テキストを再作成する—エクスポートに含まれないことが多いのでインベントリでキャプチャする

フォーマットの落とし穴（テーブル、埋め込み、ボタン）

テーブル、ボタン、多段カラムセクションなどは、ビジュアルエディタで作られている場合は再構築が必要になることを想定してください。その他チェックポイント：

• 埋め込み（YouTube、Calendly、地図）：新プラットフォームのブロックで再埋め込みする
• ショートコードやプラットフォーム固有ウィジェット：同等のプラグイン／アプリで置き換える

コメント、タグ、カテゴリ、著者

移行前に何を残すべきか決めてください：

• タグ／カテゴリ: 通常移行可能だが名前や URL 構造が変わることがある
• 著者: 真のマルチ著者を保持するか、単なるバイラインでよいか確認
• コメント: ネイティブコメントは移行しにくいことが多い。アーカイブ用にエクスポートするか、コミュニティが重要ならサードパーティを検討

コンテンツ移行を「管理された再構築」として扱えば、よりクリーンなページ、軽いメディア、SEO の驚きを減らせます。

デザインと機能: ゼロから始めずに再構築する

移行は、機能しているビジュアルと機能を保持しつつ、古い回避策を引きずらないチャンスです。目的はピクセル単位のクローンではなく、訪問者にとって馴染みある体験を、将来的な更新が容易なクリーンな構成で提供することです。

主要テンプレートを先に再現する

サイトの 80% を占める代表的なページテンプレートの小さなセットを最初に作ります。多くのビジネスでは次が該当します：

• ホームページ（主要メッセージ、信頼要素、主要 CTA）
• サービスページ（利点、プロセス、FAQ、問い合わせ導線）
• ブログ投稿（可読性、見出し、著者/日付、関連コンテンツ）
• 製品ページ（該当する場合：価格、バリアント、配送/返品、レビュー）

これらを整えれば残りはバリエーションとして素早く作れます。

ブランドの基本を先に合わせる

詳細にこだわる前にブランドの「システム」を固めます：タイポグラフィ、色、間隔、再利用コンポーネント（ボタン、カード、コールアウト、フォームフィールド）。基本が一貫していれば、レイアウトの細部が変わってもサイトはブランドらしく見えます。

再利用可能なコンポーネントセットを作ってください：

• プライマリ／セカンダリボタン
• セクションヘッダーと導入テキスト
• 推薦ブロック（テスティモニアル）
• FAQ アコーディオンまたはシンプルな Q&A レイアウト
• 料金表やパッケージカード

重要な機能を意図的に再構築し、不要は切る

必須機能をリストにして、単にプラグインを複製するのではなく意図的に再構築します。

確認すべき一般的な「重要」機能：

• フォーム（問い合わせ、リードマグネット、ファイルアップロード、オートレスポンダ）
• 予約／スケジューリング（可用性、タイムゾーン、確認メッセージ）
• e コマース（税/配送ルール、割引、在庫、放棄カート）
• サイト内検索（特にブログや製品カタログ）

プラットフォームの制約のためだけに存在していた機能（例えばナビゲーションを模擬するための余分なページ）は、新しいプラットフォームでは不要かもしれません。

後で高コストになる前にアクセシビリティの基本を入れる

最初からアクセシビリティを組み込んでください。後付けは遅くてミスが生じやすいです。

基本に注力：

• テキストとボタンの十分なコントラスト
• キーボードナビゲーション向けのフォーカス状態の可視化
• フォームラベルの適切な配置（プレースホルダのみは不可）
• 明確な見出し構造（H1、次に H2/H3 の順）

ミニスタイルガイドを残す

移行が終わる前に、設定したルール（フォント、色、ボタン、間隔、主要コンポーネントの使い方）を書き留めておいてください。一ページの簡易スタイルガイドでも、将来的な編集の一貫性を保ち、デザインの漂流を防げます。

移行プロジェクト計画とタイムライン

スムーズな移行は「ファイルを移す」よりも、小さなプロジェクトを回すことに近く、明確なステップ、担当者、切り替えの手順が必要です。目的は特にナビゲーション、SEO、DNS 周りの最後の混乱を避けることです。

ローンチのアプローチを選ぶ

一斉切り替え（Big bang）: サイト全体を再構築して一度に切り替える方法。伝達が簡単で速い反面、リスクがローンチ日に集中します。

段階的ローンチ（Phased rollout）: セクションごとに順次移行する方法（例：まずブログ、その後サービス、最後に e コマース）。リスクは分散できますが、重複ページや競合が起きないよう綿密な追跡が必要です。

コンテンツをインポートする前に構造を作る

まず サイトマップ、URL 構造、ナビゲーション を確定してください。コンテンツを早期にインポート／書き直すと何度も整理し直すことになりがちです。どのページを残し、統合／削除するか、メニューはどうなるかを明確にします。

ステージングとコンテンツフリーズを使う

ステージング環境（非公開のプレビューサイト）を用意して安全に再構築し、リリース直前に コンテンツフリーズ（旧サイトの編集を一時停止する期間）を設定してください。これで最後の更新や新規投稿・製品変更を見逃しません。

所有者を割り振り、決定を記録する

各ワークストリームに明確な担当をつけてください：SEO、コンテンツ、デザイン/機能、QA、ドメイン/DNS。リダイレクト、ページ削除、フォームの送信先、ローンチタスクなどの決定は一つの共有ドキュメント（ウェブサイト移行チェックリスト）で管理して、後で「誰が承認したのか？」の問題を避けます。

現実的なタイムライン（目安）

ほとんどの小〜中規模サイトは 2–6 週：計画／構造に 1 週、再構築＋コンテンツに 1–3 週、QA と修正に 1 週、その後ローンチ＋ポストローンチ監視、という配分が一般的です。

ドメイン、メール、DNS: 何も失わずに切り替える

ここは「ウェブサイト」以外の重要なもの（メール、トラッキング、ログイン）をうっかり壊しやすい部分です。簡単な計画があれば、ほとんどダウンタイムなしで切り替えられます。

ドメイン移管 vs DNS 指向（どちらを選ぶか）

Wix や Squarespace から移行する場合、主に 2 つの選択肢があります：

• ドメインを移管する: 長期的な請求の簡素化につながるが遅く、承認やロック解除、待機が必要
• ドメインはそのままにして DNS を更新する: 移行中は最速で安全な方法。特定の時間に切り替え可能

多くの移行ではまず DNS をポイント して安定させ、すべてが正常になってから移管するのが実用的です。

メールを守る: まず MX レコード

メールは MX レコード で制御されています。変更前の手順：

1. 現在の DNS ゾーンをエクスポート（またはスクリーンショット）
2. メールプロバイダ（Google Workspace、Microsoft 365 等）を特定
3. 同じ MX レコード および必要な TXT レコード（SPF、DKIM、DMARC）を維持する

DNS を上書きしてこれらのレコードを再現しないとメール配信が止まります。

「隠れた」DNS レコードを忘れないで

サイト A/AAAA レコードとメールの MX のほかに、多くのビジネスが依存しているもの：

• ドメイン検証やセキュリティ用の TXT レコード
• メールトラッキングやランディングページ、サポートウィジェット用の CNAME レコード

切り替え前に、解析、広告ピクセル、CRM/フォーム、スケジューリングツール、支払いプロバイダなどの再確認が必要な統合をすべてリストアップしてください。

SSL、セキュリティ、バックアップ

新しいプラットフォームで確認すること：

• SSL が有効（https:// で読み込まれる）
• バックアップが有効（ロールバックプランがある）
• 基本的なセキュリティ設定（管理者アクセス、更新、フォームのスパム対策）

ダウンタイムを避ける: TTL を下げて切り替えを予定する

DNS の TTL（Time-To-Live）を切り替え 24–48 時間前に下げると、変更の浸透が早くなり、ダウンタイムが減ります。トラフィックの少ない窓を選んで切り替え、直後に次を検証してください：ホームページの読み込み、主要フォームの動作、チェックアウト（該当する場合）、メール送受信。

ローンチと QA チェックリスト

ローンチ日は「スイッチを切る日」ではなく、新しいサイトが訪問者と検索エンジンにとって旧サイトと同等（あるいはそれ以上）に振る舞うか確認する日です。下記チェックリストで一般的な見落としを防いでください。

1) コア機能（売上に直結するもの）

実際のユーザーパスをテストしてください—ホームページを眺めるだけでは不十分です。

• リンク: ナビゲーション、フッター、ボタン、高トラフィックのブログ投稿をスポットチェック
• フォーム: すべてのフォームをエンドツーエンドでテスト（確認メッセージ、メール配信、CRM/Zapier 接続）
• 検索: いくつかクエリを実行し、結果ページとフィルタを確認
• チェックアウト／支払い（該当する場合）: 実トランザクションかサンドボックスでテスト
• トラッキング: 解析や広告ピクセルが主要イベント（ページビュー、フォーム送信、購入）で発火しているか
• 404: 既知の古い URL にアクセスしてリダイレクト（または親切な 404）が行われるか確認

2) モバイル、ブラウザ、速度のスポットチェック

• まずは モバイル（メニュー、固定ヘッダー、タップ領域、画像の切り抜き）でテスト
• 少なくとも Chrome、Safari、Firefox で確認
• 速度測定ツールで簡易チェック。大きすぎる画像、埋め込み動画、重いスライダーに注意

3) リダイレクト確認（ランキングを守る）

すべてを手動で検証するのは非現実的なので：

• 主要ページ（ホーム、サービス、重要なブログ投稿）のサンプルを取り、古い→新しいリダイレクトを確認
• 過去に共有したレガシー URL もいくつか含める（ソーシャル投稿、メールキャンペーン）

4) ローンチ後に行う検索エンジン向けの手順

• XML サイトマップを生成／確認して 送信
• サイトをサーチツールで検証し、重要ページをインデックス要求

5) 2–4 週間の監視

小さな変動は予想されます。重要なのは傾向とエラーです。

• クローラーエラー、リダイレクト、404 レポートを監視
• 週単位でトラフィックとコンバージョンを比較
• 修正ログを短く保ち、問題が繰り返し発生しないようにする

費用、労力、外部支援の検討

移行は「一律の価格」ではありません。小さなプロジェクトの束として積み上がるため、バケツ分けして予算を立てると良いです。

よくあるコスト項目

• デザイン／ビルド: テンプレート、レイアウト、コンポーネント、モバイル調整の再構築
• コンテンツ作業: 書き直し、フォーマット、ページ移行、新規ランディング作成
• メディア／資産: 画像圧縮、ダウンロード、alt テキスト整理
• SEO／解析: リダイレクト、メタデータ、サイトマップ、GA4/GSC 設定、トラッキングチェック
• ツール／サブスクリプション: プラグイン／アプリ、フォーム、メールマーケ、レビュー、CRM
• ホスティング／保守: 新しいホスティングプラン、バックアップ、セキュリティ、継続的な編集

努力量を左右する要素（タイムライン）

工数は次で大きく変わります：

• ページ数とそれらの差異
• 複雑さ：ブログ、会員、予約、多言語、カスタムフォーム
• e コマース：製品数、バリアント、サブスクリプション、配送/税のルール
• カスタム機能：計算機、ゲートコンテンツ、統合（Zapier/CRM）
• 承認の速さ

小さな案内サイトなら週末で DIY 可能ですが、コンテンツが多いか e コマースが絡むと修正とテストを含め数週間かかります。

DIY と外注（リスクのトレードオフ）

サイトが単純でチェックリストに従える時間があるなら DIY は機能します。ランキングや収益が重要なら外注の価値は高いです—壊れたリダイレクト、欠けたメタデータ、チェックアウト問題はプロジェクト費用以上の損失を生むことがあります。

移行の一環で再構築するなら、ローンチ後にどう反復していくかを考えてください。Koder.ai のようなプラットフォームはチャットから新しいアプリ構造を生成し、計画モードをサポートし、準備ができたらソースコードをエクスポートしてスタックを所有できる点でスピードを保つのに役立ちます。

もしおおよその見積りが欲しい場合は、インベントリと目標を /contact 経由で共有するか、/pricing を比較してください。

コピペ用のスコープテンプレート

Project goal:
Current platform (Wix/Squarespace):
New platform:
Pages to migrate (count + key URLs):
Blog posts (count):
Ecommerce? (products/SKUs/variants):
Must-have features (forms, booking, members, etc):
Integrations (email/CRM/payments):
SEO requirements (redirects, metadata, analytics):
Design notes (keep similar vs redesign):
Target launch date:
Who provides copy/images:
Who approves and how fast: