First CH Apps / 301リダイレクト対応表チェッカー
サイトリニューアルやドメイン移転で作る「旧URL → 新URL」の対応表を貼ってください（最大20組）。旧URLを1組ずつ実際に追跡し、最後にたどり着いたURLが新URLと完全に一致するかを判定します。合否と件数の集計を出し、結果はCSVでコピーできます。
1本のURLの転送を段ごとに詳しく見るなら「リダイレクトチェーン追跡」、URLの一覧のステータスと最終URLを並べるなら「HTTPステータス一括チェック」が向いています。どちらも、期待した転送先と一致しているかまでは判定しません。このページは、その一致を対応表の行ごとに確かめます。
合格になるのは、旧URLから転送をたどって最後に着いたURLが期待URLと完全に一致し、そのページが200を返したときだけです。http と https、www の有無、末尾のスラッシュが違うだけでも合格にはせず、「不一致（差分あり：…）」として差の種類を示します。
1回目の転送が302・303・307のときは一時リダイレクトとして注意を出します。転送が2回以上つながっている（チェーン）ときも注意を出します。どちらも、最終到達URLが一致していれば合否は合格のままです。
転送のループ、旧URLが200を返したまま転送されていない状態、旧URLの404・410、転送先が200以外を返す状態は不合格です。
取得できなかった行・転送が上限（5回）に達した行・1回の通信回数の上限に達した行は、不合格ではなく「未検査」として分けて数えます。
追跡するのはHTTPの転送（301・302・303・307・308）だけです。meta refresh や JavaScript による転送は見ません（1本のURLで確かめるなら「リダイレクトチェーン追跡」をお使いください）。
送るもの: 貼り付けた対応表（旧URLと新URL）だけです。当社サーバー（Cloudflare Workers）が旧URLを公開GETで取得し、転送を1段ずつたどります。新URLは比較に使うだけで、取得しません。Cookieもログイン情報も送りません。
保存するもの: ありません。チェックはリクエストの中だけで完結し、対応表も結果もデータベース（KV/D1）へ書き込みません。処理が終わった時点でメモリから消えます。ログイン・登録もありません。連続実行の制限のために、送信元IPごとの回数を1分間だけメモリ上で数えます（保存はしません）。
返すもの: 各組の合否、たどった経路のステータスとURL、差の種類だけです。取得したページの本文は1バイトも読まず、再配信もしません（このアプリを経由して他サイトを閲覧することはできません）。
注意: 社内ネットワーク・localhost・プライベートIP宛のURLは取得しません。転送の途中でそうした宛先へ向かう場合も、そこで追跡を止めます。
POST /redirect-map/api/check に JSON（{"from": "https://old.example.com/a", "to": "https://www.example.com/a/"}）を送ると、1組の判定結果が JSON で返ります。対応表の解析だけなら POST /redirect-map/api/parse に {"table": "…"} を送ります（最大20組・通信はしません）。連続実行はIPごとに1分あたり60組までです。
Google 検索セントラルのサイト移転ガイドは、移転の準備として旧サイトのURLを新サイトのURLに対応付けておくことを勧めています。そのうえで、対応表どおりに旧URLから新URLへサーバー側の恒久的なリダイレクト（301や308など）を設定するよう案内しています。多くの旧URLを新サイトのトップページのような関係のない1つのURLへまとめて転送することは避けるよう書かれており、移転後には転送が意図どおりかを確かめることも求めています。対応表を先に作っておけば、この確認を行ごとに機械的に進められます。