COLUMN
ホームページの更新が反映されない原因｜キャッシュは4か所にあって、消す順番があった
ホームページを更新したのに、画面が前のまま変わらない。
このサイトを運用していて、この半年で私が一番時間を取られたのはこの症状だった。
原因を追っていくと、古い画面を覚えている場所が4か所あり、しかも消す順番を間違えると、消したはずの古い画面がまた作り直されることが分かった。
この記事では、その4か所と、それぞれで実際に起きたこと、今の確認の手順を書いておく。
「更新したのに反映されない」と社内で言われたときに、どこから見ればいいかの手がかりになればうれしい。
ホームページの更新が反映されないとき、まず疑う4か所
キャッシュは、一度作った画面を覚えておいて、次に同じページを見られたときにすぐ返すための仕組みだ。
サイトを速く、落ちにくくするためには欠かせない。
ただ、覚えている場所が複数あると、どこか1か所でも古いままだと、見た人には「変わっていない」と映る。
このサイトで古い画面を覚えていたのは、次の4か所だった。
1つ目は、サーバーが組み立てたページ全体を覚えておくページキャッシュ。
2つ目は、検索エンジンやAIに向けた構造化データ（JSON-LD）をページごとに覚えておくキャッシュ。
3つ目は、見ている人のブラウザが覚えているCSSや画像。
4つ目は、Googleの検索結果に出ているタイトルや説明文。
この4つは覚えている期間も、消し方も、誰が消せるかもばらばらだ。
厄介なのは、4か所が重なっていることだ。
ページキャッシュの中には、構造化データも、CSSの読み込み先の指定も、まとめて入っている。
だから構造化データだけ新しくしても、ページキャッシュが古いままなら、外から見える中身は古いまま変わらない。
順番の話は後半で書く。
ページキャッシュ｜管理画面を通さない更新は、古い画面がそのまま返った
10月4日、このサイトのデザインを大きく入れ替えた。
ファイルとデータベースを本番に反映し終えて、トップページを開いた。
見えたのは、入れ替える前のデザインだった。
応答の見出しには「X-Cache: HIT」と出ていて、サーバーが覚えていた古いページをそのまま返していたことが分かった。
コンテナのページキャッシュは、管理画面で記事やページを保存・削除・承認すると、その場で全部消える作りになっている。
覚えておく時間も、既定では2分と短い。
普段の更新で引っかからないのは、このおかげだ。
引っかかったのは、管理画面を通さずに反映したときだった。
デザインの入れ替えは、ファイルの差し替えとデータベースへの直接の書き込みで行った。
保存ボタンを押していないので、キャッシュを消す合図がどこからも出ない。
それ以来、管理画面を通さない反映をした日は、最後にキャッシュの消去を手順に入れている。
消去は管理画面のセキュリティ設定からボタン1つでできる。
アクセスの制限に使っている記録は別の場所にあり、ここでは消さない。
もう1つ、このキャッシュで覚えておきたいことがある。
キャッシュは「どのホストの、どのURLか」でページを見分けていて、ログインの情報やCookieの違いは見ていない。
今回のデザインには明るい表示と暗い表示の2種類があり、その切り替えをCookieで覚えさせると、誰かが見た方の表示がほかの人にも返ってしまう。
そこで切り替えはURLの末尾に「?design=light」を付ける形にした。
キャッシュの見分け方を知らないまま作ると、表示が人によって入れ替わる不具合になっていたと思う。
構造化データのキャッシュ｜ページ単位で残り、本体を更新しても消えなかった
構造化データは、そのページが記事なのか、よくある質問なのか、製品なのかを、検索エンジンやAIに伝えるための情報だ。
コンテナでは、これをページごとにファイルとして覚えておき、毎回組み立て直さずに済むようにしている。
7月に、構造化データの出し方をいくつか直した。
直した直後、ページによっては古い形のまま出ることがあった。
ページ単位のファイルが残っていて、新しい組み立て方が使われていなかった。
このときから、構造化データの出し方を変えたら、CMS本体のバージョン番号を必ず上げることにした。
バージョン番号が覚えておく鍵に含まれているので、番号を上げると古いファイルは一斉に使われなくなる。
運営者の立場で覚えておくのは、もっと簡単なことでいい。
構造化データの設定画面を開いて保存すると、ここのキャッシュは作り直される。
よくある質問を足したのに検索結果の表示用のデータが変わらない、というときは、まずこの保存を試す。
確認は、Googleのリッチリザルトテストにページのアドレスを入れれば、今どんな構造化データが出ているかが見える。
ブラウザのキャッシュ｜CSSは30日間、手元の古いものが使われ続けた
9月25日、コラムの一覧ページ（/column/）を新しく作り、見た目を整えるCSSも足して本番に反映した。
私の画面では新しい見た目になっていた。
ところが社内の人の画面には、新しい見た目が届いていなかった。
原因は、CSSの読み込み先に付けている「?ver=」の番号だった。
ブラウザには「このCSSは30日間変わらないので、手元のものを使ってよい」と伝えている。
番号が同じなら、ブラウザはサーバーに聞きに来ない。
このときは、CSSを差し替えたのに番号が前のままだったので、一度でもサイトを見た人は古いCSSで見続けることになった。
作業していた私は何度も読み直していたので、自分の画面では気づけなかった。
この件のあと、CSSを差し替えれば番号も必ず変わるようにコンテナの本体を直した。
今は、管理画面から保存しても、ファイルを入れ替えても、見ている人のブラウザは新しいCSSを取りに来る。
運営者がこの番号を意識する場面は、もうほとんど無いと思う。
それでも見た目だけが古いときは、画像や、その人のブラウザに残った古いページを疑う。
見た目が変わらないと言われたときに、相手にまずお願いするのは次の2つだ。
1つは、ブラウザのシークレットウィンドウで同じページを開いてもらうこと。
もう1つは、スマートフォンでWi-Fiを切って開いてもらうこと。
どちらかで新しく見えるなら、原因はその人のブラウザに残っている古いCSSにある。
どちらでも古いなら、サーバー側のキャッシュか、そもそも反映が終わっていない。
Googleの検索結果｜サイト側では消せず、読み直しを待つ
4つ目は、自分では消せない場所だ。
ページのタイトルや説明文を直しても、Googleの検索結果に出る文字は、Googleがもう一度そのページを読みに来るまで変わらない。
サーバーの記録を見ると、このサイトにGooglebotが来るのは1日に3〜6ページほどだった。
ページは数百あるので、直したページにいつ順番が回ってくるかは分からない。
検索結果のタイトルが古いままでも、サイトの中ではとっくに新しくなっている、ということがこのサイトでは普通に起きる。
ここでできることは2つある。
1つは、Search Consoleの「URL検査」で直したページのアドレスを入れて、インデックス登録をリクエストすること。
もう1つは、サイトマップの更新日時を正しく出しておくこと。
どちらも「すぐ」ではないが、待つだけよりは早く回ってくる。
社内で「検索結果が古いまま」と言われたら、サイトの不具合ではなく、Googleの読み直し待ちだと伝えるようにしている。
キャッシュを消す順番｜内側から外側へ
4か所を順に見てきたが、実際の作業で一番効いたのは、消す順番を決めたことだった。
今の手順は、内側から外側へ向かって消していく。
最初に、構造化データのキャッシュを作り直す。
次に、ページのソースでCSSの番号が新しくなっていることを確かめる。
そのあとで、ページキャッシュを消す。
最後に、シークレットウィンドウで表示を確かめて、必要ならSearch Consoleで登録をリクエストする。
ページキャッシュを先に消すと、消した直後に誰かがページを開いた時点で、古い構造化データと古いCSSの番号を入れたページがまた作られる。
その古いページが、覚えておく時間のあいだ返り続ける。
「キャッシュを消したのに直らない」と見えるときは、たいていこの順番が逆になっている。
外側のキャッシュは内側の中身を写して作られるので、内側から順に新しくしていけば、二度手間にならない。
更新が反映されないと言われたときの確認表
最後に、社内で使っている確認の順番を書いておく。
上から順に見ていけば、どこに古いものが残っているかが絞れる。
1. 管理画面で保存したか、それとも管理画面を通さずに反映したか。
2. シークレットウィンドウか、Wi-Fiを切ったスマートフォンで新しく見えるか。
3. 見えないなら、ページキャッシュを消してもう一度開く。
4. 見た目は直ったが、検索向けの情報が古いなら、構造化データの設定を開いて保存する。
5. サイトは新しいのに検索結果だけ古いなら、Search Consoleで登録をリクエストして待つ。
キャッシュは悪者ではない。
このサイトでも、アクセスが集中した時間にページが表示されなくなるのを防いでいるのはページキャッシュだ。
困るのは、どこに何が残っているかを知らないときだけだと私は思う。
普段の更新は管理画面から保存すれば済むように作ってあるので、管理画面を通さない反映をした日だけ、この順番を思い出せば足りる。
見た目を整えるSCSSの管理と構造化データについては、それぞれの機能のページにまとめている。