Free redirect mapper and migration checklist

How to use the redirect mapper

Paste the old URL list in one box and the new URL list in the other. The matcher scores exact path matches first, then matching slugs, then token similarity. High-confidence rows are pre-approved. Amber rows need a human. Unmatched rows need a decision: find a destination or accept a 404.

Turn on ignore query, trailing slash, and case when your old and new hosts disagree on those details. If the tool spots a date-folder pattern such as /blog/2022/11/slug/ moving to /blog/slug/, apply that pattern before you export.

Export CSV for a spreadsheet review, or export Next.js, Vercel, Netlify, Apache, or Nginx rules when the map is approved. Collapse chains inside the map so A to B to C becomes A to C before you ship.

How to use the chain checker

After launch, paste the old URLs you care about most. The checker follows redirects and reports clean single 301s, chains, temporary redirects, loops, wrong destinations, homepage dumps, and hard errors. Ten chain runs a day is the free limit. Use it on the top traffic and top linked URLs first.

A chain is not always a disaster on day one, but it should not be the plan. Collapse to one permanent hop. A 302 on a permanent move keeps the old URL in play longer than you want. A redirect to the homepage for a deep page can look like a soft 404.

Website migration SEO checklist

The checklist has three phases: before launch, launch day, and the first weeks after. Before launch is where most of the work belongs. Benchmark traffic, crawl the old URL set, protect staging from the index, build the map, and move titles and schema with the content.

Launch day is short: remove staging blocks, deploy redirects, test the top URLs, submit the sitemap, and confirm robots.txt and canonicals on the live host. After launch, watch Search Console coverage, fix 404s that matter, and keep redirects in place for at least a year.

Tick items in the browser. Progress is stored locally for this device. Use the linked tools from each item when you need a check, not a theory.

301 vs 302 and how long to keep redirects

Use 301 for a permanent move. Use 302 only when the move is temporary and you expect the old URL to come back. Keeping permanent redirects for at least a year is a safe default. Longer is better when external links still point at the old paths.

Do not redirect everything to the homepage. That trains search engines that the destination is weak. Match the closest relevant page, or return a real 404 for junk URLs that never deserved a home.

What a clean migration looks like

URL structure stays the same where it can. Money pages keep their titles and headings. Internal links point at final URLs, not through a hop. The sitemap lists new URLs. robots.txt is not still blocking the live site. Analytics still fires.

Expect some volatility. Nothing on this page promises zero loss. A clean map and fast fixes after launch reduce the damage. Pair the chain checker with the SEO checker on a sample of money pages in the first week.

• Full old URL list before cutover
• Reviewed redirect map with no silent homepage dumps
• Staging blocked, then unblocked on the live host only
• Internal links and sitemap on final URLs
• Top URLs verified with the chain checker on launch day

Export formats and when to use them

CSV is for review with a second person. Next.js and Vercel exports suit this stack. Netlify _redirects is for Netlify hosts. Apache Redirect lines and Nginx map blocks are for traditional servers. Always re-test after deploy. A config that looks right in a file can still miss a trailing slash rule on the edge.

If your platform has a bulk redirect UI, upload CSV there and still run the chain checker afterward. The source of truth is the live response, not the spreadsheet.

Launch week habits that save traffic

Export the top landing pages and the strongest linked URLs before you cut over. Those two lists are the chain checker queue on launch day. Everything else can wait an hour. Those cannot.

Keep a copy of the old sitemap. After launch, fetch a sample of those URLs and confirm they 301 to the right place. If they 404, fix before you announce the redesign on social channels.

Watch Search Console coverage for spikes in not found and redirect errors. A rising 404 count on URLs that used to rank is a map problem, not a content problem. Open the mapper, add the missing rows, redeploy, and re-test the chain.

Update internal links in the CMS, not only the redirect table. Nav, breadcrumbs, body links, and XML sitemaps should speak the new paths. Redirects are a safety net for the outside web, not an excuse to leave the new site pointing at itself through hops.

If marketing insists on a homepage dump for “legacy blog noise,” push back on anything that ever earned links or conversions. Soft 404 patterns teach Google the destination is thin. Match a relevant section page or keep a real 404.

Temporary redirects show up as temporary in the chain checker. Swap them to 301 when the move is permanent. Leaving 302s “to be safe” often keeps the old URL in the index longer than the project plan assumed.

Domain moves need Change of Address in Search Console after redirects work. Same-domain redesigns do not. Using the wrong tool creates noise. The checklist calls this out on launch day for a reason.

Speed regressions look like SEO failures. Run the SEO checker on key templates after launch. If LCP collapsed because of a new hero video, fix that in parallel with redirect cleanup. Do not blame the map for a theme problem.

Keep the redirect rules in version control when you can. When traffic dips two weeks later, you want a diff. A one-line bad rule is easier to find when yesterday’s file still exists.

I leave permanent redirects in place for at least a year. Bookmarks and PDFs die slowly. Removing a working 301 early to “clean the config” is how old links become 404s again.

When a merge from the cannibalization checker needs a redirect, export that single rule through this mapper and test it in the chain tab. Content fixes and technical fixes belong in the same week when two URLs become one.

If the new site changes CMS hosts mid-project, re-export the map from the approved CSV rather than rewriting rules by hand in two panels. One source of truth beats a Netlify file and a Next config that drifted overnight.

I treat unmatched rows as a decision queue, not a failure of the matcher. Some old URLs deserve a 410 or a clean 404. Mark those outside the export so nobody “helpfully” points them at the homepage later.

Types of moves change the risk. A redesign on the same URLs is mostly content and speed. A platform change often renames paths. A domain change needs Change of Address after redirects work. HTTPS-only moves are usually simple if every http URL 301s once. Structure renames need the fullest map.

A normal post-launch dip can last days while Google recrawls. A real problem looks like rising 404s on money URLs, a robots block, or canonicals still pointing at staging. Fix those before you rewrite the content calendar.