WordPressでアイキャッチ画像を削除→再アップしたのに古い画像が表示される。原因は同名ファイルによるURLの重複と、複数層に残ったキャッシュです。ファイル名を変えるのが最速の解決策ですが、それで済ませる前にキャッシュの層構造を理解しておくと再発を防げます。
アイキャッチに仮画像のsample.pngを設定していて、後日ちゃんとした画像ができたので差し替えました。メディアライブラリから古いsample.pngを削除し、新しいsample.pngをアップロードしてアイキャッチに指定。手順としては何も間違っていない。
ところが表示されるのは削除したはずの古いsample.png。メディアライブラリには新しい方が見えているのに、サイトの表示だけが古いまま。WordPressがバグったのか、ブラウザが壊れたのか、頭の中が渋滞しました。
差し替えたはずなのに、表示されるのは古い画像のまま
キャッシュだけが原因ではない——WordPress本体の仕様が「復活」を起こす
「削除して同名で再アップしたら古い画像が出る」のは、キャッシュだけの問題ではありません。WordPress本体の2つの仕様が組み合わさって「復活」を引き起こしています。
WordPress仕様1：同名ファイルは上書きされない（wp_unique_filename）
WordPressは、同名ファイルをアップロードしても絶対に上書きしません。これは意図的な仕様です。
内部で使われているwp_unique_filename()関数（WordPress公式リファレンス）が、アップロード先ディレクトリをスキャンし、同名ファイルが存在すれば末尾に連番を付けてリネームします。sample.pngが既に存在すれば、新しいファイルはsample-1.pngになります。
これはユーザーが誤って既存ファイルを上書きすることを防ぐための安全策です。WordPress.orgのフォーラムやTracでも、この動作は仕様として確認されています。
WordPress仕様2：削除してもサムネイルがサーバーに残る
WordPressは画像をアップロードすると、元画像に加えて複数のサイズ違い画像（サムネイル）を自動生成します。
|
1 2 3 4 5 |
sample.png ← 元画像 sample-150x150.png ← サムネイル sample-300x200.png ← 中サイズ sample-1024x768.png ← 大サイズ sample-scaled.png ← スケーリング済み（大きな画像の場合） |
メディアライブラリから画像を削除すると、WordPress内部のwp_delete_attachment_files()関数（公式リファレンス）がサムネイルの削除も試みます。しかし、この関数はデータベースの_wp_attachment_metadataに記録されたサイズ情報を元に削除する仕組みです。
つまり、テーマやプラグインが独自に追加した画像サイズがメタデータに正しく記録されていない場合や、テーマ変更後に残った旧サイズなど、メタデータに載っていないサムネイルはサーバー上に残ります。WordPress.orgのサポートフォーラムでも「”Delete permanently”を押してもuploadsフォルダからファイルが消えない」という報告が複数あります。
2つの仕様が組み合わさると「復活」が起きる
ここが核心です。
sample.pngをアップロード → WordPressがsample-150x150.png等を自動生成- メディアライブラリから
sample.pngを削除 → 元画像は消えるが、一部のサムネイルがサーバーに残る - 新しい
sample.pngをアップロード →wp_unique_filename()がディレクトリをスキャン - 残骸の
sample-150x150.png等が存在するため、新ファイルがsample-1.pngにリネームされる - 投稿側は古い
sample.pngのURLを参照したまま → 古いサムネイルが表示される
つまり「キャッシュが古い画像を返している」パターンだけでなく、WordPressの仕様として新しいファイルが別名で保存され、古いサムネイルが物理的に残っているパターンがあるのです。これはキャッシュを全消ししても直りません。
さらにキャッシュの5つの層が追い打ちをかける
WordPress仕様の問題に加えて、キャッシュも5つの層で古い画像を返し続けます。仕様の問題を解決しても、キャッシュが残っていれば「戻った」ように見えます。
WordPressサイトのキャッシュは複数の層に分かれており、1つ消しただけでは解決しないことがあります。キャッシュの層構造と各層の消し方は「WordPressキャッシュが効かない・消えないときの完全対処法」で詳しく解説していますが、画像の差し替えに関係する層を整理すると以下の5つです。
1. ブラウザキャッシュ——PC・スマホのローカルに画像が保存されている。画像はCSS/JSよりキャッシュの有効期限が長いことが多い。
2. キャッシュプラグイン——WP Fastest CacheやLiteSpeed Cacheが生成した静的HTMLに、古い画像URLが含まれている。
3. CDNキャッシュ——Cloudflareなどのエッジサーバーに古い画像が残っている。
4. 画像最適化の派生キャッシュ——EWWWやShortPixelがPNGから生成したWebP/AVIFファイルが古いまま残っている。PNGを差し替えてもWebPが更新されなければ、そちらが表示される。
5. WordPress生成のサイズ違い画像——WordPressはアップロード時にサムネイル・中・大などのサイズ違い画像を自動生成する。元画像を差し替えても、生成済みのサイズ違い画像が古いまま残ることがある。CocoonなどのテーマではRetina対応のために通常の2倍サイズの画像を使う設定があり、生成される派生画像の数がさらに増えるため、残骸が発生しやすくなります。
DevToolsのNetworkタブ。画像ファイルが「(disk cache)」から読み込まれている
もう一つの罠：アイキャッチは「添付ファイル」を参照している
アイキャッチは画像URLを直接指定しているのではなく、WordPress内部の「添付ファイル（attachment）」を参照しています。この仕組みが「メディアでは新しいのに表示が古い」を起こしやすくしています。
投稿に紐づくのは添付ファイルのIDで、表示時にはそのIDからURLやサイズ違い画像を取得します。そのため、こういうズレが起きます。
元画像は新しいのに、表示側が別サイズの古いサムネイルを引いている。PNGを更新したのに、WebP/AVIFの派生ファイルが古いままでそちらが配信される。
「メディアライブラリでは新しいのに、サイトの表示だけ古い」という症状は、この構造が背景にあります。
最初に確認：FTPでサムネイルの残骸を探す
メディアライブラリ上では削除済みでも、サーバーのuploadsフォルダにサムネイルが残っていることがあります。これはWordPressの仕様です。FTPでの確認が必須です。
FTPでuploadsフォルダを確認。削除したはずの画像のサムネイル（sample-150×150.pngなど）が残っている
FTPまたはXserverのファイルマネージャーで/wp-content/uploads/年/月/フォルダを開き、古いファイル名で検索してください。sample-150x150.png、sample-300x200.pngのようなサムネイルが残っていたら手動で削除します。これが残っている限り、次のアップロードでwp_unique_filename()が連番を付け、キャッシュを全消ししても問題は解決しません。
切り分け：URLに「?v=1」を付けて確認する
画像URLの末尾にクエリパラメータを付けて新しい画像になるなら、ほぼ確定でキャッシュが古い画像を返しています。
|
1 2 |
https://example.com/wp-content/uploads/2026/01/sample.png https://example.com/wp-content/uploads/2026/01/sample.png?v=1 |
ブラウザで両方を開いて見比べます。?v=1付きで新しい画像になるなら、URLが同じままだからキャッシュが古い方を返している状態です。これでキャッシュが原因であることが確定します。
最短解決ルート
古いファイルの確認→キャッシュ全消し→ファイル名変更。この順で上から潰していくのが最短です。
1. サーバー上の古いファイルを完全削除（FTP確認が必須）
これが最も見落とされやすく、最も重要なステップです。FTPまたはファイルマネージャーで/wp-content/uploads/の該当フォルダを直接開き、古いファイルのサムネイル残骸（sample-150x150.png、sample-300x200.pngなど）が残っていたら手動削除してください。メディアライブラリからの削除だけでは消えないことがあるのはWordPressの仕様です。
2. キャッシュを全層消す
ブラウザ：DevToolsを開いた状態でリロードボタン長押し →「Empty Cache and Hard Reload」。
キャッシュプラグイン：WP Fastest Cacheなら「Delete Cache and Minified CSS/JS」で全キャッシュ削除。
CDN：Cloudflareなら該当URLをパージ。
画像最適化：WebP/AVIFのキャッシュ削除機能があれば実行。
1つでも残ると「また戻った」になるので、全部やるのが早いです。
3. 最終手段：ファイル名を変える（最強）
キャッシュと戦うより、キャッシュが効かない状況を作る方が確実です。
|
1 2 |
NG: sample.png（URLが同じになる） OK: sample-20260117.png / sample-v2.png（URLが変わる） |
ファイル名＝URLが変われば、古いキャッシュを参照しようがありません。今すぐ解決したいならここが最短ゴールです。
予防策：同名アップロードをやめる
ファイル名に日付やバージョンを含める運用ルールを作っておけば、同名問題は発生しません。
|
1 2 3 |
仮画像: hero-draft.png 本番: hero-final.png 更新: hero-20260117.png / hero-v3.png |
どうしても同名にしたい場合は、アップロード後に「CDNパージ → キャッシュプラグインの全削除 → 画像最適化の派生キャッシュ削除」を毎回セットで実行する手順を固定してください。
関連記事
WordPressの画像・キャッシュトラブルに関連する記事です。
まとめ
「削除したアイキャッチが戻る」のは、キャッシュだけが原因ではありません。WordPressは同名ファイルを上書きしない仕様（wp_unique_filename）であり、かつ削除時にサムネイルがサーバーに残ることがある仕様（wp_delete_attachment_files）です。この2つが組み合わさり、さらに複数層のキャッシュが古い画像を返し続けることで「復活」が起きます。
サーバー上にサムネイルの残骸がないかFTPで確認し、全層のキャッシュを消し、それでもダメならファイル名を変える。この3ステップが最短解決ルートです。そもそも同名アップロードを避ける運用ルールを作っておけば、この問題自体が発生しなくなります。
コメント