CloudflareをWordPressに設定する方法｜DNS・SSL・キャッシュを安全に導入

CloudflareをWordPressへ導入するとき、最も大切なのは高速化設定よりDNSを正しく移すことです。現在のA、AAAA、CNAME、MX、TXTなどのレコードを記録し、Cloudflareへ不足なく登録してからネームサーバーを変更します。

SSL/TLSは、オリジンサーバーに有効な証明書があるならFull (strict)が基本候補です。Flexibleを安易に選ぶと、WordPress側のHTTPSリダイレクトと競合してループすることがあります。

ここでは無料プランでも使われる一般的なFull setupを前提に、準備、DNS移行、SSL、キャッシュ、確認、元へ戻す方法まで説明します。DNS変更はサイトとメールへ影響するため、管理権限とバックアップを確保してから進めてください。

Cloudflareとは

Cloudflareは、DNS、CDN、SSL/TLS、セキュリティなどを提供するサービスです。WordPressの手前でアクセスを受け、条件に応じてキャッシュ済みファイルを返したり、不正な通信を制御したりします。

CDNは、画像、CSS、JavaScriptなどのコピーを複数地域のデータセンターから配信する仕組みです。訪問者と配信拠点の距離を短くし、オリジンサーバーの負荷を減らせる可能性があります。

ただし、Cloudflareを入れるだけで必ずサイトが速くなるわけではありません。重いテーマ、巨大画像、遅いデータベース、外部スクリプトといった原因は別に改善が必要です。導入前後を同じ条件で測りましょう。

導入前に確認するもの

ネームサーバーを変更すると、Webサイトだけでなくメールや各種認証の名前解決もCloudflare側へ移ります。準備なしで進めると、サイトは表示されてもメールだけ届かない事態が起こり得ます。

次の情報を保存してください。

現在のネームサーバー
A・AAAA・CNAMEレコード
MX・TXT・SPF・DKIM・DMARCレコード
サブドメインと外部サービス用レコード
オリジンサーバーのIPアドレス
WordPressとデータベースのバックアップ
ドメイン管理会社とサーバーのログイン経路

DNS管理画面のスクリーンショットだけでなく、レコード名、種類、値、TTL、優先度を表として保存すると復旧しやすくなります。秘密情報や顧客情報が含まれる画面は共有しないでください。

Cloudflare公式は、ネームサーバー変更前にDNSレコードを確認し、正しく設定されていないとドメインへ到達できなくなると注意しています。

Cloudflareへドメインを追加する

無料・Proプランで一般的なのは、Cloudflareを権威DNSにするFull setupです。Cloudflareへドメインを追加し、割り当てられたネームサーバーへ変更します。

Cloudflareアカウントへログインする
ドメイン追加を選ぶ
example.comのようにルートドメインを入力する
DNSレコードの自動スキャン結果を確認する
利用プランを選ぶ
Cloudflareから割り当てられた2つのネームサーバーを記録する

自動スキャンは便利ですが、完全とは限りません。特にメール、所有権確認、サブドメイン、外部フォーム、メール配信サービスのTXTレコードを元の一覧と照合します。

DNSレコードを確認する

CloudflareのDNS画面では、Web用レコードをプロキシするか、DNS応答だけにするかを選べます。オレンジ色の雲はプロキシ有効、灰色はDNS onlyを表すのが一般的です。

レコード用途	初期判断	理由
WebサイトのA・AAAA・CNAME	プロキシ候補	CDN・セキュリティ機能を利用するため
MX	DNS only	メール配送用でHTTPプロキシ対象ではない
mail、ftp等	サービス仕様を確認	対応しないプロトコルを誤ってプロキシしないため
TXT	DNS only	所有権・メール認証情報を公開DNSへ返すため
検証用CNAME	提供元の指示に従う	プロキシで検証に失敗する場合があるため

メール用ホスト名をWebと同じIPへ向けていると、設定の整理が必要になる場合があります。メールサービスとレンタルサーバーのマニュアルを確認してください。

ネームサーバーを変更する

DNSレコードを照合したら、ドメインを取得・管理している会社でネームサーバーを変更します。入力するのはCloudflareがそのドメインへ割り当てた値です。ほかのサイトの値を流用できません。

DNSSECが現在有効な場合、Cloudflare公式のFull setup手順では、ネームサーバー置換前にレジストラ側のDNSSECを無効にし、Cloudflareの有効化後に再設定する流れが案内されています。DSレコードが古いままだと名前解決に失敗する恐れがあります。

変更後はCloudflareのステータスがActiveになるまで待ちます。公式資料では反映に最大24時間かかる場合があると案内されています。反映中は利用者のDNSキャッシュによって新旧どちらへ到達するかが分かれる可能性があります。

重要なサイトでは、アクセスの少ない時間帯に実施し、元のネームサーバーとDNSレコードをすぐ戻せる状態にしておきましょう。

SSL/TLSをFull（strict）へ設定する

CloudflareのSSL/TLSは、訪問者からCloudflareまでと、Cloudflareからオリジンサーバーまでの2区間を考えます。片側だけ暗号化されていても、サイト全体の安全な構成とはいえません。

主な考え方は次のとおりです。

モード	オリジンへの接続	注意点
Flexible	HTTP	WordPressのHTTPS化と競合し、リダイレクトループの原因になりやすい
Full	HTTPS、証明書検証なし	自己署名などでも接続できるが証明書を検証しない
Full (strict)	HTTPS、有効な証明書を検証	オリジン証明書を正しく設定できる場合の基本候補

Cloudflare公式は、可能であればFullまたはFull (strict)を推奨しています。レンタルサーバー側でLet’s Encryptなどの有効な証明書を設定し、WordPressのサイトURLもHTTPSになっていることを確認してからFull (strict)を選びます。

切り替え後にERR_TOO_MANY_REDIRECTSが出た場合は、Cloudflareの暗号化モード、WordPress URL、.htaccess、HTTPS化プラグイン、サーバーのリダイレクト設定を確認します。複数箇所で同じ転送を重ねないことがポイントです。

WordPress向けキャッシュの基本設定

Cloudflareは既定で画像、CSS、JavaScriptなどの静的ファイルをキャッシュ対象にします。公式資料では、動的なHTMLは既定ではキャッシュされず、必要な場合はCache Rulesなどで設定すると説明されています。

初めてなら、まず既定動作で導入し、問題がないことを確認してください。いきなり全HTMLをキャッシュすると、ログイン状態、カート、会員ページ、プレビューなどを誤配信する危険があります。

確認したい除外対象はこちらです。

/wp-admin/
/wp-login.php
投稿プレビュー
カート、決済、マイアカウント
会員限定ページ
フォーム送信後の個別表示
Cookieで内容が変わるページ

WooCommerceや会員プラグインを使う場合は、製品側のCloudflare対応手順を優先します。一般的なブログ用ルールをそのまま適用しないでください。

Cloudflare導入後の確認手順

ステータスがActiveになったら、トップページだけでなくサイトの目的に直結する機能を確認します。DNS、SSL、キャッシュは問題が出る場所が異なるため、順番に切り分けます。

ルートドメインとwwwの両方を開く
HTTPS証明書エラーがないか確認する
WordPress管理画面へログインする
投稿編集とプレビューを試す
問い合わせフォームを送信する
メールの送受信を確認する
画像、CSS、JavaScriptの崩れを確認する
スマートフォンと別回線でも開く
CloudflareのAnalyticsとサーバーログを見る

キャッシュ状況はレスポンスヘッダーのCF-Cache-Statusなどで確認できます。ただしHITだけを成功条件にしないこと。ログインユーザーや個別ページはキャッシュされないほうが正しい場合があります。

表示速度を測る方法

導入効果は、変更前後を同じページ、端末、地域、時間帯で比べます。一度のPageSpeed Insights結果だけで判断せず、Search ConsoleのCore Web Vitalsや実ユーザーデータも確認してください。

GoogleはCore Web VitalsとしてLCP、INP、CLSを案内しています。Cloudflareは主に配信経路や静的ファイルの読み込みへ影響しますが、JavaScript実行やレイアウトずれはテーマ側の改善が必要です。

記録する項目は次のとおりです。

測定URLと日時
モバイル・デスクトップ
LCP、INP、CLS
TTFBと画像転送量
キャッシュHIT/MISS
オリジンサーバーの負荷

設定を一度に複数変えると、何が効いたか分かりません。DNS・SSLの安定を確認してから、圧縮、画像最適化、Cache Rulesなどを一項目ずつ検証します。

よくあるトラブルと直し方

Cloudflare導入後の問題は、DNS、SSL、キャッシュ、セキュリティの順に切り分けると整理しやすくなります。

サイトへ接続できない

A・AAAA・CNAMEが正しいオリジンを向いているか、ネームサーバーがCloudflare指定値へ変わったかを確認します。DNSSECの古いDSレコードが残っていないかも重要です。

一時的にWeb用レコードをDNS onlyへ切り替えると、プロキシ固有の問題かを分けられます。ただしIPが公開され、キャッシュや保護機能を通らなくなる点を理解して行ってください。

リダイレクトループが起きる

SSL/TLSがFlexibleになっていないか、WordPressとサーバー側がHTTPSへ転送しているかを確認します。オリジンに有効な証明書を用意し、Full (strict)へ統一するのが基本です。

更新した記事が反映されない

Cloudflare、WordPressキャッシュプラグイン、レンタルサーバーの三層を確認します。該当URLだけをパージできるなら、全キャッシュ削除より影響を小さくできます。

管理画面で403やチャレンジが出る

セキュリティルールやBot対策が管理者の通信を遮断していないかを確認します。ログを見ずにサイト全体の保護を無効化せず、対象URLや自分の管理経路へ限定して調整してください。

メールが届かない

MX、TXT、SPF、DKIM、DMARC、mail用ホスト名を元の記録と比較します。メール関連の名前を誤ってプロキシしていないかも確認します。

元の状態へ戻す方法

復旧手順は導入前に用意します。問題が大きく、短時間で原因を特定できない場合、設定を追加し続けるより元のDNSへ戻したほうが安全なことがあります。

導入前に保存したネームサーバーを確認する
元のDNS事業者にレコードが残っているか確認する
ドメイン管理会社で元のネームサーバーへ戻す
DNSSECの状態を構成に合わせる
反映後にサイトとメールを確認する

ネームサーバーを戻してもDNSキャッシュのため即時に全利用者へ反映されるとは限りません。変更時刻と作業内容を記録し、関係者へ案内できる状態にします。

よくある質問

Cloudflareは無料で使えますか？

無料プランがありますが、利用できる機能や制限は変更されます。導入前に公式料金ページで必要な機能が対象か確認してください。

WordPressプラグインは必須ですか？

DNS、プロキシ、基本キャッシュの利用だけなら必須ではありません。自動キャッシュ削除や追加機能が必要な場合は、公式・利用サービスのプラグイン仕様を確認して判断します。

ネームサーバー変更でメールも止まりますか？

MXやTXTなど必要なレコードを正しく移せば継続できます。欠落や誤設定があると止まるため、変更前後に送受信テストを行ってください。

Cloudflareを入れるとSEO順位が上がりますか？

導入だけで順位が上がるとは断定できません。表示体験や可用性の改善につながる可能性はありますが、コンテンツ、クロール、サイト構造など多くの要因があります。

SSLはFlexibleでもよいですか？

オリジンサーバーがHTTPSに対応するならFull (strict)を基本候補にします。FlexibleはCloudflareからオリジンまでHTTPになり、WordPressのHTTPS転送と競合する場合があります。

まとめ

CloudflareをWordPressへ安全に導入する順序は、DNS記録の保存、レコード照合、ネームサーバー変更、SSL/TLS、キャッシュ確認です。高速化の細かな設定は、サイトとメールが正常に動くことを確認してから追加します。

最初の一歩は、現在のDNSレコードを表として保存すること。A、CNAMEだけでなくMXとTXTまで残しておけば、問題が起きても元の状態へ戻しやすくなります。