サイト移行や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・308 | URL対応関係を重点確認 |
| 一時的なキャンペーン転送 | 302・307 | 一時転送として妥当 |
| 恒久移転なのに302が長期残存 | 要確認 | 恒久転送への変更を検討 |
| 一時的な転送なのに301 | 要確認 | 運用意図を確認 |
たとえば、商品ページのURLを完全に変更し、旧URLへ戻す予定がないにもかかわらず302を設定している場合は、設定意図とステータスが一致していません。表では「恒久移転なのに302が長期残存」にあたり、恒久転送への変更を検討します。
一方、302だからといって、ただちにSEO上の失敗になるわけではありません。重要なのは、「このURL変更は恒久なのか、一時なのか」という事業・サイト運用上の意図と、設定したステータスが一致していることです。判断に迷うURLは、運用担当者に意図を確認してから変更するかどうかを決めましょう。
リダイレクト監査は6段階で進める
サイト全体を監査する場合は、次の6段階で進めると問題を整理しやすくなります。まずサイト全体の3xxを一覧にして問題の種類を分け、転送先、内部リンク、canonical・サイトマップへと確認の範囲を広げていく順番です。

リダイレクト監査は、問題URLを見つけるだけでなく、修正後の再クロールまでを一連の工程として進めます。
- サイト内の3xx URLを抽出する
- リダイレクトチェーンとループを検出する
- 転送先が適切か確認する
- 旧URLへの内部リンク残存を確認する
- canonical・サイトマップとの整合性を確認する
- 修正後に再クロールする
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 → 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に問題があり、何を直す必要があるか」を判断しやすくなります。次の表は記入例です。
| 転送元URL | 1回目の応答 | 経由URL | 最終URL | 転送回数 | 内部リンク旧URL | canonical | 判定 | 修正担当 |
|---|---|---|---|---|---|---|---|---|
| /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を持つサイトでは、すべてのリダイレクトを同時に修正するのは現実的ではありません。そこで、問題の影響が及ぶ範囲(影響度)と、放置したときにページへ到達できなくなるかどうか(修正緊急度)を目安に、直す順番を決めます。

ページへ到達できないループやエラー転送を最優先にし、重要ページへの影響が大きい問題から修正します。
次の順番を基本にすると判断しやすくなります。
| 優先度 | 問題 | 理由 |
|---|---|---|
| 最優先 | リダイレクトループ | ページへ到達できない |
| 最優先 | 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へ、余計な中継を挟まず正しく到達できることです。
その状態を確かめるために、監査は次の順番で進めます。
- 3xxを抽出する
- チェーン・ループを確認する
- 転送先の内容とステータスを確認する
- 旧URLへの内部リンクを修正する
- canonical・サイトマップを統一する
- 再クロールする
特にサイトリニューアル、ドメイン変更、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領域の実務チェックリスト
関連記事
- › INDEX削除(インデックス削除)とは?検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド|LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの確認方法|孤立ページ・深度・アンカー偏りを改善
- › ページがインデックスされない原因は?Search Consoleで未登録・除外・重複URLを確認
- › JavaScript SEOの確認方法|表示・内部リンク・登録状況
- › クロールバジェットの確認方法|無駄なクロールと改善優先度
- › 構造化データの確認方法|エラー・本文との不一致・重複を検証
- › 多言語ページの言語・地域指定を確認|相互参照・正規URLをチェック
- › 絞り込み検索のSEO確認方法|URL増加・クロール・重複を防ぐ
- › robots設定のSEO確認方法|クロール許可と登録制御の矛盾を確認
- › ページネーションのSEO確認方法|正規URL・内部リンク・クロール
- › サイト移行後のSEO確認方法|転送・正規URL・順位変動を確認
- › 404・soft 404のSEO確認|リンク切れ・消失URLを修正
- › SEOリリース前チェックの作り方|noindex・canonical・robots・リダイレクトの事故を防ぐ
- › 画像SEOの確認方法|alt・画像URL・遅延読み込みを確認
- › 求人ページの構造化データを確認|給与・勤務地・期限の不一致
- › サイト内検索ページのSEO確認|noindex・クロール・重複URL
- › サイトリニューアルでSEO評価を落とさない移行方法|URL・301・計測・公開手順
- › サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準
- › SEOに強いURL・ディレクトリ設計|階層・命名・変更時の注意点
- › サブディレクトリとサブドメインの違い|SEO・運用の判断基準
- › リッチリザルトとは?種類・構造化データ・表示確認方法を解説
- › Google Search Consoleとは?登録方法と最初に見る4つの指標




