CSSが反映されない原因とキャッシュの直し方｜古い版と新しいHTMLで配置が崩れたLPを8つの画面サイズで確かめた手順【2026年】

CSSが反映されないとき、僕の会社で効いたのは、読み込むURLに版の文字列を付けて、変えるたびに更新することでした。2026年7月には、古いCSSと新しいHTMLの組み合わせで配置が崩れる事故を、「直した」と報告した後で見落としていたと分かりました。

キャッシュで何が起きているかと、直す手順、報告の前に確かめる方法を順に書きます。「自分の画面では直ったのに、相手には崩れて見える」という方は、次の章の表から見てください。

CSSが反映されない原因はキャッシュ：古い版と新しいHTMLが混ざると配置が崩れる

CSSを直したのに見た目が変わらないとき、多くはどこかに古いCSSが残っています。HTMLだけ新しくなり、スタイルが古いままだと、変わらないどころか配置が崩れることもあります。

ここでいうキャッシュとは、一度受け取ったファイルを手元や途中に保存し、次からそれを使い回す仕組みのことです。MDNによると、保存したものが「新しい」とみなされる間は、サーバーに取りに行かずにそのまま使われます。

どれだけの間「新しい」とみなすかは、サーバーが返す Cache-Control: max-age で決まります。MDNは、この指定が無くても、条件がそろえば保存して使い回す「ヒューリスティックキャッシュ」があると説明しています。

つまり、CSSに期限を何も指定していないサイトでも、古いCSSが使われることがあります。MDNも、基本的にすべての応答に Cache-Control を明示すべきだとしています。

キャッシュはURLごとに分けて持たれます。ここが厄介な点です。HTMLとCSSは別々のURLなので、HTMLは新しく取り直され、CSSだけ古いまま、という組み合わせが起きます。

新しいHTMLが前提にしている位置の指定が、古いCSSには無い。この状態では、要素の位置がまとめて崩れます。僕の会社の例では、絶対配置の要素が全部、画面の左上に積み重なりました。

古いCSSが残る場所は1つではありません。どこに残っているかで、消し方が変わります。

表の3行目の共有キャッシュは、利用者とサーバーの間に置かれ、複数の利用者で同じ応答を使い回すキャッシュです。MDNは、長い max-age で途中のサーバーに保存されたものを消す方法は無いとしています。

僕なら、どの場所が原因でも効く「URLを変える」を最初に入れます。消して回るより、古いものを使わせない方が確実だからです。

CSSのキャッシュを確かめて直す対処手順：style.css?v= でURLを変える

確実な直し方は、CSSを参照するURLに版の文字列を付け、中身を変えるたびにその文字列も変えます。これをキャッシュバスターと呼びます。

キャッシュバスターとは、URLに版番号やハッシュ値を入れ、更新のたびにURLを変えて古いキャッシュを使わせない方法のことです。MDNは、URLが変われば古いものは使われない、と説明しています。

1. 開発者ツールでキャッシュを切り、開き直す。 Chromeの開発者ツールの「Network」パネルで「Disable cache」にチェックを入れます。ブラウザのキャッシュを使わない状態で、初めての訪問者の見え方を再現できます。
2. これで直れば、原因はブラウザのキャッシュ。 直らなければ、CSSのURLを直接開き、サーバー上の中身が新しいかを見ます。古ければ、置き場所かサーバー側のキャッシュを疑います。
3. HTMLのCSSの参照に、版の文字列を付ける。 下の例の形です。JavaScriptのファイルも同じにします。
4. CSSを変えるたびに、v= の値を変えてHTMLを出し直す。 値を変え忘れると、手順3を入れても古いCSSが残ります。
5. ページキャッシュを使っているサイトでは、サーバー側のキャッシュを消す。 HTMLが古いままだと、新しい v= も届きません。
6. 使う画面サイズを全部、開いて確かめる。 自分の1台で直って見えても、それだけでは足りません。確かめ方は、再発防止の章に書きました。

僕の会社で使っている形は、日付と記号です。下の例の 260722a は、2026年7月22日の1回目の版という意味で、値は例です。

<link rel="stylesheet" href="/css/style.css?v=260722a">
<script src="/js/main.js?v=260722a"></script>

MDNの例は2つの形です。bundle.js?v=123 のように問い合わせに入れる形と、bundle.v123.js のようにファイル名に入れる形があります。どちらでも、URLが変わることが要点です。

自分の画面の確認には、強制の再読み込みか手順1の Disable cache を使います。MDNによると、Chromeは再読み込みでCSSなどを確かめ直さない場合があります。訪問者は、そもそも再読み込みをしてくれません。

応答のヘッダーを設定できるなら、MDNは次の組み合わせを説明しています。HTMLは Cache-Control: no-cache で毎回確かめさせ、版付きのCSSには長い max-age を付ける形です。

no-cache は「保存しない」ではなく、「使う前に必ずサーバーに確かめる」という意味です。保存そのものを止めるのは no-store で、MDNはこちらを安易に使わないよう勧めています。

裏方で実際に起きた例：「配置を直した」後に、スマホでもPCでも要素が重なっていた2026年7月

ここからは、僕の会社（株式会社UrakaTA）の作業の記録からの転記です。お客さんの案件なので、業種・サイト・数値が分かる情報は伏せています。

2026年7月22日、ある広告用のLPで、配置の修正を終えたと報告しました。このLPは、要素を座標で置く絶対配置の作りで、画面を区切りごとに見せていく形です。

報告の後、スマホ版もPC版も要素が被っている、と強い指摘が入りました。直したはずの配置で、要素どうしが重なって見えていました。

振り返ると、確認に使っていたのは1〜2サイズのスクリーンショットを目で見ることだけでした。この方法では、次の3つを見逃していました。

• 縦の短いPCの画面（例 1280×720）。 上下の余白が消え、ロゴが上の帯に被る。
• タブレットの幅（600〜768px）。 幅を基準にした要素が、縦の長さを食いつぶす。
• CSSのキャッシュ事故。 古いCSSと新しいHTMLの組み合わせで、絶対配置の要素が全部、左上に積み重なる。

3つ目が、この記事の主題です。CSSのURLが変わらなければ、すでにLPを開いたことのある人のブラウザには古いCSSが残ります。HTMLだけが新しくなるので、直したはずの配置がかえって崩れて見えます。

この件の後、僕の会社では、LPの報告の前に機械でのチェックを回すように変えました。8つの画面サイズで、LPの全部の画面を開き、要素の重なりとはみ出しを数えます。

見つかった重なりを直し、もう一度チェックする、を何度か回しました。重なりがゼロになるまで続けてから、報告し直しています。

調べ始めてから報告し直すまでにかかった時間は、記録に残していないので書きません。

CSSのキャッシュ事故を再発させない：キャッシュバスターと8つの画面サイズの機械チェック

再発を防ぐ要は、CSSのURLを必ず変えることと、自分の画面ではなく決めた画面サイズの全部で確かめることの2つです。僕の会社では、次の3つを決まりにしています。

• CSSとJavaScriptは、必ずキャッシュバスター付きで参照する。 形は style.css?v=YYMMDDx で、デプロイのたびに v= を更新します。
• 座標で置く作りのLPは、報告の前に8つの画面サイズで機械のチェックを回す。 あわせて、各画面のスクリーンショットを並べて目でも見ます。
• 直してはチェックし直す、を重なりがゼロになるまで回してから報告する。 途中で「直りました」と言わないためです。

僕の会社のチェックで使っている8つの画面サイズは、次のとおりです。スマホを4つにしているのは、同じ幅でも縦の長さで崩れ方が変わると考えているからです。

チェックの中身は、ブラウザを自動で操作する道具（Playwright）でLPを開き、要素の位置を数字で取って比べるものです。見ているのは3つです。

• 要素どうしの位置が重なっていないか
• 要素が画面や配置の枠からはみ出していないか
• ロゴ・申し込みボタンなど、画面に固定した部品と被っていないか

機械のチェックにも、作ってみて分かった落とし穴がありました。中央寄せの文字は、外側の箱が全幅になるので、内側の文字の箱で測ります。消えていく演出の要素は、動きが落ち着いた状態で判定します。

もう1つは、入れ子にした @media の指定を、ブロックの最後に置きます。後ろにある同じ強さの指定に負けて、効かないことがあったためです。

業務でCSSを更新するときの注意：自分の画面で直っても、相手の画面は古いまま

お客さんに「キャッシュを消してください」と頼む前に、URLを変える。 消してもらえば、その人の画面は直ります。ただ、ほかの訪問者のブラウザには古いCSSが残ったままです。

サーバー側のキャッシュも疑う。 ページキャッシュのプラグインがHTMLを保存していると、HTMLの中のCSSも古いまま配られます。実際の例は、WordPressの保存が403になりFTPで回避した手順に書きました。

その件では、CSSファイルのURLの版の文字列が変わらず、ブラウザに古いCSSが残る問題もありました。キャッシュの残る場所が2つ重なると、片方を消しても直りません。

置いたファイルそのものも確かめる。 キャッシュを疑う前に、サーバー上のCSSが空や古い版になっていないかを見ます。置いたファイルが0バイトになった例は、curl の FTPS アップロードで0バイトになる時の直し方にあります。

サーバーの設定で、置いたファイルの扱いが変わることもあります。.htaccess の1行でPHPのソースが表示された例は、.htaccess の SetHandler で PHP のソースが表示される原因に書きました。

AIや外注に修正を任せるときは、確かめ方まで決めて渡す。 僕の会社の例でも、「直した」の報告は1〜2サイズの目視が根拠でした。どの画面サイズで、何を確かめたら「直った」と言うかを、作業の前に決めておきます。

「CSSを直したのに崩れて見える」「スマホとPCで見え方が違う」というときは、下のフォームからご相談ください。原因の切り分けと、確かめ方の作り直しから一緒に見ます。