Next.js or Astro for a marketing website in 2026
For a marketing site that is mostly content I would build in Astro. Next.js earns its place when the site belongs to a React product. The two side by side, and which one I would pick when.
Agustin Dell’Aquila13 October 2026, 6 min read
On this page
Both are good, and both are current. Next.js 16.4 came out on 6 October 2026 and Astro 7.3 on 3 September. Both are free and MIT-licensed. Choosing the wrong one will not sink a marketing site. It will make the site slower to build, dearer to host, or harder to hand to the next person.
My answer: Astro for a site that is mostly content, Next.js for a site that belongs to a React product. This site runs on Next.js, and I say why further down.
The short answer
- Choose Astro if the site is pages of content with a few interactive parts, and nothing ties it to a React codebase.
- Choose Next.js if the site shares components, a deploy and a team with a product already built in Next.js, or if most of its pages change with who is looking.
- Choose neither if the people who change the site every week are not developers. That is the case for a visual tool, and I wrote it up apart: Framer or Astro for a startup marketing site.
The difference that matters
The two start from opposite ends.
Astro starts from the document. A page is prerendered to an HTML file when the site builds. A component is rendered to HTML and sent without JavaScript, unless I mark it to run in the browser. Astro calls the marked ones islands, and each loads its own script when I say.
Next.js starts from the application. Every page is a tree of React components. By default they render on the server, and the browser is sent the HTML first, then a payload that describes the tree, then the JavaScript that makes the client components work. React calls that last step hydration. What it buys is a site that moves between pages like an app, with the next page already fetched.
The second difference is where the line between fixed and live content falls. In Astro it falls between pages. In Next.js it falls inside the page, component by component, and both kinds arrive in one response. Its documentation is candid about the price: “The trade-off is infrastructure complexity.”
For an application that price buys a great deal. For twelve pages and a blog, I think it buys very little.
Next.js and Astro, side by side
| As of 13 October 2026 | Next.js | Astro |
|---|---|---|
| A page with nothing to press | HTML first, then a payload describing the React tree, then the JavaScript that hydrates its client components. | HTML and CSS. Components are rendered to HTML with no client-side runtime. |
| One interactive part | A Client Component. It and everything it imports join the client bundle. | An island. Its script loads on its own: at once, when the browser is idle, or when it scrolls into view. |
| Going to the next page | Client-side. The next page’s payload is prefetched and cached. | A full page load, as the browser does it. Client-side routing is there to opt in to. |
| Fixed and live content | Share a page. The line between them is drawn per component. | A page is static unless it opts out. A server island renders one part of it apart. |
| Code that runs per request | Part of the framework: Server Actions, Route Handlers and Proxy. | Opt in, page by page, with an adapter: actions, endpoints and server islands. |
| Hosting | A Node.js server or Docker runs all of it. Verified adapters: Vercel and Bun. A static export leaves the server features out. | Static files by default, for a static host. Official adapters for Node.js, Netlify, Vercel and Cloudflare. |
| Content | Wherever you put it. MDX comes through an official plugin, and reading a folder of posts is your own code. | Collections: Markdown, MDX, Markdoc, YAML, TOML or JSON files, or a loader for a CMS, each entry checked against a schema. |
| Components | React. | Its own .astro files, and React, Preact, Svelte, Vue or Solid beside them. |
| Releases | 16.4 on 6 October 2026. On version 16 since October 2025. | 7.3 on 3 September 2026. Two major versions in 2026: 6 in March, 7 in June. |
| Who is behind it | MIT licence. The copyright is Vercel’s. | MIT licence. Its team joined Cloudflare in January 2026. |
Two of those rows deserve a second look.
Hosting. Next.js needs no more than a Node.js server to do everything it does, and its documentation says so. What is short is the list of platforms with a verified adapter: Vercel and Bun as I write, with Cloudflare and Netlify building theirs. A static export runs anywhere, but it drops redirects, rewrites, Server Actions and the built-in image optimiser.
One cost to know before choosing Vercel for either: its free plan is for personal, non-commercial use. A company’s site starts on Pro, at $20 a month for each developer seat.
Releases. Upkeep is close to even, and it is not nothing in either. Astro shipped two major versions in 2026. Next.js stayed on 16, but 16.4 changed the recommended way to cache, and its notes say that becomes the default in 17. Whichever you choose, somebody has to own the upgrades.
Which one, when
| Your situation | What I would do |
|---|---|
| Pages of content with a few interactive parts. | Astro. It sends the pages as HTML and leaves JavaScript out until a component needs it. |
| The same, built by a React team. | Still Astro. Their React components run in it. |
| The site shares components, a deploy and a team with a product built in Next.js. | Next.js. A second framework would cost more than it saves. |
| Most pages change with who is looking. | Next.js. Mixing fixed and live content inside a page is what it is designed for. |
| Part of it is an application: accounts, a dashboard, tools that run on a server. | Next.js. Server code is part of the framework, not something added to it. |
| Nobody in house will maintain it. | Astro, on a static host. There is no server of its own to keep patched. |
| The people who change it every week are not developers. | Neither. Use a visual tool, and keep code for what needs it. |
This site is that fifth row. It runs on Next.js 16 because parts of it are an application: an assistant that answers questions, and tools that do their work on a server. Its pages alone would not have needed it.
What to do next
- Find your row in that table for the site you are building this quarter, not for the company you expect to be in three years.
- Ask whoever will maintain the site which of the two they already know. That outweighs most of the comparison.
- Decide where it will be hosted before the first commit, and check that host against the hosting row.
- If you are moving an existing site, map its addresses first. My migration planner does that and leaves you with a launch checklist.
- Put a number on it with the website cost estimator. It budgets in hours, so it treats both frameworks as custom code.
- After launch, run a page through the AEO check. It reads the HTML the server sends, without running scripts, and both frameworks should pass it.
I build in either one, and in Vue or plain React when a project calls for it. The framework is the smaller decision. The larger one is whether the site should be in code at all.