Framer to git-based blog migration: keep your rankings

Framer's own numbers make the platform's popularity impossible to ignore: 40% of the most recent Y Combinator batch launched their site on Framer, according to Framer's $100 million Series D announcement in August 2025, which also put the company at a $2 billion valuation, hundreds of thousands of active sites, and roughly half a million monthly active users. For a landing page and a marketing site, that trust is earned. The design-first canvas ships a polished site faster than almost anything else on the market.

The blog is where that trust runs out. Framer isn't a bad SEO platform, it's an incomplete one for a serious blog, and the gap isn't cosmetic. The CMS field primitives that would let you build categories, tags, and author pages exist in Framer's own developer docs. Nothing ships that structure by default, and canonical URL control sits behind an Enterprise plan or a paid reverse-proxy add-on. This post covers exactly where Framer's blog breaks down, how to get your content out before you touch a single redirect, and the wildcard-redirect syntax and cutover checklist that protects the rankings you already earned. It's the same discipline we cover for a Webflow to git-based blog migration, a Notion to git-based blog migration, and a HubSpot to git-based blog migration: the platform changes, the discipline doesn't.

Why Framer became the default marketing-site builder, and where its blog breaks down

Framer's pitch is the Designer: a visual canvas that ships production code, no framework decision required before you have a single page live. That's the right tool for a landing page. A blog asks a CMS to do relational work a landing page never needs, categories, tags, authors, canonical control across dozens or hundreds of posts, and that's exactly where Framer's own defaults stop covering you.

Framer's CMS field primitives exist, but categories, tags, and author pages aren't native

Framer's native blog template has no category page, no tag archive, and no author bio, out of the box. DropInBlog's review of building a blog on Framer states it plainly: Framer's CMS "lacks core features such as categories, tags, author pages, and advanced SEO tools," missing "an SEO scoring tool, author profiles with E-E-A-T structure, automatic blog schema markup, and a built-in topic discovery workflow." DropInBlog sells a competing blog tool, so weigh the framing accordingly, but the underlying claim about missing category, tag, and author page templates is one you can verify yourself in Framer's own CMS starter, and it holds.

What's also true, and worth being precise about since Framer's own docs are explicit on this: the field primitives to build that structure yourself already exist. Framer's CMS developer docs confirm the platform supports a collectionReference field type, which "allows you to create fields that point to items in another Collection," and a multiCollectionReference field for connecting to several items at once. That's exactly the join you'd use to give a post a category, a set of tags, or an author, each one a Reference field pointing at a separate Collection. The gap isn't that Framer can't model this data. It's that no starter template ships that Collection structure, that join, or the category, tag, and author page templates that would render it. You're building it by hand, field by field, page by page, the same relational design work a CMS is supposed to save you from doing yourself.

We checked this against a live example instead of taking DropInBlog's word for it: Framer's own blog runs on Framer. It groups posts behind category filters, Inspiration, Tutorials, Engineering, News, in the top navigation, so category-style browsing does exist there. What's still missing even on the platform's own site is the rest of the structure: no dedicated tag archive page, and no individual author bio page tied to a byline, only a recurring "Framer Creators" editorial feature that profiles community members rather than a page every post links to. If the company that built the platform doesn't ship tag archives or author pages on its own blog, a starter template isn't going to hand them to you either.

Canonical URLs and schema markup are locked behind Enterprise, or done by hand

Framer's Designer writes a canonical tag automatically once you connect a custom domain, and for most single-domain sites that default is correct. It breaks down the moment your setup is more complex: a staging environment you don't want indexed, a reverse proxy routing /blog under a different root domain, a multi-site project where two properties share content. BRIX Templates' walkthrough of Framer's canonical settings confirms the native override for that case, the custom Canonical URL setting under Settings, Domains, "is available on Enterprise plans or by purchasing a reverse proxy Add-On." Below that tier, you don't get a manual override at all; the canonical tag follows whatever domain you've connected, whether that's the URL you actually want indexed or not.

Schema markup follows the same pattern. No Article, BreadcrumbList, or Organization JSON-LD ships with Framer's blog template by default. If you want structured data on a post, you're writing it into a custom code embed, by hand, on every post, indefinitely. Neither of these is a Framer bug. Both are what Enterprise-only, hand-rolled per-post work looks like once your blog grows past a handful of pages.

Exporting your content out of Framer before you touch a redirect

Get your content out before you plan a single redirect. Framer's export path is narrower than most platforms', and that changes what a realistic migration timeline looks like.

There's no first-party export tool, only a marketplace CMS Export plugin

Framer ships no built-in "export my blog" button in the product itself. The closest first-party equivalent is a third-party plugin from Framer's own marketplace. CMS Export, listed free in the marketplace, lets you "export any CMS collection into a CSV file," with a preview step to check the data before you commit, and it supports reimporting exported data back into Framer's CMS too. That reimport path is handy for a backup or a content audit, but for a migration it means your content's actual shape, rich text, images, Reference-field joins, gets flattened into rows and columns you have to reconstruct on the other side, the same conversion tax any CSV-based CMS export charges.

Framer sites are static HTML/CSS/JS you can download at any time

Here's the part that should be reassuring: you're never locked out of your own site. Framer's own help docs confirm every Framer site is published as "standard HTML, CSS, JavaScript, and static assets," downloadable "at any time" and portable to "any hosting provider," because the output follows open web standards rather than a proprietary format. CMS content specifically routes through the plugin path above into CSV or JSON, but the site itself, everything that isn't Collection data, is yours to pull whenever you want, with no waiting period. Pull that static export early, even if you're weeks away from cutover; it's a free, no-risk snapshot of exactly what's currently live.

Wildcard redirects and the cutover checklist that protects your rankings

The redirect layer is the single highest-leverage part of a Framer migration, and it's also the part Framer documents unusually well for a design tool. Get the syntax and the scope right and most of your ranking risk disappears before launch.

Framer's wildcard and capture-group syntax, and what plan you need to use it

Framer's redirect tool lives in Site Settings, Redirects, and it supports real pattern matching, not just one-to-one mappings. Framer's own redirect documentation lays out the syntax directly: a wildcard * matches any path segment, so /blog/* catches /blog/hello-world and a deeper path like /blog/2022/07/18/hello-world in one rule. Capture groups reuse what the wildcard matched: /blog/*/post/* redirecting to /article/:1/entry/:2 turns /blog/my-blog/post/getting-started into /article/my-blog/entry/getting-started, and a named :slug pattern matches a specific path segment the same way.

That's genuinely useful syntax for a migration, since one wildcard rule can cover an entire Collection's worth of old post URLs instead of hundreds of one-off redirects written by hand. The catch is the plan gate: Framer's current pricing page lists "Site redirects" as a feature that first appears on the Pro plan, $30 a month, alongside a bump to 2,500 CMS items and 10 collections. The Free and Basic tiers below it don't list redirects at all. If your blog is still on Basic when you start planning the migration, budget the Pro upgrade, even temporarily, as part of the project, or the redirect tool you're relying on won't exist yet.

Framer redirects don't cover the whole domain, and here's what does

Every rule you write in Framer's Redirects panel only covers sub-paths inside the domain currently connected to Framer. Framer's own documentation is direct about the boundary: "To redirect an entire domain (e.g., www.abc.com to www.xyz.com), use your hosting provider for the old domain." That's exactly the scenario a full platform exit produces, you're moving the whole domain's authority to a new host, not just restructuring paths within it, so Framer's tool was never built to carry that redirect and stops working the moment your DNS points away from Framer entirely. Set the domain-level redirect up at your registrar or DNS provider before cutover, and treat Framer's own wildcard rules as the tool for restructuring paths while you're still on the platform, not the mechanism that survives the move itself.

301 vs 302, and why Google's site-move guidance still applies

The redirect status code is what actually carries your rankings across, and Google draws a hard line between the two families. Google's documentation on redirects states it plainly: "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical," true for a 301 or a 308. A 302, 303, or 307 doesn't get the same treatment, because those codes tell Google the move might not be permanent, so the indexing pipeline withholds that canonical signal. A Framer-to-git migration is permanent. Confirm whatever redirect layer you land on, Framer's own tool pre-cutover, your new host's config after, is issuing a 301, not defaulting to a 302 because that's what the framework shipped.

Once the redirects are live, Google's site-move guidance sets the expectation for what happens next: keep the redirects live "for as long as possible, generally at least 1 year," because that's the window Google needs to recrawl every backlink still pointing at your old Framer URLs and reassign that signal to the new address. Expect a heavier crawl 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. Google is also direct that some ranking movement during that window is normal, not a sign something broke: "the visibility of your content in Search may fluctuate temporarily during the move. This is normal and a site's rankings will settle down over time," with a medium-sized site typically taking "a few weeks for most pages to move" in the index, and larger sites taking longer. A clean 301 map at cutover is what keeps you toward the fast end of that window.

What you gain moving to a Git/PR content workflow instead

The tradeoff is real, and it's worth naming instead of glossing over. Framer's Designer gives a non-technical editor a visual canvas with zero setup. A git-based blog trades that canvas for a Markdown file on a branch, reviewed as a diff. For a team that has never opened a terminal, that's a genuine cost, not a footnote.

Categories, tags, author pages, and schema as code instead of workarounds

What you get back is everything the Reference-field workaround above was standing in for. A static build generates a category archive, a tag archive, and an author page from your content directory automatically, no manual Collection join required. Article and BreadcrumbList schema ships as code on every post instead of a per-page custom embed written by hand. A canonical tag is a build-time default, not a setting gated behind Enterprise pricing or a reverse-proxy add-on. Our headless CMS vs git-based blog post covers the sync-layer risk you take on if you land on a headless CMS instead of going fully static, worth reading before you commit to either path.

A merged pull request is the only publish event

The bigger shift is procedural. Nothing publishes on a git-based blog until a pull request merges, a meaningfully different failure mode than a Framer Collection item going live the moment someone hits publish in the Designer. You can gate that merge on checks Framer's Designer has no equivalent for: broken links, valid canonicals, valid JSON-LD. Our GitHub Actions SEO checks post walks through four automated jobs that fail a build before a bad page reaches production. If you're weighing whether that tradeoff is worth it for your specific Framer setup, talk to the founder rather than guessing from a blog post.

A pre-migration checklist for a Framer to git move

Work through this before you export a single Collection:

1. Pull every indexed URL from Search Console's Coverage report and build a spreadsheet mapping old URL to new URL. Don't trust Framer's own CMS panel as the full list.
2. Decide your new site's URL structure now, so you can write the wildcard redirect rules once instead of revising them mid-migration.
3. Export every Collection with the CMS Export plugin, and separately pull the static HTML/CSS/JS export of the live site as a full snapshot before you touch anything.
4. Rebuild every Reference and Multi-Reference join, category, tag, author, as real relationships in your new content structure. Nothing about that join survives a CSV round trip on its own.
5. If your migration includes a domain change, arrange the domain-level redirect with your DNS provider or registrar. Framer's own redirect tool only covers sub-paths on a connected domain.
6. Confirm your Framer plan includes Site Redirects, Pro or above, before you rely on the wildcard tool for the pre-cutover phase.
7. Write server-side 301 redirects for every mapped URL on your new host, tested before cutover, using wildcard rules where one pattern can cover an entire old Collection.
8. Launch the redirects and the new site together, then submit the new sitemap in Search Console the same day.
9. Watch Coverage and Performance in Search Console daily for two weeks, then weekly through the first 90 days.
10. Keep the redirects live for at least a year, and don't cancel your Framer plan until every asset and redirect is verified working on the new host.

Once your Collections are Markdown files in a repo, the publishing question changes from "who has Designer access" to "what does our git workflow look like." 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 you're rebuilding your keyword strategy from scratch instead of porting an existing Framer blog, our guide to SEO for SaaS covers picking winnable keywords before you're locked into any platform's constraints, and if you haven't settled on a framework for the rebuild, our Astro vs Next.js SEO comparison covers the tradeoff for a content-first site specifically.

Once your Framer 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.

Try Lyra → · Talk to the founder