WordPressにCloudflareを設定する方法｜DNS・SSL・CDNを安全に切り替える手順

WordPressへCloudflareを導入すると、DNS、CDN、キャッシュ、WAFなどをまとめて扱えます。ただし設定を急ぐと、Webサイトは表示できても独自ドメインメールだけ止まる、SSLのリダイレクトループが起きる、WordPress管理画面までキャッシュしてしまうといった事故が起きます。

僕はCloudflareをWebアプリや運用基盤で使い、DNS・Tunnel・Accessなども扱っています。また複数WordPressサイトでは独自ドメインメールのMX/TXTを管理してきました。WordPressへCloudflareを入れる時も、機能を全部オンにするより、DNS→HTTPS→静的配信→必要なキャッシュの順で段階的に入れる方が安全です。

CloudflareをWordPressへ入れると何が変わる？

手順1｜現在のDNSを全部保存する

Cloudflareはサイト追加時にDNSをスキャンしますが、検出結果が必ず完全とは考えません。ネームサーバー変更前に、現在のDNS管理画面を開いて全レコードを保存します。

• ルートドメインのA/AAAA/CNAME
• www等のサブドメイン
• MXレコード
• SPF・DKIM・DMARC
• Google/Zoho等のドメイン認証TXT/CNAME
• サーチコンソールや外部サービスの検証レコード
• サブドメインで別サービスを使っている場合のレコード

特にメールをZoho等で運用している場合、MX/TXTを落とすとWebとは別にメールが止まります。ネームサーバー切替前に旧DNSとCloudflare側を横並びで照合します。

手順2｜Cloudflareへドメインを追加しDNSを照合する

Cloudflareの一般的なフルセットアップでは、ドメインを追加し、DNSレコードを確認した後にCloudflare指定のネームサーバーへ変更します。Cloudflare公式も、ネームサーバーを更新する前にDNSレコードを見直すよう注意しています。

A/CNAMEの「Proxy status」はWebトラフィックをCloudflare経由にするかを決めます。メール用MXやTXTはWebプロキシとは別のレコードなので、メールプロバイダーの値をそのまま維持します。

手順3｜ネームサーバーを変更する

旧DNSとCloudflare側の照合が終わってから、ドメイン登録側でネームサーバーを変更します。切替直後は反映が混在する時間があるため、その間にDNSを何度も変更しません。

確認項目は「トップが開く」だけでは足りません。www有無、管理画面、主要記事、フォーム、メール受信、外部サービスの認証までチェックします。

切替後に整えるCloudflare設定

SSL/TLSは可能ならFull (strict)を使う

Cloudflareを挟むと、閲覧者→CloudflareとCloudflare→WordPressサーバーの2区間があります。Cloudflare公式は、オリジン側に有効な証明書を用意できる場合はFull (strict)を最も安全な選択肢として推奨しています。Full (strict)ではCloudflareからオリジンまで暗号化するだけでなく、オリジン証明書の有効性も検証します。

FlexibleはオリジンまでHTTPとなるため、「とりあえずHTTPS表示にする」目的で常用しません。WordPress側・サーバー側・Cloudflare側でHTTPSリダイレクトを重ねるとリダイレクトループが起きることがあるため、1つ変更するたびにシークレットウィンドウ等で確認します。

最初はCloudflareの標準キャッシュから始める

Cloudflareは静的コンテンツを標準でキャッシュできます。WordPressのHTML全体を最初から強くキャッシュする必要はありません。画像、CSS、JavaScriptなど標準の挙動を確認し、オリジンの速度・プラグインキャッシュとの関係を見てから範囲を広げます。

CloudflareのCache Rulesを使えば対象やTTLを調整できますが、WordPress管理画面、ログインユーザー、プレビュー、カートや会員ページなど動的部分を誤キャッシュしない設計が必要です。

WordPressプラグインとCloudflareのキャッシュを二重管理しない

Cloudflare公式はAPO導入時に、WP RocketやW3 Total Cacheなど他のキャッシュプラグインとの併用で予期しない挙動が起こる場合があるため、最初は無効化して検証する案内を出しています。

これは「併用禁止」という意味ではありません。サーバーキャッシュ、WordPressプラグイン、Cloudflareがそれぞれ何をキャッシュしているか分からない状態を避けることが重要です。更新したのに古いページが残る時、どの層をpurgeすべきか説明できる構成にします。

WordPress管理画面を守る時もいきなり遮断しない

Cloudflare WAFやAccessを使って管理画面保護を強化する方法はありますが、REST API、XML-RPC、外部連携、WordPressアプリなど正規アクセスを止める可能性があります。まずログを見て、どのパスを誰が使っているか把握します。

121〜130で扱ったWordPress REST APIやMCP等を使う場合も、Cloudflare側の保護設定と機械アクセスが衝突しないか確認が必要です。

導入直後のQAチェック

Cloudflareを入れない方がいいケース

今のサーバーとキャッシュだけで十分速く、DNS管理を増やすメリットがない場合は無理に導入する必要はありません。またDNSに不慣れで、メールや外部サービスのレコードを把握できていない状態なら、先に現状台帳を作る方が先です。

Cloudflareは「入れるだけでSEOが上がるツール」ではありません。速度や安定性を改善する余地はありますが、検索順位はコンテンツ・検索意図・内部リンクなど多くの要因で決まります。

無料CDNとAPOを混同しない

Cloudflareの無料プランでもDNSや静的アセットのキャッシュは利用できます。一方、WordPressのHTMLをより積極的にエッジ配信するAutomatic Platform Optimization（APO）は別の仕組みです。Cloudflare公式では、無料プラン利用者はAPOを追加購入する形、Pro以上ではプランに含まれる形が案内されています。

まず無料範囲のDNS・CDN・標準キャッシュだけで効果と安定性を確認し、その後にHTMLキャッシュが本当に必要か判断すると、設定を増やしすぎずに済みます。

問題が起きた時の戻し方を先に決める

導入前に旧ネームサーバー、旧DNS全レコード、オリジンの直接URLやIP、Cloudflareで変更したルールを保存します。表示障害が出た時は、いきなり全部を元に戻すのではなく、Development Modeやキャッシュpurge、問題ルールの無効化、ProxyをDNS onlyへ戻すなど、影響が小さい順に切り分けます。

ネームサーバー自体を戻すのはDNS反映時間を伴う大きな変更です。だからこそ、Cloudflare側の設定だけをオフにしてオリジンへ通せる復旧経路を持っておくと安全です。

公式情報・参考資料

仕様・ガイドライン確認日：2026年10月1日。設定画面や料金は変更されるため、実作業前にリンク先の最新版も確認してください。

• Cloudflare DNS：Get started
• Cloudflare Cache：Get started
• Cloudflare：Speed Up WordPress
• Cloudflare：Automatic Cache Management
• Cloudflare：Full (strict)
• Cloudflare：DNSSEC

あわせて読みたい

• Cloudflare DNS移行でメールを止めない方法
• WordPressにCDNは必要？
• WordPressのキャッシュ設定と重複対策
• WordPress×AI連携の全体像

まとめ

WordPressへCloudflareを安全に入れる順番は、DNS保全→ネームサーバー→HTTPS→標準キャッシュ→必要な追加機能です。Cloudflareの機能を全部有効化することが目的ではなく、メールやWordPress管理画面を壊さず、どの層が何を担当するか説明できる構成を作ることが重要です。