A practical website domain move checklist for small businesses

Write the change in one sentence before anyone builds redirects. Are you moving example.es to example.com, changing /servicios to /services, combining two websites, or replacing a platform that creates different page addresses? Google treats these as moves with URL changes. If the domain and every visible path stay identical while only the hosting company changes, use a hosting-move plan instead.

Create a spreadsheet with every important old URL. Start with the current sitemap, then add addresses found in website analytics, Search Console, menus, PDFs, email signatures, QR codes, paid campaigns, partner listings, and staff bookmarks. Include images or downloadable files that customers use. This list is the move register: one row per old address, not just one row per menu item.

For a multilingual site, record language and region separately. An English service page, Spanish servicio page, Swedish tjänst page, Danish ydelse page, Norwegian tjeneste page, and German Leistung page are six customer destinations. Keeping them visible in the register prevents an entire language from being sent to the home page by mistake.

Give every useful old page the closest meaningful new destination. A page about veterinary emergency appointments should lead to the equivalent new emergency page, not the new home page. If two old pages genuinely become one stronger guide, both can point to that guide. If content has no replacement and should disappear, return a proper not-found response rather than disguising the loss with an unrelated redirect.

Test the new website on a private preview address. Confirm that navigation, contact forms, telephone links, booking or quote journeys, consent tools, downloads, and mobile layouts work. Check page titles, descriptions, headings, visible language, image text, and internal links. Copy over Search Console verification if the chosen method depends on a file or tag that the rebuild could remove.

Each new page should name itself as the preferred, or canonical, address. A multilingual set should also list all equivalent language versions with reciprocal hreflang links, including itself. Update those links to the new domain; leaving one old-domain address inside the set creates conflicting instructions. The new sitemap should contain the new canonical URLs, not a mixture of old and new ones.

At launch, configure permanent server-side redirects from old URLs to their mapped new URLs. Google recommends server-side permanent redirects when a page address has permanently changed; 301 and 308 are the usual status codes. The website or hosting specialist should implement them at the server or platform level so customers and crawlers are sent to the destination before an old page loads.

Test a representative sample first, then the complete register. Each old URL should make one clean hop to a working new page. Avoid chains such as old A to temporary B to final C, loops that never resolve, and redirects that drop query information needed by a real campaign. Keep the old domain under business control so the redirects continue to work after launch.

Verify both the old and new properties in Google Search Console and submit the new sitemap. A sitemap is a hint rather than a guarantee, but it gives Google a clear list of the canonical addresses the site wants discovered. Keep the old property available because its reports help show whether old URLs are still being requested or failing.

Use the Change of Address tool only for a domain or subdomain move after the site and redirects are live. Google says not to use it for HTTP-to-HTTPS changes or for moving only some pages within the same site; those cases rely on redirects and updated sitemaps. The account must own both properties, so confirm access before the launch window rather than discovering a missing login afterwards.

Watch the new site immediately for broken pages, failed forms, missing images, incorrect language links, certificate warnings, and unexpected redirects. Then review Search Console and website analytics over time for crawl errors, sitemap processing, indexed pages, landing pages, and traffic patterns. Google explains that recrawling and processing happen per URL, so there is no honest fixed date when every move is finished.

Imagine a Mallorca activity company moving from an island-specific domain to a broader European brand. Its English, Spanish, Swedish, Danish, Norwegian, and German tour pages receive localized new slugs. The team maps each language separately, keeps booking links in the matching language, updates canonicals and hreflang sets, redirects every old route, and checks enquiries from a phone in each market.

The move is successful when customers reach the right working page and the technical signals agree—not when a redirect file merely exists. Keep the register as the acceptance document and repeat the checks after later content changes. It becomes a useful record for staff, suppliers, and the next website update.