CDNキャッシュによって検索クローラーが古いページを取得することはありますか？

はい。検索クローラーがアクセスするCDNノードに旧バージョンのHTMLがまだ保存されており、キャッシュルールによってそのコピーの使用が許可されている場合、クローラーには古いページが返されます。オリジンサーバーの更新が成功したからといって、エッジノードも更新済みとは限りません。ただし、検索結果に古いタイトルやスニペットが表示されているだけでは、CDNキャッシュの異常を直接証明できません。クロール、インデックス処理、検索結果の表示はそれぞれ別の段階です。

cdn caching for search crawlers の問題を判断するには、まずクローラーが実際に受信したレスポンス内容を確認し、次にキャッシュが更新されなかった理由を調べます。ブラウザーで新版が表示されることや、検索結果に旧版が表示されることだけでは、原因を特定できません。

旧ページがどの層で使われ続けているのか

1回のリクエストがエッジノード、上位キャッシュ、オリジンアプリケーションのキャッシュを経由することがあります。最外層のノードを消去しても、上位層に古いコピーが残っていれば、エッジノードは再び古いコンテンツを取得します。そのため、「更新に成功したかどうか」は、更新対象の範囲と併せて判断する必要があります。特定のURL、ディレクトリ全体、キャッシュタグ、異なるホスト名では、対象となるオブジェクトがそれぞれ異なります。

キャッシュキーによっても結論は変わります。同じ記事でも、パラメーター付きURL、パラメーターなしURL、異なる言語パスやホスト名は、それぞれ別のコピーに対応する場合があります。キャッシュルールでデバイス、地域、リクエストヘッダーがキャッシュキーに含まれていると、ブラウザーとクローラーが異なるバージョンにヒットする可能性もあります。反対に、リクエストヘッダーで多言語コンテンツを切り替えているのに、キャッシュが正しく区別されていない場合は、言語が混在することもあります。

一部の設定では、バックグラウンドで更新中に古いコンテンツを先に返したり、オリジンサーバーの障害時に期限切れのコピーを使用したりできます。この場合、キャッシュの有効期限が切れていても、古いページが送信されることがあります。「期限切れ」であることは、「再び返されることがない」という意味ではありません。

どのレスポンスヘッダーが判断に影響するのか

まずHTMLドキュメントのリクエストを確認し、画像、スクリプト、スタイルだけを調べないようにします。静的リソースのキャッシュ期間が長くても、記事本文に同じ有効期間が設定されているとは限りません。以下のフィールドは、CDNの実際のルールと照らし合わせて確認する必要があります。

• Cache-Control: max-age は、レスポンスの鮮度期間を示します。共有キャッシュでは、s-maxage が設定されている場合、こちらを重点的に確認します。CDNの管理画面では、オリジンのレスポンスヘッダーを上書きするエッジキャッシュルールが設定されていることもあります。
• no-cache はレスポンスの保存を許可しますが、再使用前の検証が必要です。no-store はレスポンスを保存しないよう指示します。この2つを混同すると、設定と想定に食い違いが生じます。
• Age はキャッシュレスポンスの経過時間を判断する手掛かりになりますが、本文が新しいか古いかを単独で証明することはできません。キャッシュヒットの表示もヒット状態を示すにすぎないため、本文中のバージョン情報と併せて確認する必要があります。
• ETag、Last-Modified は条件付きリクエストに使用されます。本文が変更されてもバリデーターが正しく更新されない場合、誤って304が返され、リクエスト元が既存のコピーを引き続き使用する可能性があります。

stale-while-revalidate は、指定された期間内に期限切れのコンテンツを先に返し、バックグラウンドで検証することを許可します。stale-if-error は、特定のエラー条件下で古いコピーを使用することを許可します。更新のタイミングを厳密に管理する必要があるページでは、キャッシュ期間を1つ調整するだけでなく、これらの期間を許容できるか明確にする必要があります。

「旧ページが取得された」ことを検証可能な証拠にする

問題が発生している完全なURLを1つ選び、新しいタイトル、本文の一節、またはバージョンマーカーのうち、何が表示されるべきかを記録します。通常のGETリクエストでレスポンスヘッダーと本文を保存します。たとえば、curl -sS -D headers.txt -o page.html 'https://example.com/article'を実行します。HEADリクエストだけでは本文を確認できず、HEADとGETで処理が異なるサービスもあります。

次に、ホスト名、パス、パラメーター、言語条件を同じに保ったうえで、オリジンサーバーとCDNから返される内容を比較します。オリジンのIPアドレスに直接アクセスすると、デフォルトサイトに接続され、誤った判断につながることがあります。オリジンを比較する際は、正しいホスト名とTLS設定を維持できる方法でアクセスしてください。オリジン自体が旧版であれば、まず公開状態、アプリケーションキャッシュ、またはバックエンドノード間の同期を調べます。

ランダムなパラメーターを追加する方法だけを、唯一の検証手段として使わないでください。パラメーターによってキャッシュが回避されることもあれば、キャッシュキーで無視されることもあります。また、テスト用URLはクローラーが実際にアクセスするURLとは異なります。リクエストにCache-Control: no-cacheを追加しても、サーバー側で更新されたことの確認にはなりません。実際の処理はCDNの設定によって異なります。

リクエストのUser-Agentをクローラー名に変更しても、フィールドによるルールの振り分けをテストできるだけで、実際のクローラーにも同じレスポンスが返されることの証明にはなりません。より有効な証拠は、エッジのアクセスログに記録された時刻、完全なURL、ノード、キャッシュ状態、コンテンツのバージョンです。また、検索エンジンが公開している方法に従って、リクエスト元を確認します。オリジンサーバーのログに記録がなくても、リクエストがエッジでキャッシュにヒットしただけの可能性があります。

更新後、どのバージョンを検証するのか

公開時は、まずオリジンサーバーから新版が返されることを確認し、その後、該当するキャッシュを更新します。順序が逆だと、オリジンの更新前にノードが旧コンテンツを再度読み込んでしまいます。上位キャッシュ、ページの別名、多言語パスがある場合は、実際のキャッシュ構成に従って処理し、更新タスクが完了したことを確認します。APIがリクエストを受け付けたと応答しても、すべてのノードが更新されたとは限りません。

更新後は、元のURLで本文を再取得し、新しいコンテンツを確認したうえで、キャッシュに再びヒットした際にも新版が返されるかを確認します。複数の海外地域に関わる場合は、地域ごとの検証も追加してください。1つのノードでの結果が、すべてのノードを代表するわけではありません。HTMLを更新してもページに古い文言が表示される場合は、本文が別のAPIから読み込まれていないか確認します。そのAPIには独立したキャッシュが設定されている可能性があります。

公開記録にコンテンツのバージョン、更新対象、検証結果を残しておくと、異常発生時に公開の失敗とキャッシュの反映遅延を区別しやすくなります。このプロセスは、デジタルトランスフォーメーションが企業のレジリエンスに与える影響に関する考察で取り上げられる具体的な技術課題にもなります。復旧プロセスでは、各層から返されるコンテンツを検証できる必要があります。

実際のクロールで新版が取得されているにもかかわらず検索結果が古い場合は、引き続きクロール時刻、正規URL、インデックス処理の状態を確認します。この段階でキャッシュを繰り返し消去しても、検索結果がすぐに更新されるわけではありません。また、クローラーにすべてのキャッシュを長期間回避させることも適切ではありません。ページの内容に一貫性があり、キャッシュルールが説明可能で、更新結果を検証できることが、継続的な調査に役立ちます。