Site Migration Link Protection Checklist
A before, launch day, and after checklist that keeps a site migration, redesign, or domain change from turning into a wave of broken links.
Reviewed for 2026, updated September 8, 2026.
Most broken links appear one at a time, but the biggest batches show up in a single afternoon when a site moves to a new platform, changes its URL structure, merges with another domain, or switches from HTTP to HTTPS. Every old address that stops answering correctly takes its backlinks, bookmarks, and search rankings with it, and recovering that traffic afterward is slow and uncertain. The cheapest moment to protect links is before anything moves, which is what this checklist is for.
Print it or copy it into your project tracker and work through the three phases in order. The before phase captures the full picture of what exists today, the launch day phase catches problems while the old environment is still available for a rollback, and the after phase covers the weeks when search engines and other sites are still requesting the old URLs. The guide at /guide/ and the article on broken links after a site migration explain the reasoning behind each line if you need to justify a step to your team.
- Before: crawl the current site completely and export every URL with its status code, title, and inbound internal link count.
- Before: pull the list of URLs that received traffic in the last 12 months from analytics and add any that the crawl missed.
- Before: export the URLs that have backlinks from other sites and flag them as must-redirect entries.
- Before: include non-HTML assets in the inventory: PDFs, images, downloads, feeds, and any file linked from emails or print materials.
- Before: build a redirect map that pairs every old URL with one new destination, one to one wherever possible, and store it in version control.
- Before: review the map entries for the home page, navigation, top traffic pages, and key landing pages by hand rather than trusting pattern rules.
- Before: choose a fallback for old URLs with no equivalent: a real 404 or 410 page, never a blanket redirect to the home page.
- Before: stage the new site, crawl it, and confirm that every page in the redirect map resolves to a 200 status on the staging environment.
- Before: test the redirect rules against the full old URL list and check that no chain runs longer than one hop and no loop exists.
- Before: confirm that the new 404 page keeps site navigation, offers search, and returns a true 404 status rather than a 200.
- Before: name one owner for redirects, one for content links, and one for monitoring during the launch window, and agree on a rollback trigger.
- Launch day: keep the old environment reachable so a rollback is possible for at least the first days after the switch.
- Launch day: run the redirect test again against production as soon as DNS or the new deploy is live.
- Launch day: watch the server error rate and 404 count in real time and compare them with the baseline from the week before.
- Launch day: crawl the new production site and check internal links in navigation, footer, and templates first.
- Launch day: update the sitemap, submit it to search engine webmaster tools, and verify that robots rules are not blocking the new URLs.
- After: crawl the new site again within the first week and compare the results against the pre-migration URL export.
- After: review webmaster tool crawl error reports for old URLs that were never added to the redirect map and add them.
- After: check redirect rules written under pressure for chains, wildcard patterns that send unrelated pages to one destination, and gaps.
- After: update internal links so they point directly at the new URLs instead of relying on the redirect for every click.
- After: contact the sites behind your most valuable backlinks and ask them to update the link if the old URL cannot be redirected.
- After: keep the redirects in place for years rather than weeks and record the date and reason for each rule so future cleanups have context.
- After: schedule a recurring crawl or continuous monitoring so leftover breaks surface within days rather than when a customer reports them.
https://linkrotly.com/templates/site-migration-link-checklist/Use it in your business, share it with your team, or link to it from your own site.
Also from LinkRotly
- Broken Link Triage Worksheet: A working sheet for turning a raw broken link report into a grouped, prioritized fix plan with a named owner for every entry.
- Free calculators