Migrating off Webflow without losing your SEO

The code export is not your site

Webflow's code export is available on paid Workspace plans only. Site plans do not include it, which surprises teams who have been paying for hosting for years and assume the code comes with it. Press Shift+E in the Designer, click Prepare ZIP, and you get your HTML, CSS, JavaScript and the contents of the Assets panel, with no attribution required.

What you do not get is the thing your SEO depends on. Webflow states plainly that CMS content, User Accounts, Ecommerce data, localized pages and code components are excluded from the export. Collection lists render their empty state. Collection pages come out as blank templates with nothing bound to them. Forms and site search stop working entirely, which Webflow attributes to GDPR compliance. So if your organic traffic comes from 400 CMS blog posts, the ZIP contains 400 empty shells and zero words.

Content leaves through a different door. You can export CMS Collections, Ecommerce Collections and User Accounts as CSV, or pull them through the Data API, where a list request returns at most 100 items per page. Plan your fetch loop around the rate limit: 60 requests per minute on Starter and Basic, 120 on CMS, Ecommerce and Business. For a few thousand items that is minutes of work, not hours, but it is a separate job from the code export and nobody warns you about it in advance.

Build the redirect map before you build anything else

Google's site move documentation is unambiguous about the sequence. Map every old URL to its new counterpart, use server side 301 or 308 redirects, avoid redirect chains, and keep those redirects live for at least a year. Google also warns that it will crawl your new site harder than usual immediately after a move, because every hit on an old URL turns into a hit on a new one, so the new host needs headroom on day one.

Webflow's own redirects are worth understanding before you leave, because they set the shape of what you are replacing. There is no hard cap on the number of rules, but Webflow recommends staying under 1,000, since every rule is written into the site's manifest.json and browsers have to download it. Wildcards are the recommended way to keep the count down. The import is destructive: uploading a CSV of redirects wipes every existing rule, so export the current set first and edit that file rather than starting fresh. Do that export early anyway, since it is the closest thing you have to a record of every URL change your team has already made.

Google's own list of common migration failures is short and predictable. People redirect to URLs that do not exist on the new site. They leave a noindex tag or a robots.txt block in place after launch, having added it while the staging site was public. They forget to update the sitemap. None of these are subtle problems, and all of them are invisible until Search Console reports the drop a week later. Crawl your own redirects before launch and again the morning after.

Rankings follow speed, so do not regress on it

A migration that preserves every URL and still ships a slower site has traded one problem for another. This is where the move usually pays for itself. On Stay World Class we replaced Webflow and Xano with Next.js, NestJS and Supabase, and Lighthouse went from 55.91 to 91 out of 100, with LCP 77% faster. Those gains came from controlling the render path, which is exactly the thing a hosted builder does not hand over.

The data move deserves as much care as the URLs. We ran a four stage ETL that mapped every legacy ID to a PostgreSQL UUID and kept the mapping table, so any old reference could still be resolved after the cutover. Slugs came across unchanged, which is what made the redirect map small in the first place. If you rewrite your URL structure during the same migration, you are debugging two things at once and Google explicitly advises against it: move first, redesign later.

When staying on Webflow is the right answer

If your site is marketing pages and a blog, your team edits it without asking a developer, and nobody has complained about load times, migrating buys you very little. Webflow's visual editor is genuinely good at that job, and replacing it with a repo means every copy change now waits on someone who can open a pull request. That is a real cost and it recurs weekly.

The case for moving gets strong when the platform starts saying no to things you need. Custom server logic you cannot write, database queries you cannot tune, a CMS item limit you keep bumping into, tests you cannot run against your own business rules, or a bill that grows with traffic rather than with value. When one of those becomes the reason a roadmap item slips, the ceiling has stopped being theoretical. Until then, a redirect map is a lot of work to do for no reason.