Astro vs WordPress for business sites: an engineer's honest comparison

For a brochure or marketing site that changes a few times a month, Astro produces a faster, cheaper-to-run and far smaller site than WordPress. It ships plain HTML with almost no JavaScript, there is no database to query, and nothing to patch every Tuesday. Our own migration took a factory site from 4.2 seconds to 0.8.

From 4.2s to 0.8s is what our own Astro migration achieved for a factory site, by removing the things the page was waiting for.

WordPress still wins when non-technical people publish daily, when you need a plugin ecosystem you would otherwise have to build, or when the site is really an application with a content section attached. That year on the rebuilt site organic traffic went up 5x, on zero ad spend.

5x organic traffic in the year after the rebuild, on zero ad spend, once search engines could actually crawl the site fast.

We build in Astro. We have also told clients to stay on WordPress, and this article is the rule we use to decide, written down so you can apply it without us.

What are Astro and WordPress, actually?

They are not competitors in the way the comparison implies.

WordPress is a content management system. It stores your pages in a database and assembles each one when a visitor asks for it. Everything else (the editor, the themes, the 60 000 plugins) hangs off that.

Astro is a site builder. It takes your content and templates and produces finished HTML files at build time. There is no server assembling anything on request, because everything was already assembled. Content can come from files in the repository or from a headless CMS, which is what you use when someone other than a developer has to edit it.

The honest framing is “generate the pages once, or generate them on every visit.”

Where does the speed difference come from?

Not from the language, and not from the hosting. From the amount of work left to do when a visitor arrives.

The last row matters more than it looks. On a static build, a mistake is caught at build time and never reaches a visitor. On WordPress, an auto-updated plugin can take a live site down at 3am while nobody is watching.

We rebuilt Fabrika Sumy, a textile factory founded in 1987, from a plugin-heavy site to Astro. Load time went from 4.2 s to 0.8 s, mostly by removing the things the page was waiting for.

The security difference, without the drama

A static site has no login form, no database and no plugin code running on a server, so the usual attack surface is absent. What remains is your hosting account and your domain registrar, both of which you should protect with two-factor authentication anyway.

WordPress can be secured. It just requires someone to keep doing it: updates, backups, a firewall, and a review of every plugin you install. That work is real, recurring, and usually nobody’s job after the site launches.

When is WordPress genuinely the right answer?

A studio that never recommends the alternative is just selling, so here is the plain list:

• Somebody publishes several times a week and is not a developer. WordPress’s editor, media library and revision history are mature, familiar and free. You can get the same with Astro plus a headless CMS, but that is another tool, another subscription and another login.
• You need a large plugin ecosystem now. Memberships, event booking, a forum, LMS courses. Rebuilding those is a project of its own.
• The team already knows it. An in-house marketer who is fast in WordPress may deliver more value than a 200 KB page would.
• WooCommerce is already running and profitable. Do not migrate a working shop for load-time points alone.

When is Astro clearly better?

• A marketing site that changes a few times a month. The common case, and the one where WordPress’s whole machine idles while you pay for it.
• Speed is a business metric on landing pages, ads, anything where bounce is measured in money.
• Multi-language and multi-domain. Routing, hreflang and canonicals live in code you write and control yourself.
• You want the site to still work in three years without maintenance. Static files do not rot.

The rule we actually use

Three questions, in this order:

1. Who edits the content, and how often? Daily, by someone non-technical → CMS, and probably WordPress. Monthly, or through us → Astro.
2. What does the site have to talk to? Nothing, or a form and analytics → Astro. A shop, a membership database, a booking system → check whether a plugin already solves it.
3. What happens if it breaks and nobody notices for a week? If the answer is “we lose business”, weigh the option that cannot break unattended.

There is no third question about which is more modern. That question has no business meaning.

What does migration actually involve?

If you do move, plan for these and nothing else surprises you:

• URLs stay identical, or every old address gets a 301 redirect. This is the one step that loses rankings when it is skipped.
• Content export. Usually straightforward, usually messier than expected, because a decade of pasted formatting comes with it.
• Forms need a destination. No PHP means no wp_mail; a form endpoint or a service takes its place.
• Whoever edits the site needs the new workflow before launch day.

For a normal brochure site, that takes a few weeks. The ranges are on our pricing page, and what we build in either direction is on the websites page.

If you are unsure which side of the rule you are on, the fastest way to find out is to say what your site does and who touches it. We will tell you which one we would pick, including when the answer is “stay where you are”.