Nirmion
HelpLog in Find a tool

Website · THE NO-PANIC PLAN

Plan and verify a website domain migration

A domain migration changes more than DNS: users, bookmarks and search systems need a reliable path from each important old URL to its new equivalent. This workflow separates the URL map, destination readiness, DNS cutover, Search Console notice and long-term redirect monitoring. Nirmion Redirect Map Generator can prepare a CSV from URL pairs you provide; it does not inspect either site or deploy redirects.

MISSION Move a website to a new domain using a reviewed old-to-new URL map, direct redirects, accurate DNS and sitemap updates, and sustained post-move monitoring.

Build a redirect map

THE REAL-WORLD BIT

What happens outside this browser tab?

Classify the move and verify control of both domains; map old canonical URLs to relevant new destinations; prepare the target site, DNS and sitemap; deploy direct redirects and use the appropriate Search Console procedure; then monitor both properties and retain redirects.

YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES

One step at a time.

Follow the order below. If a step names a Nirmion tool, its link is right there with it.

  1. 01

    Define the move and verify control of both domains

    Record the old and new hostnames, every active protocol and subdomain variant, affected path patterns, launch owner, rollback owner, DNS provider and expected maintenance window. Decide whether this is a true domain move, a path change, an HTTP-to-HTTPS change or only a hosting/CDN move; the right Search Console steps differ. Verify that the team controls both sites and can retain the old domain and TLS/DNS configuration through the migration. Keep the current URL architecture where practical instead of combining a domain move with a large redesign. Google notes that combining site moves and structural changes can make it harder for search systems to process equivalent pages. (Sources 1, 2)

  2. 02

    Map each old URL to its closest new equivalent

    Export the old site's canonical URLs and inventory important landing pages, documents, inbound links and routes with traffic. For every old URL, choose the corresponding destination or explicitly decide that no equivalent exists; do not send a large set of unrelated pages to the new homepage. Nirmion Redirect Map Generator (tool 291) validates explicit source-to-target pairs and exports a reviewable 301 CSV map. Inspect the map for missing, duplicate, malformed or wrong-host destinations, and test representative entries before deployment. Google recommends redirects for canonical old pages and a URL map that links old paths to their new equivalents. Keep the mapping with the release so developers, support and SEO owners can use the same source of truth. (Source 1)

  3. 03

    Prepare the destination site, DNS and new sitemap

    Before cutover, confirm the new pages load over HTTPS, each destination returns the expected content and status, canonical tags point to the new URLs, internal links use the new host and no staging-only block is present. Prepare a sitemap containing only absolute canonical URLs intended for discovery; Google says submitting a sitemap can help it learn the new URLs but does not guarantee indexing. Review DNS records, TTL, proxy settings, certificates and email-related records with the DNS/hosting owner; do not assume record changes propagate immediately. Cloudflare documents how TTL affects resolver caching, but provider-specific behavior and local caches can differ. Keep a verified copy of existing DNS records and redirect configuration for rollback. (Sources 1, 3, 4)

  4. 04

    Cut over with permanent redirects and the right Search Console action

    Deploy direct permanent redirects from each old canonical URL to its mapped destination, avoiding chains and loops. Update internal links and submit the new sitemap after the destination is live. For an eligible move from one domain or subdomain to another, use Google's Search Console Change of Address tool only after redirects are working and ownership of both domain properties is verified. Google says not to use that tool for an HTTP-to-HTTPS change, a www/non-www change on the same domain or a hosting-only move; those cases follow the relevant site-move guidance and redirects/canonicalization. Treat the tool's 180-day migration signal period separately from redirect retention: Google's site-move guide says to keep redirects as long as possible, generally at least a year. (Sources 1, 2, 4)

  5. 05

    Monitor both properties and keep redirects in service

    For several weeks after cutover, compare old and new Search Console properties, server logs, sitemap processing, important landing-page traffic, crawl errors, 404s and redirect chains. Confirm real users reach the intended page and that the new sitemap contains the new canonical URLs. Google warns that visibility can fluctuate while systems recrawl and process a move; do not respond to normal short-term changes by repeatedly changing redirects. Keep the old domain registered and preserve redirects for as long as they serve users and search traffic?Google's guide says generally at least a year, and its Change of Address help advises keeping redirects longer when traffic remains. If errors appear, use the URL map to correct affected routes and document any rollback decision. (Sources 1, 2, 4)

THE HELPER CREW

Tools for the fiddly bits.

These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.

RECEIPTS, PLEASE

Sources & review notes

Each source is linked to the steps it supports. Open it to check its scope and current guidance.

Source checked 2026-10-08