URL Migration Checker

Moved a site? Paste your old and new URLs and find out which redirects are actually working permanent, direct, and landing where you meant them to.

Up to 20 rows. Leave off the new URL to just check where an old one lands.

What goes wrong in a migration

A migration rarely fails loudly. The site works, the pages load, and the traffic drops over the following weeks for reasons that are hard to attribute. These are the four causes, in the order they usually turn out to be responsible.

The redirect is a 302

Visitors arrive fine. Search engines read "temporary", keep the old URL indexed, and leave the ranking signals where they were. Frameworks and hosting panels default to 302 far more often than people expect.

It lands somewhere valid but wrong

A catch-all rule sends every unmatched old URL to the homepage. Nothing errors, so nothing gets noticed, and every one of those pages has lost its specific relevance.

No redirect at all

The old URL still serves a page. Now two addresses hold the same content and compete with each other, splitting the links pointing at them.

The chain grew

Old → interim → new, because a second migration was layered on the first. It works, and it costs a round trip on every visit and every crawl.

After the redirects check out

Submit the new URLs so the participating engines re-crawl them promptly. Submitting the old ones achieves nothing. The redirect already tells the engine where to go.

Submit the new URLs Bulk status check

Frequently asked questions

What does this actually check?
For each old URL it follows the redirect chain by hand, keeping every status code, and compares where it ends up against the destination you expected. That gives four things a single status check cannot: whether the redirect exists at all, whether it is permanent or temporary, how many hops it takes, and whether it lands where you intended rather than merely somewhere valid.

Why does a 302 matter if the visitor ends up in the right place?
Because a 302 tells search engines the move is temporary, so they keep the old URL indexed and leave the ranking signals attached to it. Visitors notice nothing; your search traffic quietly fails to transfer. On a migration, almost every redirect should be a 301 or a 308. This is the most common reason a technically successful migration loses traffic.

Are redirect chains a real problem?
They are a small, avoidable cost rather than a disaster. Each extra hop is another round trip for the visitor and another request the crawler spends on you, and long chains risk being abandoned. If your rules produce old → interim → new, point the old URL straight at the final destination.

What does "still returns 200" mean in the results?
That no redirect is in place. The old URL is serving a page directly. Either the redirect was never added, or the old page is still live alongside the new one, in which case the two are now competing for the same query and splitting whatever links point at them.

How many URLs can I check at once?
Twenty rows per batch on the free tool. That is a deliberate limit rather than an arbitrary one: this runs on Cloudflare Workers, each redirect hop costs an outbound request, and the platform caps how many one invocation may make. Rows the budget could not reach are returned marked as unchecked rather than quietly dropped.

Should I submit the new URLs to IndexNow after a migration?
Yes, once the redirects are verified. Submit the new destinations, not the old URLs. An IndexNow submission is a request to crawl a specific address, and pointing it at a redirect just spends a request teaching the engine something the redirect already says.