Website Migration SEO Checklist

Define what is changing

Write down whether the move changes the domain, URL structure, hosting provider, content management system, design, or all of them. A domain move has different risks from a visual redesign, and combining several changes makes diagnosis harder if traffic drops.

Create a list of the important current URLs, their status codes, titles, canonical tags, indexation instructions, and strongest internal links. Include pages that receive search visits, links, leads, sales, or recurring customers. Your redirect plan should begin with evidence, not memory.

Prepare the new environment privately

Build and test the new site on a protected staging address or access-controlled environment. Check that forms, logins, images, scripts, redirects, structured data, and analytics work before launch. Keep staging out of search with authentication or noindex, and do not link it publicly as if it were the final site.

Compare a sample of old and new pages side by side. The new page does not need to look identical, but it should preserve the main content, intent, useful links, and user actions unless you have a deliberate reason to change them.

Map every important old URL

Create a redirect map with one old URL and one best matching new URL per row. Redirect a retired page to its closest useful replacement, not automatically to the homepage. If no relevant replacement exists, return an intentional 410 or 404 rather than sending visitors somewhere confusing.

Avoid chains such as old URL to temporary URL to new URL. Point each old address directly to the final canonical destination. Test trailing slashes, uppercase variants, query parameters, pagination, files, and common legacy paths if they appear in logs or analytics.

Check canonical, robots, and sitemap signals

The new site should reference the new canonical URLs consistently in canonical tags, internal links, Open Graph URLs, structured data, and the XML sitemap. Remove temporary staging directives when the launch site is ready, but keep private admin and account areas out of search.

Use robots.txt as a crawl instruction, not as a replacement for redirects or noindex. Submit the new sitemap in the relevant webmaster tools and monitor the old and new properties when the domain changes. The goal is to make the preferred version unmistakable.

Preserve titles, content, and internal links

A migration is not the ideal moment to delete large sections of useful content without a plan. Preserve strong titles and descriptions where they remain accurate, then improve them in a separate, documented pass. Keep important headings, copy, images, and links available on the new URLs.

Update internal links to point directly to the new paths instead of relying on redirects. Check navigation, breadcrumbs, related content, feeds, downloadable files, and structured data. Broken internal paths create unnecessary work for visitors and crawlers immediately after launch.

Launch with a verification list

At launch, confirm DNS, HTTPS, the preferred host, status codes, redirects, forms, analytics, search console verification, robots.txt, sitemap, canonical tags, and the most important page templates. Test from a logged-out browser and a mobile device. Keep the old environment available until the new site is stable.

Watch the first hours for server errors, redirect loops, missing assets, unusual response times, and a sudden drop in normal actions. Save screenshots and response samples from before launch so you can compare instead of relying on memory.

Monitor after the migration

Search engines may need time to recrawl and process the new signals. Monitor impressions, clicks, indexed pages, crawl errors, redirects, server logs, and important conversions for several weeks. A short fluctuation is not automatically a failure, but a persistent drop on a specific page deserves investigation.

Keep redirects active for as long as they are useful, especially when external sites and bookmarks still point to old URLs. Fix new internal links and update important external profiles where you control them. A migration is complete when the new site is stable, discoverable, and easier to maintain—not merely when DNS changes.

Separate cleanup from the move

Once the migration is stable, make a separate list of improvements that were postponed: rewriting thin content, changing templates, consolidating duplicates, improving speed, or testing new navigation. Handle those changes deliberately so future measurement remains understandable.

A careful migration creates a cleaner baseline for the next phase of growth. Keep the redirect map, launch checklist, monitoring notes, and before-and-after URL list in a shared place. They will save time the next time the business changes its platform or brand.

Give the team a clear owner for each follow-up. One person can watch technical errors while another reviews search performance and another confirms forms or sales actions. Ownership matters because migration problems are often small at first, and a clear responsibility makes them easier to correct before they become a long-term loss.