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

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

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

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

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

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

変わるのは、編集してから公開に反映されるまでの段取りです。プレビューと予約公開も、作り直しの仕組みに合わせた作りが要ります。プレビューは、編集側の画面と作り置きで出力されるページの表示が同じとは限りません。予約公開は、予約の時刻に作り直しと配置が始まらなければ、公開側のファイルが前の内容のままになります。

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

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

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

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

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

見るところ	従来の動的WordPress	編集用のWordPressを残して移行した後（すべて作り置きに移せた場合）
公開側で動くもの	PHPプログラムとMySQLデータベース	公開サーバーで動くプログラムはなし（配るのはHTML・CSS・JavaScript・画像のファイル）
公開側の更新作業	プラグインとテーマの更新に追従し続ける	更新の対象が公開側から無くなる。管理用のWordPressでは引き続き必要
表示までの処理	アクセスのたびにサーバーが組み立てる	配信元が作り置きのファイルをそのまま返す。CDN（配信網：利用者に近い配信拠点からファイルを返す仕組み）に置くこともできる
公開側から狙える攻撃	脆弱性を突いた侵入やデータベースの改ざん	公開側で動くプログラムを狙う攻撃は成立しない。管理用の環境と外部サービスは対象に残る

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

静的移行の可否は、サイト全体では決まりません。使っている機能を1つずつ見て、そのまま移せるか、別の仕組みに置き換えるか、静的移行には収まらないかを確かめます。収まらない機能があれば、その機能を外すか、サイトごと作り替えるかを決めます。

機能	扱い	確認すること
記事・固定ページの表示	そのまま移せる	本文に、表示のたびに中身を組み立てる部品（動的ブロック、プラグインのショートコード）が入っていないか
問い合わせフォーム	置き換える	添付ファイルの受け取り、自動返信の要否、送信内容の保存先
サイト内検索	置き換える	索引の大きさ。実際のページで読み込み時間を測り、重すぎる場合は外部の検索サービスに預ける
会員向けの非公開ページ	静的移行には収まらない	WordPressの会員プラグインで、会員をサイトの中で管理しているか。管理しているなら、会員の処理を Laravel（サーバー側で動くWebアプリを作るための枠組み）などで作り直す方法を勧める
予約の受け付けと空き状況の表示	外部に預けていれば移せる	WordPressの予約プラグインで、予約をサイトの中で扱っているか。扱っているなら静的移行には収まらず、予約の処理を Laravel などで作り直す方法を勧める
ネットショップの注文・決済・在庫	外部に預けていれば移せる	WordPressのECプラグイン（WooCommerce など）で、注文と在庫をサイトの中で扱っているか。扱っているなら静的移行には収まらず、注文の処理を Laravel などで作り直す方法を勧める

サイト内検索は、作り置きした索引を閲覧している画面の側で引く方式なら、外部のサービスを使わずに動かせます。静的な検索ライブラリのPagefind（外部サイト）は、1万ページのサイトでも、ライブラリ本体を含めて300kB未満の通信で全文検索ができると説明しています。

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

向かないサイトの条件

次に当てはまる機能を残すには、外部のサービスや代替の仕組みへ移す必要があります。会員、注文、予約をサイトの中で扱う画面は移せないため、外すか、作り替えるかを決めます。

当てはまる機能を外せるかどうかで、適用できるかが分かれます。一部の区画だけWordPressを公開側に残す形は、当方のWordPress静的移行では扱いません。どの機能が当てはまるかは、機能の棚卸しをしないと決まりません。

利用者ごと、またはその場で表示内容が変わる：ログイン後のマイページ、購入履歴、在庫の表示、予約の空き状況など。会員、注文、予約の情報によって内容が変わる画面は、作り置きでは出せない。外部の予約や決済のサービスに預けている部分は、そのまま残せる。外す仕様の変更を許容できないなら、作り直しを検討する。
更新から公開までの時間を秒単位で詰めたい：静的移行では、編集から公開までの間に作り置きの処理が入る。処理を始める時点も、かかる時間も構成によって違うが、待ち時間そのものは無くならない。秒単位の反映が要件なら、実際の構成で計測した値が要件に収まるかを先に確かめる。収まらなければ合わない。
公開側でしか動かせない仕組みに依存している：特定のプラグインが公開側のPHPで動くことを前提にしている場合、代替を探すか、その機能を諦めるかの判断になる。

参考情報（外部サイト）

本文で参照した外部の公開情報です。