ページのデザインが変わった後も、URLは使われ続けます。ブックマーク、メッセージ、提案資料など、サイトの外にも入口が残っているからです。したがって、ページの移転はURLをきれいに整える作業だけではありません。以前のリンクを開いた人が、期待していた情報にたどり着けるようにする責任も伴います。私たちは、サーバーの設定より先に、小さな「内容の対応表」を作ることを勧めます。
そもそもURLを変更する必要があるか
サービス名が変わっても、必ずURLを変える必要があるとは限りません。見出し、説明、ナビゲーションを更新し、今も意味が通じるアドレスを残す方法もあります。一方、複数ページを統合する場合や、別のカテゴリーへ移す場合は、その理由を記録しておきます。必要な変更なのか、見た目のために余分な作業を増やしているのかを判断しやすくなります。
編集を始める前に、現在のURLを一覧にしましょう。それぞれに「このページで訪問者は何を知りたいのか」を添えます。講座なら学習内容、サービスなら進め方、記事なら特定の疑問への答えかもしれません。新しい到着先は、この目的を基準に選びます。見出しに似た言葉があるというだけでは、適切な対応とは言えません。
古い入口ごとに、意味のある行き先を決める
対応表には、旧URL、新URL、変更理由、確認担当者という四つの欄があれば十分です。数ページの移転に大掛かりな管理システムは不要です。大切なのは、判断した本人以外でも、後から理由を理解して確認できることです。まだ行き先を決められないページは、完了した項目に紛れ込ませず、未決事項として残します。
例えば、写真の準備についての二つの解説を、一つの詳しい記事にまとめたとします。新しい記事が両方の疑問にきちんと答えていれば、二つの旧ページの移転先になり得ます。しかし、トップページが存在するというだけで、同等の代わりになるわけではありません。適切な後継ページがない場合は、全員をトップへ送るのではなく、内容の扱いを改めて判断します。
恒久的な移転か、一時的な変更か
Googleは、301や308などの恒久的なリダイレクトと、302や307などの一時的なリダイレクトを区別しています。選択は実際の意図に合わせます。旧URLを今後使わないのか、それとも後で元に戻すのか、という違いです。設定方法は利用するプラットフォームによって異なります。他のサイトの設定例に書かれていたから、という理由だけでコードを選ばないようにしましょう。
フォーム送信、決済、そのほかの操作は、記事を読む場合とは分けて考える必要があります。MDNは、リダイレクトによるリクエストメソッドの扱いの違いを説明しています。情報ページ用の設定を、データ送信にもそのまま流用しないことが重要です。開発担当者には、ページが表示されるかだけでなく、実際の操作が適切に完了するかを確認してもらいます。
途中の寄り道を整理する
何度もサイトを改修すると、旧URLから中間のURLへ進み、さらに現在のページへ進む経路が残ることがあります。編集用の対応表には、できるだけ最終的な到着先を直接記します。そうすれば、経路を説明しやすく、誤った対応も見つけやすくなります。アドレス同士が互いに戻し合うループがないかも、別に確認します。
メニュー、カード、ボタン、本文中のリンクも見直し、現在のページを直接指すようにします。canonical、言語別ページの対応、サイトマップも確認対象です。リダイレクトは過去の入口を支える仕組みであり、現在のサイト内リンクを放置してよい理由にはなりません。対応表は公開時だけの資料ではなく、編集と開発が共有する作業の基準になります。
表示だけでなく、移動の結果を確かめる
移転したページごとに旧URLを開き、実際の最終URLを記録します。その内容が元の目的と合っているか、言語、重要な説明、画像、主要な操作を確認しましょう。確認日と未解決の例外も残します。リダイレクトが正常に動くことは、検索への登録、順位、訪問数を保証するものではありません。
内容そのものがなくなった場合には、役に立つ404ページが別の役割を果たします。また、新しい行き先をクリック前から伝えるために、リンクの文言も見直してください。よい移転が守るのは、URLを開けることだけではなく、訪問者が持ってきた疑問への道筋です。