A Webflow to git-based blog migration playbook: why CMS collections don't map cleanly to Markdown, how to protect your rankings, and what you gain in git.
Webflow's own pricing got more generous in 2026. The May update merged its CMS and Business Site plans into one Premium tier at $25 a month billed yearly, with 20,000 CMS items and 40 collections, up from the old CMS plan's 2,000 items and 20 collections. That's the opposite of the usual migration story. Teams don't leave HubSpot or Notion for git because those platforms got worse, they leave because the platform never gave them enough room in the first place. Teams leave Webflow for a different reason: they've outgrown its designer-first content model, or they want their blog to live in the same repo and review process as the rest of their product, not because Webflow got expensive.
That difference changes where the migration risk actually sits. On HubSpot or Notion, most of the risk lived in features the platform never had: schema markup, per-post meta control, a real sitemap. On Webflow, most of that already exists. The risk here concentrates almost entirely in two structural facts: Webflow's CMS export doesn't preserve rich text or reference-field data cleanly, and every Collection item is locked to one fixed URL pattern that a new site's slug structure has to be mapped against, item by item, before you touch a redirect.
This post covers why Webflow's own export format works against you, the redirect and slug-mapping checklist that keeps your rankings intact, and what you get back once your blog is Markdown files in a git repo instead of Collection items in Webflow's database. It's the same discipline we cover for a HubSpot to git migration, a Notion to git migration, and a WordPress to Astro migration: the platform changes, the discipline doesn't. Webflow just fails in a more structural way than any of the three.
Webflow calls its blog a Collection, and a Collection is a database table, not a folder of files. That distinction is exactly what breaks when you try to export it.
Ask Webflow to export a Collection and you get a CSV, and a CSV is where the trouble starts. A guide to migrating Webflow CMS content is specific about what actually comes out: "Your carefully formatted blog posts, with headers, bold text, lists, embedded images, come out as plain text or raw HTML blobs in a single CSV column." A Rich Text field with months of formatting choices in it becomes one cell you have to parse by hand or with a script.
Reference fields fare worse. A blog post that links out to a category, an author, or a set of tags through Webflow's multi-reference field type exports as "comma-separated IDs that mean nothing outside Webflow," per the same guide. Those IDs map to other Collection items inside Webflow's database; outside it, they're just numbers. You have to rebuild the join yourself, matching each ID back to the author or category it pointed to before the export ran.
Collection page templates, the layout that actually renders each post, a title, a hero image, an author byline, related posts, don't export at all. The guide's phrasing is blunt: they "don't export at all. You're rebuilding those from scratch." Any conditional visibility rule built into the template, show this block only if a field is set, hide the author bio on unattributed posts, is gone too and has to be recreated as real code logic in the new build.
None of this is a Webflow bug. It's what happens when a visual, database-backed CMS meets a CSV, a plain-text format with no concept of nested formatting, IDs, or template logic. It's also why there's no clean workaround in the other direction: developers on Webflow's own community forum report that importing Markdown or HTML into a Rich Text field through the CMS API doesn't preserve formatting either, and pasting Markdown directly into the field doesn't render correctly, because Webflow has no native Markdown import mode for the CMS API. There's no clean round trip in either direction. Budget real time for a human review pass over every post, not a script you run once and trust.
Every Webflow Collection item publishes at one fixed pattern, /{collection-url}/{item-slug}, and category or folder data doesn't become part of that path unless you've explicitly set up a CMS Folder. Before you decide on a new site's URL structure, know exactly what Webflow's current URLs look like, because that's what every redirect has to map from.
A breakdown of Webflow's URL structure states the pattern directly: "Every CMS page URL in Webflow follows this formula: /{collection-url}/{item-slug}." A category Reference field can filter, sort, and display items by category on a page, but "that category cannot become part of the URL path" by default. The guide's own example makes it concrete: a Projects Collection with items categorized as Web Design, SEO, and Branding still publishes every project at /projects/acme-redesign, never at /web-design/acme-redesign.
We checked this against a live example instead of taking it on faith: Webflow's own blog runs the pattern on itself. A migration case study, webflow.com/blog/wordpress-migration, and a portfolio-advice post, webflow.com/blog/ux-designer-portfolio, sit in two different content categories and still publish at the same flat /blog/{slug} address, with no /case-study/ or /portfolio/ segment in either URL. If the company that built the platform doesn't route its own blog by category, don't assume yours does either. Check your live URLs before you plan a redirect map around a folder structure you're only assuming exists.
Webflow closed part of that gap with CMS Folders, added on April 27, 2023, as Webflow's own changelog confirms. A Collection's template page can take a parent folder, which lets you nest static path segments in front of the item slug, for example site.com/content/blog/post-name, without routing through anything outside Webflow. If your Webflow blog already uses folders, your current URLs are more flexible than the base pattern suggests, and you should map from what you actually have, not the flat default.
Without folders, or if you're trying to reshape a flat Collection into a category-based path, the only two ways to do it are flattening your new site to the same /collection/slug pattern Webflow used and pointing wildcard 301s at it, or routing through an external reverse proxy, Cloudflare Workers is the most common choice, that rewrites the URL the browser shows. Decide this before you write a single redirect. Changing the target URL structure after you've already mapped half your Collection means remapping all of it.
Every image in your CSV export is a Webflow CDN link, and that link has an expiration date you won't see coming. The same migration guide is direct about it: "The CSV contains Webflow CDN URLs for your images. Those URLs work today, but they won't work forever." The fix is mechanical and has to happen in the right order: batch-download every image the export references while the Webflow plan is still active, and do it before you cancel, not after, because you need the live site to reach the CDN URLs at all.
Skip this step and you find out weeks later, when a hero image on a post that ranked well for two years quietly turns into a broken link. Re-hosting every image is cheap. Finding out it broke after Webflow access is already gone isn't.
Webflow's rich text and template problems are mechanical, tedious but solvable with a script and a review pass. The part of a Webflow migration that actually loses rankings is different: an old Collection item slug with no redirect to its new address.
Pull every URL Google has actually indexed from Search Console's Coverage report, not the list of items in your Webflow Collection panel. A post you unpublished or a category page you deleted eight months ago can still be indexed and still sending a trickle of traffic through an old backlink; if it disappears with no redirect, that traffic and the link equity behind it disappear with it.
Trusting your own URL list instead of a crawl is the single biggest way teams undercount this work. The clearest documented case of that undercount is actually from the reverse move, an agency onboarding a client onto Webflow: on one 180-page project, a full site crawl surfaced 340 URLs needing redirects, versus only 94 in the client's original sitemap and URL export, well over three times as many as the sitemap alone turned up. That's 246 URLs carrying real backlink equity that would have gone dark if the team had trusted the sitemap alone. The direction of the move doesn't change why that gap opens up, a sitemap only lists what the current CMS panel knows about, not what Google has actually indexed from years of unpublished posts and deleted category pages, and that gap exists just as much leaving Webflow as it does arriving on it. Run a real crawl, not just an export, before you finalize your redirect map.
Because Webflow's own URL pattern is fixed and every path already carries this exact shape, /collection-url/item-slug, decide your new site's URL structure before you start mapping, not while you're halfway through. Every entry in your spreadsheet, old URL to new URL to redirect type, only has to get written once if the target structure is locked in first.
The redirect type is what carries the ranking signal, and Google is explicit about the distinction. Google's own documentation states plainly: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." That's true for a 301 or a 308. For a 302, 303, or 307, "the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical," because those codes tell Google the move might not be permanent. A Webflow-to-git migration is permanent. Anything short of a 301 sends the wrong signal at the exact moment you need the right one.
Webflow's own redirect tool lives in Site Settings and requires a paid Site or Workspace plan to use at all. It runs redirects in the order you added them, oldest first, and Webflow recommends a maximum of 1,000 redirects as best practice, even though there's no hard technical cap. The gotcha worth knowing before you touch it: uploading a CSV of redirects through Webflow's bulk-import tool replaces every existing redirect on the site rather than adding to them. If you already have redirects live from a prior cleanup and you import a fresh migration map without first merging the two lists, you silently delete the old ones.
None of that matters once you've left Webflow's hosting anyway, since the redirect layer has to live on your new host or CDN from day one. Set it up there, test it before cutover, and keep it live once it's up. Google's site-move guidance is specific: "Keep the redirects for as long as possible, generally at least 1 year," because that's the window Google needs to recrawl the backlinks other sites still have pointing at your old Webflow URLs and reassign that signal to the new ones. Expect a crawl spike too. Google says it will "temporarily crawl your new site more heavily than usual" right after a move, since redirected requests from the old URLs stack on top of normal crawl demand.
Here's the part that should be reassuring: a 10 to 15% dip in organic traffic during the first four weeks after a migration is normal, and most sites return to their pre-migration ranking baseline within 60 to 90 days when the move is handled cleanly. That figure comes from the same webnomads source as the crawl-undercount stat above, again a case study about onboarding onto Webflow rather than leaving it, but the mechanism, a temporary dip followed by recovery once redirects and crawl signals settle, is the same regardless of which direction the platform swap runs. The platform swap itself, Webflow to a static git-based build, isn't what costs you rankings. An unmapped slug is.
Timeline scales with how much Collection data you're carrying, and the clearest public benchmark for that scaling is, again, documented in the reverse direction. Migration timelines from an agency that runs Webflow onboardings run 2 to 4 weeks for a small site under 30 pages with no CMS, 4 to 6 weeks for 30 to 100 pages with a basic blog or CMS, 6 to 10 weeks for 100 to 250 pages with a complex CMS, and 10 to 16 weeks for 250-plus pages with multiple CMS collections. Those bands describe projects moving content onto Webflow, not off it, but the variable that sets the pace, page count and CMS complexity, not which platform sits on which end, is the same variable that sets your timeline leaving it. Treat the bands as a scale reference rather than a quote for your project: a CMS-heavy Webflow blog with real Collection depth, categories, authors, related-post logic, sits at the higher end of that range, and most of the time goes to the export and slug-mapping work above, not the rebuild.
Budget the schedule accordingly, and don't compress the mapping step to hit a launch date. The rebuild is mechanical work a developer can move through quickly. The slug map is the one part of the project that determines whether your rankings survive it.
The tradeoff here is real, and it's worth naming plainly instead of pretending the move is a pure upgrade.
Webflow's Designer is built for exactly what a marketer wants: drag a block, style it visually, publish from a browser with no engineering involved. A git-based blog trades that canvas for every post becoming a Markdown file on a branch, reviewed as a diff, merged the same way a code change ships. For a content team that has never touched git, that's a genuine cost, not a footnote, and it's the honest reason some teams stay on Webflow even after they've outgrown its Collection model.
What you get in exchange is a publishing pipeline that behaves like the rest of your product instead of a separate visual tool nobody on the engineering side ever opens. Nothing publishes without a merged pull request, a meaningfully different failure mode than a Webflow Collection item going live the moment someone clicks publish in the Designer. If your team is weighing that tradeoff for a specific Webflow setup, talk to the founder rather than guessing from a blog post.
A static build generates a unique meta title and description per post automatically, writes an XML sitemap from your content directory with no manual step, and lets you add Article and BreadcrumbList schema to every page as code, not a per-item field filled in by hand in Webflow's CMS panel. Our schema markup for AI Overviews post covers which structured data types are actually worth shipping in 2026 versus which are vendor invention.
You can also gate every merge on checks Webflow's Designer has no equivalent for: broken links, valid canonicals, valid JSON-LD, Core Web Vitals budgets. Our GitHub Actions SEO checks post walks through four automated jobs that fail a build before a bad page ever reaches production, a stronger guarantee than a content editor remembering to fill in a meta description field before hitting publish.
If you're weighing a fully static rebuild against a headless CMS sitting in front of your new frontend, instead of going all the way to flat Markdown files, our headless CMS vs git-based blog post covers the sync-layer risk a headless setup can introduce that a plain static build never has.
Work through this before you export a single Collection:
Once your Collections are Markdown files in a repo, the publishing question changes from "who has Webflow Designer access" to "what does our git workflow look like for content." A new post is a branch and a file. Review happens as PR comments instead of a Webflow revision history nobody checks. A merge to main triggers the same build and deploy pipeline your product already uses, no separate Webflow login and no separate mental model for the content team's tools versus engineering's.
That handoff is also where a repo-native writing tool fits, instead of a Webflow CMS plugin or an automation pushing rows into a database you no longer have. A git-based AI blog writer reads your repo's conventions, drafts a post as a Markdown file on a branch, and opens a pull request the same way a human contributor would, so nothing auto-publishes and your existing review process still gates every post. If your migration is still ahead of you and you're building your keyword strategy from scratch rather than porting an existing Webflow blog, our guide to SEO for SaaS covers picking winnable keywords and building topic clusters before you're locked into any platform's constraints, and Lyra's plans start at $39 a month if you want to see what running that workflow costs once you're there.
Once your Webflow migration lands on git, Lyra can take over the writing from there, reading your repo's conventions and opening a pull request for every new post, the same review gate you already use for code.
FAQ
Not if you map every indexed URL to its new address and redirect it with a permanent 301 before you cancel Webflow. Google's own site-move guidance says ranking fluctuation during a migration is expected, and most sites return to their pre-migration traffic baseline within 60 to 90 days. For Webflow specifically, the risk isn't the platform swap, it's an unmapped Collection item slug.
Because Webflow's CSV export was built to move data, not formatted content. Rich text fields export as plain text or a raw HTML blob in a single column, multi-reference fields like categories, authors, and tags export as comma-separated IDs that mean nothing outside Webflow, and Collection page templates, the layouts that actually render each post, don't export at all.
Only if your new site keeps Webflow's fixed /collection-url/item-slug pattern, which most git-based blogs don't use by default. Webflow's own CMS Folders feature, added in 2023, lets you nest static path segments before the slug without an external proxy, but if you're leaving Webflow entirely, you're choosing a new URL shape and mapping every old one to it with a permanent redirect.
301, not 302, every time. Google's documentation states that for a 301 or 308, the indexing pipeline uses the redirect as a signal that the target should be canonical; for a 302, 303, or 307 it doesn't, because those codes signal a temporary move. A Webflow migration off the platform is permanent, so anything short of a 301 sends the wrong signal.
They stop resolving. Webflow's CDN asset URLs work while your plan is active, but they go dead once you cancel or decommission the site, so every image referenced in your CSV export has to be batch-downloaded and re-hosted before cancellation, not after.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
Content marketing for PLG SaaS needs its own playbook: which post types close a self-serve signup without a demo call, and how to measure if they did.
Developer blog conversion rate optimization: why generic CTAs flop with technical readers, what CTA copy and placement work, and how to track post-to-signup.
Keyword research for developer tools means chasing 20-search queries, not 5,000-search ones. Where to find them and how to build a cluster that converts.