First CH Apps / 301 Redirect Map Checker
Paste the old URL → new URL map you prepared for a relaunch or domain move (up to 20 pairs). We follow every old URL for real and check whether the URL it finally lands on matches the new URL exactly. You get a pass/fail per row, totals, and a CSV you can copy.
To inspect one URL hop by hop, use the Redirect Chain Tracer; to list status codes and final URLs for many URLs, use the Bulk HTTP Status Check. Neither checks whether a redirect lands on the destination you intended. This page checks exactly that, row by row of your map.
A row passes only when the URL reached after following the redirects matches the expected URL exactly and that page returns 200. A difference in http vs https, www, or a trailing slash alone is not a pass; we report “Mismatch (differs in: …)” and name the kind of difference.
If the first redirect is a 302, 303 or 307 we add a note that it is temporary. Two or more redirects in a row (a chain) also get a note. Neither changes the verdict if the final URL matches.
A redirect loop, an old URL that still returns 200 without redirecting, an old URL that returns 404 or 410, and a destination that returns anything other than 200 are failures.
Rows we could not fetch, rows that hit the redirect limit (5), and rows that ran out of the per-request connection budget are counted separately as “not checked”, not as failures.
Only HTTP redirects (301, 302, 303, 307, 308) are followed. Meta refresh and JavaScript redirects are not (use the Redirect Chain Tracer to inspect a single URL).
Sent: only the map you paste (old and new URLs). Our server (Cloudflare Workers) fetches each old URL with a public GET and follows its redirects one step at a time. New URLs are only compared, never fetched. No cookies and no credentials are sent.
Stored: nothing. Each check lives entirely inside one request and writes neither the map nor the results to any database (no KV, no D1). It leaves memory when the request ends. There is no login and no account. To limit rapid repeat runs we count requests per IP in memory for one minute (never stored).
Returned: the verdict for each pair, the status and URL of each step on the route, and the kind of difference. We never read the page body (not one byte) and never re-serve it — this app cannot be used to browse other sites through us.
Note: URLs pointing at internal networks, localhost or private IPs are never fetched. If a redirect heads to one mid-route, we stop there.
POST /redirect-map/api/check with JSON ({"from": "https://old.example.com/a", "to": "https://www.example.com/a/"}) and you get the verdict for that pair back as JSON. To only parse a map, POST {"table": "…"} to /redirect-map/api/parse (up to 20 pairs; no network access). Repeat runs are limited to 60 pairs per minute per IP.
Google Search Central’s site-move guide recommends mapping your old site’s URLs to the URLs on the new site as part of preparing the move. It then advises setting up server-side permanent redirects, such as 301 or 308, from each old URL to the new one you mapped. It warns against redirecting many old URLs to one irrelevant destination such as the new home page, and asks you to check after the move that the redirects work as intended. With the map written down first, that check becomes a row-by-row routine.
Talk to us about a site relaunch or domain move (First CH web production)