最近よく見かける「WordPressは重い・危険だから、今すぐ静的サイトに移行しよう」「このツールなら誰でも簡単に爆速で静的サイト化できる」という話。
きっかけは、最近話題になったPHPの脆弱性（セキュリティ上の弱点）です。原因はPHP側にあるのに、いつの間にか「WordPressは危険」という話にすり替わっているのをよく見かけます。
PHPはWordPressの土台になっているプログラミング言語で、WordPress以外の多くのサイトやWikiでも使われています。
脆弱性の原因がどこにあるかと、どのサイトが影響を受けるかは、分けて考える必要があります。
私はWordPressのブログ、Wiki、HTMLだけで作った静的サイトを並行して自分で運用しています。
作るだけでなく、動かし続け、壊れたら直す側の立場から言うと、「簡単に静的化できる」という話はそのまま受け取らないほうがいいと感じています。
ここでいう「静的サイト」とは、WordPressのようにPHPやデータベースを使わず、できあがったHTMLファイルをそのまま置いて表示するサイトのことです。
仕組みが単純で軽い反面、入力フォームや会員ログインのような「動きのある機能」は、そのままでは持てません。
もちろん、静的サイトが悪いという話ではありません。向いているサイトは確実にあります。
この記事では、移行で何が起きるのかを整理したうえで、そもそも自分でサイトを運営する必要があるのかも含めて、Webサイトの選び方を書きます。
静的サイトが向いているケース
先に前提を置いておきます。次のようなサイトなら、静的化は有力な選択肢です。
- お問い合わせフォーム、予約、会員ログインなどの動きのある機能がない（または外部サービスで十分）
- 集客をSEOに頼らない、または更新が少なくても成り立つ（会社概要・LP・ポートフォリオなど）
- サイトを作って公開するまでの手順（変換・アップロードなど）を自分で維持できる
問題は、この条件を確認せずに「誰でも簡単にできる」と言われてしまうことです。
記事を継続的に出して検索から集客するブログ運営者には、この条件はほとんど当てはまりません。更新が止まると新しいキーワードを拾えず、情報も古くなっていくためです。
さらに、静的サイトにした後の「どうやって更新し続けるか」という仕組みまで、簡単に語られることはほとんどありません。
静的サイトで運用を始めたものの、あとから動的な仕組みが必要になって作り直す事例もあります。
静的サイトで問題ないかどうかは、用途と、将来の運用を見越して考えるのが一番だと思います。
「簡単に移行できる」で見落とされるもの
記事と固定ページを書き出して、静的サイトに変換するツールに通せば、見た目上のページは移せます。
しかし、サイトは「文字と画像を表示するだけ」のものではありません。
動きのある機能は、そのままでは動かなくなる
お問い合わせフォーム、予約システム、会員制ページ、ネットショップなどは、静的サイトにした時点で動かなくなります。
外部の別サービスで置き換える案が出ますが、サービスの選び方、設置、月額費用の管理、障害時の対応は誰がやるのでしょうか。
移行の手軽さは、この再構築コストを数えていないことが多いです。
WordPressの中のデータは全部は移らない
記事と固定ページはファイルに書き出して移せても、プラグインが独自に保存しているデータ（予約履歴、フォームの過去ログ、会員情報など）は移らない可能性が高いです。
また、記事を静的HTMLに変換する過程で、今までと同じ表示になる保証はありません。崩れたレイアウトや動かなくなった部分の調整のほうが、移行作業そのものより手間がかかることもあります。
一方で、WordPressから別のWordPressへのサーバー移転のように、データベースを使う「動的サイト」同士の移行なら、データベースごと移せるので、プラグインが持つデータもそのまま引き継げることが多いです。同じプラグインが使える環境であれば、見た目もほぼ同じように再現できます。
静的サイトへの移行が難しいのは、データベースを使う仕組みそのものをやめて、別の形に作り替えるからです。
移行のしやすさだけで見れば、静的サイトへ移すより、動的サイトのまま引っ越すほうがはるかに楽です。
移行で事故が起きやすい場所
もしサイトを移行するなら・・・という想定でそれぞれ考えられる事故を上げてみました。実際に移行すれば他にも色々な事故がおきるかもしれないです。
ドメインの設定とメール（もっとも危険）
サーバーを切り替えるときに、メールの届け先設定（MXレコード）の引き継ぎを間違えると、サイトは普通に表示されるのに、問い合わせメールや通知だけが届かなくなります。
見た目では異常が分からないので、非エンジニアにはほぼ気づけません。
そもそも、こうしたドメインの設定（DNS）は、専門知識がないと触るのが怖い部分です。
URLとSEO
記事のURLは揃えられても、更新情報の配信用URL（フィード）、短縮URL、画像のURLなどは、変わったり消えたりすることがあります。
古いURLから新しいURLへの転送設定（リダイレクト）を誤る、画像検索からの訪問が多いサイトだった、といった場合は、移行後にSearch Console（検索結果での表示状況を確認できるGoogleの無料ツール）を見て、訪問数や順位の低下に気づくことになりかねません。
順位が下がる可能性は、最初から織り込んでおく必要があります。
「静的ならノーメンテ」ではない
静的サイトにすれば、PHPやデータベースの脆弱性リスクからは解放されます。
ただし、その代わりに、次のような保守が発生します。
- サイトを作り直すためのツール類の維持
- 変換ツールや関連部品の更新
- 公開までの自動化の仕組みの保守
環境が変われば、結局は人間が直すことになります。
また、PHPが動く共用サーバーに置いたままであれば、サーバー設定の不備やログイン情報の漏れといったリスクはそのまま残ります。
HTMLだけでも、改ざんのリスクはある
HTMLだけのサイトでも、改ざん（第三者にサイトの中身を勝手に書き換えられること）のリスクはなくなりません。
FTP（サーバーにファイルを送る仕組み）やサーバー管理画面のログイン情報が漏れれば、HTMLファイルは書き換えられます。
外部から読み込んでいるプログラム部品が改ざんされ、自分のサイトに悪意あるコードが混ざることもあります。
PHPやデータベースがなくなっても、守る対象が消えるわけではなく、場所が変わるだけです。
見えにくくて怖い「踏み台」のリスク
静的サイトでも、サーバーやアカウントに侵入されれば、「踏み台」にされるおそれがあります。
踏み台とは、攻撃者が他人のサイトやサーバーを乗っ取り、別の攻撃や悪用の足がかりにすることです。たとえば、次のようなことが起こります。
- 自分のサイトに、ウイルスの配布ページや偽のログインページ（フィッシング）を置かれる
- 訪問者を別の不正なサイトへ転送するコードを埋め込まれる
- 検索結果に出る迷惑なページを大量に作られる
- サーバーの種類や設定によっては、迷惑メールの送信や他のサイトへの攻撃に使われる
怖いのは、見た目ではなかなか気づけず、知らないうちに「被害者」から「加害する側」になってしまうことです。
サイトの信用や検索結果での評価が下がり、サーバー会社に利用を止められることもあります。
バックアップは元に戻す助けにはなりますが、乗っ取られること自体は防げません。
入り口は、PHPやWordPressの弱点だけではありません。
FTPやサーバー管理画面、GitHub（プログラムや設定ファイルを保管するサービス）などのログイン情報の漏れ、外部から読み込んでいる部品の改ざん、設定のミスなど、静的サイトにも同じように存在します。
その為、静的か動的かに関わらず、次の3つが必要です。
- ログイン情報を守る（使い回しをしない、二段階認証を使う）
- 不要なファイルやアカウントを置かない。ディレクトリに正しい権限（パーミッション）を設定する。
- 変更に気づける仕組みを持つ（変更履歴を残す、変更があったら通知するなど）
静的サイトであっても「メンテナンス」から逃れられない
「静的サイトしか配信しないんだから、サーバーメンテナンスの概念なんてないでしょ？」と思われがちですが、その考えは少し甘いです。
実際、あの有名な「阿部寛のホームページ」も、サイトが置かれている@niftyのサーバーが、PHPの脆弱性対応で緊急メンテナンスに入り、2026年10月22日の未明から日中まで閲覧できなくなりました。
サイト自体は、PHPを使わないシンプルなHTMLとみられ、サイトそのものに脆弱性が見つかったわけではありません。（電撃オンラインの記事などの報道をもとにしています）
サイト自体が純粋なHTMLであっても、それを配信しているサーバー基盤が何らかのシステムで動いている以上、欠陥が見つかれば、修正やメンテナンスが入るのは当然のことです。
共用サーバーであれ、AWSやCloudflareのような大手サービスであれ、どの環境を選んでも「メンテナンスされる時はされる」という事実は変わりません。
止まったときは割り切って受け入れる。
だからこそ、「自分が一番安心できて、管理を信頼できるサーバーを選ぶ」という視点が大切になってきます。
WordPressだけが危険ではない
一方で、WordPressを一方的に悪者にするのも極端です。
サーバー側の基本的なセキュリティ対応は、現代のレンタルサーバーなら自動化されている部分も多いです。
ただし、PHPのバージョンやWordPress本体・プラグインの更新は、サーバーの仕様や設定によって、自動のものと自分で行うものが分かれます。
利用中のサービスで確認しておく必要があります。
枯れた技術という強み
WordPressは、かなり昔から使われている「枯れた技術」です。
枯れた技術とは、長く使われて、仕組みも弱点も広く知られている技術のことです。
利用者が非常に多いので、トラブルの解決方法や対策の情報が豊富で、脆弱性が見つかったときも、すぐに対応や情報共有が進みます。
困ったときに調べれば答えが見つかりやすいのは、運用する側にとって大きな強みです。
プラグインとの付き合い方
もちろん、プラグイン（機能を追加する部品）から攻撃を受けるリスクは残ります。
多くの場合は、開発者によって修正版が配られ、アップデートすれば塞がります。
注意したいのは、更新を放置することと、更新が止まったプラグインを使い続けること、そして残念ながら悪意をもって配布されるプラグインも存在することです。
だからこそ、プラグインは必要なものだけを、信頼できる配布元から入れ、更新を続けることが大切です。
バックアップがあれば、リスクは分散できる
WordPressでも、バックアップをしっかり取っていれば、万が一攻撃されたりサイトが壊れたりしても、被害を小さく抑えられます。ポイントは次の3つです。
- サーバーとは別の場所にも保管する
- 記事やコメントなどのデータベースと、テーマ・プラグイン・画像などのファイルの両方を取る
- 最新の1つだけでなく、数世代分を残す
私の場合は、サーバーのバックアップ機能だけに頼らず、自動でバックアップやサイトへの反映（デプロイ）を行う仕組み（GitHub Actions）を組んで、サーバーとは別の場所にもデータを保管しています。
具体的な方法は、過去の記事「個人開発とブログ運用を省力化。GitHub ActionsとDiscordで通知・バックアップ・デプロイを完全自動化した話」に書いています。
実際に、PHPの重大な脆弱性が話題になったときも、私はサーバーの管理画面に入って対応する必要がありませんでした。
PHPの修正は、私が使っているレンタルサーバー（エックスサーバー）の側で自動的に適用されました。
バックアップも取っていたので、万が一のときは元に戻せる状態でした。
さらに、いざとなればSSH（サーバーに文字で命令を送って直接操作する仕組み）で接続して、確認や対応もできます。
この脆弱性が公表されたのは2026年10月21日です。エックスサーバーは同日16時から、予防的な安全対策として、サーバーパネルなどの管理画面を一時停止しました。
不正アクセスによるものではないと発表されていて、サイトの表示やメールの送受信は通常どおり使えました。管理画面は翌22日の朝から順次再開されましたが、その後もしばらくは混み合っていました。
管理画面に入れない間も困らないように、バックアップなどを自分で用意しておく大切さを実感しました。（エックスサーバーの公式発表をもとに整理した、THREE D PLUSの解説記事を参照しています）
なお、PHP 8.1以前のバージョンには、PHP公式の修正版が出ていません。
エックスサーバーは独自の修正を当てて対応しましたが、古いバージョンのままだと、次の脆弱性のときに同じ対応が受けられるとは限りません。
PHPのバージョンは、サポートが続いている新しいものにしておくのが安全です。
つまり、「サーバー側の自動対応」「自分のバックアップ」「最後の手段としての直接操作」という3段構えにしておくことで、慌てずに済みました。
ただし、バックアップは「実際に復元できて」初めて意味があります。
復元の手順を一度試しておくことが大切です。
また、バックアップは被害を小さくする手段であって、攻撃を防ぐものではないので、更新やパスワードの管理は引き続き必要です。
サーバー会社やプランによって対応は異なるので、自分が契約しているサービスの仕様は確認しておきましょう。
国内レンタルサーバーは意外とメリットが大きい
AWSやCloudflareなどのモダンなインフラを使いこなすには、それなりの専門知識や、いざという時のトラブルシューティングのスキルが求められます。
その点、国内のレンタルサーバー（エックスサーバーなど）には、ネット上の解説記事やマニュアルが多く、いざという時に答えが見つけやすいという強みがあります。
何より大きいのは、サーバー側の基本設定やセキュリティ対応を、事業者が代わりに行ってくれることが多い点です。
今回のPHPの脆弱性でも、エックスサーバーでは修正が自動で適用されました。
ただし、対応方法はサーバー会社やプランで違い、緊急メンテナンスでサイトが一時的に止まった例もあります。
自分が脆弱性の情報を常にチェックして、パッチ（修正プログラム）を当てて回る必要が減るので、その分の時間を、「記事を書く」「数字を分析する」といった本来の作業に回せます。
どの環境を選ぶにせよ、「今自分が使っているインフラの仕組みを、最低限は理解しておく必要がある」という事実は変わりません。
背伸びして管理しきれない環境を選ぶより、自分のスキルとリソースに合った場所を選ぶのが、サイトを長く続ける一番の近道です。
どちらを選んでも、保守は必要
結局、どちらを選んでも「保守運用から完全に逃げられる方法」はありません。「このサービスを使えば安全」という言い方は存在しないと考えたほうが安全です。
Webサイトの最適解は、流行りの構成や誰かのおすすめでは決まりません。基準は、そのサイトの運用保守を、誰が、どうやって続けるのかというリソースとスキルです。
とくに、ブログのようにSEOで集客するサイトは、更新を止められないぶん、保守の負担も大きくなります。
静的か動的かを決める前に、更新を続ける仕組みを、自分や第三者の管理者が回し続けられるかで選ぶべきだと考えています。
移行前のチェックリスト
移行を考える前に、次のチェックリストを確認してみてください。
- 今動いている機能（フォーム、予約、会員など）をすべて洗い出したか
- 現在のドメイン設定（特にメールの届け先を決めるMXレコード）を控えたか
- 古いURLと新しいURLの対応表（転送設定）を作ったか
- 移行前のバックアップを取り、復元できることを確認したか
- 移行後に、検索からの訪問数と順位を確認する予定があるか
- フォームやリンクが壊れたとき、自分で原因を特定して直せるか
- サイトの作成手順、サーバー、ドメイン設定のトラブルから自力で復旧できるか
- 移行後に、記事を追加・修正する具体的な手順を自分で説明できるか（または自動化の仕組みを維持できるか）
1つでも不安が残るなら、静的化は「簡単」ではありません。
そもそも、なぜドメインを取ってサイトを公開するのか
静的サイトにするか、WordPressにするか。
ここまで書いてきましたが、そもそも静的サイトに拘る必要はありません。
これらは、目的を果たすための手段であって、目的ではないからです。
公開する前に、目的を決めましょう。自分でドメインを取ってサイトを公開する理由は、たとえば次のようなものです。
- 書いた記事や作ったものを、自分の資産として長く積み上げたい
- 自分の名前や屋号を、信頼できるブランドとして育てたい
- 機能や見た目を、自分の思いどおりに作り込みたい
- 事業の窓口やお店を、サービスに左右されずに自分で持ちたい
このどれにも当てはまらないなら、自分でドメインを取ってサイトを運営する必然性は高くありません。
自分のドメインでサイトを持つことは、自分の土地を持つことに近いです。
積み上げたものは自分の資産になりますが、そのぶん、守る責任も自分にあります。
運用が難しいと感じたら、外部サービスという選択肢もある
ここまで読んで「自分で管理するのは大変そう」と感じたなら、外部のサービスを使うのも立派な選択です。
ブログならnoteなど、会社や団体ならGoogle Workspaceで作れるページなど、ネットショップもショップ作成サービスが数多くあり、手段はいくらでもあります。
運用保守が難しいのであれば、外部サービスに丸ごと任せるのは正しい判断です。
無理に自分で抱え込んで、メールが届かなくなったり、サイトが改ざんされたりするほうが、よほど大きな損失になります。
外部サービスの良いところ
サーバーやドメインの管理、セキュリティの更新は、サービス側が行ってくれます。専門知識がなくても、すぐに始められます。
会社案内やお知らせ、簡単な紹介ページのように、静的サイトで足りる程度の内容なら、自分で静的サイトを作って保守するより、Googleサイトのような既存のサービスで作るほうが、手間もリスクも小さい場合があります。
ただし、デザインの自由度や検索対策の細かい調整には限りがあることが多いので、必要な機能が使えるかを事前に確認しておくと安心です。
ただし、自分の資産にはなりにくい
外部サービスに書いた記事は、そのサービスの上に「間借り」している状態です。
サービスの終了、規約の変更、アカウントの停止などがあれば、積み上げたものを失うおそれがあります。
この考え方は、過去の記事「私がQiitaやNoteなどの投稿を撤退した「3つの理由」」にも詳しく書いています。
自分のサイトか、外部サービスか
大切なのは、何のために公開するのかです。
長く資産として残したい情報なのか、一時的に公開するだけの情報なのかで、向いている方法は変わります。
| 項目 | 自分のサイト（独自ドメイン） | 外部サービス（noteなど） |
|---|---|---|
| 向いている情報 | 長期的に資産として公開したい情報 | 一時的に公開するだけの情報 |
| 運用の手間 | 更新・バックアップ・セキュリティを自分で管理 | サービス側に任せられる |
| 資産になるか | 自分のものとして積み上がる | サービスに依存し、自分の資産にはなりにくい |
| 主なリスク | 管理を怠ると事故につながる | サービス終了・規約変更・アカウント停止 |
どちらが正解という話ではありません。
自分の目的と、運用にかけられる時間や知識に合った方法を、理由を持って選ぶことが大切です。
AIに任せたとしても、責任は人間に残る
最近は、移行作業をAIやツールに任せる流れも増えています。便利ですが、「何が動いていて、何が壊れたか」を確認する責任は人間に残ります。
とくに怖いのは、壊れていても見た目では分からない領域です。メールが届かない、フォームが送信されない、検索流入が静かに減っていく。
こうした問題は、AIの出力を信用して作業を終えてしまうと、取り返しがつかなくなってから気づきます。
ウェブサイトは閲覧してもらい、使ってもらって初めて価値が出るものです。
どんな形で運用してどうしたら必要な方に情報が届けれるか。どうやって運用するのが良いのか。今一度考えてサイト運営をしてみてください。
コメント