Website Migration Checklist: Types, Steps and Tools

A website migration is any significant change to a site’s hosting, platform, design, structure, or URLs. Search engines treat it as a move that must be relearned, so the job is to keep every old URL pointing to its new equivalent, keep the new site crawlable, and watch the results. This guide covers the four types, a checklist you can follow in order, the tools for each job, and the WordPress-specific steps most generic guides skip.

What Does Website Migration Mean?

Website migration means making a major change to the way a site is hosted, built, designed, or addressed. Ahrefs defines it as “any significant change to a website’s domain, URLs, hosting, platform, or design.” Other guides use similar wording, and the practical test is the same: if the change could alter what search engines crawl, index, or rank, treat it as a migration.

A new blog post is not a migration. Neither is a plugin update or a copy edit. Moving from one host to another is a migration, even if nobody can see a difference.

Why Migrations Put Rankings at Risk

Search engines build their understanding of a site from its URLs, content, links, and signals over time. A migration can break each of those at once. Common causes of lost visibility are:

• Old URLs that return 404 instead of redirecting.
• Redirects that point to the wrong page or to a chain of other redirects.
• A noindex tag or robots.txt block copied from the staging site to the live site.
• Canonical tags that still point to the old site.
• Content, headings, internal links, or structured data that changed during the rebuild.
• Slower pages on the new setup.
• Lost analytics or Search Console access, so nobody notices the damage.

Google states the stakes plainly. Its site move documentation says that for a medium-sized site it can take “a few weeks or more for Google to gradually start showing the new URLs,” and larger sites take longer. A migration is not a pass or fail event on launch day. It is a period you manage.

What Are the Four Types of Website Migration?

There is no official list of four. Guides disagree on the count: Ahrefs separates six, one guide from IT.com lists ten, and Infidigit lists more than ten. The labels differ, but most of them describe the same four situations.

Evidence note: The four groups below are a TechEsprit grouping, built on the same-URL versus different-URL split that Ahrefs and Google’s two separate site move guides use.

1. Hosting or Server Migration

You move the site to a new host, server, or CDN while every URL stays the same. This is the lowest-risk type for rankings, and it is still easy to break. Google’s guidance for this case says to test a full copy, make sure firewalls do not block Googlebot, and lower the DNS TTL before switching.

2. Platform or CMS Migration

You move to a different CMS, a new framework, or a different build approach. Moving from another CMS to WordPress is a common case. The risk sits in templates: the new platform may output different title tags, canonicals, headings, schema, or internal links than the old one.

3. Design or Structure Migration

You change the theme, templates, navigation, or site architecture. A redesign that keeps the same URLs still changes internal links, headings, and page weight. If pages move or merge, it becomes a URL migration as well.

4. URL, Domain or Protocol Migration

Any change to the address people and crawlers use belongs here: a new domain, a move between subdomain and subfolder, changed paths, or HTTP to HTTPS. This is the highest-risk type because every old URL needs a permanent redirect and Google must reprocess the whole site.

Many real projects combine types. A rebrand might change the domain, the theme, and the host in one launch. Each added type adds risk, so when you have the choice, separate them into stages.

Website Migration Checklist

Work through these in order. Items marked (Google) follow Google’s published site move guidance. Items marked (TechEsprit) are our recommended practice, not Google requirements.

Phase 1: Plan

• Write down exactly what is changing: host, platform, design, structure, domain, or protocol.
• Name one owner, one approver, and a launch date outside peak business periods.
• Agree rollback criteria before launch. For example: the live site is blocked from indexing, key templates return server errors, or redirects fail for your top URLs.
• Freeze content and plugin changes on the old site from the baseline crawl until launch.
• Confirm access to Search Console and analytics for both the old and new site, and keep verification methods working on the new copy.
• Back up the full site (files and database) and test that the backup restores.

Phase 2: Record the Baseline

• Crawl the current site and export every URL with status code, title, H1, meta description, canonical, indexability, word count, and internal links.
• Export Search Console performance data (queries and pages) for at least the last 12 months so you can compare later.
• Export analytics landing pages and conversions.
• Export your most-linked pages and referring domains so you know which redirects matter most.
• Record Core Web Vitals and page speed for key templates. See our WordPress speed and Core Web Vitals guide for what to measure.
• Save copies of robots.txt, XML sitemaps, and structured data on key pages.

Phase 3: Build and Test on Staging

• Put the staging site behind a password or IP restriction, and add noindex. Google notes that a test site should not be indexed. (Google)
• Crawl staging with the same settings as the baseline crawl and compare titles, headings, canonicals, meta robots, hreflang, schema, internal links, and word count.
• Check forms, checkout, search, downloads, and any third-party scripts.
• Test mobile layouts and page speed on the new templates.
• Confirm the new site’s canonical tags, sitemaps, and internal links use the final live URLs, not staging URLs.

Phase 4: Build the Redirect Map

• List every old URL that should survive: indexable pages, images, and PDFs that earn traffic or links.
• Map each old URL to the closest equivalent new URL. Do not send everything to the homepage.
• Use server-side permanent redirects. Google recommends 301 and 308 and advises “redirecting to the final destination directly” to avoid chains.
• Test the full map on staging with a crawler in list mode.
• Update internal links so they point to final URLs and do not rely on redirects.

Google’s redirect documentation is clear on the method: server-side redirects are the preferred option, and JavaScript redirects should be used only if server-side or meta refresh redirects are not possible, because Google may not see them if rendering fails.

Phase 5: Launch

For a host change, lower the DNS TTL ahead of time. Google suggests a conservative low value, for example, a few hours.

• Remove staging blocks: noindex tags and robots.txt Disallow rules left over from testing.
• Switch DNS or deploy, then check that SSL is valid on every hostname, including www and non-www.
• Submit the new XML sitemap in Search Console. For URL changes, also keep a temporary sitemap of old URLs so Google finds the redirects faster.
• For a domain or subdomain change, submit a Change of Address in Search Console for the old site. Google says it is not needed for HTTP to HTTPS, www changes on the same domain, or path changes within a domain.
• Spot-check your top 50 URLs by hand and crawl the live site immediately.
• Confirm analytics tags fire on the new site.

Phase 6: Monitor After Launch

Google says to watch traffic on both old and new URLs and server logs where available, and it describes a temporary dip in crawl rate after a hosting move as normal. The schedule below is our recommended routine, not a Google requirement.

Phase 7: Clean Up

• Keep redirects in place for as long as possible. Google says “generally at least 1 year.”
• Keep the old domain registered and renewed.
• Shut down the old hosting only when you are confident users and Googlebot are being served from the new host.
• Record what changed and what you learned for the next migration.

WordPress-Specific Migration Steps

Generic checklists stop at redirects. A WordPress move has database and plugin details that cause most of the quiet failures. The WordPress.org migration handbook covers the mechanics, and these are the points to watch.

Back up first. Take a file and database backup before touching anything, and know how you would restore it.

Update wp-config.php. If the database name, user, or password changes on the new server, update it.

Handle domain changes carefully. Changing URLs means a search and replace in the database. The handbook warns that a full-database replace “can cause issues with data serialization” and says never to change the contents of the GUID column.

Use a serialization-aware tool. WP-CLI’s search-replace command and the Better Search Replace plugin support serialized data. Better Search Replace also offers a dry run so you can see how many fields would change before committing.

Re-save permalinks. After the move, visit Settings> Permalinks and save, then test several URLs. A broken rewrite rule produces site-wide 404s.

Clear every cache layer. Page cache, object cache, CDN cache, and browser cache can all serve old URLs or old HTML.

Check hardcoded URLs. Page builders, theme options, widgets, menus, and custom code can hold the old domain even after the database replacement.

Rebuild the redirect layer. Server rules in .htaccess or Nginx work well for large maps. The Redirection plugin suits smaller maps, supports CSV import and export, and tracks 404 errors, which helps after launch.

Review SEO plugin settings. Confirm the XML sitemap, canonical output, schema, and the indexing settings match the old site.

Treat multisite as a separate project. The WordPress.org handbook notes that multisite also requires reviewing additional tables and option values.

If your move also changes the theme or structure, our guide to WordPress technical SEO covers the crawlability, indexing, and canonical checks to repeat after launch. The WordPress SEO guide covers the on-page settings to verify on the new site.

Website Migration Tools

No single tool covers a migration. Choose by job.

Plugin installs are convenient for small and medium sites. They can struggle with very large databases, tight host limits, or multisite, and those cases often call for command-line tools or a developer-led migration. A migration plugin moves files and data. It does not create your redirect map, protect your rankings, or test your templates.

Common Website Migration Mistakes

Redirecting everything to the homepage. Map old pages to the most relevant new page. Pages with no equivalent can return a 404 or 410, and that is acceptable when intentional.

• Launching with staging blocks still on. A leftover noindex or Disallow: / is the fastest way to disappear from search.
• Skipping the baseline crawl. Without it, you cannot prove what changed or what to fix.
• Changing too much at once. A new domain, theme, structure, and host in one release makes problems hard to isolate.
• Forgetting images, PDFs, and other assets. If they earn traffic or links, they need redirects too.
• Letting redirects run through chains. Point each old URL straight to its final destination.
• Removing redirects too early. Google advises keeping them generally for at least a year.
• Declaring victory after launch day. Monitoring is part of the migration.

How Long Until Rankings Recover?

Nobody can promise a timeline. Google says a medium-sized site can take a few weeks or more for the new URLs to show, and larger sites take longer. Temporary movement in rankings and traffic is common. What matters is that the trend stabilizes and your baseline comparison shows the cause of any gap, such as missing redirects, lost content, or slower pages. If key pages are still down after you have fixed the technical causes, treat it as a content and intent review, not only a migration issue.

When to Get Help With a WordPress Migration

A small brochure site with unchanged URLs can often be moved with a careful plugin workflow. Get specialist help when:

• Your domain or URL structure is changing.
• The site has thousands of URLs, years of backlinks, or significant organic traffic.
• You run WooCommerce, memberships, multisite, or custom code.
• The migration is combined with a redesign or platform change.
• You cannot afford downtime or a visibility drop.

Techesprit handles WordPress builds and moves as part of our WordPress development services, and pairs them with WordPress SEO services so redirects, templates, and indexing are checked together. You can also review our case studies to see the type of work we do.