I Migrated 3 Client Sites From WordPress to Astro. With Claude, Nothing Broke.

I've been building WordPress sites for clients for over six years. Hundreds of them. And for most of that time, WordPress was fine. Good enough. The thing that pays the bills.

But somewhere around project number 150, I started dreading the updates. The plugin conflicts. The "this page builder just pushed a breaking change" panic at 11pm. I didn't want to fix WordPress anymore. I wanted to build websites that didn't need fixing.

So I migrated three client sites from WordPress to Astro in one month. And with Claude handling most of the UI conversion, almost nothing broke.

Why I Wanted a Dist Folder With Clean HTML and Nothing Else

Here's what I was after: a build command that spits out a dist folder full of clean, static HTML files. No JavaScript runtime. No hydration. No islands. No dynamic routes. Just markup, CSS, and done.

I've written about why I left WordPress before. The short version: 20+ plugins per site, security patches every week, hosting costs that kept creeping up. But the real trigger was simpler than that. I looked at a client's marketing site, a site that was basically five static pages and a blog, and realized it was running 23 plugins, a MySQL database, PHP 8.2, and a caching layer just to serve what could be flat HTML files.

That felt absurd.

Astro's pitch is exactly this. Zero JavaScript shipped by default. You write components, Astro compiles them to static HTML at build time. The output is a folder you can host anywhere. Cloudflare Pages, Netlify, a $5 VPS, literally anywhere. No server runtime needed.

I didn't care about Astro's island architecture or its ability to mix React and Vue components on the same page. Cool features, sure. But for my use case, I wanted the opposite of complexity. I wanted the simplest possible output.

ACF, Bricks, Elementor: The Migration Sounded Impossible

Here's where it gets interesting. These weren't simple WordPress sites running a basic theme. One was built with Elementor, one with Bricks Builder, and one had Advanced Custom Fields with custom PHP templates.

If you've ever viewed the source of an Elementor page, you know what I'm talking about. Div inside div inside div inside div. Auto-generated class names like elementor-element-a8b2f3c. Inline styles everywhere. It's not HTML you can read. It's HTML that a machine generated for another machine to interpret.

Bricks is better, honestly. Cleaner output. But still deeply nested, still builder-specific classes, still not something you'd want to maintain by hand.

And ACF sites? The content lives in custom fields scattered across the database. The templates are PHP files that pull get_field('hero_title') from twenty different places. There's no clean "export" button.

Manually converting any of these to Astro components would have taken weeks per site. I was looking at a two to three month project.

Or so I thought.

I Let Claude Build the UI and It Was Done in a Jiffy

This is the part that surprised me.

I took the rendered HTML from each page (just "View Source" in the browser, nothing fancy), fed it to Claude, and asked it to convert the markup into clean Astro components. Strip the builder classes. Keep the visual structure. Use Tailwind for styling.

With some tinkering and back-and-forth, Claude handled it. The deeply nested Elementor divs? Flattened into semantic HTML. The Bricks custom classes? Replaced with Tailwind utilities. The ACF template logic? Converted into Astro's frontmatter data fetching.

I'm not saying it was zero effort. There was tinkering. Some components needed a few rounds of "no, the spacing is off" or "the mobile layout broke." But compare that to manually rewriting every page from scratch? It wasn't even close.

The three sites that I estimated would take two to three months? Done in about three weeks. And most of that time was me reviewing and testing, not writing code.

Fair question: did the output need cleanup? Yes. Claude sometimes over-engineers component structures or adds classes you don't need. But the cleanup was fast. Way faster than starting from a blank file and trying to reverse-engineer what an Elementor section was supposed to look like.

The Performance Numbers Speak for Themselves

I'll let the numbers talk.

Before migration (WordPress + Elementor, typical mid-range hosting):

• LCP: 0.81s
• First load: 1.2-2.1s
• Lighthouse Performance: 72-85
• Total page weight: 1.8MB average

After migration (Astro SSG, Cloudflare Pages):

• LCP: 0.44s (46% faster)
• First load: 200-400ms
• Lighthouse Performance: 98-100
• Total page weight: Under 500KB

That's 72% less HTML, 60% less JavaScript (well, zero JavaScript in most cases), and 90% less CSS than the WordPress versions. And these aren't synthetic benchmarks. These are the numbers from real client sites serving real traffic.

The hosting cost went from around $25-40/month per site on managed WordPress hosting to literally $0 on Cloudflare Pages' free tier. For static sites, you genuinely don't need to pay for hosting anymore. If you want to dig deeper into what makes sites fast, I wrote a broader guide on website optimization that covers the fundamentals.

Where This Approach Falls Apart

Let me be honest about the limits. Because this approach has clear ones.

If a site needs blog comments, a contact form with server-side processing, user authentication, a search function, or anything that requires a database at runtime, pure SSG Astro is not the right tool.

You can bolt these things on. Astro supports API routes, server-side rendering, and third-party services for forms and comments. But at that point you're fighting the framework. You're adding complexity to a tool whose entire value is removing complexity.

I've explored Cloudflare's EmDash CMS as an alternative for sites that need a bit more. But honestly, for anything with real dynamic requirements, I reach for a different tool entirely.

Here's my rule: if the client's site could theoretically be printed on paper and still make sense, it's an Astro site. If it needs to do things, respond to users, process data, manage state, it's not.

Astro for Static, Next.js for Dynamic. That's It.

I see endless "Astro vs Next.js" comparison posts. Most of them miss the point entirely. These frameworks aren't competing. They solve completely different problems.

Astro is for content sites, marketing pages, blogs, portfolios, documentation. Sites where the content doesn't change based on who's looking at it. You build it once, deploy static files, and it's fast forever.

Next.js is for applications. Dashboards, e-commerce, platforms with user accounts, anything that needs a backend, a database, or server-side logic. I've built plenty of these too, and I've had my share of Next.js build problems. But for dynamic projects, it's still what I reach for because I'm more comfortable with it.

The decision tree is simple: Does the site need a backend? Next.js (or whatever full-stack framework you prefer). Does it need to be fast, cheap, and static? Astro.

No framework wars. Just the right tool for the job.

What I'd Tell You Before You Try This

If you're thinking about migrating WordPress sites to Astro, here's what I wish someone had told me.

Audit your pages first. Look at every page and ask: does this actually need to be dynamic? Most marketing sites don't. But that one page with the booking form or the client portal? That changes the equation.

Know your CMS situation before you start. If your client needs to edit content themselves (and they will), you need a headless CMS. Directus, Storyblok, whatever. Factor that setup time into your estimate. It's not hard, but it's not free either.

Let AI handle the builder-to-component conversion. Seriously. Don't sit there manually rewriting Elementor output. Feed the rendered HTML to Claude, tell it what you want, and iterate. You'll save weeks.

Map every URL before you migrate. I almost learned this the hard way. Your WordPress site has URLs. Your Astro site needs to have the exact same URLs, or 301 redirects for every single one. Miss this step and your SEO tanks. If you're planning a migration, the website relaunch checklist covers the SEO preservation steps in detail.

Budget less time than you think. This sounds counterintuitive for a migration. But with AI handling the UI conversion, the actual development time is surprisingly short. The testing and review takes longer than the building.

Three sites. Three weeks. Clean HTML in a dist folder. Zero JavaScript overhead. And hosting that costs nothing.

I'm not saying Astro is the answer to everything. It's not. But for static sites that don't need to do anything fancy? It's exactly what I wanted WordPress to be all along.

Thinking about migrating your sites to something faster and simpler? Let's talk about whether Astro makes sense for your specific situation.