ホームページを修正したのに古い文章や画像が見えるとき、最初にするのは「とりあえず待つ」ことでも、サイト全体のキャッシュを消すことでもありません。公開中のURLを直接開き、ページ自体と、Googleなどの検索結果に出るタイトル・説明のどちらが古いかを先に分けるのが出発点です。ページが古ければ、別の閲覧状態と別端末で再現するかを見てから、ブラウザ、CDN、サーバー、CMSへ範囲を狭めます。一方、ページは新しく検索結果だけ古いなら、公開作業と再クロール・再処理は別の問題です。

この順番にすると、「自分のパソコンだけの表示なのか」「訪問者全体へ古い内容が配信されているのか」「検索結果の更新を待つ段階なのか」を混同しません。確認に必要なのは、対象の公開URL、何を直したか、更新完了時刻、どの端末・ブラウザで見たか、ページと検索結果のどちらが古いかという5点です。技術用語を先に覚えるより、同じURLを同じ条件で比べられる状態を作るほうが、原因へ早く近づけます。

最初に「ページ」と「検索結果」を分ける

「反映されない」という一言には、少なくとも二つの状態があります。一つは、公開URLを開いても本文、画像、色、ボタンなどが修正前のままの状態。もう一つは、公開URLでは新しい内容を確認できるのに、検索結果に表示されるタイトルや説明文が以前のままの状態です。前者はページを届ける途中の確認、後者は検索エンジンがページを読み直した後の確認であり、同じ対処をしても解決しません。

見えている状態 最初に見る場所 次の確認
公開URLの本文や画像が古い別の閲覧状態・別端末ブラウザ、CDN、サーバー、CMS
公開URLは新しいが検索結果が古いページのタイトル設定と説明設定Search ConsoleのURL検査、再クロール後の変化
URLによって新旧が分かれる本番URL、テストURL、転送先公開先や正規URLの取り違え

検索結果からクリックするときは、表示された文言だけで判断せず、開いた先のURLとページ内容まで確認します。検索結果が古くてもページは更新済みの場合があり、逆にタイトルだけ新しくても画像や一部ページが古いケースは残るためです。最初の判定基準は、検索画面ではなく公開URLに届いている内容です。

最初の判定を『公開ページが古い』『検索結果だけ古い』の二つへ分け、同じ対処を繰り返させない。

公開URL・修正内容・完了時刻を最初にそろえる

確認を始める前に、制作会社や更新担当から送られたURLをそのまま開きます。サイト名から探すと、別の下層ページ、以前のURL、テスト環境、転送前のURLへ入ってしまいがちです。アドレス欄は、https、wwwの有無、末尾のスラッシュ、ページ階層まで最後まで照合してください。見た目が同じでもURLが違えば、参照しているキャッシュや公開先は別のものとして扱うのが安全です。

次に、修正内容を「トップページを直した」のような大きな単位ではなく、確認できる単位へ落とします。たとえば「料金ページの2段落目を変更」「同じページの人物写真を差し替え」「ヘッダーの問い合わせボタンの色を変更」のように、文章、画像、見た目、機能を分ける方法です。本文だけ新しく画像だけ古いなら、ページ全体ではなく画像ファイルやスタイルシートの扱いへ範囲を絞れます。

更新完了時刻も重要です。制作側が「8月16日10時に本番公開」、確認側が「同日10時15分にChromeで確認」と残しておけば、いつの状態を比較したのかが分かります。時刻を記録せず数時間後に再確認すると、途中で別の担当者が再公開したり、キャッシュが更新されたりして、最初の現象を再現できなくなりがちです。スクリーンショットにはURLが見える状態と撮影時刻を添え、差し替え前後のどちらを見ているかも一言で示します。

ページ自体が古いときは、手前から奥へ確認する

公開URLのページが古いなら、閲覧者に近い場所から奥へ進むのが基本です。最初からCMSやサーバー設定を触ると、自分の端末だけに古い表示が残っているのか、訪問者全体へ古いデータが配られているのかを見失います。確認は、①別の閲覧状態、②別端末・別回線、③画像などの個別ファイル、④CDNやサーバーキャッシュ、⑤CMSの公開状態という順序。途中で新しい内容が見えた地点が、問題の範囲を分ける境目です。

別端末と別の閲覧状態で端末側を切り分ける

まず、同じ端末で通常の再読み込みを一度行い、変わらなければプライベートブラウズやシークレットウィンドウで同じ公開URLを開きます。次はスマートフォンなどの別端末で、可能なら社内Wi-Fiとは異なるモバイル回線から比較してください。一方だけ新しいなら、公開元よりもブラウザ、端末、回線側に古いデータが残る可能性が高い場面です。すべて同じように古い場合は、端末より奥へ進む根拠になります。

Chromeで開発者ツールを開いている場合、通常の再読み込みはキャッシュを使い、ハード再読み込みはキャッシュを回避しますが、保存済みキャッシュ自体を空にはしません。Windows／Linuxのハード再読み込みはCtrl＋Shift＋R、macOSはCommand＋Shift＋Rです。ショートカットを何度も押すより、一度実行した結果と、プライベートウィンドウ・別端末の結果を並べるほうが切り分けに使えます。（Chrome for Developers「Open Chrome DevTools」）

ブラウザ全体の閲覧データ削除は、ログイン状態や他サイトの表示にも影響するため、最初の一手にしないほうが安全です。まず対象ページだけを別の閲覧状態で比較し、それでも端末固有と判断できたときに、利用ブラウザの手順で対象期間や削除項目を確認します。社内の別担当者にも同じ現象があるかを聞くなら、「見えますか」ではなく、公開URLと修正箇所を送り、現在見える文言や画像を答えてもらう方法が明確です。

画像だけ、見た目だけ古いときはファイル単位で見る

文章は新しいのに画像だけ古い場合、ページの公開自体は成功していて、同じファイル名の画像が途中に残っている可能性があります。画像を新しいタブで開ける環境なら、その画像URLを別端末でも比べてみましょう。制作会社への説明は「ページが古い」ではなく、「本文は新しいが、〇〇の写真だけ差し替え前」で十分です。そう伝えれば、画像ファイル、画像変換、CDNキャッシュへ調査先を絞れます。

色、余白、文字サイズ、ボタンの形だけが古いときは、ページ本文ではなくCSSやJavaScriptなどの読み込みファイルが以前の状態かもしれません。記録するのは、どの画面幅で、どの部品が、期待した状態とどう違うかです。「スマートフォン幅では新しいが、パソコン幅では古い」「トップページのボタンだけで、下層ページは新しい」といった差が、対象ファイルや条件分岐を探す手がかりになります。

画像名やCSS名を変更するか、URLに版を示す値を付けるかは制作側の設計判断です。確認担当が推測でファイル名やURLを書き換えると、リンク切れや重複ファイルを増やすおそれがあります。公開URL、該当箇所、差し替え前後の画像、確認した端末をまとめ、実際に配信されているファイルを制作側で特定してもらうのが確実です。

全端末で古いならCMS・サーバー・CDNを確認する

別端末・別回線でも同じ公開URLが古いなら、閲覧端末より奥側が確認対象です。CMSでは、下書き保存で止まっていないか、公開したページが正しいか、予約公開の時刻や承認待ちが残っていないかを見ます。固定ページと投稿、共通部品、テンプレート、翻訳ページなど似た編集画面が複数あるサイトほど、修正画面と実際の公開URLを照合することが先です。

CMS上では公開済みなのに全端末で古い場合、サーバーキャッシュやCDNが以前のページ・画像・スタイルを返している可能性があります。だからといってサイト全体を無条件に消去するのではなく、対象URLや対象ファイルだけを更新できるか、保守担当へ確認してください。Cloudflareの公式資料にも複数の消去方法があり、推奨されているのは単一ファイルのURL指定です。ただし、これはCloudflareを使うサイトの仕様例にすぎません。自社サイトでは、利用中のCDNやサーバーの手順を基準にします。（Cloudflare Docs「Purge cache」）

ここで制作側が確認したいのは、CMSの保存内容、公開サーバーが返す内容、CDN経由で返る内容のどこから古くなるかです。確認担当は、設定名を推測するより「同じ公開URLを複数端末で見ても同じ箇所が古い」「本文は新しいが画像だけ古い」と範囲を伝えます。すると、ページキャッシュ、画像キャッシュ、共通テンプレート、公開処理のどれを先に調べるかを決めやすくなります。

公開ページ自体が古い場合に、閲覧者に近い場所からCMSまで順番に範囲を狭める流れを一枚で理解させる。

「待てば反映される」と「公開できていない」を区別する

時間を置く判断が有効なのは、公開元に新しい内容があり、途中の更新待ちだと確認できた場合です。CMSが下書きのまま、別ページを編集した、テスト環境へだけ反映した、アップロード先を間違えた、といった状態は、待っても本番ページへ届きません。「更新には時間がかかることがある」という一般論を、公開できていない状態の説明に使わないことが大切です。

文章や画像を通常どおり差し替えただけなら、DNSを最初に疑う必要はありません。DNSが関係するのは、ドメインの向き先を変えるサーバー移転や公開先の切り替え、ドメイン設定変更を同時に行った場面です。普段のページ修正で文章や画像の一部だけが古いなら、URL、公開状態、キャッシュ、読み込みファイルの順で追うほうが筋が通ります。

反映待ちの時間を決めるときは、「何時まで待つ」だけでなく、その時点で何を再確認し、変わらなければ誰が次を調べるかまで決めます。たとえば、公開直後に別端末で確認し、30分後に対象URLを再確認、それでも全端末で古ければ保守担当がCDNとサーバーを確認する、という形です。待つこと自体を作業にせず、次の判定条件と担当を置いてください。

ページは新しいのに検索結果だけ古いときの見方

公開URLの本文や画像が新しければ、訪問者がページを開いた後の内容は更新済みです。検索結果に古いタイトルや説明が残っていても、ブラウザやサーバーのキャッシュを繰り返し消す段階ではありません。次に見るのは、CMSやSEO設定でページの<title>に相当する項目、見出し、メタディスクリプションを想定どおり更新したかどうかです。その元情報がそろってから、検索エンジンの再クロールと再処理を待ちます。

Googleの検索結果に出るタイトルリンクは、ページの<title>をそのまま表示する固定欄ではない仕組みです。ページ上の大見出し、og:title、本文、ページ内外のアンカーテキストなど複数の情報から自動的に決定されるため、管理画面へ入力したタイトルと異なる表示になることがあります。また、更新した情報を認識するには再クロールと再処理が必要です。（Google検索セントラル「Google 検索結果のタイトルリンク（見出し）の変更」）

説明文に見えるスニペットも固定表示ではありません。Googleは主にページ内の内容からスニペットを生成し、より適切に説明できると判断したときにはメタディスクリプションも使います。検索語によって、同じページでも異なるスニペットが出る可能性がある仕組みです。そのため、特定の検索語で見た一回の表示だけで「設定が反映されていない」と断定しないようにします。（Google検索セントラル「検索結果のスニペットを管理する」）

確認するもの 新しければ分かること 古いときの次の確認
公開URLの本文・画像本番ページの公開は完了端末・CDN・サーバー・CMS
ページのタイトル設定・大見出し検索へ渡す元情報は更新済み設定漏れや表示内容の不一致
検索結果のタイトルリンクGoogleが再処理した表示の一部URL検査と時間経過後の再確認
検索結果のスニペット検索語に対する要約表示本文・説明設定と別の検索語で比較

Search Consoleを利用できる場合は、対象の公開URLをURL検査に入れ、Googleが認識しているURLと一致するかを確かめます。更新したURLが少数なら、インデックス登録のリクエストも可能です。ただし、再クロールには数日から数週間かかる場合があり、検索結果への即時表示は保証されません。同じURLへ何度も送っても早くならないため、送信回数を増やすより、公開ページの内容と設定を確認し、次の確認日を決めて経過を追うほうが適切です。（Google検索セントラル「URL の再クロールを Google にリクエストする」）

検索結果の更新待ちと検索順位の変動も、同じ現象ではありません。タイトルや説明が新しくなったかは表示内容の確認ですが、何位に出るかは検索語、競合、ページ評価などを含む別の評価です。修正直後に順位が変わらないことまで「ページが反映されていない」と扱えば、公開確認とSEO評価が混ざってしまいます。まず確認するのは公開ページと検索表示の新旧で、順位は別の期間と指標による評価です。

制作会社へ伝える情報は「再現できる一組」にする

自社で切り分けても原因が分からないときは、技術用語を推測して「キャッシュを消してください」と依頼するより、同じ現象を再現できる情報を一組で渡します。制作会社が欲しいのは、困っているという事実だけでなく、どのURLを、いつ、どの条件で開き、どこが期待と違ったかです。次の5点を一通の連絡にまとめると、聞き直しを減らせます。

  1. 対象の公開URL：検索結果のURLではなく、問題が起きているページの完全なURL
  2. 期待した変更と現在の表示：どの文章・画像・部品をどう直し、今は何が見えているか
  3. 更新完了時刻と確認時刻：制作側の公開時刻、自社が確認した時刻
  4. 確認環境：端末、OS、ブラウザ、社内Wi-Fiかモバイル回線か、プライベートウィンドウでも同じか
  5. ページか検索結果か：公開URLの本文が古いのか、検索結果のタイトル・説明だけが古いのか

連絡文は、たとえば次のように書けます。「対象URLは〇〇。8月16日10時に料金表の見出しを『A』から『B』へ変更したとの連絡を受け、11時にWindowsのChromeとスマートフォンのモバイル回線で確認しましたが、どちらも『A』のままでした。プライベートウィンドウも同じで、Googleの検索結果ではなく公開URLのページ本文に起きている現象です。URLが見えるスクリーンショットを添付します」。この形なら、端末側より奥を調べるべき状況だと伝わる書き方です。

検索結果だけが古い場合は、「公開URLの本文とページタイトル設定は新しい」「検索語は〇〇」「確認日時は〇〇」「検索結果には旧タイトルが出る」という四点をまとめます。検索順位の相談は同じ連絡へ混ぜず、最初に見てもらうのは表示文言の更新状況です。緊急度は、「誤った価格が公開されている」「終了した募集が表示される」「見た目だけ以前のまま」のように利用者への影響で示すと、対応順の判断材料になります。

スクリーンショットは一枚だけ切り取らず、URL、該当箇所、確認時刻が分かる形にします。機密情報や個人情報が画面にある場合、必要部分だけを残したマスキングが必要です。動画なら、最初にURLを映し、古い状態になるまでの操作を短く記録してください。これで再現手順として使える資料になります。

制作会社が同じ現象を再現できるよう、問い合わせ時に一通へまとめる五つの情報を確認できるようにする。

確認順を決めておけば、次の更新でも迷わない

ホームページを修正しても反映されないときは、原因名を当てるより順番が重要です。公開URLを直接開き、ページ自体と検索結果を分ける。ページが古ければ別の閲覧状態と別端末で比べ、画像や見た目だけか、全体かを確認したうえで、CDN・サーバー・CMSへ進む。ページが新しく検索結果だけ古ければ、タイトルや説明の元設定を確認し、Search Consoleと再クロール後の変化を追います。

この流れを社内の更新手順へ入れるなら、公開担当とは別に確認担当を置き、対象URL、修正箇所、公開時刻、確認環境、結果を一行ずつ残します。正常に反映された更新も記録しておけば、「通常はどの段階で新しく見えるか」という自社サイトの基準になるでしょう。次に同じことが起きても、闇雲なキャッシュ削除や再公開ではなく、前回との差から調査を始められます。

最終的に必要なのは、どこが古いかを一言で表せる状態です。「自分のChromeだけ古い」「全端末で画像だけ古い」「ページは新しいが検索結果の旧タイトルが残る」と言えれば、担当者が見るべき場所は大きく絞れます。公開確認と検索結果確認を別々の工程にし、待つ場合にも次の確認時刻と担当を決めておくことが、更新後の不安を長引かせない方法です。

参考資料