Skip to content

Migrate from Framer

Framer is an excellent marketing-site builder, but its CMS is not a git-based blog. Your posts live in Framer Collections, not as Markdown files in a repo, so Lyra cannot write to them. To use Lyra, move your blog to a git-based framework first. This guide covers why Framer falls short for a serious blog, how to move without losing rankings, and where to read the full playbook.

For the complete, sourced walkthrough, see the Lyra blog post Framer to git-based blog migration.

Why Framer's blog is not Lyra-ready

Framer's Designer ships a polished landing page faster than almost anything. A blog asks the CMS to do relational work a landing page never needs, and that is where Framer's defaults stop:

  • No native categories, tags, or author pages. The field types to build them exist, but no starter template ships that structure. You assemble it by hand.
  • Canonical control is gated. A custom canonical URL sits behind an Enterprise plan or a paid reverse-proxy add-on. Below that tier, the canonical follows whatever domain you connect.
  • No default schema markup. Article and breadcrumb structured data do not ship with the blog template. You write it into a custom embed on every post.
  • Content is not in a repo. Posts are Collection items, not Markdown files, so there is no diff, no branch, and no pull request for Lyra to open.

None of these is a Framer bug. They are the shape of a design-first CMS, and they are exactly what a git-based blog gives you by default.

What you gain on a git-based blog

Moving to a static site generator turns the Framer workarounds into defaults:

  • Category, tag, and author pages generate from your content directory automatically.
  • Article and breadcrumb schema ship as code on every post.
  • A canonical tag is a build-time default, not a paid setting.
  • A merged pull request is the only publish event, so nothing goes live unreviewed.
  • Lyra can write every new post, reading your repo and opening a PR you merge.

The migration, in order

Protecting your rankings is the point of the whole move. Work through this before you export anything:

  1. Map every URL. Pull every indexed URL from Google Search Console's Coverage report and build a spreadsheet of old URL to new URL. Do not trust Framer's CMS panel as the full list.
  2. Decide your new URL structure now. Settle it before you write redirects, so you write each rule once.
  3. Export your content. Use the CMS Export plugin from Framer's marketplace to pull each Collection to CSV, and separately download the static HTML snapshot of the live site.
  4. Rebuild your structure. Recreate every category, tag, and author relationship as real structure in your new content, plus the frontmatter Lyra will learn. A CSV export flattens these joins, so you rebuild them on the other side. See Blog frontmatter.
  5. Redirect with 301s. Write permanent 301 redirects for every mapped URL on your new host. A 301 carries your rankings across; a 302 does not. If your move includes a domain change, set the domain-level redirect at your DNS provider or registrar, because Framer's redirect tool only covers sub-paths on a connected domain.
  6. Launch together. Ship the new site and the redirects at the same time, then submit the new sitemap in Search Console the same day.
  7. Watch and hold. Check Coverage and Performance in Search Console daily for two weeks, then weekly through 90 days. Keep the redirects live for at least a year, and do not cancel Framer until every asset and redirect is verified on the new host.

Then connect Lyra

Once your posts are Markdown files in a repo and the redirects are live, your blog is Lyra-ready. Connect the repo and Lyra takes over the writing, opening a pull request for every new post, the same review gate you already use for code.

  1. Confirm your blog passes the checklist in Is your blog Lyra-ready?.
  2. Connect your repository.
  3. Run onboarding if you have not already.

What's next

Claude for blog writing
© 2026 Lyra. All rights reserved.