Website migration SEO checklist: change platforms or domains without losing rankings

The short answer

A site keeps its rankings through a migration when every URL that earns traffic or links still answers after launch: the same content at the same address, or a permanent server-side redirect to its closest equivalent. Most migration problems trace back to a URL nobody put on the list.

Google's guide to site moves with URL changes sets the baseline: map every old URL to a new one, use permanent server-side redirects such as 301 or 308, keep them "generally at least 1 year", and "expect temporary fluctuation in site ranking during the move."

The same guide says to change one thing at a time: new domain first, new layout after. Google's Change of Address documentation is blunter. If you combine a move with a redesign of the content and URL structure, "you will probably see some traffic loss" while Google reassesses each page. If you need both, plan the redesign as its own phase.

Three kinds of move

For a hosting-only move, Google's hosting guide says to lower the DNS TTL "at least a week in advance of the move" and keep the old servers running until their traffic reaches zero. A short dip in crawl rate after launch is normal.

Before the move: list everything that has a URL

The redirect map is only as good as the list of old URLs behind it, and every source misses something.

Crawl the live site

Crawl the current site and export every URL with its status code, title, meta description, canonical and hreflang tags, then add every URL in the XML sitemap. Google also suggests checking server logs for URLs visited at least once recently.

Pull landing pages from Search Console and analytics

In Search Console's Performance report, export the Pages tab for the longest date range, and do the same for organic landing pages in analytics. These pages bring the traffic and leads, so each gets checked by hand at launch.

Find what links to you

The Links report shows your top linked pages, but its tables "are limited to 1,000 rows" and Google says it isn't a comprehensive list. Combine it with any backlink tool you use.

List forms, integrations and media

Write down every form and where its submissions go, every embedded tool (booking, chat, maps, payments) and every file people link to directly. Google's guide says to include "videos, images, JavaScript, and CSS files" in the plan, because those URLs move like any other content.

Build the redirect map

One row per old URL: old URL, new URL, status code, notes, tested. Four rules:

• Map each old URL to its closest equivalent. Redirecting many old URLs to one irrelevant destination, such as the home page, "might be treated as a soft 404 error."
• If several old pages were merged into one, redirect all of them to it.
• If a page has no equivalent, give it a 404 or 410, not a redirect.
• Keep paths unchanged wherever the new platform allows.

During the build: redirects and what travels with them

Use 1:1 server-side 301 or 308 redirects

Google's redirects documentation says 301 and 308 signal that "the redirect target should be canonical," and recommends "a permanent server-side redirect whenever possible." Temporary codes (302, 303, 307) don't, and JavaScript redirects are a last resort.

Redirect straight to the final URL. Google's crawlers follow up to 10 redirect hops, but the site-move guide advises "redirecting to the final destination directly." If an earlier migration left redirects behind, point those at the new final URLs too.

Check the default status code of whatever serves your redirects. On Cloudflare Workers, where Dardo hosts the sites it builds, a _redirects file uses 302 unless you write 301 on each line, holds up to 2,000 static and 100 dynamic redirects, and can't match query parameters. WordPress's plain permalinks (/?p=123) therefore need redirect logic in the Worker's code.

When to return 404 or 410 instead

Thin pages, expired offers and duplicates don't need to survive. Google's guide says content you don't move should "correctly return an HTTP 404 or 410," and Google's crawlers treat every 4xx code except 429 the same way: the URL leaves the index.

Carry over metadata, canonicals and hreflang

• Titles and meta descriptions. Migrate them field by field instead of letting new templates generate them.
• Canonicals. Each new page carries a self-referencing canonical with its new URL. Google's canonicalization guide calls a canonical "a hint, not a rule," so canonicals, redirects and the sitemap must agree.
• Hreflang. Each language version "must list itself as well as all other language versions," and "if two pages don't both point to each other, the tags will be ignored," per Google's localized versions guide. Update every annotation to the new URLs.

Structured data, internal links and image URLs

• Structured data. Rebuild Organization, Breadcrumb, Article or Product markup in the new templates and test it with the Rich Results Test. Google's move guide doesn't mention it, so it gets lost easily.
• Internal links. Point them at the new URLs, not at redirects.
• Images and files. Keep descriptive file names and alt text, and redirect old image and PDF URLs that have links or image-search traffic.

Analytics and consent

Reinstall analytics, conversion events and ad pixels, and test them on staging. If the old site asked for cookie consent, the new one has to ask the same way before those tags fire.

What typically breaks, platform by platform

These notes come from each platform's own documentation as of October 2026. They describe how the platforms work, not defects.

Leaving Wix means rebuilding every page; leaving Squarespace means importing what the export covers and rebuilding the rest. Moving to Shopify usually changes product URLs, so the map has to cover every product.

Launch day

1. DNS. If hosting or DNS changes, lower the TTL at least a week ahead.
2. Crawl blocks. Remove staging noindex tags and robots.txt blocks. Google suggests listing every URL where you used noindex during development.
3. Redirects. Ship them in the same release as the new site.
4. Redirect test. Run the whole map through a script: every old URL returns 301 or 308 to the right final URL in one hop, and that URL returns 200.
5. Search Console. Verify the new site and submit the new sitemap, plus a sitemap of the old URLs so they get recrawled. Warnings that those URLs redirect are expected.
6. Change of Address. For a domain change, submit it from a property you own on both sides with the same Google account, for every variant of the old domain, including www and non-www.
7. Money paths. Submit a real form, run a test payment and confirm analytics events arrive.
8. Your own links. Update social profiles, ads and directory listings.

The 30, 60 and 90 days after

Days 1 to 30: expect movement

Rankings can fluctuate "while Google recrawls and reindexes your site," and "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer." Watch:

• Indexing and sitemap reports. Indexed URLs fall on the old site and rise on the new one.
• Performance by page. New URLs start earning impressions and clicks.
• Server logs and 404s. Every unexpected 404 is a missing row in the map. Check daily for two weeks.

Days 31 to 60: compare against the baseline

Compare your top landing pages with their new URLs. For any page that lost clicks, check in order: does the redirect reach the right page in one hop, did the content or title change, do internal links still point to it, is it in the sitemap. Then ask the sites behind your most valuable backlinks to update them.

Day 90 and beyond: keep the redirects

Google's guide says to keep redirects "generally at least 1 year" and, from users' perspective, to "consider keeping redirects indefinitely." For domain moves, the Change of Address page sets a floor of 180 days, after which Google treats the old site as unrelated if it is still crawlable. It also recommends paying for the old domain "for at least a year" so nobody else can buy it.

The checklist

Getting help with a migration

Dardo moves sites onto custom Astro builds on Cloudflare Workers, and the redirect map is a deliverable we test before launch and hand over with the site. See website migration, or website redesign if the move also needs a new design. Or tell us what you're moving.