相対パス中心の旧サイトを安全に読み解く方法

古いHTMLで構成されたウェブサイトでは、ページ間のリンクが https:// から始まる完全なURLではなく、現在のページを基準にした相対パスで記述されていることがあります。ファイルを同じフォルダー内で移動するだけなら便利な書き方ですが、サーバーの設定変更、URLの正規化、HTTPS化などが加わると、リンク先が意図せず変わる可能性があります。

とくにフレームを使ったサイトでは、画面に表示されている親ページと、実際にリンクを持つ子フレームのURLが異なる場合があります。利用者が見ているアドレスと、ブラウザーが相対パスを解決する基準URLが一致しないため、見た目だけではリンク切れの原因を判断しにくくなります。

文字コードの不整合、古いHTML、欠落した画像、別ドメインのトップページへの誘導が重なると、サイトの構成や本来の提供内容を確認する作業も難しくなります。こうした環境では、リンク文字列だけでなく、実際のリクエスト先、リダイレクト、フレーム定義、サーバー上のファイル配置を一つずつ照合する必要があります。

リンクの書き方	解決の基準	主な利点	起こりやすい問題
guide.html	現在のページの階層	短く、同一フォルダーで扱いやすい	URL階層の変更でリンク切れになる
../guide.html	現在のページの親階層	下層ページから上位へ移動できる	階層を一段変更すると参照先がずれる
/guide.html	ドメイン直下	サイト内で基準が安定しやすい	サブディレクトリ公開では別の場所を参照する
https://example.jp/guide.html	指定した完全なURL	解決結果が明確	ドメイン移転やHTTPS変更の負担が大きい
#guide	同一ページ内の識別子	ページ内移動に便利	識別子の削除や重複で動かなくなる

相対パスが参照する場所を確認する

相対リンクは、リンクが書かれたHTMLファイルのURLを基準に解決されます。たとえば docs/manual.html という記述が /archive/index.html にある場合、通常は /archive/docs/manual.html が参照先です。サイトのトップページから見れば docs/manual.html に見えても、下層ページに同じ記述があれば別の場所へ向かいます。

ただし、HTMLに <base href="..."> が設定されている場合は、通常のページURLではなく、base要素の値が基準になります。相対リンクがすべて同じ外部ディレクトリへ送られている、あるいは移転前のドメインへ向かっている場合は、リンクそのものを修正する前にこの要素を確認することが重要です。

末尾のスラッシュにも注意が必要です。/shop/ はディレクトリとして扱われやすい一方、/shop はファイルのように解釈されることがあります。サーバーが /shop を /shop/ にリダイレクトすると、相対パスの基準が変わり、images/logo.gif の参照先が一段違う階層になることがあります。

フレーム構成では表示URLと基準URLが異なる

フレームセットを使うページでは、親HTMLが top.html や frameset.html を読み込み、ナビゲーション、本文、補助情報を別々のフレームに表示します。リンクがナビゲーション側のHTMLにあるなら、そのファイルのURLを基準に解決されます。ブラウザーのアドレス欄に親ページが表示されていても、子フレーム内の相対パスは親ページを基準にしません。

target="_top"、target="_parent"、target="main" などの指定も、遷移結果を左右します。リンク先が正しいHTMLファイルでも、誤ったターゲット名によって小さなフレーム内に表示されたり、外側のフレームを置き換えたりします。古いサイトを復元する際は、リンク先URLとターゲット属性を別々に記録すると原因を切り分けやすくなります。

現在のように日本語版の案内だけが表示され、別のトップページへ誘導される構成では、案内ページ、フレームセット、実際のコンテンツページが異なる場所に置かれていることがあります。画像やタイトルが文字化けしている場合も、ファイルの欠落とは限りません。EUC-JP、Shift_JIS、UTF-8の指定が実ファイルと合っていない可能性があるため、リンク確認と文字コード確認を同時に行います。

階層変更とドメイン移転で起きる問題

相対パスは、同じサイト内でフォルダー構成を保つ限り管理しやすい方式です。しかし、旧サイトを /old/ からドメイン直下へ移す、ページを /products/ へ集約する、拡張子を取り除くといった変更を行うと、../ の数やファイル名が合わなくなります。リンク切れが一部だけ発生するため、トップページが表示できても安心できません。

画像、CSS、JavaScript、PDF、音声ファイルへの参照も同じ影響を受けます。本文リンクの確認だけでは、背景画像やフレーム用のナビゲーション、印刷用スタイルシートの欠落を見落とします。HTML内の href と src に加え、CSSの url()、フォームの action、JavaScript内で組み立てられるパスも調査対象に含めます。

HTTPからHTTPSへ移行する場合、相対パスはプロトコル変更の影響を受けにくいという利点があります。ただし、相対リンク先のサーバーがHTTPSに対応していなければ、移行後に接続エラーが発生します。また、http:// を固定した絶対URL、外部画像、古いフレーム先が混在すると、混在コンテンツとしてブラウザーに遮断されることがあります。

リンク切れを機械的に調査する

最初に、サイトの全HTMLを保存し、ファイルごとの実URLと相対リンクを一覧化します。リンク文字列だけを並べるのではなく、「どのファイルに書かれているか」「どのURLへ解決されるか」「HTTPステータスはいくつか」「リダイレクトがあるか」を記録します。これにより、同じ index.html という記述が場所によって別のURLになる状況も把握できます。

ブラウザーの開発者ツールでは、Networkパネルで実際のリクエスト先を確認できます。404だけでなく、301や302が何度も続くケース、200を返しているもののエラーページを表示しているケースにも注意します。古いサーバーでは存在しないファイルに対しても汎用ページを返す設定があり、ステータスコードだけでは正常と判断できない場合があります。

自動検査を行うときは、リンクチェッカーの結果をそのまま修正リストにしないことが大切です。外部サイト、アクセス制限のある管理ページ、フォーム送信先、フレームのターゲットは、機械的な巡回だけでは正しく判定できません。重要な導線は実ブラウザーでも開き、文字コード、画像表示、ページタイトル、戻る操作、スマートフォンでの挙動を確認します。

修正時に決めておきたい基準

リンクの修正では、すべてを絶対URLに変える方法が必ずしも適切とは限りません。単一ドメイン内で将来もフォルダー構成を維持するなら、ドメイン直下を基準にしたルート相対パスが安定することがあります。一方、サブディレクトリに設置する可能性があるサイトでは、ルート相対パスが公開環境と合わない場合があります。

ページ移転を予定している場合は、リンクを直すだけでなく、旧URLから新URLへの恒久的なリダイレクトを設定します。検索エンジンや外部サイトが保存している古いURLから利用者を正しいページへ送るためです。リダイレクト先でも相対リンクが正しく解決されるよう、末尾スラッシュ、拡張子、大小文字の扱いを統一します。

修正履歴には、変更前の記述、変更後の記述、確認した公開URL、関連する画像やフレーム名を残します。古いサイトでは同じファイル名が複数のディレクトリに存在することがあり、単純な一括置換が別ページの導線を壊すことがあります。公開前にバックアップを取り、ステージング環境で全ページを巡回してから本番へ反映します。

利用者と検索エンジンへの影響

相対パスの誤りは、単なる404だけでなく、利用者がサイトの構造を理解できなくなる原因になります。ナビゲーションがフレーム内に閉じ込められていると、個別ページをブックマークしたときにメニューが表示されなかったり、検索結果から本文だけを開いた利用者がトップへ戻れなかったりします。重要なページには、独立して閲覧できるタイトル、見出し、パンくず、サイト内リンクを用意します。

画像の代替テキスト、リンクの目的が分かる文言、キーボード操作への対応も確認します。壊れた画像アイコンや文字化けしたリンク名は、視覚的な印象を損なうだけでなく、支援技術を使う利用者にも内容を伝えにくくします。古いフレームを残す場合でも、主要な情報へ到達できる通常のHTMLページを別途整える方法が有効です。

サイトの現状や移転予定を管理者に確認する必要があるなら、お問い合わせ窓口から、対象ページのアドレス、発生日時、表示されたエラー、使用したブラウザーを具体的に伝えます。文字化けした画面のスクリーンショットだけでなく、開発者ツールで確認した実際のリクエスト先を添えると、旧ファイルの所在やサーバー設定の問題を特定しやすくなります。

相対パス中心のサイトを扱うときは、HTMLの文字列、URLの解決規則、フレームの読み込み関係、サーバーの応答を一つの記録にまとめてください。移転やHTTPS化の前後で同じ検査を行い、内部リンク、画像、スタイルシート、外部誘導、リダイレクトを確認すれば、見た目では分からない不具合も発見できます。

古いページを急いで全面的に書き換えるより、まず現状のファイル配置とリンク経路を保存し、壊れている箇所を再現可能な形で整理することが安全です。確認結果をもとに、相対パスの維持、ルート基準への統一、絶対URLへの変更、フレーム構成の整理を選び、公開環境で一つずつ検証してください。