SEO Website Migration Checklist: How to Change Domains Without Losing SEO or GEO

An SEO website migration checklist covers everything that has to happen before, during and after a change to your URLs, domain, platform or site structure. The core tasks are crawling the old site, mapping every old URL to a new one, testing redirects on staging, and monitoring Search Console and AI citations for weeks after launch.

I’ve been in SEO since 2010, back when my job was commenting on forums and blog posts. Migrations are still the projects where a single missed step costs the most.

Site redesigns are one of the highest-risk events in SEO, as we wrote in our fraud.net case study, which is why they deserve their own workstream. This checklist runs from planning to monitoring and troubleshooting, and it works whether you have run a dozen migrations or this is your first.

If you would rather hand the whole thing to a team, that is what our SEO migration service is for.

Key takeaways

• The URL map is the whole job: every old URL needs a deliberate destination before launch, and one named person should own that map.
• The checklist runs in three phases: before launch, launch day and after launch. Most failures come from skipping items in the first and last phases.
• Domain transfers and website migrations are different events: a transfer moves registration and takes hours to days. A migration moves content and takes weeks to months.
• Redesigns are riskier than platform moves: changing content and templates while changing URLs means you cannot tell which change caused a drop.
• AI citations recover on their own curve: assistants may keep citing an old URL for months after a move, and a redirect does not always carry the mention.
• Plan for a dip: a well-run migration usually costs a few weeks of volatility. Be wary of any plan that promises none.

What is a website migration?

A website migration is any substantial change to a site’s URLs, platform, domain, structure, design or content that could affect how search engines and AI assistants find it.

That covers moving to a new domain, restructuring the content hierarchy, switching from HTTP to HTTPS, changing your content management system (CMS), and redesigning the UX and UI.

The SEO risk comes from breaking the connections search engines and assistants have already made to your pages. Handled properly, rankings carry over.

Handled badly, recovery takes months and sometimes never fully happens. The SEO value you built over years can drain away in a week, so a migration deserves careful planning and execution whatever its size.

Types of website migration

There are five common types of website migration, and many projects combine two or more of them.

• Platform migration: moving the site to a new CMS. It can bring better flexibility, a better editing interface and new functionality, and it puts existing data and SEO at risk if handled carelessly.
• Domain migration: moving the site to a new domain name. Users and search engines both need to be redirected to the new site, or the traffic stays behind on the old one.
• Protocol migration: moving from HTTP to HTTPS for better security. It is one of the most common migrations, and it still affects SEO when implemented incorrectly.
• Structural migration: changes to the overall site structure, including URL changes. SEO takes a significant hit when those changes affect how search engines crawl and index the site.
• Content migration: significant additions, deletions or alterations to the site’s content. Preserving the content that already ranks is the priority here.

The type matters because it tells you which parts of this checklist carry the most weight. A protocol migration is mostly redirects and certificates. A content migration puts steps 12 and 13 at the centre of the project.

Does a website migration affect SEO?

Yes. A website migration usually causes a period of ranking volatility, traffic dips and reduced visibility, because search engines have to recrawl and reindex the site before they trust the new version.

That short dip is normal. The damage that lasts comes from mistakes made during the migration.

Improperly redirected URLs drop pages out of the index. Hasty changes to content and metadata knock down keyword rankings that took years to earn.

So the goal is to migrate with SEO at the centre of the process from the first planning meeting. Treating SEO as a launch-week task is how traffic charts end up looking like a cliff.

The SEO migration checklist at a glance

The full website migration checklist has 38 steps across three phases. Each one is explained in the sections below.

Phase	Steps	What it protects
Before launch	1 to 24: goals, team, timeline, crawl, audit, baselines, backup, staging, URL map, on-page and technical preparation, redirect testing, DNS preparation, user communication	The record of what existed and the plan for where every URL goes
Launch day	25 to 28: DNS switch, old host kept live, immediate recrawl, sitemap submission	Clean resolution and fast discovery of the new URLs
After launch	29 to 38: Search Console, analytics, rankings, 404s, crawls, backlinks and mentions, old domain, AI citations, user feedback, optimization	Recovery, which is where the SEO outcome is decided

Before launch: the pre-migration SEO checklist

Pre-migration planning is where most of the SEO outcome is set. Every step below happens before a single live URL changes.

1. Set clear migration goals

Start by writing down clear objectives for the migration.

Are you improving the user experience, updating the branding, fixing the site structure, or moving to a more SEO-friendly platform? The answer guides every step that follows.

It also gives you a benchmark. Without a stated goal, you have nothing to judge the migration’s success against once the dust settles.

2. Assemble a migration team and name one owner for the URL map

A migration needs several kinds of expertise working together.

• Project manager: runs the operation, the timeline and the handoffs.
• Web developers: handle the technical heavy lifting, from templates to server-side redirects.
• SEO specialists: keep the organic search impact as small as possible and own the URL map.
• Content and design: writers and designers who adjust copy and visuals where the project calls for it.

I’ve argued for years that quality SEO takes a whole team, and a migration is the clearest example. Assemble the team early and keep communication open throughout.

One rule on top of that: a single named person owns the URL map. Migrations fail when the map is a shared spreadsheet nobody is accountable for.

3. Plan the migration timeline

Pick the launch date deliberately. A quiet trading period is better than your busiest month, because you will likely see temporary dips in traffic and performance after launch.

Start planning at least a month in advance, and longer where you can. For a typical B2B SaaS site of a few hundred pages, six to twelve weeks from audit to launch is realistic.

Then budget four to eight weeks of monitoring after launch, and make sure the whole team is working to the same dates.

4. Crawl the old site before anything changes

Run a full crawl of the current site before anyone touches it. That crawl is the only complete record of what existed.

Without it you cannot prove what broke. Save the export somewhere the whole team can reach, because you will compare against it for weeks.

5. Run a full SEO audit of the current site

An audit tells you the current state of the site: SEO data, content, structure, errors and weak spots.

You are looking for issues to fix, either before the migration or as part of it. The audit also gives you the reference point for judging the migration’s impact afterwards.

For the SEO audit, Semrush or Ahrefs will cover most of what you need.

6. Export rankings, traffic and top pages as a baseline

Pull performance data from Search Console and your rank tracker, and export the top pages by traffic, conversions and backlinks.

This baseline is what you compare against after launch. It also identifies the pages that earn, which are the ones that get extra protection in steps 12 and 13.

7. Record your AI citation and brand mention baseline

Record where your brand and URLs are currently named or cited in AI answers and across the web.

Rankings and citations recover on different curves, and only rankings show up in Search Console. If you skip the before snapshot, you have no way to measure the after.

8. Back up the entire website

Even with a skilled team and a precise plan, things can go wrong during a migration, and they often do.

Back up everything: content, databases, media files, configuration and redirect rules. That backup is what lets you restore the site in an emergency.

Without one, a failed launch can leave the site damaged beyond easy repair.

9. Set up a staging site

A staging site is a clone of your live website where you make and test every change before it goes public.

You can implement, test and adjust without affecting users or search positions. Keep staging behind a login so search engines never index it.

Staging also makes rollback easier. If something goes wrong, you fix that one thing and keep the rest of the work intact.

10. Build the URL map and plan 301 redirects

The URL map lists every old URL next to exactly one new URL. It is the main deliverable of the whole migration.

Plan the new URL structure carefully, then map each old URL to its closest equivalent. Every changed URL gets a 301 redirect, which keeps traffic flowing and carries link equity to the new page.

Write the redirect plan down as a document the developers build from. The map and the redirect rules should match line for line.

11. Make a deliberate decision for every URL with no equivalent

Pages that have no equivalent on the new site each need an explicit decision: redirect to the closest relevant page, or return a 410.

The single most common failure I see is redirecting everything that no longer exists to the homepage. Google treats those as soft 404s, so you get the loss of the page without the benefit of the redirect.

12. Carry metadata over unchanged

Titles, meta descriptions and image alt text should move across exactly as they are.

Metadata is a direct signal to search engines about what a page covers. Diluting it during the move weakens pages that were ranking.

Migration does surface metadata you overlooked in the past, and new keywords you want to target. Log those improvements now and apply them in step 38, once rankings have settled.

13. Preserve content and heading structure on pages that earn

The quality and relevance of your content play a large part in rankings, so preserve titles, headings and body copy on the pages that bring in traffic and revenue.

Change URLs or content, ideally one at a time. Changing both at once means a ranking drop has two possible causes.

Check the heading structure (H1, H2, H3) survives the new templates intact. Keyword research, copy quality checks and search intent alignment still matter, and they belong in step 38.

14. Point internal links at final destinations

A strong internal linking structure helps users and tells search engines which pages matter most.

Update internal links to point straight at the new URLs. Internal links that point at redirects are how redirect chains form.

Use relevant anchor text while you are in there, and avoid over-optimizing it.

15. Resolve duplicate content and check canonical, hreflang and structured data

Duplicate content hurts rankings, and a migration is a good moment to find it. Copyscape and Google Search Console will surface most of it.

Resolve duplicates through the URL map where you can, by redirecting or canonicalizing the weaker version. Save rewrites for after launch.

Then check every template on staging outputs the right canonical tag, the hreflang tags you already rely on, and your structured data. Canonicals tell search engines which version is preferred and consolidate authority onto it.

16. Test mobile responsiveness

Google uses mobile-first indexing, so the mobile version of your new site is the version that gets ranked.

Make sure the new site is responsive, and test it on a range of real devices before launch.

17. Maintain or improve site speed

Fast pages matter for both users and rankings. Prioritize performance and avoid carrying bloated code across to the new platform.

Measure the new site with Google PageSpeed Insights and WebPageTest, and compare the results with the old site before you launch.

18. Secure the new site with HTTPS

If the site still runs on HTTP, the migration is the moment to move to HTTPS. It protects your users and supports your rankings.

Make sure the certificate covers every hostname you use, and redirect every HTTP URL to its HTTPS equivalent in a single hop.

19. Prepare robots.txt for the new site

Robots.txt controls which pages search engine bots can crawl, so update it on the new site before launch.

Make sure it allows access to every page you want indexed, and reference the new sitemap location in it.

Check the file again on launch day. Staging rules that block crawlers have a habit of reaching production.

20. Generate the new XML sitemap

An XML sitemap is a roadmap that helps search engines understand your structure and discover new content.

Generate one for the new site that lists only final, indexable URLs. Submitting it after launch speeds up discovery and indexing of the migrated content.

21. Test every redirect on staging against the full old URL list

Run the complete list of old URLs from your crawl against the staging redirects, and check each one lands on the mapped destination with a single 301.

Testing a sample is how broken redirects reach production. Keep testing redirects regularly after launch as well.

22. Verify the new site in Search Console, Bing Webmaster Tools and Yandex

Verify the new site in Google Search Console and in the webmaster tools for Bing and Yandex before launch.

That way you have data access and monitoring from the first hour. Keep the old property verified too, so you can watch both sides of the move.

23. Lower your DNS TTL a day or two before the switch

Lower the TTL on your DNS records to 300 seconds a day or two before launch.

Skipping this is why some users see the old site for a day after launch. The section on name servers and DNS below covers the reasoning.

24. Inform your current users

Tell your current users about the migration before it happens. It is good manners and good business.

Daily blog readers and paying customers both appreciate a heads up about possible disruption to their visits or their use of the service.

It also helps them prepare. If you are changing payment gateways or adding new features, tell users what is coming so they are ready when it arrives.

Launch day: the migration go-live checklist

Launch day is short if the pre-launch work was done properly. These four steps happen in the first hours.

25. Switch DNS and confirm resolution from several locations

Make the DNS or name server change, then confirm the domain resolves to the new host from several locations.

Once traffic has moved, raise the TTL back to its normal value.

26. Keep the old host running until traffic has fully moved

Leave the old hosting live until every resolver has picked up the change.

Turning it off early produces outages for anyone still resolving to it.

27. Recrawl the new site immediately

Crawl the live site as soon as it resolves. Compare the result against the pre-migration crawl and the URL map.

Look for 404s, redirect chains, stray noindex tags, a blocking robots.txt and missing canonicals. These are much cheaper to fix in the first hour than in the third week.

28. Submit the new sitemap and check for crawl errors

Submit the new XML sitemap in Google Search Console and the other webmaster tools, then check the crawl error reports.

For a domain change, also file the move with the Change of Address tool in Search Console.

After launch: the post-migration SEO checklist

Post-migration monitoring catches problems before they cost rankings. Teams consistently underestimate this phase, which is where the SEO outcome is actually decided.

There is a lot to watch, and it gets overwhelming without a plan. So here it is step by step.

29. Watch Google Search Console daily for two weeks

Check Search Console daily for the first two weeks, then weekly for two months. Coverage errors surface before ranking changes do.

Search Console is the best companion you have in this phase. It alerts you to site errors, manual actions and structured data issues, and it shows search performance and indexing status.

An indexation drop there usually points to a crawling issue, which means something technical is wrong on the new site.

30. Monitor organic traffic in Google Analytics

Search engines start visiting the new site straight after the move, so watch organic traffic in Google Analytics from day one.

A substantial drop usually points to a migration issue such as missing redirects or a sitemap that was never updated. When traffic starts to dip, find the cause and fix it quickly.

31. Track keyword ranking changes against the baseline

Rankings will fluctuate after launch. That is typical and usually temporary while search engines get used to the new site.

Track your target keywords in the SEO tool you prefer and compare against the baseline from step 6. Significant declines that persist point to a problem.

When rankings sit below the baseline, review the on-page elements on the affected pages first: meta tags, headings and content quality.

32. Track and fix 404 errors

Monitor 404 errors closely during and after the migration, using the reports in Google Search Console and your other webmaster tools.

Fix each one with a proper redirect or by removing the link that points to it. A 404 or 410 on a page you deliberately retired is fine.

Keeping on top of this protects both SEO value and the user experience.

33. Crawl and audit the site on a schedule

Regular crawls reveal what is happening behind the scenes: 404 errors, redirects that misfire, redirect chains and duplicate content.

Schedule audits for the whole monitoring window. Tools like Semrush and Moz make this a lot easier.

34. Update backlinks and off-site mentions

A healthy backlink profile is one of the most valuable SEO assets you have, and it deserves attention after the move.

Contact the sites linking to your most important pages and ask them to update the links to your new URLs. That preserves link equity without relying entirely on redirects.

Mentions deserve equal attention. Update the directories, listicles, documentation and community posts that name your old domain, because they feed both AI retrieval and future training data.

35. Keep the old domain and its redirects permanently

Keep renewing the old domain after the migration. It keeps SEO value for a long time, and holding it stops a competitor from buying it.

Keep the 301 redirects from the old domain in place permanently. They send remaining visitors and remaining SEO value to the new site.

The customary twelve months is too short, because assistants surface old URLs long after users stop clicking them.

36. Track named mentions and AI citations against the baseline

Compare brand mentions and AI citations against the baseline from step 7.

Expect this curve to lag rankings. An assistant can keep naming the old domain for as long as its training data says that is where you live.

37. Collect user feedback and behaviour data

Users spot things your team misses, like broken functionality or content that became inaccurate in the move. Ask for feedback and make it easy to report problems.

Watch behaviour data too: bounce rate, time on site and page views. Those metrics show whether the new site works for people, and user experience feeds into SEO over time.

Tools like Hotjar make it easier to collect and analyse that behaviour.

38. Optimize metadata and content once rankings stabilize

Once rankings are stable against the baseline, apply the improvements you logged in steps 12 and 13.

Keep titles concise and descriptive and within the usual character limits, typically 60 characters for titles and 155 for meta descriptions.

Then use keyword research, copy quality checks and search intent to improve content, one batch of pages at a time. Continuous optimization after the move is how a migration ends up improving performance.

How to troubleshoot SEO problems after a migration

Most post-migration problems trace back to redirects, indexing rules or content changes, and they are easiest to fix when caught early.

Issues can appear even on a well-run migration. These are the moves I rely on when they do.

• Use backups wisely: if a major problem occurs, restore from the backup while you resolve the underlying issue.
• Identify issues quickly: the sooner you find the root cause, the faster it gets fixed. That is why regular auditing and monitoring matter so much.
• Use your SEO toolkit: Google Search Console is a treasure trove for troubleshooting, and your crawler and rank tracker fill in the rest.
• Ask the SEO community: if you cannot solve a problem, ask SEO specialists or the wider community. Forums, blogs and social platforms can point you to guidance or useful resources.

Those forums still answer odd technical questions faster than most documentation.

The deeper review of common SEO migration mistakes covers the failure patterns in more detail.

Keep perspective. A dip after launch is usually temporary and recoverable, and steady monitoring gets you through most migration problems.

How long does a website migration take?

For a typical B2B SaaS site of a few hundred pages, plan six to twelve weeks from audit to launch, then four to eight weeks of monitoring and correction afterwards.

Across all sites, the range is a few weeks to a few months. The duration of an SEO migration depends on site size and complexity, the type of migration, and the resources available.

The work splits roughly into a third planning, a third execution and a third recovery. Teams consistently underestimate the last third.

Larger sites take less extra time than you would expect. A ten thousand page site takes longer to map but the same time to launch, because the mapping is largely rule-based.

What genuinely extends the timeline is content changes made during the move, multiple subdomains being consolidated, or a CMS that cannot express the redirect rules you need.

Always budget time for the pre-migration audit, the migration itself, testing, and post-migration analysis.

How long does a domain transfer take?

A domain transfer between registrars usually completes in five to seven days, because ICANN requires a period in which the current registrar can confirm or reject it. Transfers within the same registrar are often immediate.

This is a registration change. Your site stays where it is and your rankings are unaffected.

People conflate this with a domain migration, where you move a site from one domain name to another. That is an SEO event, and the relevant timescale is months.

Domain name servers and DNS during a migration

Name servers tell the internet which DNS provider holds the records for your domain, and those records point visitors at your hosting.

Changing name servers propagates over anywhere from a few minutes to 48 hours, depending on cached TTL values.

The practical sequence:

1. Lower the TTL: set it to 300 seconds a day or two before the switch.
2. Make the change: update the name servers or DNS records.
3. Confirm resolution: check from several locations that the domain resolves to the new host.
4. Raise the TTL again: once traffic has moved.

Keep the old host running until traffic has fully moved. Turning it off early produces outages for anyone still resolving to it.

SEO for a website redesign

A redesign changes templates and content, while a migration changes URLs. Doing both at once is the highest-risk version of this work, and it is also what most companies do.

If you can separate them, migrate URLs first with the existing design, confirm stability, then redesign. That way a ranking drop has one possible cause.

When they cannot be separated, protect the pages that earn. Keep the headings, keep the body copy, keep the internal links, and let the design change around them.

The pages that lose rankings in redesigns are almost always the ones where a writer took the opportunity to freshen up copy that was ranking perfectly well.

It’s a balancing act. A redesign is a real chance to improve the site, and the SEO value built over years is what pays for it.

CMS migration SEO: how to switch platforms without losing rankings

Most CMS migration damage comes from the URL structure the new platform imposes.

Before committing to a platform, confirm it can reproduce your existing URL patterns. If it cannot, accept that you are running a URL migration at the same time and plan for it.

Check three things specifically:

• Redirects: whether the platform supports server-side redirects at the volume you need.
• Tags: whether it can output the canonical and hreflang tags you already rely on.
• Pagination and facets: whether paginated and faceted URLs behave the same way they do today.

WordPress has its own quirks with permalinks, plugins and redirects. The guide to WordPress migration tips covers them.

For AMPL we restructured a set of content-heavy subdomains covering developer guides and educational material. Consolidating that structure properly was what tripled their page one keywords for product terms.

How to keep AI citations through a domain change

AI citations survive a domain change when redirects stay in place permanently and the off-site mentions naming the old domain get updated.

This is the part that has changed in the last two years, and most migration guides still ignore it.

Assistants build associations from training data and retrieve pages at answer time. A 301 redirect handles the retrieval half: the assistant follows it and reaches your new URL.

The association half updates on its own schedule. A model may keep naming your old domain, or citing an old URL, for as long as its training data says that is where you live.

What helps, in order of usefulness:

• Keep redirects in place permanently: the customary twelve months is too short, because assistants surface old URLs long after users stop clicking them.
• Update your off-site mentions: the directories, listicles, documentation and community posts naming the old domain. These feed both retrieval and future training.
• Keep the brand name stable if you can: a domain change is survivable, while a simultaneous rename is much harder, because the association is to the name.
• Track named mentions before and after: rankings and citations recover on different curves, and only one of them shows up in Search Console.

Listicles deserve extra attention. They are the pages assistants reach for on comparison questions, so an outdated domain in a ranking “best tools” list keeps the old name in circulation.

How much does a website migration cost?

Website migration cost tracks URL count, the number of systems involved, and whether content changes at the same time. The design has surprisingly little to do with it.

A small site moving platforms with URLs preserved is a modest piece of work.

A multi-subdomain consolidation with a redesign and a content rewrite is a different order of project. The URL mapping stops being rule-based and becomes a page-by-page decision.

The variables that drive quotes up are the ones to interrogate:

• URL count: how many URLs the site has.
• Ranking URLs: how many of them rank or earn traffic.
• Manual decisions: how many need individual mapping decisions.
• Recovery ownership: who is responsible for the recovery period after launch.

A quote that ends at launch is quoting half the job.

The website migration project plan

A workable website migration project plan has four phases and one rule.

• Audit: set goals, crawl, baseline rankings and citations, inventory every URL, and identify the pages that earn.
• Map: old URL to new URL for everything, with explicit decisions on orphans.
• Stage and test: redirects tested against the full old URL list, and templates checked for canonical, hreflang and structured data.
• Launch and monitor: recrawl immediately, submit sitemaps, watch coverage daily for a fortnight and weekly for two months.

The rule is that one named person owns the URL map. Migrations fail when the map is a shared spreadsheet nobody is accountable for.

Build the timeline, the task owners and the risk list around those four phases. The 38 steps above slot into them directly.

Final thoughts

A migration can be a catalyst for growth or the start of a long traffic decline, depending entirely on how the process is managed.

Almost every bad migration I have been called in to fix had the same root cause: nobody treated the URL map as the main deliverable.

Crawl before you change anything, map every URL deliberately, keep the redirects forever, and stay patient through the fluctuations while you monitor.

The rest is project management.