Website Migration Checklist

A website migration can mean two quite different things. One project may move the same website to new hosting without changing any public URLs. Another may change the domain, platform, URL structure, content, or rendering method.

Both need careful preparation, but they do not use the same checklist. A hosting-only move is mainly an infrastructure cutover. A migration that changes URLs or content also needs mapping, redirects, and preservation of the signals that search engines already understand.

Choose the migration path before planning

Start by writing down exactly what will change.

• Same URLs, new infrastructure: the hosting provider, server, origin, CDN, or runtime changes, while visitors continue to use the same domain and paths.
• URLs or content delivery change: the project changes the domain, protocol, paths, CMS, framework, rendering method, templates, navigation, or substantial content.

Do not build a redirect map merely because the server changes if every public URL remains identical. Conversely, do not treat a redesign or platform replacement as a simple hosting move when it changes crawlable pages, canonicals, or internal links.

When possible, change one major layer at a time. Moving hosting, changing the domain, replacing the platform, rewriting content, and redesigning the interface in one launch makes failures much harder to isolate.

Path 1: move hosting without changing URLs

A hosting migration should move the website without losing forms, email, scheduled work, performance, search visibility, or administrative access. It is rarely just a file copy.

Inventory the complete setup

Document the systems that depend on the current host:

• Domain registrar, DNS provider, and current records
• Hosting account, server configuration, and control panel
• Website files, databases, storage, and uploads
• CMS or framework, runtime, PHP version, and extensions
• SSL certificates and renewal method
• Redirect, caching, CDN, firewall, and security rules
• Business email, transactional email, and verification records
• Cron jobs, queues, webhooks, and background workers
• Backups, retention, and a tested restoration path
• Forms, payment flows, booking systems, and third-party integrations

This prevents a successful page copy from hiding broken email, forms, callbacks, or background jobs.

Prepare and test the new infrastructure

Build the site on the new host before directing public traffic to it. Depending on the setup, testing may use a temporary hostname, preview domain, staging environment, or a local hosts-file override.

Check the pages and flows that matter: navigation, forms, search, booking, checkout, login, administration, images, downloads, redirects, API callbacks, scheduled work, and outbound email. Confirm that runtime versions, file permissions, environment variables, database settings, and cache behaviour match the application.

The new environment must also allow search-engine crawlers and real users once it becomes public. Check firewall, bot-management, rate-limit, and CDN settings rather than assuming configuration copied from another server is suitable.

Plan DNS, email, and the traffic switch

DNS may control much more than the website. Preserve mail exchange, sender authentication, service verification, and other unrelated records when changing the web origin. If Cloudflare or another CDN sits in front of the host, review its SSL mode, cache rules, redirects, firewall policies, and origin configuration as part of the same cutover. The guide to Cloudflare and website performance covers that layer in more detail.

Keep both environments available during the transition when practical. After changing DNS or the origin, monitor requests reaching the old and new infrastructure, verify that important pages still return the expected status codes, and investigate errors before shutting the old host down. Google’s guidance for changing hosting without changing URLs follows this prepare, switch, monitor, and retire sequence.

Path 2: change URLs, content, or delivery

When public URLs or the way important content is delivered changes, the migration also becomes an SEO mapping project. Existing pages, links, metadata, and crawl signals need an explicit destination on the new site.

Start with a complete URL inventory

Before building the redirect map, collect the URLs that currently matter.

Use several sources because no single source is complete:

• Crawl the current website
• Export indexed and submitted pages from Google Search Console
• Review XML sitemaps
• Export landing pages from analytics
• Include URLs with backlinks or referral traffic
• Include campaign, product, category, document, and image URLs where relevant
• Review server logs for URLs that crawlers and users still request

Record each URL’s status code, canonical target, indexability, title, primary heading, traffic, backlinks, and intended destination. This inventory becomes the reference for redirect mapping, testing, and post-launch monitoring.

It also reveals existing problems. The old website may already contain redirect chains, duplicate pages, orphaned content, or conflicting canonical signals. Decide which issues should be cleaned up during migration and which should be preserved temporarily to reduce launch risk.

Create an explicit URL map

Every important old URL should have a deliberate outcome:

• Keep the same URL
• Redirect to a close equivalent
• Consolidate into a stronger relevant page
• Return a real 404 Not Found or 410 Gone when no replacement exists

Do not redirect every removed URL to the homepage. A redirect should lead users and search engines to a page that satisfies approximately the same intent. Irrelevant redirects create a poor experience and may be treated like soft 404s.

Keep the mapping in a structured document that development, content, and SEO work can share. Include the old URL, new URL, reason, implementation status, and test result. This makes missing routes and accidental decisions visible before launch.

Preserve the signals that still matter

A migration often includes improvements, but useful existing signals should not disappear by accident.

For important pages, compare the old and new versions:

• Main content and purpose
• Page title and meta description
• Primary heading and heading structure
• Internal links
• Canonical URL
• Robots directives
• Structured data
• Language alternates
• Images, alt text, and downloadable files

The new page does not need to be identical, but it should still clearly serve the reason the old page ranked or received traffic. A technically correct redirect cannot compensate for replacing a useful page with thin or unrelated content.

Control staging carefully

The staging site should be available to the people testing it but unavailable to the public and search engines.

Use authentication or network-level access control where practical. A noindex directive is useful as an additional safeguard, but it must be removed before launch. Blocking the staging site only with robots.txt can prevent crawlers from seeing the noindex directive and does not protect private content from people who know the URL.

Create a launch check specifically for temporary controls:

• Remove staging authentication from the production environment
• Remove noindex from pages intended for search
• Confirm production robots.txt allows the correct areas
• Replace staging domains in canonicals, links, schema, and sitemaps
• Remove test analytics, API endpoints, and credentials

Temporary migration settings have a habit of becoming permanent production problems when they are not tracked explicitly.

Implement redirects without chains

Use server-side permanent redirects for URLs that have permanently moved. Point each old URL directly to its final destination instead of routing through earlier versions.

For example:

old URL -> final new URL

Avoid:

old URL -> previous redesign URL -> HTTP version -> final new URL

Redirect chains slow requests, consume crawl resources, and create more places for a migration to fail. Existing external links may still point to very old URLs, so include historical redirects in the review and update them to the final destination where possible.

Google’s guidance for site moves with URL changes recommends keeping redirects for as long as possible, generally at least one year. In practice, useful redirects can remain longer when old links and bookmarks still exist.

Update internal signals to the final URLs

Redirects are a safety net, not the preferred route through the new site.

Update internal links, navigation, canonical tags, hreflang references, structured data, and XML sitemaps so they point directly to the final production URLs. This helps users and crawlers follow the new structure without unnecessary redirects or conflicting signals.

The sitemap should contain canonical, indexable, successful URLs only. Do not include redirected, blocked, duplicate, or missing pages. This connects directly to the wider work around crawlability and indexation.

Test before launch

Crawl the staging site and compare it with the current production inventory. Test more than the homepage and a few templates.

Check:

• Every mapped redirect when URLs change
• Important pages and user journeys
• Status codes and response headers
• Canonicals and robots directives
• Internal links and orphaned pages
• XML sitemaps
• Structured data
• Mobile layout and accessibility
• Forms, search, checkout, login, and integrations
• Page speed and rendered content
• Error pages and missing URLs

Automate repeatable checks where possible. A simple script or crawler export comparison can find hundreds of missing redirects or incorrect canonicals more reliably than manual browsing.

Keep the launch controlled

Avoid launching immediately before a weekend, holiday, or period when the right people cannot respond. Make sure backups, rollback steps, DNS access, redirect configuration, analytics, and monitoring are ready before the switch.

At launch:

1. Deploy the production environment and any redirect rules required by URL changes.
2. Confirm temporary staging controls are gone from production.
3. Test a representative group of important old and new URLs.
4. Crawl the live site.
5. Submit the new sitemap.
6. Use Search Console’s Change of Address tool when moving domains and the tool is applicable.
7. Check logs, analytics, forms, integrations, and error monitoring.

A rollback plan should define what must fail before the old system is restored. Without that decision in advance, teams can spend critical launch hours debating whether a problem is serious enough.

Monitor after launch

Migration work continues after the new site is public.

Watch:

• Indexation and crawl reports
• Organic landing pages and search traffic
• 404, 500, and redirect responses
• Server logs and crawler activity
• Sitemap processing
• Canonical selection
• Rankings for important queries
• Conversion and form completion
• Performance and Core Web Vitals

Compare results with the benchmarks collected before migration. Some fluctuation is normal while search engines recrawl and process the changes, but technical errors should be investigated quickly rather than dismissed as temporary.

The conversion-tracking QA and reconciliation workflow provides the detailed checks for proving that forms, bookings, purchases, campaign attribution, and operational lead totals survived the move.

Common migration mistakes

The same avoidable problems appear repeatedly:

• The team does not distinguish a hosting cutover from a URL-changing migration
• DNS changes overwrite mail or verification records
• Forms, queues, cron jobs, or API callbacks are not tested on the new host
• Redirect mapping starts too late
• All old URLs redirect to the homepage
• Internal links still point through redirects
• Production launches with noindex
• Canonicals or schema still reference staging
• Valuable content is removed without an equivalent
• JavaScript rendering hides important content
• The sitemap contains redirects and errors
• Tracking or conversion flows stop working
• Nobody monitors the site after launch

A migration does not need to preserve every weakness of the old website. It does need to preserve the value people and search engines already rely on while the underlying platform changes.

Frequently Asked Questions

Is a hosting migration only a matter of copying the website files?

No. The database, runtime, DNS, email records, SSL, caching, backups, scheduled tasks, forms, and integrations may all depend on the existing environment. They need to be inventoried and tested even when every public URL stays the same.

Can changing DNS for a hosting migration affect business email?

Yes. DNS can also control mail delivery, sender authentication, service verification, and other systems. Preserve those records and change only the values required for the website cutover.

Should every removed URL redirect to the homepage?

No. A redirect should lead to a page that satisfies approximately the same intent as the original. Redirecting everything to the homepage creates a poor experience and can be treated like a soft 404 by search engines.

Is blocking a staging site with robots.txt enough to keep it out of search results?

No. Blocking with robots.txt alone can prevent crawlers from ever seeing a noindex directive on the page, and it does not protect private content from anyone who already knows the URL. Authentication or network-level access control is needed too.

Does search ranking stabilize immediately after a migration launches?

Not necessarily. Some fluctuation is normal while search engines recrawl and process the changes, but that is different from a technical error, which should still be investigated quickly rather than dismissed as temporary.

Migration checklist

Before approving the launch, confirm that:

• The migration path and every planned change are documented
• Hosting, DNS, email, runtime, backups, scheduled work, and integrations are inventoried where relevant
• The new infrastructure and important user journeys have been tested before public traffic moves
• The existing URL inventory is complete enough to protect important pages when URLs or content change
• Every important old URL has a tested outcome when redirects are required
• Redirects point directly to relevant final URLs rather than through chains
• Content and metadata changes are intentional
• Internal links, canonicals, language alternates, schema, and sitemaps use production URLs
• Temporary staging controls are removed from production
• Important user journeys and integrations work
• Analytics and monitoring are active
• Backups and rollback steps are ready
• Post-launch ownership and checks are agreed

Good migration work is mostly preparation, explicit decisions, and careful verification. The visible launch may happen in one day, but stability and search visibility depend on the work completed before and after it. If a business website is approaching a hosting, platform, domain, or URL change, send me the current setup, planned destination, and expected launch window before the migration plan is locked in.