

ホームページのページURLを変えるときは、旧URLごとに、同じ目的で使える新しいページがあるかを決めます。外部から案内されたリンクや、名刺のQRコードはすぐに書き換えられない場合があります。旧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に更新します。本文、共通メニュー、パンくず、カテゴリ、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年以降の扱いも担当者が検討します。
関連する作業