こんにちは。バナナデスクです。
WordPressの記事を更新したのに、別のブラウザでは古い料金が表示される。Cloudflareを使う時は、速く表示されるかと同じくらい、「どの内容を、誰に再利用しているか」が大事になります。
とはいえ、Cloudflareへ接続したら全記事のHTMLが自動的に保存される、という仕組みではありません。標準のキャッシュと、HTMLまで扱う設定を分けて考えると、導入時の確認が整理できます。
ここでは、自分で管理するサーバー上のWordPressを想定し、公式仕様と検証用の設計例を示します。実サイトでDNS変更やAPO導入を実行した結果ではなく、導入前に用意する確認手順です。
DNS管理・プロキシ・キャッシュは同じ設定ではない
Cloudflare導入では、通信経路を確認してから、公開してよい内容だけをキャッシュ対象にし、更新・ログイン・フォームの動作を別々に確かめます。WordPress本体や利用中のプラグインの代わりに、Cloudflareがすべてを判断してくれると考えないことです。
CloudflareのProxy statusの説明では、DNS-onlyは名前解決を行うものの、HTTP/HTTPS通信をCloudflareのプロキシへ通しません。ProxiedにしたWeb用のA・AAAA・CNAMEは、通信がCloudflareを経由します。MXやTXTを同じようにプロキシ化するものではありません。
導入前には、Webサイト用の接続先だけでなく、メールや所有権確認に使っているDNSレコードも控えます。レンタルサーバーや別サービスがDNSを管理している場合は、Cloudflare側の説明だけで変更対象を決めず、そのサービスの接続条件も合わせます。
HTTPSも区間を分けて見ます。ブラウザからCloudflareへ暗号化されていても、Cloudflareから元サーバーへの接続条件は別です。Full (strict)を使うには、元サーバー側がHTTPSで応答し、有効期限・対象名・信頼の条件を満たす証明書が必要です。証明書エラーを、キャッシュ設定の問題として直そうとしないでください。
標準ではHTMLをキャッシュしない。APOは別に判断する
標準キャッシュの公式説明では、HTMLとJSONは標準のキャッシュ対象外です。画像などの対象ファイルと、記事のHTMLを同じ扱いにしないようにします。Cache Rulesなどで対象を変えると、この前提も変わります。
WordPress向けAPOは、HTMLなどの動的コンテンツもCloudflare側で扱う機能です。公式の導入説明では、FreeプランはAPOの購入が必要で、Pro以上とは導入条件が異なります。また、WordPressプラグインとの接続や、ほかのキャッシュ機能との相性確認を求めています。「無料でCloudflareを使う」と「APOまで無料で使う」を一緒にしないことです。
最初から複数のキャッシュ機能を一度に変更すると、古い表示を返している場所が分かりにくくなります。今回変更する層を一つ決め、変更前の設定と、元に戻す範囲を記録して試します。
公開記事・管理画面・ログイン後・フォームを分ける
次は検証用サイトで使う試験設計の記入例です。結果のログではありません。公開記事にはテスト用の更新番号を入れ、個人情報を使わず動きを追えるようにします。
| 対象 | 試す操作 | 合格を判断する材料 |
|---|---|---|
| 公開記事／test-article | 未ログインで取得。本文を「版A」から「版B」へ更新し、再取得 | 最新の本文、取得日時、HTTP応答、CF-Cache-Status。HTMLキャッシュ採用時は破棄後の反映も確認 |
| 管理画面／wp-admin/ | テストユーザーでログインし記事を保存 | 管理操作が成立し、その画面を未ログインの別ブラウザに共有表示しない |
| ログイン後のページ | 試験ユーザーAとB、未ログインの3状態で同じURLを開く | 利用者別の内容が別の状態に混ざらない。ヘッダーだけでなく本文も照合 |
| フォーム | 新規表示→試験データ送信→再表示。必要なら時間を置いて再試験 | 入力・受付・保存・通知が設計どおり成立。古い確認画面や利用者別情報を再利用しない |
フォームの表示ページは公開でも、送信結果や入力値は同じ性質ではありません。確認画面、ログイン状態、トークン、セッションの扱いはフォームの実装で変わります。「/contactだけ除外すれば全部安全」とパス一つで決めず、実際の送信先と、個別内容を返すURLも洗い出します。
会員サイトや買い物かごがある場合、この4行だけでは足りません。会員ランク、カート、決済前後など、表示が人や状態で変わる箇所を追加します。今回はそれらを含む構成の動作は確認していません。
HITを増やすことより、対象に合う応答かを見る
ブラウザの開発者ツールでNetworkを開き、画像ではなく対象ページ本体のリクエストを選び、レスポンスヘッダーを見ます。ページURL、ログイン状態、取得時刻、本文の版と一緒に保存します。認証Cookieやトークンの値は公開用の記録から外します。
| CF-Cache-Status | 公式仕様での意味 | 次に見るもの |
|---|---|---|
| HIT | Cloudflareのキャッシュに対象があった | 公開してよい内容か、更新後の版が正しいか |
| MISS | キャッシュ可能だが、その時点では保存されておらず元サーバーから取得 | 初回か、設定・応答の条件に合うか |
| DYNAMIC | リクエスト時点でキャッシュ対象外と判断 | 標準対象外のHTMLか、除外ルールが合っているか |
| BYPASS | 対象として進んだ後、応答やそのヘッダーの条件で保存を回避 | Cache-ControlやSet-Cookie等と適用設定の関係 |
この表はCloudflareのキャッシュ応答の説明に基づきます。ログイン用のページでHITにすることを目標にしません。また、ブラウザ内のメモリキャッシュだけで表示された結果を、Cloudflareから今返された応答として記録しないようにします。
記録の一行は「未ログイン／GET／test-article／日時／HTTP状態／CF-Cache-Status／本文は版Aまたは版B／変更した設定」の順にすると追いやすくなります。今回、その実測値を埋めたログは作っていません。架空のHITやMISSを入れても、検証にはならないためです。
更新が反映されない時は、どこで古くなったか切り分ける
最初にWordPressで保存した内容が正しいかを見ます。次に、WordPressのキャッシュ機能・サーバー側キャッシュ・Cloudflare・ブラウザを分けます。すべてを同時に消して直ったとしても、原因の層は分からないままです。
- 編集したURLと、見ているURLが同じかを確かめる。別ドメインや末尾違いも確認する。
- 管理画面の保存内容と公開HTMLの本文を照合する。
- 採用しているキャッシュ機能の更新・破棄方法で、まず対象URLを扱う。
- 未ログインの別ブラウザで再取得し、本文の版と応答をもう一度記録する。
- ログイン・フォームの試験も繰り返し、公開記事だけ直って他の動作が崩れていないかを見る。
Cloudflare側で消したという受付表示と、実際に読者へ返る最新本文も別です。公式のパージ説明も、処理の受付だけで対象コンテンツの状態を断定しない確認を案内しています。自分の試験では、ヘッダーに加えて版Bの本文そのものが返ることまで見ます。
導入の判定は「スコアが上がった」より先に、「最新の公開内容を、正しい状態の読者へ返せる」です。その条件を満たしたうえで、同じページ・端末・測定方法による速度の比較へ進めます。