はじめに
WordPressを運用する場合、単にサイトを公開できればよいわけではありません。
安全に更新できること、保守の手間を増やしすぎないこと、脆弱性対応を止めないことが重要です。
この記事では、WordPressをクリーンインストールし、運用に耐える初期構成まで整える手順をまとめます。
対象読者
- WordPressの導入を検討している方
- WordPressを作って終わっている方
- WordPressのセキュリティ対応を検討している方
- WordPressの保守の手間を減らしたい方
採用する基本方針
セキュリティ方針
- WordPress本体・テーマ・プラグインは改変しません
- 管理画面の入口を複数の層で守ります
- SiteGuard WP Pluginを必須にします
- 2FAを必須化します
- 不要なテーマ・プラグインは削除します
-
xmlrpc.phpは原則無効化します -
uploads配下でのPHP実行を禁止します
テーマ方針
- 親テーマは直接編集しません
- カスタマイズは子テーマで行います
- 将来のテーマ変更を見越して、子テーマ依存を最小化します
- 独自機能は、必要に応じて小さな追加プラグインで分離します
WordPress本体・プラグイン・テーマを(なるべく)カスタマイズしない理由は、脆弱性対応などによるWordPressのアップデート作業をしやすくするためです。
それにより、セキュリティを高く保ち、ランニングコストを抑えた構成を目指します。
1. WordPressのインストール手順
1-1. サーバーとドメインを準備する
まずレンタルサーバー側で次を準備します。
- ドメイン設定
- SSL証明書の有効化
- データベース作成
- WordPressインストール先ディレクトリの確認
- PHP・MySQLの要件確認
WordPressのインストール前に、サーバー要件を満たしていることを確認します。
HTTPS対応、適切なPHPバージョン、DB設定は先に済ませておくと、後戻りが少なくなります。
WAF(Web Application Firewall)が利用可能であれば、導入することをおすすめします。
1-2. WordPressをインストールする
手順
-
公式サイトから最新版をダウンロードします。
-
ダウンロードしたWordPressファイル(ZIPファイル)を解凍し、FTPなどでアップロードします。
ドキュメントルートにアップロードしてください。 -
- サイト名
- ユーザー名
- パスワード
- メールアドレス
-
WordPressをインストールします。
-
ログインできれば、インストール作業は完了です。
- ユーザー名は
adminを使いません - パスワードは長くし、使い回しません
インストール後は放置せず、すぐにWordPressの初期設定に進みます。
多くのレンタルサーバーには、簡単インストール機能があります。
初回導入ではそれを使っても問題ありません。
その場合は、本手順はスキップします。
※簡単インストール機能については、各レンタルサーバーのマニュアルをご参照ください。
2. WordPressの初期設定
2-1. 一般設定
WordPress管理画面で「設定」→「一般」から以下を設定します。
- サイトタイトル
- キャッチフレーズ
- WordPressアドレス
- サイトアドレス
- 管理者メールアドレス
2-2. パーマリンク設定
おすすめは投稿名です。
手順
- WordPress管理画面で「設定」→「パーマリンク」を開きます。
- 「投稿名」を選択します。
- 保存します。
2-3. コメント設定
大半のWebサイトでは、不要なコメントは無効化してよいケースが多いです。
手順
- WordPress管理画面で「設定」→「ディスカッション」を開きます。
- 「新しい投稿へのコメントを許可する」のチェックを外します。
- 保存します。
推奨
- コメントを使わないなら無効化します
- 使う場合も承認制・制限を検討します
3. 子テーマを用意する
オリジナルテーマを利用する場合は、ステップ3は飛ばします。
ただし、セキュリティアップデートなどはご自身でテーマの更新を行います。
3-1. 子テーマを使う理由
親テーマを直接編集しないため、テーマ更新時にカスタマイズを失わないようにします。
子テーマは、親テーマとは別のディレクトリに作成します。
その中に style.css と functions.php を新規作成し、親テーマのスタイルや必要な設定を引き継ぎます。
既存の親テーマファイルを上書きするのではなく、子テーマ側に追加するイメージです。
例:親テーマが twentytwenty を利用する場合
wp-content/themes/
├─ twentytwenty/
└─ twentytwenty-child/
├─ style.css
└─ functions.php
メリット
- 親テーマ更新に強い
- カスタマイズを保持できる
- テーマ変更がしやすい
- 更新作業の心理的コストが下がる
3-2. 子テーマの作成
子テーマは通常、次の2ファイルで構成します。
style.cssfunctions.php
例: style.css
/*
Theme Name: My Child Theme
Template: parent-theme-folder-name
Version: 1.0.0
*/
「parent-theme-folder-name」には、親テーマのディレクトリ名を記述してください。
例:親テーマが twentytwenty を利用する場合
Template: twentytwenty
例: functions.php
<?php
add_action('wp_enqueue_scripts', function () {
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
wp_enqueue_style('child-style', get_stylesheet_uri(), ['parent-style'], '1.0.0');
});
注意
-
Templateには親テーマのフォルダ名を入れます - 子テーマで同名関数を定義する場合は衝突に注意します
- 独自機能は子テーマに書きすぎません
3-3. テーマ変更しやすくする設計
将来的にテーマを入れ替える可能性があるなら、次の方針が有効です。
- レイアウト依存の処理を子テーマに寄せます
- 業務ロジックは追加プラグインに寄せます
- 固有の見た目はCSSで吸収します
- テーマの機能に依存しすぎません
4. .htaccess の基本防御
ルート直下の .htaccess に、WordPressの標準ルールを残しつつ、必要な防御を追記します。
4-1. ディレクトリ一覧を無効化します
Options -Indexes
4-2. wp-config.php を保護します
<Files wp-config.php>
Order deny,allow
Deny from all
</Files>
4-3. xmlrpc.php を無効化します
<Files xmlrpc.php>
Order deny,allow
Deny from all
</Files>
注意
- Jetpackなど、XML-RPCを使うプラグインを利用している場合は影響があります
- 依存がある場合は、無効化前に確認します
4-4. 常時SSLを有効化します
手順
- WordPressの「設定」→「一般」でURLを
https://に変更します。 -
.htaccessにHTTP→HTTPSリダイレクトを設定します。
例
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
4-5. uploads 配下でPHPを実行禁止にします
wp-content/uploads/ に .htaccess を作成します。
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
5. 管理画面の入口を守る
5-1. Basic認証を設定します
ルート直下の .htaccess で、wp-login.php に対してBasic認証をかけます。
<Files wp-login.php>
AuthType Basic
AuthName "Restricted Area"
# /full/path/to/ には、サーバー上のフルパスを指定してください
AuthUserFile /full/path/to/.htpasswd
Require valid-user
</Files>
手順
-
.htpasswdを作成します。 -
.htpasswdをWeb公開領域の外に置きます。 -
AuthUserFileの絶対パスを設定します。 -
wp-login.phpにアクセスして認証が出ることを確認します。
5-2. IP制限を設定します
ルート直下の .htaccess で、wp-login.php に対して固定IPからのみアクセスを許可します。
<Files wp-login.php>
Order deny,allow
Deny from all
Allow from x.x.x.x
</Files>
注意
- IPが変動する環境では運用しづらいです
- 管理者はVPN経由に寄せる運用も現実的です
6. 必須プラグインの導入
ここでは、おすすめするプラグインと設定をご紹介します。
ご利用環境や仕様に合わせて、設定を変更します。
6-1. SiteGuard WP Plugin を導入します
今回の構成では、SiteGuard WP Pluginを必須にします。
導入理由
- ログインページURL変更
- 画像認証
- ログインロック
- ログインアラート
- 管理ページアクセス制限
これらをまとめて扱えるため、企業運用での初期防御に向いています。
手順
- WordPress管理画面へログインします。
- 「プラグイン」→「新規追加」を開きます。
-
SiteGuard WP Pluginを検索します。 - インストールします。
- 有効化します。
重要
- 有効化後、ログインURLが変更されます
- 新しいURLを必ずブックマークします
- 旧URLを忘れるとログインできなくなるため注意します
推奨設定
- 管理ページアクセス制限: 必要に応じて有効
- ログインページ変更: 有効
- 画像認証: 有効
- ログイン詳細エラーメッセージの無効化: 有効
- ログインロック: 有効
- ログインアラート: 有効
- XMLRPC防御: 有効
- 更新通知: 有効
注意
- ほかのセキュリティプラグインと機能重複しないようにします
- 画像認証には、サーバー環境によって
mbstringとgdが必要な場合があります - マルチサイトには非対応です
- SiteGuard自体の更新は必ず追います
6-2. WP 2FA を導入します
導入理由
- 2要素認証を必須化して不正ログインのリスクを下げます
- 管理者や編集者のログインセキュリティを強化します
- 認証アプリやメール認証に対応しており、導入しやすいです
手順
- 「プラグイン」→「新規追加」を開きます。
-
WP 2FAを検索します。 - インストールします。
- 有効化します。
推奨設定
- 「2FA ポリシー」→「方式を選択」:2FAアプリのワンタイムコード
- 「2FA ポリシー」→「2FA を強制」:すべてのユーザー
- 「2FA ポリシー」→「猶予期間」:ただちに 2FA 設定をユーザーに求める
6-3. WP Activity Log を導入します
導入理由
- サイト上の操作履歴を記録して監査性を向上します
- 不正操作の検知や原因調査に利用できます
- ログイン、投稿、プラグイン、テーマなどの変更履歴を残せます
手順
- 「プラグイン」→「新規追加」を開きます。
-
WP Activity Logを検索します。 - インストールします。
- 有効化します。
推奨設定
7. 不要テーマ・不要プラグインの削除
手順
- 使っていないプラグインを削除します。
- 使っていないテーマを削除します。
- テスト用アカウントも削除します。
無効化だけでは不十分です。
使わないものは削除します。
8. wp-config.php の保護
8-1. ファイル編集を無効化します
wp-config.php に追加します。
define('DISALLOW_FILE_EDIT', true);
8-2. 必要ならファイル変更も止めます
本番運用を厳格化したい場合は、以下も検討できます。
define('DISALLOW_FILE_MODS', true);
注意
- これを入れると、管理画面からのプラグイン更新やインストールも制限されます
- 更新運用を別フローで行う前提です
8-3. パーミッションを設定します
推奨は次のいずれかです。
-
wp-config.php→400 -
wp-config.php→440 - 共有サーバーでは
600を使うこともあります
インストール作業は以上です。
9. セキュリティアップデート時の作業手順
WordPress、プラグイン、テーマは自動更新を行うことができます。
しかし、自動更新を設定すると、事前に動作確認を行えず、意図しない動作不良やエラーが発生するおそれがあります。
そのため、自動更新はおすすめしません。
参考までに、WordPressのセキュリティアップデートを行う際の手順を紹介します。
9-1. 更新前にやること
WordPressのセキュリティアップデートを行う前に、必ずバックアップを取得します。
そのうえで、テスト環境で更新を試し、本番に影響しないことを確認します。
更新前に確認すること
- WordPress本体
- プラグイン
- テーマ
- PHPバージョン
- 既知の脆弱性情報
- 互換性情報
9-2. テストで確認します
テスト環境は、本番と同じ構成で更新を試せる検証用サイトです。
本番に反映する前に、次を確認します。
- 表示崩れがないか
- フォームが動くか
- ログインできるか
- 管理画面が開くか
- 主要プラグインが動くか
- セキュリティ設定が残っているか
9-3. 本番に反映します
テストで問題がなければ、本番に反映します。
本番反映後は、次を確認します。
- トップページ
- 下層ページ
- 管理画面
- フォーム送信
- パーマリンク
- ログ出力
9-4. 問題が起きたときの戻し方
問題が起きたら、事前のバックアップから復元します。
戻し方
- DBを戻します
-
wp-contentを戻します - 必要に応じて
wp-config.phpと.htaccessを確認します - 再度表示とログインを確認します
9-5. 更新後の確認
更新後は、次を確認します。
- サイトが正常表示される
- 管理画面にログインできる
- SiteGuardが動いている
- 監査ログが残っている
10. この構成のおすすめポイント
セキュリティ
- SiteGuardを必須化してログイン防御をまとめます
- 2FAで認証を強化します
- 監査ログを残します
-
xmlrpc.phpを止めます -
uploadsのPHPを止めます
運用コスト
- 子テーマ前提でテーマ変更しやすくします
- 親テーマを直接触らないので更新しやすくします
- 機能を専用プラグインに分散し、責務を明確化します
脆弱性対応
- コア・テーマ・プラグインを素直に更新できます
- 独自改造が少なくなります
- 戻しやすくなります
- 影響範囲が分かりやすくなります
まとめ
大手企業向けのWordPressは、SiteGuard WP Pluginを必須にしつつ、子テーマ運用でテーマ変更と更新をしやすくするのが実務的です。
これにより、ログイン防御をSiteGuardに集約し、親テーマ更新による上書きを避けながら、脆弱性対応を安全に回せるようになります。
この記事が、誰かのお役に立てば幸いです。













