Astro vs Next.js for Claude Code websites

A year ago every Siguro project started in Figma.

Now most of them start in a terminal. And once Claude Code is the one writing the code, the framework underneath decides how much it can actually get done without you.

We moved siguro.co off Statamic and onto Astro in June. Client sites have been following ever since, and I get asked “Astro or Next.js?” more than any other question right now. So this is my answer, with the numbers.

1.) How we used to build sites

Figma first, always.

We’d design the homepage until the style felt right, then push that style out to every other page and get sign off. Only then would anyone open a code editor, and the build went into Statamic, a PHP CMS we used for years.

I want to be fair to Statamic. It’s a good CMS and the editor is nice.

The problem was everything around it.

Git on the servers kept breaking. Content edited in the control panel gets committed on the live server, while code gets pushed from our side, and the two drift apart. Then a simple pull turns into a merge problem nobody wants to touch.

Every site needed its own environments too. Local, staging, production, each with its own PHP setup and config to keep in line.

And then hosting.

Some clients wanted static. Some wanted Netlify. Some wanted a fully static build on a VPS, and some wanted to host it themselves. It was a mess.

Each of those was a different setup and a different way for it to break. Add upgrades (moving clients to Statamic 6 was proper work) and the odd editor bug, like an image that just won’t swap on the day a client needs it changed.

None of that alone makes you switch. Together it’s what I’ve started calling the product tax.

The product tax is every hour you spend keeping the platform alive instead of making the site better. The client never sees any of it. They pay for all of it.

Running a Statamic site felt like we were building a product. We were meant to be building a website.

2.) What changed when Claude Code started writing the code

Claude Code works on files in a folder. It reads them, changes them, runs the build and checks what happened.

So the question I ask now isn’t “which CMS has the nicest editor”. It’s “can the agent see everything, and can it prove the change worked?”

That rules out a lot. If the real content sits in a database on a server, or the layout lives inside a visual builder, the agent is working half blind.

It has to be code. Pages, content, components and config, all in one git repo.

3.) What is Astro?

Astro is a web framework for content sites. You write pages as .astro files, which are mostly HTML with a bit of JavaScript at the top, and Astro turns them into plain HTML files when you build.

Anything interactive, like a pricing toggle or a form, is a small “island” that loads its own JavaScript. The rest of the page ships with none.

Next.js works the other way round. It’s a React framework built for apps, and every page brings React with it.

4.) Astro vs Next.js, the short version

These are the two I get asked about most.

Core Web Vitals and JavaScript: HTTP Archive, crawl of 1 August 2026. Happiness: State of JS 2025.

Part of that gap is the kind of site each one gets used for. Vercel makes that point on their own comparison page, and it’s fair.

But if you’re building a marketing site, you’re exactly the kind of site Astro was made for.

5.) Why we picked Astro

An Astro page is basically HTML with extra powers. When Claude Code opens one, what it sees is close to what ends up in the browser.

No splitting code between server and browser. No wondering which bit runs where. The page is the file.

With Astro I can just say "go and fix all these things" and it actually fixes them. You see the results straight away.

It also builds to plain files, which kills the hosting mess from section 1. Netlify, a VPS, the client’s own servers. Same build every time, and nothing to keep running.

Most marketing pages don’t need any JavaScript, so Astro doesn’t send any. The one pricing toggle gets its own little bit and that’s it.

And the content lives in the repo as Markdown and YAML, so the agent edits a blog post the same way it edits a component.

One thing people ask: Cloudflare bought the company behind Astro in January 2026. It’s still open source and they’ve said it’ll keep working on any host. Nothing has changed for us yet, but I’m watching it.

(Full disclosure: we build our own CMS on top of Astro, so I’m not exactly neutral here.)

6.) Astro SEO: what we do on every build

Astro gives you a fast start. This is what we add on top, and it all lives in the repo where the agent can see it:

• Every image becomes a WebP at build time, capped to a sensible width. Originals stay for social cards and downloads.
• Nothing blocks the first paint. Fonts load without holding the page up, and widgets like Calendly only load when someone clicks.
• Videos get a poster frame, so the page shows something straight away.
• Structured data on every page (organisation, articles, FAQs) so Google and AI assistants know what they’re looking at.
• The sitemap only lists real pages. Test pages, thank-you pages and A/B variants stay out.
• Every page gets a share image made for it automatically.

Here’s one real pass on siguro.co. I asked Claude Code to run Lighthouse across the site and fix what it found. It took under an hour.

Green, amber and red follow Google's own bands: a Lighthouse score of 90 or more is good, and the largest image should load in under 2.5 seconds.

What actually fixed it: 216 images converted to WebP (about 170MB lighter), an unused animation library removed (it was blocking the page for 832ms), fonts and Calendly loaded later, and a poster frame on the homepage video. That video was a 14.5MB file the whole page was waiting for. Oops.

That’s the loop I care about. Ask for a fix, watch the number move, ship it.

Doing the same on Statamic meant a server, a theme, a PHP asset pipeline and testing across environments. It was never an afternoon job.

7.) The myth that Next.js scores better in PageSpeed

I’d read somewhere that Astro is better for SEO but Next.js gets higher scores in Google’s PageSpeed Insights.

I went looking and couldn’t find anything credible to back it up. Across real sites, the median Lighthouse performance score on mobile is 70 for Astro and 52 for Next.js (HTTP Archive, August 2026).

Can a Next.js site hit 100? Sure, with work. What I care about is how much work, and whether it stays there every time the agent touches the code.

8.) The other code-based options

WordPress, Webflow and Framer aren’t here on purpose. They’re fine tools, but the site doesn’t live in a repo the agent can fully see, so they don’t fit how we work now.

Here’s everything else I’d look at, side by side.

All figures from HTTP Archive, crawl of 1 August 2026, mobile. Eleventy's sample is small (194 sites), so treat it loosely.

Next.js. The biggest ecosystem, and the one the AI has seen the most examples of. Vercel has also done the most for agents: new projects come with an AGENTS.md file that points the agent at bundled docs, and it says, word for word, “Your training data is outdated” (Next.js 16.2). I’d pick it when the marketing site is really part of a product, with logins or dashboards. For a site that’s mostly words and pictures it’s a lot of machine. It also had a critical security flaw in December 2025 (React2Shell) that hit default setups.

Hugo. Crazy fast, one program to install, great scores. We still build one client’s site in Hugo because it’s big, it’s stable and moving it wouldn’t pay for itself. If you’re weighing up Astro vs Hugo for a new site though, I’d go Astro for the components alone. Hugo’s templates are painful to write.

Eleventy. Tiny and simple. It’s called Build Awesome now, after Font Awesome renamed it in March 2026 and added a paid Pro tier (the free version stays free). Nice for small hand-built sites, but I’d want to see where the new owners take it first.

SvelteKit. People who use it love it (89% happy in State of JS 2025), and Svelte has an official tool that checks the code an agent writes. It leans towards apps, and AI models still write the old Svelte syntax sometimes. Great if your team already knows Svelte.

Nuxt. The Vue version of Next.js, now owned by Vercel too. Only if you’re already a Vue team.

I’d skip Gatsby (barely maintained now), Remix (being rewritten without React) and app-first tools like TanStack Start for a new marketing site.

9.) So which one should you use?

For a marketing site built with Claude Code, my current take:

Default to Astro. It’s the least work to make fast, the easiest for the agent to reason about, and it hosts anywhere.

Pick Next.js if the site is really part of your app.

Stay put on Hugo or Eleventy if you already have a big static site that works. Don’t migrate just because.

What I’m watching

This is where things stand in September 2026, and I’ll update it as things move.

The big unknown for me is Cloudflare owning Astro. So far it’s been good (faster releases, and Astro 7 added features for coding agents). But one company now owns the thing we build everything on, and I don’t love that.

I’m also watching whether Next.js closes the gap for agents. Vercel is putting real effort in and the tooling is already good.

What are you building on? And if you’ve moved off a PHP CMS, did it go as smoothly as you hoped? I read all replies.

Receipts

→ Hand this table to your own AI agent and ask it which framework fits your site.