Website Migration: Moving Off Webflow, Framer, WordPress, Squarespace, or Wix Without Losing Rankings
A website migration keeps its rankings when it is run as an SEO project with a build inside it, not a redesign with a redirect step at the end. The order is fixed: inventory every URL with its traffic, agree a map of where each one goes, build the new site on a preview URL, write and test a 301 for anything that moves, carry over titles, descriptions, canonical tags, and structured data, cut over from staging, submit the new sitemap, then watch Search Console daily for four weeks and fix anything that moved. Google's site-move guidance says to keep the redirects at least a year and that a medium site takes a few weeks for most pages to move. The platform you are leaving changes only the first step, since Webflow, WordPress, Squarespace, Wix, and Framer each let a different amount out the door. We ran this recipe on a WordPress site, redesigned in the same project, and lost zero rankings.
Why migrations lose rankings
Not because Google punishes moves. Google's documentation on site moves with URL changes is explicit that it expects them and describes how to do them. Rankings go because of three things that are entirely in the migrating team's hands.
URLs that go nowhere. A page that ranked has a URL, and the new site has a different one, and nobody wrote the redirect. The old URL now returns a 404 and the ranking evaporates over a few weeks. On a fifty-page site this is usually the blog: the posts came across, the URL pattern changed, and the redirects covered the main pages only.
Metadata that got rebuilt from scratch. The title that ranked was written three years ago by someone who tested it. The new site's designer wrote a nicer one. The nicer one ranks for nothing. The same happens to descriptions, canonical tags, and structured data, which most builders generate invisibly and most rebuilds forget to reproduce.
Nobody watching. The move happens on a Friday, the team looks at the new site on Monday, and the first sign that the blog is gone from search arrives when a customer mentions it in November. Google says a medium site takes a few weeks for most pages to move; that window is when the damage is visible and cheap to fix, and it is the window nobody is looking.
Every step below exists to close one of those three.
What each platform lets you take with you
The export is the step that changes by platform. We read every vendor's own documentation this week; the alternatives pages linked in each row carry the details and the prices.
| Leaving | What comes out | What does not | Practical plan |
|---|---|---|---|
| Webflow | Static HTML, CSS, JS, and assets; CMS collections as CSV | Interactions and the CMS wiring | Rebuild from the export; CSV becomes MDX or a headless CMS |
| WordPress | Everything: posts, pages, media, and metadata via the export tool and the REST API | Plugin-generated pages and shortcodes | The cleanest export; the work is deciding which of thirty plugins become code |
| Squarespace | A WordPress-format XML of layout pages, one blog, galleries, text and image blocks | Store, index, cover, and portfolio pages; product, audio, and video blocks; custom CSS and styles, per Squarespace's own list | Rebuild from the live site; the XML covers the blog |
| Wix | Blog posts, products, and contacts as files; media by download | The site itself, which Wix's documentation says must run on Wix's servers and cannot be exported | Rebuild from the live site, everything |
| Framer | The published HTML, CSS, JS, and assets as files; CMS content as CSV or JSON via plugins | A self-hostable site, which Framer's help center says it does not offer | Rebuild from the live site; CSV covers the CMS |
The lesson in the table: the export is never the migration. In four of five cases the site is rebuilt from what is live, and the thing that has to be perfect is not the export file but the inventory of URLs.
Week 0: the inventory and the map
Before anything is built, every live URL goes into a spreadsheet with four columns: the URL, its sessions from analytics for the last twelve months, its clicks and top queries from Search Console, and where it goes next. That last column is the migration. Most rows are one to one. Some are one to many, where a long page becomes several. Some are many to one, where five thin posts consolidate into one. A few go nowhere on purpose, and those get a 410 and a decision, not an accident.
Then the crawl. A crawler run against the live site catches the URLs analytics forgot: paginated archives, tag pages, image attachment pages, the PDF someone linked from a partner site in 2022. On a builder these are numerous and invisible from the admin.
The map is agreed in writing with whoever owns the site before a line of the new one is built. It is also where the price of a migration comes from: our Website Migration is from $6,000 flat for a site of up to twenty pages, and the inventory is what tells you whether you have twenty pages or a hundred and twenty.
Week 1: the build, on a preview URL
The new site is built on its own account, in its own repository, on a preview URL that is not indexed. For us that is Next.js on the client's Vercel or Cloudflare account. Content comes out of the builder through the export or, for Wix and Squarespace's uncovered pages, by hand from the live site, and lands in files or a headless CMS depending on how often the team edits.
Two rules during the build. Every page on the map gets built, including the ones that seem minor, because the map was made from traffic and the minor page is the one ranking. And the metadata is carried, not rewritten: the title, the description, the canonical, the Open Graph tags, and the structured data of every page are copied from the live site into the new one before anyone improves them. Improvement is a separate project, run after the rankings have settled.
Week 2: the redirects, written and tested
Every row in the map where the URL changes becomes a permanent redirect. Google's guidance says to use permanent server-side redirects, 301 or 308, and to keep them for as long as possible, generally at least a year, and from the user's perspective indefinitely. Ours live in the site's config and ship with the code, so they cannot be lost when someone changes hosts later.
Testing is a script, not a click. The script requests every old URL against the preview site and checks that it returns exactly one 301 to exactly the destination in the map, with no chains, no loops, and no redirect to a page that itself redirects. It runs again on cutover day against the live domain. The image URLs, the sitemap URL, and the robots file are in the list too.
Cutover: from staging, never live
The person who owns the site clicks through the preview and signs off. DNS moves. The old sitemap is replaced by the new one in Search Console, and if the domain changed, the Change of Address tool is used; Google notes it applies only to domain moves, not to path changes on the same domain. The old builder stays alive and paid for one more billing cycle, so that anything missed can be recovered from the source rather than from memory.
The redirect script runs against the live domain within the hour. Analytics, the tag manager, and every form are tested end to end with a real submission that lands in a real inbox. On this site that check is a script that fills every form and confirms the email arrived, which is a habit worth copying.
Weeks 3 to 6: watching, and fixing what moved
This is the step most migrations skip, and it is the one that decides the outcome. Search Console is checked daily: the coverage report for new 404s and soft 404s, the sitemaps report for indexation of the new URLs, and the performance report, filtered to the pages that carried traffic in the inventory, for clicks and position against the four weeks before the move. Google says a medium site takes a few weeks for most pages to move and that visibility may fluctuate temporarily during the move; the fluctuation is expected, a page that drops and stays down for two weeks is not.
When something moved, the fix is almost always one of the three failures above: a URL that was missed in the map, a title that was rewritten, or a page that was consolidated and should not have been. All three are cheap to fix in week three and expensive to discover in month three.
The receipt
2Wheel Epix runs multi-day mountain-bike tours in Oaxaca, Ecuador, Peru, Bolivia, and Colombia, on queries where a few operators compete hard for every ride. We moved the site off WordPress with a full redesign in the same project, which is the riskiest version of a migration, because every URL, every title, and every page's content changed at once. The recipe above was the project plan. Rankings lost: zero. That migration went into a builder rather than out of one, and the discipline is identical in either direction; the reason we now move sites the other way is the four reasons teams leave builders, which the five alternatives pages above lay out platform by platform.
The second receipt is the site you are reading, which is the stack we migrate to: Next.js on Cloudflare, in a repository, with the redirects in the config, every form smoke-tested from a script, and a post shipped daily since 31 August 2026.
What a migration costs
Three honest answers, depending on where you are going.
To managed WordPress hosting, from WordPress: usually free. Kinsta advertises free migrations and WP Engine has a migration plugin; the site does not change, only the host.
To another builder: DIY or a freelancer, a few hundred to a few thousand dollars by page count, and no export from Wix or Framer to speed it up. Run the inventory and the redirect map anyway; the builder will not do it for you.
To code, run as above: our Website Migration is from $6,000 flat for a site of up to twenty pages including posts, about two weeks to cutover and four weeks of watching after, with the URL map agreed in writing before anything moves, the site delivered on your own Vercel or Cloudflare account in your own repository, and larger sites quoted from the inventory before day one. Afterwards the Website Care Plan at $1,500 a month keeps it hosted at cost, edited within two business days, updated, and monitored, which is also where the daily Search Console habit lives for a team that does not want to run it.
If the site is one page, skip the migration and build it fresh with a Landing Page Sprint. If the site has no rankings to protect, the same applies to the whole site: a migration is an SEO project, and without the SEO there is nothing to migrate, only something to build.
The checklist
- Every live URL in a sheet with traffic, queries, and a destination. Crawl for the ones analytics forgot.
- The map agreed in writing. The number comes from the map.
- Build on a preview URL, on your own account, in your own repository.
- Carry every title, description, canonical, and schema before improving any.
- A 301 for every changed URL, tested by script, kept for at least a year.
- Cut over from staging. Keep the old platform alive one more cycle.
- New sitemap submitted, Change of Address if the domain changed, forms tested with real submissions.
- Search Console daily for four weeks, filtered to the pages that mattered. Fix what moved.
The migration is done when the rankings say so, not when the DNS does.
Have a product idea?
Designed, built, and shipped in about 5 days.