検索ブランド相談室 | 検索と評判の専門メディア

SEOリダイレクトの確認方法|多段転送・ループ・誤転送を検出

部署:マーケティング担当者レベル:実践
リダイレクトの転送経路を確認しながらSEO監査を行うパソコン作業画面

サイト移行やURL変更のあと、ページが問題なく表示されていても、リダイレクト(旧URLから新URLへの自動転送)が正しく設定されているとは限りません。旧URLから転送が複数回続く「リダイレクトチェーン」、転送が元のURLへ戻って終わらない「リダイレクトループ」、内容の異なるページへの誤転送、旧URLを指したままの内部リンクなどが残っていることがあるためです。

確認すべきなのは、301や302など「3」で始まるHTTPステータスコード(3xx)の件数ではありません。旧URLが意図した最終URLへ直接たどり着くか、転送先が正常に表示される(200を返す)か、内部リンクやXMLサイトマップまで新URLにそろっているか。この3点です。

この記事では、クローラー(サイト内のページを自動で巡回して状態を取得するツール)でサイト全体の3xxを抽出し、問題を分類して優先順位を付け、修正し、再クロールで完了を確認するまでの方法を順に解説します。

関連する全体像や前提は「テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき」で整理しています。

SEOのリダイレクト監査では「3xxの有無」ではなく転送経路全体を確認する

リダイレクトは、古いURLから新しいURLへユーザーや検索エンジンを案内するために必要な仕組みで、リダイレクトそのものがSEO上の問題なのではありません。監査で見つけるのは、その転送経路の途中や前後に生じる不整合です。

Google Search Centralでは、恒久的な移転には301や308などの永続的リダイレクト、短期間の移転には302や307などの一時的リダイレクトを使う考え方が示されています。永続的なリダイレクトは、転送先を正規URLとして扱うための強いシグナルにもなります。

監査で問題になるのは、主に次の8つの状態です。

確認対象問題例基本的な修正方向
ステータスコード恒久移転なのに302意図に応じて301・308等へ変更
転送経路A→B→Cと複数回転送A→Cへ直接転送
転送先404・500へ転送有効な200ページへ修正
転送内容無関係なページへ転送内容が対応するURLへ再設定
ループA→B→A循環するルールを解除
内部リンクサイト内から旧URLへリンク最終URLへ直接変更
canonical新ページが旧URLをcanonical指定新URLへ統一
XMLサイトマップ転送URLを掲載最終200 URLのみへ整理

8項目は別々の問題に見えますが、どれも「URLの旧状態から現在の正規URLまでの経路が一貫しているか」という同じ視点で確認できます。この視点で進めると、項目ごとの確認漏れを減らせます。ステータスコードの使い分けは次の節で、残りの項目は6段階の手順の中で確認します。

最初に301・302・307・308の使い方が意図と合っているか確認する

HTTPの3xxステータスには複数の種類があります。RFC 9110では、301と308は恒久的な移動、302と307は一時的な移動を表すステータスとして定義されています。307と308には、リダイレクト後もHTTPメソッド(GETやPOSTなど、リクエストの種類)を変更しないという特徴があります。

SEO監査では、番号だけで良し悪しを決めず、そのURL変更が恒久的なのか一時的なのかという意図と照らして判断します。次の表は、状況ごとの判断の目安です。

状況主な候補監査時の判断
URLを恒久的に変更301・308原則として問題なし
ドメイン移転301・308URL対応関係を重点確認
一時的なキャンペーン転送302・307一時転送として妥当
恒久移転なのに302が長期残存要確認恒久転送への変更を検討
一時的な転送なのに301要確認運用意図を確認

たとえば、商品ページのURLを完全に変更し、旧URLへ戻す予定がないにもかかわらず302を設定している場合は、設定意図とステータスが一致していません。表では「恒久移転なのに302が長期残存」にあたり、恒久転送への変更を検討します。

一方、302だからといって、ただちにSEO上の失敗になるわけではありません。重要なのは、「このURL変更は恒久なのか、一時なのか」という事業・サイト運用上の意図と、設定したステータスが一致していることです。判断に迷うURLは、運用担当者に意図を確認してから変更するかどうかを決めましょう。

リダイレクト監査は6段階で進める

サイト全体を監査する場合は、次の6段階で進めると問題を整理しやすくなります。まずサイト全体の3xxを一覧にして問題の種類を分け、転送先、内部リンク、canonical・サイトマップへと確認の範囲を広げていく順番です。

3xx抽出から再クロールまでのリダイレクト監査6ステップ

リダイレクト監査は、問題URLを見つけるだけでなく、修正後の再クロールまでを一連の工程として進めます。

  1. サイト内の3xx URLを抽出する
  2. リダイレクトチェーンとループを検出する
  3. 転送先が適切か確認する
  4. 旧URLへの内部リンク残存を確認する
  5. canonical・サイトマップとの整合性を確認する
  6. 修正後に再クロールする

STEP1から順に、それぞれのやり方と判断基準を説明します。

STEP1:サイト全体をクロールして3xx URLを一覧化する

最初に、サイト内で発生している3xxを一覧にします。Screaming Frog、Ahrefs、Semrushなどのクローラーを使えば、サイト内リンクをたどりながら、ステータスコードと転送先を確認できます。取得する項目は、最低限、次の7つです。

  • 転送元URL
  • HTTPステータス
  • 転送先URL
  • 最終到達URL
  • リダイレクト回数
  • 最終到達URLのHTTPステータス
  • 転送元URLへリンクしているページ

ここで大切なのは、「301が何件あるか」で終わらせないことです。たとえば /old-a/ → /old-b/ → /new-a/ という状態では、最初のURLだけを見ると正常な301ですが、経路全体ではチェーンが発生しています。「最終到達URL」と「リダイレクト回数」を取得するのは、1行ずつではなく、転送元から最終地点までを1本の経路として読むためです。

STEP2:リダイレクトチェーンとループを検出する

リダイレクトチェーンとは、最終ページへ到達するまでに複数回のリダイレクトを通過する状態です。たとえば URL A → URL B → URL C であれば、AからCへ直接転送できるにもかかわらずBを経由しています。チェーンが見つかったら、A → B → C ではなく A → C となるように変更します。

Googleはサイト移転の公式ドキュメントで、Googleのクローラー(Googlebot)が複数のリダイレクトを追跡できる一方、最終URLへ直接リダイレクトすることを推奨しています。長いチェーンは避け、必要な場合も転送回数を少なくすることが推奨されています。

Ahrefsでも、リダイレクトチェーンは読み込み時間やクロール経路を複雑にするため、可能な限り最終URLへ直接転送する方法が案内されています。

正常なリダイレクトとリダイレクトチェーン、ループの違いを比較した図

正常な転送は最終URLへ直接到達します。途中URLを挟むチェーンや、元のURLへ戻るループは監査対象です。

チェーンよりさらに優先度が高いのが、リダイレクトループです。たとえば A → B → A や、A → B → C → A のように転送が循環すると、最終ページへ到達できません。ブラウザでも「リダイレクトが繰り返し行われました」などのエラーになる可能性があります。

ループを検出した場合は、他の改善より先に転送ルールを修正します。

STEP3:転送先の内容とHTTPステータスを確認する

リダイレクト先が200を返していても、それだけでは正常とは限りません。SEO監査では、旧ページと転送先ページの内容が対応しているかを確認します。

たとえば、「SEOコンサルティング料金」ページをサイトトップページへ転送するよりも、新しい「SEOコンサルティング料金」ページへ転送するほうが自然です。このように、内容が対応するURLへ転送します。

Googleも、複数の古いURLを無関係な1ページへまとめて転送すると、ユーザーを混乱させ、soft 404(存在しないページ同然の状態)として扱われる可能性があると案内しています。

監査時は次の3点を確認します。

  • 転送先が200を返しているか
  • 旧ページと新ページの内容が対応しているか
  • 本当に転送すべきURLなのか

3点目では、対応ページがなく、同等のコンテンツも存在しない場合に注意します。そのときは、無理にトップページへ301するより、404または410が適切なケースもあります。

STEP4:旧URLへ向いた内部リンクを最終URLへ変更する

301が正常に機能していても、サイト内部のリンクが旧URLを向いたままなら修正対象です。リダイレクトは旧URLからのアクセスを救済する仕組みであり、現在のサイト内部で意図的に経由させるための仕組みではないためです。

たとえば、記事A → /old-service/ →301→ /service/ という内部リンクは、記事A → /service/ へ直接変更します。Googleもサイト移転後には、旧URLを参照している内部リンクを新しいURLへ更新するよう推奨しています。

確認する場所は、特に次の7か所です。

  • グローバルナビゲーション
  • パンくず
  • 記事本文
  • 関連記事
  • フッター
  • CTA
  • HTMLサイトマップ

アクセス数の多いページやサイト共通部分から旧URLへリンクしている場合は、優先度を高くします。

STEP5:canonicalとXMLサイトマップを新URLへ統一する

リダイレクトだけを直しても、canonicalやXMLサイトマップが旧URLを示していると、検索エンジンへ矛盾したシグナルを送ることになります。

Googleは正規URLを示す手段について、リダイレクトとrel="canonical"を強いシグナル、サイトマップを比較的弱いシグナルとして説明しています。複数のシグナルを同じ正規URLへ揃えることで、希望するURLを明確に伝えやすくなります。

そのため、移行後は次の状態を目指します。リダイレクトだけでなく、内部リンク・canonical・XMLサイトマップも同じ新URLを示す状態に揃えます。

旧URLのリダイレクト、内部リンク、canonical、XMLサイトマップを新しい正規URLへ統一する図
  • 旧URL → 301 → 新URL
  • 新URL → 200
  • 新URLのcanonical → 新URL
  • XMLサイトマップ → 新URL
  • 内部リンク → 新URL

反対に、次のような組み合わせは設定が矛盾しています。

  • 旧URL → 301 → 新URL
  • 新URLのcanonical → 旧URL

XMLサイトマップも、原則として検索結果へ表示したい正規URLを掲載します。Googleは、同じコンテンツに複数URLがある場合、希望する正規URLをサイトマップへ含める方法を案内しています。

監査結果を1行で追える監査表を残す

ここまでのSTEP1〜5で問題を見つけたら、URLごとの確認結果を監査表に残します。

転送経路だけでなく、内部リンクやcanonicalまで同じ行で管理すると、「どのURLに問題があり、何を直す必要があるか」を判断しやすくなります。次の表は記入例です。

転送元URL1回目の応答経由URL最終URL転送回数内部リンク旧URLcanonical判定修正担当
/old-page/301/middle-page//new-page/2あり旧URL要修正Web担当
/old-service/301なし/service/1なし新URL問題なし–

特に注意したいのは、転送だけが正常に見える場合です。最終URLへ正しく転送されていても、内部リンクやcanonicalに旧URLが残っていれば、修正は完了していません。

記入例では、1行目の/old-page/は2回転送され、内部リンクにも旧URLが残り、canonicalも旧URLのままなので「要修正」です。2行目の/old-service/は1回で最終URLに届き、内部リンクにもcanonicalにも問題がないため「問題なし」です。

問題を発見した時点の状態はそのまま残し、修正後は同じ表で比べます。修正前後を同じ条件で比較すると、対応漏れや再発を確認しやすくなります。

STEP6:修正後に再クロールし、同じ監査表で完了を確認する

リダイレクトの修正は、設定を変更した時点では完了ではありません。再クロールして、問題が解消されたことを確認します。最低限、次の7項目を再確認してください。

  • リダイレクトループが0件になったか
  • 不要なリダイレクトチェーンが解消されたか
  • 転送先が200を返しているか
  • 誤転送が残っていないか
  • 旧URLへの内部リンクが解消されたか
  • canonicalが新URLへ統一されたか
  • XMLサイトマップに旧URLが残っていないか

重要ページについては、Google Search ConsoleのURL検査も併用します。Googleはサイト移転時、リダイレクト実装後に個別URLをURL検査ツール等で確認し、サイト全体についてもトラフィックやクロール状況を監視することを推奨しています。

再確認は、修正前と同じ監査表で行います。「要修正」だったURLが「問題なし」へ変わったかを確認し、転送経路だけでなく、内部リンクやcanonicalまで修正されたことを記録して、監査を完了します。

リダイレクト問題は「影響度×修正緊急度」で優先順位を付ける

数千URLを持つサイトでは、すべてのリダイレクトを同時に修正するのは現実的ではありません。そこで、問題の影響が及ぶ範囲(影響度)と、放置したときにページへ到達できなくなるかどうか(修正緊急度)を目安に、直す順番を決めます。

リダイレクトループや誤転送などSEO監査で修正する問題の優先順位

ページへ到達できないループやエラー転送を最優先にし、重要ページへの影響が大きい問題から修正します。

次の順番を基本にすると判断しやすくなります。

優先度問題理由
最優先リダイレクトループページへ到達できない
最優先404・5xxへの転送転送先が機能していない
高重要ページの誤転送検索意図・ユーザー導線を損なう
高長いリダイレクトチェーンクロール・表示経路が非効率
中大量の旧URL内部リンクサイト全体のクロール効率に影響
中恒久変更で残る302転送意図と設定の不一致
中canonicalとの不整合正規URLシグナルが競合
中〜低アクセスの少ない単発チェーン影響範囲が限定的

特に、検索流入や被リンクを多く持つページ、CVにつながるページ、カテゴリトップなどの重要URLは優先して確認します。

サイト移行後はリダイレクトをすぐ削除しない

移行が終わったからといって、旧URLからのリダイレクトを短期間で削除するのは避けるべきです。

GoogleはURLを伴うサイト移転について、リダイレクトを可能な限り長く、一般には少なくとも1年間維持することを推奨しています。その目的は、Googleが旧URLと新URLを再クロールし、各種シグナルを移行する時間を確保することです。

またGoogleは、301などの永続的リダイレクト自体によってPageRank(リンクを通じて伝わる評価)が失われるわけではないと説明しています。

そのため、SEO監査では「301があるから削除する」のではなく、次の3点を分けて判断します。

  • その301が今も必要か
  • 正しい最終URLへ向いているか
  • 内部リンクから不要に経由していないか

移行・URL変更後に確認するリダイレクト監査チェックリスト

サイト移行やURL変更後は、以下の13項目を確認してください。

  • すべての旧URLの転送先が定義されている
  • 恒久移転と一時移転でステータスを使い分けている
  • リダイレクトループが存在しない
  • 不要なリダイレクトチェーンが存在しない
  • 旧URLから最終URLへ直接到達できる
  • 転送先が200を返している
  • 無関係なページへ一括転送していない
  • 削除ページを不自然にトップページへ転送していない
  • 内部リンクが最終URLを直接参照している
  • canonicalが新URLを示している
  • XMLサイトマップに転送URLが残っていない
  • 重要URLをSearch Consoleで確認している
  • 修正後にサイトを再クロールしている

1つずつ確認するだけでなく、転送元 → 転送経路 → 最終URL → 内部リンク → canonical → サイトマップを一続きで確認することが、監査の精度を上げるポイントです。

まとめ:転送経路全体を6段階で確認し、一定期間後にも再監査する

SEOのリダイレクト監査では、301や302の件数を確認するだけでは不十分です。目指す状態は、旧URLから適切な最終URLへ、余計な中継を挟まず正しく到達できることです。

その状態を確かめるために、監査は次の順番で進めます。

  1. 3xxを抽出する
  2. チェーン・ループを確認する
  3. 転送先の内容とステータスを確認する
  4. 旧URLへの内部リンクを修正する
  5. canonical・サイトマップを統一する
  6. 再クロールする

特にサイトリニューアル、ドメイン変更、URL構造変更を実施した後は、一度設定して終わりにせず、一定期間後にも再監査してください。過去の移行が積み重なるほど、A→B→Cのようなチェーンや旧URLへのリンク残存が発生しやすくなります。

URL単位の設定ではなくサイト全体の転送経路として確認することで、検索エンジンがクロールしやすく、ユーザーも最短経路で目的ページへ到達できる状態を維持できます。

まずは、サイト全体の3xxを一覧にして、転送元から最終到達URLまでを1本の経路として読むところから始めましょう(STEP1)。

参考文献・データ元

この記事で参照した情報を確認できます。

  • Google Search Central「Redirects and Google Search」
    Google
    最終更新:2026年4月14日
    https://developers.google.com/search/docs/crawling-indexing/301-redirects
    使用内容:永続・一時リダイレクトとGoogle Searchでの扱い。

  • Google Search Central「Site Moves and Migrations」
    Google
    最終更新:2026年8月20日
    https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
    使用内容:URLマッピング、リダイレクトチェーン、内部リンク更新、移行後の検証、リダイレクト維持期間。

  • Google Search Central「How to Specify a Canonical with rel="canonical" and Other Methods」
    Google
    2026年更新
    https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
    使用内容:リダイレクト、canonical、サイトマップの正規URLシグナル。

  • Google Search Central「Build and Submit a Sitemap」
    Google
    2026年更新
    https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
    使用内容:サイトマップへ正規URLを掲載する考え方。

  • RFC 9110「HTTP Semantics」
    RFC Editor
    HTTP 3xx Redirection
    https://www.rfc-editor.org/rfc/rfc9110.html
    使用内容:301・302・307・308のHTTP上の定義。

‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

関連記事

関連テーマ