Migrating From WordPress to Webflow Without Losing SEO: The Checklist We Use

No, migrating to Webflow doesn't cost you your SEO. What breaks it is migrating with no measurement, no URL map and no post-launch control.

The pattern shows up again and again: a CMO walks in with a six-year-old WordPress, 400 indexed URLs and a blog that generates leads. Nobody wants to be the person attached to the redesign that sank organic traffic. Marketing carries enough pressure without adding that ghost.

I sell migrations to Webflow, so I have a conflict of interest. Better to say it up front. My job isn't to talk you into migrating at any price, it's to show you what we check before touching a single URL. If the process isn't there, the math is incomplete.

Why does traffic fall when a company changes platforms?

Traffic almost always falls for three fairly concrete reasons: the URLs changed and nobody redirected them, the redesign cut the copy that was ranking, or nobody measured the starting point. The platform gets blamed because it was standing near the fire.

The myth that Webflow loses SEO comes from comparing two different things. On one side you have an old WordPress, with years of content, internal links and indexed pages. On the other, a new Webflow with fewer sections and shorter text. The platform wasn't the only thing that changed. The site changed.

That's where the reading breaks.

The problem doesn't blow up on launch day either. Google needs to recrawl, process redirects and reindex. The drop can show up three or four weeks later, when the team is already celebrating the new design and nobody is looking at Search Console with much enthusiasm.

That's why we work it as five fronts. A redirect spreadsheet thrown together at the last minute doesn't cover it.

Do you know what traffic you have today, before touching anything?

If you don't have a picture of the before, you can't prove what dropped, when it dropped or which pages took the hit. Measuring first turns a scare into a diagnosis. Without it, every meeting ends in opinions, loose screenshots and someone saying "I feel like it was doing better before".

The first step is looking at current keywords and rankings. Not the searches you'd like to win, the ones actually bringing traffic today. Then you pull a Search Console and GA4 snapshot covering the last 12 to 16 months. Twelve months minimum, because you need the full seasonality.

Comparing against last month means little if your business drops every January.

Out of that comes the most important piece: the complete export of indexed URLs plus a crawl of the old site. That list is the raw material for everything that follows. If a URL that brings traffic is missing, then a redirect is missing, and then a decent explanation is missing.

Monitoring has to continue during and after the migration. A single report at 30 days is no use, because by then the damage has settled in. At the end you get a pre and post migration report. That document brings the argument back down to data.

And what if the drop isn't yours?

Sometimes you lost nothing. Sometimes a competitor went up. Without competitive context, any movement in the chart looks like the migration's fault, and marketing ends up arguing with a shadow. This isn't hypothetical: it happens whenever you read your Search Console without looking at what changed around you.

Here we identify who competes for your searches and audit their visibility. Then we look at content and gaps: which pages they have that you don't. We also run an authority benchmark, because fighting a keyword against a weak blog is not the same as fighting it against a heavy domain.

A migration opens an unusual window. You can rewrite architecture and content with less political cost than usual. While the site is being rebuilt from scratch, nobody is surprised by moving sections or cleaning up categories. Six months later, every change needs three meetings.

Using that window to leave everything the same but prettier gets expensive.

Will Google find the pages that matter to you?

Google finds first whatever the architecture puts within reach. If a key page ends up buried three clicks from the home, it can take weeks to index. The new structure isn't decoration. It decides what enters the index fast and what sits waiting.

What breaks most in a migration are the internal links in the old blog. You have six years of articles pointing at each other, with URLs that may no longer exist. Nobody reviews them because they live inside the body copy. A lot of SEO gets left there, bit by bit.

Then comes the URL structure. The rule is to keep them, unless there's a strong reason to change them. In Webflow, watch the collection prefix, because CMS collections add their own segment to the URL. That's how your whole blog can change without you deciding it.

That detail looks small until you export 400 different URLs.

Structured data also changes hands. In WordPress a plugin usually handled it. In Webflow you handle it, with embeds. It's more work and also more control. It helps your pages come out better prepared for crawlers, including the ones from language models that now decide who gets cited.

Two technical checks are left. The new XML sitemap goes into Search Console only once the redirects are live. Not before. And robots.txt gets reviewed on launch day, because the classic mistake that ruins migrations is publishing the staging noindex to production.

The redesign eats the copy, and that's where relevance goes

The silent damage shows up when the new page looks flawless but goes from 900 words to 300. Google no longer finds the same signals. The design got better, sure, but the content that justified the ranking disappeared without anyone calling it by its name.

Meta titles and descriptions get exported from the old site and migrated. They don't get rewritten by eye the night before launch. There are hundreds of fields, and many carry years of adjustments. Changing them all at once mixes too many variables.

Heading structure gets reviewed page by page. One H1 per page, only one. In the Webflow CMS this matters more than it looks, because the H1 comes from the item's name field, not from the body of the article. Put another H1 in the body and you end up with two.

And then someone asks why it dropped.

HTML5 semantics isn't an aesthetic detail either. It's what crawlers read, including the systems that process content for AI-generated answers. If the markup is sloppy, the content can be well written and badly understood.

House rule: if you're going to cut content, do it in a later iteration. Not at launch. One variable at a time. If you change platform and content at the same time, and traffic drops, you won't know what broke what.

The step where you really do lose everything

The point where everything gets lost is the badly done redirect. 301 redirects one to one, never everything to the home. This is the most delicate of the five fronts, because without a complete map the ranking history of those URLs gets cut off in one go.

The URL audit is built from three sources: the crawl of the old site, the URLs that show up in Search Console and the URLs with backlinks pointing at them. All three. If you use only one, fine, do it halfway, but don't call it an audit.

Then comes the one-to-one mapping. Every old URL has to go to its closest equivalent. Sending everything to the home is throwing authority in the bin. It's also what many rushed migrations do when nobody wants to look at a long spreadsheet.

Webflow handles redirects well, but it has its own rules worth knowing beforehand:

• It supports wildcards with capture groups, using the (.*) syntax, which lets you redirect a whole section with a single rule.
• They can be imported by CSV, so the map gets built in a spreadsheet and uploaded.
• Rules run in the order you added them. Older ones are tried first, so specific rules go before broad ones.
• Webflow doesn't impose a hard limit on redirects, but recommends staying under 1,000 rules as best practice.
• Redirects don't apply to localized slugs, so if you have a secondary locale you have to duplicate the rules.

That recommendation of staying under 1,000 rules is exactly why wildcards aren't optional on a large site. If you have 3,000 old URLs and map them one by one, you don't fit inside that best practice.

Google recommends keeping redirects live for at least a year. From the user's side, it's usually worth keeping them forever. That year is the minimum for Google to finish transferring ranking signals to the new URLs.

Once the site is published, you run a post-migration crawl to catch the 404s that survived. One always survives. The point is finding it before your traffic does.

What's normal to see the week after publishing, and what isn't?

Fluctuation is normal. What you don't want to see is a sustained drop. Google notes that for medium-sized sites it can take a few weeks or more before it starts showing the new URLs, so the chart can move strangely for a while.

Day one you run a full crawl of the new site. You check 404s, confirm the sitemap was submitted and verify that robots.txt isn't blocking anything. It's an unglamorous morning. It's also the morning that saves you several weeks of explaining yourself.

During the first week you look at the coverage report in Search Console and compare old indexed URLs against new ones. What you expect is the old ones going down and the new ones going up, in that order. If you only look at aggregate traffic, you miss the film.

At one month you compare against the baseline from the first front. Against the baseline, not against last month. If your demand is seasonal, a month-over-month comparison can lie to you with remarkable confidence.

The alarm goes off when three things show up together: a sustained drop on specific pages, 404s still receiving traffic, and mass deindexing. One of those three during the first week isn't always an emergency.

What you shouldn't do is revert the migration five days in because the chart went down. Reverting stacks a second URL change on top of the first. It doubles the problem.

The complete checklist, for you to copy

Here it is all together, ordered by moment rather than by front. That's how it runs in real life, not in a tidy presentation.

Before touching the design

• Export 12 to 16 months of Search Console and GA4 (Positioning Analysis).
• Pull the complete list of indexed URLs and crawl the old site (Positioning Analysis).
• Identify the keywords bringing you real traffic today (Positioning Analysis).
• Export every current meta title and description (Semantic Optimization).
• Audit the competitors ranking for your terms (Competitor Analysis).
• Define the new URL structure and decide explicitly what stays (Architecture & Indexing).
• Build the one-to-one redirect map in a spreadsheet (Redirect Mapping).

Launch week

• Load the 301 redirects in Webflow, specific rules first and wildcards after (Redirect Mapping).
• Duplicate the rules for secondary locales if you have them (Redirect Mapping).
• Check that every page has one H1 and that the metas were migrated (Semantic Optimization).
• Review the internal links in the old content (Architecture & Indexing).
• Load the structured data into the templates (Architecture & Indexing).
• Remove the staging noindex and check robots.txt in production (Architecture & Indexing).
• Submit the new sitemap in Search Console, with the redirects already live (Architecture & Indexing).

After publishing

• Day 1: full crawl of the new site and a 404 review (Redirect Mapping).
• Week 1: coverage report, old indexed URLs against new ones (Positioning Analysis).
• Month 1: comparison against the baseline, not against last month (Positioning Analysis).
• Keep the redirects live for at least a year (Redirect Mapping).
• Pre and post migration report with the final diagnosis (Positioning Analysis).

What everyone asks before hitting publish

Those are the big pieces. The specific doubts always come next, the ones that show up in the week before launch. Here are the ones we hear every time.

Migrating isn't the risk, improvising is

The problem isn't Webflow. The problem is migrating with no process. If someone tells you the migration is risky because of the platform, they're looking at the comfortable part of the problem, not the part you can audit beforehand.

There's a quick test. Ask for the redirect map before you approve the budget. Not after. If they can't show it to you, or they tell you that gets sorted at the end, you already know how the story ends.

That's the difference between migrating a site and playing roulette with your SEO. Better Call Ander.Agency.