Search Console「リダイレクトエラー」の原因特定と1回転送への直し方

ページインデックス登録レポートに、赤い「リダイレクトエラー」が数十件。ブラウザで開くと、ちゃんと新しいページに着く。なのにGoogleはエラーだと言う。——この食い違いは、ブラウザが黙って追いかけてしまう転送の「積み重なり」や「行き止まり」を、人の目では見ていないことから起きがちです。

先に答えを書きます。Search Console のヘルプは「リダイレクトエラー」の原因として、転送のチェーン（数珠つなぎ）が長すぎる、ループしている、転送先URLが最大長を超えた、チェーンの中に不正または空のURLがある、の4つを挙げています。

ブラウザは何回転送されても黙って追いかけます。だから人の目には正常に見えます。

やることは1つです。エラーになったURLの転送履歴を1ホップずつ実測し、元のURLから最終URLへ直接飛ぶ1回の転送に書き換える。この記事はその実測と書き換えの手順です。

「リダイレクトエラー」と「ページにリダイレクトがあります」は別物

まず混同を解きます。同じレポートに、似た名前の項目が2つあります。

「ページにリダイレクトがあります」は、転送元URLが登録されなかったという記録です。ヘルプには、リダイレクトするURLは登録されず転送先だけが登録される、と書かれています。転送先が登録されていれば、これは正常な状態です（詳しくは「ページにリダイレクトがあります」放置か修正かの判別で扱っています）。

一方の「リダイレクトエラー」は、転送の途中に長すぎるチェーンやループといった問題があった記録です。転送が正しく完了しない以上、そのURL経由で転送先に評価を寄せることは期待しにくくなります。こちらは放置しないほうがよい項目です。

つまり、赤いほうだけを見ればいい。件数が少なくても、1件ずつ潰す価値があります。

4つの原因を、症状から見分ける

ヘルプが挙げる4原因を、実際に転送を追ったときの見え方に置き換えると次のようになります。

一つめのチェーンは、悪気なく積み上がります。https 化のとき1本、www 統一のとき1本、URL変更のとき1本。それぞれの転送は正しいのに、重なると1本の長い列になる。

二つめのループは、設定の食い違いです。片方が「末尾スラッシュを付けろ」、もう片方が「外せ」と言えば永久に往復します。

三つめと四つめは頻度こそ低いものの、見つけにくい。転送のたびにURLが少しずつ変わっていくので、1ホップ目だけ見ても気づけません。だから、最後まで追う必要があります。

curl で1ホップずつ追う（ワークスルー）

エラー一覧からURLを1つ取り、ターミナルで転送を追います。ブラウザの開発者ツールでもできますが、curl のほうが1ホップごとの状態が崩れず読めます。

-I はヘッダだけ取得、-L は転送を追う、--max-redirs は追う上限です。上限を付けておくとループでも止まります。

curl -sIL --max-redirs 15 -A "Mozilla/5.0" "http://example.com/old-page" | grep -Ei "^(HTTP|location)"

たとえば旧URL http://example.com/old-page を追った結果が、こう返ってきたとします。

HTTP/1.1 301 Moved Permanently
location: https://example.com/old-page
HTTP/2 301
location: https://www.example.com/old-page
HTTP/2 301
location: https://www.example.com/old-page/
HTTP/2 302
location: https://www.example.com/new-page/
HTTP/2 200

4回転送して、やっと 200 です。内訳は、https 化・www 統一・末尾スラッシュ・旧→新の4本。どれも単体では正しい。でも Google 検索セントラルは、サーバー側の恒久的な転送（301/308）を推奨したうえで、転送のチェーンは避けるよう書いています。この4段はまさに避けるべき形です。

さらに、最後の1本だけが 302（一時的）になっています。旧ページから新ページへ恒久的に移したのなら、ここは 301 か 308 に揃えます（使い分けは301と302の違いにまとめています）。

もし出力が同じ2つのURLを往復し続け、--max-redirs の上限で止まったら、それがループです。Location が空行だったり、location: / のような壊れたパスだったら、4つめの原因です。

ヘルプも、Lighthouse のようなウェブデバッグツールで転送の詳細を確認するよう案内しています。curl で全体像をつかみ、Lighthouse で個別ページを見る、という順で使うと迷いません。

1回の転送に書き換える手順

原因が分かったら、書き換えます。目標は「元URL → 最終URL」の直行便です。

1. 最終URLを1つ確定する。 さきほどの例なら https://www.example.com/new-page/。プロトコル・ホスト名・末尾スラッシュまで含めて、サイト全体で1つの形に決めます。
2. 転送ルールの置き場所を棚卸しする。 サーバー設定（Apache の .htaccess、nginx の server ブロック）、CMS本体、転送プラグイン、CDN やロードバランサ。同じ意味の転送が2か所以上に書かれていないかを見ます。ループの多くはここで見つかります。
3. 旧URLの転送先を、中継ではなく最終URLに書き換える。 old-page → https://example.com/old-page ではなく、old-page → https://www.example.com/new-page/ へ。中継役だった https 化や www 統一のルールは、まだ他のURLで使うので消さなくて構いません。順番だけ、個別ルールが先に評価されるように置きます。
4. ステータスを 301 か 308 に揃える。 恒久的な移動なら 302/307 は使いません。移行の案内でも、可能な限りサーバー側の恒久的な転送を使うよう書かれています。
5. もう一度 curl で追い、1回で 200 に着くことを確認する。 ここで HTTP/1.1 301 → HTTP/2 200 の2行になれば完了です。
6. サイト内のリンクとサイトマップを最終URLに直す。 転送を経由するリンクを残すと、また列が伸びる元になります。
7. Search Console の URL 検査で公開URLをテストし、レポートで「修正を検証」を押す。 URL検査ツールでは、対象URLを入力して現在の状態を確認できます。検証は時間がかかることがあるので、押した直後に数字が動かなくても待ちます。

3の「中継ルールは消さない」が引っかかりやすい所です。消してしまうと、まだ古い http のリンクを持つ別のページが転送されなくなります。**個別の直行便を足す。共通ルールは残す。**この順です。

見落としやすい2つ

Googlebot にだけループする。 ブラウザでは正常、curl でも正常、なのにエラーが消えない場合、ユーザーエージェントや地域で転送先を変えるルールを疑います。言語振り分けやボット判定の設定が、特定の条件でだけ逆方向を指すことがあります。curl の -A を変えて同じURLを追い、結果が変わるかを見ます。

古い転送を「整理」して外してしまう。 サイト移行の案内では、転送はできるだけ長く、一般に少なくとも1年は残すよう書かれています。チェーンを短くしたいからといって旧URLの転送自体を消すと、外部リンクからの訪問が行き場を失います。短くするのは「段数」であって「本数」ではありません。

直したあとの自己点検

• エラー一覧のURLを curl で追って、301（または 308）が1行、200 が1行の合計2行になっているか。
• 同じURLに対して、-A を Googlebot 風・スマホ風に変えても結果が変わらないか。
• 転送ルールが2か所以上に同じ意味で書かれていないか（サーバー設定・CMS・プラグイン・CDN）。
• サイト内リンク・サイトマップ・canonical の指定先が、転送を経由しない最終URLになっているか。
• 旧URLからの転送は残っているか（段数を減らしただけで、本数は減らしていないか）。
• Search Console で「修正を検証」を押したか。

チェーンは、ひとつひとつの判断が正しくても積み上がります。だから定期的に、代表的な旧URLを数本 curl で追ってみる習慣を持っておくと、赤いエラーになる前に列が伸びていることに気づけます。URLの大きな変更を控えているなら、URL変更を伴うサイト移行のリダイレクト設計も先に目を通しておくと、列を最初から作らずに済みます。