「ページにリダイレクトがあります」放置か修正かの判別

ページインデックス登録レポートを開いたら、「ページにリダイレクトがあります」が1,842件。未登録の理由のなかで断トツに多い。エラーの赤ではないけれど、この数を見て平気でいられるほうが難しいと思います。

先に答えを書きます。この項目は、転送元のURL自体が登録されなかったという記録です。転送先のほうが登録されていれば、手を入れる必要はまず出てきません。

だから、件数の多さ自体は問題ではありません。

問題があるとすれば別のところです。転送先がそもそも登録されていない場合と、自分のサイトの中のリンクが古いURLを指したままの場合。この2つだけを拾い出せば、残りは触らなくて済みます。

Googleが「登録しない」と書いている理由

公式ヘルプの説明は短いものです。ページインデックス登録レポートの項目説明には、これは別のページにリダイレクトする非正規URLであり、そのためこのURLはインデックスに登録されない、と書かれています。リダイレクト先のURLについては、Googleがそのターゲット URLをどう捉えるかによって、登録される場合と登録されない場合がある、という続きがあります。同じドキュメントの別の箇所には、リダイレクトURLはインデックスに登録されず、リダイレクト先のみが登録される、とも明記されています。

つまり仕様どおりの動きです。

転送を設定した以上、転送元が登録されないのは設定した本人が望んだ結果でもあります。ここが「エラー」と並んで表示されるせいで身構えてしまいますが、除外の理由には、直す必要のないものが混ざっています。

もう少し踏み込むと、Googleの側では両方が記録されています。検索セントラルの「リダイレクトと Google 検索」には、URLをリダイレクトするとGoogleはリダイレクト元（元のURL）とリダイレクト先（新しいURL）の両方を記録する、と書かれています。そしてどちらか1つが正規版になり、どちらが正規版になるかは、リダイレクトが一時的か永続的かなどを示すシグナルによって決まる、と続きます。もう1つのURLは正規URLの代替名になります。

消えたのではありません。役割が変わっただけです。

この整理は正規化の考え方とつながっています。「重複した URL の統合」では、正規URLを伝える方法が効果の高い順に並べられていて、その先頭がリダイレクトです。リダイレクト先が正規ページになるべきことを強く示すシグナル、という説明が付いています。正規URLというのは、内容の重複するページのなかで代表として扱ってほしい1本のことです。

強いシグナルを自分で送った。その結果が、この除外行です。

なお、レポートの説明にはもう一つ注意書きがあります。リダイレクトのある正規URLはインデックスに登録できる、というものです。転送が絡んでいれば必ず未登録になる、という単純な話ではありません。

3ステップの判別フロー

では、1,842件のうち何を見るか。順番を決めておくと、リストを上から眺める作業になりません。

1. 転送先が登録されているかを1本確かめる。 レポートから代表的なURLを1つ開き、その転送先URLをURL検査ツールに入れます。転送元ではなく転送先です。ここが登録済みなら、その系統の転送元は放置してかまいません。確かめたいのは受け皿の側の状態なので、検査に入れるURLを取り違えないようにします。
2. 転送元URLがどこから来ているかを分ける。 自分のサイトの中のリンクから来ているのか、外部リンクや古いブックマークから来ているのか。前者だけが手を入れる対象です。外部サイトの側のリンクは書き換えられないので、転送を残し続けるのが正解になります。
3. 転送が1回で終わっているかを見る。 転送先がさらに別のURLへ転送されている状態（リダイレクトチェーン）や、AがBへ、BがAへと戻ってしまう状態（リダイレクトループ）は、ここで見つけます。1と2が問題なくても、これだけは直す対象です。

3つとも「はい」で終わったなら、その件数は記録だけして閉じて大丈夫です。

判断の材料になる確認は、ブラウザだけでも足ります。コマンドが使える環境なら、curl -sI https://example.com/old-path/ で返ってくるステータス行と location ヘッダーを見るのが早いです。301なのか302なのか、転送先が1回で目的のURLに着いているか。この2点だけ読めば足ります。

カテゴリURLを変えたサイトで通してみる

抽象的なままだと使いにくいので、よくある場面に当てはめます。商品カテゴリの階層を /category/shoes/ から /shoes/ へ変えた通販サイト、という設定です。移行後、レポートの「ページにリダイレクトがあります」が一気に増えました。

ステップ1をやります。/category/shoes/ の転送先である /shoes/ をURL検査ツールに入れると、登録済みと出ました。ここで、旧URLが未登録になっていること自体は解決済みの話になります。評価の受け皿は用意できている状態です。

ステップ2に進みます。サイト内を category/shoes で検索すると、記事本文中のリンクが47本、パンくずリストのテンプレートが1か所、ヘッダーのナビゲーションが1か所、旧URLのまま残っていました。ここが本題です。ユーザーは1回余分な転送を経てからページを見ることになりますし、サイト内の案内としても古い経路を指し続けています。新しいURLへ書き換える対象は、この49か所です。

ステップ3も見ておきます。/category/shoes/ → /shoes/ → /shoes と、末尾スラッシュの統一ルールがもう一段かかっていて、2回転送されていました。転送ルールを1つにまとめ、旧URLから最終URLへ直接1回で着くようにします。

やることが49か所の書き換えと転送ルールの整理に絞れました。1,842件を1件ずつ見る作業には、最初から入らずに済みます。

放置してよいものと、直すものの一覧

上の3ステップを、よくあるパターンに当てはめた表です。自分のリストがどれに当たるかを先に決めてから作業します。

上から3行が、冒頭の1,842件の大半を占めるはずの分類です。件数が多くて当たり前、というのはこの3行のことを指しています。

4行目が、さきほどの通販サイトの49か所です。レポート上は他の行と区別が付かないので、ステップ2で自分から探しにいかないと見つかりません。

5行目と6行目は、移行を何度か重ねたサイトで出やすい形です。カテゴリ変更のあとにドメイン移転をした、というような履歴があると、転送が積み重なります。

最後の行だけは性質が違います。心当たりのないドメインが転送先に出てきたら、SEOの話ではなくサイトの安全性の問題として扱ってください。

見落としやすい4つ

判別フローを回すときに、つまずきやすい点をまとめます。

URL検査ツールのライブテストは、リダイレクトを追ってしまいます。 ヘルプには、テストではまずページに実装されたリダイレクトをたどり、次にページをテストする、と書かれています。さらに、テストでリダイレクトをたどったかどうかは確認できず、テストされた最終ページURLも表示されない、という注意も付いています。ライブテストで「問題なし」と出ても、それが転送元の話なのか転送先の話なのかは画面から読み取れません。転送先URLを自分で直接入力して検査するほうが確実です。

一時的な転送は、意味が変わります。 検索セントラルには、サイトのサービスが一時的に利用できなくなった場合に、一時的なリダイレクトを設定すれば、検索結果にある元のURLに影響を与えずに状況を説明するページへユーザーを誘導できる、という説明があります。恒久的な移転に一時的な転送を使うと、Googleに送るシグナルが意図とずれます。302と301の使い分けは301リダイレクトと302リダイレクトの違いで詳しく扱っています。

旧URLが検索結果に出ることがあります。 代替名についての説明には、ユーザーのクエリから古いURLのほうが信頼されていると解釈される場合、検索結果に代替名が表示されることがある、と書かれています。レポートで未登録に分類されているURLが検索結果で見えると混乱しますが、Googleは両方のURLを記録しているので、そういう表示は起こり得ます。

転送元をrobots.txtでふさがないでください。 「重複した URL の統合」のベストプラクティスには、正規化の目的でrobots.txtファイルを使用しないでください、と書かれています。リストを消したい一心で転送元のクロールをブロックすると、公式が避けるよう案内している使い方に正面からぶつかります。転送で伝えたかった正規URLの指定まで意図どおりに扱われなくなるおそれがあります。

直したあとの自己点検

修正を入れたら、次の項目で確認します。

• 転送先URLをURL検査ツールで確認し、登録済みになっている
• 旧URLから最終URLまで、転送が1回で終わっている
• サイト内リンク・パンくず・ナビゲーション・サイトマップに旧URLが残っていない
• 恒久的な移転に一時的な転送を使っていない
• 転送元URLをrobots.txtでブロックしていない
• 心当たりのない転送先が混ざっていない

サーバー側で転送を設定するときは、実装の早さも判断材料になります。「重複した URL の統合」には、すべての永続的なリダイレクト方法はGoogle検索に対して同じ効果があるが、検索エンジンが認識するまでの時間はそれぞれ異なり、最も早く効果が現れるのはHTTPリダイレクト（サーバーサイド リダイレクト）を使った場合、と書かれています。ページ側の記述で転送するより、サーバー設定で返すほうが先に伝わります。

レポート側で「修正を検証」を押した場合は、待ち時間も見込んでおきます。ヘルプには、検証処理には数日以上かかることがあり、進行状況はメールで通知される、と書かれています。押した直後に数字が動かないのは想定内です。

そして最後に、いちばん大事な確認を。件数をゼロにする必要はありません。 転送を持っているサイトなら、この項目にURLが並ぶのが正常です。ゼロを目標にすると、消すために転送を外すという逆方向の作業に向かってしまいます。

見るのは件数ではなく、内訳です。3ステップで拾った修正対象がゼロになっていれば、その時点で対応は終わりです。