WordPress静的移行を自社に適用できるか、機能ごとの判断基準

アクセスのたびに作るか、あらかじめ作っておくか

従来のWordPress（動的構成）は、アクセスがあるたびにWebサーバー上でPHP（Webサイトを動かすプログラムの処理系）が動き、データベースに問い合わせてHTMLページをその都度組み立てて返します。実行環境が常時インターネットに公開されている状態で、ここが脆弱性（セキュリティ上の欠陥）を狙った攻撃の標的になります。

静的移行では、ページのファイルをあらかじめ作り置きしておき、アクセスに対しては生成済みの静的HTMLファイルだけを返します。公開サーバー上でプログラムの実行もデータベースへの接続も起きないため、SQLインジェクションやプラグインのRCE（リモートコード実行）のように、公開側で動くプログラムを狙う攻撃は成立しなくなります。

管理画面での編集は残り、変わるのは公開までの段取り

「静的にすると、管理画面から記事を更新できなくなるのでは」という心配があります。ハイブリッド静的移行では、編集と管理を、アクセス元の制限や認証で保護した非公開のWordPress（管理専用の環境）に残します。公開側へは、編集内容から作り直した静的HTMLファイルを配置します。記事を書く操作は、管理画面のまま変わりません。

変わるのは、編集してから公開に反映されるまでの段取りです。プレビューと予約公開も、作り直しの仕組みに合わせた作りが要ります。保存してから作り直しと配置が終わるまでの間は、公開側のファイルが前の内容のままだからです。

段取りの組み方は構成によって違うため、移行を頼むときに次の5点を確認してください。どの製品・仕組みで静的HTMLを作るか。作り直しを保存に連動させるか、操作をまとめて行うか。毎回すべてを作り直すか、変更分だけにするか。配置が終わったことをどこで確認できるか。配置に失敗したときに前の状態へ戻せるか。

反映までには、作り置きの処理の分だけ時間がかかります。かかる時間は、ページ数、全体を作り直すか変更分だけか、画像の作り直しをどこまで含むかなどで変わります。組み合わせで決まるため、実際の構成で計測した値を出してもらってください。待ち時間が許容できるかどうかは、あとの適用判断に関わります。

WordPress静的移行のサービス内容・価格を見る →

移行の前後で何が変わるか

公開側から何がなくなり、何が変わらないかを並べます。移行後に自社の運用のどこが変わるかを見るための表です。

自社が適用できるかは、機能ごとに決まる

静的移行の可否は、サイト全体では決まりません。使っている機能を1つずつ見て、そのまま移せるか、別の仕組みに置き換えるか、公開側に残すかを決めます。1つのサイトの中で、この3つが混ざることになります。

置き換えに使う代替方式の選び方を確認する →

向かないサイトの条件

次に当てはまる場合、公開側から実行環境を外しきれません。無理に進めても動的な部分が残るため、期待した効果が出ないことがあります。

ただし、当てはまる項目があっても全体を諦める必要はありません。サイトの大半を静的にして、動的な処理が要る部分だけを分けて残す形も取れます。減らせる範囲がどこまでかは、機能の棚卸しをしないと決まりません。

• 利用者ごとに表示内容が変わる：ログイン後のマイページ、購入履歴、在庫や価格の即時反映など。あらかじめ作り置きできないため、その処理は公開側に残る。
• 更新から公開までの時間を秒単位で詰めたい：静的移行では、編集から公開までの間に作り置きの処理が入る。処理を始める時点も、かかる時間も構成によって違うが、待ち時間そのものは無くならない。秒単位の反映が要件なら、実際の構成で計測した値が要件に収まるかを先に確かめる。収まらなければ合わない。
• 公開側でしか動かせない仕組みに依存している：特定のプラグインが公開側のPHPで動くことを前提にしている場合、代替を探すか、その機能を諦めるかの判断になる。