Website Migration Checklist: 30 Essential Steps

A website migration checklist helps you move or rebuild a website without unnecessarily losing search rankings, traffic, conversions, content, or functionality. A safe migration requires a complete URL inventory, page-level redirect mapping, technical and functional testing, analytics validation, a rollback plan, and structured post-launch monitoring. Use the following 30 steps to manage the process from initial planning through stabilization.

---

TL;DR

• Benchmark rankings, traffic, conversions, backlinks, and Core Web Vitals.
• Back up website files, databases, configurations, and DNS records.
• Map important old URLs to their closest relevant new destinations.
• Test content, redirects, forms, SEO elements, analytics, and security.
• Launch during a lower-traffic period with a documented rollback plan.
• Monitor indexing, crawl errors, traffic, revenue, and conversions.
• Keep permanent redirects active for at least one year.

---

What Is a Website Migration?

A website migration is a substantial change to a website’s domain, platform, hosting environment, URL structure, design, content, or technical infrastructure.

Common examples include:

• Moving from HTTP to HTTPS
• Changing a domain name
• Moving to another CMS
• Rebuilding a website with a new framework
• Changing hosting providers
• Consolidating multiple websites
• Redesigning a website and changing its URLs
• Restructuring navigation or content
• Moving from a subdomain to a subfolder
• Changing international URL structures

Migration does not automatically improve SEO, speed, or conversions. The outcome depends on how well the team preserves content, URLs, metadata, internal links, tracking, functionality, and technical signals.

Google recommends changing one major element at a time when practical. Combining a domain change, CMS replacement, redesign, and content rewrite in one release makes performance changes harder to diagnose. Review Google’s official site migration guidance before planning a migration involving URL changes.

---

---

Which Type of Website Migration Are You Planning?

Different migrations create different risks. Define the migration type before building your website migration plan.

Migration type	Primary risk	Critical control
Domain migration	Lost authority and indexing signals	Page-level permanent redirects
CMS migration	Missing content or functionality	Content and feature parity testing
Hosting migration	Downtime or server errors	DNS, SSL, capacity, and uptime testing
URL restructuring	Broken links and ranking loss	Complete old-to-new URL mapping
Website redesign	Changed content and user journeys	SEO, UX, and conversion testing
HTTP to HTTPS	Mixed content and redirect problems	SSL, canonical, sitemap, and redirect checks
Website consolidation	Irrelevant redirect destinations	Page-level content mapping
International migration	Incorrect regional targeting	Hreflang and locale validation

A hosting migration without URL changes is generally less risky for SEO than a domain or URL migration. However, it can still affect uptime, loading speed, security, and search-engine crawl capacity.

---

What Should You Do Before Website Migration?

1. Define the scope and success criteria

Document exactly what will change and what must remain stable.

Useful success criteria include:

• No loss of revenue-generating content
• All priority URLs redirected correctly
• No critical checkout or form failures
• Analytics collecting accurate data from launch
• Organic traffic returning to an agreed range
• Core Web Vitals maintained or improved
• No unresolved critical security issues

Do not treat “the new website is live” as the only measure of success. A website can launch on schedule while losing rankings, leads, or revenue.

2. Assign clear ownership

A website migration may involve:

• Project manager
• Developer or DevOps engineer
• SEO specialist
• UX designer
• Content manager
• QA engineer
• Analytics specialist
• Security reviewer
• Business stakeholder

Every checklist item should have an owner, deadline, priority, status, and approval requirement.

3. Benchmark current performance

Create a pre-migration baseline using at least 28 days of data. For a seasonal business, also compare performance with the equivalent period from the previous year.

Record:

• Organic clicks and impressions
• Rankings for priority queries
• Sessions and conversions by landing page
• Leads or revenue by page
• Indexed-page count
• Backlinks to important URLs
• Crawl errors and server responses
• Page speed and Core Web Vitals
• Form and checkout completion rates

Google’s current Core Web Vitals are LCP, INP, and CLS. Recommended “good” thresholds are LCP within 2.5 seconds, INP within 200 milliseconds, and CLS of 0.1 or less at the 75th percentile. Consult the official Web Vitals documentation when recording the baseline.

4. Crawl and inventory the existing website

Combine URLs from:

• XML sitemaps
• Website crawls
• Google Search Console
• Analytics landing-page reports
• CMS exports
• Server logs
• Backlink tools
• Paid campaign landing pages

Do not rely only on the XML sitemap. It may exclude orphan pages, downloadable files, campaign URLs, media, or old pages that continue to receive traffic and backlinks.

Before finalizing the inventory, conduct a broader technical, content, usability, and conversion review using this website evaluation checklist. This helps identify existing problems that should not be transferred to the new website.

5. Identify priority URLs

Flag pages that generate:

• Organic traffic
• Leads or sales
• Quality backlinks
• Branded visibility
• Paid advertising traffic
• Important customer journeys
• Product usage or downloads

Test these URLs first and monitor them most closely after launch.

6. Create an old-to-new URL map

Give every important old URL an appropriate outcome.

Old URL situation	Required action
Equivalent new page exists	Redirect to the equivalent page
Content is merged into another page	Redirect to the consolidated page
URL remains unchanged	Retain and test the URL
No relevant replacement exists	Return a genuine 404 or 410

Do not redirect every deleted URL to the homepage. When the destination is unrelated, search engines may treat it as a soft 404.

7. Back up everything

Back up:

• Website files
• Databases
• Media
• CMS configurations
• Environment variables
• Redirect rules
• DNS records
• SSL configurations
• Analytics and tag-manager settings

Test whether the backup can be restored. A backup that has never been validated is not a dependable rollback plan.

8. Prepare launch and rollback plans

Document:

• Launch date and time
• Expected maintenance window
• Go or no-go criteria
• Decision-makers
• Communication channels
• Rollback triggers
• Rollback owner
• Escalation process

If the project involves changing the CMS, framework, hosting environment, or core architecture, record the dependencies and rollback conditions in a formal technology migration strategy.

Launch during a predictable lower-traffic period, with technical and business stakeholders available afterward.

---

How Should You Prepare the New Website?

9. Build a protected staging environment

The staging environment should closely reflect production. Protect it from premature indexing through authentication or controlled access.

If staging uses noindex directives or restrictive robots.txt rules, include their removal as a launch-day task.

10. Preserve important content

Compare every priority old page with its new version for:

• Main copy
• Heading structure
• Images and alt text
• Videos and downloadable files
• Author information
• Publication and update dates
• Structured data
• Calls to action
• Internal links

A redesign should not accidentally remove content that supports rankings or conversions.

11. Preserve essential SEO elements

Check every indexable page for:

• A unique title tag
• A useful meta description
• Exactly one H1
• A correct canonical URL
• Appropriate robots directives
• Open Graph tags
• Relevant structured data
• Hreflang annotations where applicable
• Descriptive image alt text

Preserve page intent as well as metadata. Moving keywords into a title tag will not compensate for removing content that answers the user’s query.

12. Update internal links

Update navigation, breadcrumbs, contextual links, image links, hreflang references, and canonical tags so they point directly to the final URLs.

Do not leave internal links dependent on redirect chains. Direct links make crawling more efficient and reduce unnecessary server requests.

13. Prepare permanent redirects

Use server-side 301 or 308 redirects for permanent URL changes. Each old URL should point directly to its final destination in one hop.

Test for:

• Redirect chains
• Redirect loops
• Missing destinations
• HTTP-to-HTTPS inconsistencies
• Uppercase and lowercase conflicts
• Trailing-slash inconsistencies
• Query-parameter handling

Google recommends retaining migration redirects for at least one year. Important redirects can remain longer to support users following old links or bookmarks.

14. Configure analytics and consent tools

Verify:

• Google Analytics configuration
• Google Tag Manager container
• Conversion events
• Advertising pixels
• Consent-management platform
• Cross-domain tracking
• Form and checkout events
• CRM integrations
• Call tracking

Run several test conversions and confirm that the information reaches the correct analytics, advertising, and CRM platforms.

---

What Should You Test Before Launch?

15. Crawl the staging website

Check for:

• Broken Broken internal links
• Internal links returning 3xx responses
• Missing or duplicate titles
• Missing or multiple H1 headings
• Incorrect canonical tags
• Accidental noindex directives
• Blocked JavaScript, CSS, or images
• Orphan pages
• Missing images
• Invalid hreflang annotations

Compare the staging crawl with the original website inventory to locate unexpectedly missing pages.

16. Test critical functionality

Test the following on supported mobile and desktop devices:

• Navigation and site search
• Contact and lead forms
• Login and registration
• Checkout and payments
• Filters and sorting
• File downloads
• Transactional emails
• Third-party integrations
• Cookie preferences
• Validation and error messages

This web quality assurance checklist provides additional coverage for functionality, usability, compatibility, accessibility, and performance testing.

17. Test performance and capacity

Test representative page templates, not only the homepage. Include service, product, article, category, account, and checkout pages.

Run load tests if traffic volume, API requests, site search, integrations, or dynamic content could place additional pressure on the new infrastructure.

18. Complete a security review

Confirm:

• The TLS certificate is valid
• HTTPS is enforced
• No mixed content remains
• Cookies use appropriate security settings
• User roles and access permissions are correct
• Dependencies and plugins are updated
• Administrative routes are protected
• Firewalls and rate limits work
• Staging credentials are not exposed

Use this web application security checklist to review authentication, authorization, data protection, dependency risks, security headers, and production configurations.

---

What Should Happen on Launch Day?

19. Take a final backup and freeze content

Temporarily pause content changes before the final transfer. This prevents recent edits, orders, customer data, or uploads from being lost.

20. Remove staging restrictions

Remove temporary authentication, noindex directives, and staging-specific robots restrictions from the production website.

21. Activate redirects and update DNS

Deploy the approved redirect map. If the migration includes a hosting or domain change, update DNS records according to the launch plan.

22. Run immediate smoke tests

Test:

• Homepage and priority landing pages
• Robots.txt
• XML sitemap
• Canonical tags
• Representative redirects
• Forms and checkout
• Analytics events
• SSL
• Server response codes

Escalate critical failures immediately using the predefined rollback criteria.

23. Update Google Search Console

Verify the new property if required, submit the new XML sitemap, and inspect priority URLs.

For a domain or subdomain move, submit Google’s Change of Address request after confirming that redirects work. This tool is not required for an HTTP-to-HTTPS migration.

---

What Should You Monitor After Migration?

Monitor the site closely during the first 24 hours, daily for the first two weeks, and weekly until performance stabilizes.

24. Validate the complete redirect map

Confirm that every mapped URL reaches its intended destination in one hop. Check both high-value URLs and a representative sample of lower-priority pages.

25. Monitor crawling and indexing

Review Search Console for:

• Not-found pages
• Soft 404s
• Redirect errors
• Duplicate or alternate canonicals
• Crawled but not indexed pages
• Blocked resources
• Server errors

26. Compare traffic and conversions

Compare performance by:

• Landing page
• Device
• Country
• Channel
• Conversion type
• Product or service category

Sitewide totals can hide significant losses on commercially important pages.

27. Review server logs and uptime

Look for search-engine crawler errors, slow responses, excessive redirect requests, and repeated requests for missing pages or assets.

28. Update external links you control

Update URLs in:

• Paid campaigns
• Social media profiles
• Business listings
• Email templates
• Partner websites
• High-value backlinks
• Customer documentation

29. Investigate material declines

Common causes include:

• Missing or incorrect redirects
• Changed page intent
• Removed content
• Incorrect canonical tags
• Production noindex directives
• Blocked JavaScript or CSS
• Broken internal links
• Analytics failures
• Slow server responses

Some fluctuation is normal while search engines recrawl and process the new URLs. Diagnose declines at the page and query level before deciding whether the migration has failed.

30. Close the project after stabilization

Document unresolved issues, final performance, lessons learned, and responsibility for ongoing monitoring. Do not close the migration project immediately after launch.

---

Which Website Migration Mistakes Should You Avoid?

Avoid these common mistakes:

• Changing the domain, CMS, content, and design simultaneously
• Launching without a complete URL inventory
• Redirecting every removed page to the homepage
• Leaving staging noindex rules on production
• Removing content without checking its traffic and backlinks
• Forgetting forms, pixels, consent tools, and CRM integrations
• Measuring rankings without checking conversions and revenue
• Removing redirects shortly after launch
• Assuming every temporary traffic fluctuation means failure
• Launching without clear rollback criteria

---

Conclusion

A successful website migration protects more than search rankings. It also preserves user journeys, business data, analytics, security, integrations, and revenue-generating functionality.

Use this website migration checklist as a shared control document throughout planning, development, testing, launch, and post-launch monitoring. If your migration involves a new CMS, custom integrations, complex redirects, or infrastructure changes, Creole Studios’ web development services can help you plan, execute, and validate the migration.

---

Website Migration FAQs

How long does a website migration take?

A small hosting migration may take several days. A full CMS migration, domain change, or website redesign can take several weeks or months. URL volume, integrations, content complexity, testing requirements, and stakeholder approvals affect the timeline.

Will website migration affect SEO?

A migration can cause temporary ranking and traffic fluctuations. Accurate redirects, preserved content, updated internal links, correct canonical tags, and post-launch monitoring reduce the risk of lasting losses.

How can I migrate a website without losing traffic?

Benchmark existing performance, preserve valuable content, map old URLs to relevant new pages, implement permanent redirects, update internal links, submit the new sitemap, and monitor results by landing page and query.

Should every old URL be redirected?

No. Redirect an old URL only when a relevant replacement exists. Deleted content without a suitable replacement should return a proper 404 or 410 response.

How long should 301 redirects remain active?

Google recommends keeping migration redirects active for at least one year. Important redirects may remain longer to support external links, bookmarks, and returning users.

When should a migration be rolled back?

Consider rollback when the new website has critical security, data-integrity, availability, checkout, or widespread redirect failures that cannot be corrected safely within the approved launch window.

---