WordPressからFramerへ移行する7ステップ｜SEOを落とさない実務手順

WordPressとFramerはどんなツール？PHPとの関係も整理

移行を考える前に、2つのツールの違いを押さえておくと判断しやすくなります。どちらもWebサイトを作って運用するためのものですが、サイトを公開する仕組みが異なります。

WordPressは、記事やページをデータベースに保存し、サーバー上でPHPというプログラミング言語を動かして表示するCMSです。テーマやプラグインで機能を追加できるため、記事数が多いメディアや、独自の要件があるサイトにも対応しやすい一方、PHP・WordPress本体・プラグインの更新を自社または保守担当が続ける前提になります。

Framerは、ブラウザ上でサイトをデザインし、そのまま公開できるツールです。Framerのホスティングで配信され、WordPressのようにPHPを使ったサーバー処理を実行する構成ではありません。CMS機能もあるため、サービスページやLPの更新・改善を自社で早く回したい場合に向きます。

PHPはWordPressが動くための土台です。そのためPHPに脆弱性が見つかると、PHPで動くWordPressサイトも更新対応の対象になります。Framerのサイトは自社でPHPを管理する構成ではありませんが、セキュリティ対応がゼロになるわけではなく、アカウント権限やフォーム・外部連携などは利用企業側の管理が残ります。この違いを踏まえたうえで、次章からPHPの更新確認と移行判断を順に見ていきます。

WordPressとFramerの機能や更新しやすさ、セキュリティ、費用の違いをより詳しく比較したい方は、WordPressとFramerを比較｜更新しやすさ・セキュリティ・費用で選ぶなら？もあわせてご覧ください。

WordPressからFramerへ移行する前に、PHPの更新確認をする

最初に行うのは、移行先を決めることではなく、現在のPHP環境に必要な更新が適用されているかの確認です。PHP公式は2026年10月21日、二つの重大な脆弱性を修正するリリースとしてPHP 8.5.12、8.4.27、8.3.36、8.2.35を案内しました。さらに10月23日付の追加案内では、特定のPHP設定とアプリケーション側の条件が重なる場合に備え、次の通常バグ修正版が公開されるまでsession.upload_progress.enabledを無効にするよう推奨しています。条件や適用方法は環境により異なるため、実施可否はホスティング事業者や保守担当に確認してください。CISAは10月23日改訂の注意喚起で、同注意喚起の公開時点では実際の悪用を観測していないと説明しています。これは公開時点の状況であり、その後の状況を示すものではありません。PHP 8.2系列は2026年12月31日にサポート終了予定です。8.2を利用している場合は、修正版の適用だけでなく、今後のサポート方針も確認してください。（情報確認日：2026年10月26日）

ホスティング事業者や保守担当には、次の点をまとめて確認するとスムーズです。

• 対象サイトが利用しているPHPのバージョンと実行環境

• 該当する修正版、またはベンダーが提供するバックポート済みパッケージが適用済みか

• 更新が未完了の場合の対応予定と、更新までに必要な暫定措置

• 更新後のサイト表示、フォーム、決済などの動作確認を誰が行うか

PHPのバージョン番号だけで修正の有無を判断できない環境もあります。ホスティング事業者が独自に修正をバックポートしている場合があるため、バージョンの数字だけでなく、提供元の案内と適用状況を確認してください。PHPの環境や影響範囲が分からない場合は、管理画面を推測で変更せず、ホストや保守担当へ相談します。

PHPの更新対応とCMS移行を別々に考える

緊急の更新対応は、現在稼働している環境のリスクに対処するものです。一方、WordPressからFramerへの移行は、ページや記事、フォーム、URL、計測、運用体制を新しい環境に合わせて組み直す中長期のプロジェクトです。移行を決めても、切り替えが完了するまでは既存のWordPress環境が稼働します。したがって、移行を検討している間も、現行環境に必要なセキュリティ対応を止めてはいけません。

PHPの更新が必要な場合は、サイトの保守担当と相談し、更新・バックアップ・動作確認を先に進めます。その後、保守負荷や更新の遅れが継続的な課題なのか、現在の体制で解決できるのかを確認し、移行の必要性を判断しましょう。今回の脆弱性情報は運用を見直すきっかけにはなりますが、WordPressサイトがすべて侵害されたことや、全サイトを直ちに移行すべきことを示すものではありません。

WordPressからFramerへ移行すると、何を引き継ぐ？

移せるのは、まず「データとして取り出せるコンテンツ」です。WordPress公式のエクスポート機能は、投稿、固定ページ、カスタム投稿タイプ、コメント、カスタムフィールド、カテゴリー、タグ、カスタムタクソノミー、ユーザーなどをWXR形式のXMLファイルに書き出します。ただし、エクスポートファイルを作っただけで、サイトの見た目や機能までFramerに再現されるわけではありません。データの変換、CMS項目の設計、ページの再構築、画像やフォームの確認は別工程です。

移行前に、資産ごとに「そのまま移す」「Framer向けに整形する」「作り直す」「移行しない」を決めておきましょう。WordPress公式のエクスポート説明とFramer公式のWordPress移行ガイドを参照し、実際に選ぶ方法や対応範囲は公開直前にも再確認してください。

投稿・固定ページ・カスタム投稿・画像

記事や固定ページは、公開・非公開の状態、公開日、URL（スラッグ）、カテゴリー、タグ、著者、抜粋、メタタイトル・説明などを一覧にしてから移行します。カスタム投稿タイプや独自フィールドがある場合は、Framer CMSのコレクションとフィールドにどう対応させるかを設計します。たとえば、投稿を「記事」コレクション、著者をテキストまたは著者コレクション、カテゴリーを選択肢や別コレクションとして表現する方法があります。

WordPressのWXR/XMLをFramerへそのまま読み込めるとは限りません。公式ガイドでは、XMLからCSVへ変換し、Framer CMSのフィールドに合わせて読み込む方法などが紹介されています。少量なら手作業で整える方が確実な場合もあります。画像は元データの場所、使用ページ、代替テキスト、権利関係を確認し、移行後に表示とリンクを一件ずつ抜き取り確認してください。

テーマ・プラグイン・独自機能

テーマやページビルダーで作られたデザイン、プラグインが担っていた機能、独自コードは、コンテンツのエクスポートとは別に扱います。現在使っているプラグインを一つずつ並べ、「機能」「利用ページ」「代替手段」「移行後の担当者」を記録すると、見落としを減らせます。Framerの標準機能で足りるもの、外部サービスを引き続き使うもの、不要になったものを分け、必要な機能は移行先で再設計します。

Framer公式のHTML to Framer拡張機能は、ページの視覚要素を複製する補助として案内されていますが、CMSデータやメタ情報、動的機能まで移す仕組みではありません。見た目のコピーをデータ移行と同じものとして扱わず、ページの再構築とCMSの引き継ぎを別々に計画しましょう。

フォーム・顧客データ・外部連携

問い合わせフォームは、見た目だけでなく、送信先、通知先、保存先、CRM連携、必須項目、エラー表示、完了画面まで確認します。これまでに受け取った回答データは、新しいフォームを作るだけでは移りません。必要な記録の保管方法や移行範囲を担当者と決め、個人情報を含むデータはアクセス権限と取り扱いルールも確認してください。

あわせて、GA4やGTM、広告計測、Cookie同意、チャット、予約、メール配信など、ページ以外に埋め込まれている連携を棚卸しします。Framer公式ガイドではフォームや外部連携の設定方法が案内されていますが、実際の接続先やプラン条件は変わる可能性があります。自社の要件と公式ヘルプを照らし合わせ、テスト送信や計測確認を移行計画に含めましょう。

WordPress継続・部分移行・全面移行、どれを選ぶ？

判断の基準は「どちらのツールが優れているか」ではなく、サイトの役割と運用体制に合っているかです。記事や複雑なCMSを育てる領域はWordPressに残し、改善頻度の高いサービスページだけをFramerへ移す方法もあります。すべてを一度に変える前提にせず、移行後の担当者や必要機能も含めて比べましょう。

WordPressを継続するケース

記事数が多く、カテゴリーやカスタム投稿、既存連携を活用している場合や、現在の保守体制が必要な更新を安定して行えている場合は、WordPressを継続する選択が自然です。今回のPHP更新のように対応すべき事項が見つかったとき、担当者と手順を決めて確実に進められるかも大事な判断材料です。移行コストをかけるより、更新・バックアップ・障害時の連絡先を整理した方が課題を解決できることもあります。

サービス・採用・LPだけ部分移行するケース

ブログやニュースはWordPressに残し、サービスサイト、採用ページ、キャンペーンLPなど、更新や改善の速度を上げたい部分をFramerへ移す方法です。コンテンツの役割や更新担当が分かれている会社では、サイト全体を同じCMSに統一するより運用しやすい場合があります。

部分移行では、同一ドメインでのページ配信やURLの扱い、フォーム・計測の境界、更新担当の分担を先に確認します。Framer公式にはページ単位で段階移行する方法も掲載されています。利用条件や構成はプロジェクトごとに異なるため、Framerの段階移行ガイドを確認し、実装前に現行のプラン・設定を照合してください。

全面移行を検討するケース

サイト全体の情報設計や更新フローを見直したい、複数の仕組みの保守責任が分散している、ページの作り直しも含めて運用を再設計したい場合は、全面移行を検討できます。ただし、全ページの移行が必要とは限りません。アクセスや問い合わせへの貢献、被リンク、更新頻度、機能の必要性を見て、残すページ・統合するページ・廃止するページを決めます。

移行後に必要なCMS機能や外部連携がFramerの仕様・プランで実現できるか、既存のデータをどう扱うかも事前確認が必要です。条件を満たせない機能がある場合は、WordPressを一部に残す、別サービスを組み合わせるなど、全面移行以外の選択肢へ戻ることも含めて検討してください。

WordPressからFramerへの移行前チェックリスト

移行前に、サイトを構成するページ・データ・機能・担当者を一覧にします。最低限、次の確認項目と完了条件を関係者で共有してください。

URL・検索流入・被リンク

移行するページと新しいURLを一対一で結び、URLを変える場合は旧URLから適切な新URLへのリダイレクトを設定します。対象は、現在アクセスがあるページだけでなく、被リンクや検索結果に残っているページも含めて確認します。Framer公式のリダイレクト設定ガイドでは、旧URLから新URLへの転送やワイルドカードの設定方法が説明されています。リダイレクトは移行時の重要な作業ですが、検索順位を維持する保証ではありません。

CMS・コンテンツ・画像

WordPressの投稿、固定ページ、カスタム投稿、カテゴリー、タグ、著者、公開状態、画像を一覧にし、移行・統合・廃止を決めます。WXR/XMLの内容とFramer CMSのフィールドを対応付け、タイトル、本文、スラッグ、画像、日付、メタ情報が正しく取り込まれるかをテストデータで確認してください。すべての記事を機械的に移すのではなく、内容の更新や統合が必要なページをこのタイミングで見直します。

フォーム・連携・計測

問い合わせ、資料請求、採用応募など、用途ごとに送信先・通知先・保存先を記録します。移行先でテスト送信し、入力エラー、完了表示、通知メール、CRM登録まで一連の動作を確認します。GA4や広告タグは、ページ表示だけでなく、フォーム送信など重要なイベントが計測されることも確認します。Cookie同意を使っている場合は、同意前後のタグ動作も担当者とテストしてください。

契約・権限・運用体制

ドメインやDNSを変更できる人、WordPressとFramerの管理者、公開承認者、更新担当者を明確にします。ホスティング契約、バックアップ、SSL、メール関連のDNSレコード、プラグインライセンスも確認対象です。公開後に誰が更新・保守・問い合わせ対応を担うのかを決め、旧環境の停止時期は、切替後の検証が終わってから判断できる状態にします。

移行はどんな順番で進める？公開後までの7ステップ

移行は、データのコピーだけでなく、設計・検証・公開後の確認まで含めて進めます。ここでは社内担当者が実際に手を動かせる粒度で、作業内容と確認方法を順に示します。Framerの画面名やプランで使える機能、各ツールの仕様は変更されることがあるため、作業時点で公式情報を確認してください。

ステップ1｜現状を棚卸しし、守るページを決める

最初に、移行の判断材料と作業対象を数字で把握します。

• PHPと保守状況：ホスティング事業者や保守担当に、PHPのバージョンと修正適用状況を確認します。

  
  

• 全URLの一覧：/wp-sitemap.xml（WordPress標準）または/sitemap_index.xml（Yoast・Rank Math）を起点に、クロールツールでサイト全体をクロールし、URL、ステータスコード、タイトル、メタディスクリプション、H1、canonical、内部リンクを書き出します。サイトマップに載っていない古いページも拾うため、クロールは省略しないでください。
  
  

• 守るページの特定：Search Consoleの「検索パフォーマンス → ページ」を過去12か月で書き出し、リンクレポートで被リンクの多いページも確認します。ここで上位に出るページが、リダイレクトを最優先で用意する対象です。
  
  

• プラグインと既存リダイレクト：有効なプラグインと役割を一覧にし、リダイレクト系プラグインや.htaccessにある既存ルールも書き出します。旧ルールも移行先へ引き継ぐ必要があります。
  
  

• 基準値の記録：移行前の流入、検索順位、表示速度を記録しておくと、公開後に比較できます。

ステップ2｜URL対応表（リダイレクトマップ）を作る

旧URL／新URL／区分（維持・転送・廃止）／月間流入／被リンク数／優先度の列でスプレッドシートを作り、ステップ1で洗い出した全URLに1行ずつ割り当てます。

• URLはできるだけ変えないのが基本です。/blog/記事スラッグはFramer側でも同じパスで再現できます。
  
  

• 日付入りURL（/2026/03/15/記事名）や/?p=1234のような形式は、移行に合わせて整理する候補です。
  
  

• 転送先は内容が最も近いページにします。まとめてトップページへ送るのは避けてください。
  
  

• 転送は1回で完結させ、リダイレクトの連鎖を作らないようにします。
  
  

• WordPress固有のURLは個別に方針を決めます。カテゴリー・タグ・著者・ページ送りのアーカイブ、/feed（FramerはRSSを自動生成しないため、外部サービスを用意するか一覧ページへ転送）、/wp-adminや/wp-login.php（404のままで問題ありません）。
  
  

• 末尾スラッシュの有無もURLの違いとして扱われます。主要URLは両方の形で挙動を確認してください。

ステップ3｜バックアップを取り、データを書き出す

1. データベースとファイルを含む完全なバックアップを取得します。

2. WordPress管理画面のツール → エクスポートで、投稿・固定ページ・カスタム投稿を選び、WXR形式のXMLを書き出します。カスタム投稿や独自フィールドが多い場合は、書き出し用プラグインの方が扱いやすいこともあります。

3. 画像は別途取得します。エクスポートファイルは画像そのものを含まず、リンクだけを持ちます。wp-content/uploadsを旧サーバーからダウンロードしておきます。

4. SEOプラグインで設定したタイトルや説明はエクスポートに含まれない場合があるため、ステップ1のクロール結果から転記します。

ステップ4｜XMLをCSVへ変換し、Framerの要件に合わせる

Framer CMSが読み込むのはCSVです。XMLを投稿タイプごとに1ファイルへ変換し、1行＝1記事、1列＝1フィールドの形に整えます。満たすべき要件は次のとおりです。

画像は元のURLから取得されるため、インポートが終わるまで旧サイトを公開状態で維持してください。あわせて、本文列のショートコードを整理します。ギャラリーや問い合わせフォーム、ページビルダーのショートコードは、そのままだとFramer上で文字列として表示されます。角かっこ（[）で検索し、種類ごとに「HTMLに置き換える」「Framerの要素で作り直す」「削除する」を決めてください。移行しない下書きや不要な記事は、この段階で行ごと削除しておくと後工程が軽くなります。

ステップ5｜Framerのコレクションを作り、CSVを読み込む

1. CMSでコレクションを作り、CSVの列名と同じ名前・対応する型でフィールドを用意します。名前が一致しない列は取り込まれません。
   
   
   

   

   
   
   

2. 参照関係がある場合は、参照先のコレクション（著者・カテゴリーなど）を先に作成・インポートします。

3. CMSのツールバーのImportからCSVを選び、列とフィールドの対応を確認して取り込みます。
   
   
   

   

   
   
   

4. まず5〜10件程度の見本で試し、装飾、画像、日付、選択肢、参照、スラッグ、一覧ページと詳細ページの表示を確認してから全件を読み込みます。

5. 同じスラッグで再インポートすると既存項目が更新されるため、修正して読み込み直しても重複しません。画像の代替テキストは一括処理で欠けやすいので、取り込み後に抜き取り確認してください。

6. 記事数が多い場合は、WordPressの投稿を直接取り込めるマーケットプレイスのプラグインも選択肢です。固定ページは対象外のものが多いため、別途作り直します。

ステップ6｜ページ・フォーム・計測を作り、リダイレクトを登録する

固定ページはFramerで作り直します。既存デザインを下敷きにする場合は、HTML to Framer拡張機能でセクションを貼り付ける方法もありますが、CMSデータや動的機能は移りません。あわせて次を接続します。

• フォーム：入力項目、送信先、通知メール、CRM連携、完了画面、迷惑送信対策

• 計測：GA4、GTM、広告タグ、フォーム送信などの重要イベント、Cookie同意

• メタ情報：タイトル、説明、OGP、canonical、構造化データ、サイトマップ、robots.txt（ステージング用のDisallow: /が残っていないか確認）

リダイレクトはSite Settings → Hosting → Redirectsで登録します。*でパスをまとめて一致させ、:1で一致部分を新URLへ引き継げます（例：/blog/* → /articles/:1、/category/* → /blog）。ルールは上から順に評価されるため、個別ルールをワイルドカードより上に置きます。件数が多い場合は、from,toの2列のCSVを一括登録できるプラグインが用意されています。別ドメインへ移る場合のドメイン全体の転送は、旧ドメイン側のホスティング事業者で設定します。リダイレクトの利用可否と上限はプランによって異なるため、公開前に自社プランを確認してください。

ステップ7｜公開前テスト・切り替え・公開後の監視

公開前に、PCとスマートフォンの表示、全CMS項目、内部リンク、フォーム送信と通知、計測イベント、主要URLのリダイレクトを確認します。ステージングは検索エンジンに登録されない設定にし、不具合時の切り戻し手順と担当者も先に決めておきます。

• 切替48時間前：DNSのTTLを短く（300秒など）しておくと切り戻しが速くなります。Search Consoleの所有権確認をWordPressのプラグインやHTMLファイルで行っている場合は切替で無効になるため、先にDNSによるドメイン所有権確認を追加します。
  
  

• 切替当日：リダイレクトを反映して公開し、Framerが指定するDNSレコードだけを変更します（メール関連のレコードは触りません）。反映には最大48時間かかることがあるため、アクセスの少ない時間帯に実施します。公開後は主要ページと旧URL、全フォームの送信をテストし、サイトマップをSearch Consoleへ送信します。
  
  

• 1週目：Search Consoleのエラーと404を毎日確認し、漏れたリダイレクトをすぐ追加します。計測とコンバージョンの記録も確認します。
  
  

• 2〜4週目：流入、順位、問い合わせ数を移行前の基準値と比べます。再クロール中の変動は起こり得ますが、特定ページの継続的な下落はリダイレクト漏れや内容変更が原因のことが多いです。
  
  

• その後：リダイレクトは1年以上維持します（Googleの推奨）。転送元のURLはサイトマップに含めません。旧環境とバックアップは公開後の検証が完了するまで残し、停止時期は安定を確認してから決めます。

移行費用・期間は何で変わる？

移行費用や期間は、サイトの規模だけでなく、データや機能をどこまで作り直すかで変わります。主な見積もり要因は次のとおりです。

• ページ数、CMS件数、カスタム投稿、画像やメタ情報の整理量

• 現行デザインを再現するか、情報設計・デザインから見直すか

• フォーム、CRM、予約、会員機能、計測タグなどの連携数と複雑さ

• URL変更の数、リダイレクト設計、SEO資産の棚卸しや公開後の確認範囲

• ステージング、テスト、切替当日の支援、公開後の保守をどこまで依頼するか

Framerの利用料と、設計・制作・データ整備などの支援費用は分けて確認しましょう。Coziesの一般的な制作支援プランが、そのまま移行案件の確定費用になるわけではありません。対象ページ数、CMSの量、必要機能、希望する切替時期を整理したうえで見積もりを依頼すると、比較しやすくなります。具体的な金額や期間は、要件を確認せずに一律で示せません。