Replatforming is a migration, not a redesign
Leaving a website builder is usually framed as a design project with a technical step at the end. It is the reverse. The design is the easy half. The migration — URLs, redirects, content, tracking — is what decides whether you keep the traffic you spent years earning.
The good news is that migrations fail in predictable ways, so they can be planned around. Nearly every replatform that loses traffic lost it to one of four things: changed URLs without redirects, dropped pages, shortened content, or broken tracking that hid the first three for a month.
Know what your builder did to your URLs
Each platform has its own conventions, and they are the first thing to map. Squarespace tends to prefix collection items, so posts sit under a blog or portfolio segment. Wix historically produced URLs that do not map cleanly to a conventional structure, and older Wix sites may still carry hash fragments from before its SEO overhaul. WordPress depends entirely on the permalink setting — a site on the default query-string permalinks is a very different migration from one on clean post-name slugs.
Do not guess any of this. Export the real list: every URL that has had an impression in Search Console over the last twelve months, plus everything in your existing sitemap. That list is the specification for the migration.
The three lists you need before anything moves
Which URLs bring in organic traffic. Which URLs have external links pointing at them. Which URLs convert. Search Console, your analytics and any backlink tool give you all three in an afternoon.
Every URL on those lists needs a decision made deliberately: kept at the same address, redirected to a specific equivalent, or retired knowingly. A page that earns traffic does not get dropped because it does not fit the new navigation. That is the rule the whole migration hangs on.
Redirect one-to-one, and keep them
Every changed URL gets a 301 to its closest equivalent page. Not to the homepage — a mass redirect to the homepage is treated as a soft 404 and throws away the value of the link. One old URL, one specific new URL, one permanent redirect.
Keep the redirects indefinitely. They are configuration, they cost nothing to carry, and they are the only thing holding the value of every link anyone has ever built to you.
Get the content out as content, not as HTML
Builders store your content wrapped in their own markup. Copying pages across as HTML carries their layout assumptions into the new site and you inherit the mess you were trying to leave. Extract the content as structured data instead — a post is a title, a date, a body, an author — and let the new site render it.
This is the step that makes the site easier to maintain afterwards than it was before, and it is worth the extra day it takes. It is also where content quietly gets shortened to fit a nicer layout, which is a ranking decision made in a design review. Do not make it there.
Rebuild the tracking deliberately
Analytics and conversion tracking break during almost every replatform, and because the reports still render, nobody notices for weeks. Rebuild them explicitly: analytics installed and verified, conversion events firing on the new forms, Search Console verified against the new property, sitemap resubmitted.
Verify these on launch day rather than the following month. Everything on this list is cheap to fix immediately and expensive to diagnose in retrospect.
Launch week, not launch quarter
Crawl the new site and check every URL from your three lists resolves or redirects correctly. Confirm the sitemap has been fetched. Watch Search Console for coverage errors and 404 spikes. Some ranking movement while search engines recrawl is normal; a sustained drop after a month is a migration problem, and it is still fixable if you are looking.
This is the sequence we follow on every website redesign — the audit and the redirect map exist before any design work starts. If you are still deciding whether to replatform at all, signs your website needs a rebuild is the shorter version of that question.