Go back

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.

Table of contents

Open Table of contents

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.

Platform Comparison

Before committing to Astro, we compared it against the platforms we’d used or considered:

FeatureAstroWordPressFramerWebflow
Native Markdown/MDXYesNo (plugin)NoNo
Static site generationYesNo (plugin)PartialYes
GitHub integrationYesNo (plugin)NoNo
Static search libraryYes (Pagefind)NoNoNo
Dynamic OG imagesYesNo (plugin)NoNo
Free tierYesSelf-host onlyLimitedLimited
Vanilla HTML/CSS/JSYesNoNoNo
Open sourceYesYesNoNo

Astro’s combination of native Markdown support, GitHub-based workflow, and zero vendor lock-in made it the clear choice for a content-heavy site.

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:

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 search methodology was straightforward: Google searches for “astro theme ai mdx tailwind html css light/dark mode, seo, minimalist” combined with browsing the top-starred Astro theme repositories on GitHub.

Our requirements were:

We evaluated a wide range of options:

After reviewing these options, we settled on AstroPaper.

AstroPaper checked every box: Tailwind CSS v4 for styling, Pagefind for static search (no external services required), Astro’s SVG component for optimised icon handling, 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.

Why Astro Excels at Speed, SEO, and AEO

Astro’s static-first architecture makes it exceptionally well-suited for search engine optimisation (SEO) and answer engine optimisation (AEO)—the practice of structuring content so AI systems can accurately surface it in responses.

Speed as a ranking factor — Google uses Core Web Vitals as ranking signals. Astro’s approach of shipping zero JavaScript by default means pages load almost instantly. All pages are prerendered to static HTML at build time and served as pure static files from a CDN edge—the fastest possible delivery method.

Clean, semantic HTML — Unlike JavaScript-heavy frameworks that render content client-side, Astro generates complete HTML that search engines and AI crawlers can parse immediately. No waiting for JavaScript execution, no hydration delays.

Structured content — Content Collections enforce consistent frontmatter schemas, making it easier to generate accurate meta tags, Open Graph images, JSON-LD structured data, and XML sitemaps. This structured approach helps both traditional search engines and AI systems understand your content.

Minimal overhead — Since AstroPaper is primarily a blog/content site, we don’t need output: "server" or complex runtime logic. Static prerendering handles everything, keeping the architecture simple and fast.

For content-driven sites where discoverability matters, this combination of speed and structure is hard to beat.

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

We built the site with Claude’s help. Here’s the initial prompt we used to kick off the project:

You are going to help me build a new Astro (astro.js) website.
Read this first https://docs.astro.build/en/guides/build-with-ai/.

We're going to be using the theme https://github.com/satnaing/astro-paper.
This uses Tailwind CSS v4, Pagefind for search, Astro's SVG component,
pnpm for package management etc.
You can read more here https://astro-paper.pages.dev/posts/astro-paper-v5/.

The site will be hosted using Cloudflare Pages.
A Server-side Rendered (SSR) site to Cloudflare Pages.
More info on the Cloudflare framework guide here
https://developers.cloudflare.com/pages/framework-guides/deploy-an-astro-site/.

You have access to the following MCP servers with the latest documentation:
- Cloudflare Docs
- Astro Docs

Don't run any commands or take any actions without asking me first.

Follow the readme (https://github.com/satnaing/astro-paper#readme)

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

Two Days with Claude Code

After the initial setup, we used Claude Code (powered by Claude Opus 4.5) to rapidly iterate on the site. Here’s everything we accomplished in just two days:

Branding & Configuration

Content & Blog Posts

Features & Functionality

Design & UI

Bug Fixes & Accessibility

Redirects & Navigation

Code Quality

The speed of iteration was remarkable. Tasks that would have taken hours of manual work—like adding 336 blog posts, reorganising tags, or implementing consistent redirects—were completed in minutes through conversational prompts.

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:

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.

growth-resources
Back to top ↑