A migration to Webflow does not have to cost you rankings, and the platform is rarely the reason it does. Traffic is lost through avoidable mistakes: URLs that change without redirects, metadata that never makes the journey, content trimmed for visual tidiness and indexing settings carried over from staging. Plan for those and the move is far less risky than most teams fear.
Key Takeaways
- Rankings are lost through planning failures, not through the choice of Webflow as a platform.
- Benchmark and inventory every URL before anything is rebuilt, because you cannot protect what you have not listed.
- Every old URL that matters needs a permanent redirect to its closest equivalent, never to the homepage.
- Titles, descriptions, headings, canonicals, schema and internal links must carry across or be changed on purpose.
- Launch is the start of the work: monitor indexing, redirects and rankings against your benchmark for weeks afterwards.
Few website projects produce as much anxiety as a migration, and the anxiety is reasonable. A site that spent years building search visibility is about to be rebuilt on a different platform, and the cost of getting it wrong shows up weeks later as a graph that has fallen off a cliff.
What rarely gets said is how predictable the causes are. The same handful of mistakes account for most of the damage, and almost none of them are specific to Webflow. This article sets out the sequence we follow: what to measure first, how to build a redirect map that holds, what has to survive the move, how to launch safely and what to watch afterwards. It uses WordPress as the main example because that is the most common starting point, but the principles apply to any source platform.
Why migrations lose rankings, and why it is usually avoidable
Search engines do not rank platforms. They rank URLs, along with the content, links and signals attached to each one. If every URL keeps its content, its links and its signals, moving to a new platform changes very little. Rankings fall when something attached to a URL breaks in transit.
The usual causes are consistent. URLs change without a redirect, so links and accumulated signals point at pages that no longer exist. Redirects exist but send visitors to an irrelevant destination. Titles, descriptions and headings are rewritten or lost. Content is cut because it looked untidy in the new design. Internal links still point at the old addresses. A setting that kept the staging site out of search results survives into production. And performance quietly gets worse. Every item on that list is a failure of process rather than of platform, which is the good news: process can be fixed in advance.
Benchmark and inventory before you build anything
You cannot protect what you have not listed. Start with a full crawl of the existing site, then compare it against the XML sitemap, the pages that earn impressions and clicks in Search Console, the landing pages in your analytics and, ideally, your backlink data. Each source reveals URLs the others miss, and the pages that matter most are often not the ones anyone remembers.
Then record the baseline you will judge the migration against: organic sessions by landing page, the queries and rankings that drive them, conversions from organic traffic, the number of indexed pages and your current Core Web Vitals. Without this, a drop after launch becomes an argument instead of a diagnosis.
Finally, classify every URL as keep, keep and improve, merge or retire. Pages with traffic, links or conversions are protected. Thin or duplicate pages can be consolidated, but as a deliberate decision with a redirect rather than as an accident of the rebuild. One discipline helps more than any tool: avoid changing everything at once. A new platform, a new URL structure, a new design and new copy delivered in the same week make any ranking change impossible to explain. Where you can, move first and refine afterwards.
Settle the URL structure before design starts
The safest URL is the one that does not change. It needs no redirect, carries no risk and keeps every link pointing exactly where it did. Make keeping existing URLs the default, and require a reason for every exception.
Check early how your current patterns map onto Webflow's collection-based structure, because some do not carry over unchanged. Dated paths, nested category folders and legacy file extensions are the common examples. When a change is unavoidable, decide the new pattern once, document it and map every affected URL, rather than letting the structure drift during the build.
Multilingual sites need separate care. Webflow's documentation states that 301 redirects are relative to the root domain and do not apply to localised slugs or subdirectories, so any change to localised URLs has to be planned on its own.
Build a redirect map that holds
The redirect map is the single most important deliverable in the project. Google's own site move guidance sets out the principles clearly: prepare a mapping from old URLs to new ones, use server-side permanent redirects where possible, avoid sending many old URLs to one irrelevant destination such as the homepage, and test the redirects before and after launch.
Three working rules follow from that. First, map one to one, sending each old URL to its closest equivalent on the new site. Second, keep it to a single hop: a redirect that passes through an intermediate URL wastes crawl effort and invites errors, so collapse chains into one step. Third, where a retired page has no genuine equivalent, a deliberate removal is better than a misleading redirect to something unrelated.
In Webflow, redirects are managed in Site settings under Publishing, then 301 redirects, and Webflow's redirect documentation notes that they require a paid site plan or a workspace on a paid plan. A few details matter on a large project. Paths are relative to the root domain. Redirects run in the order they were added, so conflicting rules need attention. Changes only take effect once the site is published. And when you change a page slug in Page settings, Webflow offers a checkbox to create the redirect automatically, which is worth leaving ticked.
Very large lists need planning. Webflow's developer documentation describes programmatic management of 301 redirects through the Data API, but notes that this requires an Enterprise workspace, so check what your plan allows before building a process around it. Whichever route you take, keep the redirects in place for as long as practical. Google's guidance suggests considering keeping them indefinitely from a user's perspective, and they cost almost nothing to maintain.
Carry across metadata, content and structure
Metadata parity is the easiest thing to promise and the easiest to lose. Export titles, meta descriptions, headings and canonical tags from your crawl and load them into the new build deliberately, using CMS fields for collection pages so they scale. Improve them later, as a separate, measured step. The migration is not the moment to discover that new titles rank differently.
The same applies to body content. Keep the text that earns rankings, even where the new design makes it feel heavy, and fix the design rather than the copy. Carry over image alt text, recreate structured data such as Organisation, Article, FAQPage and BreadcrumbList markup, and apply it honestly to content that is visible on the page.
Internal links deserve more attention than they usually get. After launch, redirects will catch anything that still points at an old address, but every internal link should point directly at the new URL. Relying on redirects for your own navigation adds a hop to every click and hides broken links until they matter. Forms, analytics tags and conversion tracking belong on this checklist too, since losing them makes the post-launch comparison impossible even when rankings hold.
Keep staging out of search, then launch carefully
While the new site is being built, it needs to stay out of search results, and whatever mechanism keeps it there is the most common source of launch-day disasters. Sites go live with indexing still blocked, or with canonical tags pointing at the staging address, and rankings disappear for reasons that take hours to diagnose and moments to fix. Put the launch-day check in writing: indexing directives, robots rules, canonical host, sitemap and redirects, in that order.
On launch, submit the new XML sitemap in Search Console and test the redirects against your full list, using scripts for volume and the URL Inspection Tool for individual pages, both of which Google's guidance recommends. Choose a low-traffic window when the team is available to respond, and avoid launching late in the week. Google also notes that very large sites can be moved one section at a time, which limits the damage if something is wrong.
Use the migration to improve performance, not harm it
A migration is a chance to improve page speed, and also a chance to make it worse. Google's Core Web Vitals guidance recommends that the largest piece of content on a page loads within 2.5 seconds, and slow pages cost both rankings and conversions. Webflow handles hosting and the CDN competently, but it does not compress your images or design your layouts for you.
The most common problem in migrated sites is image weight. Hero images and product screenshots uploaded at full size undo much of the benefit of the move, which is why we cover image compression as a separate discipline. Compress before upload, check the key templates against the Core Web Vitals thresholds and compare them with the baseline you recorded.
After launch, measure against the benchmark
The work does not end at launch. In the first days, crawl the live site and confirm that redirects return the right status, internal links resolve directly, canonical tags are correct and nothing is blocked. Watch the indexing and sitemap reports in Search Console for errors, and check your analytics and server logs for 404s, since each one is a missing redirect you can fix today.
Over the following weeks, compare organic landing pages, rankings for priority terms and conversions with your baseline. Some temporary movement is normal while search engines reprocess the change and does not on its own mean something is broken. A sustained loss on specific pages is different, and it usually has a specific cause. Check missing or irrelevant redirects first, then changed content, then canonical and indexing settings. Because you recorded the baseline, you can say which pages moved and why.
This is also why we prefer working with clients on an ongoing basis. Ergo, a company we currently work with, is an example of the model: strategy, design, new pages and Webflow development as an ongoing partnership, so issues found after launch are fixed in days rather than waiting for a project that no longer exists. You can see more across our client work.
Should you migrate at all?
It is worth asking, because a migration always carries some risk and not every site needs one. If your current site ranks well, converts and can be updated by the people who need to update it, the case for moving may be weaker than it feels. Good reasons include marketing being blocked by engineering for routine changes, growing maintenance and security overhead, or a design ceiling you keep hitting. Weak reasons include the site simply looking dated, which is a web design problem that can be solved on any platform.
If you are still deciding, our earlier pieces on the future of web design and the no-code argument set out where the platform fits and where it does not. When the answer is yes, our WordPress to Webflow service covers the process described above, alongside the SEO services that protect what you have earned.
Final word
A migration to Webflow is a project in preserving things, and the discipline is mostly unglamorous. List every URL, benchmark what you have, keep addresses where you can, map redirects one to one, carry metadata and content across, keep staging out of search and measure the result against what you recorded. Do those things and the platform change becomes a small part of the story, with the rankings you built still attached to the pages that earned them. If you would like a second opinion on a migration you are planning, or a review of one that has already gone wrong, get in touch.
Frequently asked questions
1. Will migrating from WordPress to Webflow affect my Google rankings?
Not necessarily. Moving to Webflow does not automatically cause a ranking loss. The platform offers SEO controls for Webflow websites, but changes to URLs, content, internal links and indexing settings can still affect organic visibility. Preserving high-performing pages, mapping redirects correctly and carrying over important SEO elements reduces the risk. Some temporary ranking fluctuations are normal while Google processes the migration.
2. Should I keep my existing URLs when migrating to Webflow?
Where possible, yes. Keeping existing URLs avoids unnecessary redirects and helps preserve the links and search signals associated with those pages. However, Webflow's CMS structure may require changes to certain URL patterns, particularly nested categories or dated paths. When URLs must change, each important old address should redirect permanently to its closest relevant replacement.
3. What happens if I redirect all my old website pages to the new homepage?
Redirecting unrelated URLs to the homepage can prevent visitors and search engines from reaching the content they expected. It also makes it harder to preserve the relevance and search signals associated with individual pages. Important URLs should have direct 301 redirects to equivalent pages, while content without a suitable replacement should be handled as a deliberate removal rather than redirected somewhere irrelevant.
4. Can I redesign my content and change my SEO titles during a Webflow migration?
You can, but changing the platform, page structure, content and metadata simultaneously makes it much harder to identify the cause of any ranking changes. A safer approach during a B2B website redesign is to preserve the titles, headings and important content of pages that already perform well, then make improvements after the migration has stabilised. This provides a more reliable baseline for measuring the impact of later changes.
5. How can I prevent my new Webflow website from being accidentally blocked by Google?
Before launch, check that any indexing restrictions used on the staging website have been removed from the live site. Review robots.txt rules, noindex directives, canonical URLs and the XML sitemap to ensure they reference the correct production domain. After publishing, use Google Search Console to inspect important pages and confirm that they can be indexed.
6. How long should I monitor SEO performance after migrating to Webflow?
Begin monitoring immediately after launch and continue checking performance over the following weeks. In the first few days, focus on redirects, indexing, broken links, canonical tags and analytics tracking. Then compare organic traffic, priority keyword rankings and conversions against the pre-migration baseline. Temporary fluctuations are expected, but sustained losses affecting specific pages should be investigated rather than attributed automatically to the platform change.
.jpeg)
