Site Launch and Migration Link Checklist
A before-and-after checklist for anyone shipping a redesign, platform move, or domain change, covering the URL inventory, the redirect map, the staging crawl, the sitemap, and the checks that prove the links still work once the switch flips.
Reviewed for 2026, updated September 8, 2026.
Most link damage from a launch or migration is not caused by the move itself. It comes from the steps that were skipped around it: nobody exported the full list of old URLs, the redirect map was written from memory, the staging site was never crawled, and the first full audit happened a month later when the traffic drop showed up in a report. This checklist collects the confirmations that prevent that, in the order the guide on this site recommends. It starts with an honest inventory of what exists today, moves through the redirect map and the staging crawl, and ends with the same-day and two-week checks after the site goes live. Every line is something one named person can tick off rather than assume.
Print it or paste the lines into the task tool your team already uses, and work through it in two passes: once in the week before the switch, and again on launch day with the live site in front of you. For the thinking behind the pre-launch lines, read our pre-launch link checklist article at /blog/pre-launch-link-checklist/, and for the after-launch lines, the post-migration audit article at /blog/post-migration-audit/. If you want to show a stakeholder what a two- or three-hop chain costs on every visit, the Redirect Chain Latency Calculator at /tools/redirect-chain-latency/ turns hop count and traffic into a monthly number. The complete guide at /guide/ ties all of it together.
- Export a complete list of live URLs from the current site: crawl output, sitemap entries, and every page with traffic in analytics over the last year, merged into one inventory.
- Mark every URL in the inventory as keep, move, or retire, with the new address written next to each one that moves.
- Write the redirect map as one row per old URL pointing straight at its final destination, never at another redirect.
- Decide the status code for each rule: a permanent 301 for moves that will not be undone, a temporary 302 only where the old address will come back.
- Give retired pages with no replacement a deliberate 404 or 410 and a helpful not-found page, not a blanket redirect to the home page.
- Test the redirect rules on a staging copy against the full inventory and confirm that each one resolves in a single hop.
- Crawl the staging site with the same crawler you will use afterward so the before and after reports can be compared line by line.
- Update internal links in navigation, footers, and templates so they point at final URLs instead of relying on redirects.
- Search page content, buttons, and image sources for hard-coded links to the old domain or old paths.
- Check canonical tags, hreflang tags, and pagination links on the staging site for old addresses.
- Regenerate the XML sitemap with only final URLs, then confirm every URL in it returns a 200.
- Confirm the staging robots.txt and any noindex tags will not carry a blanket block into production.
- Keep a copy of the old site's crawl, sitemap, and top pages report so there is a baseline to compare against.
- Schedule the switch for a low-traffic window with the developer available to roll back or patch redirect rules.
- Within an hour of going live, spot-check by hand the home page, top landing pages, contact and conversion pages, and a sample of redirects.
- Run a full crawl of the live site the same day and compare the broken, redirecting, and error counts against the staging baseline.
- Request every URL from the old inventory and confirm it lands on the mapped destination with a single hop and the intended status code.
- Watch the 404 report in analytics and the server logs daily for the first two weeks, and add redirect rules for any old URL that keeps getting hit.
- Resubmit the sitemap in the search console tools you use and check the crawl error reports again after a few days.
- Update the external references you control: social profiles, email signatures, ad landing pages, directory listings, and partner links.
- Put a follow-up audit on the calendar for a month after launch to catch chains created by post-launch patches.
- Record which redirect rules exist and why in one shared document so the next migration does not start from scratch.
https://deadlinkr.com/templates/site-launch-and-migration-link-checklist/Use it in your business, share it with your team, or link to it from your own site.
Also from DeadLinkr
- Broken Link Fix List Worksheet: A one-page fix list that turns a raw crawl export into rows a developer can work through: the failing URL, the pages that link to it, what the server returns, the fix, who owns it, its priority, and when it was verified.
- Free calculators