【ロリポップ×WordPress】最小構成で速さ・セキュリティ・SEOを両立する(①:方針と設計)
この間、ロリポップ(ハイスピード/エンタープライズ=LiteSpeed環境)でブログを移行しました。これまで使っていたプラグインを整理していたところ、「速くしたいが、プラグインは増やしたくない」「セキュリティは最低限で十分にしたい」という相反する願望が出てきました。そこで、最小構成で入口の安全性とSEO、体感速度を両立させるようにしました。本文ではその方針と設計を整理します。
TL;DR
- セキュリティはWAF(Web Application Firewall)+2FA(二要素認証)+ログイン試行制限で十分。
- SEOのサイトマップは /wp-sitemap.xml(WordPress標準)でOK。
- 画像やキャッシュはLiteSpeed Cache(LSC)に一本化
なぜ最小構成にしたいか(事故・脆弱性・運用コスト)
WordPressは拡張が容易です。しかし、プラグインを重ねるほど更新互換性の問題や脆弱性露出の確率が上がります。実際に、人気プラグインの深刻な欠陥が定期的に報告され、放置すると乗っ取りに至るケースも珍しくありません。だからこそ、役割が重複するプラグインは統合し、“必要最低限”だけを堅牢に保守するのが合理的です。方針は、安全は入口で止め、速度はサーバーに任せるというシンプルな設計です。
セキュリティ対策
ロリポップWAFをONにして運用
まずはWAFです。WAFは不正リクエストをアプリケーションの手前で遮断する仕組み。プラグインより先に防いでくれるため、WordPress本体やテーマ・プラグインに負担をかけません。ロリポップではユーザー専用のWAF設定画面が用意されており、運用自体はONのままが基本。万一、管理画面の保存や特定のプラグイン操作で誤検知が起きた場合は、該当URLだけ除外にします(全体OFFに戻さない)。ハイスピード/エンタープライズ環境でも、WAFの有効・無効切替や基本運用は可能です。
WAFでネットからの攻撃を構造的に遮り、サイト側の複雑な防御(多機能セキュリティプラグイン)を減らします。
2FA(二要素認証)+ログイン試行制限(ブルートフォース防止)
2FA(二要素認証)は、パスワードに加えて時限式ワンタイムコード(TOTP)などを要求する仕組みです。仮にパスワードが漏れても、二段目の認証で踏み止まります。公式のTwo-Factorプラグインは、ユーザープロファイル画面からTOTPなどを簡単に有効化できます。管理者アカウントには必ず適用しておくのが現実的です。
ログイン試行制限は、短時間に何度もログインを試す攻撃(ブルートフォース)を無力化します。Limit Login Attempts Reloaded は、一定回数の失敗後に同一IPやユーザー名を自動ロックし、負荷と侵入リスクを下げます。WordPressは標準だと試行回数に上限がないため、この一点だけでも価値が高いです。
入口での本人性確認と試行の制御を足す。これでログイン面のリスクは劇的に下がります。
XML-RPCを無効化(使わないなら)
XML-RPCは、初期のWordPressが外部アプリと通信するためのリモート実行API(例:モバイルアプリからの投稿、古いピンバック機能など)です。昔のモバイルアプリやデスクトップブログエディタ(MarsEdit等)がこれで記事投稿・編集をしていました。これが総当たり攻撃の温床になりやすく、現在はREST APIが主流でXML-RPCを必要としないサイトも増えているため、いま外部からの投稿やJetpack連携を使っていないなら止めた方が安全です。止め方は2つ。
- プラグインでOFF(“Disable XML-RPC”など)
- .htaccessで遮断(Apache/ロリポップ想定)
<Files "xmlrpc.php"> Require all denied </Files>
# 使っていないなら xmlrpc.php を閉じる(Apache 2.4)
<Files "xmlrpc.php">
Require all denied
</Files>もしJetpackや古い外部クライアントを使っていないなら、xmlrpc.php へのアクセスを遮断しておくと安全です。.htaccess で特定ファイルを拒否するのが簡単で、アプリケーション層まで処理が届かなくなります。
SEO対策
サイトマップはWordPress標準に一本化
WordPress 5.5以降は、/wp-sitemap.xml をコアが自動で出力します。外部プラグインを使わなくても、記事・固定ページ・タームなどのURLを基本形のサイトマップとして公開できます。まずはこれをGoogle Search Consoleに登録します。
サイトマップは検索エンジンに公開範囲と更新状況を正確に伝える効果があり、インデックスの安定に寄与します。
Search Console → サイトマップ → 追加
URL: https://あなたのドメイン/wp-sitemap.xml追加プラグインを足さない理由
多機能なSEOプラグインは便利ですが、“サイトマップだけのために”導入するのは過剰です。コア機能で十分な場面に大きなプラグインを加えると、キャッシュや最適化との干渉も起きやすくなります。WordPressテーマだけでもブログであれば十分な対策ができますし、メタ情報やパンくず、構造化データがテーマや手動で賄える範囲であれば、サイトマップは標準一本化が合理的でした(必要になったら後付けで拡張)。
表示速度対策
サイトを軽量化しても、表示が重い・挙動が不安定という体感の悪さが残る場合があります。多くはプラグインの重複キャッシュや古いテーマのJavaScriptが原因です。キャッシュはLiteSpeed Cache(LSC)に寄せて、他の高速化系は止めるか重複機能を解除します。LSCはLiteSpeedサーバーと一体で画像の最適化(WebP/AVIF)や差し替え配信も担えます。ハイスピード/エンタープライズ環境であったので、まずLSCをベースに置きました(導入手順とUIはロリポップのマニュアルを参照)。
参考:LSCの「Image Optimization」では、メディアライブラリをスキャンしてWebP/AVIFを生成・配信できます。非対応ブラウザには自動で元画像を返すため、後方互換も確保されます。最初は画像最適化だけから始めるのが安心です。
全体像
[Internet]
│ 攻撃・クローラ・ユーザー
▼
[WAF(ロリポップ前段)] ← 不審リクエストはここで遮断
│(正当な通信のみ通過)
▼
[WordPress 本体]
├─ [2FA(Two-Factor)] …… 管理者ログインの本人性を強化
├─ [Limit Login Attempts] … ブルートフォース対策(試行制限)
├─ [xmlrpc.php 無効化] …… 使わなければ入口を閉じる
└─ [wp-sitemap.xml] ……… 検索エンジンに公開範囲を伝える
└─ [LiteSpeed Cache(LSC)] …… 画像最適化/キャッシュはここに一本化| 機能 | 推奨 | 代替/補足 | ねらい |
|---|---|---|---|
| 二要素認証(2FA) | Two-Factor | 他2FAでも可 | パス漏えいでも踏み止まる |
| ログイン試行制限 | Limit Login Attempts Reloaded | — | 無制限試行の穴を塞ぐ |
| WAF | (ロリポップ標準機能) | URL単位で例外調整 | 最前列で遮断、アプリ側を軽く |
| サイトマップ | (WP標準)/wp-sitemap.xml | Search Consoleに登録 | 発見性の補助(順位を直接は変えない) |
| 画像/キャッシュ/最適化 | LiteSpeed Cache | 他の最適化系と重複させない | サーバー親和性が高く壊れにくい |
| XML-RPCの遮断 | .htaccess など | Jetpack等が必要なら例外 | 使わない入口は閉じる(古い攻撃面の削減) |
本稿は方針と基本設計に絞りました。次回(②)は、同じ環境で私が実際にハマった「LSCの設定で表示が崩れる」という問題を安全プリセットで回避しつつ、画像→圧縮→JS遅延→CSS最適化の順にPageSpeed Insights(PSI)/Core Web Vitals(コアウェブバイタル)を安定させる手順をまとめます。
ソース&日付(取得日:2025-10-18, JST)
- ロリポップ|WAF設定と運用(公式マニュアル). ロリポップ!レンタルサーバー
- ロリポップ|LiteSpeed Cache(LSC)/ハイスピード環境の案内. ロリポップ!レンタルサーバー+1
- LiteSpeed Tech Docs|LSC Image Optimization(WebP/AVIF配信の仕様). docs.litespeedtech.com
- WordPress 5.5|コアのXMLサイトマップ機能(Make/Core). Make WordPress
- Google Search Central|サイトマップの作成と送信. Google for Developers
- WordPress.org Plugins|Two-Factor(公式2FA), Limit Login Attempts Reloaded(試行制限). WordPress.org+1
- XML-RPCの背景と無効化の考え方(業界解説・参考). BlogVault+1
- プラグイン脆弱性の例(最小構成の動機付けの一次情報). TechRadar













ディスカッション
コメント一覧
まだ、コメントがありません