You Built an App. You Needed a Website

Open the last three sites you worked on. View source – the raw response, not the elements panel – and search for the first sentence a visitor actually reads.

On at least one of them it won't be there. A shell, a root div, a stack of script tags.

Those sites usually have a second symptom. Changing a paragraph takes three weeks.

Headless CMS. Framework front end. Nobody in marketing can publish a sentence without a developer, a pull request and a deploy.

Two symptoms, one cause.

The site isn't broken. It's overbuilt. And you pay for it three times – in what machines can read, what users wait for, and what your team can no longer change.

The machines stopped being patient before the users did

We argued about JavaScript rendering for a decade and always landed in the same place. Google renders it, so ship the SPA.

That argument expired.

Vercel and MERJ measured what AI crawlers actually do. GPTBot and ClaudeBot both download JavaScript files. Neither executes a single one.

Downloading isn't rendering. They fetch the raw HTML, take what's in it, and leave.

No second pass. No coming back tomorrow the way Googlebot does.

So a page can hold position two in Google and be a blank div to every AI engine that isn't riding on Google's or Bing's infrastructure.

The rendering debate was always about one crawler. That crawler stopped being the only one that matters.

The cost is in the payload

That's the machines. The people are paying too.

A content page on a static generator ships almost no JavaScript. The same page on a React meta-framework ships the runtime, the router and the hydration payload first. Roughly 80 to 100 KB gzipped, to display text that was already in the HTML.

You paid twice to render the same paragraph.

For a checkout or a dashboard, that cost buys something. For a blog, a docs site or a category page, it buys nothing.

The third bill arrives every week

The last cost shows up in the calendar.

Framework front end, headless CMS, and every content change is a deployment. A pricing correction waits for a developer. A landing page waits for a sprint.

The people who own the words don't own the publishing.

So pages stop getting fixed. Not by decision – a small edit just costs more than it's worth.

Then the tree underneath. Dependencies to upgrade, majors that break, advisories that don't wait for your roadmap. A brochure site on a two-year-old Node stack carries known vulnerabilities in packages nobody chose, pulled in three levels deep by a carousel.

Security patches stop landing for the same reason typos do. Every change costs a deploy.

Hugo and Eleventy, not the fashionable one

Three costs, one fix. If the page is a document, generate it at build time and serve HTML.

Astro tops most framework comparisons and it's fair if your team wants React components on content pages. Most content pages don't need components.

Hugo builds ten thousand pages in seconds. Single Go binary, no Node dependency, no npm tree to maintain for five years. Go templates are the price.

Eleventy is the pick if your team lives in JavaScript. Slower at scale, simpler to reason about, ships no client framework by default.

And you don't have to give up React for it. Through a JSX plugin your team writes components as usual, Eleventy renders them to HTML at build time, and nothing ships to the browser.

Neither is new. What changed is the setup cost – a weekend of templates and config is now an afternoon with an AI assistant.

Static output gets you the floor. There's no runtime in production – no database, no plugin to patch at midnight, no server-side code to exploit. Whatever dependencies remain sit in your build, not on the public internet.

Sort out hosting and images and you've got most of the rest.

The catch, in two parts

Next.js in a default setup doesn't get you most of this. A static export gives you server-rendered HTML, which fixes the crawler problem. It doesn't remove the React runtime or the hydration step. You solved visibility and kept the weight. I keep hearing "we're static, we're on Next" as though those are one sentence.

Nothing stops the bloat returning. A lean static page with a tag manager, a consent banner, a chat widget and three tracking scripts performs like everything else. The generator controls what you ship, not what marketing adds later.

So what should you actually use

Most people asking which framework should be picking a platform instead.

What follows is what I'd pick, not a rule. The right answer depends on the team and what they're selling. But after enough audits the same few cases keep turning up.

A small or mid-size store? Shopify. It owns the parts you don't want to – payments, inventory, checkout – and its templates behave better on Core Web Vitals than most custom builds. Resist the headless rebuild unless you have a team to run it for five years.

Publishing a lot, with editors who work without developers? WordPress. Unfashionable and still right – keep the plugin count low and cache properly.

Everything else? Hugo or Eleventy. Marketing sites, documentation, product pages, programmatic content – generate them and ship almost no JavaScript. That's most of the web, and most of what gets overbuilt.

Genuinely building an app? Then build an app. Next.js exists for checkout flows, dashboards and authenticated state, and it's good at them. The mistake isn't using it. It's using it for a blog.

And if a rebuild isn't on the table – most enterprise sites – server-render or statically generate the templates carrying commercial information, and leave the interactive parts client-side. Same HTML for everyone.

A partial fix on the templates that earn money beats a full rebuild nobody approves.

The question to ask first

Does the important content exist in the raw HTML? Does anything on the page need client-side state that survives a page load? Can someone who doesn't write code publish a change today?

Most teams can't answer the first without checking, which tells you how much of this was ever decided.

The industry spent ten years making websites behave like applications. Users got slower pages. Machines got pages they can't read. The people who own the content stopped being able to change it.

A website that needs a browser to explain itself was overbuilt. You pay for that three times over.