WordPressを更新しても反映されないときの確認順｜自分だけ・訪問者だけを切り分け
WordPressで文章や画像を変更して保存したのに、サイトを見ると古いまま。自分の画面では直っているのに、別の人から「変わっていない」と言われる。そんなときは、最初からキャッシュを全部消すのではなく、保存・確認先・配信のどこで新しい内容が止まっているかを順番に確認しましょう。
最初の確認は「保存が完了しているか」「同じページの通常URLを見ているか」「別の閲覧環境でも古いか」の三つです。編集画面に新しい文章が見えていても、公開中の本文へ保存されているとは限りません。また、シークレットウィンドウで古い内容が出ても、キャッシュが原因ではないと断定できません。サーバー側に残る古い表示は、別のブラウザにも届くためです。
この記事では、本番サイトと切り離したWordPressで「変更を保存していない状態」と「保存済みだが配信側に古い表示が残る状態」を再現しました。編集担当者向けの確認から始め、後半では画像・CSS・ヘッドレス構成、開発者ツールでの調査、担当者へ渡す記録まで整理します。
検証日：2026年9月10日。WordPress 6.8.3・PHP 8.3.33のローカル検証環境を使用しています。最新版の管理画面とボタン名が一致するとは限りません。キャッシュの再現には自作の検証用サーバーを使い、特定のWordPressプラグインやCDNの不具合を再現したものではありません。本番サイトのキャッシュ設定・プラグイン・公開記事は変更していません。
まずこの順番で確認｜更新が反映されないときの早見表
「反映されない」ときの原因は一つではありません。公開ボタンの押し忘れと、古いCSSの配信では、必要な対処が違います。次の表で一番近い状態を選び、その行の確認から始めてください。複数の問題が重なっていることもあるため、変更する箇所は一度に一つにします。
| 起きていること | 最初に確認 | 次に調べる対象 |
|---|---|---|
| 編集画面だけ新しい | 保存完了・公開状態・更新エラー | 未保存、下書き、予約、公開中の内容との差 |
| プレビューは新しいが通常URLは古い | 同じ記事を見ているか | 公開保存、訪問者向けキャッシュ、別の配信処理 |
| 自分のブラウザだけ古い | 別のブラウザや新しい閲覧セッション | ブラウザキャッシュ、拡張機能、ログイン条件 |
| 自分は新しいが訪問者は古い | ログアウト状態の通常URL | 訪問者向けのページキャッシュ、CDN、表示条件 |
| 画像だけ差し替わらない | 実際に読み込んだ画像URL | 同名ファイルのキャッシュ、縮小画像、配信変換 |
| 文字は変わるが見た目は古い | 実際に読み込んだCSS | 別ファイル、生成済みCSS、優先順位、キャッシュ |
| 特定の場所だけ変わらない | 変更したパーツと表示元 | テンプレート、同期パターン、一覧カード、別ページ |
| 検索結果やSNSだけ古い | サイトの通常URLは新しいか | 外部サービスの再取得・表示情報の更新 |
たとえば本文の修正が保存されていなければ、キャッシュを消しても古い本文しか生成できません。逆に保存内容が新しくても、配信側が前のHTMLを返しているなら、編集画面で同じ修正を何度も繰り返す必要はありません。「保存された内容」と「届いた内容」を分けると、調べる場所が見えてきます。
確認を始める前に、対象のページURL、変更した箇所、変更前と変更後の内容、最後に保存した時刻を控えてください。「更新が効かない」だけよりも、「受付時間を10時から9時へ変更したが、通常URLでは10時のまま」と記録したほうが、改善したかを確実に判断できます。
確認①：変更は本当に保存されている？下書き・公開・自動保存を分ける
保存ボタンを押した後の完了表示まで確認する
最初に記事や固定ページの編集画面へ戻り、保存・更新処理が完了しているか確認します。ボタンを押した直後にタブを閉じたり、通信が切れたりすると、画面上の内容とサーバーに残る内容が違うことがあります。エラー通知や保存中の表示が残っていないかを確認してください。
ボタン名は、バージョン、公開状態、編集画面によって「保存」「更新」「公開」などに変わります。特定の名前だけを探すのではなく、今どの状態の内容をどこへ保存しようとしているかを見ます。公開中のページを更新する操作と、まだ公開していない記事を下書き保存する操作は、結果が違います。
入力した文章が失われる心配がある場合は、画面を再読み込みする前に、変更部分を手元へ控えます。機密情報を含む文章を外部のメモサービスへ送る必要はありません。ローカルのメモや管理された保存先を使い、保存結果が確認できるまで編集画面を残しておくと安全です。
下書きや予約状態なら、通常の訪問者に出ないことがある
下書きとして保存した記事は、保存が成功していても、そのまま一般公開されるわけではありません。予約投稿なら、予定時刻やサイトのタイムゾーンも確認します。公開済みの記事を変更しているつもりで、複製した下書きや別の言語の記事を編集していた、というケースもあります。
公開状態は必ず画面で確認し、見せてはいけない下書きを「確認のため」に公開しないでください。予定していない公開や予約解除は、反映不具合の診断とは別の操作です。公開権限がない編集担当者の場合は、承認待ちになっていないかを確認し、必要なら公開担当者へ依頼します。
自動保存・リビジョンがあることと、公開反映は別
WordPressには変更履歴を扱うリビジョンや自動保存の仕組みがあります。ただし、自動保存された編集内容があるからといって、公開中のページがその内容へ更新されたとは限りません。画面に復元の案内が出ている場合は、復元候補と現在の公開内容を混同しないようにします。
履歴を確認する際は、どの時刻にどの文章が保存されたかを見ます。古い履歴へ戻す操作は、反映を確認する操作ではありません。確認だけのつもりで復元し、他の人が加えた変更まで戻さないようにしてください。履歴の基本的な役割はWordPress公式のリビジョン説明で確認できます。
保存時に「更新に失敗しました」などのエラーが出る場合は、先にそのエラーを解決します。REST APIの通信、認証、サーバー応答などを調べる必要がありますが、エラーの内容を見ずにセキュリティ機能を無効化するのは避けます。保存できていない状態でキャッシュ削除を繰り返しても、目的の文章は公開データへ届きません。
再現検証①：編集画面が版Bでも、未保存ならWordPressは版Aのまま
未保存の状態を確認するため、ローカルWordPressに「受付時間：10:00〜17:00（版A）」という検証用の記事を用意しました。これを編集画面で「受付時間：09:00〜18:00（版B）」へ変更し、まだ保存しない状態で、WordPressに保存されている本文を別に取得しました。
結果は、編集画面では版B、保存済みの本文は版Aでした。見ている文章が違うのはキャッシュの不具合ではなく、編集途中の変更がまだ保存されていないためです。この段階で訪問者のブラウザを新しくしても、WordPressが返す元の本文は版Aのままです。
| 確認箇所 | 未保存のとき | 保存完了後 |
|---|---|---|
| 編集画面の文章 | 09:00〜18:00／版B | 09:00〜18:00／版B |
| WordPressの保存済み本文 | 10:00〜17:00／版A | 09:00〜18:00／版B |
| この時点での対処 | 保存操作と完了の確認 | 配信された表示の確認へ進む |
その後、編集画面の保存処理を実行し、WordPressから本文を読み直すと版Bになりました。ここで初めて、保存自体は成功したと確認できます。保存ボタンの見た目だけでなく、保存先の内容を確かめると、未保存と配信側の問題を分離できます。
今回のテストは、作成したローカル記事だけで行っています。本番で営業時間や料金を仮の数字へ書き換えて確認する方法は勧めません。実際の修正内容を対象に比較するか、非公開の検証環境で、誤って見られても実情報と誤解されないテスト用の表示を使ってください。
確認②：編集したページと、確認しているURLは同じ？
保存が完了しているのに古い場合は、キャッシュを疑う前に確認先をそろえます。WordPressには記事詳細、固定ページ、カテゴリー一覧、検索結果、トップページなど、似た内容が表示される複数の場所があります。同じタイトルの文章が出ていても、編集した本文をそのまま使っているとは限りません。
プレビューURLと通常URLを分ける
管理画面から開いたプレビューは、ログイン状態やプレビュー用の情報を使って表示される場合があります。その結果と、訪問者が開く通常URLを同じものとして扱わないでください。通常URLをコピーして別の閲覧環境でも確認し、両方で同じ変更箇所を見比べます。
URLはドメイン名だけでなく、サブドメイン、パス、末尾、クエリ文字列まで確認します。テストサイトを編集して本番を見ている、旧URLから別ページへ転送されている、管理用ドメインを見ている、といった違いがあります。転送がある場合は、開いた後のアドレスバーも確認してください。
プレビューは新しいのに通常URLが古い場合、公開中の内容が更新されていない可能性と、公開側のキャッシュが古い可能性の両方が残ります。「プレビューが新しいから保存は絶対に成功している」と結論づけず、前の節の公開状態・保存完了と合わせて判断します。
トップページや一覧の文章は、別の場所から出ていないか
記事本文を直したのに一覧カードの説明が変わらない場合、一覧では本文ではなく抜粋や独自の紹介文を使っているかもしれません。ページ上部の案内はテンプレート、フッターは共通パーツ、トップページは専用の固定ページから出していることもあります。
画像や文章を見た目だけで追わず、その表示がどこで管理されているかを確認します。複製したパーツと同期されるパーツの違い、スマホ用とPC用に分かれた要素、条件付きで表示されるバナーも確認対象です。違う場所を編集していた場合、キャッシュを消しても目的の表示は変わりません。
テーマやファイルを修正した場合は、手元のファイルを保存しただけなのか、実際にサーバーへ配置したのかも分けます。変更元のフォルダーと配信先のフォルダーが違うまま作業を続けないでください。WordPress公式の変更が見えない場合の案内でも、キャッシュだけでなく確認先やテンプレートの違いが挙げられています。
確認③：自分だけ古い？訪問者だけ古い？閲覧条件をそろえる
同じ通常URLを、今使っているブラウザと、別の閲覧環境で開いて比較します。目的は、どちらかを「正しい画面」と決めつけることではなく、どの条件で古い表示が出るかを知ることです。ログイン状態、画面幅、言語、地域などで表示を分けているサイトでは、キャッシュ以外の差も考えます。
| 比較結果 | 考えられること | まだ断定できないこと |
|---|---|---|
| 普段のブラウザだけ古い | ブラウザ内の保存データや拡張機能、閲覧条件の影響 | 必ずブラウザキャッシュが原因とは限らない |
| ログイン中だけ新しい | 管理者向けはキャッシュを迂回するなど、経路が異なる | 特定のプラグインが原因とは限らない |
| 新しい閲覧環境でも古い | 元の保存内容、共通の配信経路、確認先の問題 | キャッシュが無関係とは限らない |
| スマホだけ違う | レスポンシブ表示、端末別の部品や配信条件 | 端末の不具合やCDNと即断しない |
シークレットウィンドウは、サイト側のキャッシュを消さない
シークレットウィンドウや別ブラウザは、普段の閲覧環境と分けて比較する手段です。しかし、それでサーバーやCDNの古いページまで消えるわけではありません。また、開いている同じシークレットセッション内では、そのセッションの状態が使われます。「シークレットなら毎回完全に何もない状態」とは考えないでください。
比較時は、通常URL、変更箇所、画面幅をできるだけ合わせ、ログインしていないことも確認します。会員サイトなどでログインが必要なページは、権限の違うアカウントへ勝手に切り替えず、担当者と確認方法を決めてください。別人の会員情報が見えるなどの症状は、単なる更新遅延として扱わず、運用担当者へ直ちに連絡します。
強制再読み込みで変わるかを、一つの手がかりにする
ブラウザには、通常の再読み込みよりもキャッシュの再利用を抑えて読み直す操作があります。WindowsのChromeなどではCtrl＋Shift＋Rが使えますが、ショートカットや動作はブラウザごとに確認してください。まず変更内容を控え、公開ページ側で試します。保存していない編集画面を不用意に再読み込みしないようにします。
強制再読み込みで直った場合は、ブラウザ側の再利用が関係した可能性があります。ただし、その操作がサイト全体のキャッシュを消したわけではありません。自分に新しい内容が見えた後も、訪問者向けの通常表示を確認します。すべての読者へ強制再読み込みをお願いし続けることを、恒久的な解決にはしません。
再現検証②：保存済みでも、共通のキャッシュが古い表示を返す
次に、WordPressへの保存は成功しているのに、別経路では古い表示が出る状況を作りました。検証用サーバーは、最初に取得した記事本文を一つだけ保持し、対象ページへのアクセスに同じ内容を返します。更新時の自動削除を意図的に入れず、版Aを残したままWordPressの本文を版Bへ更新しました。
保存済み本文を直接取得する経路では版B、キャッシュ経由の再現用ページでは版Aになりました。ブラウザ側の保存が原因にならないよう、検証用ページのHTTP応答にはno-storeを指定しています。その上でも古い内容が届くのは、自作サーバーが保持した本文を返しているからです。
ここでいう「直接取得」は、検証スクリプトがWordPressの保存済み本文を読み直す専用の経路です。管理者としてログインすれば必ず直接取得になる、という意味ではありません。自作キャッシュにはCookieによる管理者・訪問者の分岐を実装していないため、ログイン別の製品挙動を検証したとは扱いません。
| 行った確認 | 見えた内容 | 今回の意味 |
|---|---|---|
| WordPressに保存した本文を取得 | 版B | 保存は成功している |
| キャッシュ経由のページを取得 | 版A | 保持された古い本文が返った |
| 新しいブラウザコンテキストで開く | 版A | 普段のブラウザの履歴だけが原因ではない |
| ブラウザキャッシュを無効化して再取得 | 版A | ブラウザ側の無効化ではサーバー側の本文は変わらない |
| URLに確認用のクエリを追加 | 版A | 今回の自作キャッシュはクエリをキーに含めていない |
| 対象ページ一つの保持内容を削除 | 版B | WordPressの新しい本文から作り直された |
クエリ文字列を付けても版Aだったのは、今回の自作サーバーがパスだけでキャッシュを識別する設計だからです。すべてのCDNやプラグインが同じ動きをするわけではありません。ただし「URLの末尾に適当な文字を付ければ必ずキャッシュを避けられる」という考え方には、条件があることが分かります。
対象だけを削除した後は、版Bで再生成された
最後に、検証用サーバーが保持する対象ページの本文を一つだけ削除し、同じ通常経路へ再アクセスしました。結果は版Bになり、次のアクセスも版Bでした。再び元のWordPressを編集したわけではありません。保存はすでに成功していたので、古い内容を返していた箇所を更新するだけで表示がそろいました。
これは、どのサイトでも手動削除が必要だという意味ではありません。実際のキャッシュ製品では、記事更新時の自動削除や有効期限、事前生成などの仕組みがあります。症状が繰り返されるなら、手動で消し続けるより、更新通知が正しく届いているか、対象URLが削除範囲へ含まれるかを確認するほうが重要です。
どのキャッシュを確認する？ブラウザ・WordPress・サーバー・CDN
「キャッシュを削除してください」と言われても、どこを消すかが不明だと迷います。まず、今のサイトで何が使われているかを確認します。WordPressのプラグイン一覧に見当たらなくても、レンタルサーバーやCDNにキャッシュ機能がある場合があります。一方、WordPressというだけで必ずページ全体のキャッシュが有効とは限りません。
| 場所 | 主な確認対象 | 勘違いしやすい点 |
|---|---|---|
| ブラウザ | 手元で再利用されるHTML・画像・CSSなど | 削除してもサーバー側の保持内容は消えない |
| WordPressのページキャッシュ | プラグインなどが生成したページの出力 | 本文以外の変更で自動更新されるかは設定次第 |
| サーバー側のキャッシュ | ホスティングやリバースプロキシの配信結果 | 管理画面のプラグイン停止だけでは変わらない場合がある |
| CDN | 配信拠点が保持するページやファイル | URL・ヘッダー・クエリなどの識別条件が製品で異なる |
| 別構成のフロントエンド | API結果、生成済みページ、再ビルドの状態 | WordPress側の削除だけでは新しいページが作られない場合がある |
ページキャッシュとオブジェクトキャッシュを同じものにしない
WordPressの処理途中で使うデータを保持する仕組みと、完成したページのHTMLを保持する仕組みは別です。たとえばオブジェクトキャッシュを消したからといって、その外側にあるCDNの古いHTMLまで消えるとは限りません。管理画面で「キャッシュ」という言葉を見つけたからといって、全部が同じ対象ではありません。
構成が分からないときは、プラグイン名、サーバーのプランや機能名、CDNの利用有無を整理して担当者へ確認します。わからない設定を片っ端から無効化するより、「通常URLの本文が古い。WordPressの保存内容は新しい」と事実を伝えるほうが、調査対象を絞れます。
削除するなら、対象ページや対象ファイルから
利用中の製品に対象URLだけを削除する機能がある場合は、その範囲から検討します。サイト全体を一括削除すると、多くのページでキャッシュの再生成が発生し、アクセスの多い時間帯には負荷が増える可能性があります。更新対象が一記事なのか、全ページ共通のヘッダーなのかによって、必要な範囲も違います。
たとえばCloudflareにはURL単位の削除方法が用意されていますが、キャッシュキーをカスタマイズしている場合は、指定すべき条件にも注意が必要です。利用している場合だけ、公式の単一ファイル削除の説明を確認してください。本記事では実際のCloudflareアカウントの設定や削除操作を行っていません。
記事本文を更新した場合でも、トップページの紹介文やカテゴリー一覧に抜粋を載せていれば、それらも更新対象になることがあります。対象URLだけで直った後は、その記事への導線にも古い文言が残っていないか確認します。「最小範囲」とは一律に一ページだけという意味ではなく、変更内容の影響先を把握して必要な範囲を選ぶことです。
画像だけ反映されないとき｜同名上書き・縮小画像・実際の取得URL
本文は新しいのに画像だけ古い場合、ページのHTMLを読み直しても、同じURLの画像が再利用されていることがあります。また、元画像を変更しても、記事が参照しているのは別の縮小画像や変換済みの画像かもしれません。まず、どの画像ファイルを実際に見ているかを確認します。
- 編集画面で、画像ブロックが意図したメディアを選んでいるか確認します。
- 公開ページで問題の画像を開き、元のメディアURLと違いがないか確認します。
- 制作担当者はcurrentSrcやNetworkで、実際に取得された画像URLを記録します。
- 縮小版・画像プロキシ・CDNなど、別の生成や配信処理が挟まっていないかを調べます。
- 変更内容に応じて、対象画像の配信キャッシュや派生画像を扱います。元ファイルの削除から始めません。
ファイル名を変えて新しい画像として登録する方法は、旧URLとの区別に役立ちます。ただし、新しい画像を登録しただけでは、記事本文やアイキャッチの参照先が自動で切り替わるとは限りません。新しいメディアを選び直し、保存後に公開ページがそのURLを使っているかまで確認します。
同名上書きを続ける運用では、古い版と新しい版を識別しにくくなります。ファイル名に版や日付を含める運用を選ぶ場合も、無関係な画像を大量に複製するのではなく、原本・掲載版・差し替え履歴を整理します。旧画像を削除するかどうかは、他ページからの参照を確認したうえで別に判断してください。
サムネイルの再生成は、既存のメディアファイルへ影響し得る操作です。古い画像が出るからという理由だけで全画像を再生成せず、バックアップと検証環境を用意して、必要なサイズと対象を絞ります。画像の内容は新しいのにぼやける場合は、更新反映とは別に、配信サイズや圧縮を調べる必要があります。
CSSだけ反映されないとき｜古いファイルと、効かない指定を区別する
色や余白が変わらない場合、古いCSSを読み込んでいるケースと、新しいCSSは届いているのに指定が効かないケースがあります。キャッシュ削除で直せるのは前者に関係する部分です。新しいルールが読み込まれていても、別のルールが優先されているなら、削除を繰り返しても意図した見た目にはなりません。
読み込まれたCSSに、自分の変更が入っているか
開発者ツールのNetworkでCSSファイルを選び、応答本文に変更した指定が含まれているか確認します。編集したファイル名と、ページが実際に読み込んだファイル名が同じかも見ます。親テーマではなく子テーマ、元のSCSSではなくコンパイル済みCSS、結合・圧縮後のファイルが配信されている場合があります。
新しい指定が含まれていなければ、アップロード先、ビルド処理、生成済みCSS、配信キャッシュを順番に調べます。新しい指定が含まれていれば、ElementsのStylesやComputedで、どのルールが適用されているかを確認します。打ち消し線が出る指定、セレクターの対象違い、メディアクエリの条件も確認対象です。
PCでは変わったのにスマホでは変わらない場合、スマホ向けの別ルールが残っている可能性があります。画面幅をそろえずに比較すると、キャッシュの差に見えることがあります。確認したビューポート幅と、実機かエミュレーションかを記録してください。
更新版のCSSを識別するバージョン指定
テーマ開発では、CSSの読み込みURLにバージョンを付け、更新されたファイルを区別する方法があります。次は子テーマ内の特定CSSについて、ファイル更新時刻をバージョンに使う例です。既存の読み込み処理があるサイトへ、そのまま追加して二重に読み込ませないでください。
add_action('wp_enqueue_scripts', function () {
$relative = '/assets/css/article.css';
$style_path = get_stylesheet_directory() . $relative;
if (!is_readable($style_path)) {
return;
}
wp_enqueue_style(
'site-article',
get_stylesheet_directory_uri() . $relative,
array(),
(string) filemtime($style_path)
);
});これはPHPの例で、「追加CSS」欄へ貼り付けるコードではありません。制作担当者が既存のテーマ構成と読み込み処理を確認し、検証環境で適用します。wp_enqueue_styleの引数やバージョンの扱いは公式リファレンスで確認できます。ファイルが存在しない場合、この例は読み込みを追加しません。
バージョンを変えても、配信側がクエリを識別に使わない設定なら、意図どおり区別されない場合があります。結合CSSを別途生成するプラグインでは、その生成物の更新も必要です。「末尾に時刻を付ければすべて解決」と考えず、公開ページに新しいURLが出力され、実際のCSS応答が変わったかを確認します。
制作担当者向け：HTTP応答を見て、どこから古い内容が届くか調べる
ここからは、ブラウザの開発者ツールを使う調査です。普段コードを扱わない方は、無理に操作せず、最後の調査メモを担当者へ渡してください。目標は設定を変更することではなく、通常URLで取得したHTML・画像・CSSの内容と、応答の手がかりを記録することです。
Networkで対象のリクエストを一つずつ確認
- 問題の通常ページで開発者ツールを開き、Networkを選びます。
- ページを再読み込みし、本文ならDocument、見た目ならCSS、画像なら該当画像のリクエストを選びます。
- Request URLとStatus Codeを確認し、想定したURLへアクセスしているか見ます。
- Responseで、変更後の文章や指定が実際に届いているかを確認します。
- Headersでキャッシュに関係する情報を記録し、同じ条件の変更前後を比較します。
ChromeのNetworkにあるDisable cacheは、開発者ツールを使った調査時にブラウザキャッシュの影響を切り分ける機能です。WordPress、レンタルサーバー、CDNのキャッシュを削除するボタンではありません。今回の再現テストでも、ブラウザ側のキャッシュを無効化しても自作サーバーの版Aが届きました。機能の条件はChrome公式のNetworkリファレンスで確認できます。
Cache-Control・Age・HITをどう読むか
| 情報 | 読み取れる手がかり | 注意点 |
|---|---|---|
| Cache-Control | HTTPキャッシュの保存や再利用に関する指示 | それだけでアプリ内部の古いデータまで判定できない |
| Age | キャッシュされた応答の経過時間を示す手がかり | 記事の最終更新からの秒数ではない |
| ETag・Last-Modified | 応答の再検証で使われる識別情報 | 値だけで本文が期待どおりかは分からない |
| 製品独自のHIT・MISS表示 | そのキャッシュ層での処理結果 | ヘッダー名と意味は製品の仕様を確認する |
| HTTPステータス | 成功・転送・認証・失敗など | 200だから新しい内容とは限らない |
HITという表示があっても、それだけで不具合とは言えません。最新の内容をキャッシュから高速に返しているなら正常です。MISSでも、その内側の別の層から古いデータを取得する可能性は残ります。ヘッダーだけで結論を出さず、応答本文の変更箇所と合わせて確認します。
Ageはキャッシュ応答の経過時間を扱うもので、WordPressの記事更新日時とは別です。ヘッダーがないからキャッシュが存在しないとも断定できません。基本的な意味はMDNのAgeの説明を参照できます。本記事の図にあるX-Lab-Cacheは自作検証用の独自ヘッダーで、一般的な製品の名称ではありません。
no-cacheは「一切保存しない」という意味ではない
Cache-Controlのno-cacheは、保存した応答を再利用する際に再検証を求める指示で、保存自体を禁止するno-storeとは異なります。名前だけで判断し、「no-cacheを付けたのに残っているからブラウザがおかしい」と考えないでください。基本的な違いはMDNのCache-Controlの説明で確認できます。
また、あとからno-storeを付ける操作を、既存の全キャッシュを消す手段として扱わないでください。どの応答にどの指示が付いているか、その手前に別の配信処理があるかを調べます。サイト全体へ強い非キャッシュ設定を追加すれば、性能や負荷にも影響します。診断のための限定的な設定と、本番で維持する設定は分けて判断します。
応答は新しいのに、画面だけ古い場合
HTMLの応答に新しい文章が入っているのに、画面では古い文章が見える場合は、ページ表示後のJavaScriptや別APIの取得も確認します。初期HTMLの後から別の内容へ置き換えている、非表示のPC用要素と表示中のスマホ用要素を取り違えている、といった可能性があります。
Service Workerを使うサイトでは、ブラウザの通常のHTTPキャッシュとは別の保存や応答処理が関係することもあります。ただし、存在を確認せずにサイトデータを全部削除したり、登録を解除したりする手順は標準策にしません。ログイン状態やオフライン機能へ影響するため、担当者が対象と影響を把握して検証環境から確認します。
ヘッドレスWordPressや静的生成サイトは、公開側の更新処理も確認
WordPressを記事管理に使い、公開サイトを別のアプリや静的生成で構築している場合、WordPressで保存しただけでは公開ページがすぐに作り直されない構成があります。通常のWordPressテーマと同じつもりで、WordPress側のキャッシュだけを消しても解決しない場合があります。
まず、WordPressのAPIから取得した内容は新しいか、公開側がそのAPIをいつ取得する設計か、再生成やデプロイが必要かを確認します。保存時に通知を送る仕組みがあるなら、その通知が成功したか、通知を受けた公開側で処理が完了したかまで追います。途中の成功だけで公開反映まで完了したとは判断しません。
| 確認箇所 | 新しい場合 | 古い場合 |
|---|---|---|
| WordPress保存内容 | API・公開側へ調査を進める | 保存と公開状態を確認 |
| 公開側が取得するAPI応答 | 生成・再検証・配信を確認 | 取得先・APIキャッシュ・公開対象を確認 |
| 生成済みページ | CDN・ブラウザ・表示後処理を確認 | 再生成やデプロイの実行結果を確認 |
認証付きのCMSと公開サイトでドメインが違う場合、CMSのURLを直接開けないこと自体が、公開側の不具合とは限りません。公開側が正規の認証方法で取得する設計を確認します。確認のためにCMSの認証を解除したり、APIの認証情報を記事やスクリーンショットへ載せたりしないでください。
公開側の再ビルドを担当する権限がない場合は、そこで作業を止めて運用担当者へ依頼します。WordPressの編集権限があることと、別の配信システムを変更する権限があることは同じではありません。変更対象の記事、保存時刻、取得APIと公開ページの差を伝えれば、必要な処理を確認しやすくなります。
やみくもに消さない｜安全に修正するための進め方
原因候補が見えてきたら、変更前の設定を記録し、対象を絞って対処します。複数のキャッシュ機能を一度に無効化すると、どれが原因だったか分からなくなります。改善しても元の設定へ戻せず、結果としてサイトが常に重い状態になることも避けたいところです。
- 保存内容と、古い表示が出るURLを確定する。
- 変更前の画面・時刻・設定・応答内容を記録する。
- 検証環境または許可された範囲で、一つの対象に対処する。
- 通常URLを同じ条件で再取得し、変更箇所が新しくなったか確認する。
- ログアウト表示、別の閲覧環境、関連する一覧や画像も確認する。
- 問題がなければ対応内容を記録し、不要な一時設定を戻す。
「全プラグイン停止」「全キャッシュ削除」「テーマの切り替え」「パーマリンク設定の保存し直し」などを、理由なくまとめて実行しないでください。画像やCSSが消える、機能が止まる、URLの扱いが変わるなど、元の問題以外の影響が出る可能性があります。
ファイルが見つからないように見えても、いきなり本番のCSSやテンプレートを削除して確認する必要はありません。読み込んでいるURL、配置先、応答内容を読み取りで確かめる手段があります。保存失敗が続く、認証エラーが出る、別ユーザーの情報が見えるなど、通常の更新遅延と違う症状なら、無理に作業を続けず担当者へ状況を伝えます。
また、ブラウザの「閲覧データ削除」では、キャッシュとCookieや履歴の選択肢を区別してください。Cookieを削除するとログアウトするなど、閲覧状態が変わる場合があります。まず対象サイトの問題を切り分け、関係のないすべてのサイトのログイン状態まで消す操作を安易に案内しないようにします。
修正後のチェックリストと、問い合わせに使える記録
新しい文章が一度見えたら終わりではなく、次のアクセスでも新しい内容が届くか確認します。一時的にキャッシュを避けるURLだけが新しく、通常URLは古いままなら、訪問者向けの反映が完了したとは言えません。実際に案内している通常URLで、確認を締めくくります。
- 保存完了と公開状態を確認し、変更後の本文が残っている。
- プレビューではなく、訪問者が使う通常URLで新しい内容が見える。
- ログアウト状態や新しい閲覧セッションでも結果が一致する。
- PC・スマホで対象の要素を確認し、別の表示条件を取り違えていない。
- 本文だけでなく、画像・CSS・アイキャッチ・一覧への影響も必要な範囲で確認した。
- 再アクセス後も新しい内容が続き、特別なクエリ付きURLだけの改善ではない。
- 一時的に変更した設定を記録し、不要なものは元へ戻した。
制作会社やサーバー会社へ相談するときは、次のように事実を整理すると伝わりやすくなります。原因を断定した文章よりも、確認した条件と結果があるほうが調査に役立ちます。管理画面のパスワードやCookieの値は、このメモに含めないでください。
| 項目 | 記入例 |
|---|---|
| 対象URL | 公開サイトの通常URLと、編集した記事ID |
| 変更内容 | 受付開始を10:00から09:00へ変更 |
| 保存確認 | 保存完了表示あり。保存済み本文では09:00を確認 |
| 確認した日時 | 年月日・時刻・タイムゾーン |
| 新しい表示の条件 | 管理側のプレビューでは09:00 |
| 古い表示の条件 | 通常URLを別の閲覧環境で開くと10:00 |
| 実施した操作 | ブラウザの再取得のみ。サーバー側の設定変更は未実施 |
| お願いしたい確認 | 訪問者向けの配信キャッシュと、更新時の削除対象 |
HTTPヘッダーやHARファイルを共有する場合は、Cookie、認証ヘッダー、トークン付きURL、フォームの送信内容などが含まれていないか確認します。公開の質問掲示板へそのまま添付せず、必要なリクエストの情報だけを安全な方法で共有してください。
よくある疑問｜どれくらい待つ？何度も再発するのはなぜ？
反映するまで何分待てばいい？
サイトの構成や設定によって異なり、一律に「何分待てば直る」とは言えません。保存自体が失敗していれば待っても新しい内容は生成されず、予約状態なら予定時刻の確認が必要です。保存済みでキャッシュの有効期限が分かる場合は、その期限を判断材料にできますが、まずどこで止まっているかを確認します。
削除すれば直るけれど、更新のたびに再発する場合は？
更新時の自動削除や再生成の対象、公開側への通知、複数のキャッシュ層の連携を調べます。ページ本文の更新は検知できても、共通パーツや画像の差し替えが対象外になっている場合があります。毎回の手動対応を通常運用にする前に、どの変更で再発するかを記録して設計や設定を見直します。
キャッシュプラグインを入れていないのに古いのはなぜ？
ブラウザ、サーバー、CDN、別の公開アプリなどに保存が残る場合があります。また、そもそも違うページやテンプレートを編集している可能性もあります。「プラグインがない＝キャッシュは存在しない」とせず、まず保存内容と通常URLを確認し、利用中の配信構成を調べてください。
URLに「?更新日時」を付けて配れば解決する？
検証の手がかりになる場合はありますが、恒久対策とは限りません。クエリをキャッシュの識別に含めない構成では変化せず、含める構成でも元の通常URLが古いまま残る場合があります。読者に案内するURLを増やす前に、通常のアクセス経路で正しい内容が届くように修正します。
Google検索やSNSのタイトルだけ古い場合もキャッシュ削除で直る？
サイトの通常URLが新しくなっているなら、サイト内の反映とは別に、外部サービスがいつ情報を取得し直すかを確認する段階です。サイトのキャッシュを消すだけで、検索結果やSNS上の既存表示が即座に変わるとは限りません。まずページのタイトルや説明、OGPなどが意図どおり出力されているかを確認します。
更新日時が変わっていれば、訪問者にも反映済み？
更新日時は保存の手がかりになりますが、訪問者に届くHTMLや画像まで新しくなった証明ではありません。今回の再現でも、WordPressへ版Bを保存した後に、キャッシュ経由では版Aが返りました。日時と内容の両方を確認し、最後は通常URLの変更箇所で判断してください。
まとめ：保存先と表示先を分ければ、消すべき場所を絞れる
WordPressの更新が反映されないときは、保存完了と公開状態を確認し、同じ通常URLを比較するところから始めます。次に、自分だけ古いのか、訪問者にも古いのかを分け、実際に届いたHTML・画像・CSSを調べます。
今回の検証では、未保存の状態では保存済み本文が版Aのままでした。一方、保存後はWordPressが版Bでも、自作の配信キャッシュが版Aを返しました。編集をやり直すべき問題と、配信側を更新すべき問題は別です。原因を分けてから対象を絞れば、無関係な設定変更や全消去を避けやすくなります。
修正後は、特別な確認用URLではなく通常URLで、ログアウト表示と再アクセスまで確認してください。自分の画面が一度新しくなったことではなく、訪問者へ意図した内容が安定して届くことを、対応完了の基準にしましょう。
