Compare
WordPress vs Astro
The decision depends on what the team needs to publish and maintain. Keep the editorial workflow and plugins that are doing useful work; consider a different front end when maintenance and custom development are getting in the way.
- Price
- From $5,000
- Timeline
- Typically 4–6 weeks
- Included
- 30 days of hypercare
- Code
- In your name
Output
Migration trace
Sample run
northwind.example
- 01 Read the Webflow site
- 02 Map pages, CMS fields and redirects
- 03 Draft an Astro pull request
Pull request
The NewBase Stack
Astro, Sanity and Cloudflare. Sample only. This page does not open a pull request.
Site check
Not live
Not run on the sample
This trace is a sample of a migration. The site check has not run. Paste a Webflow URL and only this pane can go live.
- Platform
- Checked address
- Sitemap entries
- Mobile performance
Reasons
Move to Astro, The NewBase Stack, when
-
The plugin list has become the architecture, and nobody chose most of it.
-
The weekly job is updating the site rather than publishing to it.
-
You are paying for caching to undo work the platform is doing per request.
Differences
Four things that change when the site becomes a codebase.
-
Security
The public attack surface gets much smaller
WordPress PHP a database an admin login the public web
Astro Files a CDN
A traditional WordPress site exposes PHP, a database-backed application and an admin login to the public web. A statically rendered Astro front end takes those out of the request path.
That is not maintenance-free and not invulnerable: dependencies, hosting, DNS and third-party services still have to be looked after. There is simply far less application infrastructure answering every request, and it is the difference people notice first in the year after the move.
-
Plugins
The plugin list becomes a list of decisions
WordPress Plugin another plugin a plugin to fix those two forty
Astro Keep replace drop
Forms, redirects, SEO fields, galleries, popups and caching were each a plugin, and each is now kept, replaced with a service, or dropped because nobody has used it since 2022.
That audit is the migration. A site with four plugins is a short job and one with forty is a scoping exercise before it is a rebuild.
-
Performance
Speed stops being something you buy
WordPress Render per request a caching plugin a CDN an optimizer
Astro Build once ship the page
A WordPress site can be extremely fast. Dynamic rendering, plugins and page builders add work that then gets managed with a caching plugin, then a CDN, then an optimizer to fix what the first two broke.
A statically rendered page starts from a simpler model: build it before the visitor asks, then ship only what that page needs. The plugins bought to make the old one fast come out with everything else.
-
Content model
Custom post types get a model instead of a convention
WordPress Custom post type a plugin UI fields in another table
Astro Schema typed fields a build that fails on a missing one
A custom post type is a shape somebody defined in PHP or in a plugin UI, with fields in a separate table nobody documented.
Moving forces the model to be designed and typed, so a missing field fails a build instead of rendering an empty page nobody notices for a month.
Compare
Capability by capability.
| What is being compared | WordPress | Astro |
|---|---|---|
| Where the features come from | WordPress Plugins, including ones chosen years ago by somebody who left | Astro Written once, or a service the site talks to on purpose This is the row that decides most WordPress migrations. A site with four plugins is a short job. A site with forty is an audit before it is a rebuild, because each one is a decision somebody has to make again. |
| Themes and the design layer | WordPress A theme, a child theme, and often a page builder on top of both | Astro Components, with no theme underneath them Three layers of inheritance become one layer of markup. It is the part of a WordPress migration that looks like a redesign and is not one. |
| What you patch | WordPress Core, plugins, PHP, and the server they run on | Astro Dependencies, on your own schedule, with no admin login or database in front of them A statically built site removes the login page, the database and the request-time runtime, which is a real reduction in what is exposed. What it does not remove is the dependencies in the build, the host, the DNS and every third-party script on the page. Fewer things to patch, not nothing. |
| Publishing at volume | WordPress Multiple authors, scheduling, revisions and editorial states, built in | Astro Whatever the CMS you choose provides, and nothing by default WordPress is very good at this. If a newsroom runs on it, that is a reason to stay, or to keep WordPress headless and let Astro render the front end. |
| Extending it | WordPress Anything, if somebody writes PHP | Astro Anything, if somebody builds it. Static work happens at build time and dynamic routes run on demand where the project needs them |
Questions
WordPress and Astro, answered.
Is Astro better than WordPress?
It depends on what WordPress is doing for the site. For a site that is mostly read rather than transacted, Astro removes a large amount of runtime and maintenance infrastructure. For a site with several authors, a mature editorial workflow, or a plugin doing genuinely difficult work, WordPress may already be earning its complexity.
Can I keep WordPress as the CMS?
Yes, and it is often the best half-step. The front end becomes Astro and WordPress stays as a headless CMS behind it, so the editorial workflow survives untouched while the public site stops being a server. It is also reversible in a way a full move is not.
What happens to my plugins?
Each one becomes an explicit decision. Forms and SEO fields have direct equivalents, some plugins become a few lines of code, and some turn out to be doing nothing. The ones without an answer are the ones that decide whether this project is worth doing, and they are found in week one rather than week five.
How long does a WordPress migration take?
Four to six weeks for a typical site, then 30 days of post-launch checks. The time rarely goes into the content: it goes into the URL archive, which includes category and tag archives, author pages, pagination and whatever permalink structure preceded the current one, and it is routinely larger than the site itself.
What about page builders like Elementor or Divi?
They are the expensive part. Builders store layout inside the post body as shortcodes and serialized markup, so the export contains it and the text has to be extracted from the layout rather than imported with it. Every page a builder touched is manual, and that is worth knowing before anybody quotes.
Let me plan your next step.
I can scope a migration. Send a brief and I will reply by email with next steps.