レガシーサイトの画像がX（×印）で表示される原因と直し方

古いウェブサイトを閲覧すると、本文は表示されるのに画像だけがX印や小さなアイコンになっていることがあります。これは画像そのものが消えたとは限らず、HTMLに記された場所へブラウザが到達できない、形式を解釈できない、表示が制限されているといった複数の要因で起こります。

特にフレーム構成、古い文字コード、相対パス、現在とは異なるサーバー設定を使ったサイトでは、原因を一つに絞りにくくなります。kammuri.comのように、旧式のフレームページや日本語版への案内だけが残り、タイトルや画像が文字化けしているサイトを確認するときは、表示結果だけでなくHTMLの記述と保存場所を分けて調べることが重要です。

表示される状態	主な原因	優先して確認する箇所
画像の代わりにX印が出る	ファイルが見つからない	画像URL、フォルダー名、拡張子
画像領域が空白になる	CSSや読み込み制限	スタイルシート、混在コンテンツ
文字化けと画像欠落が同時に起きる	文字コードやHTMLの不整合	charset指定、DOCTYPE、HTML構文
フレーム内だけ画像が表示されない	基準URLや相対パスの誤り	frameset、frame、base要素
一部の画像だけ欠落する	大文字小文字や権限の違い	サーバー上の実ファイル名
古い画像形式だけ表示できない	ブラウザの対応終了	形式、MIMEタイプ、変換方法

X印が示している読み込みの失敗

画像のX印は、ブラウザが画像として表示できるデータを取得できなかったときに現れる代表的な表示です。HTMLには画像を置くためのimg要素があっても、src属性の指定先が存在しなければ、画面には代替アイコンや空の領域が残ります。したがって、X印を見てすぐに「画像が削除された」と判断するのは早計です。

典型的なのは、HTMLファイルから見た画像の場所と、実際にファイルを置いた場所が一致していないケースです。images/logo.gifと書かれているのに、実際の名前がimage/logo.gifであれば取得できません。拡張子が.GIF、ファイル名が半角ではなく全角、フォルダー名に不要な空白がある場合も、環境によっては別のファイルとして扱われます。

開発者ツールのネットワーク欄を使えば、画像の取得結果を確認できます。404なら指定された場所にファイルがなく、403ならアクセス権やサーバー規則が原因である可能性が高くなります。200で取得できているのに見えない場合は、画像形式、MIMEタイプ、CSS、ブラウザの安全機能を調べます。

フレームと相対パスが作る見えないずれ

古いサイトでは、画面を複数の領域に分けるフレーム構造がよく使われていました。外側のframesetが案内ページを読み込み、内部のframeが本文やメニューを読み込む構成です。この場合、画像の相対パスは訪問者が見ているアドレスではなく、画像を呼び出している内部HTMLの場所を基準に解釈されます。

たとえば、トップ階層のHTMLからはimg/logo.gifで正しくても、pages/menu/index.htmlから同じ記述をすると、ブラウザはpages/menu/img/logo.gifを探します。制作者がファイルを移動した後にリンクだけ修正し忘れると、フレーム内の特定領域だけX印になります。親ページと子ページで基準位置が異なることが、旧サイトの調査を難しくします。

フレームの指定方法や正しい参照先を確認する際には、正しいフレーム構成について整理された情報も手掛かりになります。frame srcの値、各子ページの実際のURL、画像ファイルの相対位置を紙やメモに書き出すと、どの階層でパスがずれているか把握しやすくなります。

文字コードとファイル名の不一致

日本語のレガシーサイトでは、画像の欠落と文字化けが同じ時期に発生することがあります。HTMLがシフトJISで保存されているのに、サーバーが別の文字コードとして配信していたり、meta要素の指定と実際の保存形式が異なったりすると、日本語のページタイトルや代替テキストが崩れます。

通常、画像URLが英数字だけで書かれていれば、文字コードの違いは直接の原因になりません。しかし、画像ファイル名やフォルダー名に日本語が含まれている場合は影響が大きくなります。たとえば「写真館/表紙.gif」のようなパスは、保存時の文字コード、URLエンコード、サーバーの処理方法が一致しなければ正しく解決されません。

対処するなら、画像ファイル名を英数字とハイフンに変更し、HTML側の参照も同じ表記に統一する方法が安全です。文字コードを直す際は、エディターで開いて保存するだけでなく、ファイルの実際のエンコードとHTTPヘッダーの指定を確認します。文字化けを見つけたら、画像の問題とは別に、HTML全体の保存形式を点検する必要があります。

サーバー移転とアクセス制限の影響

旧サイトを別のサーバーへ移したとき、HTMLだけ移行され、画像フォルダーが抜け落ちることがあります。バックアップの対象が拡張子.htmlや.htmに限定されていた場合、.gif、.jpg、.pngなどの素材が転送されず、ページの骨格だけが残ります。レンタルサーバーの契約終了やドメイン変更によって、外部サーバーに置かれた画像だけが消えることもあります。

画像が存在していても、アクセス権が不適切なら表示されません。一般的なウェブサーバーでは、ファイルを読み取れる権限が必要です。ディレクトリ一覧を禁止する設定と画像配信の拒否は別の仕組みですが、移転後の設定ミスで特定フォルダーへのアクセスが遮断される場合があります。アクセスログやサーバーのエラーログを確認すると、利用者側では分からない拒否理由を特定できます。

HTTPで作られたページからHTTPS上の画像を呼び出す、またはその逆の構成も注意が必要です。現在のブラウザは安全でない混在コンテンツを制限するため、古いページでは画像だけが読み込まれないことがあります。すべてのURLをHTTPSへ統一し、リダイレクト後のパスを確認することで、通信方式に起因する欠落を減らせます。

古い画像形式とブラウザの表示差

過去には、GIFやJPEG以外にも、特定のブラウザ用プラグインや独自形式で保存された画像が使われていました。現在のブラウザがその形式に対応していなければ、ファイルが存在していてもX印や空白として扱われます。動く画像に見えても、実体が古い動画形式やプラグイン依存のコンテンツである可能性があります。

MIMEタイプの誤りも見落とされがちです。JPEGなのにサーバーが別の種類として配信している、拡張子だけ変更されて中身が変換されていない、といった状態では、ブラウザが安全のため表示を拒否します。画像編集ソフトでファイルを開き、実際の形式を確認してから、標準的なJPEG、PNG、GIF、WebPなどへ変換すると切り分けしやすくなります。

CSSによって画像が隠されている場合も、X印とは異なる形で問題が現れます。背景画像をbackground-imageで指定していると、HTMLの画像検索だけでは発見できません。スタイルシートのURLもCSSファイルの場所を基準に解釈されるため、HTMLと同じ相対パスを使えるとは限りません。画面上の空白領域を調べるときは、HTMLとCSSの両方を対象にします。

原因を切り分けて復旧する手順

最初に、X印になっている画像を一つ選び、画像のアドレスを直接開きます。直接開いても404になるなら、ファイル名か保存場所の問題です。直接表示できるのにページ内だけ欠けるなら、相対パス、フレームの基準URL、CSSの指定、通信制限を確認します。複数の画像を同時に調べるより、代表例を一つずつ追跡する方が誤判定を防げます。

次にHTMLのimg src、フレームのsrc、CSSのurl()を調べ、記述上のパスを実際のURLに置き換えて確認します。大文字小文字、拡張子、末尾のスラッシュ、URLエンコードの有無も比較します。サーバー上のファイル一覧と照合し、必要なら画像を同じ階層へ一時的に置いて、パスの問題かファイル自体の問題かを分離します。

復旧時は、画像を再配置するだけでなく、HTMLの文字コード、HTTPS、MIMEタイプ、キャッシュも確認します。修正後も古いキャッシュが残ると、利用者の環境でX印が続くことがあります。ファイル名を整理し、相対パスを必要最小限にして、リンク切れを定期的に検査できる状態へ移すと、再発を抑えられます。

画像が完全に失われている場合は、ウェブアーカイブ、管理者のバックアップ、別の公開ページに残る複製画像を照合します。ただし、第三者が保存した画像を再利用する際は権利関係を確認し、元のデザインをそのまま復元できない場合には、代替画像と説明文で情報を補います。見た目の復旧だけでなく、サイトが何を案内していたのかを読者に伝えられる形に整えることが大切です。

手元のHTML、画像フォルダー、サーバーログをそろえて確認すれば、レガシーサイトのX印は「謎の表示崩れ」ではなく、パス、形式、権限、通信のどこで失敗したかを示す手掛かりになります。古いページを保存・修復する場合は、まず代表的な欠落画像のURLとステータスを記録し、原因に応じた修正を一つずつ反映してください。