WordPressのCloudflare導入と除外設定｜DNS・SSL・キャッシュ設計

WordPressにCloudflareを入れる目的は、静的ファイルやページ配信を近い場所から返し、サーバー負荷を下げ、表示速度と配信安定性を上げることです。

ただし、CloudflareはWordPressの前段に入るため、設定を間違えると管理画面、問い合わせフォーム、会員ログイン、予約、EC、CV計測に影響します。

特に危ないのは、「全部キャッシュすれば速い」という発想です。公開記事や固定ページはキャッシュしやすい一方で、ログイン状態、フォーム送信、確認画面、完了画面、カート、会員ページ、管理画面はキャッシュしてはいけない領域があります。

Cloudflare公式でも、WordPress高速化では匿名ページのキャッシュ、画像最適化、HTTPS、アセット最適化などが扱われています。

Cloudflare Docs: Speed Up WordPress and Improve Performance

WordPressへのCloudflare導入は、CDNを有効にする作業ではなく、DNS、SSL、キャッシュ除外、WordPress側キャッシュ、フォーム、CV計測をまとめて設計する作業です。

この記事では、Cloudflareの導入手順そのものよりも、WordPressサイトで事故を避けるための実装順を整理します。

Cloudflare/CDNをWordPressに入れる目的

Cloudflareは、WordPressのサーバーと訪問者の間に入るリバースプロキシ型のサービスです。

静的ファイルをCDNで配るだけでなく、DNS、HTTPS、キャッシュ、画像最適化、WAF、Bot対策、アクセス集中時の負荷軽減など、サイトの入口に関わる機能を持ちます。

WordPressでCloudflareを使う目的は、主に次の通りです。

目的	期待できる効果	注意点
静的ファイルの配信改善	画像、CSS、JavaScriptを近いエッジから返す	画像最適化プラグインとの重複に注意
HTMLキャッシュ	匿名ユーザー向けページのTTFBを下げる	ログイン、フォーム、ECは除外が必要
サーバー負荷軽減	WordPress/PHP/DBへのアクセスを減らす	キャッシュパージ設計が必要
SSL/TLS整理	HTTPS配信を安定させる	origin側証明書の確認が必要
セキュリティ強化	WAFやBot対策を使える	管理画面やAPIの誤ブロックに注意
配信安定性	アクセス集中時の落ち方を緩和する	動的機能はサーバー側の改善も必要

CloudflareのDNSの仕組みでは、proxiedのDNSレコードでHTTP/HTTPS通信がCloudflare経由になることが説明されています。つまり、導入後は訪問者からWordPressサーバーまでの経路が変わります。

この経路変更によって、静的なページは速くしやすくなります。一方で、WordPressの動的機能は「Cloudflareを通しても壊れないか」を確認する必要があります。

Cloudflare導入の目的は「全部をキャッシュすること」ではなく、公開ページは速くし、動的な導線は壊さず通すことです。

コーポレートサイト、メディア、採用サイト、サービスサイトのように、閲覧中心のページが多いWordPressでは効果が出やすいです。逆に、会員、予約、EC、診断、フォーム確認画面が多いサイトでは、除外条件とテスト手順がより重要になります。

導入前に確認するDNS・メール・SSL・サーバー構成

Cloudflare導入で最初に確認するのは、WordPressの管理画面ではなくDNSです。

ネームサーバーをCloudflareへ切り替えると、Webサイトだけでなく、メール、サブドメイン、外部サービス認証、CDN、API、計測タグ、MA/CRM連携に影響することがあります。

切替前には、少なくとも次を一覧にします。

確認項目	見る内容	失敗例
A/AAAA/CNAME	Web本体、www、サブドメインの向き先	wwwだけ旧サーバーを見る
MX	メール配送先	メールが届かなくなる
TXT	SPF、DKIM、DMARC、外部サービス認証	送信ドメイン認証が外れる
CAA	証明書発行制御	SSL証明書の発行に失敗する
独自サブドメイン	LP、フォーム、管理画面、ステージング	一部だけ404や証明書エラーになる
サーバーIP	現在のorigin IP	移行時に古いIPを登録する
TTL	切替時の反映時間	切戻しに時間がかかる

CloudflareのDNS recordsでは、DNSレコードはWebや他サービスを利用可能にするための情報として整理されています。WordPressだけを見ていると、メールや外部サービス認証を見落としやすいです。

次にSSLです。CloudflareのSSL/TLSモードでは、Cloudflareからoriginサーバーまでの通信も含めて考えます。Full (strict)は、origin側の証明書が期限内で、信頼された認証局またはCloudflare Origin CAから発行され、ホスト名に一致している必要があります。

実務では、可能ならFull (strict)を目標にします。ただし、origin側に有効なSSL証明書がない状態で無理に進めると、切替直後にエラーになります。

DNS切替前には、WebのA/CNAMEだけでなく、MX、SPF/DKIM/DMARC、サブドメイン、SSL証明書、origin IP、切戻し手順まで確認します。

切替前の確認メモには、現在のDNSレコード、サーバー管理画面、WordPressログインURL、フォームURL、主要CV URL、GA4/GTM、メール配送先、切戻し担当を残します。これがないと、不具合時に「Cloudflareなのか、DNSなのか、WordPressなのか」を切り分けにくくなります。

Cloudflareの基本設定手順

Cloudflareの基本設定は、次の順番で進めると事故を減らせます。

順番	作業	確認すること
1	Cloudflareにサイトを追加する	DNSレコードが正しく取り込まれている
2	DNSレコードを精査する	Web、メール、TXT、サブドメインが揃っている
3	SSL/TLSモードを決める	origin証明書とFull (strict)可否を確認する
4	Web用レコードをproxiedにする	HTTP/HTTPSがCloudflare経由になる
5	ネームサーバーを切り替える	Web、メール、サブドメインが動く
6	基本キャッシュを確認する	静的ファイルが想定通り配信される
7	管理画面・フォームを確認する	ログイン、送信、完了画面が壊れていない

CloudflareのProxy statusでは、proxiedレコードのTTLはAutoになり、300秒として扱われることが説明されています。切替前にTTLを短くする運用もありますが、Cloudflare proxied後の挙動はCloudflare側の仕様も踏まえて確認します。

基本設定では、最初から「Cache Everything」「JavaScript最適化」「画像最適化」「WAFの強いルール」を全部オンにしない方が安全です。まずはDNS、SSL、通常の静的ファイル配信が正しく動くかを確認します。

CloudflareのCache Rulesは、何をキャッシュ対象にするか、どのくらい保持するか、どこで保持するかを調整する機能です。Cloudflareのキャッシュルールは便利ですが、WordPressでは除外ルールとセットで設計します。

Cloudflareの初期導入では、まずDNS、SSL、proxied、静的ファイル配信を安定させ、HTMLキャッシュや最適化機能は動作確認後に段階的に追加します。

公開前後の確認では、トップページだけでなく、記事ページ、サービスページ、問い合わせフォーム、ログイン、管理画面、サンクスページ、計測イベントまで見ます。Cloudflare導入はインフラ側の作業に見えますが、完了条件はサイトの主要業務が正常に動くことです。

WordPress側プラグインとサーバーキャッシュの役割分担

Cloudflare導入で難しいのは、キャッシュの役割分担です。

WordPressには、高速化プラグイン、サーバーキャッシュ、オブジェクトキャッシュ、画像最適化、CDN連携が既に入っていることがあります。そこへCloudflareを追加すると、同じ領域を複数の仕組みが触る状態になります。

領域	主な役割	注意点
Cloudflare	CDN、静的ファイル配信、エッジキャッシュ、WAF	HTMLキャッシュは除外条件が重要
WordPressキャッシュプラグイン	ページキャッシュ、CSS/JS最適化、画像最適化	Cloudflareやサーバー機能と重複しやすい
サーバーキャッシュ	PHP処理前のページキャッシュ、OPcacheなど	ホスティング仕様に依存する
オブジェクトキャッシュ	DB問い合わせ結果の保存	Redis/Memcachedなど環境依存がある
ブラウザキャッシュ	端末側の再利用	更新反映とTTL管理が必要

CloudflareのWordPressプラグインによるAPO有効化ガイドでは、APO初期設定時にWP Rocket、W3 Total Cacheなどのキャッシュプラグインを一度オフにし、APOが動くことを確認してから、併用で改善するか想定外の挙動が起きるかをテストする流れが推奨されています。

この考え方はAPOに限らず重要です。まずCloudflareだけで何が改善するかを見て、次にWordPress側のキャッシュを戻すか判断します。

CloudflareとWordPress側キャッシュは、同じページを二重三重に最適化するのではなく、CDN、HTML、DB、ブラウザ、画像の担当を分けて管理します。

実務では、設定表を作ると管理しやすくなります。

機能	どこで担当するか	メモ
静的ファイルCDN	Cloudflare	CSS/JS/画像の基本配信
HTMLキャッシュ	Cloudflareまたはサーバー	除外ルール必須
CSS/JS圧縮	ビルド工程または1つのプラグイン	複数プラグインで重複させない
画像変換	Cloudflareまたは画像プラグイン	WebP/AVIFの重複に注意
DB最適化	WordPress側	削除系はバックアップ前提
キャッシュパージ	Cloudflareプラグインまたは運用手順	記事更新時の反映方法を決める

この表がないと、表示崩れやフォーム不具合が起きたとき、どのキャッシュを消せばよいか分からなくなります。

キャッシュしてはいけないURLと除外ルール

WordPressでCloudflareを使うときに最も重要なのが、キャッシュ除外です。

公開記事や固定ページはキャッシュしやすいですが、ユーザーごとに内容が変わるページ、送信処理、ログイン状態、確認画面、完了画面はキャッシュ対象にしない方が安全です。

代表的な除外候補は次です。

除外対象	例	理由
管理画面	/wp-admin/*	管理者操作、投稿編集、設定変更がある
ログイン	/wp-login.php、独自ログインURL	認証状態が関わる
プレビュー	?preview=true、下書きプレビュー	管理者向けの動的表示
フォーム	/contact/、/inquiry/、確認画面、完了画面	nonce、セッション、reCAPTCHA、通知がある
EC	/cart/、/checkout/、/my-account/	カート、決済、会員情報がある
会員・予約	マイページ、予約確認、診断結果	ユーザー別表示がある
API	/wp-json/*、admin-ajax.php	動的通信がある
計測用URL	広告LPの一部、CV完了URL	計測やリダイレクト確認が必要

CloudflareのCache Rules設定では、条件に一致するリクエストをキャッシュ対象外にするBypass cacheを選べます。Cache Rulesは強力ですが、ルールの順序と条件を誤ると、意図しないページがキャッシュされます。

ログイン状態の扱いも重要です。CloudflareのWordPress高速化ガイドでは、ログインやWooCommerceカートが関わるとエッジキャッシュをバイパスする考え方が紹介されています。実務では、Cookie、URL、パス、クエリ、レスポンスヘッダーを組み合わせて確認します。

CloudflareのHTMLキャッシュを使う場合は、キャッシュするURLより先に、キャッシュしてはいけないURL、Cookie、クエリ、フォーム、ログイン状態を決めます。

除外ルールは、ドキュメントとして残します。

ルール名	条件	アクション	確認URL
WordPress admin bypass	/wp-admin/*、/wp-login.php	Bypass cache	管理画面、ログイン
Form bypass	問い合わせ、確認、完了URL	Bypass cache	送信テスト
Cart/member bypass	カート、会員、予約	Bypass cache	ログイン、購入、予約
Preview/API bypass	preview、REST API、admin-ajax	Bypass cache	プレビュー、Ajax

キャッシュルールは「作ったら終わり」ではありません。フォーム追加、LP追加、会員機能追加、EC導入、プラグイン変更のたびに見直す必要があります。

画像最適化・CDN・既存高速化プラグインの整理

Cloudflare導入時には、画像最適化と既存高速化プラグインを整理します。

WordPressサイトでは、すでに画像圧縮、WebP変換、Lazy Load、CSS/JS圧縮、ページキャッシュ、DB最適化、CDN書き換えなどのプラグインが入っていることがあります。

Cloudflare側にも、画像最適化、CDN配信、キャッシュ、アセット最適化があります。そのため、どちらが何を担当するかを決めます。

機能	Cloudflare側で持つ場合	WordPress側で持つ場合
画像圧縮	配信時に最適化しやすい	アップロード時にファイルを軽くできる
WebP/AVIF	ブラウザに応じた配信を考えやすい	メディアライブラリ側で管理しやすい
Lazy Load	WordPress標準やテーマで十分なことがある	表示崩れ確認が必要
CSS/JS圧縮	CDN側で触れる	テーマやビルド工程と合わせやすい
CDN URL書き換え	Cloudflare proxiedなら不要なことが多い	別CDNを使う場合は必要
ページキャッシュ	エッジで返せる	サーバー内で完結しやすい

CloudflareのWordPress高速化ガイドでは、画像最適化、HTTPS、アセット最適化などが紹介されています。ただし、Cloudflare側の機能を使うほど、WordPress側の高速化プラグインと重なる領域が増えます。

まずやるべきことは、プラグインを増やすことではなく、既存プラグインの機能一覧を作ることです。

Cloudflare導入時は、新しい高速化機能を足す前に、既存プラグインが画像、CSS/JS、キャッシュ、CDN、DBのどこを触っているかを棚卸しします。

整理の目安は次です。

1. 画像の元ファイルが大きすぎる場合は、アップロード前またはWordPress側でリサイズする
2. CDN配信はCloudflareを主担当にする
3. HTMLキャッシュはCloudflareかサーバー側のどちらを主にするか決める
4. CSS/JS圧縮は1つの仕組みに寄せる
5. Lazy LoadやWebP変換は重複を避ける
6. 設定変更ごとに表示、フォーム、計測を確認する

高速化プラグインを複数使うより、役割が分かる状態にする方が保守しやすくなります。

導入後に確認する表示速度・フォーム・ログイン・CV計測

Cloudflare導入後の確認は、PageSpeed Insightsだけでは足りません。

表示速度、管理画面、フォーム、ログイン、CV計測、メール通知、スマホ表示をまとめて確認します。

確認対象	確認内容	見るポイント
表示速度	PageSpeed Insights、Lighthouse、実機	LCP、INP、CLS、TTFB
レスポンス	DevTools、レスポンスヘッダー	cf-cache-status、キャッシュ有無
問い合わせフォーム	入力、確認、送信、完了、通知メール	nonce、reCAPTCHA、完了URL
ログイン	WordPressログイン、会員ログイン	ログイン後の表示、ログアウト
管理画面	投稿編集、画像アップロード、プレビュー	保存、プレビュー、Ajax
CV計測	GA4、GTM、広告CV	form_submit、click、generate_lead
スマホ導線	メニュー、CTA、電話、LINE、予約	JavaScript遅延の影響
SEO	Search Console、robots、sitemap	クロールエラー、リダイレクト

Cloudflare導入前後で、同じURLを測ることが重要です。トップページだけでなく、サービスページ、記事ページ、問い合わせフォーム、完了画面、ログインが必要なページを分けて確認します。

CloudflareのCloudflare Traceは、Cache Rulesのトラブルシュートでルールが特定URLに対して発火しているか確認する用途として案内されています。キャッシュルールが効いているか分からない場合は、レスポンスヘッダーとあわせて確認します。

Cloudflare導入後の完了条件は、PageSpeedの改善ではなく、フォーム送信、ログイン、管理画面、CV計測、スマホ導線が正常なまま速くなっていることです。

公開後は、次の確認結果を保守メモに残します。

記録項目	例
導入日	2026-07-06
DNS切替時刻	ネームサーバー変更、反映確認
SSLモード	Full (strict)など
キャッシュ方針	Cloudflare、サーバー、WordPressプラグインの担当
除外URL	管理画面、フォーム、ログイン、EC、会員
確認URL	トップ、記事、サービス、フォーム、完了画面
CV計測	GA4/GTM/広告CVの確認結果
切戻し手順	DNS、proxy status、キャッシュ停止方法

この記録があると、次回のフォーム追加やプラグイン更新時に、キャッシュ除外の漏れを防ぎやすくなります。

よくある不具合と切り戻し手順

Cloudflare導入後の不具合は、原因を分けると対応しやすくなります。

症状	疑う場所	一時対応
サイトが表示されない	DNS、origin IP、SSL	DNSレコード、SSLモード、origin到達確認
SSLエラーが出る	SSL/TLSモード、origin証明書	証明書期限、ホスト名一致、Full (strict)可否
ログインできない	キャッシュ、Cookie、WAF	ログインURLをBypass、WAFログ確認
管理画面が崩れる	キャッシュ、Rocket Loader、CSS/JS最適化	管理画面除外、最適化機能停止
フォーム送信できない	キャッシュ、JS遅延、WAF、reCAPTCHA	フォームURL除外、送信テスト
更新が反映されない	HTMLキャッシュ、ブラウザキャッシュ	パージ、TTL確認
CV計測が落ちる	JS最適化、GTM、同意管理	タグ発火確認、最適化を段階停止
メールが届かない	MX、SPF、DKIM、DMARC	DNSレコード確認

切り戻しは、影響範囲の小さい順に試します。

1. 問題URLのCloudflareキャッシュをパージする
2. 該当URLをCache RulesでBypassする
3. JavaScript/CSS/画像最適化など追加機能を止める
4. WAFやBot対策のログを確認し、必要なら対象ルールを調整する
5. 該当DNSレコードを一時的にDNS onlyへ戻す
6. 必要に応じてネームサーバー切戻しを検討する

いきなりネームサーバーを戻すと、反映待ちやメール影響が出ることがあります。まずはCloudflare上で該当機能を止め、問題範囲を狭める方が現実的です。

Cloudflareの切り戻し手順は、導入後に考えるのではなく、DNS切替前に「どの症状なら何を戻すか」まで決めておきます。

特にフォームやログインの不具合は、サイト全体の表示速度より優先して直します。CV導線が止まっている場合は、キャッシュを一時的に弱めても、まず送信・ログイン・計測を正常化します。

BitlightのWordPress高速化・保守改善相談

Cloudflare導入は、手順だけなら難しく見えないかもしれません。

しかし、実際のWordPressサイトでは、既存プラグイン、テーマ、フォーム、サーバーキャッシュ、メール、GA4/GTM、広告CV、会員機能、予約、EC、古いPHP、DB負荷が絡みます。

Bitlightでは、Cloudflare導入を単独の設定作業ではなく、WordPressの速度改善と保守改善の一部として扱います。

支援内容	実施すること
導入前診断	DNS、SSL、サーバー、プラグイン、フォーム、CV導線の確認
Cloudflare設計	proxied対象、SSLモード、Cache Rules、WAF方針
キャッシュ除外	管理画面、ログイン、フォーム、完了画面、会員、EC、API
WordPress側整理	既存キャッシュプラグイン、画像最適化、CSS/JS最適化の役割分担
公開後確認	表示速度、フォーム送信、ログイン、GA4/GTM、広告CV
保守改善	更新時のパージ、除外ルール、月次確認、変更メモ整備

特に相談した方がよいのは、次のようなサイトです。

状況	理由
問い合わせや資料請求が重要	フォームとCV計測を壊せない
会員、予約、ECがある	キャッシュ除外が複雑になる
既存キャッシュプラグインが多い	Cloudflareとの重複整理が必要
DNSやメール設定が不明	切替でメールや外部認証に影響する
管理画面も遅い	CDNだけでは解決しない可能性がある
広告流入がある	LP、サンクスページ、広告CV確認が必要

Cloudflare導入で本当に必要なのは、速くする設定ではなく、WordPressの業務導線を壊さないキャッシュ設計と公開後確認です。

WordPressを速くしたいだけなら、プラグイン追加で一時的に改善することもあります。けれど、問い合わせ、採用、資料請求、予約、EC、広告CVが絡むサイトでは、表示速度と保守性を同時に見る必要があります。

Cloudflare、WordPress側キャッシュ、サーバーキャッシュ、フォーム除外、CV計測を整理しておくと、次回のプラグイン更新やLP追加でも事故を減らせます。高速化を一回きりの作業で終わらせず、保守しやすい設定として残すことが、古いWordPressサイトでは重要です。