はじめに
本記事の目的
この章では、Googleサーチコンソール（以下、サーチコンソール）で表示される「リダイレクト」に関するエラーや警告の意味と、解決に向けた考え方をやさしく説明します。専門用語は最小限にし、具体例を交えて解説しますので、初めての方でも理解しやすい内容です。
誰に向けた記事か
・個人サイトやブログを運営している方
・企業サイトの担当者やWeb制作担当者
・SEOの基本を学びたい方
この記事で学べること
- サーチコンソールに表示される主なリダイレクト表示の意味
- よくある原因と簡単な確認方法
- 正しいリダイレクトの設定イメージ（例：古いページを新しいページへ移す場合）
- サイト移転時やページ統合時の注意点とSEOへの影響
読み方の案内
各章で「原因」「確認方法」「対処のコツ」を順に説明します。まずは次章でリダイレクトの基本とサーチコンソールでの見え方を確認してください。質問があれば気軽にどうぞ。
Googleサーチコンソールでのリダイレクトとは
リダイレクトの基本
リダイレクトとは、あるURLへアクセスした際に自動で別のURLに転送する仕組みです。例えば古い記事を新しいURLに移したときや、HTTPからHTTPSに統一するときに使います。ユーザーを正しいページへ導くために重要な設定です。
種類と簡単な違い
- 永続的（例：301）: ページが恒久的に移動したときに使います。検索エンジンは新しいURLを評価します。
- 一時的（例：302）: 一時的に別のページに飛ばすときに使います。元のURLが戻る前提です。
- HTMLやJavaScriptによるリダイレクト: サーバー設定ではなくページ内で転送する方法で、検索エンジンの扱いが異なります。
サーチコンソールでの見え方
サーチコンソールは「ページにリダイレクトがあります」などの警告を出します。元のURL（送信側）と転送先（受信側）を示すので、どのページが影響を受けているか分かります。エラー時はリダイレクトが無限ループになっている、チェーンが長すぎる、意図しない一時転送になっているなどが考えられます。
なぜ注意するか
リダイレクト自体は正常な運用の一部ですが、誤設定や複雑なチェーンは評価低下やクロール無駄遣いにつながります。したがって、サーチコンソールの指摘を見たら転送元と先を確認し、必要なら簡潔に直すことをおすすめします。
次にやること（簡単な目安）
- サーチコンソールで該当URLを確認する
- ブラウザやオンラインツールで実際に転送先をチェックする
- 意図しないリダイレクトならサーバー設定やCMSの設定を修正する
これでリダイレクトの基本がつかめます。次章ではサーチコンソールでよく見かける具体的なリダイレクトエラーを取り上げます。
サーチコンソールでよくあるリダイレクト関連エラーとその意味
概要
サーチコンソールには主に「ページにリダイレクトがあります」と「リダイレクトエラー」が表示されます。どちらもリダイレクトに関する問題を示しますが、意味と対処は異なります。
「ページにリダイレクトがあります」
意味：Googlebotがクロール時にそのURLでリダイレクトを検出したことを示します。意図的な301/302であれば問題ありません。例：HTTP→HTTPS、非www→wwwなど。
注意点：不要な中間リダイレクト（複数回の転送）や誤ったリンク設定で表示されることがあります。例えば内部リンクが古いURLを指していると無駄な転送が発生します。
チェック方法：URL検査で実際の転送先を確認し、ブラウザやcurlでHTTPヘッダを確認します。内部リンクやサイトマップを見直してください。
「リダイレクトエラー」
意味：リダイレクトが正しく機能しておらず、Googlebotが目的のページに到達できなかったことを示します。典型例はリダイレクトループ、存在しないURLへの転送、サーバーエラー（5xx）、タイムアウト、または不正なリダイレクト先です。
優先度の目安：ユーザーに直接影響するページや多くの被リンクがあるページは優先して修正します。まずはエラーの原因を特定し、正しい恒久的(301)または一時的(302)な転送を設定してください。
次章では正しいリダイレクト設定方法を分かりやすく説明します。
リダイレクト設定の正しい方法
概要
リダイレクトは原則サーバーサイドで実装します。最も推奨するのは「301（恒久的な転送）」です。301は検索エンジンへ旧URLの評価を新URLへ受け渡します。クライアント側のmeta refreshやJavaScriptでの転送は避けてください。
サーバーでの一般的な実装例
- Apache（.htaccess）の単一URLリダイレクト例:
Redirect 301 /old-page.html https://example.com/new-page.html
- Apache（.htaccess）のディレクトリ単位（RewriteRule）:
RewriteEngine On
RewriteRule ^old-folder/(.*)$ https://example.com/new-folder/$1 [R=301,L]
- Nginxの例（ドメイン丸ごと移転）:
server { return 301 https://new.example.com$request_uri; }
実装時のポイント
- クエリ文字列やパスを維持するときは$request_uriや$1などを使います。
- 内部リンク、サイトマップ、canonicalを新URLに更新してください。
- リダイレクトチェーンやループがないか必ず確認します。
確認方法
curlやブラウザ、Search ConsoleのURL検査でステータスを確認してください。ステータスが301で届き、最終URLへ一度で到達することを目標にします。
注意点
クライアントサイドの遷移は評価の継承が弱く、ユーザー体験も悪くなります。可能な限りサーバー設定で実装してください。
リダイレクトエラーの主な原因と対処法
不要なリダイレクト
原因: 使われない古いルールや自動追加の設定で、同じページへ複数のリダイレクトが存在します。
対処法: まずサイト全体をクロールして不要箇所を特定し、不要なルールを削除してください。例: /old-page→/new-page のみで十分な場合、追加の /new-page→/new-page2 を見直す。
リダイレクトチェーン
原因: A→B→C のように中継が複数あると、処理が遅くなりエラーを招きます。
対処法: 直接 A→C に短縮してください。特にモバイルやクローラーページで確認します。
リダイレクトループ
原因: A→B→A のように終点が存在しない設定です。
対処法: ループ箇所を特定して一方のルールを無効化し、正しい終点へ向けます。ローカルで再現してから反映してください。
リダイレクト先URLの誤り
原因: タイプミスや余分なパラメータ、プロトコル違い（http/https）です。
対処法: 正しい完全URLに修正し、相対パスと絶対パスの違いを確認します。
リダイレクト種類の誤用
原因: 恒久(301)と一時(302)を誤って使うと検索エンジンの扱いが変わります。
対処法: 移転なら301、テストや一時的な変更なら302を使ってください。
サーバーやSSL設定の不備
原因: サーバー設定や証明書不備でリダイレクトが成功しない場合があります。
対処法: サーバーログとSSL状況を確認し、ホスティング会社や管理画面で設定を修正してください。
サーチコンソール上での確認・対応手順
準備
サーチコンソールにログインし、対象のプロパティを選びます。サイト所有権と自分のアカウント権限を確認してください。修正する前にブラウザで該当ページにアクセスして状況を把握します。
エラー一覧の確認
左メニューで「インデックス作成」→「ページ」を開き、エラーや警告の一覧を確認します。リダイレクト関連の項目（リダイレクトループ、到達先の問題など）を見つけ、該当URLをメモします。
URL検査で詳細を確認
「URLを検査」に対象URLを入力してライブテストを実行します。ステータスコード、最終到達先のURL、モバイル表示の状態などを確認します。スクリーンショットやレンダリングの情報も参考にします。
修正の実行
サーバーやCMS側でリダイレクト設定を正しく行います（例：恒久的リダイレクトは301）。内部リンクやサイトマップに古いURLがあれば修正します。ブラウザやcurlで実際に挙動を確認してから次へ進みます。
修正後の再確認と再送信
修正後、URL検査で再テストし問題が解消されたら「インデックス登録をリクエスト」します。サイトマップも更新して再送信してください。反映には通常数日〜数週間かかります。
確認項目チェックリスト
- 対象URLが正しくリダイレクトされるか
- ステータスコードが301（恒久）か
- 内部リンク・サイトマップが更新済みか
- URL検査でエラーが消えたか
- 必要ならサーバーのログでクローラー挙動を確認する
以上の手順を順に行えば、サーチコンソール上でのリダイレクト問題を確実に対応できます。
サイト移転時のリダイレクトとサーチコンソールの設定
移転前の準備
・旧サイトと新サイトのURL対応表を作成します。例：/old-page → https://new.example.com/new-page。1対1で対応させることが重要です。
具体的な手順
- 301リダイレクトをページ単位で設定します。サーバー（.htaccessやnginx）で恒久的に転送してください。
- 旧・新サイトの両方をGoogleサーチコンソールで所有権確認します。
- サーチコンソールの「アドレス変更ツール」を使い、移転を通知します。ツールはドメイン単位での移転に便利です。
- 新サイトのサイトマップを送信し、クロールを促します。
移転後の確認・運用
・クロールエラーやカバレッジレポートを定期確認します。リダイレクトが404やループを返していないかを確認してください。ログやFetch as Googleで検証すると確実です。
・内部リンクやcanonical、hreflang（多言語サイトの場合）も新URLへ更新します。
・可能なら主要な外部リンク元へ新URLの依頼を行い、評価の移行を早めます。
保持期間と注意点
リダイレクトは少なくとも6〜12カ月は維持してください。短期間で外すと検索評価が戻らない恐れがあります。移転は段階的に確認しながら進めると安全です。
SEOに与える影響と注意点
リダイレクトがSEOに与える基本効果
恒久的なリダイレクト（例：301）を正しく設定すれば、元のページの評価はほぼ新しいURLへ引き継がれます。たとえば example.com/old が example.com/new に301で移動すると、検索順位への影響は最小限に抑えられます。
誤った設定で起きる問題
リダイレクトチェーン（A→B→C）やループ（A→B→A）があると、評価が分散したりクロールが途中で止まったりします。検索エンジンは長いチェーンを嫌うため、順位下落やインデックス未登録のリスクが高まります。
内部リンクとサイトマップの重要性
内部リンクやサイトマップに古いURLが残ると、評価が分散します。サイト内のリンクを新URLに更新し、XMLサイトマップも最新化してください。Search Consoleでサイトマップを再送信するとインデックス促進に役立ちます。
クロール負荷と表示速度への配慮
大量のリダイレクトはクロール予算を消費し、表示速度にも悪影響を与えます。可能な限り短いリダイレクト（1回）にして、同一ドメイン内で処理することをおすすめします。
モニタリングとチェックポイント
Search ConsoleのカバレッジやURL検査で転送状況を確認し、インデックス状況とクリック数の変化を追います。問題があればリダイレクト先やステータスを修正してください。テストは実際のURLで行い、外部リンクも可能なら更新を依頼することが重要です。
注意点（簡単チェックリスト）
- 恒久的リダイレクト（301）を基本にする
- チェーンを作らない（1回で完結）
- ループを絶対に避ける
- 内部リンク・サイトマップを更新する
- Search Consoleで状態を確認する
以上を守れば、移転やURL変更の際もSEO影響を最小化できます。したがって、事前の計画と検証を怠らないようにしてください。
まとめとチェックリスト
以下はサーチコンソールでリダイレクト問題が発生した際に押さえておきたい要点と実務的なチェックリストです。
要点
- リダイレクトは可能な限りサーバーサイドで実装し、恒久的な移動は301で返すと検索エンジンに伝わりやすいです。
- 不要なリダイレクト、複数のリダイレクトチェーン、そしてループは必ず排除してください。
- サイトマップや内部リンクを最新版に保ち、古いURLへリンクしないようにします。
チェックリスト（実務）
- サーチコンソールのエラー箇所を確認し、該当URLを特定する
- 該当URLのリダイレクト先をサーバー設定（.htaccessやサーバー設定）で301に設定する
- リダイレクトチェーンやループがないかcurlやブラウザでテストする（例: curl -I）
- 内部リンク・サイトマップ・canonicalタグを新URLへ更新する
- robots.txtで新URLがブロックされていないか確認する
- 修正後、サーチコンソールの「URL検査」やカバレッジ画面で再検証を実行する
これらを順に確認すれば、リダイレクトに起因するSEOリスクを最小化できます。問題を修正したら必ず検索コンソールで再検証して完了としてください。
