WixからWordPressへ移行する前の確認項目｜URL・データ・機能・費用

WixからWordPressへの移行は、現在のサイトを丸ごとコピーして置き場所だけ変える作業ではありません。Wixで作ったサイトはWixの仕組みとサーバー上で動くため、WordPress側ではページ、デザイン、機能、更新方法をそれぞれ確認し、必要なものを作り直す工程が含まれます。

見積もりを依頼する前に決めたいのは、細かな制作方法よりも「何を残すか」「何を作り直すか」「何をやめるか」と「どの状態を完成とするか」です。この線引きがないまま相談すると、同じサイトを見ても制作会社ごとに想定する作業範囲が変わり、金額や納期を比較しにくくなります。

この記事では、URL、ページ・ブログ・画像、フォーム・予約・会員などの機能、ドメイン・メール、SEO、テスト、費用を一つずつ整理します。読了後には、現行Wixサイトの棚卸しと、WordPressで再構築する範囲を見積もりに反映できる状態を目指します。

移行方法より先に、完成条件と3つの分類を決める

最初に作るべきものは、移行ツールの候補一覧ではなく、現行サイトの構成表です。公開中のURLだけでなく、下書き、会員限定ページ、検索結果に出していないページ、ブログ、資料PDF、フォーム、予約画面、外部サービスへの導線まで対象に含めます。サイト上で見えるものだけを数えると、公開直前に「この受付メールも必要だった」「この会員向けページが抜けていた」と分かり、追加作業になりやすいためです。

棚卸しした項目は、次の3つに分けます。

分類	判断の基準	主な対象例	見積もりで確かめること
移行	内容や目的を変えず、データまたは原稿として引き継げる	会社情報、サービス説明、自社で用意した画像、CMSコレクションのデータ	取得方法、項目数、欠損時の補正、WordPress側への登録方法
再構築	Wix固有の表示や処理を、WordPressまたは外部サービスで作り直す	デザイン、フォーム、予約、会員、決済、自動通知、検索・絞り込み	画面だけでなく、権限・通知・保存先・運用手順まで含むか
廃止	現在の目的に合わない、重複している、運用されていない	古いキャンペーン、重複ページ、使われていない機能、不要な導線	旧URLの扱い、保管の要否、リンク切れを起こさない方法

「移行」は自動処理だけを意味しません。原稿を人が確認しながらWordPressへ登録する場合も、内容を変えずに引き継ぐなら移行です。一方、見た目が似ていても、入力項目、通知先、確認画面、データ保存、担当者の操作が変わるフォームは再構築として扱います。この区別を先に付けると、ページ数だけでは見えない作業が表に出ます。

同時に、完成条件も書いておきます。「公開できること」だけでは判定できません。たとえばフォームなら、送信できる、担当者へ届く、自動返信が届く、迷惑メール対策が動く、必要な計測ができるところまでを一組にします。ブログなら、本文だけでなく、公開日、著者、カテゴリ、アイキャッチ、代替テキスト、内部リンクが必要かを決めます。完成条件が具体的であれば、制作会社が違っても見積もりの前提をそろえやすくなります。

契約・権限・ドメイン・メールを止めずに切り分ける

サイト内容の前に、誰が何を管理しているかを確認します。Wixのログインができても、ドメイン、ビジネスメール、決済、外部アプリの契約者が別人になっていることがあります。退職者や以前の制作会社の個人アカウントに依存している場合、公開日にDNSを変更できない、請求情報を確認できない、二段階認証を通せないといった問題が起こります。

最低限、次の管理先を一覧にします。

• Wixサイトの所有者と共同管理者。所有権を変更できる人、二段階認証を受け取れる人
• Wixの有料プラン、アプリ、ストレージなどの契約と更新日
• 独自ドメインの登録事業者、契約者名、管理画面、移管またはDNS変更の可否
• メールサービスの提供元、利用中のアドレス、MX・SPF・DKIMなどのDNS設定
• Google Analytics、Search Console、広告、タグ管理、外部フォームなどの管理者
• 予約、会員、決済、チャット、ニュースレターなど、Wix外も含む関連サービス

ドメインは「Wixで使っている」だけでは管理方法を判断できません。Wixで取得したドメインをそのまま外部サイトへ接続する方法と、登録事業者ごと移管する方法では、準備と所要時間が異なります。移管には登録直後や連絡先変更後の制限が関係する場合もあるため、公開日から逆算して現在の状態を確認します。移行を決めた直後にWixの契約やドメインを解約してはいけません。新サイトの検証、DNS切替、メール送受信、旧URLの処理が終わるまでは、旧環境を確認できる期間が必要です。

特に見落としやすいのがメールです。ドメインの接続先を変えるとき、Webサイト用のAレコードやCNAMEだけを見て作業すると、メール用のMXレコードや送信認証の設定が抜けることがあります。Webサイトが表示されても問い合わせメールが受け取れない状態は、移行成功とはいえません。現在のDNSレコードを事前に控え、新しい管理先で再現する設定と、切替後に試験する送受信先を決めておきます。

アカウント情報を制作会社へ渡す場合も、共有方法と作業後の扱いを決めます。可能であれば共同管理者や期間限定の権限を使い、個人のパスワードをそのまま共有しない方法を選びます。公開後に不要な権限を削除し、管理者一覧を更新するところまでを引き継ぎ条件に含めると、運用開始後の不明点を減らせます。

ページ・ブログ・画像・CMSデータは別々に棚卸しする

Wixサイト全体を、WordPressでそのまま動く一つのファイルとして書き出す共通手段はありません。一方で、すべてを手入力するしかないとも限りません。WixのCMSコレクションはCSVで出力でき、自分でアップロードした画像や動画はメディアマネージャーから取得できます。連絡先もCSV出力の対象です。つまり、「サイト全体を一括移行できるか」ではなく、資産ごとに取得方法と利用条件を確かめる必要があります。

ページ棚卸しでは、URLとタイトルだけでなく、次の列を持たせると作業範囲が分かりやすくなります。

• 現在のURL、ページ名、公開状態、検索対象かどうか
• ページ種別。固定ページ、ブログ、動的ページ、会員限定、ランディングページなど
• 本文、画像、動画、PDF、埋め込み、構造化データなどの構成要素
• 流用、書き直し、統合、廃止の判断
• 新サイトで使うテンプレートと新URL
• 原稿・画像の確認担当者と、公開前の承認状態

ブログは、本文を移せるかだけでなく、記事同士のつながりを確認します。カテゴリ、タグ、著者、公開日、更新日、アイキャッチ、抜粋、関連記事、内部リンク、外部リンク、コメントの扱いが変わると、移行後の一覧や導線も変わります。記事本文のHTMLを取り込めても、画像の保存先がWixのまま、見出し階層が崩れている、不要な装飾コードが残っている場合は、後で修正が必要です。数件で試験し、変換後の状態を見てから全件の方法を決めます。

WordPress.comにはWixサイトのURLを指定するインポート機能がありますが、これはWordPress.comの機能であり、任意のレンタルサーバーへ設置するWordPressで同じ手順が使えるとは限りません。また、WordPress.comの英語版と日本語版の案内では、ブログ投稿の取り扱いに差が見られます。仕様説明だけで移行件数を確定せず、実際の移行先環境でテストインポートを行い、固定ページ、ブログ、画像、メニューがどこまで入り、何を手作業で補うかを確認するのが安全です。

画像については、ファイルを取得できるかと、移行後に使い続けられるかを分けます。Wixへ自社でアップロードした素材は取得対象になりますが、Wixの無料素材や外部ストック素材はダウンロードできないものがあります。元データ、撮影者・購入者、利用ライセンスを確認し、必要なら別の素材へ差し替えます。画像が取得できても、ファイル名、代替テキスト、キャプション、圧縮、サイズ違いの生成などはWordPress側で整え直すことがあります。

CMSコレクションをCSVで出力できる場合も、列がそのままWordPressの投稿項目になるとは限りません。Wix側の参照フィールド、複数選択、日付、画像、リッチテキスト、公開状態などを、WordPressの投稿タイプ、タクソノミー、カスタムフィールドへどう対応させるかを決めます。CSVがあることは移行可能性の確認にはなりますが、データ設計と取り込み後の検証は別工程です。

フォーム・予約・会員・決済は画面ではなく業務を再構築する

機能移行で確認すべきなのは、利用者が見る画面だけではありません。問い合わせフォームを例にすると、入力欄のほかに、必須条件、確認画面、同意文、送信後の表示、自動返信、社内通知、保存先、スパム対策、添付ファイル、計測、個人情報の保管期間があります。見た目を再現しても、担当者の業務がつながらなければ移行後に受付が止まります。

各機能は「入力」「処理」「保存」「通知」「権限」「外部連携」「例外対応」の順に確認すると抜けを見つけやすくなります。予約機能なら、予約枠、定休日、担当者、所要時間、変更・キャンセル、リマインド、決済、顧客台帳、管理者の調整操作まで含めます。会員機能なら、登録、本人確認、ログイン、パスワード再設定、会員別の表示、退会、データ削除を確認します。決済がある場合は、商品・税・送料・返金・通知・売上管理など、サイト外の運用も対象です。

既存データの扱いは、次の3種類に分けて決めます。

1. 新システムへ移すデータ。継続利用に必要で、項目と同意範囲を確認できるもの
2. 参照用として別途保管するデータ。履歴確認は必要だが、新システムの通常操作には入れないもの
3. 移さず、規程に沿って削除するデータ。用途が終わり、保管根拠がないもの

会員や予約の「件数」だけでは難易度を判断できません。顧客ごとの履歴、未消化の回数券、継続契約、予約変更、権限、メール配信への同意など、レコード同士の関係があるほど検証が増えます。制作会社へは、個人情報を渡す前に項目一覧と匿名サンプルで相談し、実データの受け渡し方法、保管場所、削除時期を決めます。

また、Wixで利用していた機能をWordPressプラグインへ置き換えることだけが正解ではありません。予約や決済を外部サービスへ分けたほうが、保守責任や更新の負担を明確にできる場合があります。反対に、外部サービスを増やすと、契約、月額費用、ログイン、データ連携、障害時の窓口も増えます。移行前と同じ操作を再現するか、新しい運用へ変えるかを決め、見積もりに「選定・設定・データ移行・操作説明」のどこまで含むかを明記します。

旧URLと新URLの対応表をSEO移行の中心にする

SEOの引き継ぎで重要なのは、WordPressを使うこと自体ではなく、旧サイトで評価や流入を得ているURLを、新サイトの適切なページへつなぐことです。先にWordPressのパーマリンクを決め、旧URLと新URLの対応表を作ります。ページ名が似ていても、目的が異なるページへ機械的に結び付けないことが大切です。

URL対応表には、少なくとも次を入れます。

項目	記録する内容
旧URL	現在公開されている正規URL。末尾スラッシュや大文字小文字も確認
新URL	WordPressで公開するURL。公開前の仮URLではなく本番形を記録
対応方法	301リダイレクト、内容統合、廃止、現状維持など
対応先の理由	同じ検索意図・内容を引き継ぐページであることを説明
関連修正	内部リンク、canonical、サイトマップ、構造化データ、広告リンクなど
確認結果	公開後のステータスコード、遷移先、表示、インデックス状況

旧URLをすべてトップページへ転送すると、利用者は探していた情報へ到達できず、検索エンジンにも対応関係が伝わりにくくなります。同じ内容を引き継ぐ新ページがある場合は一対一で恒久的なリダイレクトを設定し、統合する場合は最も関連するページへつなぎます。代替ページがない場合は、無関係な転送を作るより、廃止の扱いを明確にするほうがよいケースもあります。

リダイレクトの実装場所も見積もり前に確認します。WixにはWix内でURL転送を管理する機能がありますが、ドメインの接続先をWordPress側へ切り替えた後も同じ設定が処理されるとは限りません。新しいサーバー、CDN、リバースプロキシ、WordPressなど、公開後に実際にリクエストを受ける場所で設定・検証する必要があります。制作会社へ「301対応込み」とだけ伝えるのではなく、対応URL数、設定場所、テスト方法、公開後の修正期間を確認します。

公開前には、ステージング環境を検索対象にしない設定を確認し、本番ではその制限を外します。公開後は、内部リンクを新URLへ更新し、canonical、XMLサイトマップ、robots.txt、構造化データ、Search Consoleの登録状態を確認します。Googleはサイト移行時のリダイレクトを少なくとも1年間維持するよう案内しています。Wixの契約終了や旧環境の削除を先に行わず、旧URLから新URLへの処理が継続できる構成と期間を決めておきます。

検索順位やアクセスは、正しく移行しても一時的に変動する可能性があります。順位保証ではなく、公開前の主要URL・検索流入・被リンクの記録、公開後のクロールエラー・インデックス・流入の監視、問題が起きたときの修正担当を合意しておくことが現実的です。

デザインの再現範囲とWordPressでの更新方法を分けて決める

「今のデザインをそのまま」と伝えても、どこまで同じにするかは人によって異なります。色や雰囲気を残すのか、各ページの余白やアニメーションまで再現するのか、スマートフォン表示も含めて画面単位で合わせるのかによって、作業量は大きく変わります。Wixのテンプレートや配置をWordPressへ直接移すのではなく、新しいテーマやブロック、テンプレートとして組み直すためです。

再現が必要なものと、再設計してよいものを分けます。ロゴ、ブランドカラー、写真のトーンなどは維持し、情報の順序、導線、見出し、ボタン、スマートフォンでの並びは改善する、といった決め方ができます。反対に、広告や紙媒体と同じ見た目を守る必要があるページは、優先度と確認者を明記します。

デザイン確認では、代表ページだけでなくテンプレートの種類を数えます。トップ、会社案内、サービス詳細、一覧、記事詳細、問い合わせ、検索結果、404、会員画面などです。固定ページが50ページあっても、同じテンプレートへ原稿を流し込めるなら設計数は限られます。一方、10ページでもすべて構成が異なり、アニメーションや独自機能があると制作範囲は増えます。見積もりでは「ページ数」と「テンプレート数」を分けて確認します。

WordPressへ移行する目的に更新のしやすさが含まれるなら、管理画面側の設計も完成条件です。誰が、どの頻度で、何を更新するかを決め、自由入力と固定デザインの境界を設計します。何でも変更できる画面は柔軟ですが、レイアウト崩れや入力ルールの複雑化につながります。商品、実績、スタッフ、よくある質問など、繰り返し追加する内容は項目を定型化し、固定ページの大幅変更は制作会社へ依頼するなど、運用に合う分担を選びます。

納品時には、操作説明の対象も確認します。記事投稿だけか、画像の圧縮、カテゴリ管理、メニュー変更、フォーム確認、権限追加、バックアップ復元まで含むかで必要な資料が変わります。更新担当者が実際にテスト環境で操作し、「追加できる」「表示が崩れない」「承認手順が分かる」ことを確認すると、公開後の使いにくさを減らせます。

費用差はページ数より、再構築・検証・公開切替の範囲から生まれる

WixからWordPressへの移行費用を、ページ単価だけで比べるのは難しいものです。費用を左右するのは、何件あるかに加えて、どの方法で取得し、どこまで整え、何を試験し、誰が公開切替を担当するかだからです。

見積もりの内訳は、次のような作業群に分けると比較しやすくなります。

• 現状調査：URL、契約、権限、機能、外部連携、アクセス状況の確認
• 情報設計：新しいサイト構成、テンプレート、パーマリンク、統合・廃止の判断
• デザイン：現状再現、改善案、スマートフォン対応、部品設計
• コンテンツ移行：固定ページ、ブログ、画像、PDF、CMSデータの取得・登録・補正
• 機能再構築：フォーム、検索、予約、会員、決済、自動通知、外部連携
• SEO移行：URL対応表、301、内部リンク、canonical、サイトマップ、計測設定
• 品質確認：表示、操作、メール、権限、端末、ブラウザ、アクセシビリティ、データ件数
• 公開切替：バックアップ、更新停止、差分反映、DNS、SSL、メール、切り戻し準備
• 公開後対応：エラー監視、軽微修正、操作説明、旧契約終了の確認

同じ「30ページ移行」でも、完成原稿と元画像がそろい、共通テンプレートへ登録する案件と、公開ページから内容を回収し、重複を整理し、画像権利を確認しながら書き直す案件では作業が異なります。予約や会員データも、CSVを一度取り込むだけなのか、継続中の予約と履歴を保ちながら切り替えるのかで検証量が変わります。

比較するときは、総額だけでなく、前提と除外を並べます。「原稿の修正は含まない」「画像取得は依頼者が行う」「301は指定されたURLのみ」「フォームの送信テストは1種類」「公開後の修正は別途」など、見積書に書かれた境界を確認します。安く見える見積もりでも、必要な作業が依頼者側に残っていれば、社内工数や追加発注が増える可能性があります。

反対に、現行サイトのすべてを残す前提も費用を押し上げます。アクセスがなく、内容が重複し、今後も更新しないページまで移す必要はありません。公開前の棚卸しで統合・廃止を決めれば、登録作業だけでなく、確認、リダイレクト、公開後の保守対象も減らせます。ただし、削除は検索流入や被リンク、法令・契約上の保管、顧客対応への影響を確認してから決めます。

見積もり依頼時には、現行サイトURLに加え、URL一覧、機能一覧、希望するデザイン方針、移行したいデータ、更新担当、公開希望時期、避けたい停止時間を共有できると、制作会社は条件を具体化しやすくなります。すべてを完成させてから相談する必要はありませんが、「未決定の項目」と「誰がいつ決めるか」を区別しておくと、仮定に基づく金額が減ります。

テスト、公開、Wix契約終了を一つの工程にする

新しいWordPressサイトが完成してから公開方法を考えるのでは遅くなります。Wix側で更新が続く期間、WordPressへ移した後に発生する差分、DNS切替、メール、フォーム、リダイレクトを一続きの工程として計画します。

公開前のテストは、見た目だけでなく業務単位で行います。

• 全URLとメニュー、パンくず、記事内リンク、PDFリンクが正しい
• スマートフォン、タブレット、PCで主要ページとフォームが使える
• 問い合わせ、予約、会員登録などを実際に操作し、画面・通知・保存結果を確認できる
• 管理者、編集者などの権限で必要な操作だけができる
• GA4、Search Console、広告タグ、キーイベントなど、必要な計測が動く
• 旧URLの主要サンプルが正しい新URLへ301で移動する
• SSL、Cookie、プライバシー表示、迷惑メール対策、バックアップが想定どおり動く
• ドメイン切替後もWebとメールの両方を確認できる

公開直前には、Wixサイトの更新を一時的に止める日時を決めます。停止できない場合は、初回移行後に増えた記事、問い合わせ、予約、会員情報をどう差分反映するかを決めます。特に動的データは、古いスナップショットを本番へ入れると最新の受付が欠けるため、最終取得時刻と切替時刻を管理します。

切替時には、担当者、連絡方法、判断期限、切り戻し条件を決めておきます。DNS変更後に不具合が見つかった場合、どこまでならその場で修正し、どの状態なら旧サイトへ戻すのかが決まっていれば、公開日の混乱を抑えられます。DNSの反映には利用環境による時間差があるため、社内だけでなく、別回線や外部の確認手段も用意します。

Wixの有料プラン、アプリ、ドメイン、メールの終了日は同じとは限りません。新サイトが表示された時点ですぐ解約するのではなく、データ取得、旧URL処理、メール、請求、必要なバックアップ、公開後の監視を確認してから個別に終了します。契約を残す期間と費用も、移行予算に含めておくと判断しやすくなります。

公開後は、主要ページの表示とフォームだけでなく、404、リダイレクト、インデックス、検索流入、メールエラーを一定期間確認します。問題が起きたときに、制作会社、サーバー、ドメイン、メール、外部サービスのどこへ連絡するかを一覧にし、移行プロジェクトの資料を運用担当へ引き継ぎます。ここまで終わって、WixからWordPressへの移行が完了したといえます。

WordPressを選ぶ前段階なら、CMS比較と分けて考える

この記事は、移行先としてWordPressを検討している段階で、発注前に何を確認するかを扱っています。そもそもWordPressが自社の更新体制や保守方針に合うか決まっていない場合は、先に「【CMSの選び方】中小企業が押さえるポイント」で、SaaS型とオープンソース型を含めて運用条件を比較するほうが順序として自然です。

CMS選びの記事が答えるのは「どの仕組みを選ぶか」です。この記事が答えるのは「Wixで運用してきた資産と業務を、WordPressへどう引き継ぐか」です。二つを混ぜず、WordPressを選ぶ判断と、移行範囲を決める判断を分けると、プラットフォーム変更そのものが目的になるのを防げます。

まとめ｜移行・再構築・廃止を決めると、見積もりの前提がそろう

WixからWordPressへ移行する前には、現行サイトをURL、コンテンツ、機能、契約、運用に分け、各項目を「移行」「再構築」「廃止」に分類します。そのうえで、旧新URLの対応、データの取得方法、機能の完成条件、ドメイン・メールの切替、テスト、公開後の監視までを一つの計画にします。

制作会社へ渡す資料は、完璧な仕様書である必要はありません。現行URL一覧、機能一覧、管理サービス一覧、残したいものと見直したいもの、未決定事項が分かれば、どこから調べるべきかを共有できます。見積もりの差を金額だけで見るのではなく、調査、再構築、データ補正、SEO、検証、公開切替、公開後対応のどこまで含むかで比較することが、移行後の追加作業と運用停止を避ける近道です。