Insights Platform comparison

Astro vs WordPress for a Small Business Website: What Actually Matters

For a typical brochure or service website, Astro is faster, cheaper to run and easier for AI to read — Astro sites pass Google's Core Web Vitals about 60% of the time versus roughly 38% for WordPress. But if you need complex ecommerce, a membership system or daily hands-on editing without a developer, WordPress can still be the better call.

By Jason Sibley · Founder, Hello Foundry Published 2026-08-17 · 8 min read

The short answer

For a typical brochure or service website, Astro is faster, cheaper to run and easier for AI to read — Astro sites pass Google's Core Web Vitals about 60% of the time versus roughly 38% for WordPress. But if you need complex ecommerce, a membership system or daily hands-on editing without a developer, WordPress can still be the better call.

This isn't a "WordPress is bad" piece. It's an attempt to answer a genuinely practical question in plain English, without the developer jargon that usually surrounds it: for a small or growing business, does the technology a website is built on actually matter, and if so, why?

What Astro actually is, in plain English

Astro is a modern web framework — a set of tools developers use to build websites — designed around a simple idea: ship as little JavaScript to the browser as possible, by default. Most of a page is built and delivered as plain, static HTML, and only the parts that genuinely need to be interactive (a booking widget, a contact form with live validation, a search box) get JavaScript added back in, piece by piece. This approach is often called an "islands" architecture — small islands of interactivity in an otherwise static sea of HTML.

WordPress works differently. It's built to generate pages dynamically, and over the past two decades an enormous ecosystem of plugins and themes has grown up around it, many of which add their own JavaScript to a page for menus, sliders, forms, and effects — all of which the visitor's browser (or a crawler) has to load and process before the page is fully usable.

The practical difference for a small business owner: an Astro-built site tends to arrive in the browser (or in front of a crawler) mostly finished, whereas a JavaScript-heavy WordPress site often arrives as a skeleton that needs more work done before the real content shows up.

The Core Web Vitals and page-weight data

This isn't just a theoretical preference — it shows up in measured performance data. According to the HTTP Archive's Core Web Vitals Technology Report, which tracks real-world performance across the web using Chrome's own user data, Astro-built sites pass Google's Core Web Vitals thresholds around 60% of the time, compared with roughly 38–43% for WordPress sites, depending on the specific dataset and date measured. That's a meaningful gap — somewhere in the range of 16 to 22 percentage points, depending on exactly how it's measured.

Page weight tells a similar story: the median Astro-built page weighs around 1.65MB, against roughly 2.63MB for the median WordPress page, according to HTTP Archive data reported by Search Engine Journal. A lighter page loads faster, particularly on mobile connections — which matters directly for how a human visitor experiences the site, and indirectly for how Google ranks it.

One more detailed comparison is worth including, with an important caveat attached: a single documented migration case study found a site's Largest Contentful Paint time dropped from 0.81 seconds on WordPress to 0.44 seconds after rebuilding on Astro, alongside a 72% reduction in HTML size and a 60% reduction in JavaScript. That's a genuinely striking result — but it's one developer's case study for one specific site, not population-level data, and shouldn't be read as a guaranteed outcome for every migration.

It's also worth being straight about a fair criticism of Astro's headline numbers: some of that performance advantage may reflect that simpler sites tend to get built on Astro in the first place, rather than Astro being magically faster in every scenario. A well-built, carefully optimised WordPress site can absolutely clear Google's Core Web Vitals thresholds. The gap in the data is real and consistent, but it isn't an argument that WordPress is incapable of being fast — just that it requires more deliberate effort to get there.

Why static HTML matters for AI crawlers specifically

There's a second reason this technical choice matters beyond page speed, and it connects directly to how AI assistants find and cite businesses (covered in more depth in our companion piece on AI visibility). A large share of AI crawlers — an estimated 69%, according to a 2024 analysis by Vercel and MERJ covering more than 500 million requests from OpenAI's GPTBot — don't execute JavaScript at all. They read the raw HTML a server sends back, and nothing more.

Astro's default approach — delivering a page's real content as static HTML rather than something JavaScript has to build first — means that content is already there when a crawler arrives, whether that crawler is Googlebot, GPTBot, or something else. A JavaScript-heavy WordPress build, by contrast, may be delivering a mostly empty shell to any crawler that doesn't run scripts, regardless of how rich the page looks to a human visitor whose browser does run them.

Security as an architectural property, not a plugin

The Patchstack State of WordPress Security 2025 report found 7,966 new vulnerabilities disclosed across the WordPress ecosystem in 2024, 96% of them in plugins rather than WordPress core. That's the direct cost of the plugin-driven flexibility that makes WordPress so capable — every plugin is also a piece of software that can go wrong.

A static Astro site has no equivalent attack surface by default: no PHP interpreter processing requests, no database an attacker could query, no admin login page to target. That's not a claim that static sites are somehow unhackable — nothing is — but the category of vulnerability that generates the overwhelming majority of WordPress's security incidents simply doesn't apply to a site with no plugin ecosystem running server-side code.

Where WordPress is still the right call

To be direct about the honest counter-case, because a one-sided comparison isn't a useful one: WordPress remains the better choice in specific, real situations.

  • Complex or large ecommerce. WooCommerce's maturity handles large catalogues, complex inventory, and intricate checkout flows in ways that take considerably more custom engineering to replicate on a static-first framework.
  • Daily, hands-on self-editing. If your team wants to log in and constantly add pages, publish blog posts, and manage content without involving a developer, WordPress's familiar admin interface is a genuine advantage.
  • Existing plugin dependencies. A membership system, learning platform, or booking flow already built on specific WordPress plugins carries real switching costs — there's a legitimate case for staying put rather than rebuilding.

A reasonable rule of thumb: most simple business or brochure sites — service pages, portfolios, local business sites without complex ecommerce — don't need what WordPress's plugin ecosystem adds, and are better served by something lighter. The businesses that do need it tend to know it, because they're already using the specific functionality that only WordPress (or an equivalent platform like Shopify for ecommerce) provides well.

What migration actually involves

Moving a small WordPress site to Astro typically means exporting existing content into a structured format — Markdown or MDX files, or content pulled into a headless content management system — and rebuilding the page templates around it. Some things don't migrate cleanly: dynamic plugin functionality (booking systems, membership gating, complex forms), custom shortcodes, and anything relying on server-side PHP logic usually need to be rebuilt rather than transferred directly.

For non-technical editing after a migration, Astro pairs with several headless or Git-based content management options — Sanity, Decap, Keystatic, TinaCMS, and Storyblok are all established choices, each with different trade-offs in editing experience and setup complexity. For businesses that specifically want to keep the familiar WordPress admin screen for editing while making the public-facing site static and fast, a "headless WordPress" approach — where WordPress runs purely as a content backend and Astro builds the actual pages visitors see — is a workable middle path.

What to do next

If your current site is slow, JavaScript-heavy, or costing more in maintenance than it's worth, and your business fits the "simple brochure or service site" profile rather than the "needs WordPress's specific ecommerce or plugin capability" profile, moving to a static-first build is usually a straightforward decision once the trade-offs are clear. Hello Foundry builds — or migrates — small-business websites on Astro for free, with free hosting for life and no obligation to buy anything else.

Frequently asked questions

Is Astro always faster than WordPress?

On average, yes, based on real-world Core Web Vitals data — but not universally. A well-optimised WordPress site can perform well, and a poorly built Astro site can still be slow. The consistent advantage comes from Astro shipping less JavaScript by default, not from any guarantee.

Can a non-technical person edit an Astro website?

Yes, when it's paired with a suitable content management system. Options like Sanity, Decap, Keystatic, TinaCMS, or Storyblok give non-technical editors a familiar interface for updating content, without needing to touch code.

Is WordPress a bad choice for a small business?

No — it depends on what the business needs. WordPress remains the stronger choice for complex ecommerce, sites needing frequent hands-on self-editing, or businesses with existing deep plugin dependencies. For simpler brochure and service sites, a static-first framework like Astro typically offers better performance and lower running costs.

Because a large share of AI crawlers can't execute JavaScript. A static HTML site, like those Astro produces by default, delivers its real content in the initial page load that these crawlers read — whereas a JavaScript-heavy site may show those crawlers a mostly empty page.


Evidence sources used

The source notes supplied with this article identify the following evidence used in the draft.

  1. HTTP Archive Core Web Vitals Technology Report / CrUX, 2025–2026 — Astro ~60% vs WordPress ~38–43% CWV pass rate
  2. HTTP Archive via Search Engine Journal, 2026 — median page weight Astro 1.65MB vs WordPress 2.63MB
  3. mfyz.com developer case study — LCP 0.44s (Astro) vs 0.81s (WordPress); explicitly labelled as a single-site case study, not population data
  4. Vercel/MERJ, "The Rise of the AI Crawler," 2024 — ~69% of AI crawlers can't render JavaScript (cross-referenced to Pillar)
  5. Patchstack State of WordPress Security 2025 — 96% of WordPress vulnerabilities in plugins (cross-referenced to Cluster 2)

Free Website Programme

A properly branded small-business website. £0 build. £0 supported static hosting.

You buy and own the domain. Hello Foundry builds the agreed standard site, including SEO and AI-readable foundations, and hosts it for £0 while it remains on our supported static stack.