Search ConsoleでURL検査をしたときに「リダイレクト エラー」と表示されると、かなり不安になります。
記事は公開できているはずなのに、Search ConsoleではGoogle未登録。しかも「ページの取得に失敗しました」と出ると、「記事が壊れているのでは」「設定を間違えたのでは」と考えたくなります。
AIブログ実験室でも、17記事目、18記事目、19記事目を2026-05-28に再確認したところ、3記事とも Google未登録 / リダイレクト エラー になっていました。
ただし、公開ページを確認すると、読者が見るHTTPSのURLは開けます。curlでHTTPからHTTPSへの転送も確認すると、公開サーバー側では HTTPのwww URLからHTTPSのwww URLへ301転送され、その後HTTP/2 200で表示される 状態でした。
この記事では、Search Consoleの「リダイレクト エラー」が出たときに、初心者がどの順番で確認すればよいかを整理します。
結論:
Search Consoleでリダイレクト エラーが出ても、すぐに記事本文やcanonicalを直す必要があるとは限りません。まずは 「検査したURL」「公開ページのURL」「canonical」「Search Consoleプロパティ」 を分けて確認します。
初心者ブロガーSearch Consoleでリダイレクト エラーと出ました。記事そのものを直したほうがいいですか?



いきなり本文を直す前に、まずURLの種類を分けて見ます。HTTPとHTTPS、wwwありとなし、Search Consoleのプロパティが同じ前提になっているかを確認しましょう。
この記事でわかること
- Search Consoleのリダイレクト エラーで最初に見ること
- HTTP、HTTPS、www、canonicalを分けて確認する理由
- AIブログ実験室で実際に起きた17〜19記事目の事例
- 初心者がやりがちなNG対応
- 次にSearch Consoleで再確認すべき作業
Search Consoleのリダイレクト エラーは何が不安なのか
ブログを始めたばかりの時期は、Search Consoleの表示が少し変わるだけでも不安になります。
特に「URLがGoogleに登録されていません」だけでなく、「リダイレクト エラー」と出ると、記事がGoogleに読まれていないように見えます。
ただ、ここで大事なのは、Search Consoleの表示だけで原因を決めつけないこと です。
公開ページが読者に開けるのか。HTTPからHTTPSへ転送されているのか。canonicalがどのURLを指しているのか。Search Consoleで開いているプロパティがHTTPなのかHTTPSなのか。ここを分けて見る必要があります。
Search ConsoleのURL検査は、開いているプロパティ内のURLを確認するための機能です。公式ヘルプでもURL検査ツールは、特定のURLについてGoogle側の認識やインデックス登録可否を確認するための機能として案内されています。
注意:
リダイレクト エラーが出た直後に、canonicalやパーマリンクを何度も変更するのは避けたほうが安全です。原因がURL側なのか、Search Consoleプロパティ側なのかを分ける前に変えると、あとで何が効いたのかわからなくなります。
今回のAIブログ実験室で起きたこと
今回確認したのは、17記事目、18記事目、19記事目です。
| 記事 | Search Consoleの状態 | 前回クロール | 公開URL側の確認 |
|---|---|---|---|
| 17記事目 | Google未登録 / リダイレクト エラー | 2026-05-24 01:24:50 | HTTP www → HTTPS www → 200 |
| 18記事目 | Google未登録 / リダイレクト エラー | 2026-05-24 18:29:25 | HTTP www → HTTPS www → 200 |
| 19記事目 | Google未登録 / リダイレクト エラー | 2026-05-24 21:57:44 | HTTP www → HTTPS www → 200 |
Search Consoleでは、3記事ともスマートフォン用Googlebot、クロール許可は「はい」。一方で、ページの取得は「失敗しました: リダイレクト エラー」でした。
そこで公開サーバー側を確認しました。通常のアクセスでも、Googlebot smartphone UAでも、HTTPのwww URLはHTTPSのwww URLへ301転送され、その後HTTP/2 200で表示されます。
また、HTTPS本文のcanonicalは、それぞれHTTPSのwww URLを指していました。つまり、少なくとも公開サーバーの簡単な確認では、読者が見るページが完全に壊れている状態ではありません。
運営メモ:
今回の確認では、Search Consoleのプロパティ一覧までChromeで確認しようとしましたが、接続タイムアウトで未完了でした。そのため、この記事では「公開サーバー側で確認できたこと」と「Search Console側で次に確認すること」を分けて記録しています。
まず確認したい5つのポイント
リダイレクト エラーが出たときは、次の順番で見ると混乱しにくくなります。
HTTPのURLを検査しているのか、HTTPSのURLを検査しているのかを確認します。今回の確認対象はHTTPプロパティのHTTP URLでした。
読者が見るURLが200で開けるかを確認します。ここで404や下書き表示なら、まず公開状態を直します。
HTTPのURLがHTTPSへどう転送されるかを確認します。転送が何段階も続く、途中で別URLへ飛ぶ、エラーになる場合は注意が必要です。
canonicalが公開したいHTTPS URLを指しているか確認します。別記事や古いURLを指している場合は、記事側の設定確認が必要です。
HTTPプロパティで検査している場合、canonical先のHTTPS URLを直接確認できるプロパティが必要になることがあります。次回はこの確認を優先します。
HTTP、HTTPS、www、canonicalをどう見ればよいか
URLまわりで混乱しやすいのは、似たURLが複数あることです。
たとえば、同じ記事でも次のように見え方が変わります。
| 種類 | 例 | 見るポイント |
|---|---|---|
| HTTP www | http://www.example.com/article/ | HTTPSへ正しく転送されるか |
| HTTPS www | https://www.example.com/article/ | 読者が見る正式URLとして200で開くか |
| HTTP non-www | http://example.com/article/ | wwwありへ何段階で転送されるか |
| canonical | https://www.example.com/article/ | Googleに代表URLとして伝えたいURLか |
| Search Consoleプロパティ | http://www.example.com/ など | 検査したいURLがプロパティ内か |
301リダイレクトそのものは、通常は悪いものではありません。Google検索セントラルでは、恒久的な移転を示すリダイレクトとして301が扱われます。
ただし、Search Consoleでリダイレクト エラーが出ているときは、転送先、転送段数、canonical、プロパティのどこかで前提がずれている可能性を見ます。
注意:
HTTPからHTTPSへ転送されること自体を問題と決めつけない ようにします。問題にするべきなのは、転送先が想定外、何度も転送する、途中で失敗する、Search Consoleのプロパティとcanonical先が合っていない、といったケースです。
Search Consoleプロパティが原因候補になるケース
今回のAIブログ実験室では、HTTPプロパティでHTTP URLを検査していました。一方で、公開ページのcanonicalはHTTPSのwww URLです。
この状態では、Search Console上で見ているURLと、記事側が代表として示しているURLが違います。
もちろん、HTTPからHTTPSへの転送は一般的です。ただ、Search Consoleで調べたいURLがHTTPS canonicalなら、HTTPSプロパティまたはドメインプロパティで直接確認できる状態 にしておくほうが、原因を切り分けやすくなります。
AIブログ実験室での次アクション:
17〜19記事目は、公開サーバー側ではHTTP wwwからHTTPS wwwへの転送とcanonicalが正常に見えました。次はSearch ConsoleでHTTPSまたはドメインプロパティを確認し、HTTPS canonical URLを直接URL検査します。
初心者がやりがちなNG対応
リダイレクト エラーが出ると、何かをすぐ直したくなります。ただ、原因がわからないまま触ると、後から追いにくくなります。
- 同じURLで何度もインデックス登録リクエストを押す
- 記事タイトルや本文を先に大きく書き換える
- canonicalを理由なく別URLへ変える
- HTTP/HTTPSの違いを見ずに、記事が失敗したと判断する
- 確認した内容を台帳や作業ログに残さない
特に、canonicalやパーマリンクは記事の代表URLに関わる部分です。変えるなら、理由と変更前後を記録してから行います。
リダイレクト エラーが出たときのチェックリスト
実際に確認するときは、次のチェックリストを使います。
- Search Consoleで検査したURLを記録した
- 公開ページのHTTPS URLが200で開く
- HTTP URLが想定したHTTPS URLへ転送される
- wwwあり、wwwなしの転送先を確認した
- canonicalが公開したいHTTPS URLを指している
- noindexになっていない
- Search ConsoleでHTTPSまたはドメインプロパティを確認できる
- 再検査結果を台帳に残した
URL検査の基本は、Search ConsoleのURL検査とは?ブログ記事を公開した後にやることを初心者向けに解説で整理しています。
また、未登録表示が出たときの原因分けは、Search Consoleでインデックス未登録が出たときの確認手順もあわせて見ると流れをつかみやすいです。
AIブログ実験室で次にやること
今回の確認で、17〜19記事目については、公開サーバー側のHTTP→HTTPS転送とcanonicalは大きく崩れていないように見えました。
そのため、次にやることは記事本文の大幅修正ではありません。
- Search ConsoleでHTTPSまたはドメインプロパティを確認する
- 17〜19記事目のHTTPS canonical URLを直接URL検査する
- 20、22、23記事目のURL検査と再確認も進める
- 結果を `data/search_console_recheck_tasks.csv` に残す
- 必要ならSearch Console系記事からこの記事へ内部リンクを戻す
公開後の確認作業全体は、ブログ記事を公開した後にやること|初心者向け公開後チェックリストにもつながります。
よくある質問
Q. リダイレクト エラーが出たら記事は検索に出ませんか?
A. その時点では「Search Console上で取得に失敗している」と考えます。公開ページが壊れているのか、リダイレクト設定なのか、プロパティの違いなのかを分けて確認します。
Q. HTTPからHTTPSへの301は悪いことですか?
A. 悪いこととは限りません。HTTPからHTTPSへ恒久的に転送するのは一般的です。見るべきなのは、転送先が想定どおりか、途中で失敗していないかです。
Q. canonicalがHTTPSなら、HTTPプロパティで検査してもよいですか?
A. HTTPプロパティで状態を見ることはできますが、canonical先のHTTPS URLを直接確認できるプロパティがあるほうが切り分けやすいです。今回の次アクションもそこです。
Q. どのタイミングで再検査すればよいですか?
A. まず公開URL、転送、canonical、プロパティを確認します。その後、必要な修正やプロパティ確認が終わってから再検査します。原因を分ける前に何度もリクエストしないほうが記録しやすいです。
Q. 自分でcurl確認ができない場合はどうすればよいですか?
A. まずブラウザでHTTP URLとHTTPS URLをそれぞれ開き、最終的にどのURLになるかを見ます。難しい場合は、WordPressのサイトアドレス、パーマリンク、canonical表示、Search Consoleプロパティを順番に確認します。
まとめ:記事を直す前にURLの前提をそろえる
Search Consoleのリダイレクト エラーは、不安になりやすい表示です。
ただ、エラー表示を見てすぐ記事本文を直すのではなく、まずはURLの前提をそろえます。
- 検査したURLはHTTPかHTTPSか
- 公開ページはHTTPSで200表示されるか
- HTTPからHTTPSへの転送は想定どおりか
- canonicalは公開したいURLを指しているか
- Search ConsoleでHTTPSまたはドメインプロパティを確認できるか
AIブログ実験室では、17〜19記事目のリダイレクト エラーをきっかけに、この切り分けを台帳へ残しました。次はHTTPSまたはドメインプロパティでcanonical URLを直接確認し、検索側の土台を整えていきます。
あわせて読みたい
- Search ConsoleのURL検査とは?ブログ記事を公開した後にやることを初心者向けに解説
- Search Consoleでインデックス未登録が出たときの確認手順|初心者向けチェックリスト
- ブログ記事を公開した後にやること|初心者向け公開後チェックリスト
- ブログ記事をいつリライトするか|Search Console・Analytics・X反応から判断する方法
- ブログ開設から1週間でやったこと|AIブログ実験室の運用レポート








