Astro vs Next.js for a B2B marketing website (2026): which to choose, and when

For a content-led B2B marketing site, we'd pick Astro; for a site that is part of a product (logins, app-like features, heavy personalisation) or a team that already runs Next.js, we'd pick Next.js. Astro prerenders every page to plain HTML and ships JavaScript only for the parts you mark as interactive, which is what a site people mostly read needs. Next.js earns its extra moving parts (React in the browser, server rendering, caching rules) when the website and the product share code, people and infrastructure.

Our bias, stated once: we build on Astro, Next.js, Framer, Webflow and WordPress, we're an Official Framer Expert, and our own site runs on Astro + Sanity. Versions, prices and quotes below are as of October 2026 and link to the vendors' own pages. It's one of our 2026 platform comparisons.

Astro vs Next.js at a glance

What is the real difference between Astro and Next.js?

Both can produce prerendered HTML. The difference is what each one assumes a page is: Astro assumes a document with a few interactive parts, Next.js assumes an application that also has pages.

In Astro, "By default, your entire Astro site will be prerendered", and Astro components "render to static HTML with no client-side runtime". Interactivity comes from islands: a component written in React, Preact, Svelte, Vue or SolidJS that you mark with a directive such as client:visible, which loads it "only once it enters the viewport". A React island still brings React, but only to pages that use one. Server islands render one dynamic block on demand inside a static page, and Astro 7 made route caching stable: one API for caching on-demand pages on any host.

In the Next.js App Router, "By default, layouts and pages are Server Components". They render on the server and "Reduce the amount of JavaScript sent to the browser". Routes that don't use dynamic APIs are prerendered at build, and ISR refreshes them without a full rebuild. The browser still runs React on every page: the RSC Payload the server sends is "used by React on the client to update the browser's DOM", and Next.js prefetches it for instant navigation. Interactive parts are Client Components, and once a file starts with 'use client', everything it imports joins the client bundle.

The same pricing calculator in each:

---
// src/pages/pricing.astro: this block runs at build time only
import PricingCalculator from '../components/PricingCalculator.jsx';
---
<h1>Pricing</h1>
<p>Plain HTML, no JavaScript.</p>
{/* Only this island ships JavaScript (React plus the component), when it scrolls into view */}
<PricingCalculator client:visible />

// app/pricing/pricing-calculator.tsx
'use client' // this file and everything it imports ship to the browser

On Astro, a page has no JavaScript until you add some. On Next.js, every page carries React, and a small client bundle is a discipline your developers maintain.

Is Astro faster than Next.js for a marketing site?

Out of the box, an Astro page usually ships less JavaScript, because a page without islands ships none. That isn't a guarantee: a well-built Next.js site can be fast, and an Astro site with heavy video and unoptimised images will be slow.

Speed and layout shift came up in 35% of our 101 client conversations this year, and the problems clients described (slow first loads where the animation is, pages jumping while scrolling, heavy hero video) sit in images, fonts, video and animation code on any framework. On our own site we took layout shift from a CLS of 0.19 to 0 with font metric overrides and reserved image space; Next.js would have needed the same work. Once a page needs more than a few interactive widgets, the JavaScript gap narrows and Astro's advantage moves from speed to simplicity.

Who is behind Astro and Next.js, and does it matter?

Both are MIT-licensed open source with one company paying the core team: Cloudflare for Astro, Vercel for Next.js. For a buyer, the useful question is whether the features you use tie you to one host.

On 16 January 2026, Astro announced that The Astro Technology Company, the company behind the framework, is joining Cloudflare, and that "All full-time employees of The Astro Technology Company are now employees of Cloudflare, and will continue to work on Astro full-time." Cloudflare's press release calls it an acquisition. The same Astro post says "Astro will remain free, open-source, and MIT-licensed" and "Astro continues to support a wide set of deployment targets, not just Cloudflare". Our own Astro site is hosted on Vercel.

Next.js is "Maintained by Vercel" and MIT-licensed. Its deployment docs say a Node.js server or Docker supports all features, list Vercel and Bun as verified adapters, and call the Netlify and Cloudflare integrations "not verified by the Next.js team, so feature support and compatibility may vary" while both build verified ones.

In practice, lock-in sits in features, not licences. A static Astro build is a folder of files any host can serve; a Next.js site using ISR, default image optimisation, Draft Mode or Server Actions needs a host that runs them (a Node.js server or Docker always does). Neither is a reason to avoid either framework. List the features you depend on before you pick a host.

Where can you host Astro and Next.js, and what does it cost?

Both deploy to Vercel, Netlify and Cloudflare: Astro through its official adapters, Next.js through Vercel's verified adapter, Netlify's OpenNext adapter or Cloudflare's vinext, which Cloudflare says "is in beta". The frameworks are free; the bill is hosting, the CMS and developer time.

• Vercel: Hobby is $0, but "Hobby teams are restricted to non-commercial personal use only", and commercial use includes "a paid employee or consultant writing the code". A company site needs Pro: $20/month with one deploying seat and $20 of usage credit, and $20 per extra deploying seat.
• Netlify: Pro is $20/month "with unlimited members" and 3,000 credits; a production deploy costs 15 credits and bandwidth 20 credits per GB.
• Cloudflare: on Workers, "Requests to static assets are free and unlimited". On-demand code is billed as Workers: 100,000 requests a day free, then a paid plan from $5/month.

An all-static Astro build is just files, so it fits the cheapest tier on every host, including Cloudflare's free static requests. Next.js can export a static site too, but that drops ISR, redirects, headers, default image optimisation, Draft Mode (how Next.js previews unpublished CMS content) and Server Actions. A Next.js site that needs those runs a server runtime, which adds usage-based compute.

An estimate, assuming a commercial site of about 40 pages plus a blog, two developers who deploy, three Sanity seats, traffic within the included allowances, and USD list prices per month excluding tax:

Sanity's Free plan ($0) can cover a small site, but its datasets are public only. The bigger line is developer time. Astro 7 shipped in June 2026 and Next.js 16 in October 2025, so budget upgrades either way. A team that writes React every day pays less for Next.js; a team that doesn't pays less for Astro.

Which works better with Sanity or another headless CMS?

Both work well with Sanity and other headless CMSs, so choose the CMS on its own merits. Astro's docs list the "Official Sanity integration for Astro", published by Sanity as @sanity/astro, and Astro's content collections validate CMS content against Zod schemas at build. Sanity's Visual Editing has official quickstarts for both Next.js and Astro.

Editors get the same Sanity Studio on either framework. The Studio is itself a React app, so on our Astro site React runs at /studio and nowhere on the public pages. Still choosing the CMS? Read Sanity vs WordPress and headless CMS vs website builder.

Which is better for SEO and AI crawlers?

Neither, as long as the content is in the HTML the server sends. Both do that by default, both let you opt out, and the opt-outs are where sites lose visibility.

Google renders JavaScript after a render queue and still advises that "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript." OpenAI, Anthropic and Perplexity document their crawlers but don't say whether they run JavaScript. The safe baseline is content that is readable before any script runs.

Patterns to avoid:

• Next.js: a Client Component that fetches its text in useEffect after load, or one loaded with dynamic(..., { ssr: false }), which disables prerendering for that component.
• Astro: client:only, which "skips HTML server rendering, and renders only on the client".
• Both: tabs, accordions and modals whose content is fetched or inserted only on click.

To check a page, open view-source (not the inspector) and search for a key sentence. JSON-LD and an /llms.txt are yours to add on either framework (more on AI visibility).

Why did we launch our own site on Astro, not Next.js?

Until 16 October 2026, agr.studio ran on Framer. We started a rebuild on Next.js + Sanity in January 2026 (first commit on 5 January); it never launched, and the Framer site stayed live. In October we rebuilt on Astro + Sanity and switched the domain.

The reason was the shape of the site: about 300 indexable pages, English plus a full Hebrew right-to-left mirror with hreflang, all prerendered to static HTML at build time. Only the embedded Sanity Studio and a few API endpoints (forms, the AI visibility check) run on demand, and motion is plain GSAP with Lenis, so public pages ship no React runtime. Next.js could have prerendered the same pages; Astro's default matched the job, so we had nothing to opt out of.

The stack is Astro 7, Sanity 6 and Tailwind CSS 4 on Vercel; a production build takes roughly one to two minutes on our machine. We ported about 80 redirect rules from Framer (91 today) and added JSON-LD on every page type, /llms.txt and a Markdown version of every page. AI coding agents (Claude Code) did much of the implementation under our direction and review.

What we gave up, compared with Framer, would be the same on Next.js: on-canvas editing and instant publishing by a designer. Design changes are now code changes that go through a build and deploy; content edits stay self-serve in Sanity. The full story is in Framer to Astro + Sanity.

What we've seen on client projects

From 101 anonymised client conversations, January to October 2026:

• Platform choice came up in 46% of them; a common reason for choosing Framer was that marketing can edit without a developer. On Astro or Next.js, layout changes are developer work, so the CMS model and documented components decide how fast marketing ships. One team whose website was its design system needed about two weeks per new page; the plan to roughly halve that was a CMS plus documented components.
• On Framer projects we flag custom React code components, whose content may not render without JavaScript. Any React stack has the same risk when a component renders only in the browser.
• Questions about AI search clustered in August to October. A cybersecurity SaaS company moving five languages asked for "SEO and LLM optimisation". Its structured data was missing, and we advised generating per-locale metadata rather than typing it by hand: code work on either framework. We quote 15 business days for a five-language migration with QA.
• Teams came to us from Craft, Squarespace, WordPress, React and Webflow. Whatever the framework, redirects decide whether traffic survives; we ask for CMS access or a full URL export, plus GA4 and Search Console (more on migrations).

How do you decide between Astro and Next.js?

• Pick Astro if people mostly read the site (product pages, case studies, a blog), editors work in a headless CMS, and the interactive parts are a few widgets such as a pricing calculator or demo form (Astro website development).
• Pick Next.js if visitors log in, pages change per user or account, the site shares components or deployment with a React product, or your developers already run Next.js; a second framework for one team is a real cost (Next.js website development).
• Pick neither if marketing must change layouts without a developer. A visual builder fits better; compare Webflow vs Next.js and Framer vs Next.js.
• Don't rebuild for the framework alone. If your Next.js marketing site serves complete HTML and your team ships comfortably, check what reaches the browser before you plan a move.

If you're weighing the two for a real project, tell us what you're building, or run your current site through our free AI check first.