Website migration checklist: keep your rankings, email and tracking

Decide what is actually changing

“Migration” covers several different moves, and search engines treat each one differently. Write down which of these apply before planning anything else:

• Domain change, for example example.co.il to example.com.
• Platform change, for example WordPress to Next.js or one store platform to another.
• URL structure change: new paths, new category levels, removed language folders.
• Hosting or server change, with the domain and URLs staying the same.
• Protocol or host change: HTTP to HTTPS, or www to non-www.
• Merging several sites into one, or splitting one into several.

The more of these you change at once, the harder it is to tell what caused a drop in traffic. Where the timeline allows, move hosting first and redesign later, or launch the new design on the same URLs before restructuring them.

Inventory every URL that matters

The redirect map is only as good as the list behind it. Build the list from several sources, because each one misses something:

• Crawl the current site. Screaming Frog, Sitebulb or a similar crawler gives every linked page with its status code, canonical and title.
• Export from Search Console. The Pages report lists what Google has indexed; the Performance report gives clicks and impressions per page for up to 16 months. The interface exports at most 1,000 rows, so on larger sites pull the data through the Search Console API, the Looker Studio connector or the BigQuery bulk export.
• Export landing pages from analytics. Twelve months of landing pages in GA4 catches campaign and old pages that are no longer linked from the menu.
• List pages with backlinks. The Links report in Search Console, or a backlink tool, shows which URLs other sites point to.
• Add files and media. PDFs, images and downloads that get traffic or links need redirects too.

Merge everything into one spreadsheet, remove duplicates, and note traffic and links per URL. That column tells you which redirects cannot be wrong.

Build the 301 map

Every old URL with traffic, links or indexed status gets a permanent (301) redirect to the most relevant new page.

• Redirect to the equivalent page. Redirecting many pages to the homepage is usually treated as a soft 404, and the old rankings are lost.
• One hop only. Update existing redirects so old URLs point straight at the final address instead of chaining through an intermediate one.
• Pick one form for trailing slashes, letter case and the www host, and redirect every other variant to it.
• Pages with no equivalent and no value should return 404 or 410, not redirect to something unrelated.
• Implement redirects on the server or at the edge (Nginx, .htaccess, Cloudflare rules, framework config), never with JavaScript or a meta refresh.

Keep staging out of the index

The new site will live on a staging address before launch. Search engines discover staging hosts through stray links, sitemaps and public certificate logs.

• Protect staging with HTTP basic authentication or an IP allowlist. That is the only reliable block.
• Add an X-Robots-Tag: noindex header as a second layer. A robots.txt Disallow on its own does not stop URLs from being indexed if they are linked elsewhere.
• Put the removal of every block on the launch checklist. A production site that still sends noindex or “Disallow: /” is one of the most common launch-day mistakes.

X-Robots-Tag: noindex

User-agent: *
Disallow: /

Carry over what search engines read

Compare the old and new versions of your most important pages before launch, not after.

• Content. Titles, meta descriptions, H1s and body text on top pages. Removing content removes the rankings it earned.
• Canonical tags. They point at the new production URLs, not at staging and not at the old domain.
• hreflang. Each language version lists itself and every other version with absolute URLs on the new domain. Hebrew, Arabic and English sites break this easily.
• Structured data. Organization, Product, BreadcrumbList and the rest carry over; check them with the Rich Results Test.
• Internal links. Menus, footers and body links use final URLs, so the site does not depend on its own redirects.
• XML sitemap. It lists only final, indexable URLs that return 200.

Prepare DNS and SSL before the switch

• Get access early. Know who controls the domain registrar and the DNS host, and have working logins well before launch week.
• Export the zone. Save a full copy of the current DNS records before touching anything.
• Moving DNS providers. If the zone itself moves to a new DNS provider, recreate the complete zone there, compare it record by record, and switch the nameservers at the registrar days before the cutover. The parent zone’s NS records often have a 48-hour TTL that you cannot lower. Then make the website change as an ordinary record change.
• Lower the TTL. Drop the TTL on the records you will change to around 300 seconds, at least one full old TTL before the switch (often 24 to 48 hours), so the change spreads quickly and can be rolled back quickly.
• Issue certificates first. The new server or CDN must have valid certificates for every hostname, apex and www, before traffic arrives. Use DNS validation or the CDN’s certificate so HTTPS works on the first request.
• Check HSTS. If the old site sent an HSTS header, browsers will refuse plain HTTP on the covered hosts. Every one of them needs working HTTPS on the new server.

Leave email alone

Moving a website should not affect email, but DNS changes break it regularly, usually when the zone moves to a new DNS provider and only the website records are recreated.

• Copy MX records exactly, with their priorities.
• Copy SPF, DKIM and DMARC records (TXT and CNAME). If SPF or DKIM is missing, mail goes to spam or is rejected.
• Keep verification TXT records for Google Workspace, Microsoft 365, Meta and other services.
• If the new server sends mail (form notifications, order emails), send it through an authenticated SMTP service, set up DKIM signing for that service and add it to SPF. SPF allows at most 10 DNS lookups, so check the record after each new include.
• After the switch, send test messages to Gmail and Outlook and check the headers for SPF, DKIM and DMARC pass.

Verify forms, tracking and conversions

A site can look perfect and report nothing. Check what the business measures, on the staging site and again on launch day.

• Every form submits, the notification arrives, and the lead reaches the CRM or wherever it is supposed to go.
• The GA4 tag or GTM container is on every template, with the same measurement ID, and key events fire. Check in Realtime or DebugView.
• Google Ads conversions and the Meta pixel fire on the right pages, and the consent banner still controls them.
• For stores: a complete test order through checkout, with payment gateway callbacks updated to the new domain.
• Integrations with hard-coded URLs keep working: webhooks, API callbacks and OAuth redirect URIs.

Launch day

• Freeze or sync content. Stop edits on the old site, or plan a final sync. For stores, sync orders and customers last.
• Take a fresh backup. Files and database of the old site, stored somewhere you can restore from quickly.
• Switch DNS. Then confirm the new server answers from more than one network.
• Remove staging blocks. noindex headers, robots.txt rules and basic authentication.
• Test the redirect map. Run the full list of old URLs through a crawler: each one returns a single 301 to a page that returns 200.
• Submit the sitemap. Submit it in Search Console. For a domain change, verify both properties and use the Change of Address tool.
• Keep the old server running. Leave it up until DNS has fully propagated and nothing reaches it any more.

The weeks after launch

Rankings usually move around for a few weeks while search engines recrawl. The point of monitoring is to catch the problems that will not fix themselves.

• In Search Console, watch the Pages report for “Not found (404)” and “Page with redirect”, and follow the number of indexed new URLs.
• Check server or Cloudflare logs for 404s that real visitors and bots hit, and add redirects for anything with traffic or links.
• Compare organic traffic per landing page against your inventory, not only the site-wide total.
• Watch Core Web Vitals and server response times on the new stack.
• Keep the redirects permanently. Google recommends at least a year, and links on other sites point at the old URLs for much longer.

Where we fit

We run migrations end to end: the URL inventory and redirect map, DNS and certificates, email records, tracking checks and the follow-up in Search Console. If you are handling it in-house, we can review your plan before launch.

• SEOTechnical SEO, structured data, visibility
• Web DevelopmentCorporate sites, portals, booking engines
• Managed WebsitesUpdates, backups, fixes and support