If you did the planning right, this is the easy part.

In Part 1 we prepped your current site. We audited the traffic, mapped the backlinks, captured every redirect and meta tag, and built one master sheet that scripts every URL. That sheet did one more thing we skipped past. It mapped your content into a CMS plan. Which posts become Collections. Which fields each one needs. What stays a static page.

So now you are not staring at a blank Webflow canvas wondering where to start. You are executing a plan.

This is Part 2 of our complete guide to migrating from WordPress to Webflow. It covers the actual build: turning your CMS map into real Collections, importing your content, rebuilding the design on a clean system, and wiring up forms. Across the roughly 12 WordPress to Webflow migrations we have run, including Transfr at 250 pages, the builds that go smoothly all share one trait. The plan was done first, and the build just follows it.

From your migration plan to a Webflow build

Here is the handoff most teams fumble. They finish planning, open Webflow, and start designing a homepage. The content gets bolted on later, and the structure never quite fits.

We work in the opposite order. Content structure first, design second. Your master sheet already grouped your content into collections and listed the fields each one needs. So the first thing we build in Webflow is not a page. It is the data model.

Get the structure right and the design has somewhere clean to live. Get it wrong and you are rebuilding Collections halfway through the project, which means re-importing everything.

Step 1: Turn your CMS map into Webflow Collections

Your CMS map from Part 1 is the blueprint. Now you build it.

Each WordPress content type becomes its own Webflow CMS Collection. Your blog posts become a Posts Collection. Case studies, a Case Studies Collection. Team members, a Team Collection. This mapping is direct, and it comes straight from how WordPress already organized your content into post types.

The trick is the fields. A WordPress post is not one blob of text. It is a title, a slug, a featured image, an author, categories, tags, and a body, plus any custom fields a plugin like ACF added. Each of those becomes a field on your Collection. Here is how the common pieces map.

[ TABLE TO ADD: WordPress to Webflow CMS field map. Columns: WordPress | Webflow CMS field | Note. Rows: post type to Collection; title and slug to Name and Slug; author to single reference (Team Collection); categories and tags to multi-reference; featured image to image field; ACF custom fields to dedicated fields; post body to rich text. ]

One decision pays off later: split structured data into its own fields instead of burying it in the rich text body. If every case study has a client name, an industry, and a result, those are three fields, not three lines inside a paragraph. Structured fields are what let you design once and reuse everywhere.

Step 2: Import your content

With the Collections built, you bring the content across. The order matters.

Import your reference Collections first. Your categories, tags, and authors have to exist before the posts that point to them. If you import posts first, their references have nothing to link to. So you load the small reference Collections, then the posts.

Use the right import path for the volume. Webflow has a native CSV importer that maps each column in your file to a Collection field. For every column you choose to match an existing field, create a new one, or skip it. Matching on the Item ID updates items you already imported instead of duplicating them. You can test the whole thing free with a CSV of up to 50 items before you commit to the full load.

Let a tool handle the messy export. As covered in Part 1, exporting WordPress content built with a page builder drags along code and junk markup. The free Exporter for Webflow plugin helps here. It works around Webflow's 4MB CSV size limit by splitting your content into a ZIP of smaller files, and its Smart Match feature auto-maps the exported fields to your Collection fields. Then we run the content through an AI cleanup pass to strip the leftover div soup and shortcodes before it ever lands in Webflow. Done right, you keep the meta titles, the URLs, the body, and the in-content images.

The strategy is hybrid. CSV import for the bulk, structured content. Manual rebuilding for the design-led static pages. No tool recreates your homepage, so do not wait for one.

Step 3: Rebuild the design on one clean system

This is where a migration becomes an upgrade instead of a copy. You are not cloning the old WordPress theme. You are rebuilding the design properly, on a system that scales.

The single most important build decision is this: pick one class-naming system and stick to it. A consistent, descriptive class system is what keeps a Webflow site clean enough to edit a year from now. We build on Client-First or Lumos, the two leading frameworks, because both give us clean, scalable structure instead of a tangle of one-off styles.

[ TABLE TO ADD: Client-First vs Lumos. Columns: (blank) | Client-First (Finsweet) | Lumos. Rows: Approach = descriptive readable class names / extensive utility-class system; Best for = beginner to intermediate, team handoff / power users who want maximum reuse; Why it scales = anyone can read and edit safely / utilities cover spacing, grid, layout fast. ]

Then build with components, not one-off sections. A Webflow component has a base, the source of truth, and instances placed across the site. Edit the base once and every instance updates. Your nav, footer, buttons, and cards become components, so a brand change is one edit, not fifty.

For the static, design-led pages, we build reusable Webflow templates and place components inside them. That is what makes the finished site easy to scale and easy for your team to edit. The whole point of moving to Webflow is that marketing can ship without a developer. A clean component system is what delivers that, and it follows the same Webflow development best practices we use on every build.

Step 4: Rebuild forms and integrations

Forms are where a lot of migrations quietly break, because the WordPress plugin that ran them does not exist in Webflow. Good news: you usually do not need it to.

Native Webflow forms cover most of what a marketing site needs, including file uploads. They capture submissions out of the box, and you can connect them to HubSpot through a native app that syncs your existing Webflow forms without rebuilding them. If you run your pipeline through HubSpot, plan that connection during the build, not after. We covered the exact setup in our guide to connecting HubSpot forms to Webflow.

One real limit to design around: a Webflow Collection list renders a capped number of items per page. For a large blog or resource library, that matters. The standard fix is Finsweet Attributes, specifically CMS Combine, which lets you display more items than a single native Collection list allows. We plan for this on content-heavy sites so the library does not hit a wall at launch.

The build-phase mistakes that cause rework

Most rework on a migration traces back to a few build decisions. Avoid these and you avoid re-doing days of work.

  • No single class system. Styling with one-off classes for every element. The site works at launch and becomes unmaintainable a month later.
  • Skipping components. Hard-coding the same nav and footer on every page, then editing fifty copies when the brand changes.
  • Trusting the raw import. Dropping exported WordPress content straight in without a cleanup pass, so page-builder markup and shortcodes ride along.
  • Building Collections by guess. Starting the data model without the CMS map, then rebuilding Collections mid-project, which forces a full re-import.
  • Ignoring Collection list limits. Designing a 500-post blog as one native list, then discovering it will not all render.

Notice the pattern again. None of these is a Webflow flaw. Every one is a build-discipline choice, and discipline is the part you control.

The limits, and how we plan around them

No honest build guide pretends Webflow does everything WordPress did. Here is what to plan around.

  • Imported content needs a human pass. Even with a good export tool and AI cleanup, we review every Collection before it goes live. Bulk import gets you 90 percent there, not 100.
  • Collection lists have a render cap. Large libraries need Finsweet Attributes or smart pagination. We design for it up front.
  • Plans changed in 2026. Webflow restructured its plans, merging the old CMS and Business tiers. So we size your plan to your real content count rather than quoting yesterday's limits.
  • Components take setup time. Building a proper component system is more work on day one. It pays for itself the first time you need a site-wide change.

None of these are reasons to stay on WordPress. They are reasons to build deliberately, which is the whole job.

Rebuild a WordPress site in Webflow: FAQ

How does WordPress content map to the Webflow CMS?

Each WordPress post type becomes a Webflow CMS Collection, and each piece of a post becomes a field. The title and slug use Webflow's built-in Name and Slug fields, the author becomes a single reference field pointing to a Team Collection, categories and tags become multi-reference fields, the featured image becomes an image field, and the body becomes a rich text field. Custom fields from a plugin like ACF become their own Collection fields.

What is the best way to import WordPress content into Webflow?

A hybrid approach. Use Webflow's native CSV importer for bulk, structured content like blog posts, and rebuild design-led static pages by hand. Import your reference Collections, such as categories and authors, before the posts that link to them. A tool like the free Exporter for Webflow plugin handles the export and field mapping, and the content should be cleaned of page-builder markup before import.

Should I use Client-First or Lumos for a Webflow build?

Either works well. The important thing is to commit to one class-naming system and use it consistently. Client-First, by Finsweet, uses descriptive, readable class names and is friendly for teams and handoff. Lumos leans on an extensive utility-class system for fast, reusable layout. Both produce clean, scalable sites, which is what keeps a Webflow build editable over time.

Do I need a third-party form plugin in Webflow?

Usually not. Native Webflow forms handle most marketing needs, including file uploads, and capture submissions without any add-on. They also connect to HubSpot through a native app that syncs your existing forms, so most teams never need a separate form tool.

Ready to rebuild?

The plan is what makes the build smooth. The build is what your visitors and your team actually live with every day.

If you are weighing a move off WordPress, or you have a plan and need a clean, scalable Webflow build to match it, that is exactly what we do. Talk to us about your migration, and we will build it to last instead of just to launch.

Next in this series: Part 3, going live. DNS, redirects, the launch-day checklist, and what to watch after. And for the full redirect and ranking-preservation playbook, see our guide to protecting your search rankings during the move.