Astro vs Next.js vs WordPress for a small business in 2026

We get asked this comparison on almost every discovery call. The answer is rarely “the framework you’ve heard of.” It depends on what your site actually has to do.

Here’s how we think about it when we’re quoting a project.

The honest one-line summary

• WordPress: a great answer when the site is mostly content and the budget is small.
• Astro: the best answer when the site is mostly content and you care about performance, longevity, and ranking.
• Next.js: the right answer when the site has to log users in, save data, take payments, or otherwise behave like a product.

Most small business sites are in the middle bucket. That’s why we default to Astro for marketing sites and reach for Next.js when the work is genuinely a web application.

WordPress: when the budget is the constraint

WordPress runs about 40.7% of the public web, and 58.9% of sites whose CMS is identifiable (W3Techs, checked August 22, 2026), because it’s hard to beat on price and ecosystem. A decent theme, a managed host, and a few well-chosen plugins gets a working site for under $1,000 if you assemble it yourself.

The cost shows up later:

• Plugins drift. Every plugin is a third-party dependency that needs updates, and the more plugins you stack, the more brittle the site gets. Count is not the only variable, though: what matters more is reach. A gallery plugin sees images. A translation, caching, SEO, or personalisation plugin sees every string your site produces and every query it runs, which is why a bug in one of those is routinely a critical rather than a nuisance. In August 2026 a translation plugin on 400,000 sites was found writing administrator password reset links into a table it serves to unauthenticated visitors. Know which of your plugins are the broad ones and patch those on a short clock.
• Performance ceiling. Even with caching, a typical WordPress site lands in the 40-70 range on mobile Lighthouse Performance, and roughly 6 in 10 WordPress sites fail Core Web Vitals according to HTTP Archive / CrUX data. INP issues are particularly common.
• Security surface. WordPress sites are a perennial target for credential-stuffing and plugin-vulnerability attacks. Updates have to happen on a schedule, not when you feel like it.

Correction, August 22, 2026. The security bullet above was too narrow, and the sentence after it made the mistake explicit by tying the maintenance cost to keeping plugins patched. In July 2026, the wp2shell chain turned two flaws in WordPress core into unauthenticated remote code execution on a default install with no plugins involved at all. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on July 21 and gave US federal agencies three days to fix one of them. So the correct framing is: WordPress has a fixed maintenance floor that does not shrink as you remove plugins, because the core REST API is itself an unauthenticated public attack surface. In practice that floor is “somebody must be able to apply a core security release within about a day, including on a Friday in July.” The auto-update system does this for free when it is enabled, which is why the single most important WordPress maintenance question is whether automatic updates are actually switched on. Our overall recommendation below is unchanged; the cost estimate attached to it is not.

When we recommend WordPress: the client has under $5k, content is the primary deliverable, they have someone (themselves or an agency) who will keep plugins patched, and core auto-updates are enabled and verified rather than assumed.

When we don’t: anything that needs custom interaction, anything where Core Web Vitals matter for ranking, anything where downtime hurts revenue.

Astro: the editorial / marketing-site default

Astro ships HTML by default and only sends JavaScript when you ask for it. That’s the entire architectural pitch and it’s a big one for marketing sites. A typical Astro site lands at 95+ Lighthouse Performance without effort.

What you get vs. WordPress:

• Faster pages out of the box. We’ve never built an Astro site that needed to be optimized after launch. They’re fast at the start and stay fast.
• No plugin drift. Dependencies are explicit in package.json and you choose when to update.
• Better SEO and AI-search visibility. Static HTML is what crawlers want, and the small JS payload helps INP.
• Markdown content, version-controlled in Git. Editors who are comfortable with Notion or Markdown do fine; editors who insist on a WYSIWYG block editor will need a headless CMS in front (Sanity, Storyblok, Decap), which adds setup cost.

Where Astro doesn’t fit: anything with logged-in users, server-side state that changes per visitor, or a real product surface. You can bolt those things on, but at that point Next.js is a more honest choice.

This site (aurabyt.com) is built on Astro. So is most of our marketing-site work.

Next.js: when the site is actually an app

Next.js is the right default when the site has to do things, not just show things. Auth, dashboards, billing, real-time data, server-side personalization, complex forms: all of these become easier with a full React framework that has server components, server actions, middleware, and route handlers.

What you give up vs. Astro:

• Bigger JS bundle. Even with React Server Components, a Next.js page ships more JavaScript than an Astro page. INP tends to be slightly higher, though React Compiler (stable in Next.js 16) has narrowed the gap with reported INP improvements of 15-30% on the same code.
• More moving parts. The mental model is bigger. Every page can be static, server-rendered, or client-rendered, and the choice matters.
• More expensive hosting at scale. You’re paying for serverless function execution, not just CDN bandwidth.

When we reach for Next.js: SaaS products, booking systems, customer portals, anything where the site itself is the product. TruBites (subscriptions + nutrition tracking + customer accounts) is on Next.js. Stattraq (a calculator with persistent state) is on Next.js. FairSlice (multi-user expense splitting) is on Next.js.

The pattern: if the site has more than a contact form, Next.js usually wins.

One thing worth saying about this whole comparison, because it is easy to miss: these three stacks differ enormously at the top and converge hard at the bottom. Astro and Next.js both process images through the same sharp package, which reaches the same C libraries underneath. In August 2026 a critical heap overflow in one of those libraries, libheif, produced an emergency Next.js release and left every Astro, Nuxt and Docusaurus site running the identical vulnerable code with no advisory of their own. We wrote up the dependency chain and the check that finds it. Choosing a framework is a real decision; it is not a decision about which C libraries you depend on.

What we actually recommend

A rough decision tree we use on discovery calls:

1. Will real people log in? → Next.js.
2. Does the site take payments or save user data? → Next.js.
3. Is the site mostly pages of content (services, about, blog, portfolio)? → Astro.
4. Does the client want to edit content themselves with a WYSIWYG? → Astro + a headless CMS, or WordPress if budget is tight.
5. Is the budget under $3k and the client will maintain it themselves? → WordPress with a clean theme.

There is no universal best framework. There is a best framework for what you’re trying to ship and who’s going to maintain it after launch.

What we don’t recommend in 2026

A few framings we hear that we tell clients to avoid:

• “Next.js so we can scale to millions of users.” You don’t have millions of users. You have to find your first hundred customers. The framework is not the bottleneck.
• “WordPress because everyone uses it.” Popularity is not an architecture argument. The right question is whether your specific site fits WordPress’s strengths.
• “Whatever’s cheapest.” The cheapest site to build is rarely the cheapest site to own. A $500 template you have to redo in 18 months is more expensive than a $4,000 build you keep for 5 years.

If you want a real conversation about which one your project should use, email us. We’ll tell you what fits, including the answer “you don’t need us, here’s a template you can buy.”