Moving a site from one builder to another without losing the search traffic

Most people plan a website migration backwards. They start by picking the new platform — comparing templates, reading reviews, signing up for a trial — and only once the new site is mostly built do they think about what happens to the old one. By then the question has quietly become "how do I point the domain at this," when the question that actually decides whether the move costs anything was "what URLs does my current site have, and where does each one need to end up." Asked in that order, on a site with any search traffic at all, a migration is a redirect project with a rebuild attached to it — not the other way round.

This matters because search engines do not track your intent, they track your URLs. A page ranking for a useful phrase is not a page Google likes in the abstract; it is a specific address that has accumulated links, clicks and time, and all of that is filed under that address, not under the business or the brand. Move the content to a new address without telling anyone what happened to the old one, and you have not moved the ranking — you have created a new, unranked page and left the old one to quietly disappear, taking its history with it. The rebuild is real work, but it is recoverable work: a bad template choice can be fixed on a Tuesday. A missing redirect map can cost months, and by the time the traffic dip shows up in your analytics, the cause is three weeks in the past and much harder to trace.

Start with the inventory, not the template

Before touching the new platform, crawl the site you already have and produce a flat list of every URL that is currently live. Free crawlers handle a small site in minutes; for a site under a few hundred pages this is not a specialist task. Against each URL, record whether it has search traffic, whether it has inbound links from other sites, and roughly what it is about. That list is the actual scope of the migration. Everything else — the new design, the new copy, the new platform's feature set — is downstream of it.

The reason this has to come first rather than second is that it is the only step that tells you what you are allowed to change. A URL with meaningful traffic or a handful of inbound links is not available to rename casually; whatever replaces it needs a redirect pointed specifically at its replacement, and the platform you choose needs to be one that lets you set that redirect. A URL with nothing pointing at it is available to drop entirely, which is a legitimate outcome and one people underuse — not every old page deserves to survive the move, and carrying dead weight into a new site for the sake of completeness is its own kind of cost. The fuller method for building this into an actual redirect map, including how to decide which pages to drop rather than carry forward, is in keeping your URLs when you move.

Where reach fits, and where it plainly does not

If the site in question is a single person's page — a portfolio, a CV turned into a page, a freelancer or consultant's one-pager — reach is the strongest answer available, and "migrate" is arguably not even the right word for what you are about to do. You upload the CV you already have, answer a short form, and a complete page is generated in about twenty seconds; you can be live on a free subdomain in under two minutes, which is faster than most platforms let you configure a single redirect. For a site that is one page wide, the honest comparison is not reach's migration tooling against anyone else's, because reach does not have migration tooling — it is whether rebuilding from the CV is faster than exporting and reassembling whatever the old platform hands back. It usually is.

That comparison has a hard edge, though, and it belongs here rather than in a footnote: reach has no HTML export and no custom code field. The markup a reach site is built from never leaves the platform, so if you build there today and want to leave for a multi-page site, a CMS, or anywhere with server-side logic later, there is nothing to export — you rebuild from what is visible on the page, the same way you would if you were leaving a platform with no export button at all. reach is also strictly one page: one index.html, no sub-pages, no navigation tree, no contact form beyond a mail link. A site that has grown past a single scroll — multiple sections with their own URLs, a blog, a services page with its own ranking history — is exactly the case this article is about, and it is not what reach is built for. Where it earns its place in a migration conversation is narrower and real: the one-page personal site that is being rebuilt anyway, where the fastest honest path is starting over rather than dragging an old export through a redirect map for content that was three sentences of bio and a project list to begin with.

What each builder actually hands you on the way out

The word "export" on a pricing page rarely means what it sounds like. Most platforms give you back your text and your images, detached from the layout they were sitting in, which is useful for rebuilding but is not a working site. A genuine code export that runs on any host is rare, because it requires the vendor to hand over the templating engine that is the actual product. Webstudio is the clean exception among newer tools — it is AGPL-licensed and produces a standard Remix/React codebase you can self-host, so leaving its own hosting does not mean leaving the site behind. Self-hosted WordPress qualifies by default, since the content already lives in a database you control; there, migration is a hosting decision more than a platform decision. Ghost sits in the middle: since a July 2026 update it generates a Markdown version of every public post, reachable by appending .md to the post's own URL, which gets your writing out cleanly even though the layout does not travel with it.

At the other end, Butternut AI offers no code export, no WordPress export and no static export of any kind — leaving means copying text off the rendered page by hand, because there is no file the platform will hand you. It is worth pairing that with the rest of Butternut's picture rather than judging it on the export question alone: the fast, CV-driven "20 seconds" flow that makes it reach's closest direct competitor sits alongside a seven- person team with no disclosed funding since 2023, a $5 entry tier that exists specifically to keep the vendor's badge visible on the page, and documented complaints about mismatched imagery and generic copy in niche categories. The speed is real. So is the fact that whatever you build there stays there. The full breakdown of what each platform's export button actually produces — including where Wix's "you cannot switch template" restriction fits into the same lock-in question from the inside rather than the outside — is in what you can actually export from each website builder.

The redirect map is the part that is not optional

Once the inventory exists, the redirect map is mechanical, but it has to be one-to-one. The common failure is redirecting every old URL to the new homepage because it is faster than mapping each one individually — it makes every old link "work" in the sense that it loads a page, but a redirect that lands somewhere unrelated to what it used to be about does not carry ranking signal with it. Search engines treat an off-target redirect much like a page that returned an error: the address stopped meaning what it meant. The old blog post about pricing needs to redirect to the new page about pricing, not to the new site's front door, even when the front door is nicer to look at.

Decide deliberately which URLs from the inventory get a redirect and which are allowed to 404. A URL with real traffic or real inbound links gets one. A URL nobody visits and nobody links to can be dropped — that is a legitimate, even healthy, outcome of a migration, and trying to redirect everything indiscriminately just adds maintenance surface for pages that were never doing anything. Whichever platform you land on, confirm it lets you set redirects yourself rather than routing every request through a single catch-all rule, because a catch-all is exactly the shortcut that erases the ranking signal you are trying to keep. The week-by-week checklist for building and verifying this map, including which search-traffic checks to run after cutover and how long to keep watching before declaring it fixed, is in keeping your URLs when you move.

Sequencing the domain so the site is never dark

DNS is the part people rush, usually because it is the last step and the new site already looks finished. The order that avoids downtime is to build and fully test the new site on its platform's own temporary address first — most builders give you one automatically — and confirm every page, form and redirect works there before touching the domain at all. Only after that verification does the domain move, and even then it should not move all at once from the user's point of view: DNS changes propagate over minutes to hours depending on the record's cache lifetime, not instantly, so there is a window where some visitors reach the old site and some reach the new one no matter how carefully the change is timed. Lowering the DNS record's time-to-live a day or two before cutover shrinks that window; it does not remove it.

Custom domains behave differently across platforms during this window, and it is worth knowing which kind you are dealing with before cutover day rather than during it. A reach custom domain, for comparison, takes minutes to hours after payment for DNS and the SSL certificate to settle — not the instant switch that publishing to a free subdomain gets, which lands live in seconds because it is a file copy and a status flip rather than a registrar-dependent process. Any platform where the domain is bought through the platform itself tends to behave similarly; any platform where you are pointing an externally-owned domain at new infrastructure adds the extra step of confirming the old host's DNS records — particularly MX records, if email runs through the same domain — are copied over before the old account is closed, not after. Losing email because a DNS record was assumed rather than copied is one of the more common ways a migration goes wrong for reasons that have nothing to do with the website itself.

Keep the old hosting account active and unmodified until the new site has been live and verified for at least a few days, not hours. That overlap is cheap insurance against exactly the kind of DNS propagation lag described above, and against the redirect gaps that tend to surface only once real traffic — not your own testing — starts hitting the new site's edges. The fuller list of what quietly goes missing in that window even when the redirects are right — comment threads, form submissions, published dates, image alt text — is in what you lose when you migrate a site, and it is worth reading before cutover, not after someone asks where a testimonial went.

When the honest answer is not to migrate

A meaningful share of migrations happen because a site feels dated, not because the platform has hit an actual ceiling, and those two problems have very different cures. If you can name a specific capability your current platform lacks — no CMS when you need one, no e-commerce, a hard page limit you have hit — that is a real reason to move, and the redirect work above is the price of moving correctly. If you cannot name anything and the site just feels tired, the fix is usually a current price, a recent example, and design attention applied to the platform you are already on, which is cheaper than a rebuild and carries none of the redirect risk described in every section above it. A redesign in place never has to answer the question of what happens to a URL that has been ranking for two years, because the URL never changes.

That is worth sitting with before opening a comparison chart for the next builder, because the chart answers a question — which platform has the better feature set — that is not always the one actually costing you traffic or time. The fuller case for staying put, with the specific symptoms that a rebuild will not fix, is in the rebuild you should not do. Read it before the inventory, not after, because it can save you from doing the inventory at all.

Route	What it involves	Real cost
Full migration, sitewide	URL inventory, redirect map, DNS cutover, content rebuild	Days to weeks of work; risk is concentrated in the redirect map
Rebuild a one-page personal site on reach	CV upload, twenty-second generation, live in under two minutes	$0 on the free subdomain; $4.99/month or $49/year for a custom domain
Redesign in place, same platform	Updated copy, current examples, visual refresh	Design time only; no redirect risk because no URL changes
Do nothing, fix the content	New prices, a recent case, a working contact link	The cheapest option, and often the correct one

Prices checked August 2026.

Whichever route it is, the decision that matters most is made before any template is chosen: what is the URL inventory, what on it is actually worth protecting, and is a full migration the only way to protect it. Everything after that — the platform, the design, the DNS sequencing — is the work of carrying out a decision you have already made, not the decision itself.