Define exactly what is moving
Start by naming the move: domain change, protocol or host change, subdomain-to-folder consolidation, URL restructuring, platform rebuild, hosting change or a combination. The risk profile changes when several variables move together. If the commercial timetable allows, separate infrastructure changes from information-architecture and content changes so that faults can be isolated.
Record the markets, languages, domains, subdomains, folders, integrations and lead routes in scope. Freeze the migration boundary before the final crawl. Pages that are outside the project must not disappear simply because they were absent from a design inventory.
Build an evidence-based URL inventory
Combine the current sitemap, crawl data, analytics landing pages, Search Console data, paid-campaign destinations, backlink evidence, CRM entry points and stakeholder-owned URLs. No single source contains the full estate. Tag every URL by market, language, template, status, traffic, conversions, backlinks and business owner.
Decide whether each page will be retained, consolidated, replaced, redirected or intentionally removed. Preserve content that answers a distinct search intent or supports a material customer journey. A redesign is not evidence that the demand behind a page has disappeared.
Create a one-to-one redirect map
Map each old URL to the closest relevant new URL. Google recommends permanent server-side redirects such as 301 or 308 for permanent moves. Avoid sending a large group of unrelated pages to the homepage, which weakens user relevance and can be treated as a soft 404. Remove redirect chains by pointing the original URL directly to the final destination.
Keep the map as a controlled release file with old URL, new URL, decision reason, owner and test status. Include alternate hostnames, protocol variants, trailing-slash variants, parameters that receive meaningful traffic and campaign URLs that remain in circulation.
- one relevant final destination for every retained legacy URL
- permanent server-side status for permanent moves
- no redirect chains, loops or mass homepage redirects
- explicit 404 or 410 decision for content with no replacement
- test both encoded and localized URL variants
Protect localized versions and market relationships
Maintain a market matrix for every equivalent page: final URL, language and region, self-canonical, hreflang set, default version and internal-link source. Google recommends separate locale URLs and reciprocal hreflang annotations for localized alternatives. A migration should update the complete cluster together rather than leave old and new addresses mixed.
Confirm that each localized page remains useful on its own. Do not canonicalize genuinely localized versions to a global master simply because they share a template. Check language declarations, currencies, offers, legal text, forms and local contact destinations as well as technical tags.
Rebuild technical search signals on the destination
Every indexable destination needs a crawlable internal link, a self-referencing canonical where appropriate, correct robots directives, unique metadata, a clear primary heading and structured data that matches the visible page. Update XML sitemaps to the final canonical URLs and submit the new sitemap after launch.
Inspect robots.txt, authentication, firewall rules and staging controls before release. A correct redirect cannot compensate for a destination blocked from crawling or marked noindex. When the domain changes, use the search engine's current site-move procedure and verify ownership of both properties before the launch window.
Preserve forms, analytics and lead ownership
Migration acceptance criteria should include the commercial journey, not only page rendering. Test every priority form, confirmation state, email or CRM delivery, consent record, file download, telephone link and booking or application route. Confirm who receives each lead by market and what happens when an integration fails.
Carry the measurement plan into the new implementation. Compare analytics events, channel attribution, consent behavior and campaign parameters before and after launch. Annotate the migration date and preserve a baseline for search visibility, qualified conversions and form completion so that change can be interpreted rather than guessed.
Use a staged launch and a tested rollback decision
Test the production build against a release checklist while access is controlled. Crawl the destination, validate templates and structured data, run the redirect map against the release candidate and complete representative journeys for each market and device. Name the person who can stop the launch when a critical test fails.
A rollback plan must distinguish between a reversible deployment fault and a completed domain or URL move that has already been exposed to users and crawlers. Record backups, configuration owners, DNS dependencies, certificate status, cache controls and the decision threshold for rollback or forward repair.
Launch-day checklist
Immediately after release, remove staging blocks, verify the primary domain and certificate, test representative old URLs, crawl the new canonical URLs, submit the sitemap and check priority forms from submission to the final business system. Confirm that navigation, language switching, hreflang, canonical tags and structured data refer to the public destination.
Keep one incident register for broken redirects, 404s, blocked resources, incorrect canonicals, missing market versions, form failures and tracking gaps. Assign severity, owner and next test. Do not let a clean homepage substitute for sampling deep pages and real entry routes.
Monitor the move until signals and journeys stabilise
Google notes that site moves can take time to process. Monitor indexing, submitted-versus-indexed sitemap URLs, crawl errors, redirect behavior, canonical selection and search performance by market and page group. Compare branded and non-branded demand separately and investigate changes against the migration map.
Continue commercial monitoring in parallel: qualified leads, form completion, source attribution, conversion by market and sales-team exceptions. Keep redirects in place for as long as they remain needed and users or crawlers may still request the old URLs. Close the project only when critical defects are resolved and ongoing owners have accepted the new controls.
How ICON IMAGE can coordinate an international migration
ICON IMAGE can coordinate the market and content inventory, URL decision framework, localized information architecture, redirect and release register, metadata and structured-data requirements, multilingual QA, form and lead-path checks, launch communications and post-launch reporting. The scope is designed around the company's markets, search demand, publishing stack and commercial ownership.
Hosting, development, DNS, security, legal, privacy and specialist search-engine decisions remain with the relevant qualified owners. To define the mandate, share the current and target domains, markets, platform, planned move type, launch constraints, analytics and CRM stack, critical journeys and the people responsible for technical deployment and leads.
Editorial sources
Primary sources used to verify the factual statements and publication dates in this article.