【スコア改善】お金をかけずにWordPressをCloudflareで高速化する手順
長い間、さくらインターネットでWordPressを運用し続け、少しでも安いプランで高速化チューンを行いつつ、セキュリティを確保しながらSEO対策をしたいと思い、チューニングを続けてきました。しかしこれらチューニングでもいよいよ、改善の余地がなくなってきた。
ということで、色々調べてCloudflareのCDNを入れることで、壁を突破できそうだったので、取り組んでみました。Pagespeed InsightやGTMetrixのスコア改善にも繋がり、取り組む価値アリです。
今回利用する素材
これまでのチューニングは外部のCDNを使わず、自身のレンタルサーバの設定やWordPressのプラグインを利用して、高速化やページスコアの上昇に着目して行っていました。しかし、レンタルサーバの制限という壁やそのスペックの限界、設定を弄るだけで上昇する余地がなくなってきたものの、予算があるわけじゃないので上位のサーバーにプラン変更というのもままならないのが現実です。
そこで、今回はいよいよ外部のCDNを使うことでこれらの壁を突破し、技術のみで現状の環境を維持しつつ更なるチューンで少しでもSEOスコアをアップさせようというのが目論見です。もちろん必要なのは時間と腕で利用コストは無償です。
CDNで高速化はこれだけ変わる
スピードアップに勝るSEO対策無し
過去に作成した以下のWordPressのスピードチューニングのブログ記事にも記載していますが、ブログ記事の中身を充実させるのは当然のこととして、SEO対策で何よりも重要なのは応答性。つまりスピードアップ。サーバースペックが低いが為に応答性が悪いと人は待たずに去っていきます。
銀行のATMなどは3秒を最大値として応答するよう設計されてるのは、人が待てるのがおおよそ3秒までだそうで。当然CLSといったレイアウト崩れもユーザー体験を損ないます。そこでCloudflare連携をいれることでサーバースペック問題をCDN側で任せて回避し、高速化したことでLCPやCLSといった指標が改善。
結果、ユーザが去っていくのを防ぐことが出来、アクセス数が増加→Google検索でも有利に働くという流れです。自身のサイトを閲覧していてAnalyticsの数値の伸び悩みや、応答性悪くてイライラするという問題はここに課題があります。けれどお金掛けないと実現できないのか?といったらそういうわけじゃありません。
今回の手法はノーコストです。自分の手を動かす分の労賃は必要ですけれど。ここに拘っています。
結果に大きい変化
WordPressとCloudflareの連携の手順は結構ハードルが高めですが、自身のサイトは連携前のPagespeed Insightの結果は以下のような状態でした。
- デスクトップは90点のスコアは出せてもLCPでどうしても数値が悪いまま(サーバースペックがボトルネック)
- モバイルは常に60点、最悪の場合には40点を下回るケースも出てきていた
- セキュリティ重視でWAFを入れた結果、GZIPが使えなくなりパフォーマンス向上が袋小路になっていた。
今回、思い切ってCloudflare連携を導入したことにより、モバイル側もPC側も結果は99点、一気に指標類が改善。もちろん、コンテンツのページではもう少し下がりますが、それでもこれまでのような中空で漂ってる状態ではなくなりだいぶ余裕が出ました。もう少しCloudflare側での設定を加えれば更にスコアに余裕が出るかもしれません。
これによりSearch Consoleのウェブに関する主な指標に於いて、モバイル側のCLSの評価が真っ赤な状態であるのが治るかを経過観察してみたいと思います。とりあえず修正をクリックしておきましたので、数週間後にどれくらい改善されたのかを見てみたいと思います。
図:スコア劇的に上昇
図:スピード指標も改善しました
導入メリット
導入結果として、ユーザーはブログにアクセスしてもCDN経由でアクセスすることになるため、レンタルサーバの負荷が大幅に下がります。Adsenseが無効になるであったりAnalyticsが無効になることもありません。常にCloudflareのキャッシュから払い出されるのでレンタルサーバのスペックが低くても、Pagespeed Insightのスコアも大幅に上昇します。非常にメリットが高いですが、手間とリスクが伴うので注意は必要です。(AIのクローラーボットも排除することが可能です)。
特にこれまでWP Fastest CacheでのHTML, CSS, JSのチューンをしていても効果が薄かったのはサーバーのスペックが高くない為、どうしてもスコアがここで落ちていたのが改善。
更に追加のメリットとして、Cloudflare側のWAFが使えるようになるためセキュリティもアップし、さくら側がダウンしていてもCloudflare側からキャッシュ払い出される為、サイトの可用性がアップします。結果、レンタルサーバ側を増強しなくても良いので、コストアップをせずにパフォーマンスだけアップさせるという結果を得ることが出来ました。
※ウェブ転送量が半分になり、だいぶ余裕が出てきました。CPU時間はそこまで変わっていないのはHTMLは動的に生成してるため。
※さくら側でのWAFの検出ログがCloudflare導入後ゼロになりました。ほぼCloudflare側で弾けてるのでかなり外部からの攻撃にも強くなったのではと思います。

図:ウェブ転送量が半分に下がった
Cloudflare導入のキッカケ
GZIP圧縮とWAF
自身が利用しているさくらインターネットのレンタルサーバーのスタンダードプラン、よくあるGZIP圧縮でパフォーマンス向上を図ることは普通に出来ます。しかし、同時に提供されているWAFをオンにすると、このGZIP圧縮が使えなくなりパフォーマンスが落ちるという特性があります。
さくらインターネットで採用されてるWAFはSiteGuardと呼ばれるもので、オンオフの設定しかなく、オンにするとセキュリティは向上するのですが、一方でhtaccessにセットしたmod_deflateが使えなくなるだけじゃなく、結果GZIP圧縮が使えなくなる(mod_deflate以外の方法であっても)ことが公式サイトにも記載されています。
さくらで導入のSiteGuardは、mod_deflateが使えないだけじゃなく送信ヘッダから「content-encoding: gzip」を削除してしまってるようで、どう頑張っても現状、WAFとGZIP圧縮を同居出来ないのです。
そうなると一気にパフォーマンスが低下し、SEO的にも不利になる。かといってGZIPの為にWAFをオフにするというのも憚られる。このいかんともしがたい状況なんとかならないか?とうことで到達したのが、「CloudflareのCDNを利用する」というゴール。といっても結構ハードルが高いので、今回まとめてみてる次第です。
※CDN導入により、htaccess側のGZIP圧縮設定は不要になりますので削除しました。
図:GZIP圧縮がオンになりました。
事前準備
今回は、取り組みを始める前に以下の環境が整ってることが前提です。Cloudflareアカウントの作成は簡単なので事前に作っておいてください。
- Cloudflareアカウントを作成しアクティブになっていること
- WordPressにWP Fastest Cacheが入ってること(公式プラグインでも良いみたい)
- さくらのコントロールパネル上で対象サイトに対してWAFがオンであること
今回のエントリーでは、Cloudflare上で設定を行いつつ、さくら側のDNS変更なども伴っているので両方にアクセスできる権限も必要になります。
Cloudflare連携手順
サイトをアクティブにする
アカウント作成をしてるだけでは、何も登録が無い状態であるので、サイト登録をしてアクティブにしてあげる必要があります。但しこの手順だけでは最終的にアクティブになりませんので、この連携手順の全てを順序よく確実に行う必要があります。
画面は設定で日本語にしているので、右上のプルダウンから言語を日本語にしておいてください。
- Cloudflareダッシュボードを開く
- ドメインのオンボードをクリックする
- WordPressで利用してるドメインを入力し、AIクローラーの設定については全てブロックで取り敢えずOKです。
- 続行をクリックする
- プラン選択画面が出るので、「Free」を選びます。
- 自身のドメインのDNSのレコードがスキャンされるので、Aレコード、AAAAレコード、CNAMEのwwwレコードはオンの状態で、Google Workspace系で使ってるCNAMEなどは除外するようにセットしました。
- アクティベーションに進む。
- ここで、3.の手順にあるDNSサーバーの2つの値を控えておく。
ここまでで取り敢えず完了です。ここから先に続行する為には、さくら側のDNSサーバー変更が必要になる為、そちらで設定変更をしてから、続行ボタンを押して待つことでアクティブになります。
※手順3のAIクローラーに対する処置はクローリングしてほしくない場合には全てブロックで良いのですが、一方でLLMO的観点から見た場合にはブロックしないという設定のほうが良いのかもしれません。
図:ドメイン登録からまず始める
図:DNS設定の画面
図:置き換えるDNSの項目
DNS設定の変更
次に、さくらの側のDNSサーバー設定変更が必要です。こちらはDNSレコード側の設定では変更が出来ませんので、whoisの情報から設定を変更する必要があるというハマりポイントがあるので注意が必要です。
- さくらの会員メニューにログインする
- 左サイドバーの契約中のドメイン一覧をクリックする
- whois情報変更のリンクをクリックする
- ネームサーバーを編集をクリックする
- 前述のCloudflareで出てきたDNSのアドレスを2つ入力して、保存をするをクリックする
- Cloudflareの画面に戻って、続行をクリックしてReview your DNS recordsとなり、数十分するとDNS情報が行き渡って、Cloudflare側での登録がアクティブになる(メールで通知が来ます)
図:この2つを書き換える
さくら側の設定変更
つづけて、Cloudflare側設定に入る前に、さくらのコントロールパネルからも設定変更を行ってきます。
- サーバーコントロールパネルにログインする
- 左サイドバーから、ドメイン/SSL > ドメインSSLのページを開く
- 自身のサーバーで設定してるドメインのうち、CloudflareのCDNを使う対象の設定をクリック→基本設定を開く
- HTTPSに転送するのチェックを外す
Cloudflare側で転送設定を行うのでここは必ず、転送設定を外しておく必要があります。
図:サーバー側のHTTPS転送はオフにしておく
Cloudflare設定を変更する
現在のCloudflareはデフォルトでGZIP/Brotliの圧縮機能が有効になっているため、手動でオンオフする必要がありません。よって、さくら側でWAFのせいでGZIP圧縮が使えない状態でも、CDNであるCloudflare経由でユーザーはアクセスするため、さくら側のhtaccessによるGZIP圧縮設定は不要になります。
また、ページコンテンツのキャッシュもデフォルトで有効になってるので、別途設定は不要です。
SSL/TLS設定
ここからは、アクティブになったドメインに対して、Cloudflare側のセッティングを行います。誤った設定をするとWordPressの管理画面に入れなくなったり、数々のエラーが出てウェブサイトが表示されなくなるなど重大な問題に直面するので注意が必要です。今回はそこまで深い設定をせず、必要最低限の設定のみをセットします。
- ダッシュボード上のアクティブになった自身のドメインのリンクをクリックする
- 左サイドバーの「SSL/TLS」をクリックする
- SSL/TLS 暗号化の設定をクリックする
- 暗号化モードを設定するではカスタム SSL/TLSを選び、今回はフル(厳密)を選び、保存をクリックする
- 次に同じSSL/TLSの項目の中にある「エッジ証明書」を開きます。
- この中にある「常に HTTPS を使用」の設定をオンにします。
- また、同じセクションにある「HTTPS の自動リライト」をオンにします。
とりあえずこのセクションの設定はこれだけでオッケーです。以前は、Auto MinifyというCSSやJS、HTMLの自動圧縮というWP Fastest Cacheみたいな機能があったのですが、効果が薄いということで現在は廃止になってるようです。
図:SSL/TLSの設定
図:HTTP転送設定をオンにする
ルール設定
この設定は非常に重要ですので慎重にセットをしましょう。
- ダッシュボード上の左サイドバーからルールをクリックする
- ルールを作成をクリックして、キャッシュルールを選択します。
- 名前はまず「管理画面」として、受信リクエストが一致する場合…は、「カスタムフィルタ式」を選びます
- WordPressの管理画面に入る為のURLを入れます(通常、https://ドメイン/wp-admin/*)
- キャッシュをバイパスするにチェックが入ってるのを確認
- 保存をクリックする
- 同様に、プレビュー画面も同じように作ります(通常、)
- 続けて、ルールを作成をもう一回クリックし、圧縮ルールを選択します。
- 名前は「Brotli 圧縮を無効にする」として、受信リクエストが一致する場合…は、「カスタムフィルタ式」を選択します。
- WordPressの管理画面に入る為のURLを入れます(通常、https://ドメイン/wp-admin/*)
- 圧縮の種別では、「圧縮を無効にする」を選択します。
- 保存をクリックする
設定が反映するのに少しだけ時間が掛かるので待ちます。この間に、WordPressのウェブページが正しく見られるか?管理画面に入れるか?を確認します。Chromeのキャッシュが悪さをして入れないといったことが起きることがあるので、その場合Chromeのキャッシュを捨てたり、別のブラウザ(SafariやFirefoxなど)で確認しましょう。
図:キャッシュバイパスルールを作る
図:管理画面はBrotli圧縮は適用しない
WP Fastest Cacheの設定
WP Fastest Cacheと連携する為に、今回の連携の為のトークン設定をします。
- こちらのページにアクセスする
- トークンを作成するをクリックする
- API トークン テンプレートは、WordPressを選択します。
- 特に何も変更すること無く、概要に進むをクリックする
- トークンを作成するをクリックする
- トークンが発行されるのでこれをコピーしておく。この時にしか表示されないので注意。
- 自身のWordPressのWP Fastest Cacheの設定ページを開きます。
- 上部タブのCDNをクリックする
- CDN by Cloudflareをクリックする
- トークン入力画面が出てくるので、トークンを入れてNextをクリックする
- Disable Rocket LoaderはそのままNextをクリックする(Cloudflare上でRocket Loaderは使えない)
- Browser Cache Expirationはこの結果、6ヶ月になるので承知するのでNextをクリックする
- Ready to Goが出たら完了。Finishをクリックして終わりです。
前述まででCloudflareアカウントがアクティブになっていないとこの設定は出来ないので注意。
図:このテンプレを利用する
図:WP Fastest Cacheの設定
連携後の作業
圧縮有効化の確認方法
実際に今回の設定変更で、一番の目的である圧縮が有効になっているかを確認します。
- こちらのサイトを開く
- 自身のワードプレスのトップページのURLを入力してチェックをするをクリック
- gzip圧縮は有効ですと出たら成功です。
図:目的が達成されました
ページキャッシュの確認方法
対象のページのキャッシュがきちんとCDN側で行われているかを確認します。
- WordPressにログインしていない状態でページアクセスする
- F12キーでChrome Developer Toolsを開く
- 上部タブのネットワークを開く
- 一旦ネットワークログを消しておいてリロードをする
- 右側パネルにズラズラ出てくるので、cssやjsなどの適当なWordPressで使ってると思わしきファイルをクリック
- 左側のパネルの「ヘッダー」タブを開いてみる
- cf-cache-statusがHITになっていればキャッシュから払い出されています。またserverがcloudflareとなっていればCDNからの払い出しとわかります。
図:きちんとCloudflareのキャッシュがヒット
ちょっとした不具合
この結果としてページスコアが大幅に改善し、GZIP圧縮も使えるようになった為、まだまだチューニングの余地がある状態です。しかしあまりCloudflare側であれこれ弄ると、思わぬ不具合が出る可能性があるため、注意が必要です。
またこの導入の結果、稀にですがChromeのキャッシュの関係なのか?ページの編集画面に入っても真っ白なことがあります。その場合リロードすればブログ記事の内容は出てくるので焦らず対処しましょう。
きちんとブログ更新をして、他のブラウザからログインしていない状態で、ウェブページが最新状態になってるか?は確認しておきましょう。
不正アクセスの増加対策
概要
管理画面はバイパスし、その他はCDNで払い出しという状況を作れました。しかし、結果として急激に変わったのが不正アクセス。Limit login Attempts Reloadedという不正アクセスをブロックするプラグインの数値が急上昇。もちろん、二段階認証も入れてるのでログインしても2FAでブロックされるようにしてるので大丈夫なのですが、気になる値。
そこで管理画面の場所に対してCloudflare側で特定条件以外はブロックする措置を追加しました。
図:不正アクセスが急上昇
セキュリティルールの追加
Cloudflareにログインし自身の登録ドメインのページを開いて、セキュリティルールを追加します。
- 左サイドバーからセキュリティ→セキュリティルールをクリックします
- まず1つ目のルールを追加。ルールを作成をクリックします。
- ルール名はcountryとし、URIパス>次を含む>/wp-login.phpを追加し、ANDをクリック
- 国>次に等しい>japanをセットする
- アクションは「スキップ」とし、スキップする WAF コンポーネントは、「残りのすべてのカスタム ルール」として保存をクリック
- 2つ目のルールを追加。ルールを作成をクリックします。
- ルール名はallowipとする。URIパス>次を含む>/wp-login.phpを追加し、ANDをクリック
- 送信元のIPアドレス>リストに含まれる>作っておいたリストを選択(リストがない場合、リストを管理をクリック)
- リストを管理をクリックした場合はカスタムリストを作成し、自分の今のIPアドレスをCIDR形式で追加しておく。(確認くんを使って、IPを調べて/24のCIDR形式としました)。
- アクションは「スキップ」とし、スキップする WAF コンポーネントは、「残りのすべてのカスタム ルール」として保存をクリック
- 3つ目のルールを追加。ルールを作成をクリックします。
- ルール名はblockとする。URIパス>次を含む>/wp-login.phpを追加し、アクションは「ブロック」とする
- ルール1〜3として順番に実行されるように並び順を再確認する
これでとりあえずはルール作成は完了。なのですが、ここで嵌りどころがあります。1つ目のルールが無い場合、2つ目のルールでIPアドレスリストは正しいのに何故かスキップされずブロックされる。そこで、セキュリティ>Analytics>イベントのブロックイベントで、カスタムルールのものを調べてみると、ブロックの1つにSAKURAの文字が(自身のレンタルサーバ)。
そこで、このログのIPアドレスをCIDRとして9.のカスタムリストに追加した所、自身のISPであればきちんと通過し、違うISPの場合はブロックされるという理想の環境が構築出来ました。Cloudflareからは管理画面はCDNではなくバイパスさせてる点と、DNSをCloudflareに変更したからなのかもしれませんが、WordPress設置のレンタルサーバからの通信も許可してあげないとならないようです。
そもそも1つ目のルールで殆ど国外からの不正アクセスは弾けるので用をなしてるのですが、2番目のルール設定には注意しないと、問題ないアクセスなのにブロックされて嵌まることになります。
図:3つのルールを作成する
図:カスタムリストを使ったルールの事例
図:カスタムなIPアドレスリストの作成
障害対策
2025年11月18日、夜8時半頃Cloudflareにて大規模障害が発生し、XやChatGPTだけでなくCDN利用していたこのサイトも巻き込まれてInternal Server Errorになってしまいました。
現在は落ち着いているものの原因がまだ判明していない。ちょうど自分もDNSをイジっていた時であったので、自分が何かしでかしたのかと焦りました。この場合、長期間に渡ってサーバーダウンの状態となるため、この結果として以下のことが連動して発生しました。
- CloudflareへはGoogleのSSOでログインしていたので、ログイン認証が出来ず(Unable to authenticate request状態)
- 自身のWebサーバはDNSをCloudflareに振り向けているので、レンタルサーバであってもWordPressにログイン出来ず
このような障害が発生した場合の対処手順は以下の通り。本来は放置してCloudflareが復旧するのを待つのが最善策ですが、どうしても手動でフェイルオーバーさせたいことがあります。
- Cloudflareにログインできるならば、サイト連携の一時停止を実行する(これでWordPressにログインできればそれで作業は一旦終了)
- 駄目な場合はさくらのDNSをDNS1を「ns1.dns.ne.jp」、DNS2を「ns2.dns.ne.jp」に変更して保存
- さくらのLet's EncryptのSSLについては常に有効化しておき外さないこと(これが重要)
さくらのDNS設定は契約中のドメイン一覧の中のWhois情報からDNS情報を書き換え可能です。これでしばらく待ってログインできればOK。ただし、ウェブサイトのSSL情報がしばらく発行元がWE1のGoogle Trust Servicesのままだと思われるので(これはCloudflareのSSL証明書)、放置しておけばさくらのR13のLet's Encryptに切り替われば、連携解除完了です。
これでさくらのDNSに切り替わってるのでサイト復旧完了です。再度、CDNを有効にする場合はCloudflare側の一時停止解除して、さくらのDNS設定をCloudflareに向ければ自然とCDNがまた有効になると思います。
図:あちこちでこの表示に
図:DNSを元に戻す
図:Cloudflareにログイン出来ず
関連リンク
- さくらのレンタルサーバにてGZIP圧縮が出来ないときの対処法
- SiteGuardを導入するとHTTP_ACCEPT_ENCODINGなどのHTTPヘッダが削除されてしまう件
- さくらスタンダードですけどCloudflareをやってみた
- さくらのレンタルサーバ+αで費用を節約しつつ軽めのサイトを作る
- WordPress にCloudflare を導入
- WP Fastest Cache Cloudflare
- Perplexityはブロックされたサイトを「ステルスクローリング」している──Cloudflareが告発
- Cloudflare、AIクローラーのブロックを標準設定に
- CloudflareがAuto Minifyを廃止へ 代替手段は?
- ERR_TOO_MANY_REDIRECTS
- コミュニティのヒント - 「Google ChromeでSSLのバージョンまたは暗号の不一致」エラー
- Getting ECH fallback certificate error
























