「WordPress 静的化」「WordPress Cloudflare」で検索している方の多くは、この手段自体はもう知っていて、あとは「結局どういう流れで進むのか」「自分のサイトでもできるのか」を知りたい段階だと思います。
このサイト自体もWordPressをCloudflare Workers Static Assetsへ移行した実例で、私たちはこの移行を受託でもお手伝いしています。この記事では、細かい手順ではなく、移行という作業の全体像と、やる価値があるかどうかの判断材料をまとめます。
静的化すると何が変わるのか
WordPress静的化とは、記事を書く場所はWordPressのまま残しつつ、公開時にページをあらかじめHTMLへ書き出しておき、読者にはそのHTMLだけを配信する構成です。何が変わるのかを4つの面で見ていきます。
速度：通常のWordPressは、アクセスのたびにPHPでページを組み立ててから返します。静的HTMLならその場で組み立てる工程がなく、あらかじめ用意したファイルをそのまま返すだけで済みます。私たちの実測でも、サーバーが応答するまでの時間が大きく縮まりました。詳しい数値は後述します。
費用：静的ファイルの配信だけであれば、Cloudflare Workers Static Assetsの無料枠に収まることが多く、配信費用0円で運用できます。ただし記事を書くためのWordPress自体は別に必要で、その置き場所の費用は残ります（この点は「費用の考え方」で改めて触れます）。
セキュリティ：読者からアクセスされるのは静的なHTMLファイルだけなので、WordPressの脆弱性を突いた攻撃（プラグインの穴を突かれる、管理画面へ不正ログインされるなど）が、そのまま公開サイトの改ざんに直結しにくくなります。WordPress本体は管理用の経路からしかアクセスできない状態にしておくのが前提です。
運用：普段の執筆作業はWordPressの編集画面のままで変わりません。ただし公開のたびに「書き出し→後処理→デプロイ」という一手間が増えます。この一手間をどう見るかが、後述する向き不向きの分かれ目になります。
どんなサイトなら静的化できるのか
会員機能やサイト内検索、コメント欄のようにリクエストのたびに処理が変わる仕組みは、静的HTMLだけでは動かせません。お問い合わせフォームのような単純な機能は、外部サービスへの置き換えで対応できます。
自分のサイトが向いているかどうかをもう少し詳しく確認したい方は、WordPress静的サイトの向き不向き診断で判断基準を整理しています。
移行の全体像 — 準備から検証までの5段階
ここが本記事の中心です。実際の移行は、準備・書き出し・後処理・公開・検証という5つの段階に分かれます。それぞれ何をする段階なのか、どこで詰まりやすいのかを、手順の細部には立ち入らずに地図として示します。
| 段階 | 役割 | 主な難所 |
|---|---|---|
| 準備 | 静的化に対応しない機能を洗い出す | 見た目だけ動く機能の確認 |
| 書き出し | WordPressをHTMLファイルへ変換する | 動的参照やサイトマップの扱い |
| 後処理 | URLや参照を検査・補正する | OGPやSNS共有URLの確認 |
| 公開 | Cloudflare Workers Static Assetsへ配信する | 本番ドメイン切り替え |
| 検証 | 公開後のリンク・サイトマップを確認する | 見えない参照漏れの発見 |
- 準備：WordPress側で、静的化に対応しない機能を洗い出して外していく段階です。サイト内検索のように「見た目だけ動いて中身が動かない」機能は気づきにくく、事前に確認しておく必要があります。お問い合わせフォームも、PHPでメール送信するタイプ（Contact Form 7など）は静的HTMLでは動作しないため、静的サイト向けの送信サービスへの置き換えが必要です。具体的な置き換え方法は静的サイトのお問い合わせフォーム設置にまとめています。
- 書き出し：Simply StaticのようなプラグインでWordPressのページをHTMLファイルとして書き出す段階です。標準設定のままだとsitemap.xmlが書き出しに含まれなかったり、WordPressやテーマが埋め込む動的な参照（REST APIのリンクなど）がHTMLに残ってしまったりと、初回でつまずきやすいポイントが集中しています。設定の基本的な流れはSimply Staticの使い方、実際に発生したエラーと対処法はSimply Staticの詰まりどころ対処法で扱っています。
- 後処理：書き出したHTMLの中から、WordPress生成元のURLや動的な参照が残っていないかを機械的にチェックし、補正する段階です。OGP画像やSNS共有用のURLが意図せず相対パスに変換されてしまうといった、見た目では気づきにくい不具合もここで拾います。
- 公開：後処理を終えたHTMLをCloudflare Workers Static Assetsへデプロイし、実際のドメインで配信を始める段階です。具体的な公開手順はWordPress静的サイトをCloudflareで公開する手順にまとめています。
- 検証：公開後、リンク切れや混在コンテンツ（WordPress生成元のURLが本番に紛れ込んでいないか）、サイトマップへの反映などを確認する段階です。ここを省略すると、検索エンジンに正しく認識されないまま気づかない、という事態になりかねません。
5段階を通して見ると、詰まりやすいのは「書き出し」と「後処理」です。ここは一度パターンをつかめば再現性が高い一方、初回は想定外の動的参照やURL変換に振り回されやすいところです。
移行の全体像を把握したうえで、作業範囲と費用を確認したい方は、静的化移行サービスの費用と範囲をご覧ください。
実際にやってみてどうだったか
このサイト自体が移行の実例です。Lighthouse CLIでの実測では、Mobile LCP（ページの主要な要素が表示されるまでの時間）が3.534秒から2.460秒へ、1.074秒短縮しました（約30%短縮）。配信費用も、WordPressで直接配信していたときの月額相当額から、配信費用0円に変わっています。
一方で、Mobile FCP（最初の要素が表示されるまでの時間）は悪化しており、良い数字だけを見せているわけではありません。またこの比較は、配信基盤だけを切り替えたA/B試験ではなく、画像の差し替えなども含めたサイト移行プロジェクト全体のbefore/afterです。計測条件や悪化した指標まで含めた全データはWordPress×Cloudflare移行の実録で公開しています。
費用の考え方
静的化そのものにかかる費用は、自分で作業するか、外部に依頼するかで変わります。自分で行う場合、プラグインの設定や後処理の仕組みづくりに時間がかかりますが、金銭的なコストはほぼかかりません。外部に依頼する場合は作業費がかかる代わりに、前述の「書き出し」「後処理」でつまずきやすい部分を任せられます。
配信基盤の費用については、無料枠に収まる範囲であれば配信費用0円が実現できます。ただし、記事を書くためのWordPress自体をどこに置くかによって、そちらの費用は別途かかる場合とかからない場合があります。自分で作業する時間が取れない方は、静的化移行サービスの費用と範囲で、この記事と同じ移行にかかる費用と作業範囲を確認できます。
まとめ
WordPress静的化とCloudflareへの移行は、準備・書き出し・後処理・公開・検証という5段階で進みます。詰まりやすいのは書き出しと後処理で、そこさえ乗り越えれば速度・費用の面でメリットが出やすい構成です。一方で、サイト内検索のような動的機能は失われるため、自分のサイトに向いているかどうかの見極めが最初の分かれ目になります。
- 移行は準備→書き出し→後処理→公開→検証の5段階
- 特に書き出し・後処理でつまずきやすい
- 更新頻度が低〜中程度の情報サイトに向いている
- 実測ではMobile LCPが約30%短縮、配信費用0円を達成（悪化した指標もあり）
各段階の詳しい手順は、それぞれのリンク先記事で確認してください。
