1. WordPressも「置かない」で守る、『静的サイト化』――ヘッドレスか、プラグインか、2つの道

1. 導入：「うちはWordPressなんだけど......」

前回、PHPの重大脆弱性「php2shell」をきっかけに、Drupalをヘッドレス化して静的サイトにする構成を紹介しました。

CMSは手元のPCに引っ込めて、公開サーバーにはHTMLだけを置く。

守るより、置かない。

そんな話でした。

すると、ほぼ予想通りの質問が返ってきます。

「それ、WordPressでもできるの？」

できます。

しかも、WordPressにはDrupalよりも選択肢が多い。

利用者が圧倒的に多い分、静的化のためのプラグインも育っているからです。

そして、WordPressこそ静的化の恩恵が大きいCMSでもあります。本体、テーマ、そして数十個入っていることも珍しくないプラグイン。そのすべてがPHPの上で動いています。

この章の結論：WordPressにも「置かない」道はある――。

2. WordPressの静的化には「2つの道」がある

富士山の山頂には、いくつかの登山道があります。

どの道を通っても、たどり着く山頂は同じ。

WordPressの静的化も、それに似ています。

• 道① ヘッドレス：前回のDrupalと同じ。APIでデータを取り出し、Next/NuxtでHTMLを作る
• 道② プラグインで書き出す：WordPress自身に、今のサイトをそのままHTMLとして書き出させる

途中の道は違っても、出口は同じです。

WordPressは手元のPCに。公開側には、HTMLと画像のファイルだけ。

S3＋CloudFrontの部分は、前回の構成をそのまま使えます。

この章の結論：道は2つ、ゴールは1つ――。

3. 道① ヘッドレス：REST API＋Next/Nuxt

実は、WordPressは最初からヘッドレスの準備ができています。

REST APIが本体に標準で入っているからです。

/wp-json/wp/v2/posts を開けば、記事一覧がJSONで返ってくる。前回のDrupalの「JSON:API」を、これに置き換えるだけです。GraphQLで扱いたければ、WPGraphQLプラグインという選択肢もあります。

あとの流れは、前回とまったく同じです。

ローカルのWordPress → Next/Nuxtでビルド → S3＋CloudFront。

画像URLが localhost になる問題も、バックアップが生命線になる点も、そのまま当てはまります。

ただし、WordPressならではの落とし穴が一つあります。

ブロックエディタの見た目です。

カラム、ボタン、ギャラリー、埋め込み。ブロックエディタで作った装飾は、APIからは「HTMLの断片」として返ってくるだけです。

見た目を支えているCSSはテーマ側にあります。

つまり、フロントエンドを作り直すなら、ブロック用のCSSも持ち込むか、自分で書き直す必要がある。記事が多く、装飾を凝っているサイトほど、ここで手間が膨らみます。

この章の結論：自由度は最大、ただし見た目は自分で作る――。

4. 道② プラグインで書き出す：Simply Staticという近道

「フロントエンドを作り直す余裕なんてない」

正直、多くの現場はこちらだと思います。

そこで出てくるのが、WordPressならではの近道です。

WordPress自身に、静的HTMLを書き出させる。

代表格がSimply Staticです。インストールしてボタンを押すと、今のサイトをテーマの見た目もブロックの装飾もそのままに、HTMLのフォルダとして書き出してくれます。

無料版で書き出したフォルダを、前回紹介した aws s3 sync でS3に載せる。それだけです。構成図の「Next/Nuxtでビルド」が、プラグインに置き換わるイメージですね。

有料のSimply Static Proになると、さらに踏み込みます。

• AWS S3への直接デプロイと、CloudFrontのキャッシュ無効化
• GitHub、Cloudflare Pages、Netlifyなどへのデプロイ
• Contact Form 7、Gravity Forms、WPFormsなど既存のフォームを静的サイトでも動かす仕組み
• 静的サイト用の検索、コメントをWordPress側に送り返す仕組み

「静的化すると動かなくなる機能」の多くを、プラグイン側で面倒を見てくれるわけです。

ちなみに、同じ系統のプラグインとしてWP2Staticも知られています。ただ、WordPress.orgのプラグインディレクトリには掲載されておらず、インストールはGitHubやComposer経由になります。開発の停滞を受けてフォークされたプロジェクトもあり、これから始めるならSimply Staticの方が無難だと思います。

もちろん、ここにも注意点はあります。

WordPress自体は、手元のPCで動かし続けることになります。PHPもプラグインも、更新は必要です。ただ、インターネットから見えない場所にあるので、「今夜中に当てないと危ない」という切迫感からは解放されます。

この章の結論：見た目はそのまま、PHPだけ消える――。

5. どちらを選ぶか

引っ越しにたとえるなら、こうです。

道①は、新築への建て替え。間取りは自由ですが、時間もお金もかかります。

道②は、家ごと安全な場所へ移すこと。中身はそのまま、場所だけが変わります。

私の考えは、シンプルです。

• 今のデザインのまま、早く静的化したい → 道②
• デザインも刷新したい、フロントエンドを自由に作りたい → 道①

迷ったら、まず道②で静的化してしまう。デザインのリニューアルは、その後でゆっくり道①に移ればいい。セキュリティの手当ては早い方がいいからです。

どちらの道でも、PHPで動いていた機能の置き換えは避けられません。

この章の結論：迷ったら、まず「移す」。作り直すのはその後でいい――。

6. 明日からできる対処

1. まずPHPとWordPressを最新に
   • 静的化は計画的に。パッチは今日です
2. プラグイン一覧を棚卸しする
   • 「これはPHPが無いと動かない機能か？」という目でひとつずつ見る
   • フォーム、検索、コメント、会員機能、EC。どれが残るかで道が決まります
3. ローカルにWordPressのコピーを作る
   • LocalやDocker、wp-envなどで、本番のコピーを手元に立ち上げる
   • 本番には触らないので、気軽に試せます
4. Simply Static（無料版）で書き出してみる
   • 書き出したフォルダのHTMLをブラウザで開き、崩れやリンク切れを確認する
   • これだけで「道②でいけるか」がかなり見えてきます
5. バックアップの仕組みを先に作る
   • DBダンプと wp-content/uploads のバックアップ。手元に移す前に必ず

この章の結論：まずは手元のコピーで、ボタンを1回押してみる――。

7. 結論

WordPressは、世界で最も使われているCMSです。

だからこそ、狙われやすい。

本体、テーマ、プラグイン、そしてその土台のPHP。どこか一か所に穴が開けば、それで十分です。

でも、前回と同じことが言えます。

公開サーバーにPHPが無ければ、PHPの穴は関係ない。

Drupalでも、WordPressでも、この原則は変わりません。

そしてWordPressには、デザインをそのままに静的化できる近道がある。

「静的化なんて大がかりな話」と思っていた方ほど、一度手元のコピーで試してみてほしいと思います。

思っていたより、ずっと簡単かもしれません......。

あなたのWordPress、プラグインを外したら、何が動かなくなりますか？