WordPress to Astro: the migration guide

A WordPress site we audited last year was running 31 plugins. Four of them existed purely to make the site faster: a caching plugin, a minifier, a lazy-loader and a CDN connector. Four pieces of software whose entire job was to compensate for the other twenty-seven. The owner was paying a maintenance retainer, mostly so someone would click "update" once a month and hold their breath.

The site itself? A homepage, nine service pages, and about sixty blog posts. No logins, no accounts, no cart. Static content, dressed up as an application.

That's the shape of most WordPress sites we see, and it's the shape Astro was built for. If your site is content, this is the migration we'd point you at by default. We've written up the broader decision, including the paths we'd pick when Astro isn't the answer, in our guide to migrating off WordPress in 2026. This article is the Astro path in detail.

Why Astro suits an ex-WordPress site

Astro's core idea is aggressively boring: ship HTML, not JavaScript. Your pages are rendered to plain HTML at build time, and by default no JavaScript goes to the browser at all. Zero. A blog post that would load 400KB of scripts on a typical WordPress theme arrives as text and images, because that's what a blog post is.

When you do need something interactive, a search box, an image carousel, a booking widget, Astro uses what it calls islands: that one component loads its JavaScript, and the rest of the page stays inert HTML. It's the inverse of the WordPress model, where every plugin dumps its scripts on every page and you install a fifth plugin to clean up after the first four.

The other piece that matters for ex-WordPress people is content collections. Your posts become Markdown or MDX files in a folder, with frontmatter for title, date, categories and so on, and Astro type-checks the lot. A post missing its publish date fails the build instead of silently breaking your archive page. Coming from a MySQL database you can't easily inspect, having your entire content library be readable files in a git repo is the single biggest quality-of-life change. Every edit has a history. Nothing gets eaten by a failed plugin update.

The performance gap, measured

You don't have to take a framework's word for any of this. The HTTP Archive Core Web Vitals Technology Report tracks real Chrome user data by platform, and the gap is not subtle. In Search Engine Journal's analysis of the January to April 2026 data, 67% of Astro sites passed all three Core Web Vitals, against roughly 49% of WordPress sites.

Two honest caveats. First, that's correlation: a carefully tuned WordPress site can pass, and plenty do. The numbers describe what each platform does in ordinary hands, which is exactly what you should care about, because ordinary hands is what most sites get. Second, WordPress's weak spot is loading speed specifically, which is the thing you feel on a phone on a spotty connection, and the thing that half of one percent of caching-plugin configurations actually fixes.

We'd add one more from experience: the WordPress sites that pass tend to pass because someone is paying attention every month. Astro sites pass by default and keep passing when everyone stops looking. That difference compounds.

Getting your content out

There are two export routes, and which one you use matters less than people think.

The traditional one is WXR, the XML file WordPress produces from Tools, then Export in the admin. Every post, page, category, tag and comment in one file. Plenty of converters turn it into Markdown.

The route we prefer is the WordPress REST API. Every WordPress site since 4.7 exposes its posts as JSON at /wp-json/wp/v2/posts, no plugin required. A short script pages through that endpoint, converts the rendered HTML of each post to Markdown, and writes one file per post with the frontmatter filled in from the same response: title, slug, date, categories, tags. We like it because you can rerun it. The content team keeps publishing on the old site while you build the new one, and you pull a fresh copy the day before launch instead of freezing content for six weeks. Astro's own docs cover the WordPress migration path if you want the official version.

The parts that actually take the time:

Images. Your media library lives in wp-content/uploads, and your exported posts are full of absolute URLs pointing at it. Crawl them, download them, rewrite the references. Do not leave the new site hotlinking images from a WordPress install you're about to switch off. This is tedious, scriptable, and skipped more often than you'd believe.

Taxonomies. Categories and tags come across as frontmatter arrays, which is the easy half. The hard half is that WordPress generated an archive page for every category, tag, author and date, and Google has spent years indexing them. List them before you decide what survives.

Shortcodes and page builders. If the content is clean prose, conversion is nearly free. If it's ten years of Elementor sections and [shortcode] soup, the markup is the project. Budget accordingly, and be suspicious of anyone who quotes you a migration without asking to see a few representative posts first.

The redirect map still decides everything

Nothing about Astro exempts you from the one rule of replatforming: every old URL either keeps working or 301s to its successor. WordPress URL structures rarely match what you'll want in Astro, ?p=123 links, /2019/06/slug/ date permalinks, category archives, so somebody has to write the map, old address by old address, before launch. Google's documentation on site moves with URL changes is the canonical reference, we've written about why rebuilds lose rankings and how not to, and our migration checklist walks the whole sequence. We won't repeat it all here. Just don't skip it; it's the difference between a migration and an accident.

What hosting costs afterwards

An Astro site builds to static files, and static files are the cheapest thing on the internet to serve.

Our default is Cloudflare Workers, where requests for static assets are free and unlimited on every plan. The free tier includes 100,000 dynamic requests a day, which a content site barely touches, and the paid plan is US$5 a month if you outgrow it. Netlify's free tier covers a similar site comfortably if you'd rather be there.

Compare the bill you're leaving. WP Engine's Australian pricing starts at A$42 a month for one small site, on annual billing, with a first-year discount. That's the going rate for managed WordPress, and it's fair, because keeping WordPress fast and patched genuinely is ongoing work. The Astro version of that work doesn't exist, so the bill doesn't either. Call it A$500 or more a year back, before you count the maintenance retainer, which for most of our incoming clients is the larger number.

The security line item mostly disappears too. Patchstack recorded 7,966 new WordPress ecosystem vulnerabilities in 2024, 96% of them in plugins. A static Astro site has no plugins, no admin login and no database, so the standing risk you're paying that retainer to manage isn't there. It's a large part of why we don't build on WordPress in the first place.

What you give up

The admin dashboard. Out of the box, editing an Astro site means editing files in a git repository, and whether that's fine depends entirely on who publishes.

If content changes a few times a month and goes through one or two people, git-based editing works better than it sounds, especially with AI assistance, more on that below. If you want a proper editing screen, Keystatic gives you a local or GitHub-backed admin UI over the same Markdown files, so editors get forms and previews while the content stays in the repo. And if you have a genuine newsroom, multiple non-technical editors publishing daily, you can keep WordPress purely as an editing backend and have Astro pull from its REST API at build time. That's the headless arrangement, and it has real trade-offs of its own, which we've covered in our guide to headless WordPress.

What we'd caution against is pretending this cost is zero. It isn't. It's just much smaller than most people assume, and far smaller than the cost of the treadmill they're on.

When Astro is the wrong choice

If your "site" is actually an application, don't force it. Customer dashboards, logged-in areas, anything where most pages are personalised to the viewer, that's app territory, and you want a framework built around it: Next.js is the common answer, and TanStack Start is what we reach for on our own builds. Astro can do server rendering and API routes, but a heavily interactive app on Astro means fighting the framework's grain, and the zero-JavaScript advantage that made it worth choosing evaporates once every page is an island.

Ecommerce sits in between. A WooCommerce store is a different migration with different destinations, and we've written it up separately rather than pretend one guide covers it.

The test we use: count the pages a logged-out stranger can see. If that's 90% of the site, Astro. If most of the value is behind an interaction or a login, look at the app frameworks.

Where AI tooling changes the maths

The quiet reason these migrations got cheap: an Astro site is the ideal codebase for AI-assisted development, and WordPress is close to the worst.

An Astro project is plain typed files in a git repository. An agent like Claude Code can read the whole site, write the WXR or REST API conversion script, port templates, fix the image references, and hand you the result as a diff you review before it merges. TypeScript catches a good share of its mistakes at build time, and Astro, React and TypeScript are so heavily represented in what these models trained on that the tooling is fluent in them. Content is Markdown, so "update the pricing on the services page" is a two-line diff with an audit trail, not a ticket.

A WordPress site gives an agent nothing to hold. The state that matters is smeared across a MySQL database, plugin option tables and a themed PHP runtime, none of it visible in any repo, and an agent poking at a live admin panel has no type checker, no diff and no undo. There's no safe way to hand it the keys.

The practical effect is on the quote. Migrations of this shape were priced in weeks of hand-porting; the mechanical majority of the work is now done by tooling and checked by a person, and a small-site quote from 2022 is roughly double what the same job costs today. One honest limit: AI accelerates a clean target. It does not rescue a decade of page-builder markup on its own, and anyone claiming otherwise hasn't opened the export file.

Where we fit

This is work we do: content export, redirect map, a design that isn't a theme, Cloudflare hosting at the end of it. If you want to know what's actually involved for your site before deciding anything, we'll audit it for free, and if you're ready to talk about the rebuild itself, start here. Occasionally the audit says your WordPress site is fine for another couple of years. We'll tell you that too.