WordPressにCSSが反映されない時の確認順

更新したはずのデザインが変わらない。管理画面ではCSSを直したのに、公開ページでは以前のまま。WordPressにCSSが反映されない場面は、WordPressに慣れている担当者でも意外と時間を取られます。しかも原因は1つではなく、記述ミスではなく周辺の設定や配信の仕組みにあることも少なくありません。

こういうときに大事なのは、やみくもにコードを書き直すことではなく、どこで止まっているかを順番に切り分けることです。特に中小企業のサイトでは、過去の制作会社の設定、キャッシュ系プラグイン、CDN、テーマ独自機能が重なっていて、見た目より構造が複雑になっているケースがあります。

WordPressにCSSが反映されない原因は1つではない

最初に整理しておきたいのは、「CSSが効かない」と見えても、実際にはいくつかの別問題に分かれるという点です。ファイル自体が読み込まれていない場合もあれば、読み込まれていても別のCSSに上書きされている場合もあります。さらに、正しく反映されているのにブラウザやサーバーのキャッシュで古い表示が残っていることもあります。

この違いを見ずに修正を重ねると、不要なコードが増えて、後から保守しにくいサイトになります。ホームページを資産に変えるには、その場しのぎの追記より、原因の位置を見つける姿勢のほうが大切です。

まず確認したいのはキャッシュです

もっとも多いのは、CSSの中身ではなくキャッシュの問題です。WordPressでは、ブラウザキャッシュ、キャッシュプラグイン、サーバーキャッシュ、CDNの4つが重なることがあります。1か所だけ更新しても、別の層に古いデータが残っていれば、見た目は変わりません。

特に保守の引き継ぎ直後は、どこにキャッシュ設定があるか把握されていないことがあります。プラグイン一覧にキャッシュ系が見当たらなくても、レンタルサーバー側で高速化機能が有効になっていることもあります。まずはブラウザのスーパーリロードを試し、次にキャッシュプラグイン、サーバー機能、CDNの順に消していくと整理しやすくなります。

CSSにバージョン番号を付けて読み込んでいる場合は、その値が更新されているかも見てください。ファイルの内容を変えても、読み込みURLが同じままだと古いCSSを参照し続ける環境があります。

ファイルは本当に読み込まれているか

キャッシュを消しても変わらないなら、次はCSSファイルが読み込まれているかを確認します。ここで見たいのは、編集したファイルと実際にページで読み込まれているファイルが同じかどうかです。

よくあるのは、子テーマを触っているつもりで親テーマ側が読み込まれていたり、カスタマイザーの追加CSSに別の指定が残っていたりするケースです。ページビルダーを使っている場合は、テーマのstyle.cssではなくビルダー専用のCSSが優先されることもあります。FTPやファイルマネージャーで修正した場所と、ブラウザの検証ツールで読まれているファイル名が一致しているかは必ず見たいところです。

もし404エラーでCSSファイルが読めていなければ、パスの指定ミスやテーマ構成の変更が疑われます。テーマ更新後にディレクトリ構造が変わり、以前の指定が残っていることもあります。

読み込まれていても、上書きされていることがある

WordPressにCSSが反映されないと感じる原因として、実際には「反映されているが勝てていない」状態も多くあります。つまり、書いたCSSは読み込まれているのに、より後から読まれたCSSや詳細度の高いセレクタに上書きされている状態です。

たとえば、`.btn` に色を指定しても、後から `.header .btn.primary` のようなルールが読まれれば、そちらが優先されます。`!important` を多用すると一時的には解決できますが、将来的にさらに強い指定が必要になり、保守性が落ちます。

ここではブラウザの検証ツールで、対象要素にどのCSSが当たっていて、どのルールが打ち消されているかを見るのが早道です。追加CSS、テーマCSS、プラグインCSS、ページ単位のCSSのどれが最後に効いているかを把握すると、修正箇所も絞れます。

テーマやプラグインの干渉を疑う場面

WordPressは便利な反面、テーマとプラグインの組み合わせで挙動が変わります。特に表示最適化、圧縮、遅延読み込み、ページビルダー系の機能は、CSSの読み込み順や生成方法に影響を与えます。

たとえば、CSSをまとめて圧縮する設定が入っていると、編集後の内容がすぐ再生成されないことがあります。未使用CSSの削除機能があると、必要なスタイルまで除外されてしまう場合もあります。また、プラグイン側がインラインCSSを出力していて、そちらが優先されるケースもあります。

このあたりは、すべてのプラグインを止めればよいという話ではありません。問い合わせ導線や計測設定まで止めてしまうと、別の影響が出ます。まずは表示最適化に関わるプラグインから切り分けるのが現実的です。

エディターと公開画面が別物になっていないか

ブロックエディターや固定ページビルダーを使っていると、編集画面で見えている構造と公開側のHTMLが一致しないことがあります。つまり、見た目のラベルは同じでも、実際のクラス名や要素階層が違っていて、書いたCSSの対象が存在していない状態です。

このときは、管理画面の感覚でCSSを書くより、公開ページのHTMLを基準に確認したほうが早いです。クラス名が自動生成されるブロックや、更新のたびに構造が変わるページビルダーでは、過度に細かい指定は安定しません。短期的には直っても、次の更新で崩れることがあります。

まず確認すべき順番を決めておく

現場では、確認の順番を固定しておくと無駄が減ります。おすすめは、キャッシュ、読み込み確認、上書き確認、干渉確認、構造確認の順です。これなら「コードは合っているのに変わらない」という時間を減らしやすくなります。

逆に、最初からCSSを何度も書き換える進め方は、原因をぼかしがちです。特に複数人で運用しているサイトでは、誰かが追加CSSに応急処置を重ねていて、全体像が見えなくなっていることがあります。そうした状態は、今回の不具合だけでなく、今後の修正コストも上げます。

自社で対応しやすい範囲と、相談したほうがよい範囲

自社で対応しやすいのは、ブラウザ更新、キャッシュ削除、追加CSSの確認、検証ツールでの読み込み確認あたりまでです。ここで原因が見えれば、比較的安全に直せます。

一方で、テーマのfunctions.phpでの読み込み制御、子テーマの構成、圧縮設定、CDNやサーバーキャッシュ、ページビルダー固有の仕様が絡む場合は、無理に触らないほうがよい場面があります。見た目だけ直しても、別ページの崩れや表示速度の悪化につながることがあるからです。

中小企業のサイト運用では、1回の修正より、今後も安心して直せる状態を作ることが重要です。誰が見ても把握できる構成に整えておくことは、会社の信用を守ることにもつながります。

直すだけで終わらせない考え方

CSSの不具合は、小さな表示崩れとして現れます。ただ、その背後には、保守体制が曖昧、更新ルールがない、制作後の相談先がない、といった運用上の問題が隠れていることがあります。

もし同じような不具合が何度も起きるなら、単発修正よりも、テーマやプラグインの役割整理、月次での確認、変更履歴の管理まで含めて整える価値があります。+STOCKでも、WordPress保守を単なる更新代行ではなく、守る、整う、育つの順で考えます。表示トラブルを直すだけでなく、次に迷わない状態へ寄せていくためです。

CSSが反映されないときほど、サイト全体の整理状態が見えます。急いでいるときほど、1か所ずつ落ち着いて確かめる。その積み重ねが、ホームページを長く使えるWeb資産に変えていきます。