# 【実録】WordPressサイトを月額0円で配信できるようにした話｜Cloudflare移行の全データ公開
このサイト「のりかえサーバー」自体が、今回の移行の実物です。2026年7月15日にWordPressの構築を始め、7月18日に本番をCloudflare Workersへ切り替えました。トップページで紹介している「表示速度が主要な部分まで表示されるのにかかる時間（LCP）が3.53秒→2.46秒」「サーバーが応答するまでの時間が83ms→41ms」「配信費用が月額1,320円相当→0円」という数字は、すべてこのサイトで実際に計測した値です。この記事では、その計測条件とデータの全体を、良い結果も悪い結果も省略せずに公開します。
何をしたか：移行の全体像
何をしたか：移行の全体像で確認すべきポイントを整理します。
今回の移行は、WordPressをまるごと配信し続ける構成から、「WordPressは記事を書く道具として残し、公開時だけ静的HTMLへ書き出してエッジから配信する」構成への切り替えです。
| 項目 | 移行前 | 移行後 |
|---|---|---|
| サーバー | Xserverスタンダード | Xserverスタンダード（生成専用） |
| CMS/生成 | WordPress + SWELL（配信も兼務） | WordPress + SWELL（記事作成・生成のみ） |
| 配信 | Xserver（nginx）から直接配信 | Simply Staticで書き出した静的HTMLをCloudflare Workers Static Assetsから配信 |
| フォーム | Contact Form 7（PHPでメール送信） | SSGform + Turnstile（静的HTMLからの送信に対応） |
| 配信基盤の月額 | 1,320円相当※ | 0円（Cloudflare Workers無料枠） |
※Xserverスタンダードの最短3ヶ月契約における通常料金を月額換算した金額です。実際に選択した契約期間・初回支払額とは異なるため、実支払額ではなく比較基準として記載しています。
ここで誤解しやすい点をひとつ補足します。「月額0円」になったのは、あくまで読者がアクセスする配信部分の費用です。WordPress自体は記事を書く場所として今もXserver上に残っており（管理用の別経路を用意しています）、Xserverを解約したわけではありません。
このサイトのようにひんぱんに記事を追加するメディアであれば、いつでも書ける管理画面を維持する意味があります。一方、会社案内や店舗紹介のような「更新が月に数回程度」のサイトであれば話は変わります。更新のたびだけ静的ファイルを作り直せばよいので、常時稼働のWordPressサーバーを持ち続ける理由がなくなり、配信基盤だけでなくサーバー代そのものをずっと0円にできます。実際、私たちが受託でこの移行をお手伝いする際は、更新頻度の低いサイトを主な対象にしており、そちらは「サーバー代がずっと0円」を文字どおり実現できます。
作業は3日間に分かれています。7月15日に固定ページ・記事下書きの作成とディレクトリ整備、7月18日にサーバー契約からWordPress構築・コンテンツ投入・before計測・静的化・本番切替・after計測まで、7月19日に検索機能の非表示化などの運用整備を行いました。
なぜこの構成にしたか
WordPressを完全に手放すのではなく、生成専用として残した理由は3つあります。
1つ目は速度です。WordPressはリクエストのたびにPHPを実行してページを組み立てますが、あらかじめ静的HTMLへ書き出しておけば、Cloudflareのエッジからそのまま返すだけで済みます。実測結果は後述しますが、サーバー応答の短縮がLCP改善の一因になっています。
2つ目は費用です。静的ファイルの配信だけであれば、Cloudflare Workers Static Assetsの無料枠に収まり、配信基盤の月額を0円にできます。
3つ目は保守のしやすさです。SWELLのブロックエディタで記事を書くという普段の作業は変えず、公開のタイミングだけ書き出し・後処理・再デプロイという手順を挟む形にしたことで、執筆側の負担を増やさずに配信だけを軽くできました。
計測条件
計測条件で確認すべきポイントを整理します。
数値だけを見せて「速くなりました」と言うのは簡単ですが、それでは再現性がありません。ここでは、トップページで紹介している数字がどの条件で測られたものかを、省略せずに公開します。
| 項目 | 内容 |
|---|---|
| before計測日時 | 2026-07-18 11:52〜11:54 JST |
| after計測日時 | 2026-07-18 23:28〜23:30 JST |
| 計測ツール | Lighthouse CLI 12.8.2 |
| 実行環境 | Google Chrome 150.0.7871.128 |
| Lighthouse計測回数 | mobile・desktop各3回実行し、中央値を採用 |
| curl TTFB計測回数 | 5回実行し、中央値を採用 |
この計測には、あらかじめ開示しておくべき制約が3つあります。
- PageSpeed Insights APIは、before・after双方の計測時にHTTP 429（`RESOURCE_EXHAUSTED`）で利用できませんでした。そのため、同一のローカル環境で動かしたLighthouse CLIに統一して比較しています。
- 移行作業の過程で、ダミー画像を自前のヒーロー画像・記事アイキャッチへ差し替えています。つまりこの記事のbefore/afterは、配信基盤だけを入れ替えたA/B試験ではなく、「サイト移行プロジェクト全体」のbefore/afterです。
- Mobileの計測では1回だけ他の2回より遅い結果が出ましたが、あらかじめ決めていたとおり中央値をそのまま採用しました。外れ値を恣意的に除外することはしていません。
実測結果：before/after全データ
実測結果：before/after全データで確認すべきポイントを整理します。
ここからは、報告書の数値をそのまま並べます。表の指標が何を表すかは先に簡単に説明しておきます。
- Performance：Lighthouseが総合的な表示速度を100点満点で採点したスコア
- LCP：ページの主要な画像やテキストが表示されるまでの時間
- Server response：サーバーがリクエストを受けてから最初に応答を返すまでの時間
- curl TTFB / Total：ブラウザを介さずコマンドで直接計測した応答時間（TTFB＝最初の1バイトが届くまで、Total＝全体）
| 指標 | before | after | 変化 |
|---|---|---|---|
| Mobile Performance | 88 | 96 | +8点 |
| Mobile LCP | 3.534秒 | 2.460秒 | -1.074秒（30.4%短縮） |
| Mobile Server response | 83ms | 41ms | -42ms（50.1%短縮） |
| Desktop Performance | 97 | 99 | +2点 |
| Desktop LCP | 1.258秒 | 0.859秒 | -0.398秒（31.7%短縮） |
| Desktop Server response | 54ms | 51ms | -2ms（4.0%短縮） |
| curl TTFB | 0.111秒 | 0.088秒 | -0.023秒（20.6%短縮） |
| curl Total | 0.144秒 | 0.112秒 | -0.032秒（22.2%短縮） |
| 配信基盤の月額 | Xserverスタンダード 1,320円相当※ | Cloudflare Workers 無料枠 0円 | -1,320円／月相当 |
※XServerの最短3ヶ月契約における通常料金の月額換算です。実際に選択した契約期間・初回支払額は未確認のため、実支払額ではなく比較基準として記載しています。
速くなったところ
Performance・LCP・TTFBといった主要な指標は、mobile・desktopともにすべて改善しました。特にMobile LCPは30.4%、Mobile Server responseは50.1%短縮しています。静的HTMLをCloudflareのエッジから配信する構成に変わり、サーバーが応答するまでの時間が大きく縮まったことが、LCP改善の主な理由と考えられます。
遅くなったところも正直に書く
良い数字だけを並べるのはフェアではないので、悪くなった項目もそのまま出します。
| 指標 | before | after | 判定 |
|---|---|---|---|
| Mobile FCP（最初の要素が表示されるまでの時間） | 1.145秒 | 1.921秒 | 0.776秒悪化 |
| Mobile Speed Index（画面が視覚的に埋まっていく速さ） | 1.407秒 | 1.957秒 | 0.550秒悪化 |
| Desktop FCP | 0.373秒 | 0.537秒 | 0.164秒悪化 |
| Desktop Speed Index | 0.531秒 | 0.537秒 | ほぼ横ばい |
| Mobile／Desktop TBT（操作を受け付けるまでの待ち時間） | 0ms／0ms | 0ms／0ms | 変化なし |
| Mobile／Desktop CLS（表示中のズレの少なさ） | 0／0 | 0／0 | 変化なし |
特にMobile FCPは0.776秒悪化しています。前述のとおり、移行作業中にダミー画像を自前のヒーロー画像・アイキャッチへ差し替えたため、描画される要素や順序がbeforeと完全に同一ではありません。この悪化を配信基盤の切り替えだけが原因と断定することはできず、ページ内容の変化も影響していると考えられます。
なお、配信基盤の月額「1,320円相当」は、Xserverスタンダードの最短3ヶ月契約における通常料金を月額換算した金額であり、実際の支払額ではありません。また、旧契約期間分の返金はないため、実際に配信費用が0円になるのは旧契約が終了してからです。
同じ記事だけで配信基盤の差を比べてみた
同じ記事だけで配信基盤の差を比べてみたで確認すべきポイントを整理します。
ここまでのbefore/afterは、コンテンツも配信基盤も変わった「時系列比較」でした。その後、WordPress本体へ直接アクセスできるようになったため、「同じ記事・同じ時刻」で配信基盤だけを比較する参考データも取ってみました。メインの結論には含めず、あくまで参考情報として載せます。
PSI Web版（pagespeed.web.dev）mobile・ラボデータ
| 指標 | norikae-server.com（Cloudflare） | WordPress直接 |
|---|---|---|
| Performance | 100 | 100 |
| FCP | 1.2秒 | 1.5秒 |
| LCP | 0.6秒 | 0.5秒 |
| TBT | 20ms | 0ms |
| CLS | 0 | 0 |
| Speed Index | 1.8秒 | 4.5秒 |
参考：Lighthouse CLI（日本国内から実行、simulate throttling）
| 指標 | Cloudflare | WordPress直接 |
|---|---|---|
| Mobile Performance | 97 | 99 |
| Mobile LCP | 2.264秒 | 2.106秒 |
| Mobile FCP | 1.911秒 | 1.095秒 |
| Desktop Performance | 100 | 100 |
| Desktop LCP | 0.812秒 | 0.531秒 |
| curl TTFB（5回中央値） | 0.088秒 | 0.114秒 |
WordPressが勝つ項目もある
同一コンテンツで比較すると、Performance・FCP・LCP・TBTはいずれも僅差で、むしろWordPress側が良い項目もあります。明確にCloudflareが優位だったのは、PSI Web版のSpeed Index（1.8秒 対 4.5秒）と、静的アセットのキャッシュ効率くらいのものでした。配信基盤を変えれば何でも速くなるわけではない、という正直な結果です。
計測拠点で結果が逆転する
興味深いのは、Lighthouse CLI（日本国内から実行）とPSI Web版（Googleのテストサーバー、多くは海外リージョン）とで、FCPの優劣が逆転していることです。WordPress直接アクセスはXserverの単一オリジン（日本国内）からしか配信されないのに対し、Cloudflareはグローバルにエッジ配信されます。この構造から、計測拠点が国内から遠いほどWordPress側が不利になり、Cloudflareのエッジ配信が有利になると考えられます。実際のユーザーは国内外に散らばっているため、実運用の体感はPSI Web版の結果に近いと推定しています。
なお、両ホストとも実ユーザーデータ（CrUX）は「No Data」（アクセス数不足）で、フィールドデータでの検証はまだできていません。
向いているサイト・向いていないサイト
向いているサイト・向いていないサイトで確認すべきポイントを整理します。
ここまでの結果を踏まえると、この移行が向くかどうかはサイトの性質によって分かれます。
向いているのは、更新頻度が低〜中程度の情報サイトで、表示速度と配信費用を下げたいと考えている方です。お問い合わせフォームのように単純な機能であれば、SSGformのような静的サイト向けの外部サービスに置き換えられます。前述のとおり、このタイプのサイトなら「サーバー代がずっと0円」を文字どおり実現できます。自分で作業する時間が取れない場合は、お問い合わせ窓口で、この記事と同じ移行にかかる費用と作業範囲を確認できます。
向いていないのは、会員制サイトやECサイト、コメント欄がある記事、サイト内検索が必須の構成、リアルタイム性が求められるページです。今回の移行でも、サイト内検索機能は静的化後に動かなくなったため、見た目だけを残す対応ではなく機能自体を削除する判断をしています（詳しくは次の章で触れます）。
自分のサイトが向いているかどうかをもう少し詳しく判断したい方は、WordPress静的化に向くサイト・向かないサイトの見分け方に判断基準を整理しています。
詰まった点ワースト5
移行が自社サイトに合うか、費用と作業範囲を確認したい場合は、静的化移行サービスの費用と範囲を相談することができます。
詰まった点ワースト5で確認すべきポイントを整理します。
実際の作業で詰まった点のうち、同じ構成に取り組む方の再現性が高い5件を紹介します。
1. Simply Staticの書き出しにsitemap.xmlが入らない
現象：Simply StaticでZIP書き出しを行っても、公開中の`sitemap.xml`本体とその中の子サイトマップが含まれていませんでした。
原因：Simply Staticの標準クロールは、投稿・固定ページなどのコンテンツURLが対象で、`sitemap.xml`自体は対象に含まれません。
対処：Simply Staticの設定画面「General（設定）→ Include → ADDITIONAL URLS」に、`sitemap.xml`本体と、そこに掲載された子サイトマップのURLを1行ずつ追加しました。XMLサイトマッププラグイン側の「外部のWebページ」欄では反映されませんでした。設定の基本的な流れはSimply Staticの使い方、このほかの詰まりどころはSimply Staticでよくあるエラーと詰まりどころの対処法でまとめて紹介しています。
2. SWELL・WordPressの動的参照が静的HTMLに残る
現象：Simply StaticでREST APIを対象外にしても、書き出し後のHTMLに`wp-json`のREST発見リンクや、SWELLの`restUrl`・`ajaxUrl`・`ajaxNonce`が残っていました。
原因：これらはWordPressコアやテーマがページ出力時に埋め込む値で、Simply StaticのInclude REST API設定を切っても、HTML内への出力自体は止まりません。
対処：WordPress側（子テーマのfunctions.php）でREST発見リンクの出力を停止する対策と、書き出し後のHTMLから該当箇所を機械的に除去する後処理スクリプトの両方を用意しました。
3. お問い合わせフォームは静的サイトで動かない
現象：Contact Form 7はPHPでメール送信処理を行うため、静的HTMLだけを配信する構成では動作しません。
原因：Cloudflare Workers Static Assetsはあくまで静的ファイルを返すだけで、サーバーサイドの処理を実行しません。
対処：フォームの送信先をSSGformに置き換え、スパム対策としてCloudflare Turnstileを組み合わせました。具体的な置き換え手順は静的化したWordPressサイトでお問い合わせフォームを使う方法で紹介しています。
4. OGPタグ・共有URLがSimply Staticで相対化され壊れる
現象：書き出したHTML内の`og:image`やSNS共有用のURLが、絶対URLではなく相対パスに変換されてしまい、SNSでのプレビュー表示が壊れる状態になっていました。
原因：Simply Staticの「Replacing URLs」設定をRelative Pathにしていたため、本来絶対URLであるべきメタタグの値まで巻き込まれて相対化されていました。
対処：書き出し後の後処理スクリプトで、該当するメタタグとSNS共有URLだけを本番の絶対URLへ補正する処理を追加しました。同様の症状の見分け方はSimply Staticでよくあるエラーと詰まりどころの対処法、公開後の確認手順はWordPress静的サイトをCloudflareで公開する手順で扱っています。
5. 検索窓が「見た目だけ動く」状態で残る
現象：静的化後もヘッダーの検索アイコンやサイドバーの検索ウィジェットは表示されたままで、実際に検索を実行してもトップページと同じ内容が返るだけでした。
原因：SWELLの検索機能はWordPress側の動的処理に依存しており、静的HTMLではその処理が実行されません。エラーにはならないため、見た目上は気づきにくい不具合でした。
対処：検索結果を代替表示に切り替える案も検討しましたが、UXとして中途半端になるため、ヘッダー・サイドバー双方から検索UI自体を非表示にする方針としました。
各項目の再現手順そのものは、この記事では深掘りしません。詳細な移行手順はWebサイト移行の基本手順で別途整理しています。
まとめ
まとめで確認すべきポイントを整理します。
今回の移行で、Mobile LCPは30.4%、Server responseは50.1%短縮し、配信部分の月額は1,320円相当から0円になりました（WordPress自体は残しているので、サーバー代がすべてなくなったわけではありません）。一方でMobile FCPは0.776秒悪化しており、これはページ内容の変化も含めた結果です。速度と費用が改善する引き換えに、サイト内検索のような動的機能は失われる、というのがこの移行の実態です。
改めて整理すると、実測ハイライトは次のとおりです。
- Mobile LCP：3.53秒 → 2.46秒（30.4%短縮）
- Mobile Server response：83ms → 41ms（50.1%短縮）
- 配信部分の月額：1,320円相当 → 0円
このサイト自体が、その施工実例です。
