Separate the migration type from its business reason
A website refresh or rebuild decision starts by identifying what changes. Migration can describe domain, URL, hosting or CMS transitions. Each needs a different technical plan. A visual redesign does not necessarily change addresses; retaining working URLs may be a suitable option.
A new brand, editorial requirements or capacity problem may justify a move. First assess whether improving the current setup could solve it. More traffic does not automatically require a dedicated server, and an older CMS does not automatically require rebuilding. Record the problem, expected benefit and operating implications.
Changing domain, CMS, design and content together can make diagnosis difficult. Assess whether changes can be staged. When a business requirement makes a combined move necessary, document the dependencies. A plan should not claim to eliminate every data, traffic or revenue risk.
| Change | Main check | Separate attention |
|---|---|---|
| Hosting/CDN, unchanged URLs | Access and data integrity in new environment | DNS, certificates and capacity |
| Domain or URL paths | Old-to-new mapping | Redirects, internal links and search monitoring |
| HTTP to HTTPS | Certificate and resource access | Old address transition and mixed content |
| CMS or design | Content model and visitor tasks | Whether addresses actually change |
Record existing data and recovery conditions
Before a CMS migration, inventory content, files and relationships. Include important images, downloads and campaign addresses as well as pages. Decide what moves, merges or is removed. Reviewing only the navigation menu may miss relevant addresses.
Prepare backups for files, databases, media, configuration and email where applicable. A completed backup is not proof of recoverability: plan a controlled restoration exercise. Compare sample content and records in the new environment. For transactional sites, define the final transfer point and reconciliation of records created during the transition.
Save a baseline covering important pages, error responses, loading observations and meaningful enquiries. Use Search Console for search queries, clicks and position, and appropriate analytics for on-site usage. One total-traffic graph can conceal affected pages. Record seasonality and campaign changes when choosing comparison periods.
FROM READING TO A NEXT STEP
Clarify migration scope and acceptance conditions
Share the existing and proposed systems, important addresses and critical visitor tasks so we can assess the transition.
Give each old URL a meaningful outcome
An SEO migration plan should record which new content answers each old address. Equivalent content at a new location may use an appropriate permanent redirect; 301 and 308 are server-side examples. Genuinely consolidated pages can share a destination. Redirecting everything to an unrelated homepage is not a general solution.
Content with no replacement may need an appropriate error response. Do not hide every 404 with a new redirect. Keep redirects direct where possible, checking chains, loops, incorrect languages and failing targets. A rule working for one example does not prove that every product or archive address is handled correctly.
Keep new addresses consistent in canonicals, internal links, sitemaps and language relationships. Review titles and descriptions with content, preserving the page's purpose rather than requiring unchanged wording. Google's URL-change guidance explains mapping and launch checks. Canonicals do not eliminate every duplicate-content risk by themselves.
Prepare hosting, DNS and HTTPS before cutover
Test the new hosting environment against real requirements before changing DNS. Choose a secure, platform-appropriate transfer method; FTP is not universal. Check runtime, media, database connections, forms and authenticated areas. Loading the homepage alone does not verify the whole move.
Assess certificates and HTTPS for intended hostnames in advance. Incorrect DNS/CDN, server or certificate alignment can expose the old or wrong environment. Document TTL and cache conditions; do not assume every visitor reaches the new server at the same second. Treat email DNS changes as a separate control where applicable.
Write the order for final reconciliation, publication, access checks and recovery. A lower-traffic window may help; nighttime is not universally required. Plan coordination with campaign and operations owners. Consider post-launch orders and messages before deciding that restoring an old backup is an adequate rollback.
Separate test-environment review from live acceptance
Before publication in Webflow or another platform, perform controlled acceptance checks using real content. Cover mobile navigation, search, forms, downloads and any account or payment tasks. Test records should not be real customers or leads. Identify integration test environments and responsibility for test-data cleanup.
Manage staging access separately from its search behaviour. Sensitive data requires access controls; robots.txt is not a security mechanism. Record where preparation-stage noindex or crawling restrictions must be removed for launch. If staging becomes visible, investigate access, indexing and canonical conditions rather than assuming an automatic penalty.
Define failures that should stop publication. Prioritise incorrect redirects, missing records and broken contact flows by impact. Record the owner, correction and repeat check for each defect. Visual approval does not establish that infrastructure and search-publication requirements have all been met.
Use Search Console notifications for the right migration type
In a live technical review, check old addresses, new destinations and launch restrictions. Verify Search Console access and assess the new sitemap. Change of Address is used after moving and redirecting eligible domain or subdomain transitions. It is not used for hosting-only moves, HTTP to HTTPS or path changes within the same site.
Follow the current scope in Google's Change of Address documentation. The tool does not replace redirects or content delivery, and cannot make every page appear in search simultaneously. Checking old addresses and their new targets provides better evidence than a homepage test alone.
Align campaign destinations, profile links and internal links with the new decision. Monitor visitors still arriving at old addresses. If technical failures require recovery, assess operational implications and notification conditions together. A changed setting in the DNS panel is not sufficient evidence of a successful transition.
Monitor pages and business flows after publication
Post-migration monitoring should consider search signals and working visitor tasks together. Recheck redirects using the mapping and inspect crawling, indexing, server responses and analytics. Search visibility can fluctuate. Do not promise a fixed completion time, zero traffic loss or a return to every previous enquiry level.
Distinguish causes of a decline. Missing measurement code, changed campaigns, removed content, broken destinations and changing demand can appear in one graph. Review important page groups and suitable periods. Retain ownership of redirects and necessary old-domain access rather than closing every old-system component as soon as publication succeeds.
Define completion conditions in advance: transferred content and critical records, working tasks, addressed defects and assigned monitoring. Returning to an old traffic total is not a sufficient technical acceptance measure. The handover record should explain changes, remaining issues and the next review date.
Access and redirects
Monitor important old addresses, final destinations and the correct responses from new pages.
Content and transactions
Investigate missing fields, broken files and interrupted enquiry or order flows separately.
Search and measurement
Review Search Console alongside analytics setup. Do not attribute every graph change to one cause.
BEFORE YOU DECIDE
Frequently asked questions
Is every redesign a URL migration?
No. Appearance can change while addresses remain stable. List domain, path, protocol and infrastructure changes, then choose the appropriate plan.
Does a hosting-only move need Change of Address?
The tool is not used when visitor-visible URLs remain unchanged. DNS, HTTPS, data, access and performance still need checks.
Can every old URL redirect to the homepage?
That is not a general solution. Use equivalent or genuinely consolidated content where appropriate, and correct error responses for content without a replacement.
Can migration guarantee zero SEO loss?
No. Planning can reduce risk, while recrawling and reassessment may affect visibility. Manage technical acceptance separately from search monitoring.
Is a backup enough for recovery?
Assess restoration, access and preservation of recent records too. Document how post-launch transactional data is retained.
When does monitoring finish?
There is no universal duration. Define acceptance for critical tasks and transfer, then hand over ongoing search and operational monitoring.
LET’S DEFINE THE SCOPE
Clarify migration scope and acceptance conditions
Share the existing and proposed systems, important addresses and critical visitor tasks so we can assess the transition.
Discuss your migration