Webflow CMS Migration SEO: How to Switch Platforms Without Losing Your Rankings
- Treat a CMS migration as an SEO project from day one. Most traffic drops happen when SEO is handled after launch.
- Build the redirect map before design starts: every indexed URL gets one 301 to its closest equivalent page, with no chains or 404s.
- Export titles, meta descriptions, canonicals and schema, and set them up per template in the new CMS. They don’t transfer automatically.
- For a custom or headless CMS, build the URL and field inventory from a crawl. There’s no export to rely on.
- Check Search Console daily for the first two weeks, then weekly until week eight.
- In our experience, small issues settle within 4-8 weeks. Major redirect or metadata gaps take 3-6 months to recover.
Most CMS migrations lose traffic for one reason: URLs change and nobody owns the redirect map. Map every indexed URL to its new home, carry over titles, metas and schema, and check Search Console daily for two weeks after launch. Done that way, a B2B SaaS site usually stays within a normal 10-15% traffic swing.
The problem is that most migrations are run as a design and development project, and SEO gets handled after launch, or not at all. Below is the process we use at SKROL: what to do before, during and after the build, the redirect and metadata checklists, and how long recovery takes if something goes wrong.
What Are the Biggest SEO Risks of a CMS Migration?
The biggest risk is changed URLs without correct redirects: the ranking signal stays on the old URL and the new page starts from zero. A CMS switch also changes the technical foundation search engines use to crawl, index and rank your site, so several other things can break at the same time:
- URL structure changes that break the link between your existing rankings and your new pages.
- Redirect errors that send crawlers and users to the wrong destination or return a 404.
- Metadata loss where title tags, meta descriptions, and canonical tags don’t carry over correctly.
- Internal linking gaps where the new CMS breaks or removes links that were distributing authority across the old site.
- Indexing delays where search engines take weeks to recrawl and re-evaluate the new site.
- Core Web Vitals regressions where the new platform performs worse than the old one, temporarily lowering rankings.
Any one of these is manageable. Several happening at once - which is common in rushed migrations - can cause a significant, sustained traffic drop.
How Do You Keep Your SEO Rankings During a CMS Migration?
Work in three phases: before, during and after the build. Most of the risk is decided before the first design file is opened, and the work continues for several weeks after launch. CMS migration SEO isn’t a checklist you run once the site is built.
Phase 1 - Pre-Migration
This is where most of the risk is either removed or locked in.
Audit the existing site first:
Before touching the new CMS, you need a full picture of the current site’s SEO state: which pages are indexed, which pages are ranking, which pages are generating organic traffic, and which URLs are receiving inbound links. This becomes your source of truth for everything that follows. Pages generating organic traffic or carrying backlinks cannot be left without a proper redirect.
Define the new URL structure:
If the new CMS changes your URL format - and it usually does - you need to map old URLs to new ones before development starts. Changing URL structure is fine, but it has to be intentional and documented. Every old URL that matters needs a destination.
Document all existing metadata:
Export title tags, meta descriptions, H1s, and canonical tags from the current site. These need to be migrated and adapted, not rewritten from scratch at launch under time pressure.
Identify all high-value pages:
Not every page carries equal SEO weight. Identify the pages driving the most organic traffic, the pages with the most inbound links, and the pages that are actively ranking for commercial keywords. These get the most attention during the migration.
Phase 2 - During the Build
Implement redirects in the new CMS before launch:
This is non-negotiable. Every old URL that is changing needs a 301 redirect pointing to the correct new page. Not a 302. Not a redirect to the homepage. A 301 to the most relevant equivalent page on the new site.
Rebuild metadata from the documented export:
Title tags and meta descriptions should be set in the new CMS before any page goes live. Dynamic metadata templates should be tested across page types to make sure they are generating correctly.
Rebuild internal links:
When the URL structure changes, internal links throughout the site often break. Every reference to an old URL in the content needs to be updated to the new URL - not left to rely on the redirect.
Test crawlability before launch:
Run a crawl of the staging site before it goes live. Look for broken links, missing metadata, pages that are accidentally blocked from indexing, and redirect chains (where a redirect points to another redirect rather than directly to the final destination).
Phase 3 - Post-Launch (The First 30 Days)
Submit the updated sitemap immediately:
Once the new site is live, submit the XML sitemap to Google Search Console. This signals to search engines that the site has changed and prompts a recrawl.
Monitor crawl errors daily for the first two weeks:
Search Console will flag pages that are returning errors. Address 404s and redirect issues as they appear - do not wait for a weekly review.
Watch for traffic drops by page, not just by total:
A drop in total organic traffic can mask which specific pages are affected. Monitor traffic and ranking movement at the page level so you can identify and fix problems before they compound.
Check Core Web Vitals on the new platform:
Performance can regress significantly when moving platforms, particularly from WordPress with a lightweight theme to a richer, component-heavy build. Monitor LCP, CLS, and INP in the first weeks and address any regressions before they settle into stable ranking signals.
The Most Common CMS Migrations and What to Watch For
Different platform combinations carry different levels of risk. The table below covers the most common migrations we handle at SKROL.
The WordPress to Webflow migration is the most common and, handled properly, one of the lower-risk options: WordPress gives you clean export options and Webflow gives you full control over the destination structure. If you’re moving to Webflow, our Webflow migration services cover the redirect map, metadata and launch checks for you.
HubSpot and other CMS migrations tend to be more complex because of how they structure blog and landing page URLs natively.
How Do You Migrate a Custom CMS Without Losing SEO?
A custom or headless CMS has no export plugin and no standard URL format, so you have to build the inventory yourself. That’s where most custom CMS migrations go wrong. Four steps keep it under control.
- Build the URL inventory from four sources. Crawl the live site, pull every URL from the XML sitemap, export the Pages report from Search Console, and export the URLs that have backlinks. Combine and de-duplicate them. Custom sites often have pages only one of these sources finds.
- Map the content fields, not just the pages. List where each piece of SEO data lives today: title, meta description, canonical, H1, author, publish date, schema. On custom builds, some of it is hard-coded in templates. Every field needs a home in the new CMS before you import content.
- Write redirects for the non-standard URLs. Custom CMSs produce URLs with IDs (/post?id=123), uppercase letters, mixed trailing slashes and language folders. Use pattern redirects where the new platform supports them, then test each pattern against real URLs from your inventory.
- Re-crawl the old URL list after launch. Every old URL should return one 301 to a live page. Then check the “Not found (404)” and “Page with redirect” reports in Search Console daily for two weeks.
In practice, step 1 takes the longest and saves the most traffic.
What Does a Redirect Map Look Like, and Why Does It Matter?
A redirect map is a simple document - usually a spreadsheet - that lists every URL on the current site alongside its destination URL on the new site. It sounds straightforward. In practice, it is the single most important deliverable in any CMS migration.
A well-built redirect map has four columns:
- Old URL - the exact current URL, including trailing slashes and query parameters where relevant.
- New URL - the exact destination on the new site.
- Status code - almost always 301 (permanent redirect).
- Priority - high, medium, or low based on whether the page is ranking, receiving traffic, or carrying backlinks.
The priority column matters because large sites can have hundreds or thousands of pages, and not every redirect carries the same risk. Pages with no traffic and no backlinks are low risk: redirect them to the closest relevant page, or let them return a 404 or 410 if nothing fits. Pages that rank for commercial keywords must redirect to a closely equivalent page, or you risk losing that ranking.
The rule of thumb: closest equivalent page first, then the nearest relevant parent page like a category or hub. Avoid mass redirects to the homepage, because Google often treats those as soft 404s and the old page’s value is lost anyway. And keep every redirect to one hop: chains slow down crawling and weaken the signal.
The Metadata Migration Checklist
Metadata is one of the most frequently dropped elements in a CMS migration, usually because the team assumes the new CMS will pick it up automatically or that it can be written after launch. Neither approach works.
Before launch, every page that was indexed and receiving traffic should have:
- Title tag: migrated and adapted for the new URL context.
- Meta description: migrated and reviewed; descriptions that referenced the old brand positioning or old CTAs should be updated.
- H1: confirmed as present and unique on every page.
- Canonical tag: set correctly, pointing to the page’s own URL unless it is a duplicate.
- Open Graph tags: title, description, and image set for social sharing.
- Schema markup: rebuilt in the new CMS; schema from a WordPress plugin does not carry over automatically.
For sites using Webflow as the destination, CMS collections allow dynamic metadata to be templated across page types - which significantly reduces the manual workload on larger sites. The key is setting up the field model correctly before populating content, not after.
How Long Does It Take to Recover If Something Goes Wrong?
In our experience, it depends on two things: how big the issues are, and how fast you fix them.
Minor issues (a handful of missing redirects, a few metadata gaps) typically stabilize within four to eight weeks as Google recrawls and re-evaluates the affected pages. Rankings may dip briefly but recover without significant long-term impact if the issues are caught and fixed quickly.
Major issues (large numbers of broken redirects, significant URL structure changes without redirect mapping, substantial metadata loss across the site) can result in ranking drops that take three to six months to recover from - sometimes longer for highly competitive keywords where the site had built authority over years.
The pattern is consistent: teams that start the SEO work before the build starts recover faster, lose less, and often end up with better performance than they had on the old platform within three months. Teams that treat SEO as a post-launch task spend those same three months recovering rather than improving.
If traffic already dropped, check in this order: redirects (404s, chains, homepage redirects), then indexing in Search Console, then metadata on the pages that lost the most traffic. In our experience, broken or missing redirects explain most drops.
The SEO Handover: What to Document Before You Switch Off the Old Site
One final step that is consistently overlooked: the SEO handover document. Before the old site is taken down or redirected, save a full record of its state.
This should include:
- A full crawl export (all URLs, status codes, metadata).
- A Google Search Console data export (impressions, clicks, rankings by page for the last 90 days).
- A backlink export (all inbound links pointing to the old site, by destination URL).
- A list of all pages currently indexed in Google.
- Screenshots or exports of any structured data or schema in use.
This documentation serves two purposes. First, it gives you a baseline to compare against after launch - so you can identify ranking drops at the page level and trace them back to a specific cause. Second, if something goes wrong post-launch and the old CMS is no longer accessible, this document gives you the information needed to fix it.
What Should Your SEO Look Like 30-60 Days After Launch?
If the migration went well, you should see three things within the first 30 to 60 days:
Traffic continuity:
Organic traffic holds within a normal variance band (10-15%) across the first month. Some fluctuation is normal as Google recrawls and reindexes. A significant, sustained drop is a signal that something needs fixing.
Rankings preserved on priority pages:
Pages that were ranking for commercial keywords before the migration should still be ranking after it. The rankings may shift slightly while Google re-evaluates the new pages, but they should return to pre-migration levels within four to eight weeks.
A cleaner technical foundation:
The new CMS should give you more control over metadata, cleaner code and faster pages than the old one. If the migration went well, your technical SEO signals (crawl errors, Core Web Vitals, indexation) should be better than before within the first quarter.
The goal is not to survive the migration. It’s to come out of it with a better site - one that is easier to grow, easier to manage, and better positioned for organic performance over the next two to three years.
Frequently Asked Questions
For a typical B2B SaaS marketing site, a well-managed CMS migration takes four to eight weeks from kickoff to launch. That timeline includes the SEO audit, redirect mapping, metadata migration, build, and pre-launch testing. Rushing this timeline is the single most common cause of post-launch ranking drops - the SEO work cannot be compressed without increasing risk.
Not necessarily. A properly managed migration with a full redirect map, preserved metadata, and clean technical setup typically holds rankings within a normal variance. Some fluctuation is expected as Google recrawls the new site, but sustained ranking drops are a symptom of migration issues - not an inevitable outcome of switching platforms.
Redirect mapping. More ranking losses in CMS migrations are caused by missing or incorrect redirects than by any other single issue. If search engines and users hit a 404 or land on the wrong page, the ranking signal built on the old URL is lost. Get the redirect map right before launch and you eliminate the biggest risk.
No, as long as the migration is handled correctly. Webflow gives teams more direct control over technical SEO than most plugin-dependent WordPress setups, and its clean HTML output is easy for search engines to read. The platform change itself isn’t the risk. The risk is how the migration is executed.
Submit your XML sitemap to Google Search Console, monitor crawl errors daily for the first two weeks, check that all high-priority redirects are working correctly, verify that metadata is appearing as expected across page types, and run a Core Web Vitals check. Start all five on launch day. That catches most post-launch issues before they affect rankings.
