Website Migration SEO: A Redirect and Launch Checklist
Protect useful URLs during a website migration with an old-to-new map, relevant redirects, indexing checks, form tests, and post-launch monitoring.
A redesigned website can look better while leaving customers with broken bookmarks, outdated search results, and forms that no longer reach the right team.
A website migration SEO checklist connects the old site with the new one. It helps the launch team preserve useful destinations, explain intentional changes, and verify that the business still receives inquiries.
This guide focuses on changes to URLs, including a new domain or reorganized page paths. A hosting change that preserves all URLs has a different scope.
SMART takeaway
Plan the URL handoff before the visual launch.
Inventory existing destinations, map each important old URL to a relevant new one, test redirects and conversion paths, and monitor the site after launch.
Quick answer: what should be checked before launch?
- An inventory of existing URLs and important customer destinations
- An approved old-to-new URL map with deliberate removal decisions
- Redirects, canonical URLs, internal links, and sitemap entries
- Production crawling and indexing settings
- Forms, calls, booking links, analytics, and lead destinations
- A rollback decision, launch owner, and post-launch monitoring plan
Google’s site-move documentation recommends mapping old URLs to new destinations, updating links, and using permanent server-side redirects for permanent changes. It also advises sending users directly to relevant final destinations rather than routing unrelated pages to the homepage.
The implementation checklist below turns those principles into a practical business launch review.
1. Inventory the old site before replacing it
Collect current page paths from the website, sitemap, analytics, Search Console, and any available crawl. Reconcile the sources rather than assuming one list is complete.
Include landing pages used in advertising, PDF links, QR codes, email signatures, social profiles, and customer bookmarks known to the team.
Prioritize pages that support actual services and inquiries. A rarely visited page can still matter if it is linked from a printed brochure or an active campaign.
For a South Florida business, also review existing location and service-area pages. A migration should not accidentally erase accurate information that helps customers understand where the company works.
2. Build an explicit destination map
For each old URL, record its new destination, the reason for the change, and the person approving it.
Keep a useful URL when there is no reason to change it. When pages are combined, select a destination that genuinely answers the old page’s purpose.
Handle removed offerings deliberately. The team should decide whether there is a relevant replacement or whether the content is gone, then implement the appropriate response.
Have the service owner review the map. Developers should not have to infer which new service page replaces an old one.
3. Test the exact legacy paths
Use the literal URLs customers may still have, including older path spelling, capitalization where relevant, and historical file-like paths.
For each important URL, record the initial response, redirect destination, final status, and the page the user sees. Check the final content as well as the status code.
Test for loops and unnecessary chains. A redirect that reaches a technically valid but irrelevant page is still a poor handoff for the customer.
SMART Solutions’ current site retains its established service paths while presenting the updated service framework. That is a useful reminder to assess existing routes before renaming them during a redesign.
4. Review canonical URLs and internal destinations
Check that new pages identify the intended production URL, that navigation and body links use the chosen paths, and that the sitemap lists the pages intended for public discovery.
A canonical tag and a redirect serve different purposes. Follow the platform’s implementation conventions and have the technical reviewer check the generated output.
Review key page titles, descriptions, heading structure, and service content against the approved launch inventory. Confirm that the migration preserved important copy rather than replacing every detailed service page with a generic summary.
The web design planning guide helps establish those page and conversion requirements before implementation.
5. Check the production indexing settings
Preview restrictions should be intentional. Production settings should be reviewed separately from staging settings.
Google’s migration guidance includes checking robots directives and removing unintended development restrictions at launch. Confirm the generated production pages and crawl controls rather than relying only on a configuration screenshot.
If the domain changes, review Search Console ownership and the applicable Change of Address process with the migration owner.
Record the expected behavior for redirects, removed pages, and new pages so post-launch observations can be compared with a plan.
6. Test the complete inquiry path
Submit a labeled test inquiry using the public website on a phone and a desktop. Confirm that the customer receives the expected response and that the intended team receives the submission.
Test telephone links, booking destinations, customer portals, and campaign landing pages. If CRM connections are involved, confirm the record and assignment in the destination.
Review analytics events against the business’s chosen conversion actions. Do not assume the tracking survived because the new site uses the same visual button.
SMART Solutions’ Web Design & Development service includes responsive websites, SEO structure, forms, analytics, and practical integrations when needed. Those business paths belong in the acceptance review.
7. Decide who can authorize launch and rollback
Assign one person to coordinate the cutover and define the conditions that would pause or reverse it.
Examples include a widespread redirect failure, an unusable contact form, or incorrect service content. A minor copy correction may need a different response.
Keep the previous configuration and approved migration map available to the launch team. Record any changes made during cutover so the team can explain the resulting state.
Avoid making unrelated major content, domain, and platform changes without considering how that complicates diagnosis.
8. Monitor after deployment
Review actual generated routes, inquiry delivery, analytics, Search Console, and customer reports after launch.
Google notes that search visibility may fluctuate during a site move. A technically sound launch does not guarantee unchanged rankings or immediate indexing.
Track broken destinations and repair them against the migration map. Compare changes over time with the launch baseline while accounting for seasonality, campaigns, and other business changes.
Use the website maintenance checklist to turn launch checks into ongoing ownership.
Website migration FAQ
Must every redesigned page get a new URL?
No. Retain useful paths when the redesign does not require a change.
Can all old pages redirect to the homepage?
That usually fails to preserve their purpose. Map important old pages to relevant replacements and decide removals explicitly.
Can SMART Solutions help plan SEO continuity?
SMART Solutions provides SEO & Local Visibility and website development services. Contact our team to review your existing URLs, service pages, and launch requirements.
Primary source
- Google Search Central — Site moves with URL changes: URL mapping, redirects, launch controls, and monitoring.
Prepare the map before launch day. It gives the team a concrete way to verify that the new website still connects customers with the right services.