WordPressからCloudflareへ移す手順
- 今のサイトで動いているものを一覧にする。
- 記事・画像・復旧用データを取り出す。
- Cloudflareで配信する新サイトを作る。
- フォームとメールの流れを作り直す。
- 旧URLと検索向けの設定を引き継ぐ。
- 旧サイトと新サイトを並べて試す。
- 公開先を切り替え、実際に届くページを確認する。
- 公開後を見守り、旧環境を整理する。
この記事で扱うのは、WordPressで公開していたサイトを、Cloudflare Workersからページを配信する形へ移す方法です。Workersは、Cloudflare上でページを届けたり、フォームの送信を処理したりできる仕組みです。どのサイトも同じ構成にできるわけではありません。会員ログインや予約などがあれば、その機能をどこで動かすかも決めます。
第1回ではPHP2Shellへの対策として、PHPの更新を先に行い、公開ページのPHP依存を減らす考え方を整理しました。今回は、国内レンタルサーバーのWordPressからCloudflareへ移るときに、何をどの順番で確認するかを説明します。
図は8つの手順を「棚卸し」「並行確認」「切替後」の3段階にまとめたものです。スマートフォンで文字が小さいときは、図を大きく開くから確認できます。
各手順でやること
1. 今のサイトで動いているものを一覧にする
公開中の記事・固定ページ、画像、ダウンロード資料、問い合わせフォーム、英語ページなどを書き出します。会員ログインや予約、決済を使っているなら、それも加えます。管理画面で見える記事だけを数えると、サイトの外からリンクされている古いURLや、送信後に届くメールを見落としがちです。
まず「今の場所」「移行後の場所」「どう確かめるか」を一行ずつ記録します。フォームなら、入力画面だけでなく、受付記録・担当者への通知・自動返信までが一組です。この一覧が、新サイトで作るものと残すものを決める土台になります。
2. 記事・画像・復旧用データを取り出す
WordPressの管理画面で「ツール → エクスポート」を開き、必要な投稿や固定ページをXMLファイルに書き出します。この形式をWXRと呼びます。WordPress公式の説明によると、記事や固定ページ、分類、カスタム項目などを含みます。
画像の実ファイル、テーマ独自の表示、フォームの設定は別に確かめます。画像はサーバー上の保存先やバックアップから取得し、記事が参照する画像と突き合わせます。元サイトのファイルとデータベースも、切替に失敗したときに内容を調べられるよう保全します。WXRを取得しただけで「サイト全体のバックアップができた」とは判断しません。
3. Cloudflareで配信する新サイトを作る
記事と画像を、新サイトのページとして組み立てます。Workers Static Assetsを使う構成では、HTML・CSS・画像などのファイルをCloudflareから配信できます。作ったファイルを確認用のURLから開き、見出し、リンク、画像の表示先まで確かめます。
公開ページをファイルとして配信しても、問い合わせやログインは送信内容を受け取る処理が要ります。WordPressで使っていたプラグインを列挙し、新しい場所で同じ仕事ができるか確認します。置き換え先がない機能が残るなら、その機能の設計を先に決めます。
4. フォームとメールの流れを作り直す
新しいフォームでは「送信できた画面が出る」だけで合格にしません。入力を受け取る、必要な記録を残す、担当者に知らせる、自動返信を送る。この流れを一つずつ試します。迷惑送信対策を使う場合も、画面に表示して終わりではありません。たとえばCloudflare Turnstileは、受け付け側で送信された情報を検証する必要があります。
Webサイトの移行と、普段使うメールの受信先は別に確認します。ドメインのDNS設定を動かす前に、誰がメールを受け取り、どのサービスから通知を送るのかを控えます。設定名が分からなければ、メールの管理担当者や提供元に確認できるよう、現状を記録しておきます。
5. 旧URLと検索向けの設定を引き継ぐ
「旧URL」「新URL」「同じ場所で公開・転送・終了のどれか」「確認結果」の四列を作ります。同じURLを使えるなら、まずその場所で本文と画像が開くか確認します。URLを変える場合は、旧URLから対応する新しいページへ恒久的に転送します。関係のない旧記事をすべてトップページへ送ると、探していた内容にたどり着けません。Googleの移行手順も、ページごとの対応を求めています。
検索結果に出るページのタイトルと説明文、代表URLを示すcanonical、検索対象にするかを示すrobots、サイトマップも比べます。名前を覚えるより、「旧ページと新ページで、検索エンジンに何を伝えているか」を一行ずつ照合する方が確実です。
6. 旧サイトと新サイトを並べて試す
公開先を変える前に、新サイトの確認用URLでトップ、記事、画像、フォーム、英語ページ、存在しないURLまで開きます。スマートフォンでも、文字やボタンが隠れていないか見ます。問い合わせは実際に送信し、完了画面・受付・通知・自動返信を別々に確かめます。
確認用ページは、本番の検索結果に出さない設定にします。本番へ切り替えるときは、その設定が本番に残っていないかも見直します。URLを変えない移行でも、Googleは新サイトの事前確認と切替後の監視を勧めています。
7. 公開先を切り替え、実際に届くページを確認する
切替直前に旧サイトの更新を止め、最後の変更を新サイトへ反映します。公開する版と切替時刻を記録してから、Cloudflareの「Domains & Routes」で新しいWorkerを公開ドメインに割り当て、Web用のDNSレコードも確認します。既存サーバーの前にWorkerを置くRouteと、Workerを直接の配信元にするCustom Domainでは前提が違います。どちらを使うかは新サイトの構成に合わせて決めます。
DNSの管理先をCloudflareへ移しただけでは、ページの配信先は決まりません。Web用レコードがDNS-onlyなら、訪問者は元のサーバーへ直接つながります。ProxiedのレコードはCloudflareを通ります。Cloudflareの説明に照らし、切替後は管理画面の設定だけでなく、実際に表示されるページ、古いURLの転送、問い合わせの到達を確かめます。結果が分からないまま公開操作を重ねず、まず配信中の状態を読み取ります。
8. 公開後を見守り、旧環境を整理する
切替後も、古いURLからの訪問、404、画像の欠落、フォームの受付、メールの受信を確認します。検索順位が必ず維持されるとは言えません。検索の状態はSearch Consoleなどで継続して見ます。
旧WordPressを片付ける前に、バックアップと残る依存先を確かめます。メール、別ドメイン、保存すべきデータが旧契約に残っていれば、その扱いを決めてから整理します。サイトの切替とサーバー契約の終了は別の判断です。
the N Creativeで重視したこと
国内レンタルサーバーのWordPressからCloudflareへ移る際、サイトに必要なページと機能を整理し、表示と問い合わせの動作を確かめました。ページが表示されたことだけで移行完了とはしませんでした。
私たちの対策は、すべてのサイトにそのまま当てはまる手順ではありません。記事を自分で更新する方法、予約や会員機能の有無、メールの受け方を確かめたうえで、必要な構成を決めることが大切です。
よくある質問（FAQ）
Q. WordPressのエクスポートファイルがあれば移行できますか？
A. 記事などのデータを取り出す出発点にはなります。画像の実ファイル、フォーム、テーマ独自の表示、メール、古いURLは別に確認してください。
Q. DNSをCloudflareへ移せば、PHPサーバーは不要ですか？
A. DNSの管理先を変えただけでは決まりません。Web用レコードがDNS-onlyなら、旧サーバーからページが届く場合があります。新サイトが実際に配信されていることと、旧環境への依存がないことを分けて確かめます。
Q. 会員ページや予約機能があるサイトも、同じ手順で移せますか？
A. 棚卸しと並行確認は共通です。ただし、会員情報や予約枠を扱う処理は別の移行先が必要です。公開ページを静的なファイルにするだけでは置き換えられません。
Q. 旧WordPressはいつ整理できますか？
A. 新サイトの表示、画像、古いURL、フォーム、メールを実際に確認し、必要なバックアップと旧環境に残る仕事を把握してからです。サーバー契約に別の用途が残る場合は、その扱いも別に決めます。
移行の相談は、今あるサイトの棚卸しから
最初の相談で全設定を決める必要はありません。今のURL、使っているフォーム、メールの受け方、残したい記事と画像が分かれば、確認の順番を整理できます。the N CreativeのWeb制作では、サイトの表示から問い合わせまでを一緒に見て、移行の範囲を考えています。
