Astro vs Next.js: Which Framework to Pick

The short answer

Pick Astro when your website delivers content: home page, services, case studies, knowledge articles, landing pages, careers. Pick Next.js as soon as app logic joins in, meaning a gated login area, data that changes constantly, or content the server assembles per visitor on every request. There is no grey zone between those two cases that you would have to fill with taste.

Our default for B2B websites is Astro with Sanity as the content database, a content system without its own front end that delivers content through an interface. We reach for Next.js as soon as logins, live data or server-side data per request are required. We run both in daily operation: in-sync.io itself runs on Next.js, leanwave.com runs on Astro.

Both frameworks give you full access to rendering, structured data, sitemaps and caching. That is what matters to Google and to AI crawlers, and on that front they are equal. They differ in what the browser has to download, and in what the server can still do at runtime.

What Astro and Next.js are

Both are JavaScript frameworks for websites, both produce HTML, both run on hosting platforms like Vercel. From there they part ways, and the fork is about when the HTML is created and how much code keeps working in the browser afterwards.

Astro: HTML at build time, JavaScript only for islands

Astro, often written as Astro JS, turns your pages into finished HTML at build time and stores them as files. Interactive elements like a search field, a pricing calculator or a carousel ship as islands, meaning single interactive spots inside an otherwise static page that carry their own JavaScript and boot independently. Everything else stays plain HTML. You can mix components from React, Vue, Svelte or Solid in the same page, because Astro only uses them to render.

Next.js: React with a full runtime

Next.js is a React framework with server rendering (HTML created on the server when the request arrives), static builds, React Server Components and a full runtime. Behind it runs a server process that can manage sessions, query databases, accept form submissions and expose API routes, meaning your own interfaces for other systems. With that you are no longer building a website, you are building an application that also works as a website.

Astro vs Nextjs: ten criteria compared

The table below compares both frameworks along the points that actually decide things in our projects. It does not replace an architecture decision, but it shows where the differences sit.

Shipped JavaScript and performance

Astro ships 0 KB of JavaScript for static content by default. Scripts load only where you place an island. Next.js sends the React runtime along, even when the page ends up showing nothing but text and images. That is not a flaw in Next.js, it is the price of a runtime that keeps working in the browser.

How large the gap gets in practice shows in our own measurement from 13 September 2026. leanwave.com, which we build statically with Astro, loads roughly 39 KB of JavaScript in three files on its homepage. One of our Webflow client sites loads roughly 740 KB in thirteen files at the same spot. We deliberately quote no PageSpeed values alongside, because those depend on the moment and the test device. Less JavaScript means less work for the device, and that feeds straight into Core Web Vitals, Google's measurements for loading behaviour and stability.

A cleanly built Next.js project can be very fast too. It just takes more discipline: Server Components instead of client components, bundles kept under review, libraries used sparingly. In Astro the lean state is the default, in Next.js it is a decision your team has to make again in every sprint.

Rendering models compared

Rendering answers one question: when is the HTML created that browsers and crawlers see. SSG means static site generation, finished HTML at build time. SSR means server side rendering, HTML the server creates on every request.

Astro does both and lets you decide per page. A service page goes static, a search results page goes server-side. Static stays the norm, and static means delivery without computation, everywhere in the CDN, with no dependency on a running process. The price is the rebuild. When an editor changes a line, a new build runs, at LeanWave triggered by a webhook, an automatic call Sanity fires on every change.

Next.js adds two more models on top. ISR refreshes single pages after a set interval without rebuilding the whole website. React Server Components render components on the server and send only the result to the browser. Both pay off once you have many pages changing independently, or content that differs per user. For a marketing website with thirty to two hundred pages you rarely need them.

Content and CMS integration

Both frameworks work with a headless CMS, a content system that delivers content as data only and dictates no design. We use Sanity for that. The content model, the queries and the rendering live in code, not in an interface that sets your limits for you.

With Astro the build fetches content once and writes files from it. With Next.js you can additionally query per request whenever a piece of content has to be current. In both cases you drive the whole chain programmatically: content model, templates, rendering, schema, sitemap, internal linking and deploy. AI agents can create and check content through the API and through an MCP server, a standardised interface for AI tools.

That is not a distinction against page builders: Webflow, Wix, Contentful and Storyblok have official MCP servers and APIs as well. The real difference sits elsewhere, namely in item and collection limits, in template limits (one template is tied to one collection), in API rate limits and in the missing code-level access to rendering, caching, schema logic and internal linking. How that plays out against Webflow and Wix Studio is written up in our platform comparison. One rule holds in both frameworks: programmatically generated pages need real substance per page, otherwise Google devalues them as doorway pages, pages that exist only to cover a keyword. We lived through that on our own old website.

Interactivity and where Astro hits its limits

Astro covers every form of interactivity that happens inside one page. A form with validation, a filter above a list, an animation on scroll, a 3D element: all doable, wired in as an island, costing the rest of the page nothing. Our animation projects run exactly that way.

The limit is shared state across page changes. A cart that follows the visitor over five pages. A customer portal with permissions and roles. An interface where users create data and see it reflected immediately. The moment you start building your own state management and your own server layer inside Astro, you are rebuilding Next.js without its tooling. That is where we switch.

Second limit: personalised content per request. When every visitor sees something different because they are logged in or come from a certain country, the static build loses its advantage. Astro can render server-side, but then you are comparing it to Next.js on home turf, and there Next.js has the more mature toolbox.

SEO and GEO levers: a tie between the two

Rendering, structured data, sitemaps, hreflang and caching are code-level in Astro and in Next.js alike. Both deliver HTML that crawlers can read without executing JavaScript. No framework ranks on its own, both hand you every lever Google and AI crawlers read.

In practice that means schema markup like FAQPage or Organization is generated from the same data you build the page from. The sitemap comes out of your routes automatically. hreflang, the markup that says which language version belongs to which country, is set reciprocally including x-default. An llms.txt, a machine-readable overview of your content for AI systems, is just a route in either framework. Canonical tags, which tell Google the authoritative URL, belong in the template in both. More on that in technical SEO and in our take on generative engine optimization.

The one difference with SEO impact is indirect: less shipped JavaScript improves loading behaviour on weak devices, and loading behaviour is one ranking factor among many. That favours Astro, but it never outweighs a portal feature you actually need.

Team and learning curve

Astro is approachable for developers who know HTML, CSS and some JavaScript. The component syntax sits close to HTML, and you do not have to learn React to build a complete website. Anyone who does know React simply brings it along for the islands.

Next.js requires React knowledge, and since React Server Components an understanding of which code runs on the server and which runs in the browser. That is learnable, but it is the steeper curve, and mistakes there cost exactly the performance you chose Next.js for.

For your selection that means: ask first who maintains the website in two years. If your company has a React team, Next.js is defensible even for pure content pages. If nobody internal owns it and an agency handles development, Astro is the smaller risk, because onboarding a successor takes less time. What either route costs is laid out in our overview of web development costs.

Can you combine Astro and Next.js?

Yes, and on larger accounts it is the norm. The marketing website runs on Astro, the product or customer portal behind it runs on Next.js, both on the same domain, split by a path like /app or by a subdomain. For visitors the transition is one click, for crawlers it is an ordinary link.

Both halves pull their content from the same Sanity database. Prices, product names, legal texts, translations: maintained once, current in both places. The marketing side fetches at build time, the application per request. Having both read the same content model removes exactly the duplicate maintenance that drifts apart after six months in separate systems.

If you are coming from an existing platform, plan that split into the relaunch project itself. How we protect rankings while doing it is written up in our piece on relaunch without SEO losses: a crawl beforehand, a ranking snapshot, a 1:1 redirect map for every old URL, then two weeks of monitoring with a 404 report.

When Astro, when Next.js

The decision comes down to whether your website delivers content or executes logic. The two lists below cover the cases we meet in projects.

Pick Astro when

Your website is a content project at heart that should load fast and be found easily.

Pick Next.js when

Your website is part of a product, or is meant to become one.

Our verdict

Astro is our default for content-driven business websites, Next.js our tool the moment app logic appears. We have held that rule for two years, and it has held up in every project where we applied it.

LeanWave, the website of Otto ID Solutions for RFID in textile services, we build statically with Astro and Sanity on Vercel: bilingual with reciprocal hreflang including x-default, translated URL segments, 64 documents and 86 image assets, rebuilt via webhook on every change. For Yarowa we ported a five-language Webflow export 1:1 to Astro: 21 page templates, 163 sections, design untouched, with the move to Sanity and Presentation Mode planned. Ullsteinhaus (Astro, React, Three.js, Sanity) and Monteval (Astro, GSAP, Sanity) run on Astro as well.

in-sync.io itself sits on Next.js, because we use server rendering and server-side data per request: 49 knowledge articles, 10 service pages and 17 city pages all come out of one Sanity database, bilingual with hreflang, plus llms.txt, IndexNow and FAQPage schema. To be straight about it: the old Wix site ranked for close to nothing, the new one went live in June 2026 and is building its rankings now. If you are unsure which route fits your project, our web design and development consultation looks at the actual feature set before any framework is fixed.

Frequently asked questions

Next step

Send us the requirements for your next website and we will tell you whether Astro or Next.js is the shorter route, before a line of code exists.