Astro vs Next.js: Which to Pick for SEO and Speed

Astro vs Next.js comes down to one question. Is your site mostly pages people read, or an app people use? Astro is built for the first. Next.js is built for the second.

We run both sides of that choice. contextbolt.com, the home of ContextBolt, is an Astro site of about 650 pages. Our Context Board app is React. So on October 19, 2026, we built the same page in Astro and in Next.js and measured what each one sends to the browser.

The result is the clearest way to see the difference, and it matters for SEO in ways most comparisons get wrong.

Astro vs Next.js at a glance

The rest of this post explains the rows that matter.

We built the same page in both

The test is simple on purpose. One page, a heading and three paragraphs of plain text. No buttons, no forms, nothing interactive. Anything the browser downloads beyond the HTML is the framework’s own weight.

The Astro version is one file:

---
// src/pages/index.astro (Astro 7.4.1)
---
<html lang="en">
  <head><meta charset="utf-8" /><title>Test</title></head>
  <body>
    <h1>Astro vs Next.js test page</h1>
    <p>This page is plain text...</p>
  </body>
</html>

The Next.js version is the smallest App Router site there is, a layout and a page, both server components, built as a static export:

// app/page.js (Next.js 16.4.2, output: 'export')
export default function Page() {
  return (
    <>
      <h1>Astro vs Next.js test page</h1>
      <p>This page is plain text...</p>
    </>
  );
}

Then we built both and counted every script the page loads in a modern browser.

Astro 7.4.1    HTML 371 bytes   scripts: 0
Next.js 16.4.2 HTML 5.0 KB      scripts: 5 files
               about 130 KB compressed, about 446 KB unpacked
               plus 3.8 KB of inline page data

To count, we added up every file on the page’s script tags. We left out one more Next.js file, about 110 KB of polyfills, because it is marked noModule and modern browsers skip it. Our own site is on Astro 6. The test used the current release of each framework.

To be fair to Next.js, that JavaScript is not waste. It is React itself, plus the router that makes clicking between pages feel instant. On an app, you need all of it and more. On an article, it is weight the reader pays for and never uses.

A real site only widens the gap. A real Next.js site adds its own client components on top of that runtime. A real Astro site adds only the islands you choose. Our 650-page site has chosen none, so every page still sends no framework JavaScript.

What it means for SEO

Here is where most comparisons go wrong. They say Google struggles with Next.js because it is JavaScript. It does not.

Both send real HTML: Next.js renders pages on the server or at build time, so the words are in the HTML before any script runs. Google reads that directly, and so do AI crawlers that never run JavaScript. Vercel’s December 2024 study found none of the major ones did. A Next.js site only hides content when you fetch it in the browser after the page loads. That is a choice, not a default.

Page weight is the real difference: Google calls Core Web Vitals, its loading and responsiveness scores, part of what “our core ranking systems seek to reward,” and it recommends “good Core Web Vitals for success with Search.” Less JavaScript means less work for the phone before the page responds. Astro starts at zero. Next.js starts at the React runtime and you work down from there.

Next.js has more SEO plumbing built in: This is a point for Next.js. It has a metadata API for titles and descriptions, and special sitemap.ts and robots.ts files. Astro needs you to write a head component and add the sitemap integration. Neither is hard, and we show the Astro version in our Astro SEO setup.

Watch the sitemap dates: The Next.js sitemap docs set lastModified: new Date() on every URL in their example. Copy that and every page claims it changed today, on every build. Google’s sitemap guide says it only uses lastmod when it is “consistently and verifiably” accurate. Use each page’s real edit date in either framework.

Redirects depend on how you deploy: On a server, Next.js redirects with permanent: true send a 308, which Google treats as permanent, the same as a 301. But the static export docs list redirects, headers, image optimization and timed regeneration as unsupported. Astro’s static build turns redirects into meta refresh pages. Either way, a static site should put its redirects in the host’s file.

Images need a plan in both: Next.js resizes images with next/image, but on a static export the default loader is on that unsupported list, so you need another image service. Astro’s Image component resizes images at build time, so a static Astro site gets sized, lighter images with no server. Images are often the largest thing on a page, so this one matters for loading scores.

When Next.js is the better pick

Choose Next.js when the site is really an app.

• People log in. Accounts, settings, anything behind a password.
• The screen changes a lot. Dashboards, editors, carts, live data.
• You need the server per request. Personalized pages, server actions, forms that write to a database.
• Huge catalogs that change. Next.js can rebuild a page on a timer instead of rebuilding the whole site.
• Your team already lives in React. That counts for a lot.

Our Context Board app is React for exactly these reasons. It is an app people sign in to and drag things around in. We did not build it in Astro, and we would not.

When Astro is the better pick

Choose Astro when the site is mostly read.

• Blogs, docs and marketing sites. Pages that look the same for everyone.
• Speed without effort. Zero JavaScript is the default, not a goal you tune toward.
• Content in files. Astro’s content collections turn a folder of Markdown into typed pages. Our blog is a folder of .mdx files, and a post with a missing or malformed field fails the build before it can ship.
• You still want React here and there. The official React integration drops a React component into an Astro page as an island. Only that component loads JavaScript.

contextbolt.com is the example. About 650 pages, no React, no Vue, and every interactive piece is a small plain script. Astro has been the right call for a site that is all words.

Who owns each one

Next.js is made by Vercel. It runs best on Vercel, and it also runs on your own Node server and on other hosts, Cloudflare included.

Astro changed hands this year. On January 16, 2026, Cloudflare announced that the team behind Astro was joining it. Astro’s own announcement says the framework stays open source and keeps supporting other hosts. Astro still deploys to Netlify, Vercel or any static host. Ours runs on Cloudflare Pages.

So both frameworks now have a hosting company behind them. Neither locks you in, but each works smoothest on its owner’s platform.

Moving a Next.js site to Astro

If your Next.js site turned out to be mostly content, the move is smaller than it looks. Most pieces have a direct match.

Watch the trailing slash: Next.js removes it by default. Its trailingSlash docs say /about/ redirects to /about. Astro’s default build writes /about/index.html, which Cloudflare Pages serves at /about/. Move without thinking and every URL on the site changes. Set build.format: 'file' in Astro to keep /about, the same fix we use in Framer to Astro.

Keep React where it earns its place: A pricing calculator or a signup form can stay a React component inside an Astro page, loading only its own script. Everything around it becomes plain HTML.

Snapshot rankings first: Same rule as any move. Save what ranks before you change a line, keep every URL or redirect it with a 301, and compare after four weeks.

What we would pick, site by site

• Marketing site for a SaaS product: Astro. It is pages people read, and speed helps every visit.
• Docs: Astro. Its official docs theme, Starlight, handles navigation and search out of the box.
• Blog or content site: Astro, with posts as Markdown files in a content collection.
• The SaaS app itself: Next.js or plain React. People sign in, and the screen changes all the time.
• A shop: It depends. A small catalog fits Astro with a hosted checkout. A big catalog with accounts and personalized pages fits Next.js.

You can use both

This is the answer for a lot of teams. Build the marketing site and blog in Astro, where pages are light and rank. Build the product in Next.js or React, where people log in. Link between them.

That is our setup. The site you are reading is Astro. The app is React. Each does the job it is built for, and neither carries the other’s weight.

If you are moving an existing site, the SEO steps are the same whichever framework you leave. Framer to Astro walks through them, and Astro vs WordPress covers the other common move.

Check rankings from the same window

Whichever you pick, the site will probably be built in an AI coding tool. ContextBolt SEO is the SEO toolkit we build for that. It runs inside Claude Code over MCP and brings keyword data, the results page for any search, page audits and your own Search Console into the window where the code lives.

Copy this prompt

This repo is my site. Pull my Search Console pages for the last
28 days and find the five with the most impressions but a click
rate under 2%. Open each page's file here, tell me what framework
renders it, and suggest a better title and description. Show me
the changes before you edit anything.

Search Console calls are free. Keyword and results-page checks cost one credit each, and your research saves to your private SEO Dashboard on its own. It is $35 a month after a 7-day free trial with 100 credits.