Website Migration SEO Checklist (2026): 60 Steps

Why Migrations Lose Traffic in 2026

Rebuilding a website used to be the expensive part of a migration. It is now the cheap part: with an AI coding assistant, a WordPress blog can be rebuilt as a static Astro site in hours.

What did not get cheaper is the migration layer: the redirects, the URL parity, the trailing slashes, the schema, the internal links, the decisions about which pages to keep, the tracking and the visibility in AI answers. That layer decides whether Google and Bing treat the new site as the old site with a better engine, or as a stranger with no history. It is also the layer an AI assistant handles worst when nobody supervises it, because every mistake in it looks fine in a browser.

This checklist is the migration layer. It is written for founders and marketing leads who will run, hire for or sign off on a migration: five phases, 60 steps, each one verifiable.

It comes from migrations we have run on our own properties:

• seosavages.com moved from WordPress to Astro in June 2026, with every URL kept 1:1.
• Prawomat, our legal-document product, moved from WordPress to static Astro pages at the edge. 2,646 WordPress URLs became about 1,370, each one judged on its own clicks and backlinks. Nine weeks from first commit to live. In the 19 days after the switch, Google clicks rose 2.9x, Bing clicks 2.0x and appearances in Google’s AI answers 6.4x. On the same dates in 2025, with nothing changed, Google rose 1.3x and Bing stayed flat. The full story is in the Prawomat case study.

If you would rather hand the whole thing to a team that does this weekly, that is what our SEO migration services are for. If you want to run it yourself, read on.

Phase 1: Before You Touch Anything (Benchmark)

Every argument after launch (“did we lose traffic, or is it seasonal?”) is settled by data captured before launch. Date it and store it where the new site cannot overwrite it.

1. Crawl the live site with Screaming Frog, Sitebulb or similar. Export every URL with status, title, meta description, H1, canonical, meta robots, word count, inlinks and schema. This is the “old” side of your URL map.
2. Add URLs your crawler cannot find. Export pages from Google Search Console’s Performance report, plus your XML sitemaps and server logs. Orphan pages with clicks only show up here.
3. Export Search Console performance data. Clicks, impressions, CTR and position per page and per query for the full 16 months Search Console keeps, so you can compare year over year later.
4. Export Bing Webmaster Tools data. Clicks and pages per URL, so Bing gets its own before-and-after comparison.
5. Export analytics. Organic sessions, conversions and revenue per landing page, plus every event and conversion definition.
6. Export backlinks per URL. From Ahrefs, Semrush or Majestic: referring domains per target URL. A page with zero clicks and 40 referring domains is a page you redirect carefully.
7. Record rankings for your money keywords. Pick 50-200 queries that drive revenue and record positions, including which URL ranks.
8. Record Core Web Vitals per template, from Search Console or CrUX field data.
9. Record AI search visibility. Note whether you appear in Google AI Overviews for your key queries, and run the same set of prompts in ChatGPT, Perplexity and Gemini. Save which of your URLs get cited. See our AI Overviews entry if this is new to you.
10. Snapshot structured data: schema types per template and the rich results you earn.
11. Value-tag every URL. Merge steps 1-6 into one spreadsheet with one row per URL: clicks, impressions, conversions, referring domains, internal inlinks. Then tag each URL: high value, medium, low, zero. Every Phase 2 decision rests on this content inventory, and it is the step most teams skip.
12. Back up the old site, including its current redirect rules (.htaccess, nginx config, plugin exports). Old redirects must survive the move.

Phase 2: Plan (URL Map and Redirect Rules)

The URL map is the migration. Everything else is implementation.

13. Build the URL map 1:1. One row per old URL, one destination per row. No row is allowed to be blank.
14. Decide per URL: keep, improve, merge or retire. Base the call on that URL’s own clicks and backlinks; its template or category tells you nothing. On Prawomat we cut 2,646 URLs to about 1,370 this way. The rule we wrote down: prune before you migrate, from click data per URL. Keep and rebuild the pages that earned clicks, because a redirect to a hub reads as a soft 404.
15. Keep the URL wherever you can. A URL that does not change needs no redirect and loses nothing. seosavages.com kept every URL 1:1. Change URLs only when the old structure actively hurts you.
16. Merge into the closest equivalent. When two thin pages cover one topic, merge them into the stronger one and redirect the weaker. The destination must answer the same query.
17. Retire only what earned nothing. Zero clicks, zero backlinks, no conversions: let it return 410 or 404, or redirect it to a genuinely equivalent page. Do not redirect it somewhere irrelevant just to “save” it.
18. Never redirect to the homepage in bulk. Google’s site move documentation says redirecting many old URLs to one irrelevant destination, such as the home page, “might be treated as a soft 404 error.” A soft 404 passes nothing. Our soft 404 glossary entry explains how Google detects them.
19. Use permanent redirects. 301 or 308, server-side. Google treats a permanent redirect as a signal that the target should be canonical; temporary ones (302, 307) keep the old URL in results. JavaScript redirects are a last resort.
20. Write explicit rules and avoid chains. Every old URL should reach its final 200 page in one hop. Update old redirects too: if /a/ already pointed to /b/, and /b/ now moves to /c/, rewrite /a/ to point straight at /c/. Google’s crawlers follow up to 10 hops by default, but every hop is delay and risk. More in our redirect chain entry.
21. Decide your trailing-slash policy now. Pick /page/ or /page and enforce it everywhere: internal links, canonicals, sitemaps, redirect sources and targets. Then add redirect sources in both forms for any URL you delete (details in the AI section below).
22. Map query parameters and campaign URLs. Paid landing pages, email links and QR codes printed on physical material all need destinations. Make sure UTM parameters survive the redirect.
23. Plan media and file URLs. PDFs, images and downloads earn links and image-search traffic. They need redirects too.
24. Plan hreflang if you are multilingual. Every language version needs its reciprocal tags on the new URLs.
25. Pick a launch window: a low-traffic season, early in the week, with the team available for five days afterward.

Here is what a compact redirect map looks like. The “why” column is what keeps the map honest in review:

Phase 3: Build and Staging QA

Staging is where fixes are cheap. After Googlebot has seen a bug, they stop being cheap.

26. Block staging from indexing. Password protection is best; noindex plus a robots.txt disallow works. Write down how it is blocked, because unblocking it is a launch-day step.
27. Crawl staging and diff against the old crawl. Compare URL lists, titles, meta descriptions, H1s, canonicals and word counts row by row. Every missing URL, emptied title or shortened page is a finding.
28. Test every redirect in the map. Upload the old URL list to your crawler in list mode against staging. Every row must return one 301 or 308 to a 200. Check the exact Location header, trailing slash included.
29. Check canonicals. Every page should self-canonicalize to its final, absolute, production URL (never the staging hostname).
30. Check meta robots. No production page should carry noindex. Search the build output for it.
31. Check hreflang, if used: reciprocal, absolute, pointing at 200 pages.
32. Validate structured data per template. Run Google’s Rich Results Test and the Schema.org validator on one page of each template. Compare against the snapshot from step 10. Organization, Article, Product, FAQ and Breadcrumb markup is often dropped silently in rebuilds. Our structured data entry covers what each type does.
33. Check image alt text. Rebuilt templates often lose it. Crawl for empty alt attributes on content images.
34. Rewrite internal links to final URLs. Internal links should point directly at the new URLs; relying on redirects for them wastes crawl budget and leaks signals. Crawl staging and confirm zero internal links hit a 3xx or 4xx.
35. Check internal link counts for your top pages. If your top 20 pages lost navigation or sidebar links in the new design, they lost internal authority too.
36. Build XML sitemaps with only final 200 URLs. No redirects, no noindexed pages, no staging hostnames.
37. Write the production robots.txt. Keep it separate from staging’s, and do not block CSS or JavaScript.
38. Test every form. Submit each one and confirm the lead lands in the CRM or inbox. Forms are the most common silent casualty of a rebuild.
39. Check analytics and tag parity. Every GA4 event, conversion, pixel and consent behavior from step 5 should fire on the new templates. Use Tag Assistant or the network tab, page type by page type.
40. Check campaign landing pages. Every URL currently running in paid ads must resolve. Ad platforms will disapprove broken destinations.
41. Check performance per template against your step 8 baseline.
42. Read the top 20 pages side by side, old and new, top to bottom. A person spots a missing pricing table that a crawler will pass.

If You Rebuilt the Site With AI

AI coding assistants are excellent at producing a site that looks right. They are weak at preserving what search engines already know about the old one, because nothing in the prompt says what that is. These are the misses we see most often in AI-assisted rebuilds, our own included, with the check for each:

• URLs “cleaned up” without being asked. The assistant renames /services/seo-audit-services/ to /seo-audit/ because it looks tidier. Check: diff the old crawl against the new URL list. Every changed URL needs a row in the map.
• Trailing slashes inconsistent between links, canonicals and the server. Check: crawl and filter for internal links whose target returns a 3xx.
• Deleted pages redirected in one form only. On Cloudflare Pages we found that redirect matching is exact: a rule for /old-page/ does nothing for /old-page. While the page existed, the platform added the slash for you; once it was deleted, every backlink written without the slash returned 404. Check: request both forms of every retired URL.
• Wildcard rules that match their own destination. On one of our own sites, a Cloudflare Pages _redirects rule meant to hold a section (/section/* pointing to /section/) also matched the section page’s own rewritten path. The result was an infinite redirect loop across an entire section, with the section still listed in the sitemap. Every build passed and every test was green, and nobody noticed until a 404 and redirect audit requested the URLs. The fix was a single-segment placeholder (/section/:slug/) instead of a splat. Check: after any redirect change, request the section root, its index.html and one child page on a preview, following every hop.
• Redirect rules silently ignored past a platform limit. Cloudflare Pages allows 2,000 static and 100 dynamic redirects and wants static rules first. We had rules after an early wildcard stop working with no error once the file grew. Check: keep wildcard rules at the end, and test every rule on the deployed preview, in file order.
• Schema dropped or flattened. The assistant ports the visible page and forgets the JSON-LD in the old theme’s head. Check: step 32.
• Tracking missing. Consent-gated scripts, conversion events and pixels live in plugins the assistant never saw. Check: step 39.
• Content quietly shortened or summarized. Asked to “port” a 2,000-word page, a model sometimes returns 1,200 words. Check: compare word counts per URL in the crawl diff and flag any drop above 10%.
• Consolidation done on vibes. The assistant merges pages because their titles look similar. Check: every merge in the map should trace back to clicks and backlinks from step 11.

None of this means you should avoid AI for the rebuild. It means the migration layer needs a human who owns it. If you are weighing whether to keep WordPress at all, our take on whether WordPress is still worth it in the AI era covers that decision.

Phase 4: Launch Day

Launch day should be boring: flip switches, then verify.

43. Lower DNS TTL a day or two ahead if DNS is changing, so the switch propagates quickly and a rollback is fast.
44. Deploy, then remove staging blocks. Confirm no noindex and no Disallow: / on production. This is the single most common self-inflicted migration disaster, and it takes one request to check.
45. Switch on the redirects and confirm they are live on the production hostname.
46. Verify your top 100 URLs by hand or script. For each old URL: one hop, correct destination, destination returns 200, page renders with the right title and canonical.
47. Test HTTP to HTTPS and non-www to www (or the reverse) in one hop, combined with a real path.
48. Submit the new XML sitemap in Search Console and Bing Webmaster Tools. Google also recommends keeping a sitemap of the old URLs submitted for a while, so it recrawls them and sees the redirects faster.
49. Use Google’s Change of Address tool only if the domain or subdomain changed. Google states it is for moves from one domain or subdomain to another. For a CMS switch on the same domain, a URL restructure or a redesign, it does not apply.
50. Ping IndexNow. Bing, Yandex, Naver, Seznam and others share IndexNow submissions; Google does not participate. Submit new URLs and the redirected old ones, which IndexNow explicitly asks for. Our Bing Webmaster Tools and IndexNow guide walks through setup.
51. Inspect key URLs in Search Console with URL Inspection and request indexing for your top pages.
52. Confirm analytics is recording and fire a test conversion.

Phase 5: The 90-Day Watch

Google says a medium-sized site can take “a few weeks or more” before new URLs replace old ones in results, and larger sites longer. Watch closely for two weeks, then weekly until day 90.

53. Check the Pages report in Search Console daily for two weeks. Look for rising “Not found (404)”, “Soft 404”, “Redirect error” and “Excluded by noindex” counts.
54. Check server or edge logs for 404s. Any 404 that receives traffic or has backlinks gets a redirect. Our 404 glossary entry covers what to leave alone.
55. Compare clicks against the same period last year, in addition to the weeks just before launch. Seasonality fools more migration post-mortems than bugs do. On Prawomat, the 2025 comparison is what made the 2.9x meaningful.
56. Track rankings for your money keywords from step 7, watching for the ranking URL changing as well as the position.
57. Re-run the AI visibility prompts from step 9 at weeks two, six and 12.
58. Recrawl the site at day 7 and day 30. New content added after launch is where fresh broken links and chains appear.
59. Keep redirects for at least a year. Google’s guidance: keep them “for as long as possible, generally at least 1 year.” In practice, keep them forever; they cost nothing.
60. Update external links you control: social profiles, directory listings, partner sites.

Normal wobble vs a real bug

Google warns that rankings can fluctuate while it recrawls and reindexes a moved site. Here is how we tell a wobble from a bug:

• Normal: impressions dip or bounce for one to three weeks while clicks on your top pages hold roughly steady; old URLs linger in results for a few weeks; the “Page with redirect” count in Search Console climbs (that is Google processing your map).
• Bug: a whole section drops to near zero; clicks fall on pages whose URLs did not change; 404 or soft 404 counts keep climbing after week two; branded queries drop; conversions fall while traffic holds (that one is broken tracking).

A sharp drop in the first 48 hours is almost always technical: noindex left on, robots.txt blocking, redirects not deployed, canonicals pointing at staging. Check those four before anything else.

Platform Notes

Leaving WordPress? Add three steps to Phase 1: export the redirect plugin’s rules, export the SEO plugin’s per-page titles and canonicals, and list every shortcode that renders content. Plugins carry redirects, schema and sitemaps that vanish with them. Hosted builders impose their own URL rules; see our Webflow migration guide and our Squarespace to WordPress migration walkthrough.

How We Run Migrations

We treat the URL map as a build artifact. On Prawomat, the build fails if any migrated URL goes missing, so URL parity is a test instead of a launch-day worry. Redirects are verified on the deployed preview, rule by rule, because a local checker cannot see what the edge does. Every keep, merge or retire decision traces back to click and backlink data. That is what separates a rebuild from website migrations that grow organic traffic.

FAQ

How do I migrate my website without losing SEO?

Benchmark first, keep URLs unchanged wherever possible, and map every old URL to its closest equivalent with one permanent redirect. Test the map on staging, verify it on launch day, and watch Search Console for 90 days. Most losses trace back to a missing redirect, a leftover noindex, or pages merged into irrelevant destinations.

How long does a website migration take?

The build can take days with modern tooling. The full migration, from benchmark to launch, typically takes four to 12 weeks depending on URL count and how many pages are being consolidated; Prawomat took nine weeks from first commit to live. After launch, Google says it can take a few weeks or more for new URLs to replace old ones, and longer for large sites.

How much traffic do you lose after a migration?

A well-run migration should lose little beyond a short wobble, and one that improves content and speed can gain: Prawomat’s Google clicks rose 2.9x in the 19 days after its switch. Large, lasting losses almost always come from specific, fixable errors, and the benchmark tells you which pages lost and why.

Should I change URLs during a migration?

Only when the old structure causes real problems, such as duplicate paths, parameter clutter or URLs that no longer describe the page. Every changed URL depends on a redirect working forever. If you are only changing platform or design, keep the URLs identical.

What is a 301 redirect map?

A spreadsheet listing every old URL with its new destination, status code (usually 301) and the reason for the decision. Developers implement it and QA tests against it. A good map has no blank rows, no homepage catch-alls and no chains.

Do I need Google’s change of address tool?

Only if you are moving from one domain or subdomain to another, for example from example.com to example.org. For a platform change, redesign or URL restructure on the same domain, the tool does not apply; your redirects and sitemaps do the work. The tool also requires 301 redirects to be in place first.

Does a migration affect AI search visibility?

It can, in both directions. AI answers draw on pages search engines have indexed, so a broken migration removes you from them along with the rankings. A migration that makes pages faster, cleaner and easier to quote can increase citations; Prawomat’s appearances in Google’s AI answers rose 6.4x in the 19 days after its switch.

Get a Second Pair of Eyes

Planning a migration, or already three weeks past one and not sure whether the dip is a wobble or a bug? We will review your URL map, redirects and launch data and tell you what we find. Request a free migration check.

Sources

• Google Search Central, Site moves with URL changes (timing, soft 404 risk of homepage redirects, keeping redirects at least one year, old and new sitemaps, internal links, ranking fluctuations).
• Google Search Central, Redirects and Google Search (permanent vs temporary redirects, JavaScript redirects).
• Google Search Central, How HTTP status codes affect Google’s crawlers (up to 10 redirect hops).
• Google Search Central Blog, Analyzing Google Search traffic drops (16 months of Performance data).
• Google Search Console Help, Change of Address tool (domain and subdomain moves only, 301 prerequisite).
• Cloudflare Docs, Pages redirects (2,000 static and 100 dynamic redirects, static before dynamic).
• IndexNow, FAQ (participating engines, submitting redirected and deleted URLs).
• SEO Savages, Prawomat case study (URL counts, timeline, click and AI answer changes).