Framer to Astro migration
Moving from Framer to Astro means rebuilding the front end in code, because Framer has no HTML export for self-hosting. Your content, URLs and metadata do carry across: we export the CMS, keep paths identical where we can, redirect the rest permanently and check every page before the domain moves.
- Audit and inventory
- Content model and export
- Rebuild in Astro
- Redirects, checks and switchover
Trusted by B2B and premium service brands in 17+ countries.
Proof
Our own site is the case study
urest.agency moved from Framer to Astro, with Tailwind CSS, Sanity as the CMS and Cloudflare hosting. These are the checks from the move, taken from the parity report in our repository.
Live on the new stack since 21 October 2026.
97
Old URLs checked
97 found on the new site, 0 missing
23
Served through a 301
The other 74 kept their exact path
94
Meta descriptions unchanged
Out of 97, carried over word for word
64
Blog posts carried over
Every published post, with the same slug
Built during the move: the first programmatic pages were committed on 21 October 2026, two days after the first commit of the new site.
26
Programmatic pages built
10 migration guides, 6 comparisons, 6 technology guides, 4 location pages
26
Pass the quality gate
Checked on every build; a page that fails stays noindex
262
Official sources on file
The documentation behind each claim, kept in the CMS for review
Real-user performance data needs a full 28-day Chrome UX Report window. We will add it once it exists.
Why teams move
Why teams move from Framer to Astro
The content model has outgrown one site
When content has to feed more than a marketing site, such as an app, a help centre or a partner portal, a headless CMS read by Astro gives every channel the same structured source instead of one builder project holding it.Hosting has to sit with your infrastructure
Framer hosts every Framer site and offers no HTML export for self-hosting.Astro builds static files, or runs on official adapters for Node, Netlify, Vercel and Cloudflare, so the site can live where the rest of your stack already does.
Engineers want the site in the repository
Some teams want the marketing site reviewed, tested and deployed like the rest of their product, with pull requests and automated checks.An Astro codebase fits that workflow; a visual builder project sits outside it.
What moves
What carries over, and what needs work
Carries over
- Page copy, headings and the structure of the site you already have
- CMS collections, exported to CSV with Framer's CMS Export plugin and imported into the new CMS
- URL paths and CMS slugs, which we keep identical wherever the new routes allow
- Meta titles, descriptions and social images, carried over page by page
- Images and files, downloaded once and re-optimised by Astro's image tools at build time
Needs work in Astro
Layouts and componentsFramer does not export code for self-hosting, so every layout, breakpoint and component is rebuilt by hand as Astro components.
It is a rebuild of the front end, not a file conversion.
Effects and interactionsScroll effects, hover states and animations set up in the Framer editor have no export path.
We rebuild the ones that earn their place with CSS and small scripts, and leave JavaScript off pages that do not need it.
- The editing experienceEditors lose the visual canvas. Content moves into a headless CMS such as Sanity, where people edit structured fields, so we model those fields around how your team actually writes and publishes.
Forms, code components and pluginsFramer forms, React code components and marketplace plugins do not move on their own.
Each one gets a deliberate replacement, such as a form endpoint, an Astro or React component, or a direct integration.
Content model
How Framer content maps to Astro
We map every field before anything moves, so content is not retyped by hand and nothing is dropped without a decision.
| In Framer | In Astro | What we check |
|---|---|---|
| Plain Text | Sanity string | Length limits added in the schema where the design depends on them |
| Formatted Text | Portable Text | Headings, links and lists checked after conversion |
| Image | Sanity image with alt text | Alt text carried over, crops set with the hotspot tool |
| Date | date or datetime | Publish dates compared item by item after import |
| Reference, Multi-Reference | reference, array of references | Referenced collections imported first so every link resolves |
| Option | string with a fixed list | Values kept identical so filters and labels keep working |
| Toggle | boolean | Default value set in the schema, not left empty |
| Gallery | array of images | Order of images preserved |
Redirects and SEO
Protecting rankings during the move
The redirect plan
Keep paths identical first
Framer CMS pages use a path pattern you set, such as /blog/:slug.Astro's file-based routes reproduce the same pattern, so most URLs on the new site are exactly the ones Google already knows.
Redirect only what has to change
Where a path must change, the old URL gets a permanent redirect.On static hosting we write rules to the host's own redirect file, such as _redirects on Cloudflare Pages, because a plain static Astro build only produces meta refresh pages.
Compare old and new before the switch
We crawl the Framer site, then the Astro build, and compare status codes, titles, descriptions, headings and canonical URLs page by page before the domain is pointed at the new host.
Risks we watch for
Canonical tags become your code
Framer writes canonical tags for you. In Astro they come from your templates, and settings such as trailing slashes and the build output format change the URL a page reports, so every canonical is tested against the live address.Sitemap and robots.txt
Framer generates sitemap.xml and robots.txt automatically. In Astro the sitemap comes from the official @astrojs/sitemap integration and robots.txt is a file in the project, so both are checked on launch day.Structured data added by hand
JSON-LD pasted into Framer custom code has to be rebuilt in the templates from real data, page type by page type, or the site quietly loses the rich results it has earned.
Timeline and fit
How long it takes, and whether it suits you
It fits when
- Your team wants the site in its own repository, reviewed and deployed like the rest of your code
- Content needs one structured model shared with other channels or products
- Hosting has to run on your own infrastructure or a specific provider
- Developers on your side, or ours, will own the site after launch
We would advise against it when
- Marketing needs to build and launch new layouts without a developer
- The site is a typical marketing site that Framer already serves well
- Nobody will own the codebase after launch
- The main goal is speed to launch rather than control
How we run it
How we run a Framer to Astro move
Step 01
Audit and inventory
We crawl the Framer site and list every page, CMS item and URL, with its title, description and current rankings, so the Astro build has a baseline to match before anything changes.
Step 02
Content model and export
We design the schema in the headless CMS, export each Framer collection with the CMS Export plugin and import it with references and images intact, so nobody retypes content.
Step 03
Rebuild in Astro
We rebuild the layouts and components from the existing design as Astro components, rendered to static HTML, with client-side scripts only where an interaction needs one.
Step 04
Redirects, checks and switchover
We map any changed URL to a permanent redirect, compare old and new page by page, then point the domain and watch crawling and rankings closely in the weeks after launch.
Common questions
Framer to Astro: questions we get asked
Can a Framer site be exported to Astro automatically?
No. Framer does not offer HTML export for self-hosting, so the front end is rebuilt as Astro components. Content is different: CMS collections export with a plugin and import into the new CMS, so text is not retyped.
Will we lose rankings moving from Framer to Astro?
Not if URLs, metadata and redirects are handled first. We keep paths identical wherever we can, redirect the rest permanently and compare the old and new sites page by page before the domain moves.
Where does our content live after the move?
Usually in a headless CMS such as Sanity, which Astro reads at build time. Editors work in structured fields rather than on a canvas, and a webhook can rebuild the site when something is published.
Why would a Framer studio move a site off Framer?
Because some projects outgrow a site builder. When a team needs code ownership, a shared content model or its own hosting, Astro is the route we recommend; when a marketing site is served well where it is, we say so.
Next step
Want it moved for you? We plan the move around what already ranks.
We inventory every Framer URL, map each one to its new address in Astro, move the content with its metadata, then switch over and watch indexing.
- Every URL inventoriedA full URL list with a ranking and traffic baseline.
- Every old URL mappedA 301 redirect map so link equity carries over.
- Watched after launchSitemap submitted, then indexing and rankings monitored.
Planning a move from Framer?
Tell us about your current site and what needs to move, and we will come back to you with the next steps.