WordPress静的化とは？管理画面を残して別サーバーで公開する方法

「WordPressの管理画面は使い続けたい。でも、公開しているサイトが攻撃される不安は減らしたい」
この両方を満たすのがWordPressの静的化です。

記事はこれまでどおりWordPressで書き、公開するのは書き出したHTMLだけ。管理画面は外部から見えない場所に置くため、WordPressの脆弱性を狙った攻撃が公開サイトに届かなくなります。

この記事では、WordPressの保守・セキュリティを専門とするサイト引越し屋さんが、静的化の仕組みと向き不向き、管理用WordPressと公開サーバーを分ける推奨構成、Simply Staticでの手順、静的化で動かなくなる機能の対処、更新フローまでを解説します。

WordPress静的化とは？WordPressをやめるのとは違う

WordPressの静的化とは、WordPressが動的に生成しているページをHTMLファイルとして書き出し、そのHTMLだけを公開サーバーに置いて表示させる手法です。WordPress本体は管理画面として残す点が、WordPressを完全に廃止してHTMLに戻す「html移行」との大きな違いです。

	WordPress静的化	WordPressからhtml移行
WordPress管理画面	残す（記事はWPで書く）	廃止する
公開サーバーの中身	HTML・CSS・画像のみ	HTML・CSS・画像のみ
更新方法	WPで編集→書き出し→同期	HTMLを直接編集
WP本体の保守	必要（管理用WPのみ）	不要
向いているサイト	更新を続けるサイト	更新がほぼないサイト

通常のWordPressは、アクセスがあるたびにPHPがデータベースを読んでページを組み立てます。このPHPとデータベースが公開サーバーで動いている状態が、脆弱性を突かれる原因です。

静的化すると公開サーバーにはPHPもデータベースもなく、WordPressの管理画面は別の場所にあるため、公開サイトが改ざんされるリスクを大幅に下げられます。

WordPressそのものをやめたい場合は、別記事「WordPressからHTMLへ移行する手順と注意点」を参照してください。

静的化に向いているサイト・向かないサイト

静的化は「更新は続けるが、動的な機能は使っていない」サイトに向いています。公開側でPHPが動かなくなるため、訪問者の操作に応じて何かを処理する機能は原則すべて使えなくなります。

向いているサイト

• 会社サイト・ブログ・オウンドメディアなど、閲覧が中心のサイト
• 記事やお知らせの更新は続けたいが、担当者はWordPressの編集画面しか使えない
• 過去にハッキング被害があり、公開面のリスクを根本から下げたい
• 表示速度を上げたい、アクセス集中に強くしたい

向いていないサイト

• 会員ログイン・マイページ・予約・決済・EC機能がある
• コメント、サイト内検索、絞り込み検索など訪問者の操作で結果が変わる機能が多い
• 投稿者が複数いて、1日に何度も更新・公開している
• WooCommerceなど、プラグインの動的機能がサイトの中心

会員機能やECがある場合は静的化ではなく、WordPressのまま保守体制とセキュリティ対策を固めるほうが現実的です。

【事例】動的な部分を洗い出せず、静的化を見送ったケース
アクセス集中への対策として、サーバーのスペックアップと静的化のどちらにするかを検討したご相談がありました。静的化すればシンプルなサーバー構成で負荷に耐えられる見込みでしたが、サイトのどこが動的に動いているかを制作会社と確認しきれず、不確定要素が大きいため静的化は見送りました。

どの機能がPHPで動いているかを把握できていないサイトは、静的化の判断自体ができません。まずは動的な機能の洗い出しから始めましょう。

===

「自社サイトが静的化に向いているか判断できない」という方は、サイト引越し屋さんにご相談ください。使っている機能を確認し、静的化とWordPressのまま保守する方法のどちらが合うかをご提案します。
→無料ご相談窓口はこちら

推奨構成：管理用WordPress＋公開用サーバーの2段構え

静的化の効果を最大にするには、「管理用WordPress」と「公開用サーバー」を物理的に分けるのがポイントです。同じサーバーの中で書き出すだけでは、WordPressの管理画面が引き続きインターネットに公開されたままになり、攻撃の入口が残ります。

役割	置く場所	アクセス制限	中身
管理用WordPress	非公開のサブドメイン、または別のレンタルサーバー	IPアドレス制限・ベーシック認証・検索エンジンからの除外（noindex）	WordPress本体・テーマ・プラグイン・データベース
公開用サーバー	本番ドメイン	制限なし（誰でも閲覧）	書き出したHTML・CSS・JavaScript・画像のみ

管理用WordPressの置き方

管理用WordPressは「admin.example.com」のような非公開サブドメイン、あるいは本番とは別の安価なレンタルサーバーに設置します。そのうえで、.htaccessによるIPアドレス制限やベーシック認証をかけ、社内や担当者のネットワークからしか開けないようにします。

検索エンジンに管理用サイトが拾われないよう、noindex設定も忘れずに行ってください。

Simply Staticは、サーバー自身から管理用WordPressにHTTPでアクセスしてページを書き出します。IP制限をかける場合はサーバー自身からのアクセスも許可し、ベーシック認証をかける場合はSimply Static側にも認証情報を登録してください（手順はステップ2で解説します）。

公開用サーバーの選び方

公開側はHTMLを配信できればよいので、PHPやデータベースが不要です。今使っているレンタルサーバーをそのまま使う場合は、WordPressを公開領域から外し、HTMLだけを置き直します。

表示速度やアクセス集中への強さを求めるなら、静的サイト向けのホスティングやCDN配信も選択肢になります。

同じサーバー内で静的化との違い

1台のサーバーでWordPressと書き出しHTMLを同居させる構成でも、公開ページ自体は静的になります。ただし管理画面のURLが公開されたままなら、ログイン画面への総当たり攻撃や脆弱性を突いた侵入のリスクは残ります。

公開サイトを守るだけでなく、管理画面も隠して初めて静的化のメリットが活きると考えてください。

【事例】日英2言語の会社サイトで静的化を設計したケース
サイト引越し屋さんで静的化を検討した日英2言語の会社サイトでも、この2段構えで設計しました。管理用WordPressは「admin.」から始まるサブドメインに移してアクセス制限をかけ、書き出したHTMLは「static.」から始まるサブドメインでベーシック認証付きで表示確認し、問題がなければ本番サーバーへFTPで反映する流れです。

一方で、このサイトは言語切り替えをPHPで実装していたため、「書き出したHTMLで言語切り替えが動くかは、一度出力してみないと分からない」という課題が出ました。独自のPHP処理が入っているサイトは、本番に進む前にテスト環境で一度書き出し、動作を確かめる工程を必ず入れてください。

===

管理用WordPressのサブドメイン設置やIP制限・ベーシック認証など、管理画面を隠す設定もサイト引越し屋さんにお任せください。構成の設計から公開サーバーの準備まで代行いたします。
→無料ご相談窓口はこちら

Simply Staticで静的化する手順

静的化プラグインの定番はSimply Staticです。
参考：Simply Static – 静的サイトジェネレーター｜WordPress.org

無料版でも全ページの書き出しとZIPダウンロードができ、まずは試してみるのに向いています。

無料版はサイト全体を毎回書き出す仕様で、出力先は「ZIPファイル」か「サーバー上の指定ディレクトリ」の2択です。公開サーバーへの転送は手動になります。

Pro版では更新したページだけの書き出し（Changes Only）、FTP/SFTP・GitHub・AWS S3・Bunny CDNなどへの自動デプロイ、フォーム・サイト内検索・コメントの静的対応が可能になります。更新頻度が週1回以上なら、Pro版の自動化で運用負荷が大きく下がります。

実装の手順は「インストール→URL設定→生成→公開サーバーへ配置」の4ステップです。以下の画面名・項目名は、2026年11月時点のSimply Static無料版（3.8系）にもとづいています。

1. Simply Staticをインストール・有効化
2. 書き出し先URLと形式を設定
3. 静的ファイルを生成
4. 公開サーバーへ配置して確認

ステップ1：Simply Staticをインストール・有効化

管理用WordPressの「プラグイン」→「新規追加」で「Simply Static」を検索し、インストール後に有効化します。事前に、パーマリンク設定が「?p=123」のような形式ではなく、スラッシュ区切りのURL構造になっていることを確認してください。

ステップ2：書き出し先URLと形式を設定

「Simply Static」→「Settings」→「General」タブの「Replacing URLs」で、書き出したHTML内のURLをどう置き換えるかを選びます。選択肢は「Absolute URLs」「Relative Path」「Offline Usage」の3つです。

管理用WordPressと公開サイトのドメインが異なる構成では、「Absolute URLs」を選び、SchemeとHostに公開ドメインを指定します。これで「管理用URL→公開用URL」の置換が行われます。

「Relative Path」はcanonicalやOGPのURLまで相対パスになるため、ルートドメインで公開するサイトには公式も推奨していません。「Offline Usage」はPC上で閲覧するための設定で、公開用ではありません。

管理用WordPressにベーシック認証をかけている場合は、「Settings」→「Debug」タブの「Basic Auth Username」「Basic Auth Password」に同じ認証情報を入力してください。Simply Staticは自分のサイトにHTTPでアクセスしてページを取得するため、認証情報がないとページを取得できません。

参考：How to replace URLs｜Simply Static Docs

ステップ3：静的ファイルを生成

左メニューの「Generate」画面で書き出しを開始すると、全ページ・画像・CSS・JavaScriptが書き出されます。ページ数が多いと数分〜数十分かかります。

出力先は「Settings」→「Deploy」タブで選び、無料版では「ZIP Archive」（ZIPでダウンロード）か「Local Directory」（サーバー上の指定ディレクトリに出力）のどちらかです。

書き出しの進み具合とエラーは「Activity Log」画面で確認できます。下部の「Export Log」にはURLごとのステータスコードが一覧で表示されるので、200以外のURLがないかを必ず見てください。

Simply Staticはステータス200以外のページを保存せずに書き出しを続けるため、エラーが出ても完了表示になることがあります。

【現場の注意点】書き出しが止まる・ファイルが抜けるときの対処

1. 書き出しが途中で止まる：無料版の書き出しはWP-Cronを使ったバックグラウンド処理で少しずつ進みます。アクセスの少ない管理用WordPressではWP-Cronが動かず、進まなくなることがあります。「Settings」→「Debug」タブの「Use server-side cron job」を有効にし、サーバーのcron設定からwp-cron.phpを定期実行してください。止まったまま動かない場合は「Cancel」で中断し、それでも解除されなければWP Crontrolプラグインで書き出しジョブ（wp_archive_creation_job_cron）を削除します。
2. 画像・フォントが抜ける：テーマやページビルダーがCSSの背景画像やJavaScriptで読み込む画像は、クローラーが見つけられず漏れることがあります。「Settings」→「General」タブのInclude欄で、URLなら「Additional URLs」、ファイルやフォルダなら「Additional Files and Directories」（こちらはURLではなくサーバー上の絶対パス）で追加指定します。
3. 「429」や「5xx」が大量に出る：短時間に多数のリクエストが届き、サーバーの制限に引っかかっている状態です。Simply Staticが一度に処理するURL数（初期値50）を、フィルター「simply_static_fetch_urls_batch_size」で減らすと落ち着きます。
4. 書き出したくないページが含まれる：テスト用ページや会員向けページは、同じくGeneralタブの「URLs to exclude」に指定して除外します。

書き出しがうまくいかないときは、まず左メニューの「Diagnostics」を開いてください。パーマリンク設定、検索エンジンのインデックス拒否設定、キャッシュ系プラグイン、WP-Cron、Basic Authなど、書き出しの失敗につながる項目をまとめて確認できます。

参考：Add missing pages/files to your static website｜Simply Static Docs

ステップ4：公開サーバーへ配置して確認

書き出したファイル一式を公開サーバーの公開ディレクトリにアップロードします。トップページ・下層ページ・画像・内部リンクが正しく表示されるか、スマートフォンでも崩れがないかを確認してください。

あわせて、次の4点も公開直後に確認しておくと安心です。

• ページのソースに管理用WordPressのURL（例：admin.example.com）が残っていないか
• canonical・OGPのURLが公開ドメインになっているか
• XMLサイトマップとrobots.txtが公開サーバーにあるか（AIOSEO・Yoast等は「Settings」→「Integrations」で連携を有効にすると書き出し対象になります。出力されない場合は「Additional URLs」に追加）
• 存在しないURLにアクセスしたとき、404ページが表示されるか（「Generate 404 Page?」の設定で書き出せます）

【事例】参照パスが元の環境のまま残り、デザインが崩れたケース
静的サイトをご自身で別のサーバーへ移したところ、デザインが大きく崩れたというご相談がありました。ファイルはすべてアップロードされていましたが、HTML内のCSS・JavaScript・画像の参照先が書き出した環境のパスのまま残っていたため、スタイルも画像も読み込まれない状態でした。

静的化でも同じことが起こります。ステップ2のURL置換設定と、上記の「管理用URLが残っていないか」の確認は省かないでください。

===

Simply Staticでの書き出しや公開サーバーへの配置がうまくいかないときは、サイト引越し屋さんにお任せください。リンク切れや表示崩れの確認まで含めて作業を代行いたします。
→無料ご相談窓口はこちら

静的化で動かなくなる機能と代替方法

公開側でPHPが動かなくなるため、訪問者の操作に応じて処理を行う機能は使えなくなります。静的化を決める前に、サイトで使っている機能を次の表で確認してください。

動かなくなる機能	理由	代替方法
お問い合わせフォーム（Contact Form 7等）	送信処理がPHP	Googleフォーム／formrun等の外部フォームを埋め込み、またはSimply Static Proのフォーム対応
サイト内検索	検索処理がデータベース	静的検索ライブラリ（Pagefind等）、Googleのプログラム可能な検索エンジン（無料版は広告表示あり）、またはSimply Static Proの検索機能
コメント機能	投稿処理がPHP	廃止、外部コメントサービス、またはSimply Static Proのコメント対応
会員ログイン・マイページ	セッション管理がPHP	静的化の対象外（WordPressのまま運用）
新着記事の自動表示	書き出し時点で固定	更新のたびに書き出せば反映される
関連記事・人気記事ウィジェット	アクセス集計がPHP	書き出し時点の内容で固定、または廃止
プレビュー・下書き確認	公開側には存在しない	管理用WordPress側で確認

お問い合わせフォームは、ほぼすべてのサイトで使っている機能なので、静的化の最初の検討事項です。外部フォームに切り替える場合は、スパム対策と送信通知先の設定を忘れずに行ってください。

お問い合わせフォームを外部フォームに置き換える手順

Contact Form 7などのフォームは、管理用WordPress側の固定ページからショートコードを削除し、外部フォームの埋め込みコードに差し替えます。送信処理は外部サービス側で完結するため、公開サーバーにPHPがなくても動作します。差し替えたら書き出し直し、公開サイトで実際に送信テストを行ってください。

• Googleフォーム：フォームを「公開」状態にしたうえで、編集画面右上の「その他」メニュー→「HTMLを埋め込む」でコードを取得し、固定ページに貼り付けます。無料で使えますが、デザインはGoogleフォームの見た目のままです。ファイル添付の質問を入れると、回答者にGoogleアカウントへのログインが求められる点に注意してください。
• formrun：フォームの設定画面「埋め込み」で、埋め込み先のURLを登録してからスクリプトまたはiframeのコードをコピーして貼り付けます。プルダウンの選択肢が多いフォームはiframeで高さを大きめに取ると崩れにくくなります。FREEプランは1フォームあたり月30件の回答までで、超えるとフォームが非公開になるため、問い合わせが多いサイトは有料プランを前提にしてください。

デザインを既存サイトと完全に揃えたい場合は、自作のHTMLフォームの送信先を外部サービスに向ける方式（formrunのコード型フォーム等）がありますが、formrunではFREEプランだと有料オプションが必要です。

参考：Googleフォームの埋め込み方法｜Google ドキュメント エディタ ヘルプ
参考：フォームの共有・埋め込み方法｜formrun ヘルプ

サイト内検索の代替を選ぶ基準

サイト内検索は、記事数と「広告を出してよいか」で選ぶのが実務的です。

• Pagefind：書き出したHTMLを読み込んで検索用のインデックスを作るツールです。書き出し後に「npx -y pagefind –site 出力フォルダ」を実行すると「/pagefind/」フォルダが作られ、検索窓のパーツを埋め込めば動きます。広告は出ず、サーバー側の処理も不要です。ただし書き出しのたびにインデックスの作り直しが必要なので、更新フローに1工程加わります。
• Googleのプログラム可能な検索エンジン：コードを貼るだけで導入できますが、無料版は検索結果に広告が表示されます。Googleにインデックスされていないページは検索結果に出ません。
• Simply Static Pro：WordPress側の設定だけで検索機能（Fuse.js／Algolia）を追加できます。Pro版を導入するなら最も手間がかかりません。

記事数が少なく検索がほとんど使われていないサイトは、検索窓を廃止してカテゴリーやタグからの導線に切り替えるのも選択肢です。

参考：Pagefind Docs

静的化後の運用フロー：更新のたびに「書き出し→同期」

静的化後は、WordPressで記事を保存しただけでは公開サイトに反映されません。「管理用WordPressで編集→静的ファイルを書き出し→公開サーバーへ同期」という3ステップが更新のたび必要になります。

この一連の作業を実行しないと、「更新したのに反映されない」という現象が発生します。

1. 管理用WordPressで記事を作成・編集し、公開状態にする
2. Simply Staticで静的ファイルを生成する（Pro版なら更新ページのみ）
3. 生成したファイルを公開サーバーへアップロード・同期する（Pro版なら自動デプロイ）
4. 公開サイトで表示を確認する

複数人で更新する場合の注意

Simply Staticは書き出し中にロックがかかるため、同時に2人が書き出すことはできません。また標準の設定では、書き出しは「編集者」以上の権限で実行でき、設定画面は「管理者」のみが操作できます。

複数の投稿者がいる場合は、「書き出しは1日1回、担当者がまとめて行う」といった運用ルールを決めるか、Pro版のユーザー権限管理（UAM）や自動化で、書き出しできる人と手順を絞ってください。

管理用WordPressの保守は引き続き必要

公開側は安全になりますが、管理用WordPressは通常のWordPressです。本体・テーマ・プラグインの更新、バックアップ、PHPバージョンの管理は変わらず必要です。IP制限で守られているとはいえ、古いまま放置すればプラグインの脆弱性からログイン情報が漏れる可能性はあります。

===

静的化後の管理用WordPressの更新・バックアップ・PHP管理は、サイト引越し屋さんの保守管理でまとめてお引き受けできます。更新のたびの書き出し・同期作業もお気軽にご相談ください。
→無料ご相談窓口はこちら

静的化のメリット・デメリット

静的化は万能ではありません。得られるものと失うものを整理したうえで判断してください。

メリット	デメリット
公開サーバーにPHP・DBがなく、WordPressの脆弱性攻撃が届かない	更新のたびに書き出し・同期の手間が発生する
サーバー側でPHP・DBの処理がなくなるため応答が速く、アクセス集中に強い	フォーム・検索・会員機能など動的機能が使えない
公開サーバーは安価なプランやCDNで済む	管理用WordPressの保守は引き続き必要
公開サイトが改ざんされても、書き出し直せば復旧できる	複数人運用には権限・ルール設計が必要
公開ドメインからログイン画面がなくなり、総当たり攻撃の的にならない	管理用と公開用の2環境を管理する必要がある

WordPress静的化のよくある質問

静的化するとSEOに影響はありますか？

URL構造を変えなければ、検索順位への直接的な悪影響はありません。Googleは、Core Web Vitals（表示速度などの指標）をランキングで考慮する要素の一つとしていますが、優先されるのはあくまでコンテンツの関連性です。静的化で表示が速くなっても、それだけで順位が上がるとは考えないでください。

ただし、書き出し時にメタタグ・サイトマップ・canonicalが正しく出力されているか、noindexが意図せず付いていないかは確認してください。

Simply StaticはSEOプラグインがページに出力するメタタグを含めて書き出すため、基本的には引き継がれます。XMLサイトマップは「Settings」→「Integrations」でSEOプラグインとの連携を有効にしておきましょう。

参考：Core Web Vitals と Google 検索の検索結果について｜Google 検索セントラル

管理用WordPressの保守は不要になりますか？

不要にはなりません。公開面の攻撃リスクは大幅に減りますが、管理用WordPressは引き続き本体・プラグインの更新とバックアップが必要です。保守の対象が「公開サイト＋管理画面」から「管理画面のみ」に絞られる、と理解してください。

今のレンタルサーバーのままでも静的化できますか？

できます。同じサーバー内で、WordPressを非公開ディレクトリやサブドメインに移し、公開ディレクトリにはHTMLだけを置く構成が可能です。ただし管理画面へのIP制限やベーシック認証は必ず設定してください。

静的化とWordPressをやめてHTMLに移行はどちらが良いですか？

今後も記事やお知らせを更新し続けるなら静的化、更新がほぼないなら完全移行です。判断に迷う場合は、直近1年の更新回数を数えてみてください。年に数回程度なら完全移行のほうが管理が楽です。

【事例】更新頻度の低い士業サイトのご相談
2026年10月にPHPの脆弱性が報じられたことをきっかけに、「WordPressをやめて静的HTMLに移行したい」というご相談をいただきました。更新はお知らせをときどき出す程度、問い合わせはGoogleフォームという、静的化やhtml移行に向いた条件のサイトです。

ただし100ページを超える規模で、全ページを手作業でHTMLに作り直すと費用が大きくなるため、このケースではテーマ変更とWordPressのバージョンアップのほうが費用を抑えられるとご案内しました。

ページ数が多いサイトは、手作業のhtml移行だけでなく、Simply Staticなどで書き出す静的化や、WordPressのまま保守する方法とも比較して判断するのがおすすめです。

まとめ：静的化は管理画面を隠すまでが一式

WordPressの静的化は、管理画面はこれまでどおり使いながら、公開サイトからPHPとデータベースをなくす手法です。WordPressを廃止するhtml移行と違い、記事の更新を続けるサイトに向いています。

効果を出すには、管理用WordPressを非公開のサブドメインや別サーバーに置き、IP制限やベーシック認証で隠したうえで、公開サーバーにはHTMLだけを置く2段構えが基本です。お問い合わせフォームや検索など動かなくなる機能は事前に洗い出し、外部サービスへ置き換えてください。

静的化後も管理用WordPressの保守は必要です。公開面の攻撃リスクを下げつつ、管理用WordPressの保守に集中する構成として、サイト引越し屋さんでは設計から移行、その後の保守までご相談いただけます。