Migration

How to Migrate from WordPress to Webflow Without Losing Your Google Rankings

2026-08-28 · 11 min read · Faizyab AhmedBy Faizyab Ahmed

The short version: rankings survive a migration when every old URL points to a matching new one and the metadata comes with it. Rankings die when someone rebuilds the site first and thinks about URLs afterwards. The redirect map is the migration — everything else is design work.

Most people who move off WordPress have already made the decision emotionally. They are tired of plugin conflicts, tired of paying someone to patch a security hole, tired of a page builder that breaks on update. What stops them is a single fear, and it is a reasonable one: we spent three years earning these rankings, and a bad move could wipe them out.

That fear is justified but the risk is manageable. Google has confirmed that permanent 301 redirects pass ranking signals through to the new URL. Sites lose traffic in migrations not because migration is inherently dangerous, but because of a short list of specific, avoidable mistakes. This is the sequence we use, and the mistakes it exists to prevent.

What Actually Kills Rankings In A Migration

Before the process, it is worth naming the failure modes, because every step below exists to prevent one of them:

  • Missing redirects. Old URL returns 404, ranking signal evaporates.
  • Redirects added after launch. Google crawls the new site, hits errors for days, and starts dropping pages before the fix lands.
  • Metadata not carried over. New pages ship with empty or auto-generated titles and descriptions.
  • Redirect chains. Old URL points to a URL that points to another URL. Signal degrades and crawling slows.
  • Forgotten long tail. The homepage and service pages get mapped; four years of blog posts and old category URLs do not.

Notice that four of the five are about URLs, not design. That is the correct proportion of worry.

Step 1: Audit Every URL You Currently Have

Start by producing a complete list of every URL on your WordPress site — not the ones you remember, all of them. This is the foundation of everything that follows, and it is the step people rush.

Pull your list from four sources, because no single one is complete:

  • Your WordPress sitemap (/sitemap.xml or /sitemap_index.xml) — everything the site currently declares.
  • A crawler such as Screaming Frog — finds pages the sitemap missed, plus existing redirects and broken links.
  • Google Search Console → Pages → Indexed. This is what Google actually has, which is the list that genuinely matters.
  • Search Console → Performance, sorted by clicks and impressions over the last 12 months. This tells you which URLs are earning traffic, so you know where to concentrate.

Do not skip the attachment pages, tag archives, category archives, and paginated URLs. They are unglamorous and they are frequently indexed.

Step 2: Build The Redirect Map Before You Build Anything Else

The redirect map is a two-column spreadsheet: old URL, new URL. Every indexed URL gets a row. Build it before design starts, not after.

Building it early changes the project in a useful way — it forces the new site's structure to be decided up front, which is when structural decisions are cheap. Discovering during launch week that your new URL scheme orphans 200 blog posts is an expensive discovery.

Three rules that prevent most of the damage:

  • Map to the closest equivalent page, never to the homepage. Bulk-redirecting everything to / is treated as a soft 404 and throws the ranking signal away.
  • Keep the URL identical wherever you can. The best redirect is the one you did not need. If /services/web-design works, keep it.
  • Redirect once, never twice. If you already have old redirects on WordPress, point the original URL directly at the final destination rather than adding another hop.

A genuinely dead page with no equivalent should return 410 rather than redirect somewhere irrelevant. Sending a discontinued product page to a vaguely related one produces a poor user experience and Google usually treats it as a soft 404 anyway.

Step 3: Export Your Content Properly

Export WordPress posts to CSV, then import that CSV into a Webflow CMS Collection. The default WordPress XML export is awkward to work with; a plugin such as WP All Export gives you a CSV with exactly the fields you want.

Export these columns at minimum: title, slug, publish date, body content, excerpt, featured image URL, categories, and author. Then create a Webflow Collection whose fields mirror them and import.

Two things to check before you start:

  • Your Webflow plan's CMS item limit. Check it under Site settings → CMS. Once you hit the cap, Webflow blocks new items entirely — you cannot add, import, or duplicate until you delete items or upgrade. Finding this out mid-import is a bad afternoon.
  • Images. Featured images usually transfer by URL, but inline images inside post bodies often still point at your old WordPress uploads directory. If you switch hosts and that server goes away, every one of those images breaks. Audit the body HTML before you decommission anything.

This is also the moment for content cleanup you have been postponing. If 60 of your 200 posts get no traffic and no links, migrating them costs effort and dilutes the site. Check the Search Console data from Step 1 and decide deliberately — but if you drop a page, still redirect its URL to the most relevant survivor.

Step 4: Recreate Metadata As You Build, Not Afterwards

Fill in each page's SEO fields at the moment you create the page. Meta title, meta description, Open Graph title, Open Graph description, and the canonical if the page needs a non-default one.

Leaving metadata as a final pass is how pages ship with an empty description or a placeholder title. On a 40-page site with a deadline, "we'll do the SEO fields at the end" reliably means several pages never get them.

Pull the existing values from your Step 1 crawl. If a title is already ranking, port it across as-is. Migration week is not the time to rewrite titles — change one variable at a time, or you will not know what caused a ranking movement.

Step 5: Know What Cannot Come With You

Plugin-dependent functionality does not migrate. It has to be rebuilt, replaced, or dropped. Identify these before you commit, because one of them can change the entire decision:

WordPress featureWhat happens in Webflow
Contact formsRebuild with native Webflow forms; connect to your CRM or email
Yoast / RankMath SEO fieldsRe-enter manually in Webflow page settings
Blog commentsNo native equivalent — use a third-party service or drop them
Membership / gated contentNeeds Webflow's user accounts or an external tool; verify before committing
Complex e-commerce logicOften the genuine reason to stay on WordPress
Booking / scheduling pluginsReplace with an embedded third-party service
Shortcodes inside post contentDo not render — must be stripped or rebuilt before import

That last row catches people out. Shortcodes live inside your exported post body as literal text like [su_button], and they will publish as visible junk unless you clean the CSV first. Search your export for square brackets before importing.

If membership or complex commerce is central to your business, the honest answer may be that Webflow is the wrong move. We would rather tell you that before a project than during one — which is part of why we wrote the honest comparison between the two platforms.

Step 6: Launch In The Right Order

Every redirect must be live at the moment the domain switches — not after. This single detail separates clean migrations from painful ones.

If you point DNS at Webflow and then start adding redirects, Google spends that window crawling a site full of 404s. Every day a ranking page returns 404, it sheds signal, and recovery takes far longer than it would have taken to load the redirects first.

The order that works:

  • Load the full redirect list into Webflow (Site settings → Publishing → 301 redirects; you can import them in bulk rather than typing each one).
  • Publish to the staging .webflow.io domain and test properly — click through navigation, submit every form, view on a phone.
  • Spot-check redirects on staging, especially your top 20 traffic URLs from Search Console.
  • Keep the WordPress site running and untouched. Do not cancel that hosting yet.
  • Switch DNS. Confirm the new site resolves and SSL is valid.
  • Immediately test your top URLs on the live domain and confirm each returns 301 to the right place.

Keep the old WordPress install alive for at least 30 days after launch. It costs one more month of hosting and it is the cheapest insurance in the project — if something was missed, the original is still there to check against.

Step 7: The First Week After Launch

The work is not finished at DNS switch. The first seven days determine how fast you recover.

  • Submit the new sitemap in Search Console immediately, and leave the old sitemap submitted too — it helps Google rediscover old URLs and find their redirects.
  • Request indexing on your homepage and top pages to pull the crawl forward.
  • Watch Search Console → Pages daily for a fortnight. A rise in 404s means a gap in your redirect map. Fix within hours, not weeks.
  • Check Core Web Vitals once real traffic data accumulates.
  • Confirm analytics and conversion tracking fire. Migrations routinely drop a tracking script, and you find out a month later when the reports look wrong.

What To Expect: An Honest Timeline

Expect a temporary dip. It is normal, and it is not evidence that something broke. Google needs to recrawl every URL, follow each redirect, and transfer the signals — that takes weeks, not hours.

PeriodWhat is normal
Week 1–2Visible ranking fluctuation; some pages drop temporarily
Week 3–4Most sites return to roughly their pre-migration baseline
Month 2–3Full settling; site speed gains often push rankings above baseline

If traffic is still meaningfully down after 90 days, that is not a slow recovery — that is a redirect or metadata problem, and it needs an audit rather than more patience.

Is It Worth It?

For a marketing or lead-generation site, usually yes. You trade a platform that needs constant maintenance for one that needs almost none, and the speed improvement tends to help rankings once the dust settles.

For a site whose value sits in plugin functionality — memberships, complex commerce, custom back-end logic — the honest answer is often no. A migration that forces you to rebuild the thing your business actually runs on is not a saving.

The deciding question is not "which platform is better." It is "what does my site actually do, and does the new platform do that natively?" Answer that first, and the migration becomes a project plan instead of a gamble.

If you are weighing this up, our website redesign service covers migrations end to end, including the redirect mapping. It is also worth reading the redesign checklist before you start, and the SEO fundamentals guide if you want to understand what you are protecting.

Thinking about moving off WordPress?

Book a free strategy call and we'll look at your specific situation.

Book a Free Strategy Call
More From The Blog

Related Articles