ホームページのページURLを変えるときのリダイレクト対応表

ホームページのページURLを変えるときのリダイレクト対応表

ホームページのURL変更に備え、旧URLと後継先、転送の応答、リンク、XMLサイトマップを確認する対応表です。

ホームページのページURLを変えるときは、旧URLごとに、同じ目的で使える新しいページがあるかを決めます。外部から案内されたリンクや、名刺のQRコードはすぐに書き換えられない場合があります。旧URLを維持できる範囲を先に調べ、変更する場合は転送、リンク、サイトマップを一枚の対応表で追います。



古いページから新しいページへの転送を示すイラスト


変えるURLと維持するURLを分ける

現在のURL、ページの目的、変更する理由、リンクしている場所を一覧にします。見出しやページ名の表現を変えるだけなら、公開URLを維持できることがあります。フォルダー構成や公開先を変更する場合は、作成ツールとサーバーが現在のURLを継続して使えるかを確認します。ドメインを変えずに移転する準備は、公開先の変更を調べるときに使えます。


対象は本文ページだけでなく、料金PDF、地図の案内、フォーム、外部から参照される資料です。外部リンクをすべて把握できない場合でも、よく使う案内、検索で確認できるページ、印刷物や固定投稿を先に点検します。何を変えるか決めたら、公開前のURLと、変更した後に利用者ができることを一行ずつ記載します。残せるURLを残すことと、変更したURLの行き先を整えることを分けます。


事前に控える一覧には、以前に変更したURLや、同じページを開く別表記も含めます。既に転送がある場合は、今の最終到達先までたどり、今回の変更で影響する入口を確認します。サイトの作り直しで同じ目的の案内を別の場所へ移す場合も、既存のURLと内容を先に照合します。

旧ページに対応する行き先を決める

同じ目的で使える後継がある

旧ページが体験の申込を案内していたなら、新ページでも同じ対象の体験と受付条件を確認できるかを見ます。後継が決まれば、公開先で利用できる恒久または一時の転送を選びます。Googleの公式資料は、永続的な変更での301や308、一時的な変更での302や307などの扱いを説明しています。期間と目的を決めてから、使うサーバーやサービスの手順で設定します。


後継にあたるページがない

提供終了した資料やサービスでは、同じ用件を果たせる後継があるかを担当者に聞きます。関連性のないトップへ一律に送ると、利用者は元の案内を探し続けることになります。終了のお知らせを表示するのか、提供していないことを示す404や410の応答を返すのかは、情報の性質と公開側の要件を照合して決めます。


旧URLの役割 新しい行き先の例 確認すること
体験申込案内 同じ教室の新しい体験ページ 申込条件と新しいURL
料金PDF 同じ対象の現行料金資料 版と適用日
受付終了の特設ページ 後継の有無を確認 終了を知らせる方法
継続する店舗案内 旧URLを維持 リンクと内容が継続するか

「新しいサイトに同じ内容がある」という判断は、担当者だけでなく、旧URLを保存している人が同じ用件を果たせるかで行います。別の年度の申込へ進む場合は、受付の対象と状態を確認します。過去の資料を残す必要がある場合は、最新版への案内と旧資料の役割を分けます。

転送と新ページの整合を確認する

切替前に、隔離した環境で、旧URLを開いたときの最初の応答と、最終的に開くページを確認します。転送が何度も重なっていないか、旧と新を往復して停止しないか、最終ページが正規として示すURLが予定どおりかを見ます。設定を変更する場合は、現在の規則の控え、適用する範囲、戻す手順を用意します。URLごとに設定する場合と、フォルダー全体に適用する場合では影響範囲が違います。


ブラウザーとローカルのHTTPサーバーを使った検証では、架空の旧URLで301を受け、続けて新URLで200を受けました。新ページの正規URLの指定も、最終的に到達したページと一致しました。これはローカルでの例で、実際に使うサーバーや検索結果への反映は、運用中の環境で別に確認します。


確認には、旧URLを直接開く試験と、以前の掲載ページからリンクを押す試験を用意します。転送が設定どおりでも、新しいページに必要な画像や申込先が出ないことがあります。公開前に、到達先の見出しと、想定する操作がそろっているかも見ます。意図しない経路が見つかった場合は、適用範囲を広げる前に対象を絞ります。



旧URLごとに移転・統合・廃止の扱いを確認する図
ローカルのHTTPサーバーとChromeの検証結果です。各項目は本文でも確認できます。

リンクとサイトマップを更新する

転送が用意できたら、サイトの内部リンクを新しい正規URLに更新します。本文、共通メニュー、パンくず、カテゴリ、PDFのリンク、案内に使うQRコードを確認します。XMLサイトマップは公開する新しいURLを載せ、転送される旧URLが残っていないかを調べます。外部サイトや印刷物は変更できる範囲と担当を確認し、変更できないリンクから来る人も旧URL経由で目的を果たせるかを見ます。


修正表には、旧URL、新URL、最初の応答、最終応答、正規URL、確認日を残します。公開する日と戻す条件を決め、途中で別の作業が変更した規則がないかを確認します。XMLサイトマップ送信後の確認とリンク切れの点検は、転送設定の後でそれぞれ照合できます。


対応表は、転送しないで維持するURLや、後継を探しているURLも区別します。記事やカテゴリの一覧を更新する人と、転送を管理する人が異なる場合は、新しいURLの正本を共有します。両方を反映した日と確認した端末を記録すると、公開直後の調査に使えます。


この対応表の検証例は手元のHTTPサーバーで試した結果です。実際の作業では確認日と担当を空欄に追記し、新旧の完全なURLを管理表へ記入します。


旧URLのパス 新URLのパス 最初の応答 最終応答と正規URL 確認日・担当
検証例 /old /new 301 200、到達した /new と一致 ローカルの検証
記入欄 記入欄 記入欄 記入欄 記入欄
記入欄 記入欄 記入欄 記入欄 記入欄

公開後の確認項目を決める

公開後は、旧URLと新URLを使って代表の案内を再確認します。検索や外部からの入口が動き、スマホで予約や問い合わせへ進めるかを見ます。Search ConsoleのURL検査を利用する場合は、新旧のURLで公開状態と登録された情報を分けて確認します。検索に出る時期や順位がいつ元に戻るかを決めつけず、確認した日と状況を記録します。


旧URLへのアクセスが残る間は、転送先が同じ目的を果たす状態か点検します。再び新しいURLへ移る時には、元から最終先まで何度も転送されないかを見ます。切替直後の問題が落ち着いても、外部から使われる案内をいつまで提供するか、費用や公開先の契約を含めて担当者が決めます。


確認用の期間は、公開後に何を見られるかを考えて設定します。アクセスの記録が見られるなら旧URLの利用やエラーを確認し、見られない場合は重要な入口の実際の動作を点検します。外部から旧URLを利用する人がいる限り、転送の終了時期を担当者と検討し、利用状況が分からない欄は未確認と記載します。


修正が必要になった場合は、最初の応答、転送の先、開いたページの内容を一緒に記録します。旧URLが開けない場合に、設定の変更と新ページの公開のどちらを直すかを分けて考えます。


運用で使える対応表にするには、各行に確認担当と、次に見直す時期を添えます。旧URLを後で確認する担当者が、変更当時の理由と新しい行き先を読める場所に保存します。


サイト移転に伴って恒久転送を設定する場合は、Googleのサイト移転ガイドで、通常少なくとも1年間の維持を勧めている点も確認します。実際の利用者が旧リンクを使う場合は、1年以降の扱いも担当者が検討します。


確認に使った資料

情報確認 2026/11/09。製品・サービスの仕様は参照先でご確認ください。