WordPress Migration Checklist: How to Move a Website Safely

Moving a WordPress website can look simple from the outside.

Copy the files. Move the database. Point the domain to the new server. Done.

In practice, a WordPress migration can affect much more than hosting.

A poorly planned migration can break forms, images, plugins, integrations, user accounts, URLs, redirects, analytics, and search visibility. If the migration also changes your domain, URL structure, design, or CMS, the SEO risk becomes even greater.

A safe WordPress migration is therefore less about moving files and more about moving the entire website without losing functionality, data, traffic, or search equity.

WordPress Migration Checklist at a Glance

Before starting, use this checklist as your migration roadmap:

• Define the reason and scope of the migration
• Audit the existing website
• Record the current URLs
• Back up the database and website files
• Back up media and important configuration
• Record plugins, themes, integrations, and custom code
• Set up the new hosting or WordPress environment
• Create a staging/development copy
• Transfer WordPress files
• Transfer the database
• Update database configuration
• Check domain and URL settings
• Test the migrated site before changing DNS
• Test forms, search, login, payments, and integrations
• Review SEO settings
• Prepare URL redirects if URLs are changing
• Update internal links
• Check canonical URLs
• Check robots.txt and noindex settings
• Generate the new XML sitemap
• Verify the new site in Google Search Console
• Point the domain to the new environment
• Run final live-site checks
• Monitor traffic, indexing, errors, and conversions
• Keep the old environment available until the migration is confirmed stable

The exact steps vary depending on the type of migration.

What Is a WordPress Migration?

A WordPress migration is the process of moving a WordPress website from one environment to another.

That can mean several different things.

Common WordPress migration types

Not all migrations carry the same level of risk.

A hosting migration where the URLs remain unchanged is very different from changing your domain and URL structure at the same time.

Google specifically distinguishes infrastructure moves where URLs remain unchanged from site moves involving URL changes. For hosting-only migrations, the main concerns include preparing the new infrastructure, changing DNS, and monitoring traffic.

Why WordPress Migrations Go Wrong

Most migration problems aren't caused by copying WordPress files.

They happen because something important was forgotten.

Common examples include:

• Missing database data
• Broken image URLs
• Incorrect domain settings
• Missing plugins
• Missing custom code
• Broken forms
• Lost customer accounts
• Incorrect file permissions
• DNS mistakes
• Missing redirects
• Incorrect canonical URLs
• Accidental noindex
• Robots.txt blocking crawlers
• Broken internal links
• Missing analytics
• Lost tracking scripts
• Incomplete WooCommerce data
• Incorrect PHP or server configuration
• Expired API credentials

SEO problems can be even more serious.

If old URLs disappear without proper redirects, valuable search traffic and backlinks can be affected.

Google recommends preparing the new site, mapping old URLs to their new destinations, implementing permanent redirects where URLs change, updating internal links and sitemaps, and monitoring both the old and new URLs during the move.

Step 1: Define the Migration Scope

Before touching the website, write down exactly what is changing.

For example:

"We're moving the existing WordPress website from Hosting A to Hosting B. The domain, URLs, design, content, and WordPress installation will remain unchanged."

That's a relatively controlled migration.

Compare that with:

"We're moving from an old domain to a new domain, redesigning the website, changing the URL structure, replacing the theme, removing old content, and moving to new hosting."

That's a much higher-risk project.

Document the changes

Record whether you're changing:

• Domain
• Hosting
• Server
• WordPress installation
• Theme
• Plugins
• URLs
• Content
• Design
• Information architecture
• Database
• PHP version
• CDN
• DNS
• Email infrastructure
• E-commerce system
• Third-party integrations

Try not to change everything at once unless there is a strong reason to do so.

Google's site-migration guidance recommends changing one major element at a time where practical because combining multiple changes makes it harder to identify the source of problems.

Step 2: Audit the Existing Website

Before migration, create a baseline.

You need to know what currently exists so you can confirm that everything important made it to the new environment.

Record the website's current state

Document:

• Total URLs
• Important landing pages
• Blog posts
• Categories
• Products
• Customer accounts
• Orders
• Media
• Forms
• Plugins
• Theme
• Custom code
• Integrations
• Analytics
• Search Console
• XML sitemap
• Robots.txt
• Redirects
• Canonicals
• Structured data

Identify important URLs

Pay particular attention to pages that have:

• Organic traffic
• Search rankings
• Backlinks
• Leads
• Sales
• High engagement
• Important business information

Your sitemap, analytics, Search Console data, and CMS can all help identify important URLs. Google specifically recommends using sitemaps, analytics, Search Console, and other URL sources when preparing a URL mapping for a site move.

Don't start the migration until you understand what you're moving.

Step 3: Crawl the Existing Website

A full crawl gives you a useful snapshot of the current website.

Record:

• URLs
• Status codes
• Titles
• Meta descriptions
• H1s
• Canonical URLs
• Internal links
• Images
• Redirects
• Indexability
• Broken links

This gives you a baseline for comparing the new website.

If the old site has 500 indexable URLs and the new site has only 300, you need to know why.

Some pages may have been intentionally removed.

Others may have been forgotten.

That difference matters.

Step 4: Create a Complete Backup

Never begin a migration without a verified backup.

You generally need to protect at least two major components:

WordPress files

These can include:

• WordPress core files
• Themes
• Plugins
• Uploads
• Custom files
• Configuration files

Database

The database contains important WordPress data such as:

• Posts
• Pages
• Comments
• Users
• Settings
• Taxonomies
• Custom fields
• Other site-specific data

WordPress's own documentation explains that its export functionality can export posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users.

For a full production migration, however, don't assume the WordPress XML export alone is a complete website backup. You also need the actual database and website files appropriate to your migration method.

Backup checklist

• Full database backup
• WordPress files backup
• wp-content backup
• Uploads/media backup
• Theme backup
• Plugin backup
• Configuration backup
• Export important DNS information
• Save existing redirect rules
• Verify that backups can actually be restored

A backup that has never been tested is not much of a recovery plan.

Step 5: Record Your Current WordPress Environment

Before migration, document the technical environment.

Record:

• WordPress version
• PHP version
• MySQL/MariaDB version
• Active theme
• Installed plugins
• Active plugins
• Plugin versions
• PHP extensions
• Server configuration
• Cron jobs
• CDN
• Caching system
• SSL configuration
• DNS records

Also document any custom development.

For example:

• Custom theme files
• Custom plugins
• Code snippets
• API integrations
• Custom cron jobs
• Webhooks
• Server-level redirects
• .htaccess rules

This prevents the common problem of discovering after migration that an important feature depended on something nobody documented.

Step 6: Prepare the New Hosting Environment

Set up the destination before moving production traffic.

The new environment should have:

• Compatible PHP version
• Suitable database
• SSL support
• Adequate server resources
• Correct file permissions
• Backup capability
• Staging/development access
• CDN configuration if required

The new environment should be tested before DNS changes.

If you're moving to a new host without changing URLs, Google recommends preparing the new infrastructure, testing it, changing DNS, monitoring traffic, and only shutting down the old infrastructure once you're confident users and crawlers are being served correctly from the new environment.

Step 7: Create a Staging or Development Copy

Don't perform a major migration directly on the live website unless the project genuinely requires it.

Create a controlled copy where you can:

• Import the database
• Upload files
• Update configuration
• Test plugins
• Test themes
• Check URLs
• Fix errors
• Test forms
• Test integrations
• Run crawls

Keep staging out of search

A staging site should not accidentally become indexed.

Use appropriate access controls and temporary search-engine blocking where appropriate.

But remember to remove temporary noindex or crawling restrictions before launch.

Google specifically warns that migration environments sometimes retain noindex directives or robots.txt blocks after launch, preventing the new site from being indexed properly.

Step 8: Move the WordPress Files

There are several ways to transfer the site.

Depending on the environment, you may use:

• Hosting migration tools
• SFTP
• SSH
• Server-to-server transfer
• Backup restoration
• Managed WordPress migration tools

The correct method depends on the hosting environment and site size.

Make sure all required files are transferred, including:

• wp-content/uploads
• Themes
• Plugins
• Custom files
• Configuration files
• Any application-specific assets

For large sites, don't assume that the homepage loading correctly means the entire file transfer was successful.

Check media and less frequently visited sections too.

Step 9: Move the WordPress Database

The database is just as important as the files.

A WordPress database can contain:

• Pages
• Posts
• Users
• Products
• Orders
• Settings
• Plugin data
• Custom fields
• Taxonomies

For a WooCommerce store, this becomes even more important because customer and order data can be business-critical.

After importing the database, confirm that:

• Tables exist
• Database credentials work
• WordPress connects correctly
• Content appears correctly
• Users exist
• Products exist
• Orders exist
• Plugin data is intact

Don't assume that a successful database import means the migration is complete.

Step 10: Update WordPress Configuration

The destination server may have different:

• Database name
• Database user
• Database password
• Host
• File paths
• Environment variables

Update the configuration appropriately.

Then check:

• Database connection
• Site URL
• Home URL
• File paths
• SSL
• Caching
• Server rules

If the domain is changing, don't simply replace URLs blindly across the database.

Serialized data, plugin settings, media references, and custom fields may require migration-aware tools or scripts.

Step 11: Check URLs Before Launch

This is one of the most important parts of the migration.

If URLs are staying exactly the same, your migration is simpler.

If URLs are changing, create an old URL → new URL mapping.

For example:

Don't redirect every old URL to the homepage.

A redirect should take users to the most relevant equivalent destination.

Google specifically warns against redirecting large numbers of unrelated old URLs to one destination such as the homepage because this can confuse users and may be treated as a soft 404.

Step 12: Implement 301 Redirects

If URLs change permanently, use permanent redirects.

Google recommends server-side permanent redirects such as 301 or 308 when possible.

Good redirect

Old:

https://example.com/wordpress-services/

New:

https://example.com/services/wordpress-development/

301 → New URL

Bad redirect

Old page

↓

Homepage

unless the homepage is genuinely the relevant replacement.

Avoid redirect chains

Don't create:

Old URL

↓

Temporary URL

↓

Another URL

↓

Final URL

Instead:

Old URL

↓

Final URL

Google recommends avoiding redirect chains and keeping the number of hops low because chains add latency and can complicate crawling.

Step 13: Update Internal Links

Don't rely on redirects to handle all internal links.

Update your new website so internal links point directly to the correct new URLs.

Check:

• Navigation
• Footer
• Blog posts
• Service pages
• Category pages
• Breadcrumbs
• Related-content modules
• CTAs
• Images
• Canonical references

Google specifically recommends updating internal links to point to the new URLs during a site move.

This also improves the user experience because visitors don't need to pass through redirects unnecessarily.

Step 14: Check Canonical URLs

Every important page should have the correct canonical URL.

After migration, verify that canonical tags:

• Point to the correct domain
• Use HTTPS where appropriate
• Don't point back to the old site
• Don't reference staging URLs
• Match the preferred URL structure

Google recommends that new URLs use self-referencing canonical annotations where appropriate after a URL-changing migration.

Step 15: Check Robots.txt and Noindex Settings

This is one of the easiest migration mistakes to make.

A staging site might intentionally contain:

Disallow: /

or pages may use:

<meta name="robots" content="noindex">

That's fine during development.

It's a serious problem if those settings remain on the production website.

Before launch:

• Check robots.txt
• Check page-level noindex settings
• Check HTTP headers
• Check SEO plugin settings
• Check individual page settings
• Check XML sitemap accessibility

Google explicitly lists accidental noindex and robots.txt blocks among common migration problems.

Step 16: Test Forms and Lead Generation

Don't assume forms survived the migration.

Test every important form.

Check:

• Submission
• Validation
• Email delivery
• Confirmation messages
• CRM integration
• Automation
• Spam protection
• Thank-you pages
• Tracking

For a lead-generation website, this is critical.

A website can look perfect while silently losing every new inquiry because the SMTP configuration or form integration broke during migration.

Step 17: Test WooCommerce Functionality

If you're migrating a WooCommerce store, the checklist becomes longer.

Test:

• Products
• Variations
• Categories
• Images
• Inventory
• Prices
• Coupons
• Customer accounts
• Orders
• Checkout
• Payment gateways
• Shipping
• Tax settings
• Emails
• Refund workflows
• Order notifications
• Integrations

For stores with active transactions, plan the migration carefully around order activity.

You may need a short maintenance window or a process for synchronizing new orders and customer data created during the migration.

We provide WooCommerce migration work covering migrations from platforms such as Shopify, Magento, OpenCart, and PrestaShop, including product data, customer accounts, order history, and SEO redirects.

For businesses moving an existing store, our WooCommerce development services can be considered when the migration also requires custom development, integrations, or performance work.

Step 18: Test Analytics and Tracking

A migration can accidentally remove tracking.

Check:

• Google Analytics
• Google Tag Manager
• Google Search Console
• Conversion tracking
• Ad pixels
• Remarketing tags
• Call tracking
• Heatmaps
• Other third-party scripts

Test actual events rather than simply checking whether the script appears in the source code.

For example:

Submit a form → confirm conversion event → confirm analytics receives it.

Step 19: Test Email and DNS

If you're changing hosting, don't assume email is unaffected.

Review DNS records such as:

• A
• AAAA
• CNAME
• MX
• TXT
• SPF
• DKIM
• DMARC

If your website and email use the same domain, an incorrect DNS change can affect email delivery.

Before changing DNS, document the current records.

Then reproduce only what is required in the new configuration.

Step 20: Run a Full Pre-Launch Crawl

Before switching traffic, crawl the new website.

Look for:

• 404 errors
• 5xx errors
• Redirect chains
• Redirect loops
• Broken internal links
• Missing titles
• Missing descriptions
• Duplicate titles
• Missing H1s
• Incorrect canonicals
• Noindex pages
• Blocked resources
• Orphan pages

Compare the crawl against your original website inventory.

This is one of the best ways to identify content or URL loss before launch.

Step 21: Run a Mobile and Performance Check

Test the new website on:

• Desktop
• Tablet
• Mobile

Check:

• Layout
• Navigation
• Images
• Forms
• Buttons
• Tables
• Page speed
• Core Web Vitals
• Fonts
• Third-party scripts

If you're changing hosting at the same time, compare server response and page performance before and after the move.

A migration should not accidentally turn a healthy website into a slower one.

Step 22: Take a Final Backup

Before changing DNS or switching production traffic:

Take one final backup of the current live website.

This gives you a known recovery point immediately before launch.

Also preserve:

• Database
• Files
• Redirect configuration
• DNS records
• Current sitemap
• Crawl data
• Analytics baseline
• Important SEO data

Step 23: Change DNS or Point the Domain

Once the new site has passed testing, point the domain toward the new environment.

Depending on the setup, this may involve:

• A record
• CNAME
• Nameserver changes
• CDN configuration
• Load balancer configuration

The exact DNS propagation behavior depends on the existing setup and DNS TTL.

Don't shut down the old server immediately.

Keep it available while you confirm that the new site is working correctly.

Google recommends monitoring traffic during a hosting migration and only shutting down the old infrastructure after you're confident that users and Googlebot are receiving the site correctly from the new environment.

Step 24: Run the Live-Site Checklist

Immediately after the migration, check the live site.

Homepage

• Loads correctly
• HTTPS works
• Images load
• Navigation works

Important pages

• Services
• Products
• Categories
• Contact
• Blog
• Landing pages

Functionality

• Forms
• Search
• Login
• Checkout
• Payments
• Integrations

SEO

• Indexability
• Canonicals
• Robots.txt
• Sitemap
• Redirects
• Internal links

Analytics

• Analytics
• Tag Manager
• Conversion tracking
• Ad tracking

Step 25: Submit and Validate the New Sitemap

If URLs changed, make sure your sitemap contains the new URLs.

Submit the new sitemap through Google Search Console.

Google recommends submitting the new sitemap after a site move to help Google discover the new URLs.

Don't leave the sitemap containing old URLs when the new site has a different URL structure.

Step 26: Verify Google Search Console

Make sure the appropriate properties and URL variants are verified.

For domain migrations, verify the relevant old and new properties.

Then monitor:

• Indexing
• Sitemap status
• Crawl errors
• Search performance
• Page indexing
• Search queries
• URL inspection

Google recommends using Search Console throughout a site move to monitor indexing and traffic changes.

Step 27: Monitor SEO After Launch

Don't assume everything is fine because the website loads.

Watch:

• Organic traffic
• Impressions
• Clicks
• Rankings
• Indexed URLs
• 404 errors
• Redirect errors
• Crawl errors
• Search Console warnings

Some ranking fluctuation is normal during a migration because Google needs to crawl and process the new URLs.

Google says a medium-sized site may take a few weeks for most pages to move through its index, while larger sites can take longer.

The goal is not to panic over every short-term ranking movement.

The goal is to identify unexpected problems quickly.

Step 28: Keep Redirects in Place

If you've changed URLs, don't remove the redirects immediately.

Google recommends keeping redirects in place for as long as possible and generally for at least one year so Google has time to process the move and transfer signals to the new URLs.

For users, keeping redirects longer can also make sense, particularly when old URLs are still being shared or linked externally.

How Long Does a WordPress Migration Take?

There isn't one standard timeline.

A small WordPress website moving between hosts may take a few hours to a day when the environment is straightforward.

A larger website can take several days or longer when it includes:

• Hundreds of pages
• Large media libraries
• WooCommerce
• Custom functionality
• Multiple integrations
• URL changes
• SEO migration
• DNS changes
• Complex hosting environments

Most of our WordPress projects take 2–4 weeks, but a simple hosting migration can be much shorter than a full redesign or rebuild.

The important distinction is between migration execution time and migration preparation.

A technically simple move can still require careful planning if the website generates substantial traffic or revenue.

Frequently Asked Questions

What is the safest way to migrate a WordPress website?

The safest approach is to back up the current site, prepare and test the destination environment, transfer the files and database, test functionality before changing DNS, prepare redirects if URLs are changing, then monitor the live site after launch.

Will WordPress migration affect SEO?

It can. A hosting-only migration where URLs remain unchanged generally presents less SEO risk than a domain or URL migration. When URLs change, incorrect redirects, missing pages, canonical errors, internal-link problems, or accidental noindex settings can affect search visibility.

Do I need 301 redirects when moving WordPress to a new host?

Not necessarily if the URLs remain exactly the same. A hosting migration without URL changes generally doesn't require redirects. If URLs or the domain change, permanent redirects are normally needed to map old URLs to their new destinations.

How do I migrate WordPress without losing SEO?

Preserve valuable URLs where possible, crawl the existing website, map old URLs to new ones when they change, implement permanent redirects, update internal links, preserve important content and metadata, verify canonicals, update the sitemap, and monitor Search Console after launch.

How long should I keep 301 redirects after a migration?

Google recommends keeping redirects in place for as long as possible and generally for at least one year after a site move.

Can I migrate WordPress without downtime?

Often, yes. Using a staging environment and switching DNS after the new site has been tested can reduce downtime. The exact process depends on the hosting setup, DNS configuration, website complexity, and whether the site receives ongoing transactions.

What happens to my WordPress database during migration?

The database needs to be transferred to the new environment and connected to the migrated WordPress files. It contains important information such as posts, pages, users, settings, and plugin data. WooCommerce sites also need careful handling of products, customers, orders, and related data.

Can I migrate a WooCommerce website?

Yes, but WooCommerce migrations require additional testing because the store may contain products, customer accounts, orders, payments, shipping settings, inventory, and third-party integrations.

Should I migrate and redesign my WordPress website at the same time?

It depends. Combining the projects can make sense if the current site needs both a new technical environment and a redesign. However, changing hosting, URLs, design, architecture, and content simultaneously can increase migration risk. Where practical, isolate major changes so problems are easier to diagnose.

What should I do after a WordPress migration?

Monitor uptime, forms, conversions, analytics, Search Console, indexing, rankings, 404 errors, redirects, server errors, and performance. Keep the old environment available until you're confident the migration is stable.

Final Takeaway

A WordPress migration isn't just a file transfer.

It's a controlled transition of your website, data, functionality, URLs, tracking, and search presence from one environment to another.

The website being live doesn't mean the migration is finished.

You still need to confirm that:

• Users can access everything.
• Forms and transactions work.
• Analytics are tracking.
• Search engines can crawl the site.
• Important URLs are indexed.
• Redirects work.
• Organic traffic is behaving normally.
• The new server can handle the traffic.

For a small website, you may be able to handle the migration yourself.

For a high-traffic business website, WooCommerce store, or SEO-dependent site, the cost of a migration mistake can be far greater than the cost of getting the move right the first time.

If you're planning a WordPress hosting, domain, redesign, or platform migration, talk to our experts.

The team can review the existing website, identify migration risks, and provide a fixed-price proposal