Search Consoleのアドレス変更で「ページを取得できませんでした」と出た時の対処法

Search Consoleの「アドレス変更」ツールで、旧サイトから新サイトへの移転を設定しようとしたときに、認証エラー「ページを取得できませんでした」「ホームページからの301リダイレクト」に失敗した、というエラーが出ることがあります。
ブラウザでは新しいサイトへ転送されているように見えるし、他のツールなどで確認しても301リダイレクトは返っている。それなのに、Search Consoleの確認だけが通らない。
今回の記事では、実際に対応したケースをもとに、確認したポイントと解決につながった対処法を整理します。
結論から言うと、今回のケースでは、サーバー側のHTTPS強制リダイレクトと、Google Search ConsoleのHTML認証ファイルまで新サイトへリダイレクトされていたことが、確認エラーの原因になっていた可能性が高いと考えています。
Search Consoleのアドレス変更ツールで出たエラー

Google Search Consoleには、サイトのドメインを変更したときに、旧サイトから新サイトへの移転をGoogleに伝える「アドレス変更」ツールがあります。
Googleの公式ヘルプでは、アドレス変更ツールを実行する前提として、旧サイトと新サイトの所有権確認、旧サイトから新サイトへの301リダイレクトなどが必要と説明されています。詳しくは、Google公式のアドレス変更ツールのヘルプも確認してください。
今回表示された主なエラーは、以下のような内容でした。

表示されたエラー
- ホームページからの301リダイレクトに失敗
- サンプルページからの301リダイレクトに警告
- 「ページを取得できませんでした」と表示
- 所有権確認は通っているのに、リクエストを続行できない
厄介だったのは、ブラウザで旧URLを開くと新サイトへ転送されているように見え、コマンドで確認しても301リダイレクト自体は返っていたことです。
まず確認したのは、旧URLが本当に301になっているか
ブラウザでページが切り替わるだけでは、301リダイレクトなのか、302なのか、JavaScriptによる移動なのか、途中で別のURLを経由しているのかが分かりません。
そのため、まずはWindowsのコマンドプロンプトで、curlを使ってリダイレクトの流れを確認しました。
curl -I -L https://old.example.com/
正常な場合は、次のように旧URLが301を返し、その後、新URLが200 OKを返します。
HTTP/1.1 301 Moved Permanently
location: https://new.example.com/
HTTP/1.1 200 OK
また、http版とhttps版の両方を確認しました。
curl -I -L http://old.example.com/
curl -I -L https://old.example.com/
Search Consoleのアドレス変更ツールは、旧サイトのホームページだけでなく、サイト内のいくつかのページでも301リダイレクトを確認します。トップページだけでなく、Search Consoleに表示されたサンプルURLや、検索流入の多い代表的な記事URLも確認しておくと安心です。
原因1:cPanelのHTTPS強制リダイレクトで2段階になっていた
最初に見つかった問題は、cPanel側の「HTTPSリダイレクトを強制する」がオンになっていたことです。
この設定が有効な状態では、http版の旧URLが一度、旧ドメインのhttps版へ転送され、その後、新ドメインへ転送されていました。
以前のリダイレクト状態
old.example.com(http) ↓ 301 old.example.com(https) ↓ 301 new.example.com ↓ 200 OK
最終的には新サイトへ到達しているものの、Search Consoleのアドレス変更確認では、旧ホームページから新ホームページへの301をできるだけ素直に見せた方がよいと考えました。
そこで、旧ドメイン側のcPanelで「HTTPSリダイレクトを強制する」をオフにし、http版からも直接、新ドメインへ301されるようにしました。
修正後のリダイレクト状態
old.example.com(http) ↓ 301 new.example.com ↓ 200 OK

Googleのサイト移転ガイドでも、リダイレクトチェーンはできるだけ避け、可能な限り最終的な移転先へ直接リダイレクトすることが推奨されています。詳しくはGoogle公式のサイト移転ガイドも参考になります。
原因2:Google認証ファイルまで新サイトへリダイレクトされていた
もう1つ大きかったのが、Search ConsoleのHTML認証ファイルまで新サイトへリダイレクトされていたことです。
Search Consoleでは、HTMLファイル、HTMLタグ、Google Analytics、Googleタグマネージャー、DNSレコードなど、複数の所有権確認方法があります。
今回、新サイト側に設置していたHTML認証ファイルに、旧ドメインからアクセスすると、次のように新サイト側の認証ファイルへ転送されていました。
認証ファイルまで転送されていた状態
old.example.com / googlexxxx.html ↓ 301 new.example.com / googlexxxx.html ↓ 200 OK
つまり、旧サイトにはその認証ファイルが存在しないのに、リダイレクト先の新サイト側にある認証ファイルで200 OKになっていたという状態です。
この状態だと、所有権確認の経路が旧サイトと新サイトで混ざっているように見えます。Google公式が「この状態だと必ずアドレス変更に失敗する」と明記しているわけではありませんが、今回のケースでは、ここを切り分けたことで最終的にアドレス変更ツールが通りました。
Google認証ファイルだけリダイレクト除外にした
対応として、google*.html の認証ファイルだけは新サイトへリダイレクトしないようにしました。Search ConsoleのHTMLファイル認証では、通常 googlexxxxxxxxxxxx.html のようなファイル名が発行されます。この部分は、自分のSearch Consoleで発行された認証ファイル名に合わせて確認してください。
このコードの google*.html は何を意味する?
google*.htmlは、Search ConsoleのHTMLファイル認証で発行されるgoogleから始まる認証ファイルをまとめて指す書き方です。- 例:
googleabc123.html、googled5cc714833bd685d.htmlなど。 - 下の正規表現
^/google[a-zA-Z0-9_-]+\.html$は、「ルート直下にある、googleで始まり.htmlで終わるファイル」をリダイレクト除外する意味です。 - 特定の認証ファイルだけを除外したい場合は、自分の認証ファイル名を直接指定しても構いません。
<IfModule mod_rewrite.c>
RewriteEngine On
# Google Search Console の所有権確認ファイルはリダイレクトしない
RewriteCond %{REQUEST_URI} ^/google[a-zA-Z0-9_-]+\.html$ [NC]
RewriteRule ^ - [L]
# 通常ページは旧ドメインから新ドメインへ301
RewriteCond %{HTTP_HOST} ^(www\.)?old\.example\.com$ [NC]
RewriteRule ^(.*)$ https://new.example.com/$1 [R=301,L,NE]
</IfModule>
この設定後、旧ドメイン側の認証ファイルURLは、新サイトへ飛ばなくなりました。旧サイトにファイルがなければ404になり、旧サイト専用の認証ファイルを置けば旧サイト側で直接200 OKになります。
除外後の認証ファイルの状態
old.example.com / googlexxxx.html ↓ 404 Not Found または old.example.com / googlexxxx.html ↓ 200 OK ※新サイトへはリダイレクトしない
HTML認証ファイルをリダイレクト除外する場合でも、通常ページの301リダイレクトは維持します。サイト移転中に旧トップページや旧記事の301を止めてしまうと、移転シグナルが弱くなる可能性があるため注意してください。
.htaccessは「除外 → 個別転送 → 全体転送」の順にする
.htaccessで旧ドメインから新ドメインへ301リダイレクトを設定する場合、順番も重要です。
先にすべてのURLを新ドメインへ転送してしまうと、その下に書いた個別リダイレクトや除外ルールが効きにくくなります。基本的には、次の順番で書くと整理しやすくなります。
.htaccessの基本的な順番
- Google認証ファイルなど、リダイレクトしたくないURLを除外する
- 旧スラッグから新スラッグへの個別301を書く
- 最後に、その他すべての旧URLを新ドメインの同じパスへ301する
- WordPress本体の
# BEGIN WordPressより上に書く
たとえば、次のような形です。
<IfModule mod_rewrite.c>
RewriteEngine On
# 1. Google Search Console の所有権確認ファイルはリダイレクトしない
# googleから始まり、.htmlで終わる認証ファイルをまとめて除外する
RewriteCond %{REQUEST_URI} ^/google[a-zA-Z0-9_-]+\.html$ [NC]
RewriteRule ^ - [L]
# 特定の認証ファイルだけを除外したい場合は、上の2行の代わりに次のように書いてもOK
# RewriteCond %{REQUEST_URI} ^/googleabc123.html$ [NC]
# RewriteRule ^ - [L]
# 2. 個別リダイレクト:旧スラッグから新しい対応ページへ
RewriteCond %{HTTP_HOST} ^(www\.)?old\.example\.com$ [NC]
RewriteRule ^old-page/?$ https://new.example.com/new-page [R=301,L,NE]
# 3. 上記以外は、同じパスのまま新ドメインへ301
RewriteCond %{HTTP_HOST} ^(www\.)?old\.example\.com$ [NC]
RewriteRule ^(.*)$ https://new.example.com/$1 [R=301,L,NE]
</IfModule>
.htaccessはサイト表示に関わる重要なファイルです。編集前には必ずバックアップを取り、1つ変更したら必ず表示確認とリダイレクト確認を行ってください。
最終的に確認した理想的な状態
最終的には、通常ページとGoogle認証ファイルで、次のように挙動を分けました。

確認できた状態
- 通常ページは旧URLから新URLへ301される
- 新URLは200 OKで表示される
- http版も旧httpsを経由せず、新ドメインへ直接301される
- Search Consoleに表示されたサンプルページも301→200になる
- Google認証ファイルは新サイトへリダイレクトしない
この状態でSearch Consoleのアドレス変更ツールを再実行したところ、「このサイトは現在移行中です」と表示され、アドレス変更の設定が通りました。
確認に使ったcurlコマンド一覧
同じようなエラーが出ている場合は、以下のように確認すると原因を切り分けやすくなります。
旧トップページのhttps版を確認する
curl -I -L https://old.example.com/
旧URLが301を返し、新URLが200 OKになっているか確認します。
旧トップページのhttp版を確認する
curl -I -L http://old.example.com/
http版が一度旧httpsを経由していないか、直接新ドメインへ301されているかを確認します。
サンプルページを確認する
curl -I -L https://old.example.com/sample-page
Search Consoleに表示されたサンプルURLや、検索流入が多い旧記事URLを確認します。転送先が404になっている場合は、正しい新URLへ個別301を追加します。
Google認証ファイルの挙動を確認する
curl -I -L https://old.example.com/googlexxxx.html
旧ドメインの認証ファイルURLが、新ドメイン側の認証ファイルへ301されていないか確認します。通常ページとは違い、認証ファイルは旧サイト側で直接確認できる状態、または旧サイト側で404になる状態に切り分けると判断しやすくなります。
順位が落ちているときほど、設定を何度も変えすぎない
ドメイン変更を伴うサイト移転では、正常に301リダイレクトを設定していても、一時的に順位や表示回数が大きく揺れることがあります。
Googleのサイト移転ガイドでも、移転中は検索結果での見え方が一時的に変動することがあると説明されています。また、301リダイレクトはできるだけ長く、一般的には少なくとも1年維持することが推奨されています。
順位が落ちていると焦って、.htaccessや認証方法を何度も変えたくなります。しかし、リダイレクトや所有権確認の状態が頻繁に変わると、原因の切り分けが難しくなります。
移転後に確認したいこと
- 旧URLから新URLへの301リダイレクトを維持する
- 新サイトのcanonicalが新URLになっているか確認する
- 新サイト内の内部リンクを新ドメインへ置き換える
- 新サイトのサイトマップを送信する
- Search Consoleで旧サイトと新サイトのパフォーマンスを見比べる
よくある質問
301リダイレクトできているのに、Search Consoleでエラーになることはありますか?
あります。ブラウザで新サイトへ転送されているように見えても、http版が旧httpsを経由していたり、サンプルページの転送先が404になっていたり、認証ファイルまで新サイトへ転送されていたりする場合があります。curl -I -Lで実際の流れを確認すると切り分けしやすくなります。
Google認証ファイルは必ずリダイレクト除外した方がいいですか?
すべてのケースで必須とは言い切れません。ただ、今回のように旧サイトの認証ファイルURLが新サイト側の認証ファイルへ転送され、所有権確認の経路が混ざっているように見える場合は、google*.htmlをリダイレクト除外すると切り分けしやすくなります。
DNS認証を使えば解決しますか?
DNS認証は、.htaccessやWordPressのリダイレクトに左右されないため、所有権確認を安定させる方法として有効です。ただし、アドレス変更ツールでは所有権確認だけでなく、旧URLから新URLへの301もチェックされるため、DNS認証だけで301エラーが必ず解決するわけではありません。
旧サイトの管理画面はリダイレクト除外した方がいいですか?
Search Consoleのアドレス変更を通す目的だけなら、管理画面の除外は必須ではありません。旧サイトのWordPress管理画面に入りたい場合だけ、wp-login.phpやwp-adminを必要に応じて除外します。移転専用の旧サイトで管理画面を使わない場合は、無理に除外しなくても構いません。
旧ドメインのプロパティは削除してもいいですか?
移転作業中は、旧プロパティを削除しない方が安全です。アドレス変更ツール、URL検査、旧URLの状態確認に使うためです。プロパティ削除は検索インデックスを消す操作ではありませんが、移転中は確認できる状態で残しておくことをおすすめします。
301リダイレクトはどれくらい維持すればいいですか?
Googleのサイト移転ガイドでは、リダイレクトはできるだけ長く、一般的には少なくとも1年維持することが推奨されています。旧URLへのアクセスや外部リンクが残ることもあるため、可能であれば長期間維持するのが安全です。
まとめ:301だけでなく、認証ファイルの経路も確認する
Search Consoleのアドレス変更で「ページを取得できませんでした」と出たときは、単に「301リダイレクトを設定したか」だけでなく、実際にGoogleが見に行くURLの流れを確認することが大切です。
今回のケースでは、旧トップや個別ページの301はできていましたが、cPanel側のHTTPS強制リダイレクトでhttp版が旧httpsを経由していたこと、さらにGoogle認証ファイルまで新サイト側へリダイレクトされていたことが、確認エラーに関係していた可能性がありました。
最終的には、通常ページは旧URLから新URLへ301、Google認証ファイルはリダイレクト除外、という形に整理したことで、Search Consoleのアドレス変更ツールを通すことができました。
Support
サーバー移転・ドメイン変更後の設定でお困りの方へ
ドメイン変更、301リダイレクト、Search Consoleのアドレス変更、SSL設定、DNS設定は、1つの設定違いで検索評価や表示に影響することがあります。キャピタルウェブサービス株式会社では、WordPressサイトのサーバー移転・ドメイン移管・Search Consoleまわりの確認もサポートしています。
- 旧サイトから新サイトへの301リダイレクト確認
- Search Consoleのアドレス変更・URL検査の確認
- サーバー移転後のSSL・DNS・canonical確認
- WordPressサイトの移転後チェック

