Webflow migration: what transfers to Contentive and what doesn't
A Webflow migration to Contentive, honestly: what our importers bring across, what you rebuild by hand, and how to keep the client's URLs and rankings.
Start with the expectation, because it shapes everything else: there is no Webflow importer in Contentive. Nothing reads a Webflow project, its CMS collections or its interactions directly. A Webflow migration to Contentive is a two-tool job, using importers that work on any public website, plus a fair amount of work by hand. If someone tells you a Webflow migration is a button, they're describing a site with no CMS and no interactions.
What follows is what each route actually brings across, what never comes, and how to keep the client's URLs and search rankings intact. Like our WordPress migration guide, it's a list of edges rather than a pitch, because the costly part of any migration is finding out three weeks later that something quietly didn't make it.
Route one: clone the site
The clone importer captures a public site's pages and turns them into a theme plus pages, in staging. Images, fonts and stylesheets are downloaded and re-hosted, so nothing hotlinks Webflow's servers after you switch off the old plan.
Two things to know about this version. First, the words sit inside the copied sections rather than as separate editable fields. The result looks right straight away, but it isn't yet editable the way you'll want a client to edit it. Treat it as a faithful starting point that you then restructure, not a finished site.
Second, nested URLs are flattened, with redirects added. A page at /services/seo/ becomes /services-seo, and the old path redirects to it. That's safe for visitors, but a redirect is not the same as an unchanged URL, which matters for the section on rankings below.
Cloning suits marketing pages: the home page, about, services, a landing page or two. It's the quickest way to get the look across while you decide the model.
Route two: the scraper
The scraper crawls the site, extracts the content from each page and can suggest a content model from what it finds. It's the better route for anything that was a Webflow CMS collection: blog posts, case studies, team members, job listings. Those come across as content rather than as copied sections.
What it doesn't do is build the theme. After a scrape you have content and a proposed model, and you write the theme yourself. Every import lands in staging, and a re-run updates the existing content rather than duplicating it, so you can adjust the model and import again.
Most real Webflow migrations use both: clone the marketing pages for their look, scrape the collections for their content, then rebuild properly.
What doesn't come across
Interactions and animations. Scroll effects, hover states built in the Interactions panel, page transitions, Lottie timelines. Some of the visual result may survive a clone as static styling. The behaviour does not. Rebuilding it means writing it in the theme's own CSS and JavaScript.
The CMS collection structure as such. The scraper reads rendered pages, not your collection schema. Reference fields, multi-reference fields and option fields have to be re-created in the content model by you. The scraper's suggested model is a starting point, not a copy of the original. Webflow can export a collection as CSV, which is useful as a reference while you check the result, but Contentive doesn't import CSV.
Forms and their submissions. The form markup may come across in a clone. The handling doesn't, and past submissions stay in Webflow. Export them before you close the account.
Ecommerce. Products, orders, customers, checkout. None of it, and Contentive has no shop to put it in. If the site sells things, this isn't the right move.
Member accounts and gated content, if the site uses them. Accounts and passwords don't transfer.
Site search settings, custom code embeds and third-party scripts. Note every embed on the old site and decide, one by one, whether it comes back.
The work that's yours
Four things, in roughly this order.
Decide the model. Look at what the scraper suggests, then design it properly: which collections become content types, which repeating sections become reusable sections, which references are real links. A migration is a good moment to fix the collection that grew twenty optional fields.
Rebuild the theme properly. Use the cloned pages as the visual reference, but write a layout, a template per content type and a template per section. The clone gives you the look. The theme makes it last.
Re-create the forms. Rebuild each one as a form, place it on its page, send a real test submission and confirm the notification arrives.
Check every redirect. Walk the list of old URLs against the new site. This is tedious and it's the step that protects the client's search traffic.
Keeping the rankings
Most of a site's search value is in its URLs, so treat the URL list as the core of the migration.
Before you touch anything, save the old site's
sitemap.xmlfrom Webflow. That's your list of every URL that matters.Map each old URL to its new one in a spreadsheet. Wherever the URL can stay exactly the same, keep it the same. For collection content, declare routing on the content type, such as
/blog/:slug, so entries can live at the same paths they did before, as long as their slugs match the old ones.For every URL that does change, including the flattened ones from a clone, confirm a redirect exists. A changed URL with no redirect is a launch blocker.
In staging, compare the generated sitemap against your list. Anything missing is either intentional, and written down, or a bug.
Only then promote to production and point the domain. Keep the Webflow site available, unpublished from the domain, for a fortnight in case you need to check something.
Before launch, run the rest of the pre-launch checklist.
When not to take it
Be honest about why the client is moving. If they want an editor that can't break the layout, predictable hosting costs across a portfolio, or a site an agent can help run, this migration makes sense, and Contentive vs Webflow sets out that trade-off fairly.
If the site's value is in its interactions, the scroll-driven storytelling and the animated reveals, then moving it isn't a migration. The parts that made the site special are exactly the parts that don't transfer. That's a redesign, so scope it and price it as one, or leave the site where it is.