Next.js is a framework for building websites with React, and it exists because React on its own is not enough to build one. React gives you components: reusable pieces of interface that update when their data changes. It does not give you pages, URLs, data loading or a way to produce HTML on a server. React's own docs say that if you start without a framework, you end up "building your own adhoc framework": you must pick a router, a data-fetching library, a code-splitting strategy, and later build server rendering yourself. Next.js makes those choices for you. It maps files to URLs, loads data, splits the JavaScript into chunks, and renders React on a server as well as in the browser. It is "a React framework for building full-stack web applications", maintained by Vercel, which also sells hosting for it.
Its closest competitor for a normal website is Astro. Both frameworks turn components into pages. They disagree about what a page is for. Astro's docs call it "the web framework for building content-driven websites like blogs, marketing, and e-commerce" and draw the line themselves: frameworks like Next.js, SvelteKit, Nuxt and Remix "were built for client-side rendering of your entire website and include server-side rendering mainly to address performance concerns." Astro's approach is the reverse. It renders every component to HTML and CSS, ships zero JavaScript by default, and adds a JavaScript "island" only around a component you mark as interactive. Astro also accepts React components, so the choice is not React or no React. It is: should the whole page be an application, or should the page be HTML with a few live parts?
Both frameworks solve two real problems for developers. The first is organisation. A site with fifty pages that share a header, a footer and a card design needs components, and a plain HTML folder makes you copy the header fifty times. The second is data. A blog with a hundred posts in Markdown, or a shop with products in a database, needs a build step that turns that data into pages. Both frameworks do both. The difference is what they assume you will do next.
So, do you need Next.js to publish a website?
If your pages are built out of React components, yes, you need Next.js or something like it. React's docs are clear about this. Once React is rendering your whole page, "we recommend migrating to a React framework right after to get the most out of React." The framework is the part that turns a folder of components into URLs, finished HTML and a site a host can serve.
But the question hides an assumption: that a website is built out of React components. It does not have to be. A browser reads three things, HTML, CSS and JavaScript, and it never sees React. React is a JavaScript library that produces HTML, either in the browser or on a server. The output is the same kind of HTML you could write by hand or generate from a template.
React's own docs make this point for you. The page on adding React to an existing project starts with: "If you want to add some interactivity to your existing project, you don't have to rewrite it in React." It describes rendering a React component inside one <nav> tag on a page built with something else, and adds: "That's a common way to integrate React. In fact, it's how most React usage looked at Meta for many years!" The page came first. React was added to one part of it.
So the chain of needs runs in one direction. A webpage does not need React. React, once it takes over the page, needs a framework. The framework, for its best features, needs a server. Every link is a choice. The first one is the one most people skip, because the tool they opened, or the AI they asked, had already made it.
Every claim below links to a page by Next.js, React, Astro, Vercel or HTTP Archive. No third-party opinions.
Three places a page can be built
A browser understands three things: HTML for structure, CSS for style, JavaScript for behaviour. Every framework ends up producing those three. The technical question underneath this whole post is where and when the HTML gets made. There are three answers.
At build time. A program runs once, on your machine or a build server, and writes out finished HTML files. The host hands them out unchanged. This is static site generation, SSG. Next.js calls it a static export. Astro calls it its default. The HTML is the same for every visitor until you build again.
On the server, per request. A program runs all the time. When a visitor asks for a page, it builds the HTML at that moment, so the page can contain things the build could not know: who is logged in, what is in the cart, today's price. This is server-side rendering, SSR. It needs a server process running Node.js, and someone to keep that process alive and patched.
In the browser. The server sends a nearly empty HTML file and a large JavaScript bundle. The JavaScript runs on the visitor's device and builds the page there. This is the single-page application, SPA. When a framework first sends HTML from the server and then attaches JavaScript to it in the browser so it becomes interactive, that step is called hydration. Astro's docs describe the SPA model as "a heavy-handed choice for most projects on the web today." React's docs now recommend a framework partly to avoid it.
Next.js can do all three. Its deploying guide lists the options: a Node.js server or Docker container supports "All" features, a static export supports "Limited" features. To get everything, the platform guide is direct: "To run Next.js, your platform needs a Node.js server."
Which parts of Next.js need the server
Next.js documents this itself: its static export guide lists every feature that stops working without a server. Here they are in plain words:
- Cookies. The site cannot read who the visitor is when it builds the page, so it cannot build a page for one logged-in person.
- Redirects, rewrites and headers set in Next.js. The web server has to handle these instead. The same guide shows how to do it in Nginx, a plain web server.
- Server Actions. Forms and buttons that save data straight to your server. A form on a static site sends its data somewhere else.
- Incremental Static Regeneration (ISR). Pages that rebuild themselves in the background, on a timer or on request. Without it, a content change means you build and publish again. The rendering philosophy page says it plainly: "every content change requires a rebuild and redeploy."
- Image optimization with the default loader. Next.js resizes images on the server when a visitor asks for them. Without a server you need an outside image service, or images you size before you publish.
- Draft Mode. A preview of unpublished CMS content on the live site.
- Proxy, also called Middleware. Code that runs before every request, often to check a login.
Read the list again. Every item is about one of two things: a visitor who is different from the last one, or content that changes between publishes. A page that is the same for everyone, and changes when you publish, needs none of it.
What Next.js really gives you
The main idea behind Next.js is on a page called Rendering philosophy. Most frameworks decide per page: a page is built at build time, or it is built per request. Next.js decides per component. "A single page can have a static shell that loads instantly and dynamic sections that stream in as they resolve."
Picture a shop page. The product photo and description are the same for everyone and come from the build. The price, the stock count and "Hi, Anna" are rendered on the server for this one request and stream into the page a moment later. One page, two sources.
Astro has a version of the same idea, called server islands, and says it "does not depend on any server infrastructure." Next.js goes further and is more explicit about the bill. The same rendering page names the cost, in one sentence worth reading twice:
"A finer-grained rendering boundary transfers complexity from application code into the hosting platform."
In plain words: the code gets simpler for the developer, and the server gets harder to run. The self-hosting guide shows what "harder" means once a site runs on more than one server:
- A shared cache, such as Redis, so every server shows the same version of a page.
- One shared encryption key, or forms fail with "Failed to find Server Action" errors.
- A deployment ID, so a visitor does not get files from an old version in the middle of an update.
- A proxy such as Nginx set up not to hold back streamed responses. If it does, the "loads instantly" part stops working.
None of this is a flaw. It is the price of the feature, and Next.js is open about it. The question is whether your site uses the feature.
The cost nobody puts in the quote: patching a server
A static file does not run. A server does, and code that runs can be attacked.
In July 2026, Next.js moved to a monthly security release program. Its reason: "The volume of vulnerability research across the industry is rising fast, driven by LLM-assisted discovery." AI now finds bugs faster, for defenders and for attackers.
This is the Next.js security calendar since then:
| Date | Release | What it fixed |
|---|---|---|
| July 2026 | Scheduled | 4 high and 5 medium severity issues |
| 25 August 2026 | Scheduled, moved forward | Two critical: code execution through image optimization of AVIF files, and on Windows servers |
| 22 September 2026 | Unscheduled | A critical issue in an upstream dependency |
| 30 September 2026 | Scheduled | Two fixes held back to October |
| 14 October 2026 | Unscheduled | Two critical: code execution through use cache and through SVG image optimization. One high: denial of service through Server Actions |
"Remote code execution" means this: a stranger on the internet, with no login, can make your server run their code. It is the worst class of bug a server can have.
Before the program started, in December 2025, the React team disclosed React2Shell, CVE-2025-55182. It scored 10.0, the maximum on the CVSS scale, and it affected Next.js. The advisory includes this line:
"If your app's React code does not use a server, your app is not affected."
An earlier flaw, CVE-2025-29927, let attackers skip login checks in Middleware. In its postmortem, Vercel ruled out one group first: "Static exports were immediately ruled out due to Middleware not being available without a server runtime."
A patch also needs a version that still gets it. Under the support policy, each major version gets security fixes for two years after release. Next.js 14 came out in October 2023 and is now unsupported, except in rare cases. A site built on the newest Next.js three years ago needs a major upgrade to stay safe.
Who does that work on your client's site, every month? If the answer is "nobody", you have your answer about the server too.
AI search reads HTML, not JavaScript
Vercel, the company behind Next.js, studied how AI crawlers read the web, together with the agency MERJ. The finding: "none of the major AI crawlers currently render JavaScript." That covers OpenAI's crawlers for ChatGPT, Anthropic's ClaudeBot, Meta's crawler and PerplexityBot. They download JavaScript files but do not run them. Google's Gemini and AppleBot are the exceptions, because they render pages like a browser.
Vercel's advice is to put important content in the HTML: "SSR, ISR, and SSG keep your content accessible to all crawlers." SSG, static site generation, is the plain-files approach. Next.js can deliver that HTML too. But the finding shows what a crawler needs, and it is not a framework. It is HTML that is there when the page arrives. A static page has that by default.
The numbers across the whole web make the point sharper. The HTTP Archive Web Almanac 2025 measured the median mobile home page at 632 KB of JavaScript and 22 KB of HTML. The text a crawler reads is the smallest part of the page. And as the Almanac puts it, "100 KB of JavaScript is work": the phone must parse and run it before the page responds.
When to use Next.js: a five-question test
If you answer yes to one or more of these, Next.js, or a tool like it, earns its server:
- Does the page change for each visitor? Logged-in areas, carts, customer prices, dashboards.
- Do visitors write data? Accounts, comments, orders, anything more than a contact form.
- Must content update on its own, between publishes? Live stock, prices from a database, thousands of pages that change every hour.
- Must it feel like an app? Next.js 16.3 added Instant Navigations, tools for "single-page-app responsiveness."
- Does your team already write React every day? Then the framework is your shared language, and that has value.
If all five answers are no, you do not need Next.js. A company site, a portfolio, a studio site, a blog, documentation and most landing pages land here. Their HTML can be built once, before anyone visits, and rebuilt when someone publishes.
What a site without a server needs
Files, and a place to put them. HTML for the content, CSS for the design, a little JavaScript for a menu or a slider, and a host that hands them out. No Node.js process, no shared cache, and no monthly security calendar of your own to follow.
This is how Splitleaf publishes. You design in the Designer, edit in Content, and publish plain HTML, CSS and JavaScript to a host you choose. The files are yours, in your own Git repository. If a client later needs logged-in accounts or live prices, that is the moment to bring in a framework like Next.js, for that part of the project.
For the bigger question of what frameworks are for now that agents write the code, read Now that agents write all code, what is the job of the JS frameworks?
Already have a Next.js site? Export it to plain files
If a site was built in Next.js and fails the five-question test, you do not have to rebuild it. Next.js's static export guide shows how to turn it into plain HTML, CSS and JavaScript:
- In
next.config.js, setoutput: 'export'. - Run
next build. - Next.js writes an
outfolder with one HTML file per page, plus the CSS and JavaScript they use. The guide's words: it "can be deployed and hosted on any web server that can serve HTML/CSS/JS static assets."
That out folder is a complete static site. Zip it and import it into Splitleaf, and the pages open in the Designer as ordinary HTML. From then on the site is files you own, with no Node.js server, no framework version to keep patched and no rebuild step between an edit and a publish. The React team describes the same route for sites that cannot or do not want to run JavaScript on a server: "serve the HTML/CSS/JS export."
Questions people ask
Is Next.js bad for SEO?
No. Next.js can send finished HTML to search engines and AI crawlers. Vercel's own advice is to server-render or pre-build important content. The risk is content that only appears after JavaScript runs, in any framework.
Do I need React to build a website?
No, and most websites gain nothing from it. React solves one problem: keeping many parts of a screen in sync while the data behind them changes, as in an inbox, a dashboard or an editor. A company site has a menu, some sections, maybe a slider and a contact form. Nothing on the page changes after it loads, so there is no state to keep in sync. HTML gives you the structure, CSS the design, and a few lines of plain JavaScript open the menu. Astro's docs describe what you avoid by skipping React in the browser: "hooks (React), stale closures (also React)" and the rest, because "there is no reactivity on the server, so all of that complexity melts away." You take on React's model when the interface needs it, not before.
What Astro gives you, if you still want a framework, is the two things that make frameworks useful on a content site without the React tax: components and a build step. Shared headers and footers, pages generated from Markdown or a database, and HTML with zero JavaScript by default. If one part of a page does need React, Astro renders that one component as an island and leaves the rest as HTML.
Can I use React without Next.js?
Yes. React's docs describe rendering a component into one element on a page built with anything else, and say that is how most React usage looked at Meta for years. You need a build tool such as Vite to compile it. You need a framework only when React runs the whole page.
Can I host a Next.js site on GitHub Pages?
Yes, as a static export. Next.js keeps a GitHub Pages template for it. You lose the server features listed above.
Does a static site have to be rebuilt for every change?
Yes. Next.js's rendering guide says it directly: "every content change requires a rebuild and redeploy." When your tool publishes in one step, that rebuild is the publish button.
Does a static site need security updates?
The host keeps its own servers patched, as with any site. Your site's files do not run code on a server, so the server-side flaws in this post do not apply to them. React's advisory says the same about React2Shell: no server, not affected.