Bulk redirect checker for site migrations

What a redirect map is, and why a migration needs one

When a site moves to a new domain, a new platform or a new URL structure, every old address needs to send visitors and search engines to its new equivalent. The redirect map is the list that says which old page goes where: /blog/2019/hello-world to /blog/hello-world, old.example.com/shoes to example.com/shop/shoes, and so on for every page that had traffic or links.

Getting it right is most of what decides whether a migration keeps its search traffic. Search engines have to discover each redirect, trust it and move the old page's signals to the new one. A map that sends pages to the wrong place, to the homepage or into a 404 throws those signals away, and the drop usually shows up weeks later, when it is harder to trace.

Why one 301 hop matters

The goal for each row is simple: the old address answers 301 (or 308), and the address it points to answers 200 with the right page. One permanent hop.

Chains creep in during migrations because rules stack up. The old http address goes to https, then the new domain, then the new path, then a version with a trailing slash. Each rule is right on its own; together they make four hops. Every hop is another round trip for visitors, every crawl of the old address costs more, and Google's documentation says Googlebot follows at most 10 hops. Fix it by pointing each old address at its final destination directly.

Temporary redirects (302 and 307) are the other common slip. Some platforms create them by default. A migration is permanent, so the redirect should say so.

How to read the verdicts

• Right page, one 301: done. The old address reaches the expected page in one permanent redirect.
• Right page, extra hops: it gets there, but through a chain. Shorten it.
• Right page, temporary: it gets there with a 302 or 307. Change it to a 301.
• Wrong page: it redirects, but somewhere else. Often the homepage, a category page, or an older version of the map.
• Broken: it loops, never arrives, or the target answers 404, 410 or a server error.
• Not redirecting: the old address still loads its own page, or returns 404 with no redirect at all.
• Couldn't check: the site refused our automated request (403 or 429) or didn't answer in time. Check those by hand.

We compare addresses exactly, apart from the case of the domain name. When the only difference is a trailing slash or a query string, the row still counts as the right page and the note says so, because that's usually a detail of how the new site writes its URLs rather than a wrong target.

Formatting your list

Each line needs the old address first and the new address second, separated by a comma, a tab or an arrow (->). Copying two columns out of Excel or Google Sheets gives you tabs, which works. A header row like "old,new" is skipped automatically, and so are blank lines and lines starting with #.

Addresses can be full URLs, bare domains (we add https://), or paths like /old-page. If the old addresses are paths, add your website in "Website for paths". New addresses written as paths are read as being on the same site as their old address. Any line we can't read is listed with its line number, so you can fix it before checking.

What this check doesn't cover

It checks the rows you give it. It can't tell you which old pages are missing from the map; for that, compare the map with an export of your old sitemap, your analytics' landing pages and Search Console's list of indexed pages. The lost URL finder can also surface old addresses from the Wayback Machine that now return 404.

It also checks from one server, at one moment. Run it again after the redirect rules go live, and once more a few days later, because caches and CDNs sometimes serve the old behaviour for a while.