リダイレクトは転送先と途中の経路を確認する

古いURLから新しいURLへ案内するリダイレクトは、最終ページが開くだけでなく、意図した経路で到着するかを確認します。トップページへの一括転送だけでは困る場合があります。

元URLと行き先の表を作る

記事のURLを変えるなら、古い記事と対応する新しい記事を一行ずつ対応させます。対応する内容がなくなった場合は、関係のないページへの転送を自動で割り当てず、残す案内や削除の扱いを判断します。

HTTPには301や308などの恒久的な転送と、302や307などの一時的な転送があります。フォーム送信などではHTTPメソッドの扱いも関係するため、数字だけを置き換えず、配信サービスの用途別の案内に従います。

ブラウザの開発者ツールでネットワークを記録し、元URLから開きます。HTTPとHTTPS、wwwありなし、末尾スラッシュなどのルールが互いに戻し合っていないか確認します。何段も経由する場合は、可能なら最終URLへ直接案内できるか見直します。

転送があるからと古いリンクを残し続けず、自分で管理できるリンクは新しい行き先に直します。設定後はクエリ付きURLや下層ページも試し、必要な情報を落としていないか確認してください。

転送の目的は、古い入口を使った人が必要な内容へ進めることです。新しいURLで何かが表示されるだけでは、元のリンクが約束していた情報を渡せたとは言えません。記事なら同じ記事、手続きの案内なら対応する手順というように、内容の関係を先に決めます。

一つのルールで全てをトップへ送ると設定は短くできますが、読者がどこへ行きたかったかを失う場合があります。URLの対応表を作る工程は、その関係を確認するためのものです。置き換え先のないページは、残す案内や削除の扱いを個別に判断します。

旧ブログの記事を新しい記事ディレクトリへ移す場面を考えます。まず公開中の記事を一覧にし、各記事の新しい場所を対応させます。新ページの内容と表示を確認してから、古い入口の転送を設定します。試験では古いリンクから開き、最終URLと見出しを照合します。

途中で一度トップへ進み、さらに別のURLへ転送されるような経路があれば、ルールが重なっていないか見ます。HTTPからHTTPS、ホスト名の統一、記事移転を別々に設定した場合でも、組み合わせた結果を確認します。管理できる内部リンクは新URLへ直し、古い入口は過去の案内を支えるために扱います。

GETで記事を開く確認と、フォームを送信する確認は同じものではありません。送信処理を含むURLでは、メソッドなどの扱いを実装と公式案内で確認します。転送コードを数字だけで置き換えて終えず、対象の操作に必要な動作を確かめます。変更記録には元URLと到着先、検査した操作を残します。