Search Consoleでのサイト移行：アドレス変更、リダイレクト、移行後のトラフィック確認

どの種類のサイト移行ですか？

Googleは、ドメインの変更、HTTPSへの切り替え、新しいURL構造を、同じ種類の作業として扱います。つまりURLが変わるサイト移行であり、すべての旧URLを新URLに恒久的にリダイレクトする必要があります。アドレス変更ツールはその作業の一部にすぎず、対象になるのも一部の移行だけです。そのため、計画を立てる前に、この表のどの行に当てはまるかを把握しておくと役立ちます。表の内容はすべて、Googleのサイト移行ガイドとアドレス変更のヘルプページに基づいています。

Googleは、一度に変更するのは1つだけにするよう求めています。新しいドメイン、新しいCMS、新しいデザインを予定しているなら、ガイドでは1つずつ順番に行うことを勧めています。アドレス変更のページでは、移行と新しいURL構造を同時に行うと、Googleが個々のページを学び直す間に「おそらく」一部のトラフィックを失うと警告しています。トラフィックに季節性があるなら、閑散期に移行するのがよいでしょう。移行直後のトラブルに巻き込まれる訪問者が減り、Googlebotに回せるサーバーの余力も増えるからです。

移行の前：Search Consoleで準備すること

1. 両方のプロパティを、すべてのバリエーションで確認する。Googleのガイドでは、たとえばwwwありとなし、HTTPSを使うならHTTPとHTTPSなど、「旧サイトと新サイトのすべてのバリエーションを確認する」とされています。ドメインプロパティなら、すべてのサブドメインと両方のプロトコルを一度にカバーできますが、DNSでの確認が必要です。アドレス変更ツールにはさらに厳しい条件があり、両方のプロパティのオーナーであること、そして両方を同じGoogleアカウントで管理していることが求められます。確認方法が移行後も有効かどうかも確かめてください。HTMLファイルによる確認では、そのファイルを新サイトにコピーする必要があり、メタタグによる確認では、新しいテンプレートにタグを入れておく必要があります。
2. 設定を引き継ぎ、取得済みドメインを確認する。旧サイトにdisavowファイルをアップロードしていた場合、Googleは新しいプロパティに再アップロードすることを勧めています。新しいドメインを中古で取得した場合は、前の所有者が残した手動対策やURL削除リクエスト、「特にサイト全体のURL削除」がないかを確認してください。
3. URLマップを作る。すべての旧URLの移行先を書き出します。Googleは、サイトマップ、サーバーログやアナリティクス、Search Consoleのリンクレポート、CMSから始めることを提案しており、画像、動画、JavaScript、CSSファイルも他のURLと同じように移行されるので含めるよう注意しています。パフォーマンスレポートでクリックのあったページはすべて加えてください。ただし、Search Consoleの画面でエクスポートできるのは1つの表につき1,000行までなので、大きなサイトではすべてを取得するのにAPIが必要です（1,000行の上限を参照）。
4. 旧サイトをクロールする。デスクトップ型クローラーで全体をクロールすると、何かが変わる前の、すべての旧URLのステータスコード、更新が必要になる内部リンク、そして公開日にリダイレクトをテストするためのリストが手に入ります。GoogleもリダイレクトがSEOに問題なく機能しているかの確認にはScreaming Frogを挙げています。旧プロパティにまだリンクレポートがあるうちに、リンク元のサイト一覧を保存しておけば、のちに価値の高いサイトにリンクの更新を依頼できます。
5. ベンチマークをエクスポートする。ページごと、クエリごとのクリック数、表示回数、掲載順位を、少なくとも直近28日分エクスポートします。トラフィックに季節性があるなら、前年の同じ週の分も取っておきましょう。移行後は旧プロパティの数字が減っていきますし、Search Consoleが保持するのは16か月分のデータだけです（データの保持期間を参照）。このエクスポートがあれば、3か月後に新サイトが旧サイトの水準に戻っているかどうかが分かります。
6. 新しいページを準備する。新しいURLにはそれぞれ自己参照のcanonicalタグが必要で、hreflangの指定にも新しいURLを使い、内部リンクは新しいURLを直接指すようにし、新URLのサイトマップは送信できる状態にしておきます。開発中に新サイトをnoindexやrobots.txtのブロックで隠していた場合は、公開日に外すものの一覧を今のうちに作っておいてください。代わりのページがない削除済みまたは統合済みのページは、404か410を返すようにします。

移行当日：301リダイレクト、アドレス変更、サイトマップ

すべての旧URLを1対1で、301でリダイレクトする

Googleは、マップにある旧URLから新URLへの、サーバー側の恒久的なリダイレクト（HTTP 301または308）を勧めています。リダイレクトのドキュメントでは、種類が重要な理由が説明されています。恒久的なリダイレクトでは「インデックス登録パイプラインは、リダイレクトを、転送先を正規とすべきシグナルとして使う」となるのに対し、一時的な302、303、307ではそうならず、旧URLが検索結果に残る場合があります。各旧URLは、最終的な行き先に直接向けてください。Googlebotは最大10回の転送をたどりますが、Googleはチェーンを「理想的には3回以下、少なくとも5回未満」に抑えることを勧めており、直接のリダイレクトならさらに良好です。多数の旧URLを新しいホームページのような無関係な1ページにまとめて送るのは避けてください。Googleは「ソフト404として扱われる可能性がある」としています。ただし、複数の旧ページを1つの新しいページに統合した場合は、すべてをそこにリダイレクトして構いません。また、Googleは301やその他の恒久的なリダイレクトが「PageRankの損失にはつながらない」とも述べています。

リダイレクトは、有効になったらすぐにテストしてください。Googleは、単一のURLにはURL検査ツールを、多数のURLにはコマンドラインツールやスクリプトを使うことを提案しており、移行でよくある間違いの1つとして、新サイトに存在しないURLへのリダイレクトを挙げています。そのあと、準備しておいた作業を実施します。開発用のnoindexとrobots.txtのブロックを外し、新サイトのcanonicalタグが新しいURLを使っていることを確認してください。

アドレス変更ツールの使い方

このツールは、サイトを移行し、リダイレクトが有効になってから使ってください。Googleのヘルプページにも「サイトを移行してリダイレクトしたあとにこのツールを使う」とあります。同ページに記載された要件は次のとおりです。

• 旧プロパティと新プロパティの両方で、同じGoogleアカウントのオーナーであること。
• 旧プロパティが、http://example.com/petstore/のようなパスではなく、ドメインレベル（example.com、m.example.com、http://example.com）であること。
• 旧サイトのホームページが新サイトのホームページに301でリダイレクトされていること。Googleは旧サイトの正規ページにも301を使うことを勧めており、ツールはリクエストを受け付ける前に、いくつかのページで301を確認します。

手順自体は短いものです。旧プロパティを開き、設定 → アドレス変更に進み、新しいサイトの選択で新しいプロパティを選び、検証して更新をクリックします。ツールは移行前のチェックを実行します。重大なチェックに失敗した場合は、修正しないと先に進めませんが、重大ではないチェックに失敗した場合は警告が表示されるだけで、リクエストは通ります。受け付けられると、両方のプロパティに、移行が180日間進行中であることを示す通知が表示されます。確認済みの旧ドメインのバリエーションごとに、リクエストを繰り返してください。ツールが移行するのは指定したプロパティのすべてのプロトコルですが、その下にあるサブドメインは、wwwも含めて対象外だからです。

同じ手順の簡潔版は、FAQのアドレス変更ツールの使い方にあります。

アドレス変更ツールが行うことと、カバーしないこと

Googleによると、アドレス変更は、リクエストから180日間、旧サイトより新サイトを優先してクロールおよびインデックス登録するようGoogleに伝え、旧サイトのシグナルを新サイトに引き継ぎ、正規ページを選ぶ際にも新サイトを優先させます。リダイレクトの作業を何も代替するものではなく、明確な限界もあります。

気が変わった場合は、180日以内であればリクエストを取り消せます。旧から新へのリダイレクトを外し、新サイトから旧サイトへ戻すリダイレクトを追加して、旧プロパティのアドレス変更ツールでCancel Moveをクリックします。

旧URLと新URLのサイトマップ

公開日に、新URLを載せたサイトマップを新しいプロパティに送信します。Googleのガイドでは、旧URLを載せた2つ目のサイトマップを、目安として送信することも提案しています。最初は新しいサイトマップのインデックス登録済みページは0で、旧サイトマップには多くあります。時間がたつと旧サイトマップのインデックス数が0に近づき、新サイトマップの数が増えていきます。Search Consoleは旧サイトマップのURLがリダイレクトされるという警告を出しますが、Googleは「これは正常で、これらの警告は無視してかまわない」としています。サイトマップには最終的なURLだけを載せるという通常のルールの、唯一の例外であり（リダイレクト付きのページを参照）、一時的なものです。旧サイトマップのインデックス数がほぼ0になったら削除し、新しいものだけを残してください。

リダイレクトは長く維持してください。サイト移行ガイドでは、すべてのシグナルが移るように「通常は少なくとも1年」とされており、ユーザーのためには無期限に残すことも提案されています。アドレス変更のページでは最低180日とし、旧URLがGoogle検索から引き続きトラフィックを得ているならそれより長くすることを求めています。また、ほかの誰かが買って悪用できないよう、旧ドメインの費用を少なくとも1年は払い続けることも勧めています。

移行の後：Search Consoleで週ごとに確認すること

Googleの監視に関するアドバイスは、1つのパターンに集約されます。「理想的には、旧サイトのトラフィックが減り、新サイトのトラフィックが増える」。以下のスケジュールは、私がこれらの確認を最初の数か月に振り分ける方法です。タイミングは私の実務上のやり方であり、Googleのものではありません。Googleが述べているのは、小規模から中規模のサイトでは「ほとんどのページの移行には数週間かかることがある」こと、そして大規模なサイトではURLの数とサーバーの速度によってさらに時間がかかることだけです。

旧サイトと新サイトのインデックス登録。ページのインデックス登録レポート（Googleのガイドではいまも「カバレッジ」と呼ばれています）では、旧プロパティのインデックス登録数が減り、新プロパティで増えていくはずです。旧プロパティで出てくるはずのステータスはリダイレクト付きのページで、Googleはこれを「別のページにリダイレクトする非正規URL」と定義し、そのようなURLは「インデックスに登録されない」一方、転送先は「インデックスに登録される場合もされない場合もある」と補足しています。このステータスは移行が機能している証拠であり、不具合ではありません。対処が必要なのは、リダイレクトエラーと、新サイトで見つかりませんでした（404）のURLが異常に多い場合です。リダイレクトエラーとは、Googleによれば、チェーンが長すぎる、リダイレクトのループ、リダイレクト先URLが最大長を超えている、チェーン内のURLが不正または空である、といったケースです。404が多いのは、たいていリダイレクトが存在しないページを指していることを意味します。個別のURLについては、URL検査ツールで、Googleがリダイレクトを認識したかどうかと、どのcanonicalを選んだかを確認できます。そのほかのステータスについては、テクニカルなインデックス登録のプレイブックで解説しています。

プロパティ間でのトラフィックの移動。Search Consoleは2つのプロパティを別々に扱うため、パフォーマンスレポートでは移行が1本の線として表示されることはありません。旧プロパティはクリックを失い、新プロパティはクリックを得るので、合計が維持されているかどうかは、日ごとに自分で足し合わせて確認します。公開の前後で期間の長さがそろうことはまれなので、期間単位ではなく日単位で比較し、Search Consoleがまだ数字を埋めている直近の2〜3日は除外してください。公開から1か月たっても旧プロパティが多くの表示回数を集めているなら、リダイレクトが足りないか、GoogleがそれらのURLをまだ再クロールしていません。新プロパティのアドレス変更の通知にも「ほかのサイトがこのサイトに移行している」と表示され、Googleは旧サイトからユーザーがリダイレクトされるにつれてトラフィックが増えると説明しています。

サーバーの負荷。Googleは、移行後は新サイトを「通常より多く」クロールすると警告しています。旧サイトへのクロールがリダイレクトされ、それが通常のクロールに加わるからです。設定にあるクロール統計レポートでその負荷が確認でき、そこでサーバーエラーが増えているなら、新しいホストにはより多くの処理能力が必要です。

GSC Wizardでできること：移行の比較

Search Consoleは各プロパティを別々に表示しますが、そのせいで移行の成否を判断しにくくなります。GSC Wizardの移行の比較レポートは、旧環境（公開日より前のA側）と新環境（公開日より後のB側）を1つの分析にまとめます。プロパティの左メニューとメインメニューのサイト分析の下にあり、3種類の移行に対応しています。ドメインの移行や2つのプロパティ間のHTTPS切り替えにはProperty vs property、1つのプロパティ内でのフォルダの移行にはURL prefixes、新しいURL構造にはRegex patternsです。Run analysisをクリックするまでは、何も取得されません。

• 順調な移行を基準にした判定。公開日を指定すると、Migration healthバナーに、回復率（公開前の旧側のクリック数に対する、新側の1日あたりのクリック数の割合）、想定ステージに対するペース、勢い、0〜100のリスクスコア、URLの成功率が表示され、ステータスはHealthy、Recovering、At risk、Critical、Insufficient dataのいずれかになります。想定ステージは、私がレポートに組み込んだ経験則で、日数56で旧クリック数の60%、日数180で90%といったものです。あらゆるサイトに当てはまる保証ではありません。すべての数字の意味は、ヘルス、回復、リスクのページで解説しています。
• URLマップを、稼働中のサーバーで検証する。旧URLから新URLへのマップをCSVでアップロードし（1ファイル最大10,000行、1回の分析で最大50,000行）、Verify redirectsをクリックします。GSC Wizardは各旧URLにリクエストを送り、最大5回の転送をたどり、robots.txtを尊重して、すべてのマッピングに1つの判定を付けます。Migrated、Redirect chain、Temporary redirect、Wrong target、Not redirected、Broken target、Old URL broken、Redirect loop、Kept、Unknownのいずれかです。ホームページへのリダイレクト、noindexのリダイレクト先、まだ旧サイトを指しているcanonicalにもフラグを立てます。リダイレクトマップと検証を参照してください。
• Googleから見た移行。Inspect in Googleボタンは、上位20〜200組の旧URLと新URLのペアにURL検査を実行し、各ペアをRedirect not seen yetからCanonical movedまでの引き継ぎステージに分類します。
• トラフィックの行き先。ページ、クエリ、URLセクション、国、デバイス、検索タイプを移行の前後で比較できるほか、公開時のチェックリストと、影響するクリック数の多い順に並べた最大12件の提案が表示されます。ドメインが変わって旧URLが表示回数を集め続けている場合、その提案の1つが、Search Consoleでのアドレス変更の申請です。
• 公開後のアラート。移行を保存してAlertsをオンにすると、毎日の再チェックでリダイレクトが再度検証され、新しいリダイレクトの問題が出たとき、または回復が止まったり下がったりしたときに、Slack、Microsoft Teams、Webhookに通知されます。保存、共有、アラートを参照してください。

移行の比較はすべてのプランに含まれ、すべてのプランに7日間の無料トライアルがあります（料金を参照）。準備段階のベンチマークの問題にも役立ちます。GSC Wizardに保存されたプロパティは、Search Consoleの16か月ではなく最長10年分の履歴を保持するので、Googleが破棄したあとも、旧ドメインの公開前の期間が残っています。

AIアシスタントに移行について質問する

GSC WizardをClaude、ChatGPT、その他のMCPクライアントに接続すると、同じ分析をツールとして使えるので、アシスタントは推測ではなく、実測データをもとに答えます。

MCPツールは、アプリが保存したリダイレクトのチェック結果を読み取ります。新しいチェックは自分では実行しないので、先にアプリでVerify redirectsをクリックしてください。すべてのツールはMCPドキュメントに一覧があります。

List my saved migrations, then run a health check on the shop
replatform. Tell me which three fixes matter most, with the clicks
at stake for each, and state the go-live date and both windows.

よくある質問

Search Consoleでウェブサイトを新しいURLに移行するには、どうすればよいですか？

Search Consoleで、旧サイトと新サイトを、使っているすべてのバリエーションを含めてプロパティとして確認し、すべての旧URLを、対応する新URLにサーバー側の恒久的なリダイレクト（301または308）で転送します。新しいプロパティに新URLのサイトマップを送信します。ドメインまたはサブドメインが変わる場合は、旧プロパティの設定でアドレス変更ツールを開き、新しいサイトを選んで、検証と更新を実行します。そのあと両方のプロパティを見守ります。インデックス登録とトラフィックは旧プロパティで減り、新プロパティで増えるはずです。

HTTPからHTTPSへの移行に、アドレス変更ツールは必要ですか？

いいえ。Googleのヘルプページでは、httpからhttpsへの移行にこのツールを使わないよう案内しています。サイト移行ガイドに従えば、Googleが変更を自分で判断します。このツールは、同じドメイン内でのwwwありからなしへの変更、1つのサイト内でのパスの移動、URLが変わらないホスティングやCDNの変更にも使えません。

アドレス変更でサブフォルダを移行できますか？

移行元としてはできません。このツールが使えるのは、example.com、m.example.com、http://example.comのようなドメインレベルのプロパティだけで、Googleはhttp://example.com/petstore/のようなパスレベルのプロパティは移行できないとしています。逆方向は可能で、example.comからexample3.com/new/location/のように、ドメイン全体を別のドメインのパスに移せます。1つのサイト内でのフォルダの移行に必要なのは、リダイレクトとサイトマップの更新だけです。

サイト移行がSearch Consoleに反映されるまで、どのくらいかかりますか？

Googleのサイト移行ガイドによると、小規模から中規模のウェブサイトでは、ほとんどのページの移行に数週間かかり、大規模なサイトではURLの数とサーバーの速度によってさらに長くなります。移行はURLごとに進み、Googlebotがすべての旧URLと新URLを少なくとも1回訪れたときに完了します。アドレス変更のリクエストは180日間有効です。

サイト移行のあと、301リダイレクトはどのくらい維持すべきですか？

Googleのサイト移行ガイドでは、すべてのシグナルが移るように、一般に少なくとも1年とされており、ユーザーのために無期限に残すことも提案されています。アドレス変更のヘルプページでは最低180日とし、旧URLがGoogle検索から引き続きトラフィックを得ているならそれより長くするよう求めています。また、ほかの誰かが買って悪用できないよう、旧ドメインの費用を少なくとも1年は払い続けることも勧めています。

ドメイン移行のあと、旧サイトマップは残すべきですか？

しばらくは、計測ツールとして残します。Googleは、新しいサイトマップと並べて旧URLのサイトマップを送信することを勧めています。そうすれば、旧サイトマップのインデックス登録数が0に向かって減り、新しい方が増えていくのを確認できます。旧サイトマップに出るリダイレクトの警告は正常だともGoogleは述べています。旧サイトマップの数が0に近づいたら削除し、新URLのサイトマップだけを残してください。

移行したのに、旧サイトがまだGoogleに表示されるのはなぜですか？

移行はURLごとに進み、旧URLが消えるのは、Googlebotが再クロールしてリダイレクトを確認したあとだからです。Googleは、アドレス変更ツールが旧サイトをインデックスから消すわけではないこと、また、新サイトに対応するページがない旧URLは表示され続けることがあるとも述べています。新しいページのリダイレクトと自己参照のcanonicalタグによって、表示される旧URLは減ります。

GSC Wizardでアドレス変更を代わりに申請できますか？

いいえ。アドレス変更は、Search Consoleで手動で申請します。GSC Wizardが行うのは移行の計測です。移行の比較（Migration Compare）レポートは、公開日の前後で旧プロパティと新プロパティを読み取り、リダイレクトマップにあるすべてのリダイレクトを本番サーバーで確認し、回復度とリスクをスコア化します。リダイレクトが壊れたときや回復が止まったときには、Slack、Microsoft Teams、Webhookで通知することもできます。

次のプレイブック

移行が落ち着いたら、完全には回復しなかったページや、Googleが今もインデックス登録に苦労しているページを探しましょう：技術的なインデックス登録の問題を修正する →