リニューアル後、旧URLをそのまま消してはいけません。訪問者は商品をブックマークしていたり、検索結果から古い記事へアクセスしたりします。ページがなければ離脱につながります。URL変更時の301リダイレクトはどう処理すればよいのでしょうか。旧アドレスを対応する新コンテンツに割り当て、恒久的に転送したうえで、各経路を実際に開いて確認します。

301は、ページが恒久的に移動したことをブラウザーと検索エンジンに伝えるサーバー応答です。適切な転送先を自動で探すものではありません。誤った転送先、ループ、すべての旧ページからトップページへの転送では、訪問者は求める情報にたどり着けません。

まず301が適切な場面を理解する

商品コンテンツの移動元が example.com/old-product/ への example.com/new-product/ で、旧アドレスを独立したページとして廃止するなら、典型的な恒久移転です。301と308はいずれも恒久リダイレクトを示します。初心者は現在のWordPressサイトで利用できる301設定を使えます。Googleはサーバー側の301と308を恒久移転の強いシグナルとして扱います。詳しくはGoogleの次の資料を参照してください。 リダイレクトの公式ドキュメント .

一時的なメンテナンス後に元のURLへ戻す場合は、恒久移転として扱いません。302と307は一時的なリダイレクトです。デザインと内容だけが変わり、URLが変わらないなら、そのURLに追加の301は不要です。

設定前に新URLが正常に動作するか確認します。転送先が404や未公開なら、301が正しくてもコンテンツを届けられません。試験用リストを作り、新ページの準備が整ってから切り替えます。

旧ページに代替ページがない場合は？

旧URLをすべて301にするためだけに、すべてをトップページへ送らないでください。販売終了商品は、内容と購入目的が一致する本当に近い代替商品へ転送できます。適切な転送先がなければ、販売終了を説明するか適切な404/410を返し、無関係なトップページへは送らないようにします。Googleの サイト移行ガイド でも、多数の旧URLを無関係なトップページへ転送するとソフト404として扱われる可能性があると説明されています。

手順1：旧URLと新URLを一対一で対応付ける

現在のサイトマップ、重要な流入ページ、内部リンクをエクスポートし、Search Consoleで訪問や表示が続いている旧URLを追加します。少なくとも旧URL、新URL、ページの目的、処理、検証結果を記録してください。タイトルだけで転送先を推測してはいけません。特にモデル名変更、カテゴリ統合、多言語サイトのリニューアルでは、旧コンテンツを開いて読者の目的を理解します。

これらは説明用の例であり、AIRSANG顧客の実際の移行記録ではありません。本番ではプロトコル、ドメイン、パス、末尾スラッシュ、大文字小文字を完全に指定します。移行元が http への https となる場合や、アドレスに含めるかどうかを変更する文字列が www の場合も、複数回の転送が発生することがあります。最終到達先が意図した正規URLか確認します。

• 旧URL、転送先URL、ページ種別を保存し、個別に確認できるようにします。
• 自然検索流入、外部リンク、頻繁なブックマーク、広告流入のあるページを優先します。
• 設定者と公開日時を記録し、設定元をすぐ特定できるようにします。

手順2：管理しやすい一か所で転送を設定する

WordPressでは既存の転送管理機能、またはサーバーやホスティングのルールを使うのが一般的です。保守担当者に現在の転送管理者を確認し、同じURLに対してプラグイン、サーバー、CDNが異なる転送先を指定するのを防ぎます。Rank Mathなどを使う場合は、インストール済み機能と実際の設定を確認してください。記事でプラグインに触れているからといって、自分のサイトで有効とは限りません。

通常は旧パスと転送先の完全なURLを入力し、恒久リダイレクトを選びます。保存前に、旧パスが意図したページだけに一致すること、転送先に入力ミスがないこと、管理画面、画像、他言語ページに影響しないことを確認します。一括インポート前に、実在する低リスクのURLを一件試します。

開発者がWebサーバーを設定する場合は、完全な対応表を渡し、先にステージング環境で試験してもらいます。Nginx、Apache、CDN、WordPressではルールの構文が異なります。この記事では、本番に貼り付けられると称した万能設定は提供しません。実際のサーバーバージョンと公式資料に合わせて実装し、以前のルールをバックアップしてください。

恒久転送を選び、ルールが作用する場所を確認する

ブラウザーで新ページが開くだけでは、旧URLが301を返している証拠にはなりません。ページスクリプト、meta refresh、新ページへのリンクでも、必要な恒久サーバー応答なしに移動できます。アドレスバーの変化だけに頼らず、設定後のネットワークステータスを確認します。

一件のルールが動作したら、リストを小分けにインポートします。各バッチのルール数、画面キャプチャまたはエクスポート、試験結果、切り戻し担当者を保存します。カテゴリのパスが間違っていても、不具合の発生時点を推測せず、そのバッチを戻せます。

手順3：各旧URLの301と転送先の200を確認する

旧URLをプライベートウィンドウで開き、正しい代替ページに到達するか確認します。開発者ツールのネットワークパネルか信頼できるHTTP確認ツールで応答を調べます。通常の恒久移転では、旧アドレスが301を返し、Locationヘッダーが新アドレスを示し、最終的に200が返ります。ステータス 200 はページが正常にコンテンツを返したことを示し、 404 はページが見つからないことを示します。

最終的にページが開くかだけを見ていると、転送チェーンを見逃します。旧URLから中間アドレスへ、さらに別の転送を経て新ページへ到達する場合です。必要な数回の転送が直ちに失敗というわけではありませんが、長いチェーンは保守が難しく、次のリニューアルでループが起きやすくなります。できる限り最終的な正規アドレスへ直接転送します。

1. 各旧URLを開き、最初のステータスコードとLocationヘッダーを記録します。
2. 最終URLを開き、同一または実際に対応する内容であることと、最終応答200を確認します。
3. 旧アドレスへの戻り、自己転送、誤った言語サイト、バッチ全体がトップページへ到達していないか調べます。
4. 重要ページをモバイルとデスクトップで抽出確認し、画像、ボタン、フォームを調べます。

開発者ツールに不慣れなら、「設定済み」という説明だけでなく、旧アドレス、ステータス、転送先、転送先ステータスをURLごとに示した表を開発者へ依頼します。大規模移行ではスクリプトで全URLを試験できますが、内容の対応ミスを見つけるため、各ページテンプレートのサンプルも手動で開いてください。

手順4：内部リンクを新URLへ更新する

301は旧アドレスを使う人を支える仕組みであり、内部ナビゲーションの通常経路にするものではありません。転送設定後は、メニュー、フッター、記事内リンク、ボタン、商品紹介、メールテンプレートの旧URLを可能な限り更新します。弊社の 旧トップページのセクションを残すか削除するかのガイド は、リンク更新前に残す入口を判断する際に役立ちます。

新ページのcanonicalタグも確認します。canonicalは検索エンジンに主要なURLを伝えます。新しい商品ページが旧URLを指したままだと、移行シグナルが矛盾します。通常は自身の正規URL、または実際の重複コンテンツ対策に応じた正しい版を指定します。ソースコードとプラットフォームのルールを調べずに、すべてのcanonicalを書き換えないでください。

XMLサイトマップを更新し、主要リストには今後も検索エンジンに発見してほしい新しい正規URLを載せ、再送信またはクロールを待ちます。旧ページの転送は残してください。サイトマップからURLを削除したからといって、ルールをすぐ削除できるわけではありません。リニューアル範囲を決める際には弊社の 企業サイト制作の6段階チェックリスト を参照し、納品計画にURL移行と検証を含めてください。

外部サイトの古いリンクは管理できない場合があるため、その訪問者のために301を維持します。協力可能な重要パートナーには、新アドレスへ直接リンクを更新するよう依頼します。中間転送を減らせますが、サーバー側の転送を維持する代わりにはなりません。

手順5：公開後も監視し、旧ルールを保持する

移行直後の数日間は、旧URLへのアクセスログ、404レポート、サイトマップ処理、Search Consoleのインデックス状況を監視します。Google Search Consoleの「ページ」レポートは、欠落ページ、転送ページ、新ページの処理状況を把握するのに役立ちます。レポートには遅延があるため、当日に更新がないだけで移行失敗とは判断できません。

最近アクセスされた旧URLを抽出して再試験し、広告、SNSプロフィール、顧客メールのリンクを特に確認します。旧URLが404なら、対応を追加する前に該当する新コンテンツがあるか確認します。すべての404を自動的にトップページへ転送してはいけません。内部リンクに旧URLが多く残っているなら、リンク元を直して再確認します。

Googleのサイト移行ガイドは、旧URLの転送を一般に最低1年間、利用者や外部リンクがまだ使う場合はさらに長く維持するよう推奨しています。1年は保守の目安であり、1年後の順位回復を保証するものではありません。リニューアル前に弊社の サイトリニューアル費用の対象範囲ガイド を参照し、公開後の監視、リンク修正、ルール維持の担当を決めてください。

症状に応じて原因を調べる

旧ページがトップページや別言語へ転送される

複数の旧パスが一般的な転送先へ割り当てられていないか確認し、サーバー、WordPress、CDNの重複ルールを探します。元の利用目的に合わせて修正します。サイズを知りたい人はブランドのトップではなくサイズ情報に到達すべきです。多言語サイトでは、中国語の旧ページが誤って英語の商品トップへつながらないようにします。

ブラウザーにリダイレクトが多すぎると表示される

通常は二つのルールが互いを指しているか、HTTP/HTTPSやwwwあり・なしの正規化ルールが衝突しています。キャッシュを繰り返し消すのではなく、リクエストチェーンのLocationを一つずつ追跡します。競合するルールを一つ無効化または修正し、プライベートウィンドウとコマンドラインから再検証します。

新ページは動くのに検索結果に旧URLが残る

まずサーバー側301、転送先200、新canonical、内部リンク、サイトマップを整合させ、検索エンジンの処理を待ちます。ルールを保存しても検索結果が即時更新されるわけではありません。表示を急ぐためにスラッグを繰り返し変えたり、同じ誤ったサイトマップを再送したりせず、技術的なシグナルを先に直します。

誤った移行を戻すには、以前の設定バックアップを復元して旧URLが適切な内容を返すようにするか、誤った転送先を正しい一対一の対応に修正します。別の担当者が古いルールを再インポートしないよう、切り戻し時刻、対象URL、再試験結果を記録します。正式な切り戻しでは、内部リンクとcanonicalが復元したURLに一致することも確認します。

まとめ：対応付け、転送、再試験

リニューアルでURLが変わる場合、対応コンテンツが残る旧アドレスは最も関連性の高い代替ページへ恒久転送します。新ページ公開後、すべての旧アドレスが301、最終到達先が200を返すことを確認します。内部リンク、canonical、サイトマップを更新し、404とSearch Consoleのレポートを継続監視します。

初めての移行では、重要な3〜5ページで試験すると、サイト全体を一度に変更するより対応ミスを発見しやすくなります。段階的に広げる前に、ルールの作用箇所、対応の方向、切り戻し担当を確認します。代替のない旧ページを無理にトップへ送らないでください。訪問者が本来求めた情報を見つけられるかどうかが、正しい転送の最も重要な基準です。