サイト移転でURLが変わるときの301リダイレクト手順

サイトをリニューアルする、ドメインを変える、CMSを入れ替える。どれもURLが変わる可能性のある作業で、そのたびに「検索からの流入が消えないか」という不安がついてきます。

やることの中心が301リダイレクト（古いURLにアクセスがあったとき、新しいURLへ自動的に転送し、そのURLが恒久的に移ったとGoogleにも伝える設定）であることは、多くの方がすでにご存じだと思います。ただ、実際に事故が起きるのは「301を張る」という一行の作業そのものではなく、その前後——どのURLをどこへ移すか決める段階と、移した後に本当に転送できているか確かめる段階です。

この記事は、自社サイトを自分で移転させるエンジニア／サイト運用担当の方に向けて、Google公式ドキュメントに書かれている準備項目を土台に、example.com から example.net への移転を1回通してみせる形でまとめます。読み終わったときに、移転当日までに手を動かして潰しておくべき項目が具体的に決まっている状態を目指します。

公式が「準備」として挙げていること

Googleの「サイト移転（URL 変更あり）」のページでは、Google検索への影響を最小限にするための準備として、旧URLを新URLに対応づけること、内部リンクを更新すること、新しいサイトマップを作ること、そして旧URLから新URLへサーバー側のリダイレクト（301／308）を実装することが挙げられています。

ここで注目したいのは、4つのうち3つが「リダイレクトを張る前」の作業だという点です。

• **対応づけ（マッピング）**は、旧URLの一覧と、それぞれの移転先を1行ずつ決めた表です。ここが曖昧なまま移転すると、あとから「どこへ転送すべきだったのか」を誰も答えられなくなります。
• 内部リンクの更新は、記事本文・ナビゲーション・パンくず・サイトマップ・構造化データの中に残った旧URLを新URLへ書き換える作業です。リダイレクトがあるからそのままでも動く、というのが厄介なところで、動いてしまうので放置されやすく、サイト内リンクが延々と転送を経由し続ける状態が残ります。
• 新しいサイトマップは、新URLだけを載せたものを用意します。

つまり、リダイレクトは「準備の結果を実行に移す最後の一手」です。対応表がないままリダイレクト設定ファイルを書き始めると、設定ファイルそのものが実質の対応表になってしまい、抜けを見つけられなくなります。

見落としやすい3つ：画像・PDF、robots.txt、証明書

同じ公式ページには、HTMLページ以外についても書かれています。

自分がホストしている画像やダウンロード物（PDFなどのドキュメント）も移す対象で、これらにはすでにGoogle検索やリンク経由のアクセスがあることがあり、だからこそユーザーとGooglebot（ページを巡回して情報を集めるGoogleのロボット）に新しい場所を伝えるのが役に立つ、という説明です。

移転作業はどうしてもHTMLページの一覧を中心に進みます。しかし資料ダウンロードや製品カタログをPDFで配っているサイトでは、そのファイルのURLが外部から直接リンクされていることも珍しくありません。対応表を「ページの表」ではなく「URLの表」として作ると、この抜けを防げます。PDFそのものの扱いについてはPDFを検索結果でどう扱うかの整理も合わせてご覧ください。

新サイトのrobots.txtを設定し、ファイル内の規則を確認することも準備として挙げられています。ステージング環境をそのまま本番に昇格させる進め方だと、開発中の「すべて拒否」の記述が残ったまま公開されてしまう事故が起こり得ます。新ドメインのrobots.txtは、移転当日にブラウザで開いて中身を目で読む——これだけで防げる種類の失敗です。

HTTPSへ移る場合は、サーバーで必要なTLS証明書を取得して設定することも同ページに含まれています。ドメインが変われば証明書も新しいドメインのものが必要になるので、移転日の直前に慌てないよう、証明書の発行と自動更新の仕組みまで含めて先に済ませておきます。

リダイレクトの実装：サーバー側を第一に

Googleの「リダイレクトと Google 検索」のページには、リダイレクトの実装方法がいくつか並んでいます。判断の軸になるのは、そのうちJavaScriptによるリダイレクトについて、サーバー側でできない場合にだけ使うと書かれている点です。同じページでは、Googleは対象URLのクロールが完了した後に、Web Rendering ServiceでJavaScriptを解釈・実行する、と説明されています。

PHPで恒久的なリダイレクトを設定する例も公式に載っています。

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/newurl');
exit();

このコード例には注意書きが付いていて、画面に何かを出力する前にヘッダーを設定しなければならないとされています。テンプレートを読み込む処理より前、デバッグ用の出力より前に書く、ということです。同ページには一時的なリダイレクトをPHPで設定する例も並べて示されています。

実装方法の選び方は、次のように整理できます（サーバー側を選べるかどうかが分岐点です）。

example.com から example.net へ、5ステップで通してみる

ここまでの内容を、実際のケースに1回通します。前提は「example.com を example.net へ移す。ページ構成も見直すのでパスも一部変わる」という、よくある形です。

1. URLの棚卸しと対応表づくり。旧サイトのサイトマップ、Search Consoleの「ページ」レポート、サーバーのアクセスログを突き合わせて、旧URLを1列目に並べます。2列目に新URL、3列目に「まだ決まっていない」印を置きます。HTMLページだけでなく、/download/catalog-2026.pdf のようなファイルも同じ表に入れます。3列目の印がゼロになるまで、この表が移転のToDoリストです。

2. 1対1で移す先を決める。統合してなくなるページは、内容がもっとも近い新ページを移転先にします。「決めきれないから、とりあえず全部トップページへ」という判断は、対応表の3列目を埋めるための逃げ道になりやすく、しかも読者にとっては目的のページに着けない転送になります。まとめ先ページのどこに旧内容が入ったのか、表にひとことメモを残しておくと後で説明できます。

3. 新サイト側を先に整える。新ドメインで、内部リンクを新URLに書き換えたコンテンツを用意し、新URLだけを載せたサイトマップを置き、robots.txtを開いて規則を読み、TLS証明書を設定します。この段階では旧サイトはまだ生きています。

4. リダイレクトを実装して実測する。対応表の全行について、旧URLへのアクセスが新URLへ301で転送されるようにします。実装後は、対応表からサンプルを抜いて実際のレスポンスを確認します。

   curl -sIL https://example.com/service/price | grep -Ei '^(HTTP/|location:)'
   

   この出力で、1回目が 301、location: が意図した新URL、最終的な到達が 200 になっていれば、その行は合格です。末尾スラッシュの有無で挙動が変わることもあるので、両方の形で確認しておくと安心です（この論点はURL末尾のスラッシュを1つに統一する手順で詳しく扱っています）。

5. Search Consoleを整える。新ドメインのプロパティを追加して所有権を確認し、新しいサイトマップを送信します。アドレス変更ツールを使うかどうかは、次の節の判断に従います。

この5ステップで手が止まりやすいのは2番です。逆に言えば、2番に時間をかけられれば移転作業の質はほぼ決まります。

アドレス変更ツールを使うかどうか

Search Consoleの「アドレス変更ツール」のヘルプには、いくつかの移転パターンが並べて挙げられています。そのうちhttpからhttpsへのアドレス変更については、「URL変更を伴うサイト移転のガイドラインに従ってください。ただしこのツールは使わないでください。Googleがあなたの変更を判断します」と明記されています。同じ並びには、サイト内で一部のページを別の場所へ移すケース（example.com/oldpath/... から example.com/newpath/... への移動）も挙げられています。

このことから、実務上の方針はこう置けます。ツールに頼るのはドメインそのものが変わる移転に絞り、同一ドメイン内のパス変更や常時HTTPS化では、ツールを探すのではなくサーバー側のリダイレクトとサイトマップの整備に集中する——という切り分けです。

ツールを使う側のケースでは、ヘルプに次の点が書かれています。

• www.example.com と example.com から new-example.net へ、といったバリアント（表記の違い）を、いま実際には使っていないものも含めてSearch Consoleで確認済みにしておくこと。
• ツールはソースプロパティのすべてのプロトコルを移すこと。http://example.com を指定した場合、https://example.com も一緒に移ります。

2つ目は見落としやすいところです。「http側だけ指定したつもりだったのに」という誤解が起きないよう、指定するプロパティと実際に移る範囲を事前に一致させておきます。

移転後に順位が動いたとき、原因を決めつけない

移転後の数字が動いたとき、真っ先に「移転が失敗した」と考えたくなります。ですが切り分けの材料として、Googleの「コア アップデートとサイトの関係」のページに書かれている2点を押さえておく価値があります。

ひとつは、Googleは年に数回、検索アルゴリズムとシステムに対して大きく広範な更新（コアアップデート）を行い、その情報をランキング更新の一覧で知らせている、という点です。同ページは、この変更は本質的に広範なもので、特定のサイトや個別のページを対象にしたものではないと説明しています。多くのサイトは特に気にする必要がなく、更新が完了したことに気づかないこともある、とも書かれています。

もうひとつは、検索結果の順位は静的でも固定でもないという点です。同ページは、Google検索の結果は本質的に動的に更新される（ユーザーの期待が時とともに変わり、ウェブにも新しい内容や更新が絶えず加わるため）と説明し、この継続的な変動によって自然検索からの流入が増減する可能性があるとしています。

つまり、移転後の変動には少なくとも「移転作業の不備」「検索側の広範な変動」という2つの筋があり、どちらかを見ずに結論を出すと対策を間違えます。実務としては、次の順で見るのが素直です。

1. 自分の作業の側を先に潰す。対応表のサンプルで301の実測を再度取り、新サイトのrobots.txtとサイトマップの状態、Search Consoleのページレポートで新URLの登録状況を確認します。転送が期待どおりに動いていない行が残っていれば、それが最初の仮説です。移転後に「ソフト404」が出た場合の見方はソフト404の原因と直し方にまとめています。
2. 作業側に問題が見つからなければ、時期を照らし合わせる。変動の始まった時期と、ランキング更新の一覧で告知されている時期が重なるかを確認します。
3. どちらとも言えない期間があることを受け入れる。新URLのクロールと登録が進むのを待つ局面もあります。ここで手を増やすより、記録を取りながら監視を続けたほうが、後から振り返れる材料が残ります。Search Consoleでのインデックス登録リクエストの考え方はインデックス登録リクエストの扱いで扱っています。

よくある誤解とエッジケース

リダイレクトはいつ外せるか。ここは自分のサイトの事情で決める話です。旧URLは外部サイトのリンクやブックマークの中に残り続けるので、外した瞬間からその人たちは行き先を失います。当面は外さない前提で運用計画を立て、外すとしても旧URLへのアクセスがどれくらい残っているかをアクセスログで確認してから判断するのが安全です。維持期間を何日と決め打ちするより、自分のサイトに旧URL経由のアクセスがどれだけ残っているかを見て決めたほうが、実態に合った判断になります。

旧サイトマップに旧URLを残すか。公式に挙がっている準備は「新しいサイトマップを作る」ことです。新URLを載せた新しいサイトマップを主役にし、旧URLの一覧は自分の対応表として手元に持っておくのが素直な形です。

一度に何を変えるか。ドメイン移転、CMSの入れ替え、デザインの全面刷新を同じ日に実施すると、数字が動いたときに原因を切り分けられなくなります。ひとつずつ時期をずらして実施できるなら、そのほうが後から調べやすくなります。移転の翌週に大規模なリライトを始めるのも、同じ理由で観察を難しくします。

移転前の数字は先に控えておく。新ドメインのプロパティで、移転前の期間の数字まで遡って見られるとは限りません。移転前後を比べたいなら、旧プロパティの表示回数・クリック数・ページ単位の数字を移転前にエクスポートしておくのが確実です。移転してから比較したくなったときに手元に材料がない、という状況は避けたいところです。

移転前チェックリスト

移転当日を迎える前に、この表の右側を自分の言葉で埋められるかを確認してみてください。

移転は、作業量が多い割にひとつの抜けが目立つ種類の仕事です。だからこそ、公式が挙げている「対応づけ・内部リンクの更新・新しいサイトマップ・サーバー側のリダイレクト」を、そのままチェック項目として持ち込むのが確実です。順位の変動そのものは自分でコントロールできませんが、対応表と実測の記録は完全に自分の手の内にあります。移転後に不安になったとき、最初に開けるのはその記録です。