How to migrate from WordPress to Webflow without losing SEO

Search this question and you'll get the same checklist five times over. Crawl the old site with Screaming Frog. Build a redirect map. Export your XML. Rebuild the CMS. Verify.

That checklist isn't wrong. It's just not where migrations actually go sideways. I recently moved Abatable, a voluntary carbon markets platform, off WordPress onto Webflow. Over 100 pages, a mix of static and dynamic. The parts that took real thought weren't on anyone's checklist.

The best redirect map is a short one

Abatable needed 58 redirects for a 100+ page site.

That number is the whole point. Most guides treat the redirect map as the centrepiece of the migration, which quietly assumes your URLs are going to change. Usually they change because the new site has a new structure, and the new structure exists because nobody questioned whether it needed one.

I start from the opposite position: keep every URL you can, and only accept a change where there's a real reason for it. Fewer redirects means fewer chances for a rule to misfire, less link equity passed through a hop, and, for the client's team, a site that still works the way they remember it.

Where you can't avoid it, WordPress will hand you a category of URLs that has no Webflow equivalent. Tag and category archives, date archives, attachment pages, paginated URLs. You have to decide for each group whether it earns a redirect or should just 404. The test is simple: does it have traffic or backlinks? If not, redirecting it to a vaguely related page is worse than letting it go, because you're teaching search engines your redirects aren't meaningful.

So the first job isn't building the map. It's working out how small the map can be.

The CMS transfer is where content actually breaks

This is the part almost no guide covers honestly, and it's where I spend the most effort.

Webflow's native CSV import works fine on simple collections. On anything with substantial rich text, it doesn't. You'll import a hundred blog posts and find half of them arrive with formatting stripped, or the rich text truncated partway through, or the nested elements flattened. Worse, it fails quietly. Nothing errors. You just have a CMS full of content that looks fine in the list view and is broken when you open it.

On larger sites I now use Claude to handle the content transfer in bulk. Where Webflow's character limits get in the way, I go around them: a Python script hitting the CMS API directly, pushing items from a CSV. That gives you control over exactly how each field is mapped and lets you verify programmatically that every item landed complete, rather than spot-checking twenty out of two hundred and hoping.

If you take one thing from this article, make it this: after any CMS import, check the rich text fields specifically. Not the item count. The content inside the items.

Deciding what becomes dynamic and what stays static

This is a judgement call, and generic guides skip it because there's no rule to state. The instinct is to make anything repeated into a Collection. That instinct is often wrong.

My default is to keep the system as familiar to the client as possible, so nobody has to relearn how their own website works. Beyond that it comes down to what the team actually needs from each page type.

For Abatable, my initial recommendation was that their solution pages should be dynamic. Same layout, different content, exactly the case for a CMS template. But their team needed maximum flexibility on each of those pages, and a CMS template can't give you that. Every page has to share one structure, so a change to one is a change to all of them. I built those pages static instead, which means the team can fully customise any one of them without touching the others.

The way I assess it now:

• How much layout flexibility does the team need per page? High flexibility pushes towards static.
• How many of these pages will exist in a year? High volume pushes towards dynamic, because nobody wants to hand-build the fortieth one.
• Who's creating them? A marketing team adding entries to a structured collection is a different job to a marketer needing to build a bespoke page for a campaign.

Repetitive layout with variable content is the classic dynamic case. Repetitive layout where the team keeps wanting to break the layout is a static case wearing a CMS costume.

Your traffic comparison is probably wrong

Here's the thing I didn't expect to be writing about.

After launch, I went looking for headline traffic numbers at Abatable and the picture was murky. There was a gap in tracking while consent was being set up, and the figures afterwards looked slightly lower than before. No obvious explanation, no big campaigns on either side of the launch to account for it.

Their marketing lead worked out what was going on. The old WordPress site almost certainly wasn't running a proper consent opt-out, which meant it was tracking everyone. The new site is consent-gated and tracking only opted-in visitors. Those are two different measurements of two different populations, and comparing them tells you nothing about the migration.

This is more common than you'd think. If the old site predates a properly configured consent setup, or the setup got lost in a previous rebuild, the pre-migration baseline you're about to judge your new site against is inflated by every visitor who would have opted out.

So capture what you can before you launch, and be honest about what the baseline is actually measuring. And lean on the metrics that survive the comparison. At Abatable, contact form submissions are up 54%, and the team reports that the enquiries are better qualified, more of them from the audience they actually want. A form submission is a form submission regardless of consent state. That number means something. A traffic delta across a consent-model change doesn't.

The migration itself is now the fast part

Two years ago this process took days of careful, tedious work. With AI handling the bulk content transfer, once the structure is built in Webflow I can migrate everything in a single morning.

That changes where the value sits. The typing was never the hard part, but it used to eat the budget. Now the time goes into the decisions: what stays at the same URL, what becomes a Collection, what the team needs to be able to do on their own afterwards.

Webflow announced Source at their conference this month, currently in limited research preview, which puts agents to work directly on the underlying code alongside the marketing team. If that lands the way it looks, this gets faster again.

When I'd tell you not to migrate

I only recommend a migration when the new platform solves an actual problem.

Most of my clients coming off WordPress describe the same one: managing the CMS was frustrating and they wanted a smoother experience. That's a real problem and Webflow solves it well. Abatable's team described the new site as a dream to manage compared to the old one.

But it's worth being precise about the cause. That frustration usually isn't WordPress's fault. It's how the site was built in the first place. A well-structured WordPress site with a well-configured editor is perfectly pleasant to run, and if that's what you've got, a migration is an expensive way to solve a problem you don't have.

The clearer test is who's going to be using it. Webflow is built for companies with a marketing team, people who need to publish, test and iterate without filing a developer ticket. If you're a solo founder or a small team with nobody in that role, you're paying for governance and collaboration features nobody will use, and something simpler will serve you better.

Where AI has genuinely changed things is the middle of the process, not the ends. It handles the repetitive work: moving content in bulk, mapping fields, checking a hundred imported items instead of a sample of twenty. Every bit of it still gets reviewed by a person, because the failures are quiet ones and you only catch them by looking. What it doesn't touch is the judgement. Which URLs survive, what becomes a Collection, what the team needs to run on their own in six months. That's still the work, and it's still the part that decides whether the migration was worth doing.

The question to answer before you start isn't which platform is better. It's what specifically is broken now, and whether moving actually fixes it.

I handle WordPress to Webflow migrations for B2B tech companies, usually alongside a rebrand or a repositioning. Have a look at how I approach the work.