301・302リダイレクトの監視では、転送元が301や302を返すことだけでなく、転送後の最終到達URL・最終HTTPコード・転送回数・HTTPSの状態を確認することが重要です。旧URLが301を返していても、最後に404や503となったり、別のページへ誤って転送されたりする可能性があるためです。
特に見逃しやすいのが、最終的に200 OKが返っても、予定と違うページへ着いているケースです。旧問い合わせページから新問い合わせページへ移動するはずが、トップページへ飛ばされていても、最後が200なら正常と判定する監視もあります。転送先が正しい場所かどうかまで確認しましょう。
この記事は、301・302の転送元から最終到達先までを監視する方法、異常の具体例、curlでの確認、ドメイン移転後の点検、エンリンクの補助診断を解説します。監視URLの選び方や監視履歴の見方とは検索意図を分け、転送先の異常を見つける方法に限定します。
301・302の転送元だけではサイトの正常を確認できない
HTTPリダイレクトは利用者を別のURLへ案内する仕組みです。最初の301・302と最終到達先のレスポンスは別の情報であり、一方だけを確認しても利用者が目的ページまで到達できたとは限りません。
301は恒久的、302は一時的な転送を示す
301 Moved Permanentlyは恒久的な移転、302 Foundは一時的な移動を示します。いずれも通常はレスポンスのLocationヘッダーに次のURLが指定されます。最初の301・302を受け取ったことは、次の場所を案内されたという意味です。
Google検索セントラルは、301などを転送先が正規URLであるという強いシグナル、302などを一時的な転送として説明しています。ただし検索の評価はほかの要因にも左右されるため、301だけで検索順位が必ず維持されるとは断定できません。Google公式のリダイレクト解説を参照してください。
旧URLが301を返しても転送先が404になる
例えばhttps://example.com/old/が301でhttps://example.com/new/へ誘導していても、新ページが削除されていれば最後は404になります。この場合、転送元の301は返っていますが、利用者は目的ページを閲覧できません。
初回レスポンスだけを成功判定する監視では、こうした異常が見えない可能性があります。最終到達先まで追跡し、そのHTTPコードとURLを確認することが必要です。
意図した301や302をすべて障害と判定しない
旧ドメインから新ドメインへ301で転送する予定なら、最初の3xxは想定どおりの応答です。「200以外は全部失敗」という設定のまま初回応答だけを見ると、正常な転送を障害として扱うことがあります。
反対に301を成功とするだけでは、最後の公開ページが正常か分かりません。監視ツールが転送を追跡して最終レスポンスを判定するか、最初の応答しか見ないかを確認してください。Google Cloud Monitoringの公開uptime checkでは転送を追って最終レスポンスを成功条件に使う仕様が案内されています。
HTTPの転送とJavaScriptの画面遷移は異なる
301や302はサーバーがHTTPヘッダーで次のURLを案内する仕組みです。一方、ページに記述されたJavaScriptやmeta refreshによる移動は、最初に200でHTMLを返した後にブラウザーが移動する場合があります。
一般的なHTTPの転送追跡だけでJavaScriptの動作を再現できるとは限りません。本記事はサーバー側の301・302を中心とし、画面描画後の移動が必要な場合は別途ブラウザーベースの安全な検査を検討します。
301・302リダイレクト先で確認する6つの項目
転送先の監視では、初回の301・302、Location、最終到達URL、最終HTTPコード、転送回数、HTTPSや目的の内容をセットで確認すると問題の位置を絞りやすくなります。
| 確認項目 | 確認する情報 | 見逃しやすい問題 |
|---|---|---|
| 転送元 | 入口URLと初回301・302 | 旧URLからの転送設定ミス |
| Location | 次の移動先URL | 誤った転送先の指定 |
| 最終到達URL | 最終ドメインとパス | 別ページへ200で到達 |
| 最終HTTPコード | 200・404・503など | 転送後の公開先の不具合 |
| 転送回数 | 正常時との差・上限超過 | 余計な経由やループ |
| HTTPSと内容 | 方式、証明書、目的ページ | 平文への転送や画面の誤表示 |
1．転送元URLと最初のHTTPコード
まず利用者がブックマークや外部リンクから訪れる旧URL、httpのURL、wwwあり・なしなど、入口となるURLを特定します。そこで301・302を返すことが予定されているか明確にしておきましょう。
最初から新URLだけをチェックした場合、旧URLのルールが誤っていても気づきません。旧URLからの移動を維持する必要があるなら、入口のURLも管理対象として記録します。
2．Locationヘッダーが指定する次のURL
301・302のLocationには、次にアクセスする先が指定されています。絶対URLだけでなく、Location: /new/のような相対パスもあるため、元のURLを基準に解釈された実際の転送先を確認してください。
最初のLocationが正しい場合でも、その後に別の301や302が発生することがあります。入口の次のURLだけでなく、最後にどこへ到達したかも確認する必要があります。
3．最終到達URLのドメインとパス
転送を追跡した後のURLが、予定したホストとパスに一致するか確認します。例えば/contact/へ案内すべき古い問い合わせリンクが、トップページ/へ転送されても、最終コードは200となる場合があります。
ただし地域・言語・認証状態によって正しい転送先が複数あるサービスもあります。期待URLを単一の文字列に固定しすぎず、仕様に合わせて許容するドメインとパスの条件を決めます。
4．最終HTTPコードと失敗理由
最終ページで200が返れば、最後のHTTPリクエストに成功したことを示します。404や503、タイムアウトになれば、そのページの公開状態や接続経路に問題がある可能性があります。
最終コードだけでは、ログイン画面や保守ページに誤って移った場合を区別できないことがあります。最終URLと組み合わせ、必要なら内容も確認してください。
5．転送回数とループ
通常1回だった転送が急に3回や5回になった場合、https化やwww統一、CMSとCDNのルールの重複を調べる手掛かりになります。A→B→Aと行き来する設定では、最終ページまで到達できず追跡上限で停止する場合があります。
転送回数が多いことだけで障害とは断定できませんが、正常時との差と実際に経由したURLを確認しましょう。追跡上限を無制限にしてもループは解決しません。
6．最終HTTPSとページの内容
httpからhttpsへ移す予定なら、最後にhttpsのURLへ到達しているか、証明書の検証に問題がないかを確認します。途中でhttpへ戻る経路がある場合、意図したルールか確認することも重要です。
最終URLとHTTP 200が一致していても、JavaScriptや問い合わせフォームが正常とは限りません。画面の内容や操作の確認は200 OKでもサイトに不具合がある理由と役割を分けます。
301・302の後で見逃しやすい7つの異常
リダイレクト先の異常は、最終HTTPコードの失敗だけとは限りません。予定外のページへ200で到達する問題や、転送ループなどの到達失敗もあるため、典型的な事象を整理します。
| 最初の応答 | 転送後の状態 | 確認する項目 |
|---|---|---|
| 301 | 新ページが404 | 最終HTTPコード |
| 302 | 転送先が503 | 最終HTTPコードと保守予定 |
| 301 | トップページが200 | 最終URLのパス |
| 302 | 別ドメインが200 | 最終ホスト名 |
| 301→302→301… | ループで取得不可 | 転送回数と経由先 |
| 301 | 最終URLがhttp | 方式と証明書 |
| 302 | ログイン画面が200 | 最終URLと期待する表示 |
転送先が404でページが存在しない
旧URLが予定どおり301を返していても、移転先の公開が漏れたり、パスが間違っていたりすれば最後は404になります。最初の301だけを正常として数えると、この問題を見逃す可能性があります。
最終到達URLと404の発生時刻を記録し、公開先のCMS設定、公開状態、変更履歴を確認しましょう。元URLと新ページの問題を分けて調べることが重要です。
転送先が503やタイムアウトになる
転送元は302を返していても、メンテナンス用の転送先が503やタイムアウトとなることがあります。計画メンテナンスの一時的な応答か、予定外の障害かは対象と時刻を照合しなければ分かりません。
監視結果を一律に誤検知として処理しないでください。メンテナンス中の監視アラートでは、予定停止と障害の区別を説明しています。
最終200でも別ページへ誤転送される
古い問い合わせページから新フォームへ転送する予定なのに、誤ってトップページへ進む場合があります。どちらも最終コードは200となり得るため、200だけを成功と判定すると問題が分かりません。
意図しないURLの200は、転送先監視の典型的な落とし穴です。最終URLのドメインとパスを、台帳に残した期待URLと照合してください。
予定外の外部ドメインへ転送される
転送先のドメインを誤入力したり、設定が別のURLへ変更されたりすると、無関係なサイトへ移動する場合があります。外部サイトが正常な200を返しても、元のサイトの利用者にとって適切とは限りません。
最終到達ホストが管理上承認されたドメインか確認し、転送先へ認証情報などを渡さないよう注意してください。特に監視ツールの自動追跡には安全なアクセス先の制限が必要です。
転送ループが続いて最後のページを取得できない
/old/が/new/へ301、/new/が/old/へ302となると、同じ二つのURLを繰り返すループが起きます。ブラウザーや監視ツールではリダイレクトの上限を超えて停止する場合があります。
どのURLからどのURLへ戻っているかを確認し、CMS・サーバー・CDNのルールを調べます。追跡回数の上限を増やすだけでは根本原因を解決できません。
HTTPSからHTTPへ戻ってしまう
最初のURLがhttpsでも、途中のLocationがhttpを指定すると、最終的に暗号化されないURLへ到達する場合があります。意図しない転送ならセキュリティや利用者の信頼性に関わります。
転送経路、最終URLのスキーム、SSL証明書を確認し、正しいhttpsへ到達するかを調べてください。証明書の検証を無効化して失敗を隠すことは避けましょう。
ログイン画面や保守ページが200を返す
未認証ユーザーが会員ページからログイン画面へ302で案内されることは、仕様どおりの場合があります。しかし一般公開を予定したページで同じ転送が起きれば、アクセス制御の誤りを疑う材料になります。
最終URLと期待する内容を照合し、正当な転送か確認します。ログインや購入など実際の操作は、単純な公開HTTP監視とは別の検査が必要です。
リダイレクト元から最終到達先までの監視設定手順
転送元のURLを監視対象として記録し、転送追跡の有無と成功条件を確認します。そのうえで、最終HTTPコードだけでなく到達URLの一致や転送回数の変化を確認できる方法を選びます。具体的な設定項目は監視サービスによって異なります。
手順1：転送元URLと期待する最終URLを対応づける
例としてhttps://example.com/old/を転送元、https://example.com/new/を最終到達先と記録します。旧ドメインなら新ドメインへ、wwwなしの入口ならwwwありの正規URLへ、といった形で対応を明確にしてください。
ドメイン移転では、トップページだけでなく問い合わせやサービス案内など重要な旧ページも個別に確認します。旧URLごとにどこへ移動すべきかを残しておくと、予定外のトップページへの一括転送などを発見しやすくなります。
手順2：監視ツールが転送を追跡するか確認する
最初の3xxレスポンスだけを見る監視と、Locationの転送先を追跡して最終レスポンスを評価する監視は結果が異なります。監視サービスの設定説明で、リダイレクト追跡の有無、追跡上限、タイムアウト、SSL検証を確認しましょう。
Google Cloud Monitoringの公開uptime checkではHTTP/HTTPSの転送を追い、最終レスポンスを成功条件に使う仕様が案内されています。ただし、他製品も同じ動作とは限りません。
手順3：最終HTTPコードと最終URLを照合する
最終ページが200など予定したHTTPコードを返しているか確認し、同時に最終URLが想定したホスト・パス・httpsになっているか比較します。コードは200でもログイン画面やトップページへ誤転送されていることがあるためです。
最終URLの一致条件を自動で設定できない監視サービスの場合は、補助診断で表示された値と運用台帳の期待URLを人が比較する方法があります。表示できることと、その条件で自動的にアラートを発生させることは別の機能です。
手順4：転送回数の基準値と変更履歴を残す
正常時に1回だった転送が変更後に3回になった場合、HTTPS化やwww統一のルールが余計に重なっている可能性があります。変更前の最終URL、転送回数、確認日時を記録し、更新後に同じ入口から再確認しましょう。
転送回数が増えたことだけでエラーとは断定できません。途中のLocationと転送規則を調べ、予定した構成で説明できるかを判断してください。ループや上限超過で最終ページを取得できなかった場合は、その結果を成功として扱わないことが重要です。
手順5：設定変更後は別の条件でも再確認する
更新後の旧URLを一度開いて正常に見えたとしても、ブラウザーの301キャッシュやCDNの配信拠点によって、異なる転送先が表示される場合があります。同じURL・時刻・HTTPメソッドの条件で結果を比較し、必要なら別回線でも確認します。
ただし確認のために本番のDNSやCDN設定を無断で変更してはいけません。監視の結果とサーバーログなどを照合し、権限のある担当者が必要な修正を判断してください。
最終到達先の異常を監視履歴のサンプルで確認する
以下は架空の旧URLhttps://example.com/old/を監視したという説明用の記録です。実際のエンリンクの管理画面や保存データを再現したものではありません。同じ初回301でも、その先の結果が異なる点に注目してください。
| 時刻（JST） | 初回応答 | 最終到達先 | 最終結果 |
|---|---|---|---|
| 10:00 | 301 | https://example.com/new/ | 200・想定どおり |
| 10:05 | 301 | https://example.com/new/ | 404・公開先エラー |
| 10:10 | 301 | https://example.com/ | 200・誤転送 |
| 10:15 | 302 | https://example.com/login/ | 200・目的と照合 |
| 10:20 | 301→302→301… | 取得できない | 転送ループ・上限超過の疑い |
| 10:25 | 301 | https://example.com/new/ | 200・再び正常を観測 |
10:05の301と404を分けて読む
10:05には旧URLから301が返っていますが、移動した先は404でした。転送の指示自体は機能しても、公開先が見つからなければ利用者は目的のページを使えません。
公開先のパスが変更されたのか、CMSのページが非公開になっていないか、権限や公開環境が変わっていないかを調べます。初回301だけを確認した記録から最終ページの正常性を推測しないようにしてください。
10:10の200は「正しくない場所への成功」
10:10にはトップページが200を返しています。しかし想定しているのは/new/であるため、転送先が変わったこと自体は異常の可能性があります。
「200だから正常」と判定してしまうと、問い合わせや申込への旧リンクが壊れていても気づかないことがあります。転送後の最終URLを期待するパスと照合することが重要です。
10:15の302とログイン画面は目的次第
ログイン必須の会員ページが302でログイン画面へ誘導されるのは正常な仕様の場合があります。逆に誰でも閲覧できるはずのページで同じ現象が起きたら、アクセス制御の誤りが疑われます。
単に最終200を成功とするのではなく、URLの用途と未認証利用者への期待動作を確認しましょう。認証後の操作や画面の検証は、単純なHTTP監視とは別の安全な検査が必要です。
10:20は最後まで到達できなかった記録
ループや上限超過によって最終ページが取得できなければ、最後のHTTPコードやURLが確定しない場合があります。途中の301・302を理由に成功とするのではなく、追跡が完了しなかった事実として区別します。
転送元と途中のLocationを並べ、同じURLへ戻っていないか調べます。途中のURLで証明書の検証やDNS解決が失敗していないかも必要に応じて確認してください。
curlでLocationと最終到達URLを確認する方法
curlはHTTPリクエストを使って、初回の転送指示と追跡後の結果を調べる際に役立ちます。ここでは管理権限のある公開URLを対象に、状態変更のないGETで確認する例を示します。コマンドは実行せず、仕様を説明しています。
最初の301・302とLocationを確認する
初回レスポンスだけを見るコマンド例は次のとおりです。
curl --silent --show-error --dump-header - --output /dev/null https://example.com/old/curlは通常--locationを指定しなければリダイレクトを追わず、初回のHTTPコードやLocationを確認できます。
この操作で確認できるのは、最初にサーバーが返した転送指示です。最後のページが200になるかは分からないため、転送を追跡する次の確認を行います。
転送を追って最終URL・コード・回数を確認する
追跡後のURL、最終HTTPコード、転送回数を表示するコマンド例です。
curl --silent --show-error --location --max-redirs 5 --output /dev/null --write-out 'final=%{url_effective} status=%{http_code} hops=%{num_redirects}' https://example.com/old/ポイントはstatus=200だけではなくfinal=を確認することです。hops=が増えた場合は転送規則を調べます。またcurl自体がエラー終了した場合は、取得できなかった結果を200へ置き換えないでください。
経由先を調べる場合は各レスポンスを確認する
--locationと--dump-header -を組み合わせると、追跡中のレスポンスヘッダーも確認できます。どのLocationで意図しないホストへ移ったのか、どこで同じURLへ戻っているのかを調べる手掛かりになります。
ただし転送先が外部ドメインになる場合やURLにトークンがある場合、アクセス範囲と情報の扱いに注意してください。第三者サイトへの継続的な監視や、大量の自動リクエストは行わないようにします。
HEADとGETは同じ結果とは限らない
curl --headで実行するHEADと、通常のブラウザー閲覧で使うGETは別のHTTPメソッドです。サーバーやCDNの実装によっては、HEADとGETでリダイレクトや最終応答が異なる場合があります。
利用者の通常の閲覧経路を確認するなら、まずGETを基準に結果を読みます。curlではJavaScriptの実行やブラウザー上の描画結果まで確認できないことにも注意してください。curl公式のコマンドオプションを参照できます。
ドメイン移転・HTTPS化・URL変更後に確認すること
サイト移転やリニューアルでは、新しいURLが正常でも、古いURLからの転送に不具合が残る可能性があります。旧URLと期待する新URLの対応を整理し、作業後の転送経路を点検しましょう。
旧URLと新URLの対応表を作成する
企業サイトの移転では、旧トップページから新トップページだけでなく、旧問い合わせ入口から新問い合わせ入口、旧サービス案内から新サービス案内などを確認します。すべての旧URLを新しいトップページへ転送する方法が適切とは限りません。
利用者が古いリンクから必要な情報に進めるかを判断するため、転送元と最終URLを対応表にまとめます。関連する担当者や保守会社へ確認できるよう、更新日と確認結果も残しておくと役立ちます。
HTTPからHTTPSへの転送とwww統一を確認する
http://example.com/からhttps://www.example.com/へ移す構成では、HTTP→HTTPSとwwwなし→wwwありの転送が組み合わさることがあります。転送経路が想定どおりか、最後にhttpsで目的のホストへ到達するか確認します。
転送回数が急に増えた場合、サーバーとCMS、CDNに設定したルールが重なっていないか確認しましょう。ただし転送回数だけで原因を確定せず、実際の各ホップと変更履歴を照合してください。
恒久的な301と一時的な302は目的に合わせる
恒久的なURL移転なら301や308、一時的な移動なら302や307が候補になります。Google検索セントラルは、転送の永続性によって検索システムへ伝える意味が異なることを説明しています。
ただしこの記事の主題はSEOの正規化全般ではなく、設定した転送先が実際に正しく応答するかの確認です。HTTP監視だけで検索結果へのインデックス反映や順位を保証することはできません。
キャッシュや確認地点の違いを考慮する
301はブラウザーやCDNのキャッシュの影響を受けることがあり、同じURLでも確認する環境によって古い転送先が残る場合があります。検査した日時と利用環境を揃え、違いがあれば記録してください。
一度200へ到達できたとしても、すべての利用者に同じ結果が返るとは限りません。必要なら別回線や監視地点の違いを検討し、設定変更は権限を持つ担当者が判断します。
転送先監視で注意する安全性と運用の落とし穴
リダイレクトの追跡では、監視対象として登録したURLと異なるドメインへアクセスする場合があります。監視が正確に動くことだけでなく、転送先の権限や情報の扱い、安全なアクセス範囲を確認する必要があります。
許可のない外部URLへ継続的なアクセスを行わない
自社サイトから別会社のサイトへ転送される設定を確認するときは、その転送先が正当な管理対象か確認してください。外部のサイトやAPIに許可なく多数のリクエストを送ると、相手側の運用に影響する可能性があります。
自作の監視サービスで利用者が任意のURLを指定できる場合、リダイレクト先が内部ネットワークや管理用のエンドポイントへ向くSSRFの危険があります。OWASPのSSRF対策資料にあるように、転送先のURL・接続先IPを含む検証と権限制限が必要です。
認証情報や個人情報を含むURLを監視へ使わない
ログイン用トークン、ワンタイムURL、顧客IDなどがURLに含まれると、監視サービスの履歴や転送先のアクセスログへ情報が残る場合があります。認証や個人情報を含むURLを安易に定期監視へ登録しないでください。
アクセスすると購入・予約・送信などの状態が変化するURLも、通常のHTTP監視には適していません。原則として管理権限があり、安全な公開GETで取得できるページを対象とし、操作が必要な確認は別の許可された検証方法を検討します。
最終200だけでは画面や機能の正常を保証しない
最終URLが合っていてHTTP 200を返しても、HTMLの本文が空欄になっている、JavaScriptのエラーで画面が表示されない、問い合わせフォームが送信できないなどの問題は起こり得ます。外部HTTP監視だけで確認できるのは設定された観測条件の範囲です。
画面内容や重要な機能を確認する必要がある場合は、対応する安全なコンテンツ検査やブラウザーベースの確認を使います。本記事では転送経路の正常性へ絞り、200 OKでもサイトに不具合がある理由と役割を分けます。
短時間の転送異常は監視間隔によって見逃す場合がある
転送設定が一時的に誤っていても、次のチェックが実行される前に修正されれば、その異常が監視履歴に記録されないことがあります。成功したチェックの割合が高いことは、監視を実行していない時間まで正常だった証明にはなりません。
断続的な転送ミスが疑われる場合には、Webサイトが時々落ちる原因と同じく、利用者が問題に遭遇した時刻、サーバーの設定変更、監視結果を突き合わせましょう。
エンリンクでリダイレクト先と転送回数を確認する
エンリンクの現行公式機能一覧には、HTTP/HTTPSの定期監視に加えて、補助診断でリダイレクト回数、最終到達URL、到達URLの変化を確認できることが記載されています。ここでは公開説明から確認できる機能に限って案内し、独自の監視条件を自由に設定できるなどの未確認機能を提供済みとは書きません。
補助診断で最終到達URLと転送回数を確認できる
エンリンクの公式機能一覧には「リダイレクト先・転送回数」の機能が案内されています。HTTPからHTTPSへの転送を含む回数と、最終到達URLを表示するものです。転送設定の更新後、目的のページへ到達できているか確認する手掛かりになります。
また、接続先IPや最終到達URLについて以前の結果から変わったかを比較する補助診断も説明されています。ただし、これらの情報が画面に表示されることと、変更が起きた瞬間に自動で通知することは別です。
HTTP監視と補助診断の目的を区別する
エンリンクのHTTP/HTTPS定期監視では、チェックの日時・結果・HTTPコード・応答時間などを履歴として確認できます。一方、最終到達URLや転送回数は補助診断に分類されています。異常を見つけた場合も、両者の情報の役割を混同しないことが重要です。
通常のHTTP監視が各中間レスポンスのLocationをすべて保存するか、最終URLが期待URLと一致することを成功条件にしているかは、公式機能一覧から断定できません。監視画面が正常でも、最終到達URLが予定どおりか別途確認すべき場面があります。
最終URLの自動一致判定や転送回数のアラートは未確認
現行の公開機能一覧では、任意の最終URLの一致条件や、転送回数のしきい値で警告を出す設定、転送経路すべてのホップの保存について、提供を確認できません。これらの機能がある前提で具体的な操作手順を案内することは避けます。
到達先を定期的に確認する場合には、補助診断に表示された最終到達URLと期待するURLを台帳で比較する方法が考えられます。自動通知が必須であれば、それに対応した別の許可された監視手段が必要かを検討してください。
無料枠と監視頻度は料金プランを確認する
2026年10月24日時点の公式料金プランでは、無料は最大5サイト・1日2回、スタンダードは最大20サイト・最短15分、ビジネスは最大50サイト・最短5分、プロは最大100サイト・最短1分の定期監視が案内されています。これらは設定可能な間隔であり、転送先の変更を必ず一定時間以内に検知できる保証ではありません。
エンリンクの無料登録ではサイト管理と監視から始められます。ただし、同一サイトの複数の転送元URLをどのような登録単位で扱えるかについては、現行の管理画面と利用条件を確認する必要があります。
301・302リダイレクトの監視についてよくある質問
転送元の301・302、最後のHTTPコード、転送先URLはそれぞれ違う意味を持ちます。よくある疑問を、確認できる範囲と監視の目的を分けて整理します。
301が出ていれば転送先も正常ですか？
正常とは限りません。301は恒久的な転送を指示したことを示し、転送先が404や503となることがあります。追跡後の最終HTTPコードとURLを確認してください。
また最終200でも目的と違うページへ移動することがあるため、最後に到達したホスト・パスも確認する必要があります。
302は監視エラーとみなすべきですか？
一律には言えません。一時的な転送が正常な仕様なら、302自体は意図どおりの動作です。ログイン画面への誘導などの場合、最終到達URLと未認証利用者の期待動作を確認します。
ただし本来は恒久的な移転を案内するべきURLであれば、301や308などの利用を検討する余地があります。コードの選択と、転送先が実際に使えるかという監視は別の確認です。
最終HTTPコードが200なら確認は完了ですか？
完了とは限りません。転送先のホストが違う、トップページへ移っている、ログイン画面になっているなどの場合も200が返ることがあります。最終到達URLを予定したURLと照合してください。
さらに最終ページの内容や重要操作が正常かは別のテストが必要になる場合があります。HTTPコードの成功範囲を明確にして説明しましょう。
リダイレクトループはどうやって調べますか？
転送回数が異常に増えた場合や追跡上限エラーが出た場合に、途中のLocationと経由URLを調べます。同じ二つのURLを交互に行き来しているなど、ルールの競合が見つかることがあります。
curlでは--locationと--max-redirsで追跡回数を制限できます。無制限に追跡すれば解決するわけではなく、転送規則自体の確認が必要です。
旧URLと新URLはどちらを監視すべきですか？
目的が異なります。旧URLを起点にすると、既存のリンクを踏んだ利用者が正しいページへ移動できるか確認できます。新URLを直接確認すると、現在の公開先自体が応答するか調べられます。
利用者影響の大きいURLを優先して検討し、監視サービスの登録可能件数やURLの単位と合わせて管理してください。
HTTPからHTTPSへ転送すればSSLも正常ですか？
転送指示が返っただけでは、最終到達先で安全なHTTPS接続が成功したことまでは分かりません。最終URLがhttpsであるか、証明書検証に問題がないかを確認してください。
証明書が期限切れや別ホスト向けであれば、転送先の取得が失敗する可能性があります。問題を隠すためにSSL検証を無効化するべきではありません。
HEADとGETで転送結果は必ず同じですか？
必ず同じとは限りません。サーバーやCDN、独自の転送ルールによってはHEADとGETで挙動が異なることがあります。通常の公開ページ閲覧に近いGETで確認することが基本です。
監視サービスがどのHTTPメソッドを用いているかも確認し、ブラウザーで再現する現象と監視の条件が違っていないか整理してください。
エンリンクは最終転送先の変化で自動通知しますか？
公式の機能一覧には、最終到達URL・リダイレクト回数・到達URLの変化の補助診断が記載されていますが、自由な最終URL一致条件による自動通知が提供されていることまでは確認できません。
最終URLの変化を確認したい場合は、現行の管理画面で表示される情報の範囲を確認し、必要なら作業台帳と照合する方法を検討してください。
まとめ：転送元・最終URL・最終HTTPコードの3点から確認する
301・302リダイレクトを監視する場合は、転送元が予定した応答を返すことと、利用者が最終的に目的のページへ着けることを区別します。初回301が正常でも最後に404となる場合や、最終200でも誤ったページへ進む場合があります。
転送経路と最終到達先を合わせて記録する
転送元URL、Location、最終到達URL、最終HTTPコード、転送回数をセットで確認し、変更前の期待結果と比較しましょう。HTTPSの状態や必要なページ内容の確認も、目的に応じて追加してください。
移転やリニューアル後は旧URLと新URLの対応を定期的に見直すと、古いリンクからの到達失敗に気づきやすくなります。監視した時刻と実際の利用者の体験がすべて一致するわけではない点にも注意します。
エンリンクの補助診断とHTTP履歴を使い分ける
エンリンクの現行機能には、リダイレクト回数・最終到達URL・到達URLの変化の補助診断と、HTTP/HTTPSの監視履歴が案内されています。期待した転送先へ着いているか確認する手掛かりとして使えます。
エンリンクは最大5サイトまで無料で利用開始できますが、最終URLを自由に指定して自動通知する機能があるとは断定できません。まず自分が管理するサイトの転送元と最終URLを整理し、公開された機能の範囲で確認してください。
参考にした一次資料：Google検索セントラル「リダイレクトとGoogle検索」、MDN「301 Moved Permanently」、MDN「302 Found」、Google Cloud「Create public uptime checks」、curl「コマンドラインオプション」、OWASP「SSRF Prevention」（確認日：2026年10月24日）。
