The question is not which technology is best, but which one matches the way your site is going to live. A site you feed every week and a presentation site that sits unchanged for three years do not have the same needs, and the worst choice is the one made in imitation of somebody else. What follows is a comparison of Astro and WordPress across seven concrete criteria, with a verdict per profile rather than a single winner. We work with both foundations, which spares us having to defend one against the other.
What Astro is, in three sentences
Astro is a tool that assembles pages in advance and sends the browser only what is strictly needed. By default it strips all the JavaScript out of interface components: the visitor receives HTML and CSS, nothing more. When an element genuinely needs to be interactive, a carousel or a filter for instance, you declare it explicitly with a directive and it alone carries any code.
---
import Carousel from "../components/Carousel.jsx";
---
<Carousel client:visible />This is the islands principle: client:load loads straight away, client:idle waits for the browser to catch its breath, client:visible waits for the element to come into view. Server islands, declared with server:defer, go further and let the page appear at once while the parts that are expensive to compute arrive afterwards.
Let us also say what Astro is not: it is not a ready-made admin interface. You have to attach a content source to it, without which your client will not be able to change anything on their own. Version 6, released on March 10, 2026, asks for Node 22 as a minimum and adds native font handling and content collections loaded on demand; the documentation also exists in French.
What WordPress does better, honestly
Let us start there, because we would rather say it ourselves than leave you to find it out later.
- Editorial independence, from day one. Your client publishes an article, changes a photo, corrects a price, without calling anyone. No modern foundation matches it on that ground without extra work.
- The ecosystem. Forms, bookings, memberships, multilingual, commerce: the component already exists, tested by millions of installations.
- Mature online commerce. Stock, taxes, carriers, invoices, refunds. Rebuilding that elsewhere costs months.
- Skills available everywhere. If your provider disappears, you find somebody else within a week. That is a continuity criterion, not a detail.
- The cost of entry. A solid brochure site goes live quickly, on standard shared hosting.
Version 7.0 came out on May 20, 2026 and the project is still by a wide margin the most widely deployed on the web. For a great many brochure sites it remains quite simply the right choice, as we already wrote when we covered turnkey WordPress.
What Astro really brings
Four advantages, only one of which is a question of speed.
Performance by design. A pre-generated page runs neither PHP nor a database query at the moment of the visit: it is already written. You do not stack three caching plugins to make up for a heavy foundation, because there is nothing to make up for. The contrast is sharp with the causes set out in why a website is slow, and with the effect of page speed on your customers.
A reduced attack surface. A site served as static files has no public admin, no exposed database, no third-party plugin running code. Very nearly all the automated attacks aimed at WordPress simply have nothing to aim at.
Simple, light hosting. Serving files costs a fraction of the resources of an application server, which runs directly into our approach to sustainable design and the sparing use of resources.
A longer technical life. No plugin debt to keep watch on, no PHP version catching up with you. Dependencies do get updated, but they are few and visible in a single file.
The seven decision criteria
| Criterion | Leans toward | Why |
|---|---|---|
| Who publishes, and how often | WordPress if the client publishes alone every week | The admin is usable straight away, with no technical chain |
| Selling online | WordPress as soon as there is stock and customer accounts | Full commerce calls for a mature application layer |
| Personalized areas, accounts | WordPress, or a custom build | A pre-generated page is by nature identical for everyone |
| Demands on performance and frugality | Astro, clearly | The HTML is produced once, not on every visit |
| Skills available | WordPress | The pool is incomparably wider in France |
| Intended life before a redesign | Astro beyond five years | Fewer dependencies, so less wear |
| Acceptable upkeep load | Depends on the kind, not the volume | Watching plugins on one side, dependencies and a build chain on the other |
The third way: keep the admin, change the front
The decoupled approach consists of keeping WordPress and changing the front: the admin stays the place where the writing happens, invisible to the public, and the public pages are generated with Astro. The client keeps the interface they know, visitors receive static pages, and the admin is no longer exposed on the web.
The benefit is real and so is the cost: you now maintain two systems plus the chain that links them, and a new question appears, that of the delay between publishing an article and its actually going live, which depends on rebuild time. On a 300 page site it is a matter of seconds; on a catalog of 20,000 records it calls for partial rebuilds and some method. This route is justified when editorial independence and performance are both non negotiable, and only then.
What it changes for upkeep
No foundation does away with upkeep: it changes the nature of it, and that is the point we want to put honest figures on.
| Recurring load | WordPress | Astro |
|---|---|---|
| Updates | Core, theme and plugins, often several times a month | Dependencies, a few times a year |
| Security | Active monitoring, firewall, accounts to manage | Marginal on a static site |
| PHP version | To keep an eye on: the 8.2 branch will receive no more fixes after the end of 2026 | Not applicable, though Node runs its own cycle |
| Changing content | On your own | On your own only if a content source was planned for |
| Changing structure | Often possible without a developer | Goes through a developer and a deployment |
One figure to anchor the idea: on a properly built WordPress brochure site, monthly upkeep comes to one to two hours of real work on average, tested updates and verified backups included. On an equivalent Astro site it is closer to two to three hours a year, but every change of structure calls on a developer. The totals come nearer to each other than people think; they are simply spread out differently. Our plans for a website with hosting and upkeep start at €59/month (VAT not applicable, article 293 B of the French tax code), with a registration fee when the account opens.
Our position
It holds in three sentences, and we stand by it even when it has us selling the less impressive project.
WordPress for sites that live by their content and by their owner’s independence: a site that publishes, that sells, that the client wants to steer alone. Astro for demanding presentation sites, where performance, frugality and length of life count for more than daily editing: brand sites, institutional sites, documentation, landing pages under heavy traffic. The decoupled approach for projects that want both and accept paying for the complexity, which assumes an upkeep budget genuinely set aside.
We publish our own Astro themes, as it happens, seven finished foundations with their demos online: it is the shortest way to see what a finished Astro site looks like, rather than read it described.
A word on a signal many people missed: Cloudflare acquired the Astro team in January 2026, undertaking to keep the project open source. That strengthens its durability and its integration with delivery networks, a subject we take up in our article on speeding up and protecting a site with Cloudflare. It changes nothing in the decision grid above: technical frugality is a criterion for choosing, not a sales argument, and the best foundation is still the one you will be able to keep alive.
Frequently asked questions
Is Astro suitable for a shop?
For a small catalog and a payment page handled elsewhere, yes, and the result is very fast. For full commerce with stock, promotions, customer accounts and invoicing, WordPress with WooCommerce or a dedicated solution remains the reasonable choice.
Can I edit my own text with Astro?
Only if the project includes a content source you can administer, whether a decoupled content system or WordPress in the background. Without that, every comma goes through a developer. It is a choice to settle at the scoping stage, not afterwards.
Does an Astro site rank better?
Not mechanically. It starts with an advantage in performance and clean HTML served first time, which removes a whole family of technical problems. Content, structure and reputation do the rest, exactly as anywhere else.
Can a WordPress site be migrated to Astro?
Yes, and the operation is a common one. The difficulty is not technical but methodical: keeping every existing address, laying down an exhaustive redirect plan and working out how the client will publish afterwards.
Let us refuse the single verdict. The right foundation is the one that matches the way your company will keep its site alive, and that answer is not to be found in a performance benchmark: it is found by answering the seven criteria above honestly. Take thirty minutes to work through them before you commit to anything, on your own or with us.
Also worth reading: Git and GitHub: why your website deserves a history
