リダイレクトチェッカー
このリダイレクトチェックツールで、どのURLや短縮リンクのリダイレクトも確認できます。各ホップのステータスコード（301、302、307、308、meta refresh）とその意味、転送先、所要時間を、ブラウザーと同じく最大20ホップまでたどって表示します。Googlebotが追跡をやめる位置や、httpとhttps、wwwあり・なしの4バージョンも調べられます。
ドメインだけを入力すると https:// から始まります。HTTPからHTTPSへのホップも調べるには http:// を付けて入力してください。
リダイレクトチェッカーでは何がわかりますか？
リダイレクトチェッカーは、ブラウザーと同じ方法でURLにアクセスし、返ってきたLocationヘッダーを1ホップずつたどって、ページが応答するまで追跡します。各ホップのステータスコード、転送先、所要時間、応答したネットワークがわかります。
このツールは各ホップの時間を計測します。新しい接続ならDNS、接続、TLS、最初のバイトに分け、ブラウザーと同じく同じホストへの開いている接続を再利用するホップでは最初のバイトのみを表示します。ブラウザーのようにホストごとにCookieを保持し、最終ページのmeta refresh、canonicalタグ、noindexも読み取り、Googlebotが追跡をやめる位置も示します。
- 13301永続POSTがGETに変わる場合あり4368 mshttp://google.com/Google AS15169HTTP/1.1 · TLSなし
- 2302一時POSTがGETに変わる場合あり537 mshttp://www.google.com/Google AS15169HTTP/1.1 · TLSなし
- 3200最終OK393 mshttps://www.google.com/?gws_rd=ssl“Google”Google AS15169TLS 1.3 · HTTP/2
- 1合計時間 ページが始まる前の全ホップの合計です。
- 2ホップ数の目安 リダイレクト1回につき1マス。Googlebotの上限は10、ブラウザーは20です。
- 3各ホップのサイト アイコンが変わったら、リンクが別のサイトに移ったことを示します。
- 4ステータス 種類ごとの色と、その意味を言葉で示します。
- 5時間の内訳 DNS、接続、TLS、最初のバイトを1つの時間軸で表示します。
301リダイレクトを確認するには？
上のフィールドにURLを貼り付けてリダイレクトを確認を選ぶと、URLにアクセスして最終ページまですべてのリダイレクトをたどり、各ホップのステータスを示します。301と308は永続として緑、302、303、307は一時として黄色で表示されます。ドメインだけを入力した場合はhttps://から始まります。HTTPからHTTPSへのホップも調べるには、http://を付けて入力してください。
判定はチェーン全体を言葉でまとめ、紺色の列は各ホップを1つの時間軸で描き、チェーン表示では各ホップのリクエスト、ステータス行、送信されたままのLocationと解決後のURL（相対パスも可）、すべてのヘッダーを一覧にします。
URLリダイレクトチェッカー：1つのリンク、すべてのホップ
任意のURLや短縮リンクを最大20ホップまで追跡し、各ホップのネットワーク、TLSバージョン、HTTPバージョンを表示します。httpとhttps、wwwあり・なしの4つの入口も並べて確認します。
リダイレクト一括チェック：最大50件のURL
一括に切り替えて、移転リストを1行に1URLずつ貼り付けます。ホップ数、最終ステータス、最終URL、判定を表にまとめ、CSVでダウンロードできます。
Googlebot、iPhone、Bingbotとしてリダイレクトを確認
フィールドの下でユーザーエージェントを選びます。クローラーやスマートフォンを別の場所へ転送するサイトもあり、そのエージェントが受け取った結果がチェーンにそのまま表示されます。
各ホップのHTTPステータスチェック
各ステータスコードを、ブラウザーとGoogleにとっての意味とともに言葉で説明します。ボット対策による遮断は「ブロック」として扱い、壊れたページとは呼びません。Cloudflare独自の52xエラーもCloudflareのものとして示します。
判定URLの行き着く先、ホップ数、各ホップが永続か一時かを言葉で示します。ホップ数の目安リダイレクト1回につき1マス、種類ごとの色で表し、Googlebotの10とブラウザーの20を基準にします。各ホップのステータスサーバーが返したコードと、その意味（永続か一時か、POSTがどうなるか）を表示します。時間の内訳各ホップのDNS、接続、TLS、最初のバイトを、最初のリクエストからページまで1つの時間軸で表示します。301と302の違いは？どちらを使うべきですか？
ページが恒久的に移転したなら301（または308）、元に戻す予定がある場合だけ302（または307）を使います。このコードによって、ブラウザーと検索エンジンはどちらのURLを保持するかを判断します（RFC 9110 §15.4）。
Googleにとって、301と308は転送先が正規URL（検索結果に表示するURL）であるべきことを示すシグナルですが、302、303、307はそうではないため、検索結果には古いURLが残ります（Google検索セントラル）。302が無視されるわけではありません。Googleは302もたどり、転送先を処理すべきだという弱いシグナルとして扱います（Googleのクローラーに関するドキュメント）。他の正規化シグナルが転送先を示していれば、転送先がインデックスに登録される可能性もあります。Bingは、2日未満の変更にのみ302を使うよう求めています。
ブラウザーは301と308を既定でキャッシュするため、取り消した永続リダイレクトが訪問者のブラウザーに残ることがあります。307と308はリクエストメソッドを保持しますが、301と302はPOSTをGETに変える場合があり、303は必ずGETに変えます。
| コード | 永続 | POSTの場合 | ブラウザーのキャッシュ | Googleのシグナル | 用途 |
|---|---|---|---|---|---|
| 301Moved Permanently | 永続 | GETに変わる場合あり | あり | 強 | 恒久的に移転したページ |
| 308Permanent Redirect | 永続 | 保持 | あり | 強 | 恒久的に移転したフォームやAPI |
| 302Found | 一時 | GETに変わる場合あり | なし | 弱 | 短期間の移転（Bing：2日未満） |
| 303See Other | 一時 | 必ずGET | なし | 弱 | フォーム送信後に表示するページ |
| 307Temporary Redirect | 一時 | 保持 | なし | 弱 | POSTを保持する必要がある一時的な移転 |
| meta 0即時meta refresh | 永続 | GET | — | 強 | サーバーでリダイレクトできない場合 |
| meta 5遅延meta refresh | 一時 | GET | — | 弱 | 非推奨：訪問者に先に古いページが表示される |
Refreshヘッダーも含みます。リダイレクトチェーンは何ホップまでなら大丈夫ですか？
3ホップを超えないようにしてください。チェーンとは、http://からhttps://、次にwww、さらに新しいパスへというように、リダイレクトが連続することです。Googleは、最終URLへ直接リンクするか、チェーンを3ホップ以内、どんな場合も5ホップ未満に抑えるよう推奨しています（Google検索セントラル）。
Googlebotは最大10ホップまでたどり、それを超えると追跡をやめて、Search Consoleに「リダイレクト エラー」と表示されます（Googleのクローラーに関するドキュメント）。ChromeとFirefoxは最大20ホップまでたどり、それを超えるとERR_TOO_MANY_REDIRECTSを表示します。ホップが増えるたびにページの開始前に往復通信が1回増えるので、内部リンクは最終URLを指すように更新してください。
- Googleの推奨：3以下
- 追跡はされるが遅くなる
- Googlebotはここまで到達しません：Search Consoleに「リダイレクト エラー」と表示
- 20超：
ERR_TOO_MANY_REDIRECTS
リダイレクトループを直すには？
食い違っている2つのルールを見つけて、1つの最終URLに揃えます。ループとは、すでにアクセスしたURLに戻ってくるチェーンのことで、ブラウザーはリダイレクトが20回に達するまで繰り返し、ERR_TOO_MANY_REDIRECTSを表示します。
ループの多くは、wwwを付けるルールと外すルールの衝突、またはCDNの背後でHTTPとHTTPSのルールがぶつかることで起こります。CDNがhttp://でサーバーに接続し、サーバーがhttps://へリダイレクトし、CDNがまたhttp://で問い合わせるという具合です。ブラウザーは永続リダイレクトを保持するため、修正後はプライベートウィンドウで確認してください。
リダイレクトループチェッカーがループを見つける仕組み
新しいCookieがないまま同じURLに2回目のアクセスが発生すると、ループと判定します。経路は繰り返されるホップまで戻して描画してそこで止まり、20回まで回り続けることはありません。Cookieを設定して自分自身にリダイレクトするサイトでは、ブラウザーと同じようにそのCookieを送り返すため、ログイン手順をループと誤認することはありません。
ERR_TOO_MANY_REDIRECTS · 20回後
meta refreshリダイレクトとJavaScriptリダイレクトはGoogleにたどってもらえますか？
条件付きでたどられます。Googleは、即時のmeta refresh（content="0; URL=…"）を永続リダイレクト、遅延のあるものを一時リダイレクトとして扱い、HTTPのRefreshヘッダーも同様に扱います（Google検索セントラル）。JavaScriptリダイレクトはGoogleがページをレンダリングできた場合にのみ機能するため、最後の手段として使ってください。
0秒のmeta refreshでも、ページの読み込みが完了してから実行されるため（HTML Standard）、訪問者に先に古いページが表示されることがあります。このチェッカーは、meta refreshとRefreshヘッダーを待ち時間付きの独立したホップとして追跡します。ページ内の単純なJavaScriptリダイレクトも検出してこのURLを確認を表示しますが、スクリプトは実行しません。「見つかりません」はHTML内にないという意味で、まったくないという意味ではありません。
HTTP/1.1 301 Moved Permanently Location: https://example.com/new
- Google: コードによる：301と308は永続、それ以外は一時
- このチェッカー: 1ホップずつ追跡
<meta http-equiv="refresh" content="0; URL=https://example.com/new">
- Google: 0秒：永続、遅延あり：一時
- このチェッカー: 待ち時間付きのホップとして追跡
window.location.href = "https://example.com/new";
- Google: レンダリングできた場合のみ：最後の手段
- このチェッカー: 「このURLを確認」で表示、実行はしない
http、https、www、wwwなしはすべて同じURLに転送されますか？
そうなっているのが望ましい形です。どのサイトにも4つの入口があり、それぞれが同じ最終URLに、できれば1回の永続リダイレクトで到達する必要があります。そうでないと、同じページの別バージョンにリンクが分散します。
例外が1つあります。同じホストで先にhttps://www.へ移るなら、http://www.が2ホップになっても問題ありません。hstspreload.orgはまさにこの順序を求めており、Mozilla HTTP Observatoryはhttp://からの最初のホップが別のホストに向かう場合に5点を減点します。
4つすべてがhttps://github.com/に到達http://www.github.comは2ホップ：HSTSプリロードの求めに従い、まず同じホストのhttps://へ
各入口は、メインのチェーンと並べて最大10ホップまでたどります。
国によってURLのリダイレクト先が変わるのはなぜですか？
サーバーが訪問者のIPアドレスやAccept-Languageヘッダーから国や言語のバージョンを選んでリダイレクトするため、同じURLでも訪問者によって行き着くページが変わります。www.mozilla.orgは言語で振り分けており、/en-US/への相対302とVary: Accept-Languageを返します。
Googleはこれを推奨していません。「サイトのある言語バージョンから別の言語バージョンへユーザーを自動的にリダイレクトしない」よう求めています。Googlebotは通常米国からクロールし、Accept-Languageを送らないためです（Google検索セントラル）。各バージョンに専用のURLを用意してhreflangでリンクし、他のバージョンはバナーで案内してください。
結果の11地点からは、Webサイトダウンチェッカーの世界各地のプローブからチェーンをたどるため、国別のリダイレクトは異なる行き先として現れます。これらのプローブは独自のユーザーエージェントで最大5回までリダイレクトをたどります。
Ahttps://shop.example/10地点がここに到達
- あなた最寄り20041 ms
サンノゼSJC200152 ms- アッシュバーンIAD20096 ms
ロンドンLHR20022 ms
ストックホルムARN20031 ms
シンガポールSIN200168 ms
シドニーSYD200290 ms
サンパウロGRU200201 ms
ケープタウンCPT200170 ms
ムンバイBOM200121 ms
Bhttps://shop.example/ja-jp/異なる
大阪KIX302200486 ms
大阪だけが受け取った応答
HTTP/1.1 302 Found Location: /ja-jp/ Vary: CF-IPCountry
2026年10月24日に記録：www.mozilla.orgは言語でリダイレクトします
HTTP/1.1 302 Found location: /en-US/ Vary: Accept-Language
Googlebotは主に米国からクロールし、Accept-Languageを送らないため、見えるのはhttps://shop.example/だけです。
このリンクの行き先は？短縮リンクを展開する
短縮リンクやトラッキングリンクを上に貼り付ければ、開く前に行き先を確認できます。各ホップのホスト、途中で追加されたパラメーターをすべて含む最終URL、応答したネットワークがわかります。短縮リンク、QRコード、メールマガジンのリンクのリダイレクト追跡に使えます。
リンクを開くのはあなたのブラウザーではなく当サーバーなので、行き先にあなたのアドレスやCookieが知られることはありません。途中の各ホストはCloudflareのマルウェアおよびアダルトコンテンツのフィルターでも照会され、登録されたホストは赤で示されてリンクは開けず、問題のないホストには「Cloudflareのマルウェア・アダルトリストに登録なし」と表示されます。これはそのサイトの安全を保証するものではないため、このリンクリダイレクトチェッカーは複数の確認手段の1つとして使ってください。
短縮リンク
https://youtu.be/jNQXAC9IVRw
303 See Other · 260 ms到達先
https://www.youtube.com/watch?v=jNQXAC9IVRw&feature=youtu.be
200 OK · 768 ms- AS15169Google · 応答したネットワーク
- TLS 1.3両方のホップが暗号化
- 当サーバー開いたのは当サーバー、ブラウザーではない
feature=youtu.beを追加します。クリックする前に、トラッキングパラメーターが最終URLに現れます。nginx、Apache、Cloudflareで301リダイレクトを設定するには？
リダイレクトはサーバー側で設定し、301を明記します。nginxならreturn行、Apacheなら.htaccessのRedirect行、IISならweb.configのルール、CloudflareやNetlifyなら_redirectsファイルの1行、Vercelならvercel.jsonの設定、Expressなら関数呼び出しです。下でお使いのプラットフォームを選んで、スニペットをコピーしてください。
既定値に注意してください。コードを書かない場合、nginx、Apache、Express、Cloudflareの_redirectsは一時的な302を返し、Vercelは308を返します。308はGoogleが301と同様に扱います。デプロイ後は、古いURLをここで確認してください。新しいURLへ直接向かう301が1回だけ返るはずです。
| プラットフォーム | 記述方法 | 返す値 |
|---|---|---|
| nginx | return URL; | 302 一時 |
| Apache | Redirect /old /new | 302 一時 |
| IIS | action type="Redirect" | 301 永続 |
| Cloudflare | _redirects | 302 一時 |
| Vercel | vercel.json redirects | 308 永続 |
| Netlify | _redirects | 301 永続 |
| Express | res.redirect(path) | 302 一時 |
location = /old-page {
return 301 /new-page;
}サイトのserver { }ブロック内に記述し、nginxをリロードします。コードなしの`return URL;`は302です。
Chromeやcurlでリダイレクトを確認する方法
Chromeでは、DevTools（F12）を開いてネットワークに移動し、ログを保持にチェックを入れてURLを読み込みます。各ホップがステータス付きの1行として表示されます。curlでは、curl -sILがリダイレクトをたどりながら各レスポンスのヘッダーを出力します。
どちらもお使いの端末から実行されるため、あなたのCookieや、ブラウザーが覚えているHTTPS専用サイトの情報が影響します。そのため、Chromeではサーバーが送っていない307 Internal Redirectが表示されることがあります。リクエストをブラウザー自身がHTTPSにアップグレードしたもので、理由はNon-Authoritative-Reasonに示されます（Chromiumソース）。Chrome 115以降は、入力したhttp://のアドレスをまずHTTPSで試すため、サーバー自身のHTTPリダイレクトが表示されないこともあります。
$ curl -sIL http://google.com | grep -iE '^(HTTP|location)' HTTP/1.1 301 Moved Permanently Location: http://www.google.com/ HTTP/1.1 302 Found Location: https://www.google.com/?gws_rd=ssl HTTP/2 200
307 Internal Redirectはサーバーからのものではありません。ChromeがそのサイトをHTTPS専用だと把握していたために生成したもので、理由はNon-Authoritative-Reason: HSTSに示されます。サーバー側のチェッカーには、サーバーが実際に送ったものだけが表示されます。
リダイレクトチェッカー：よくある質問
302リダイレクトはSEOに悪いですか？
Googlebotは何回までリダイレクトをたどれますか？
GooglebotやiPhoneとしてリダイレクトを確認するには？
この301リダイレクトチェッカーは無料ですか？多数のURLを一度に確認できますか？
サーバーが送っていない307がChromeに表示されるのはなぜですか？
301リダイレクトはどのくらいの期間維持すべきですか？
このリンクの行き先は？開いても安全ですか？
ERR_TOO_MANY_REDIRECTSが表示されるのはなぜですか？
HTTPからHTTPSへは301でリダイレクトすべきですか？
301リダイレクトはリンクの評価を引き継ぎますか？
関連するWebサイトツール
HTTPヘッダーチェッカー
HTTPレスポンスヘッダーとセキュリティヘッダーのグレーディング分析
リンク解析
dofollow/nofollow検出とHTTPステータスチェック付きでページ内リンクを分析
サイトダウンチェッカー
落ちてるのは全員か自分だけか？11か所とお使いの回線からサイトを確認し、実際の画面のスクリーンショットも表示
SSL証明書チェック
SSL証明書の有効性とセキュリティ詳細を検証
DNS検索
ドメイン自身のネームサーバーから全DNSレコードを取得し、GoogleとCloudflareのキャッシュと比較
ホスティングチェッカー
あらゆるサイトのホスティング会社を特定：ホスト、CDN、CMS、メールプロバイダー、レジストラ、SSL発行元
サブドメイン検索
ドメインの全サブドメインを検出
WHOIS検索
RDAPでドメインの登録情報、レジストラ、所有者の詳細を検索