WordPress to Webflow migration without losing your rankings

The migration horror story is always the same. New site launches, everyone is pleased with it, and three weeks later organic traffic is down forty per cent. Somebody says “Webflow tanked our SEO.”

Webflow did not tank your SEO. Almost every time, the site launched with a URL structure nobody mapped, redirects nobody wrote, and page titles that were never carried across. The platform is rarely the problem. The migration is.

Here is the part of the project that actually protects the traffic — the work that happens before and around the build rather than inside it.

Start with an inventory, not a design

Before anything is designed, you need three exports. They take an afternoon.

Every URL the old site serves. Crawl it — Screaming Frog’s free tier handles 500 URLs, which covers most SaaS marketing sites. What you want is the full list, including the pages nobody remembers: the old pricing page from two positionings ago, the /thank-you/ variants, the author archives, the paginated blog pages.

Search Console performance, last 16 months, exported by page. Sort by clicks. This is the list that matters. Typically twenty to forty URLs carry almost all of the organic traffic, and those are the ones where a mistake is expensive. Everything else can be handled with a rule.

Your current titles and meta descriptions. The crawl gives you these. They are the thing most commonly lost in a migration, because they lived in a WordPress plugin’s database table rather than in the page content, and nothing about exporting content brings them along.

If you skip this step, you will discover what you had only by watching it disappear.

Map URLs one to one, and be honest where you cannot

Build a two-column sheet: old URL, new URL. Every URL from the crawl gets a row. There is no “we will figure that one out later” — later is after launch, when it is a 404 in someone’s index.

Most rows are identical on both sides, and that is the goal. The cheapest migration is the one where URLs do not change at all. Resist the urge to tidy the structure while you are already changing platforms. If both must happen, do them as two separate launches, weeks apart, so that when something moves you know which change moved it.

Where Webflow will force your hand: CMS items live under their collection’s path. A blog post is /blog/post-slug/, a case study /case-studies/study-slug/, and the collection slug applies to every item in it. If your WordPress blog served posts from the root — /my-post/ rather than /blog/my-post/, which was the default for years — every post URL changes. That is not a reason to avoid Webflow; it is a reason to have the redirect list ready before launch rather than after.

Two rules for the mapping itself:

• Never point a redirect at the homepage because you cannot find a match. Google reads a mass redirect to the root as a soft 404 and drops the page rather than passing anything to it. If a page genuinely has no successor, let it 404 honestly, or map it to the closest category page.
• Never chain. Old URL → interim URL → final URL loses signal at every hop and slows the crawl. If the old site already carried redirects from a previous migration, flatten them: point the oldest URL directly at the final destination.

The redirects, and the one nobody remembers

Webflow’s 301 redirects handle the path-level rules, including wildcard patterns for whole sections. Write them from the sheet, not from memory, and test each one against the live staging site before launch rather than after.

The rule that gets forgotten is the host. Pick one canonical hostname — example.com or www.example.com — and make the other one 301 to it, permanently. Sites carry both for years without noticing, splitting their own signals between two versions of every page, until someone finally consolidates and it looks like a ranking change.

We learned this one on our own site. When we consolidated our host, the weekly performance probe kept measuring the old one — so every measurement quietly included a redirect hop, and the numbers looked worse than the site was. The redirect was right; the thing measuring it was not. Whatever you use to watch performance after a migration, point it at the canonical host, or you will spend a month optimising a hop.

What has to carry over besides the content

Content is the easy part. These are the things that arrive at launch only if someone puts them there:

• Titles and meta descriptions, per page, from the crawl export. Not regenerated, not “improved” — carried across as they are. Improve them a month later, one at a time, so you can see what each change did.
• Canonical tags, self-referencing on every page, on the canonical host. Webflow handles this by default; verify rather than assume, especially on CMS templates.
• Structured data. Organization, WebSite, BreadcrumbList, Article on blog posts, FAQPage where you have real FAQ blocks. If the old site had it via a plugin, it does not migrate itself.
• Image alt text. It rarely survives a CMS export. It is also the thing your accessibility audit will find later, at a worse time.
• robots.txt and the XML sitemap, pointing at the canonical host. Then resubmit in Search Console on launch day.
• Analytics, with consent handling intact. A migration is the most common moment for a tag to go missing or for a consent banner to stop gating it correctly. Verify events fire — in the real property, not just in the tag debugger.

Launch day, in order

1. Publish with the redirects already live, not queued behind a follow-up task.
2. Spot-check the top twenty URLs from the Search Console export. Every one should land on its intended destination with a single 301, no chain.
3. Confirm the sitemap resolves and lists the new URLs; resubmit it in Search Console.
4. Request indexing for the ten highest-value pages. It costs a few minutes and shortens the recrawl.
5. Note the launch date somewhere you will find it in six weeks. Every unexplained chart needs this date on it.

The two weeks after

Expect a dip. A small one, for one to three weeks, while Google recrawls and reconciles. That is normal and it recovers.

What is not normal, and means something is wrong:

• Impressions falling on the pages that were your top performers, rather than across the tail.
• Coverage reports filling with 404s or “Redirect error” — that is the chain problem, or a mapping row nobody wrote.
• Two versions of the same page indexed — the host redirect did not ship, or a canonical points at the wrong one.

Check Search Console weekly for the first month, not daily. Daily numbers during a recrawl are noise, and reacting to noise is how a fine migration turns into three more changes that genuinely do break something.

One honest note

We build SaaS marketing sites in Webflow, and we do not run our own site on it. This one is a static build, because it is maintained by the two people who also wrote it, and that trade-off is the right one for us and the wrong one for most of our clients.

The thing that makes Webflow worth it for a SaaS team is that marketing can ship a landing page on a Tuesday without a deploy or a developer. If your team has that need, that is the whole argument, and it outweighs everything a developer might prefer. If your site is maintained entirely by engineers who would rather write code, be honest about that before you migrate — the platform is not the point, the person who has to change the page on a Tuesday is.

---

Migrating and want the URL mapping checked before you launch? Send the site over — we will record a 15-minute Loom on what would break. Free, no follow-up. If you want the whole thing run for you, that is the Webflow build: four weeks, published price, migration included. The handoff handbook covers what happens on the design side.