How to Migrate From Webflow to WordPress Without Losing Traffic

The Export Button Is a Trap Here

Webflow gives you an export button, which makes this migration look easier than it is. It is not the same kind of export you are imagining.

There are actually two, and neither one produces a WordPress site.

The code export hands you static HTML and CSS. The markup is clean by web standards, but it is covered in Webflow's own generated class names and structural conventions, which exist to serve Webflow's Designer rather than to be maintained by a human afterward. More importantly, it strips out everything dynamic: CMS content, interactions, animations, and form handling all disappear. What you have is a photograph of your website.

The CMS export gives you one CSV per Collection. This one is genuinely useful, and it has a trap in it that we will come to.

So set the expectation correctly before you scope anything. A Webflow to WordPress move is a front end rebuild plus a structured content migration plus a redirect project. The exports assist with exactly one of those three.

If you have not settled the decision itself yet, the tradeoffs are in Webflow vs WordPress, and the wider set of options is in Webflow alternatives.

Benchmark Before You Build

This is the step that separates a migration you can manage from one you can only apologize for, and it takes about a day.

Crawl the whole site with Screaming Frog or Sitebulb. Every URL with its status code, title tag, meta description, H1, and word count. Save the export somewhere that is not the website.

Export Search Console, sixteen months by page and by query. This tells you which URLs actually earn traffic, which is rarely the list you would guess.

Export GA4 sessions and conversions by landing page for the past twelve months.

Export your backlinks. These URLs are non-negotiable redirect targets even when the pages get almost no traffic.

Save the sitemap. Webflow publishes one at /sitemap.xml.

Screenshot your rankings, dated.

Once the Webflow project is gone, none of this can be recreated. The reasoning behind each item is laid out in our SEO migration checklist.

Decide the Content Model First

This is where most Webflow migrations quietly go wrong, and the damage does not show up until a year later when the site has become miserable to maintain.

The mistake is dumping every Collection into the standard WordPress Posts type. It imports cleanly, it looks fine on day one, and it destroys your content model. Now your case studies, team members, locations, and blog posts are all the same thing, distinguished only by a category, and you cannot template them differently without fighting the platform.

Map it deliberately instead:

• Each Collection becomes a custom post type. Case Studies, Team, Locations, Services, each its own type.
• Reference and multi-reference fields become taxonomies. A Collection field pointing at a Categories Collection becomes a real WordPress taxonomy.
• Everything else becomes custom fields. Plain text, rich text, numbers, dates, images, and switches map to custom fields on the post type.
• Only the actual blog becomes Posts.

Write this mapping out as a table before you import a single row. It takes an hour and it determines how the site works for the rest of its life.

Export the Collections, Then Fix the Images

Webflow exports Collections one at a time from the CMS panel. Run each one and keep the files together.

Now the trap, and it is the single most expensive detail in this article.

The CSV does not contain your images. It contains links to images hosted on Webflow's servers.

If you import that CSV and change nothing else, your WordPress site will display images that are still being served by Webflow. Everything will look completely correct. Then your Webflow plan lapses and every one of those images disappears at once, on a site you believed you had already migrated.

Two things to do about it:

1. Download every asset locally and rewrite the references to point at your own media library. A media import script or a plugin that sideloads external images will handle the bulk of it.
2. Check the rich text fields separately. Images embedded inside a rich text field are buried in the HTML of that field rather than sitting in their own image column, so bulk tools frequently miss them. These are the ones that survive your testing and break later.

Before you cancel anything, crawl the new site and search the source for any remaining Webflow asset domain. Zero hits, or you are not finished.

Rebuild What Does Not Export

Three things need real budget, and pretending otherwise is how these projects run long.

Interactions and animations. Webflow interactions are produced by Webflow's own JavaScript and do not transfer in any usable form. They get reimplemented in CSS or with an animation library. On a design-led site this is not a detail, it is often a large share of what the site actually is. Scope it honestly at the start, and take the opportunity to decide which interactions were earning their keep and which were there because they were easy to add.

Forms. Webflow's native forms stop working the moment the site is not served by Webflow. Rebuild each one in a WordPress form plugin, wire the notifications to an inbox a human reads, and submit a real test enquiry end to end. Also export any submission history you need out of Webflow while the project is still active.

Ecommerce. Webflow Ecommerce products export separately and need mapping into WooCommerce column by column. Variants are where this gets tedious, because the two systems model them differently. Reconcile the product count afterward rather than assuming it worked.

Memberships, if you use them, do not transfer. Members have to be recreated in whatever membership plugin you choose, with a password reset communication planned in advance.

Build the URL Map

One spreadsheet, one row per old URL, one column for its destination.

Build the source list from the union of three exports: your crawl, Search Console, and your backlink file. Each finds URLs the others miss.

Webflow URL patterns to watch for:

• Collection items sit at /collection-slug/item-slug, so your case studies are probably at something like /case-studies/client-name
• Static pages sit at the path set in page settings, which may not match the navigation structure
• Webflow serves URLs without a trailing slash and WordPress commonly adds one, which is a redirect you want to handle deliberately rather than by accident

Then the four rules that govern every migration. Keep URLs identical wherever the new build allows it, since an unchanged URL carries no risk at all. Map one to one to the closest equivalent page, never in bulk to the homepage, because a redirect to an unrelated page reads as a soft 404 and drops the original from the index. Resolve chains so each old URL points straight at its final destination. Use 301, and leave the rules in place permanently.

Implement them at the server level in your host's configuration where you can, or in a redirect plugin where you cannot.

Test Before You Launch

Build on staging and protect it with HTTP authentication rather than a noindex tag. Authentication cannot be forgotten, because if it is still on at launch nobody can reach the site and you will know within a minute. A forgotten noindex tag is invisible and quietly removes the site from search over the following fortnight.

Before you flip anything:

• Run every old URL through the redirect rules and confirm each returns a 301 to the intended destination in one hop. Not a sample. All of them.
• Confirm no page carries an unintended noindex tag
• Confirm robots.txt is the production version
• Confirm the sitemap contains only canonical, indexable, 200-status URLs
• Search the source for any remaining Webflow-hosted asset
• Submit a real enquiry through every form
• Compare word counts against your original crawl, since content gets quietly shortened during rebuilds
• Check every template on a phone
• Compare page speed against your recorded baseline, because a Webflow site is fast by default and a WordPress rebuild that ships uncompressed images will be slower than what it replaced

Launch, In Order

1. Confirm you still have the Webflow project and all export files
2. Push WordPress live with the redirect rules already active, not added afterward
3. Remove staging protection, then immediately verify robots.txt and check the live source for stray noindex tags
4. Update DNS. Do it early in the day and allow for propagation
5. Crawl the live site immediately, looking for 404s, chains, and missing titles
6. Hand check thirty of your highest traffic old URLs
7. Submit the new sitemap in Search Console
8. Confirm analytics and conversion tracking are recording

Launch on a Tuesday morning. Problems found on day one are cheap when the people who built the site are at their desks.

Keep the Webflow plan running for at least thirty days. It costs one month and it is your only way back.

What to Expect Afterward

A short dip is normal. A permanent loss is not.

Search engines have to recrawl every redirected URL, follow it, process the destination, and reassign the signals. Under two hundred pages that takes roughly two to three weeks. Larger sites take six to eight.

Weeks one through three will fluctuate. By weeks four to six you should be back at baseline. A drop of thirty percent or more that has not started recovering by week three is a defect rather than the migration settling, and the first four places to look are the redirect map, robots.txt, the live source for a noindex tag, and whether content got shortened during the rebuild.

The Five Failures That Cause Most of the Damage

Images left on Webflow's servers. Everything looks right until the plan lapses, then every image on the site breaks at once. This is the one that catches the most people, because the site passes every test you thought to run.

Collections dumped into Posts. Imports cleanly, ruins the content model, and you live with it for years.

Redirect map built from the sitemap alone. Misses every orphaned page that still earns traffic and every page with inbound links.

Interactions treated as a detail. Scoped as an afternoon, discovered to be three weeks.

Forms rebuilt but never tested. Enquiries stop arriving and nobody notices for a fortnight, because an absence of leads looks exactly like a slow month.

Frequently Asked Questions

Can you export a Webflow site to WordPress?

Not as a working site. Webflow offers two separate exports and neither produces WordPress. The code export gives you static HTML and CSS with Webflow-generated class names, and it strips out CMS content, interactions, animations, and form handling. The CMS export gives you one CSV per Collection. A Webflow to WordPress move is therefore a front end rebuild plus a structured content migration plus a full redirect map, not an import.

Do images transfer when you export a Webflow CMS Collection?

No. The CSV contains links to images hosted on Webflow servers rather than the image files themselves. If you import that CSV and change nothing else, your WordPress site will display images that are still being served by Webflow, and every one of them breaks the day your Webflow plan lapses. Images embedded inside rich text fields are worse, because they are buried in the HTML of the field and are easy to miss entirely. Download every asset locally and rewrite the references before you cancel anything.

Should Webflow CMS Collections become WordPress posts or custom post types?

Custom post types with custom fields, in almost every case. The most common migration mistake is dumping every Collection into the standard Posts type, which flattens your content model and produces a site that is painful to maintain and impossible to template properly. A Collection maps naturally to a custom post type, its reference fields map to taxonomies, and its other fields map to custom fields. Decide that mapping deliberately before you import anything.

Do Webflow interactions and animations survive a migration?

No. Webflow interactions are generated by Webflow's own JavaScript library and do not transfer in any usable form. They have to be reimplemented in the new theme, either in CSS or with a JavaScript animation library. This is worth scoping honestly at the start, because on design-led Webflow sites the interactions are often a large share of what the site is, and rebuilding them is a real line item rather than a detail.

How long does a Webflow to WordPress migration take?

For a marketing site with one or two Collections and fewer than a hundred URLs, three to five weeks is realistic including the theme build, content mapping, redirect work, and testing. Sites with several Collections, heavy interactions, memberships, or Webflow Ecommerce run six to ten weeks. The exports themselves take an afternoon. The schedule is dominated by rebuilding the front end and getting the content model and redirects right.

Move It Once, Move It Properly

The two decisions that determine how this goes are both made before anything is built: how the Collections map into a WordPress content model, and what the redirect map covers. Projects that get those right tend to go fine. Projects that start with the theme and think about content structure later tend to get rebuilt again in two years.

Get a free Revenue Opportunity Analysis and we will show you which of your current pages earn the traffic, which URLs carry links you cannot afford to break, and what your redirect map has to cover. See how we handle rebuilds in WordPress development and website design and development, or read our process. Book a strategy call or call us at 321-401-7016.