Move your website without losing what already works.

A sitemap is a starting point, not a complete record. Valuable pages may be orphaned, excluded, redirected, or known only through analytics and external links. Put them in one control sheet before deciding what the new site needs.

• Export every indexable URL from the current sitemap, CMS, and a fresh crawl.

• Add landing pages from analytics and Search Console, including pages missing from the sitemap.

• Add linked PDFs, campaign pages, image URLs, and URLs with valuable external links.

• Record the current status code, canonical, title, organic visits, conversions, and backlinks for each URL.

• Give every URL a decision: keep, update, merge, redirect, retire, or investigate.

Minimum columns for the control sheet

Download the redirect map CSV template

It includes examples for an unchanged URL, a one-to-one permanent redirect, and an intentional 410 when no useful replacement exists.

A redirect is a promise that the useful destination moved. The best match answers the same question or serves the same need. If no honest replacement exists, a clear 404 or 410 can be better than a misleading redirect.

• Map each changed URL to the closest page that serves the same visitor intent.

• Use a permanent server redirect, usually 301 or 308, when the move is final.

• Do not send a long list of unrelated pages to the homepage. That is confusing and may be treated as a soft 404.

• Avoid chains. An old URL should reach its final destination in one hop whenever possible.

• Update old internal links so visitors do not have to pass through redirects.

• Keep permanent redirects working for at least one year. Keep useful redirects longer when people or other sites still use the old URLs.

Keeping the title tag is not enough. Search engines and customers also use the page content, internal links, canonical URL, and place in the site. Make them agree with the final URL.

• Keep the main topic, useful copy, headings, and proof on pages that already earn qualified search traffic.

• Give every indexable page a self-referencing canonical with its final public URL.

• Update titles and descriptions deliberately. Preserve strong search intent instead of copying stale metadata without review.

• Update JSON-LD URLs, IDs, breadcrumbs, business details, and page types, then test the live output.

• Remove preview noindex rules and temporary robots.txt blocks before launch.

• Replace links to the staging host, old domain, old assets, and old canonical URLs.

• Keep only final, canonical, indexable URLs in the new XML sitemap.

Without a benchmark, teams remember traffic vaguely and diagnose problems late. Save the old site's page and query data, then confirm the new site records the actions that matter.

• Save a pre-launch benchmark for organic landing pages, clicks, impressions, conversions, and top queries.

• Carry over analytics IDs, consent settings, ad pixels, call tracking, and the events that matter to the business.

• Confirm Search Console ownership will survive the move. Copy HTML files or meta tags if they provide verification.

• If the domain changes, verify both old and new properties before launch.

• Add the launch date to your reporting notes so normal migration movement is not mistaken for an unrelated trend.

• Test live page views, form events, thank-you pages, and revenue or lead events with a real visit.

A page can look right while a form, booking link, or payment flow is broken. Imports bring over useful content and layout context, but forms, payments, calendars, accounts, and notification routes still need hands-on testing.

• Submit every important form and confirm the entry appears where the team actually works.

• Check notification recipients, reply-to addresses, autoresponders, spam handling, webhooks, and success redirects.

• Test phone links, email links, booking widgets, chat, maps, downloads, and account sign-in.

• Reconnect checkout, subscriptions, scheduling, member accounts, and other systems that do not move as page content.

• Test from a phone and a desktop, including one browser where you are not signed in.

Read the Redo Page forms guide

DNS is shared infrastructure. The records that route website traffic sit beside records that authenticate and deliver email. Back up the zone, identify the exact web records, and leave mail records alone.

• Export or screenshot the full DNS zone before changing anything.

• Identify the web records that will change and the person who can change them.

• Lower DNS TTL ahead of the cutover when your provider and schedule allow it.

• Do not replace MX, SPF, DKIM, or DMARC records while pointing the website to a new host.

• Plan the canonical host, such as www or the bare domain, and test both versions over HTTPS.

• Keep the previous hosting available until traffic and critical workflows are stable.

Review the preview as a future public site, not as a design presentation. Crawl it, compare it with the control sheet, and complete the real customer tasks before anyone points the domain.

• Crawl the preview and compare its indexable URL count with the approved migration sheet.

• Test every redirect in bulk, then manually test the highest-traffic and highest-value URLs.

• Check status codes, canonicals, robots directives, sitemap URLs, headings, and structured data.

• Review navigation, internal links, images, downloads, forms, and layouts on common phone and desktop sizes.

• Confirm that 404 pages return a real 404 and that retired content is not redirected somewhere irrelevant.

• Have one person who did not build the site complete the main customer task from start to finish.

• Write down who can roll back publishing, DNS, redirects, and third-party integrations.

A migration is not finished when the new homepage loads. Watch the things users feel first, then the crawl and search signals that take longer to settle.

Roll back for a broken site, not a temporary ranking dip

A temporary change in crawling or rankings can be normal. Roll back when the site or a critical workflow is broadly broken and cannot be corrected quickly. Agree on those conditions before launch.

• The main domain serves the wrong site, a certificate error, or persistent 5xx responses.

• Lead forms, checkout, booking, or sign-in is broadly unavailable.

• Email delivery breaks after the DNS change.

• Priority redirects or canonical tags are wrong across a large part of the site.

• The new site is accidentally blocked by noindex or robots.txt.