対応事例と解説
WordPressの静的化で安全性はどう変わるか
当社は2026年10月、企業の公式サイトなどで使われていたPHPの脆弱性に対応しました。サイトの見た目やURLを変えず、公開サーバーではPHPやデータベースを動かさない静的ページへ切り替えました。この記事では、その対応事例から、WordPressの静的化で減らせる危険と、切り替え後に必要な更新・管理の仕事を説明します。
サイトの見た目を保ったまま公開サーバーのPHPを止めました
静的化によるセキュリティ上の効果は、公開サーバーでWordPressやPHPを実行する経路をなくし、その経路を悪用する攻撃の対象を減らせることです。
通常のWordPressは、アクセスがあると、保存された内容を読み出してページを組み立てます。静的化では、あらかじめ作ったページを公開側に置きます。客室、料理、アクセス、お知らせなど、閲覧者によって内容を変える必要がないページに使える方法です。
当社が2026年10月に対応した企業公式サイトでは、WordPressを使うサイトと独自の更新システムを使うサイトを静的ページへ切り替えました。公開側のPHPとデータベースを停止し、見た目、ページのURL、検索向けの設定、必要な転送を維持しました。元のプログラムとデータベースは、今後の更新システムの検討に使えるよう別途保管しています。
10月29日の外部確認では、従来のPHPページや管理画面を呼び出せず、設定・バックアップファイルも外部から見えないことを確かめました。この事例の効果は、実行の入口を閉じた構成と、対応後の確認結果に基づくものです。
古いWordPressが動くままでは静的化しても危険が残ります
静的ページを置いても、同じ場所に旧WordPressやPHPの実行環境を外部から使える状態で残せば、その部分は引き続き対策が必要です。
公開側に静的なトップページを置き、見た目だけを切り替える方法では、以前の管理画面や別URLが動き続けることがあります。利用者が普段見るURLだけを確認して、古い仕組みが閉じたと判断しないことが大切です。
静的化を依頼する際は、ページの書き出しに加えて、旧プログラムの撤去または隔離、管理画面の保護、使わないデータベースや接続権限の整理まで対象を確認してください。旧サイトを保存する場合も、公開領域にそのまま置く必要があるかを見直します。別URLと旧サイトのリスクは、当社の調査事例で詳しく説明しています。
また、すでに改ざんされているページを、そのまま静的ファイルへ書き出してはいけません。不審な外部読み込みや書き換えを含んだ状態なら、静的化したあとも閲覧者にその内容を配ってしまいます。元の内容を確認し、修正したものを出力します。
問い合わせフォームや会員機能は別の仕組みで動かします
静的なページだけでは、サーバー側で問い合わせを受け付けたり、利用者ごとの会員情報を処理したりする機能は実行できません。
そのため、静的化の可否は、ページ数だけでなく、必要な機能をどこで動かすかで判断します。予約エンジンへのリンクは残せますが、空室検索の埋め込みや問い合わせフォームは、接続するサービスの仕様と実際の動作を確認する必要があります。
| 現在の機能 | 静的化するときに決めること |
|---|---|
| 客室・料理・アクセスの紹介 | 修正した内容を誰がいつ書き出すか |
| お知らせの更新 | 更新画面と公開側をどうつなぐか |
| 問い合わせフォーム | 受け付ける処理、保存先、通知先をどこへ置くか |
| 空室検索・予約への移動 | 利用中の予約エンジンとの接続が動くか |
| 会員・決済・個別表示 | 動的な機能を残す範囲と管理する担当を決める |
外部サービスに任せた機能は、そのサービスの管理アカウントや保存データも確認対象になります。静的化したサイトの安全対策と、予約・決済サービスの安全対策を混同しないようにします。
静的化しても施設の担当者がすぐにお知らせを更新できるか確かめます
静的化を選ぶ際は、日常の更新と急ぎのお知らせを、ホテルの担当者が無理なく扱えるかまで確認します。
単にページを書き出しただけでは、これまでWordPressで直せた文章を、制作会社へ毎回依頼する運用に変えてしまう場合があります。季節の料理、休館、交通規制など、施設側がすぐに直したい情報を先に挙げてください。更新する画面、公開までの時間、確認する担当者を、実際の流れで比べます。
更新用のWordPressを一般の閲覧者から切り離し、そこから静的ページを書き出す構成も選べます。この場合は、更新側のWordPressと追加機能の保守、公開のための認証情報の管理が残ります。公開側のプログラムを減らしても、運用の仕事がすべてなくなるわけではありません。
現在のWordPressを更新して使い続ける案と比較するときは、初期費用だけでなく、数年間の保守、更新の依頼費、施設側の作業時間を同じ条件で並べると判断しやすくなります。
静的化した後もドメインや管理アカウントを守る必要があります
静的化しても、ドメイン、サーバー、公開用のアカウント、ページ内で読み込む外部プログラムへの対策は必要です。
公開ファイルを書き換える権限を奪われれば、静的ページも改ざんされます。外部から読み込むプログラムに問題があれば、閲覧者側に影響する場合もあります。必要なものだけを読み込み、誰が変更できるかを整理し、公開内容の変化を監視します。
切り替え時は、検索向けのページ名や説明、URL、転送、言語ごとのページ、画像、予約・問い合わせを確認します。とくに一部の機能を外部へ移した場合は、画面の表示だけでなく、受け付けと通知まで試験します。変更前の状態を残し、問題が出たときの戻し方も決めておきます。
考察：静的化を選ぶときは日々のお知らせを更新する方法も決めます
今回の対応事例では、見た目やURLを保ち、公開側のPHPとデータベースを停止しました。サイトを見せることと、そこで更新システムを動かすことは分けられます。ただし、休館や交通規制のお知らせを誰が出し、いつ反映できるかが決まらなければ、施設が使い続けられる仕組みにはなりません。
静的化を選ぶときは、攻撃の対象を減らす効果と、日々の更新を続ける方法を一緒に比べてください。切り替え後にも、公開ファイルの書き換えや予約導線の変更を見つける仕事は残ります。Webサイトの監視と異常への対応では、その変化を見つけてから対処の結果を確かめるまでを説明しています。
Maximizeは、現在の仕組みを調べ、更新して使い続ける方法、危険な部分を分離する方法、静的化する方法を、必要な機能と運用で選びます。施設側が更新を続けられることも含めて対策します。セキュリティ対策の内容はこちら。
この記事の前提と条件
当社事例は2026年10月29日の対応完了報告に基づきます。静的ページへの切り替え、公開側のPHP・データベース停止、URLや検索向け設定の維持、対応後の外部確認が報告された範囲です。顧客名、ドメイン、ページ数は掲載していません。更新用CMSを分離する構成などは、一般的な設計方法の説明で、この事例で実装した内容を示すものではありません。
この事例で言えないこと
静的化によってすべての攻撃や情報漏えいを防げるとはいえません。外部の予約・決済システム、管理者の端末、メールなどを含む安全性を保証するものでもありません。作業時間、費用、更新頻度に対する適性は、対象の機能と運用を調べて判断します。
Maximize株式会社について
ホテル・旅館の集客を、Webサイト制作、写真・映像制作、広告運用、AI検索対策で支援し、業務のソフトウェアも開発している。セキュリティ対策の詳細
この記事の内容は、出典「Maximize株式会社『WordPressの静的化で安全性はどう変わるか』」を明記して引用してください。調査・参照資料の条件は本文に記載しています。
