症状別 /
サイトの画像が表示されない・メディアライブラリが壊れた ─ 闇雲な再アップロードが被害を広げる
画像が×印になる、サムネイルが全部消えた、WordPressのメディアライブラリが真っ白。この症状は原因が5系統に分かれ、切り分けずに「削除して再アップロード」すると記事との紐付けが切れて被害が拡大する。確認の順番と復旧可否の判断基準を現場経験から整理した。
<p>「サイトの画像が全部表示されなくなった」という連絡は、サーバ移転の直後と、画像最適化プラグインを入れた直後に集中します。本文は表示されるのに画像だけ×印、あるいはメディアライブラリを開くと真っ白。見た目は派手に壊れていますが、実ファイルが本当に消えているケースは経験上3割程度。残りは設定とパスの問題で、ファイルは無事です。</p>
<p>最初にやることは1つだけ。表示されない画像のURLを右クリックでコピーし、ブラウザで直接開く。この結果で原因が3方向に割れます。</p>
<p>404が返るなら、実ファイルがその場所にないか、URLが間違っています。サーバ移転で wp-content/uploads のコピーが年度フォルダ単位で漏れた、あるいはDB内のURLが旧ドメインのまま、というのが二大原因です。後者は WP-CLI の <code>wp search-replace</code> で一括置換すれば直ります。phpMyAdminで wp_posts を直接UPDATEするのは、シリアライズされた wp_postmeta を壊すので推奨しません。</p>
<p>403が返るなら権限の問題です。移転後にディレクトリのパーミッションや所有者が変わったケースで、エックスサーバーならディレクトリ705・ファイル604が基準。FTPで uploads 配下を確認すれば数分で特定できます。.htaccess にホットリンク対策の記述が残っていて自サイトまで弾いている事例も月に1件は見ます。</p>
<p>画像が普通に表示されるなら、ファイルもURLも無事で、変換レイヤーの問題です。EWWW や Smush のWebP変換失敗、Jetpack Photon や Cloudflare Polish などCDN側の変換エラーがここに入ります。プラグインとCDNのキャッシュを順に止めて、どの層で壊れるかを見ます。</p>
<p>メディアライブラリが真っ白になる症状は、画像消失とは別物です。大半は管理画面のJavaScript競合か、wp_posts・wp_postmeta テーブルの破損。ブラウザの開発者ツールでコンソールエラーを見れば10秒で切り分けられます。</p>
<p>やってはいけないのは、表示されないメディアを削除して再アップロードすることです。削除した時点でDB上の添付IDが消え、記事本文・アイキャッチ・カスタムフィールドとの紐付けがすべて切れます。数百記事のサイトでこれをやると、復旧作業は「画像を戻す」から「全記事の画像を貼り直す」に化けます。Regenerate Thumbnails の全件実行も、原因特定前に走らせると壊れたファイルで正常なサムネイルを上書きする恐れがあるので、最後の仕上げに回すべきです。</p>
<p>実ファイルが本当に消えている場合でも、打つ手は残っています。エックスサーバーなら自動バックアップが14日分あり、uploads 配下だけの部分復元が可能です。それより古い消失でも、Wayback Machine に画像が残っていることは珍しくありません。昨年対応した案件では、5年分・約2,400枚のうち9割をこの組み合わせで回収できました。</p>
<p>切り分けに自信がない状態で管理画面やFTPを触り続けると、原因の痕跡が消えて調査時間が倍になります。URLの直接確認まで終えた段階で手が止まったら、その状態のまま相談してください。触っていない現場ほど、復旧は速く終わります。</p>
<p>最初にやることは1つだけ。表示されない画像のURLを右クリックでコピーし、ブラウザで直接開く。この結果で原因が3方向に割れます。</p>
<p>404が返るなら、実ファイルがその場所にないか、URLが間違っています。サーバ移転で wp-content/uploads のコピーが年度フォルダ単位で漏れた、あるいはDB内のURLが旧ドメインのまま、というのが二大原因です。後者は WP-CLI の <code>wp search-replace</code> で一括置換すれば直ります。phpMyAdminで wp_posts を直接UPDATEするのは、シリアライズされた wp_postmeta を壊すので推奨しません。</p>
<p>403が返るなら権限の問題です。移転後にディレクトリのパーミッションや所有者が変わったケースで、エックスサーバーならディレクトリ705・ファイル604が基準。FTPで uploads 配下を確認すれば数分で特定できます。.htaccess にホットリンク対策の記述が残っていて自サイトまで弾いている事例も月に1件は見ます。</p>
<p>画像が普通に表示されるなら、ファイルもURLも無事で、変換レイヤーの問題です。EWWW や Smush のWebP変換失敗、Jetpack Photon や Cloudflare Polish などCDN側の変換エラーがここに入ります。プラグインとCDNのキャッシュを順に止めて、どの層で壊れるかを見ます。</p>
<p>メディアライブラリが真っ白になる症状は、画像消失とは別物です。大半は管理画面のJavaScript競合か、wp_posts・wp_postmeta テーブルの破損。ブラウザの開発者ツールでコンソールエラーを見れば10秒で切り分けられます。</p>
<p>やってはいけないのは、表示されないメディアを削除して再アップロードすることです。削除した時点でDB上の添付IDが消え、記事本文・アイキャッチ・カスタムフィールドとの紐付けがすべて切れます。数百記事のサイトでこれをやると、復旧作業は「画像を戻す」から「全記事の画像を貼り直す」に化けます。Regenerate Thumbnails の全件実行も、原因特定前に走らせると壊れたファイルで正常なサムネイルを上書きする恐れがあるので、最後の仕上げに回すべきです。</p>
<p>実ファイルが本当に消えている場合でも、打つ手は残っています。エックスサーバーなら自動バックアップが14日分あり、uploads 配下だけの部分復元が可能です。それより古い消失でも、Wayback Machine に画像が残っていることは珍しくありません。昨年対応した案件では、5年分・約2,400枚のうち9割をこの組み合わせで回収できました。</p>
<p>切り分けに自信がない状態で管理画面やFTPを触り続けると、原因の痕跡が消えて調査時間が倍になります。URLの直接確認まで終えた段階で手が止まったら、その状態のまま相談してください。触っていない現場ほど、復旧は速く終わります。</p>
この症状でお困りなら、まず無料相談
60分無料相談を予約