サーチコンソールでのURL変更を失敗なく安全に行う方法

2025 11/04

2025/11/04

はじめに

この文書は、Googleサーチコンソールを使ってウェブサイトのURLを変更する際の手順と注意点をわかりやすくまとめたガイドです。主にドメインの移転やサイトアドレスの変更（例：http→https、サブドメインの変更、完全なドメイン移行）を対象としています。

対象読者

サイト運営者や制作者、SEO担当の方。技術的な作業に慣れていない方でも読み進めやすいよう配慮しています。

この章でわかること

本書の目的と構成。以降の章で「アドレス変更ツールの使い方」「事前準備」「操作手順」「移転後のフォロー」「SEOへの影響」「よくあるトラブルと対策」を順に解説します。

準備しておくと良いもの

サーチコンソールの所有権（旧サイト・新サイト）
サイトのバックアップ
旧URLから新URLへの恒久的転送（一般に「301リダイレクト」と呼ばれます）を設定できる環境

読み方のアドバイス

まずは事前準備を整えてから、手順に沿って進めると安全です。急いで作業を始めず、各ステップで確認を行ってください。

サーチコンソールでのURL変更とは

概要

Googleサーチコンソールの「アドレス変更ツール」は、サイトのドメインやサブドメイン、プロトコル（http→https）を変更した際に、Googleへ公式に引っ越しを伝える機能です。適切に使うと、検索結果のインデックスや評価を新しいURLへスムーズに移行しやすくなります。

何を通知するのか

具体的には「旧サイトのすべてのURLが新しいサイトに移りました」とGoogleに伝えます。個別ページの移転ではなく、サイト全体の移転を前提にしています。例：example.com → www.example.com や http://example.com → https://example.com

前提条件と準備の要点

旧サイトと新サイトの両方をサーチコンソールで所有権確認していることが必須です。
旧URLから新URLへは301リダイレクトを正しく設定してください。Googleはリダイレクトを頼りに移行を確認します。

制限と注意点

個別ページの移動やURL構造を大きく変える場合は、このツールは適しません。
移行後もインデックスや評価が完全に移るまで時間がかかります。検索トラフィックが一時的に変動することを見越して準備してください。

次章では、どんなケースでこのツールを使うべきか、使えない場合はどうするかを詳しく説明します。

アドレス変更ツールを使うべきケース・使えないケース

使うべきケース

ドメインを完全に変更する場合（例：oldsite.com → newsite.com）。サイトの住所がまったく変わるとき、Search Consoleのアドレス変更ツールを使うとGoogleに移転を正式に知らせられます。
サブドメイン間での移転（例：blog.oldsite.com → blog.newsite.com）。同じ親ドメインでもプロパティが別になる場合に有効です。
大規模なサイト移行で、旧サイトのURLが新サイトに恒久的に301リダイレクトされることが確実な場合。ツールは転送設定と合わせて使うことで効果を発揮します。

使えない（不要な）ケース

HTTPからHTTPSへの移行（SSL導入）。この場合は301リダイレクトとサイト内リンクやサーチコンソールへの新プロパティ追加で対応します。
wwwあり/なしの統一（例：www.example.com ⇄ example.com）。プロパティの正規化設定と301リダイレクトで対応します。
パスやディレクトリ構造の変更（例：/old/ → /new/）。個別の301リダイレクトやcanonicalタグで対応してください。

判断のための簡単チェックリスト

新旧でドメイン部分（example.com）が変わるか？→変わるならツールを検討。2. サブドメインだけの移動か？→プロパティが別ならツールが使える。3. 単にプロトコルやパスの変更か？→ツールは不要。

注意点

ツールだけに頼らず、サイト側で必ず301リダイレクトを設定してください。検索エンジンはリダイレクトと合わせて評価します。
両方のサイトをサーチコンソールで所有権確認しておく必要があります。

URL変更時に必須の事前準備

概要

URLを変える前に必ず行う準備をまとめます。目的は旧URLから新URLへユーザーと検索エンジンを確実に誘導することです。

1. 301リダイレクトを計画・実装

・ページ単位で旧URL→新URLへ301リダイレクトを設定します。例: Apache .htaccessなら「Redirect 301 /old-page https://example.com/new-page」、Nginxなら「return 301 https://example.com$new_uri;」。
・テストはcurlやブラウザの開発者ツール、オンラインのリダイレクトチェッカーで確認します。

2. 内部リンク・画像パスの書き換え

・サイト全体で内部リンクと画像（src属性）を新URLに置換します。CMSなら検索置換プラグイン、静的サイトならビルドスクリプトで一括変更します。

3. canonicalタグ・robots.txt・sitemap.xmlの更新

・各ページのcanonicalを新URLへ書き換えます。重複防止のため重要です。
・robots.txtのDisallowやSitemap行を新しいドメイン／パスに更新します。
・sitemap.xmlのURLを新サイトのパスで生成し、アクセス可能か確認します。

4. サーチコンソールの登録と所有権確認

・新サイトのプロパティをサーチコンソールに追加し、所有権を確認します。推奨はDNSレコードでの確認ですが、HTMLファイルやメタタグでも可能です。
・新サイトのsitemapをサーチコンソールへ送信し、インデックス状況を確認します。

チェックリスト（必須）

301がページ単位で動作すること
内部リンク・画像が新URLを参照すること
canonical/robots/sitemapが新URLを反映していること
サーチコンソールで新サイトが登録・所有権確認済みであること
リダイレクト後のステータスやクロールエラーを監視すること

以上を事前に済ませると、移行後の問題を大幅に減らせます。

サーチコンソールでのアドレス変更ツールの操作手順

前提

旧サイトと新サイトの両方がサーチコンソールで同じGoogleアカウントに登録・所有権確認済みであることを確認してください。

操作手順（具体的な流れ）

旧サイトのプロパティを選び、サーチコンソールにログインします。
左下の「設定」に移動し、「アドレス変更」をクリックします。
新しいサイトのプロパティを選択し、画面の指示に従って移行先のドメインを指定します（例：oldsite.com → newsite.com）。
「検証して更新」をクリックして、サーチコンソールがリダイレクトや所有権を確認できるようにします。
検証に合格すると「移動を確認」ボタンが表示されるので、押して手続きを確定します。
操作後は「移行中」ステータスが表示され、処理が完了するとステータスが消えます。新サイト側にも移行中のメッセージが出ます。

検証に不合格だった場合の対処例

301リダイレクトが正しく設定されているか確認する（旧URL→新URLへ恒久的リダイレクト）。
新サイトの所有権が確認済みか確認する（DNSやHTMLファイルでの検証）。
robots.txtやnoindexでブロックしていないか確認する。

ワンポイント

検証はリダイレクトと所有権が揃って初めて通ります。手順を焦らず一つずつ確認してください。

URL変更後にやるべきフォローアップ

概要

URL変更後は、検索エンジンの反映やユーザー導線に問題がないかを定期的に確認します。初期は細かく、落ち着いたら間隔を伸ばして観察します。

1. サーチコンソールでの監視

カバレッジ（Coverage）とインデックスの状況を毎日確認します。新URLがインデックスされているか、旧URLにエラーが残っていないか見ます。URL検査ツールで個別チェックも行います。

2. エラーの早期発見と対応

404エラー、リダイレクトの多重（チェーン）やループを探します。見つけたら速やかに301リダイレクトを修正します。canonicalが新URLを指しているかも確認します。

3. sitemap.xmlとrobots.txt

sitemapを新ドメイン用に更新し、サーチコンソールに再送信します。robots.txtでクロールをブロックしていないかも必ず確認します。

4. リンクの整理

内部リンクを新URLに更新します。可能なら主要な外部リンク先（被リンク）にも変更依頼を出します。旧URLは一定期間リダイレクトを残します。

5. トラフィックと指標の監視

アナリティクスで流入やコンバージョンを比較します。急激な落ち込みがあれば原因を切り分け、検索順位も定期チェックします。

6. 期間とレポート

初週は毎日、1ヶ月は週次、その後は月次でレポートを作成します。問題は履歴として残し、対応状況を共有します。

注意点

旧ドメインは最低数か月は維持してください。ユーザーと検索エンジンの両方が新URLに移行するまで時間がかかります。

SEOへの影響とリスク管理

概要

URLを変えると検索エンジンの評価が一時的に変わります。適切なリダイレクトや通知がないと、検索順位の低下やインデックス遅延のリスクが高まります。リダイレクトは最低1年以上維持することを推奨します。

主な影響と原因

順位変動：古いURLの評価が新URLに完全に移るまで時間がかかります。特に被リンクが多いページは影響が大きく出ます。
インデックス遅延：クローラーが新URLを発見・評価するまで数日〜数ヶ月かかることがあります。
クローラビリティの問題：リダイレクトチェーンや誤設定でクロール効率が落ちます。

リスク管理の具体策

永続的リダイレクト（301）を使う。302は避ける。例：/old → 301 → /new
リダイレクトは直列チェーンにせず1対1で設定する。
サイト構造や本文は可能な限り変えない。URLだけを変える方が安全です。
内部リンクとサイトマップを新URLに更新する。
サーチコンソールで住所変更ツールを使い、サイトマップを再送信する。
重要な被リンク先には可能な範囲で直接更新を依頼する。
監視：検索順位、Search Consoleのカバレッジ、アクセスログを定期確認する。

運用とロールバック

まずテスト環境で小規模に実施し、問題なければ段階的に展開します。想定外の問題があれば、設定を元に戻す準備（バックアップとマッピング表）を用意してください。

大規模サイトの注意点

ページ数が多い場合は分割して移行し、サーバー負荷やクロール頻度も考慮してスケジュールを組んでください。

トラブル事例と対策

代表的なトラブル

新URLがインデックスされない：旧URLに引き続きトラフィックが集まり、新URLが評価されないことがあります。
クローリング拒否やnoindex：robots.txtやmetaタグで誤ってブロックしている場合があります。
重複判定や正規化（canonical）で新URLが無視される：旧URLが正規扱いになっている場合です。

対策（具体例付き）

1) 基本確認から着手
– Search ConsoleのURL検査で状態を確認し、クロール時のステータスや被リンク状況を見ます。
– robots.txt、meta robots、rel=canonicalをチェックします。

2) インデックス促進の実践例
– ブロック解除：robotsやnoindexがあれば除去して再取得をリクエストします。
– サイトマップ再送信：新URLを含めたサイトマップを更新し送信します。
– 一時的な柔軟運用：旧URLと新URLを別物として認識させたいときは、旧ページをしばらく残し、旧ページのrel=canonicalを外すか内容を少し変えて双方をクローラブルにします。新URLがインデックスされたら適切な301リダイレクトへ戻します。

3) 技術的な問題別対応例
– 301が正しくない：サーバ応答を確認し、正しいHTTPステータスを返すよう修正します。
– ソフト404や重複：コンテンツを改善してユニーク性を出します。