For most business sites Astro 7 on Cloudflare is cheaper, faster and easier to secure than WordPress 7.0. That advantage has a price the previous version of this comparison never mentioned: the framework has its own release cadence, and somebody has to pay for it in developer time.
I wrote the first version of this comparison in April, against Astro 6 and a WordPress 7.0 still in release candidate. Both have shipped since, and we moved this site from Astro 6 to Astro 7. So I now have something I did not have then: an itemised bill for a major framework migration, run on our own corpus of well over ten thousand pages.
The platform recommendation has not changed. What changed is how much I know about the hidden costs on the Astro side.
WordPress 7.0, three months after release
WordPress 7.0 shipped on 20 May 2026. It is worth separating what was announced from what actually landed in the tarball.
AI Client and the Abilities API
AI Client is infrastructure, not a finished AI writer. WordPress 7.0 provides a unified API for talking to models, but it wants an external key and configuration before it does anything. The Abilities API lets agents discover and invoke WordPress functionality programmatically, which matters to plugin authors and is essentially invisible to an editor.
It is an important foundation. It is not a feature a client will notice in the admin on day one.
Real-time collaboration did not ship
Simultaneous editing was the loudest promise attached to this release and it was pulled after technical problems. Three months on it is still absent from the 7.0 line. Anyone who sold a client on WordPress 7.0 by promising multiple editors in one document has an awkward conversation ahead.
The architecture underneath did not move
The refreshed admin and the new blocks are a visual step forward. Underneath there is still PHP, MySQL and a conventional server that has to be patched, cached and watched. None of the 7.0 additions change the fact that every plugin widens the attack surface, or that performance needs an aggressive caching layer to arrive.
WordPress 7.0, the trade
What it gives you:
- The best content editor for non-technical people, with no real competition in that category
- A plugin ecosystem counted in tens of thousands
- WooCommerce as a complete commerce platform
- The Abilities API as groundwork for agent integrations
What it costs you:
- Core weight and overhead you cannot switch off
- An attack surface that grows with every plugin
- Hosting, backups, monitoring and security plugin budgets
- Performance that only arrives after a caching and CDN layer
- Security releases every few weeks
Astro 7 and what actually changed since version 6
Astro 7.0.0 shipped on 22 June 2026, 104 days after Astro 6.0.0. Three changes carry consequences you will not see in the changelog until you run your own build.
The Rust compiler stopped being an experiment
In Astro 6 the Rust compiler was an opt-in experiment. Astro 7 swaps the @astrojs/compiler dependency for @astrojs/compiler-rs and makes it the default. Builds get faster. The parser also gets stricter.
We broke on exactly one line. An HTML comment written inside a JSX expression, roughly {import.meta.env.DEV && ( <!-- ... --> )}, passed the old compiler and is rejected by the new one. The fix is a JavaScript comment instead. A minute of work, provided you know what you are looking for, because the error points at a position in compiled output rather than in your source.
Vite 8 underneath
Astro 6 sat on Vite 7. Astro 7 moves to Vite 8, the Rolldown-based line. For most projects this is invisible, but on large corpora it is worth watching build memory, because the allocation profile differs from before.
CSP hashing of inline styles, and why it bites
This is the change that cost us a full day.
Astro 7 computes hashes for <style> sheets embedded in the page and adds them to the style-src directive. Per the Content Security Policy spec, the presence of any hash in a directive voids 'unsafe-inline'. The result: every dynamic style="" attribute stops working. For us that took out Shiki token colours in code blocks, theme variables, animation speeds and background images. The home page alone produced 26 CSP violations, and every syntax-highlighted page was affected.
There is no switch to turn the hashing off. 'unsafe-hashes' alone does not fix it either, because it covers style attributes but not the bodies of <style> elements.
The solution turned out simpler than it looked, because the set of inline styles is finite. Across roughly 260,000 occurrences in the whole corpus there were 143 distinct values. Harvest them once, list the hashes in the config, add 'unsafe-hashes' for the attribute case, and violations drop to zero across every template type.
That leaves a standing obligation. Any new component that introduces a new inline style value either joins the list or gets silently blocked in production. This needs a CI gate, otherwise you learn about it from a user report.
A new default markdown pipeline
Astro 7 changes how markdown is processed by default. If you run your own remark and rehype chain, you have to pull in @astrojs/markdown-remark explicitly to keep the existing behaviour. It is a one-line dependency change, but missing it produces a quiet rendering difference rather than a build error, which makes it easy to ship by accident.
What the Astro 6 to 7 migration actually cost us
Numbers from our own rollout, not from the docs.
| Item | Result |
|---|---|
| Files changed | 5 |
| Lines of template source changed | 1 |
| Headline breaking changes that applied to us | 1 of 4 |
| CSP violations before the fix, home page alone | 26 |
| Distinct inline style values to hash | 143 |
| Pages in the preview build after migration | 15,850, exit code 0 |
| Unit tests | 103 of 103 |
| Typecheck errors | 0 |
Three of the four headline breaking changes did not apply to us, and that is the whole point. We have no Astro DB, no server adapter to move and we build statically, so the server entrypoint reorganisation passed us by. A project running SSR with an adapter and an Astro database faces a completely different bill for the same migration.
The practical lesson: the cost of a major Astro release does not scale with the size of your site. It scales with how many points of contact you have with the runtime. Our fourteen thousand plus pages cost less than one application with Astro DB and a custom adapter would have.
Head to head in 2026
| Trait | WordPress 7.0 | Astro 7 + Cloudflare | Winner |
|---|---|---|---|
| Load time | 1.5 to 4 s | under 500 ms, typically 200 to 300 ms | Astro |
| Annual hosting cost | Several hundred euros | Zero to low double digits | Astro |
| Security | Wide attack surface | Static HTML plus islands | Astro |
| Content editing | Block editor, no real rival | Good, Content Collections plus a CMS | WordPress |
| Core Web Vitals | Good after tuning | 100/100 almost always | Astro |
| Scalability | Moderate, needs caching | Very high, served from the edge | Astro |
| Plugin ecosystem | Tens of thousands | npm and Cloudflare integrations | WordPress |
| E-commerce | WooCommerce | No native equivalent | WordPress |
| Learning curve | Easy for content, hard for code | Moderate | Tie |
| Infrastructure maintenance | High | Minimal | Astro |
| Keeping up with the framework | Low, majors are rare | Real, majors every few months | WordPress |
Score: Astro 7, WordPress 3, one tie.
WordPress took back a point in this edition, and not through a new feature. It took it on release cadence. A WordPress site from three years ago still builds, because there is no build. An Astro site from three years ago is two majors behind and someone has to carry it forward.
When to migrate in 2026, an eight-point checklist
Migration makes sense when you meet at least five of eight:
- A content site, blog or landing page, which is exactly what Astro was built for
- PageSpeed below 80 despite WordPress tuning, which means an architectural problem rather than a configuration one
- Hosting costs above roughly two hundred euros a month
- Recurring security incidents, plugin patching, brute force attempts
- A development team that knows JavaScript and TypeScript and will still be around to carry out the next major upgrade
- No need for WooCommerce or a heavy logged-in user area
- SEO is a priority and Core Web Vitals move your positions
- The site serves several countries and global TTFB matters
Point five is wider than it was in the April version of this list, deliberately so. Knowing JavaScript on launch day is not the requirement. The requirement is knowing who runs npm update nine months later.
Three or fewer: stay on WordPress. Four: consider a hybrid. Five or more: migration pays.
Case study, before and after
Corporate site, Warsaw client
Before: WordPress with Elementor, PageSpeed in the red on mobile, load time measured in seconds, a standing monthly hosting line.
After: Astro on Cloudflare Pages, PageSpeed in the green, load time well under a second, static hosting on the free tier.
Net effect: the hosting cost line disappeared and Core Web Vitals went from red to green on the main templates. That same site later went through the Astro 6 to 7 migration under our maintenance and the client noticed nothing beyond one deploy.
wppoland.com, this site
More than fourteen thousand prerendered pages across six languages, of which roughly three thousand appear in sitemaps as content meant for indexing. The rest is a city by service fan-out carrying noindex. Hosting on the Cloudflare free tier. The same site previously ran on WordPress with paid monthly hosting.
Migrating that corpus from 6 to 7 was five files and one day of work, nearly all of it Content Security Policy.
Vendor risk, and what the Cloudflare acquisition actually changes
This is the question that comes up in English-language RFPs and almost never in a technical review: who owns the framework now, and what happens if their interests stop matching yours.
Astro is owned by Cloudflare. The honest reading of the 7.0 release is that this has so far produced neutral engineering rather than lock-in. The Rust compiler and Vite 8 are upstream improvements that benefit every deployment target. The adapter interface still exists and Astro still builds to static output that any host can serve. Nothing in this release makes a non-Cloudflare deployment harder.
What it does change is the shape of the risk you are underwriting. Before the acquisition, the risk was that a community project runs out of maintainer energy. Now it is that a commercial owner reprioritises. Those are different risks, and the second one is the one procurement teams know how to write clauses about.
Two practical mitigations that cost nothing at build time. First, keep the output static wherever the page does not genuinely need a server, because static HTML is portable to any host on any notice. Second, keep the CMS layer separate, because a headless WordPress backend does not care what renders it. Both are good architecture regardless of who owns Astro, which is the main reason to do them.
We cover the full cost model behind that separation in the headless versus monolith TCO guide.
How a WordPress to Astro migration runs in practice
Step 1, audit the WordPress site
Count custom post types, list plugins with what each one actually does, map the templates. This determines the complexity of everything after it.
Step 2, export the content
WP CLI or the REST API to pull posts, pages and media into markdown or JSON. Most of this automates.
Step 3, build the Astro templates
Rebuild layouts and components in .astro syntax. Tailwind CSS behaves identically. Most WordPress templates have direct equivalents.
Step 4, Content Collections
Define content types with Zod validation. The equivalent of custom post types, except the typing catches the error at build time rather than in production.
Step 5, hosting and DNS
Cloudflare Pages, connected to the Git repository, domain configured. Builds fire on every push.
Step 6, one-to-one redirects
Map every old URL to its new path. This is the step where rankings die when it is done casually.
Step 7, testing and GSC submission
A full crawl, Lighthouse runs on every template type, a new sitemap in Google Search Console.
Step 8, thirty days of monitoring
Track positions, indexing and Core Web Vitals through the first month.
I would add a ninth step today: write down which Astro version you shipped and what to check at the next major. A runbook written on migration day takes an hour. Reconstructing that knowledge six months later takes a day.
The hybrid, WordPress plus Astro
You do not have to pick one. The hybrid looks like this:
- WordPress as a headless CMS, the admin panel for content
- Astro as the frontend, generating static pages from WordPress data
- WPGraphQL or the REST API as the bridge
- Cloudflare Pages hosting the frontend
Editors keep the interface they know, visitors get a static page, developers get a modern stack.
The hidden cost I did not write about in April
Astro 6.0.0 shipped on 10 March 2026. Astro 7.0.0 shipped on 22 June. By the end of August the 7.x line had reached 7.2.8. That is a cadence WordPress has never had.
For us it is acceptable, because we maintain our own stack and have CI gates that catch drift before it reaches production. For a client who received a site and then disappeared for two years, it is a different story. The site keeps working, because static HTML does not stop working. But adding anything after two years means jumping two majors at once, and that is considerably harder than two migrations taken in sequence.
So the honest version of the recommendation reads like this. Astro wins on performance, infrastructure cost and security. WordPress wins on being safe to leave alone for longer. If the maintenance budget has no line for technical reviews, that second property is worth more than the table suggests.
Energy footprint and CSRD reporting
Among clients inside the EU sustainability reporting regime, the energy footprint of a website has started appearing in tender questionnaires. It is worth separating what can be evidenced from what merely sounds good in a proposal.
The mechanism is real and easy to explain to an auditor. Every dynamic page view in WordPress starts a PHP-FPM process and a set of MySQL queries, so the view consumes CPU cycles in a data centre. A static page comes out of an edge cache and, on a normal cache hit, engages no application process at all. The direction of the difference is not in dispute.
The number is. We do not hand clients a percentage reduction in energy use, because we have not measured one, and the figures circulating in vendor material have no published methodology behind them. If a specific number has to go into a report, it has to come from the host’s own data for the period, not from a comparison of architectures.
Practical advice: take what your provider actually publishes about its infrastructure and energy mix, and cite it as their statement rather than your measurement. Moving to a static architecture is an argument about resource consumption, not an environmental certificate.
My forecast for 2026 and 2027
WordPress stays dominant for WooCommerce stores, sites with non-technical editorial teams, projects built on off-the-shelf plugins, and companies that need to launch fast and cheap.
Astro with Cloudflare takes content sites and performance-driven blogs, corporate sites and landing pages, technical documentation, and multilingual sites with global reach.
My April estimate put static frameworks at 30 to 40 percent of content-driven sites currently on WordPress by the end of 2027. I stand by it, with the caveat above attached: that migration only pays where the frontend is budgeted as software.
Summary
WordPress 7.0 is a solid release that does not change the platform’s foundations. Astro 7 is mostly work under the bonnet rather than new user-facing features: the Rust compiler as default, Vite 8, and a stricter CSP.
Building an online store: WordPress. Building a corporate site, blog or landing page where performance and SEO matter: Astro 7 with Cloudflare. Building both: consider the hybrid.
If you are not sure, get in touch. If Astro is the right call for your project, there is more on the Astro developer page.
Mariusz Szatkowski, WordPress and Astro developer. WordCamp Gdynia organiser, WordPress Core contributor. Builds on both platforms for clients across Poland and Europe.
