Why We Moved Our Website from Framer to Astro

We’ve migrated our website from Framer to Astro—a modern JavaScript framework that’s transformed how we think about content-driven websites. Here’s why we made the switch and what we learned along the way.

What is Astro?

Astro is a JavaScript web framework optimised for building fast, content-driven websites. Unlike traditional frameworks that ship heavy JavaScript bundles to the browser, Astro generates static HTML by default and only hydrates interactive components when necessary.

The result? Blazing fast page loads and excellent Core Web Vitals scores out of the box.

The Journey: WordPress → Framer → Astro

We originally ran on WordPress. It served us well for years, but the constant maintenance—plugin conflicts, security updates, database overhead—eventually pushed us to look for alternatives. Framer seemed like the answer: a beautiful visual editor, fast hosting, and no server to manage.

Framer was great for design-led pages, but as our blog grew, the limitations became apparent. We’d set up Airtable sync to manage blog posts—a common pattern with Framer—but the workflow was overly complex. Editing posts through Airtable connectors (whether via Claude or MCP integrations) felt clunky. And every change required the same tedious dance: log into Framer, sync the new content from Airtable, then manually publish the site.

For a content-heavy site, this friction added up. We wanted to write, commit, and deploy—not juggle three platforms for every blog post.

We evaluated our options:

Staying with Framer — Beautiful but expensive at scale, and the blog workflow never felt quite right.

Webflow — Similar visual builder trade-offs, plus we’d be learning a new tool for the same category of limitations.

Astro — Static-first architecture, native Markdown support, and the flexibility to add dynamic features only where needed.

Astro won because it aligned with how we actually work: writing content in Markdown, wanting full control over our code, and prioritising performance above all else.

The Killer Feature: Content Collections

Astro 2.0 introduced Content Collections, and it’s genuinely changed how we manage content. It was the first major web framework to deliver complete type-safety for Markdown and MDX.

Here’s how it works: you organise your Markdown files into folders within src/content/, define your frontmatter schema in src/content/config.ts, and Astro handles the rest:

• Schema validation — Astro validates your frontmatter against your defined schema at build time
• Automatic TypeScript types — Generated types mean inline errors and autocomplete in your editor
• SEO best practices — Structured content makes it easier to generate meta tags, sitemaps, and OG images
• Informative error messages — When something’s wrong, Astro tells you exactly what and where

For a team writing lots of content, this structure is invaluable. No more runtime errors from missing fields or typos in frontmatter.

Markdown vs MDX

Astro supports both Markdown (.md) and MDX (.mdx). We use standard Markdown for most posts—it’s simpler and renders faster. But MDX shines when we need to embed interactive components, custom callouts, or dynamic elements within our content.

The flexibility to choose per-file means we’re never forced into unnecessary complexity.

Choosing a Theme

We spent considerable time evaluating Astro themes. Our requirements were straightforward:

• Markdown/MDX support
• SEO-friendly structure
• Responsive design
• Light and dark mode
• Fast performance
• Good documentation
• Active maintenance

After reviewing options including Astro Cactus, Astro Micro, Astro Nano, and Astroship, we settled on AstroPaper.

AstroPaper checked every box: Tailwind CSS v4 for styling, Pagefind for static search, built-in pagination and tags, dynamic OG image generation, sitemap support, and vanilla JavaScript with no heavy framework dependencies. It’s maintained by an independent developer with regular updates and good documentation.

One theme we explicitly avoided was AstroWind—while feature-rich, it includes a custom Astro integration that adds significant complexity. Not ideal for teams new to Astro who want to understand what’s happening under the hood.

Static vs Server-Side Rendering

Astro defaults to static output, which means all pages are pre-rendered to HTML at build time. This gives you the fastest possible serving—pure static files delivered from a CDN edge.

But Astro is flexible. You can opt individual pages into server-side rendering by adding export const prerender = false at the top of any page file. This hybrid approach means you get static performance for content pages while retaining the ability to add dynamic features like authentication or form handling where needed.

For a blog, static is almost always the right choice. We prerender everything and enjoy the simplicity of files that don’t need a runtime.

Hosting on Cloudflare Pages

We chose Cloudflare Pages for hosting. The setup is remarkably simple:

1. Connect your GitHub repository
2. Cloudflare detects it’s an Astro project
3. Deploy

Cloudflare’s edge network means our static files are served from locations close to readers worldwide. Combined with Astro’s minimal JavaScript output, our Time to First Byte is consistently excellent.

For sites that need SSR, Cloudflare’s adapter runs your server-rendered pages in Cloudflare Workers at the edge. But since our content is static, we stick with pure prerendering.

The Migration Process

Our setup was straightforward:

# Create new project with AstroPaper template
pnpm create astro@latest --template satnaing/astro-paper

# Install dependencies
pnpm install

# Start development server
pnpm dev
# Site available at http://localhost:4321/

# Add Cloudflare adapter (if you need SSR)
pnpm astro add cloudflare

From there, we exported our blog posts from Airtable to Markdown files, configured our site metadata, and deployed.

What We Gained

The migration delivered everything we hoped for:

Performance — Page loads are near-instant. No runtime rendering, just static HTML served from edge locations worldwide.

Developer experience — Writing in Markdown with TypeScript validation catches errors before they reach production. No more wrestling with a visual CMS for blog posts.

Cost control — Cloudflare Pages’ generous free tier means our hosting costs dropped significantly compared to Framer’s traffic-based pricing.

Content workflow — Our posts live in Git alongside our code. No more Airtable sync, no manual Framer publishing. We write in Markdown, push to GitHub, and Cloudflare Pages deploys automatically. Version control, branch previews, and collaborative editing come naturally.

Full control — Every line of HTML, CSS, and JavaScript is ours to modify. No platform constraints, no vendor lock-in.

Future flexibility — If we need dynamic features later, Astro’s hybrid rendering means we can add them without rebuilding everything.

Resources

If you’re considering a similar move, these resources helped us:

• Astro Documentation — Comprehensive and well-written
• AstroPaper Theme — Our chosen theme with excellent docs
• Cloudflare Pages Framework Guide — Deployment walkthrough
• Astro Discord — Active community for questions

Final Thoughts

Moving from Framer to Astro required upfront effort—particularly exporting content and rebuilding templates—but the ongoing simplicity has been worth it. For content-driven sites, the combination of Astro’s static-first architecture, Content Collections for type-safe Markdown, and edge hosting on Cloudflare Pages is hard to beat.

If you’re finding that visual builders like Framer or Webflow don’t quite fit your content workflow, or you want more control without returning to WordPress complexity, Astro deserves serious consideration.