I build and maintain WordPress sites for a living, and I also move sites off WordPress onto Astro. That puts me in an odd position for this article: I have no interest in convincing you WordPress is bad. For a lot of businesses it’s still the right tool.
But if there’s no team of editors behind your site, it barely changes once it’s live, and you can’t justify the hosting and maintenance overhead for the couple of hours of updates you actually make, Astro is worth understanding. Here’s what a migration actually involves, and the decisions you’ll need to make before anyone writes code.
How Astro is different
WordPress builds your pages when someone asks for them. A visitor requests a page, PHP runs, the database is queried, and HTML comes back. Caching plugins exist to avoid doing that work on every request, which tells you something about the model.
Astro is a static site generator. It builds every page once, ahead of time, and the result is plain HTML files served from a CDN. There’s no server-side language running, no database, and by default no JavaScript sent to the browser at all. Interactive parts, like a search box or a booking widget, are added as isolated components only where you need them. Astro calls these islands.
Side by side, the two models look like this:
flowchart TB
subgraph wpp["WordPress — when you publish"]
direction TB
E1["You edit in wp-admin"] --> S1[("Saved to the database")]
end
subgraph wpv["WordPress — when someone visits"]
direction TB
V1["Visitor requests a page"] --> P["PHP runs"] --> DB[("Database queried")] --> T["Theme and plugins assemble HTML"] --> C1["Caching layer softens the repeat work"] --> R1["Page delivered"]
end
S1 ~~~ V1
flowchart TB subgraph asp["Astro — when you publish"] direction TB F["You edit content files in git"] --> B["Build runs once"] --> H["Static HTML and assets"] --> U["Uploaded to the CDN"] end subgraph asv["Astro — when someone visits"] direction TB V2["Visitor requests a page"] --> CDN["CDN serves the ready-made file"] --> R2["Page delivered"] end U ~~~ V2
The practical consequences are what matter. Pages are fast without a caching layer. There’s no admin login to attack and no plugin updates to run, so the security and maintenance story shrinks to almost nothing. Hosting becomes cheap, often a few pounds a month on a CDN.
What about the dynamic parts?
The trade-off: anything that changes per visitor, like a cart, a members’ area, or live availability, needs deliberate work rather than a plugin install. To be fair, that’s no harder in Astro than in any headless or API-driven setup. An island can be a React component talking to a third-party API, loaded only on the page that needs it, and something like a small ticketing widget works fine that way. Session management gets trickier, but it’s not impossible.
It’s a question of proportion. A couple of dynamic components on a content site is comfortable Astro territory. If you’re building something app-like, a dashboard, say, where most of the site is logged-in and interactive, you’re better off in Next.js or React from the start.
Most sites are less dynamic than they look
In practice, most small business sites have less of that than you’d think. Look at what’s actually interactive on the page and it’s usually the contact form. The rest of what feels dynamic, animations, a clever menu, is visual. There’s no data behind it.
Even the serious integrations rarely live in WordPress. Clients don’t run their CRM in WordPress, they use something like HubSpot or Salesforce, and the connection is an embedded snippet, an iframe, or at most a plugin that authenticates with the service. Those embeds work exactly the same on a static site.
Be honest about how often your site actually changes
WordPress earns its overhead when its machinery gets used: multiple editors, frequent publishing, a visual editing experience for people updating content every day. That’s what it’s built for.
Here’s what I actually see. I deliver a WordPress site, provide training, and for most clients the day-to-day reality is updating a bit of content on a page or publishing a blog post every now and then. Most small businesses aren’t publishing daily with a team of editors. Once the site is live, not much changes except the blog and the odd landing page.
The machinery keeps costing you either way. Plugin updates, security patches, user accounts, a database, hosting that can run PHP. It all needs looking after whether you edited the site this month or not.
And yes, WordPress is free and cheap hosting exists, so you can get a site up for almost nothing. But that route usually means an off-the-shelf theme, a page builder like Elementor, and a stack of plugins, and the bloat that comes with all of it. The site is slow, and the work to keep it updated and maintained never goes away.
That’s the calculation that has shifted for me. A couple of hours of edits every few months doesn’t justify a platform that needs care every week.
Astro is not the same as going headless
These two get muddled together, and they’re different decisions.
A headless setup keeps a CMS running as a content API, often WordPress itself, and puts a JavaScript front end in front of it, usually React through something like Next.js. You still have the CMS to host, secure, and update. You’ve also added a front-end application on top.
You can pay a cloud platform like Sanity or Contentful to run the CMS for you, and they’ll maintain it well. But it’s still a service that has to be online and available for your site to work, with a monthly bill attached. More overhead, more cost, and more cogs to think about.
The thing to notice is that headless WordPress doesn’t change the editing experience at all. You still log into the same admin and update pages the same way as on a normal install. So if your team barely edits the site, going headless gives you nothing: you’ve kept all the WordPress overhead and added a second system in front of it. It suits large editorial teams who live in the WordPress admin and need it to stay exactly as it is.
Astro’s default model is simpler. Your content lives in files in the same repository as the site, the build turns them into pages, and there’s nothing running in production except a CDN. For a marketing site, a portfolio, or a content site with a small team, that simplicity is the point.
You can use Astro headlessly against WordPress if there’s a genuine reason to keep the admin. It’s just not where I’d start for most small businesses.
Decide how you’ll edit content before anything else
This is the decision that shapes the whole project, and it’s the one people leave until last.
In WordPress, editing is built in. In Astro, editing is a choice. Content lives in markdown and data files, and the question is how non-developers change it. The options range from editing files directly, to Git-based CMS tools like Pages CMS or Keystatic that give you a friendly editing screen on top of the same files, to API-first platforms with monthly fees.
I’ve written up the options properly in Choosing a CMS for an Astro Website. The short version: for most small teams a Git-based CMS is the sweet spot. No subscription, no separate database, and your content stays in files you own. On WestEnd.com the team manages 50 or so shows and 40 venues through Pages CMS without touching code, and without a CMS bill.
Files beat a database for a small site
For a small site, content in files beats content in a database in ways you feel every month. Every change is version controlled, so you can see what changed, when, and roll it back. There’s no database to back up or fall out of sync. And the whole site, content included, moves between machines with a git clone.
If your editors need scheduled publishing, complex workflows, or dozens of concurrent users, that’s when the paid platforms earn a look.
Getting your content out of WordPress
How hard this is depends entirely on how your content was put in.
Clean WordPress content, posts and pages written in the block editor or classic editor, comes out well through the REST API or an XML export. A migration script can pull titles, body content, dates, categories, and featured images into markdown files fairly directly.
Page-builder content is the trap. Elementor, Avada, WPBakery, and Divi store your copy inside their own shortcodes and blocks, so what the API returns is builder markup, not your actual words. When we migrated WestEnd.com off Avada, we had to scrape the rendered pages to recover the real text. Budget for this if your site was built with a page builder, and treat it as a chance to clean up as you go.
If you have access to the hosting, WP-CLI makes this much easier. It can take full backups, export the database, and run queries directly against the content, which is often quicker than going through the API. You can supercharge the extraction further by having an AI tool write and run the migration scripts with you. Be careful with that, though: work from a cloned backup rather than the live site, and keep an eye on what it’s doing so it doesn’t go off the rails.
The media library needs its own plan. You’ll want the images your content actually uses, moved into the repository or object storage, with URLs rewritten. It’s mechanical work, but skipping it leaves you hotlinking a WordPress install you’re trying to switch off.
Mapping custom post types to content collections
If your site uses custom post types, this part is genuinely satisfying.
In WordPress, everything lives in the database. Custom post types all follow the same storage format, and even copy that never changes gets pulled from the database on every page, because you’d never hardcode it into the theme. For a content site, that’s a whole layer you’re forced to think about without getting much back from it.
Astro’s answer is files. Content collections: folders of content with a schema that defines what fields each entry must have. A WordPress custom post type maps onto a collection almost one to one. Your ACF fields become frontmatter fields, your taxonomies become properties you can filter on, and the schema is checked at build time. If an entry is missing a required field, the build fails and tells you, rather than the page quietly rendering wrong.
On WestEnd.com, shows and venues became two collections. A show is a record with ticketing details, a venue reference, cast, and images. Templates render the records. Compared with a custom post type held together by ACF and template parts, it’s the same idea with the guesswork removed.
The mapping exercise is worth doing on paper before the build: list your post types, their fields, and their relationships, and sketch the collections they’ll become. It usually takes an afternoon and it surfaces every awkward decision early.
The things WordPress gives you that you’ll have to replace
A stock WordPress install with a decent SEO plugin quietly does a lot. None of it is hard to replicate in Astro, but every piece is a deliberate choice rather than a default, and a migration checklist should name them all.
The usual list looks like this:
- Metadata and schema. Yoast or Rank Math handled titles, descriptions, Open Graph tags, and structured data. In Astro these come from your layouts and frontmatter, which means they end up more consistent, but someone has to build them.
- XML sitemap. The official
@astrojs/sitemapintegration generates one at build time. - Redirects. Every URL that changes needs a 301, and old URLs search engines know about need mapping to new routes. This is the single biggest factor in whether you keep your rankings, and it deserves a spreadsheet, not an afterthought. There’s a catch on a static site too: there’s no Apache layer processing redirect rules any more. Astro can define redirects, but it handles them by loading a page that then forwards you on, which isn’t a clean 301. The better place is the host, on bunny.net that’s an edge rule, and every host does this slightly differently.
- RSS feeds. There’s an official Astro package if your readers use them.
- Forms. WordPress form plugins post to the database. A static site needs a form endpoint, either a small serverless function or a service. The same applies to search, which becomes either a build-time index or a hosted service.
- Comments. I’d be surprised if you actually use WordPress comments. The only time I see them on a site is when nobody turned them off, and then they’re full of spam. If discussion genuinely matters to you, build it properly with a forum as a fully fledged part of the website rather than a comments box under each post.
The tooling is smaller than you’re used to, on purpose
The WordPress instinct is to reach for a plugin. Astro has integrations, but the honest answer is you need far fewer of them, because the platform isn’t fighting you. Astro has its own way of doing things, but it’s intuitive to pick up, and ideas like content collections are built into how it expects you to work rather than bolted on.
The ones that come up on nearly every project: the sitemap integration, MDX if you want components inside content, Tailwind for styling, and Astro’s built-in image handling, which resizes and converts images at build time and does the job several WordPress performance plugins are sold to do. Deployment is a pipeline that builds the site and pushes it to a CDN. On WestEnd.com that’s automated, so a content edit in the CMS goes live without anyone thinking about it.
What you won’t find is an ecosystem of ten thousand plugins. I’d call that a feature. Less to install means less to update, less to break, and less to audit when something goes wrong.
Should you migrate at all?
Sometimes the answer is no, and it’s better to know before you spend money.
E-commerce is the clearest case. WooCommerce is still my default for shops because so much is pre-built: products, carts, checkout, payments, emails, refunds. Astro has no equivalent ecosystem. You could build a shop on it against a headless commerce API, but I don’t think it’s the best tool for that job.
Membership sites and anything where logged-in users generate the content are in the same category, or at least need a much more careful conversation. The same goes for teams whose whole workflow lives in the WordPress admin and who have no appetite to change it.
The sites that gain the most are content and marketing sites where speed, security, and hosting costs matter more than dynamic features. If most of your plugins exist to make WordPress faster or safer, that’s the tell.
Put it this way. If a client told me they’d probably update the site every three months and write the odd blog post in between, I’d be hesitant to recommend WordPress for that now. All the maintenance and overhead, for a couple of hours of actual editing a quarter, is hard to justify when a trimmed-down static site does the same job faster and with less to go wrong.
If you’re weighing it up, the WestEnd.com case study shows what the finished thing looks like in practice, and the Astro development page covers how I approach these projects. And if your site is one of the ones that should stay on WordPress, I’ll say so. I look after WordPress sites every day, so I’ve nothing to sell you either way.