Map URLs one to one
Export the old site and assign each valuable URL a relevant final destination instead of collapsing the whole site into the new homepage.
Domain migration launch control
A domain move is a business-system release, not a registrar forwarding setting.
The old domain can appear in search indexes, links, email, listings, ads, feeds, documents, QR codes, integrations, callbacks, analytics, and customer habits. Preserve it, map every important URL, redirect directly to the matching new URL, and monitor the complete system after launch.
- Old-to-new URL map
- DNS and HTTPS readiness
- Direct permanent redirects
- Post-launch monitoring
Decision frame
Keep the old domain and use it to carry users forward.
A registrar-level homepage forward is not enough for an established site. Preserve path and query intent where practical, redirect every valuable old URL to its closest new equivalent, update internal signals, and retain ownership of the old domain.
Prepare every hostname
DNS, certificates, www and apex behavior, HTTP variants, mail, verification records, APIs, media, and callbacks must be accepted before cutover.
Monitor business systems
Search is one workstream. Email, forms, payments, feeds, CRM, ads, listings, analytics, support, QR codes, and printed assets can also fail.
Practical controls
Coordinate the domain across every customer and system touchpoint.
The launch owner needs a single inventory even when several vendors control individual changes.
URL and redirect map
Capture pages, products, categories, articles, media, documents, campaigns, parameters, canonicals, hreflang, and important inbound links.
DNS and certificates
Lower TTL when appropriate, pre-provision the new hostname, verify records, cover every required host, and preserve the old zone.
Search signals
Update canonicals, internal links, XML sitemaps, structured data, robots references, Search Console properties, and change-of-address steps.
Email and identity
Review MX, SPF, DKIM, DMARC, mailboxes, aliases, signatures, account identifiers, OAuth origins, redirect URIs, and recovery paths.
Commerce and integrations
Update payment callbacks, webhooks, APIs, feeds, analytics, tags, ads, CRM, shipping, tax, POS, maps, listings, and support systems.
Operations and rollback
Define owners, timing, support communications, health checks, logs, alert thresholds, escalation, and a tested rollback decision.
Implementation workflow
Run the domain change as a measured cutover.
Google recommends changing one major variable at a time where practical and monitoring the move closely.
- 01
Inventory
Capture the old URLs, traffic, backlinks, systems, domains, DNS, certificates, email, credentials, integrations, owners, and baselines.
- 02
Prepare
Build and verify the new domain, URL map, certificates, DNS, search properties, sitemaps, integration changes, tests, and rollback plan.
- 03
Cut over
Release DNS and direct server-side permanent redirects, update internal signals, submit new sitemaps, and complete accepted provider changes.
- 04
Accept
Crawl old and new hosts, exercise key journeys, inspect headers and logs, and verify search, analytics, forms, orders, email, and callbacks.
- 05
Monitor
Track indexing, traffic, conversions, 404s, redirects, DNS, certificates, mail, integrations, errors, support, and old-domain renewal.
Practical reference
Use a launch control sheet with explicit owners.
A checklist is effective only when each row has a system, owner, acceptance test, timing, and rollback action.
- Old URL
- The exact path currently used by visitors, search engines, campaigns, documents, or integrations.
- Final URL
- The closest accepted destination on the new HTTPS canonical hostname.
- Owner
- The person or vendor responsible for the change and production verification.
- Acceptance test
- A repeatable check for status, content, workflow, data, event, or provider callback.
- Rollback trigger
- The measurable condition and decision owner for restoring or pausing part of the cutover.
Current evidence
Verify the live standard, provider, and platform guidance.
Products, policies, interfaces, standards, and search systems change. Use current primary documentation and test the production implementation before release.
Frequently asked questions
Resolve the common assumptions before launch.
Each answer identifies a decision, responsibility, test, or operating boundary that the team should document.
Can the old domain simply forward to the new homepage?
That loses path-level intent. Established URLs should redirect directly to the closest relevant final URL wherever an equivalent exists.
Should the old domain be allowed to expire?
No. Retain organizational ownership and renewal so redirects, old links, customer habits, email risk, and brand protection remain controlled.
Can the redesign and domain move happen together?
They can, but changing several major variables increases risk and diagnosis difficulty. Separate major changes when practical.
How long should redirects remain?
Google recommends keeping site-move redirects for at least a year and suggests longer retention for users when practical.
Put one accountable launch plan around the entire domain move.
CMS Max can build the inventory, URL mapping, redirect release, search updates, integration checks, production acceptance, monitoring, and rollback plan.