WordPressでCSSを直したのに反映されないとき｜キャッシュより先に確かめる配信元

CSSを修正してアップロードした。ファイルはサーバーに上がっている。それなのに見た目が変わらない。

このとき最初に疑うべきはブラウザのキャッシュではありません。「自分が編集したファイル」と「実際にサイトが配信しているファイル」が同じものかどうかです。ここが食い違っていると、キャッシュを何度クリアしても?v=を付け直しても、永久に反映されません。

厄介なことに、この状態はエラーを一切出しません。FTPのアップロードは成功し、サーバー上にファイルも存在し、管理画面にも何も表示されません。「正しく作業できているのに結果だけが変わらない」ため、原因の見当がつかないまま時間が溶けていきます。

この記事では、3つの確認で配信元を特定する手順と、これが起きやすいサイト構造の見分け方をまとめます。制作会社に依頼している場合に何を伝えるべきかも最後に書きます。

結論：確認する順番を逆にする

「反映されない」への対処は、多くの場合こう進められます。①ブラウザのスーパーリロード ②キャッシュプラグインの削除 ③?v=を付けてキャッシュバスト ④サーバーのキャッシュ設定を確認。

この順番は、「配信されているファイルは、自分が編集したファイルである」という前提の上に成り立っています。前提が崩れていると、①〜④を全部やっても何も起きません。正しい順番はこうです。

順番	確認すること	見る場所
1	配信されているファイルの中身は新しいか	HTTPレスポンスヘッダー
2	サーバー上の実ファイルは更新されているか	FTP・SSHで実ファイル
3	同名のファイルが別の場所にもないか	ドキュメントルート直下
4	ビルドを挟む構成なら、ビルドは走ったか	反映の仕組み
5	ここまで問題なければキャッシュを疑う	ブラウザ・サーバー・CDN

キャッシュは最後です。1〜4で切り分けが付くケースの方が、実務では多く見つかります。

手順1：HTTPヘッダーで「実際に配信されている中身」を見る

ブラウザで見ても分かりません。ブラウザは自分のキャッシュを混ぜて表示するので、「サーバーが今この瞬間に返しているもの」とは別物だからです。見るのはHTTPレスポンスヘッダーの2項目です。

• content-length … 配信されているファイルのバイト数
• last-modified … 配信されているファイルの最終更新日時

ターミナルが使える環境なら、次の1行で取れます。

curl -sI https://example.com/assets/style.css

ここで返ってきた content-length が、自分がアップロードしたファイルのサイズと一致しているかを見ます。last-modified が数か月前の日付を指していたら、その時点で「今日アップしたファイルは配信されていない」と確定します。

ターミナルを使わない場合は、ブラウザの開発者ツールのネットワークタブでも同じ2項目が確認できます。

この確認の価値は、「アップロード失敗」と「配信経路の食い違い」を分けられる点にあります。サイズも日時も古いなら、手順2へ進みます。

手順2：サーバー上の実ファイルと突き合わせる

手順1で「古いものが配信されている」と分かったら、FTPソフトでアップロード先のファイルをダウンロードし直し、手元のファイルと比べます。サイズの一致だけでも十分な目安ですし、厳密にやるならハッシュ値（SHA256など）を突き合わせます。

ここで結果が2つに分かれます。

• サーバーのファイルが古い → アップロードが失敗している。FTPの接続先ディレクトリ、上書き権限、転送モードを確認する
• サーバーのファイルは新しい（手元と一致する） → アップロードは成功している。それでも古いものが配信されている＝配信経路が違う

後者が確定したら手順3が本題です。ここまで来ると「アップロードし直す」を繰り返しても状況は変わりません。作業をやり直す前に、必ずこの切り分けを済ませてください。

手順3：ドキュメントルート直下に同名ファイルが残っていないか

ここが実務で最も多く見つかる原因です。Webサーバーは、URLに対応する物理ファイルが存在すればそれをそのまま返します。テーマを経由するのは、物理ファイルが存在しないときだけです。

つまり https://example.com/assets/style.css というURLに対して、ドキュメントルート直下に assets/style.css が実在していれば、WordPressは一切呼ばれません。テーマの中に同じ名前のファイルがあっても、それは使われない控えになります。

サーバーのドキュメントルート直下を一覧し、assets/ css/ images/ js/ といったテーマの外にあるアセット用ディレクトリが無いかを確認してください。

この構造になりやすいのは「静的サイトを後からWordPress化した」案件

新規でWordPressを構築したサイトでは、まず起きません。起きるのは次の経緯を持つサイトです。

• 元は静的HTMLサイトとして公開されていた
• 後からWordPressを導入し、既存デザインをテーマ化した
• 移行時に、旧サイトのファイルをドキュメントルートから消していない

この場合、アセットの反映先は「テーマの中」と「ドキュメントルート直下」の2箇所になります。テーマの中だけを更新しても表側は変わりません。

一方、HTML本体はドキュメントルート直下に残っていなければWordPress経由になるので1箇所の更新で反映されます。同じサイトの中で、ファイルによって反映先が違うわけです。これが「画像は差し替わったのにCSSだけ古い」という一見不可解な症状を生みます。

実例：正しく上書きしても表示が変わらなかった福祉サービスのサイト

弊社で管理している、福岡の生活支援サービス会社のサイトがこの構造でした。

テーマ内のCSSファイルをFTPで上書きし、サーバー上の実ファイルのハッシュ値が手元と一致することまで確認済み。それでも配信されるCSSは旧内容のままで、?v=のパラメータを変えても古いままです。

原因は、ドキュメントルート直下に旧静的サイト時代のassets/ディレクトリと画像用ディレクトリが残っていたことでした。/assets/*.css へのリクエストはWordPressを経由せず、ルート直下から返っていた。テーマ内のCSSは事実上ただの控えだったわけです。

この構造のサイトを引き継いだら、修正作業の前にドキュメントルートの一覧を取るのが最短です。 1回確認すれば以後は「どちらに置けば効くか」が確定します。運用メモに「CSSの反映先はルート直下のassets/」と1行書いておけば、担当者が変わっても事故になりません。

ビルドを挟む構成では「反映されない」ではなく「反映待ち」

症状は同じでも原因がまったく違うケースもあります。WordPressを裏側の管理画面として使い、表側は静的なHTMLとして書き出す構成（ヘッドレス構成）では、保存してもすぐには表側に出ません。書き出し処理（ビルド）が走り、その結果がサーバーに反映されて、はじめて表側が変わります。

弊社が運用している構成では、この書き出しを30分ごとの自動実行にしています。つまり保存から最大30分は、表側が古いままです。これは不具合ではなく設計です。

この構成では必ず2つを用意しておくべきです。保存をきっかけに即座にビルドを走らせる仕組みと、一定間隔で必ず走る仕組み（取りこぼしの保険）。片方だけだと、取りこぼしたときに「記事が出ない」という問い合わせに直結します。制作会社に任せている場合は、「更新してから何分で表側に出る仕様か」を最初に確認しておくとよいでしょう。

出力そのものが壊れているケース

配信元も正しい、ビルドも走っている。それでも見た目が変わらないときは、書き出された結果が意図と違う可能性を見ます。

CSSやJavaScriptをビルドで生成する構成では、書いたコードがそのまま出力されるとは限りません。弊社の事例では、.nav.is-dark .logo-black と書いた指定がビルド後に親要素の指定を落として .logo-black だけになり、直前の非表示指定を無条件に上書きしたことがあります。結果、ヘッダーのロゴが2枚重なって表示されました。厄介なのは、ビルドがエラーを出さずに成功することです。

対処は難しくありません。書き出された側のファイルを開いて、目的の指定が生きているかを検索する。これだけです。「入力を直したから出力も直っているはず」は推測であって、確認ではありません。構造化データやメタ情報も同様に、出力されたHTMLで確かめてください。

直したページが1枚とは限らない

ページごとにHTMLファイルを持つ形で書き出されているサイトでは、index.htmlが1枚ではありません。弊社サイトも、書き出し方式に切り替えた時点で各ディレクトリに個別のHTMLが並び、合計20枚存在していました。

このとき、トップページのHTMLだけを修正して確認するとトップページでは成功しているように見えます。しかし残りのページは何も変わっていません。計測タグやメタ情報のように全ページに入るべきものは、この状態だと大半のページで欠落します。

対策は、修正前にファイル構成を一覧して枚数を数えること。そして修正後の確認を、1ページではなく主要URLを一通り回して行うことです。

?v= は反映の「手段」であって「証拠」ではない

CSSやJSのURL末尾に ?v=20260803a のようなパラメータを付けてキャッシュを回避する手法（キャッシュバスト）は日常的に使われます。弊社でも修正のたびにこの値を1つ進めており、1日に何度も修正が入る日は末尾の記号がaからqまで進むこともあります。

ただし、この値を更新したこと自体を「反映できた証拠」にしてはいけません。

?v=はブラウザに「別のファイルとして取り直せ」と伝えるだけの仕組みです。取りに行った先が古ければ、取り直しても古いものが来ます。前半の事例は、まさに?v=を更新しても何も変わらないパターンでした。反映の確認は、?v=を進めた事実ではなく手順1のHTTPヘッダーで実際に返ってきた中身で行ってください。

「一部を確認して全体を判断する」を避ける

反映確認でもう一つ重要なのは、確認した項目についてしか、確認したとは言えないということです。

書き出しやデプロイをやり直す作業は、計測タグ・フォント・リダイレクト設定・環境変数を一度に巻き込みます。互いに無関係に見えて、同じ1回の作業で同時に壊れることがあります。しかも壊れ方が「画面には何も出ない」タイプだと、気づかないまま何週間も走ってしまいます。

そうならないために、書き出しを伴う更新の前後で見る項目を決めておくと安全です。①設定値がすべて解決されているか ②計測タグが出力に含まれているか ③フォントの読み込みが残っているか ④リダイレクト設定のファイルを上書きしていないか ⑤主要URLを開いて本文まで表示されるか。

特に④は明示的に除外指定をしておくべきです。 転送設定のファイルはサイト全体のアップロードで静かに巻き込まれ、上書きされた瞬間に検索評価の受け皿が消えます。

記録を残すときも「更新した」ではなく、「このURLが、この日に、正しい内容を返した」と書く。数か月後に読み返したときに、記録が事実として使えるかが決まります。

制作会社に依頼している場合、伝えるとよいこと

自社で確認できない場合でも、次の3点を添えて連絡すると調査が一気に短くなります。

• いつ・どのファイルを・どこに更新したか
• どのURLで、どの表示が変わらないか（トップだけか、全ページか）
• すでに試したこと（スーパーリロード、キャッシュ削除など）

「反映されません」だけだと受け取った側はキャッシュの確認から始めます。上の3点があれば、配信経路の確認から入れます。

逆に制作会社を選ぶ立場なら、「更新してから表側に出るまでの仕組みと所要時間」を説明できるかは運用体制を見る良い質問です。即答できる相手は、反映の経路を把握して作っています。

まとめ

「直したのに反映されない」はキャッシュの問題として扱われがちですが、実務で頻度が高いのは編集した場所と配信されている場所の食い違いです。

• 最初にHTTPヘッダーで、実際に配信されている中身を見る
• サーバーの実ファイルと突き合わせ、アップロード失敗か経路違いかを分ける
• ドキュメントルート直下に同名のアセットが残っていないかを確認する
• ビルドを挟む構成なら、「反映されない」ではなく「反映待ち」かもしれない
• 出力されたファイルと主要URLを一通り実測してから完了とする

確認の対象を「見た目」から「実際に返ってきているデータ」に変えることが、この種のトラブルを短時間で終わらせる最も確実な方法です。

よくある質問

Q. ブラウザのスーパーリロードでも変わりません。サーバーのキャッシュでしょうか？

その可能性もありますが、先にHTTPレスポンスヘッダーの content-length と last-modified を確認してください。キャッシュが原因なら、値は「新しいファイルのもの」になっているはずです。値が古いままなら、キャッシュではなく配信元の問題です。

Q. ドキュメントルート直下に古いファイルが見つかりました。消してよいですか？

すぐには消さず、まず別名にリネームして数日様子を見るのが安全です。そのファイルを参照している箇所が他にも残っている可能性があります。表示に問題がないことを確認してから削除し、削除前にサイト全体のバックアップも取ってください。

Q. 自分で確認できる範囲はどこまでですか？

ブラウザの開発者ツールでネットワークタブを開き、対象のCSSファイルのレスポンスヘッダーを見るところまでは専門知識がなくてもできます。ここで日付が古いと分かるだけでも、制作会社への連絡内容が具体的になります。

Q. 画像を差し替えたのに古い画像が出ます。CSSと同じ原因ですか？

同じ原因であることが多いです。画像も物理ファイルとして配信されるため、ドキュメントルート直下に同名の旧画像が残っていればそちらが優先されます。手順1で、配信されているファイルサイズが新しい画像と一致しているかを見てください。