WordPress is still the right answer for a lot of sites. But if you look after a pile of small brochure sites, you are probably paying for the same things over and over: a server, a control panel, plugin updates, security patches, and the occasional 2am call because a plugin broke the contact form. For sites that mostly publish pages and rarely change, moving to a static Astro build removes most of that.
This guide is the checklist we would follow for a migration: how to decide which sites to move (and which to leave alone), how to get the content out, how to replace what your plugins did, how to avoid losing your rankings, and how to cut over safely. If you manage many client sites and are staying on WordPress, our guide to managing WordPress releases across 40+ client sites is the better fit.
Which WordPress sites are worth migrating?
The decision is not is static better?
It is does this site actually need a database and a plugin ecosystem at request time?
Most brochure sites do not. Most stores do.
| Good candidates | Leave on WordPress |
|---|---|
| Brochure and marketing sites that change a few times a month | Online stores (WooCommerce checkout, accounts, inventory) |
| Blogs and documentation where content is the product | Membership, learning-management or gated-content sites |
Sites whose dynamicparts are a contact form and search |
Sites that depend on many interacting plugins |
| Sites nobody dares to update because plugins might break | Sites where non-technical editors rely on the WordPress editor every day |
If you are weighing the two approaches in general, not just for WordPress, our post on Jamstack vs traditional CMS and how to deploy both covers the wider decision.
That last row matters. If editors live in the WordPress dashboard, moving to Markdown files in Git changes their daily work. You have two honest options: keep WordPress as a headless CMS (Astro can fetch content from it, covered below) or give editors a Git-based editor. If neither is acceptable, that site stays on WordPress, and our guide to deploying WordPress from Git covers doing that safely. For stores, see WooCommerce deployment with safe database migrations.
What you gain, and what you give up
Gains: no PHP runtime, database or plugin updates to patch in production; a much smaller attack surface; hosting that can sit on a CDN; and every change reviewed in Git. Costs: you rebuild the front end, you replace each plugin's job on purpose, and editors lose the familiar dashboard unless you keep WordPress headless.
Be realistic about the effort. A small brochure site is a contained job; a large blog with custom post types, redirects and forms is a real project. Do one small site first and use it to build your template.
Step 1: Inventory the site before you touch it
Write down what the site does today, not what you think it does:
- Every public URL. Crawl the live site (or export the sitemap) and save the list. This becomes your redirect and verification checklist.
- Every plugin and what it does. Forms, SEO metadata, redirects, caching, sliders, analytics, comments. Each one needs a replacement or a decision to drop it.
- Content types. Posts, pages and custom post types, plus categories and tags.
- Media. How many files, and where they live.
- Traffic. Pull Search Console data for the top pages. These are the URLs you must not break.
Step 2: Choose how content gets into Astro
Astro's own WordPress migration guide describes three routes: start fresh from a template, keep using your existing WordPress site as a CMS for Astro, or move content into files, typically Markdown or MDX.
| Route | Good for | Trade-off |
|---|---|---|
| Convert to Markdown/MDX files | Sites that rarely change; developer-run content | Editors move to Git or a Git-based editor |
| Headless WordPress | Sites with editors who must keep the dashboard | You still run and patch WordPress somewhere |
| Rebuild fresh | Small sites where the old content is poor anyway | Most manual effort |
Converting to files. WordPress can export posts, pages, custom post types, comments, custom fields, categories, tags and users through Tools, then Export. Astro's guide links to a Markdown export tool and a community utility for converting the export. Check how media is handled on your site and plan to copy the wp-content/uploads folder directly rather than assume the export file carries it.
Headless WordPress. Every WordPress site exposes a REST API at /wp-json/wp/v2/, and posts are available at /wp-json/wp/v2/posts. Astro's headless guide fetches posts from that endpoint, and static sites need getStaticPaths() to generate the pages. Two practical details: the API returns at most 100 records per request (per_page is capped at 100), so a larger site needs to paginate using the X-WP-TotalPages header, and custom post types have to be exposed in the WordPress dashboard before the API will return them. Astro's content collections can also load remote content through a custom loader if you prefer to treat the API as a data source.
Step 3: Rebuild the site and keep the URLs identical
This is the single decision that makes the rest of the migration easier. If /services/web-design/ is a page today, make it the same path on the new site. Then your redirect list shrinks to the few URLs you genuinely change, and the SEO risk drops with it.
Practical rules while you build:
- Match the permalink structure exactly, including trailing slashes.
- Carry over the page title, meta description and canonical for every URL you keep.
- Rebuild the sitemap and robots rules.
- Keep the content, headings and internal links of your top-traffic pages as close to the original as possible. Redesign later, once the move has settled.
Step 4: Replace what the plugins did
Each plugin was doing a job. Decide how that job gets done without PHP:
- Search. A fully static search library such as Pagefind lets you add search without running a server.
- Forms. A static site has no PHP to receive a form post, so you need an external endpoint. Services such as Formspree publish an Astro guide for this. Cloudflare Turnstile is worth adding to fight spam, but it is a spam check, not a place that stores submissions. Astro's own forms recipe needs a server adapter and on-demand pages, so it does not apply to a purely static build.
- Redirects. Move your redirect plugin's rules into your host's redirect configuration, and check that your host supports them before you commit to it.
- SEO metadata. Generate titles, descriptions and canonicals in your layouts from page frontmatter.
- Comments. Most migrations drop them or move to a third-party service. Decide deliberately, and keep the old comments as static text if they carry value.
Moving several client sites? Once a migrated site is in Git, automatic deployments ship every push to the host without a manual step, which is what keeps a fleet of small sites cheap to look after.
Step 5: Protect your rankings
Most migration pain is lost search traffic, and it is avoidable. Google's guidance on site moves is clear on the mechanics: use server-side permanent redirects (301 or 308) where possible, and map every old URL to its new URL. Permanent redirects do not cause a loss in PageRank, and you should keep them for as long as possible, generally at least a year. For a small or medium site, it can take a few weeks for most pages to move.
WordPress also creates URLs you may not think about. Check each of these in your crawl and decide what happens to it on the new site:
- Shortlinks.
?p=123style URLs that WordPress redirects to the pretty permalink. - Feeds.
/feed/and per-category or per-post feeds that subscribers and aggregators may still request. - Archive pages.
/category/...,/tag/...,/author/...and date archives, which often rank for long-tail queries. - Pagination.
/page/2/style URLs on the blog and archives. - Uploads.
/wp-content/uploads/...file URLs that other sites and Google Images may link to. - Trailing slashes. Whatever the old site used, match it, or redirect consistently.
A workable checklist:
- Crawl the old site and save every URL, status code, title and canonical.
- Build the new site and crawl a staging copy the same way.
- Diff the two lists. Every old URL must either exist unchanged or have a 301 to a close equivalent.
- Submit the new sitemap in Search Console after cutover.
- Watch impressions and clicks for the top pages for several weeks, not days.
Because this guidance is about moves with URL changes, keeping your URLs identical (Step 3) is your best insurance: it leaves you with far fewer redirects to get wrong.
Step 6: Host the static build
You have three sensible options, and the deploy step is the same Git-to-host flow either way.
Managed static hosting on a CDN. DeployHQ Static Hosting runs on Cloudflare's edge and detects Astro automatically, with builds in an isolated container and atomic deploys with instant rollback. Our step-by-step guide to deploying an Astro site to DeployHQ Static Hosting walks through the configuration, and the overview of Static Hosting on DeployHQ covers what the product does. Two things client sites usually need, custom domains and redirects, are not available on Static Hosting yet, and both are coming soon. Until they ship, it is a good fit for staging copies, previews and sites that need neither; for production client sites that need their own domain or 301s, deploy to Cloudflare directly or to your own server for now. Whichever managed host you choose, confirm that it supports your custom domain and the redirects you need before you plan your cutover.
Cloudflare directly. If you deploy straight to Cloudflare Workers with static assets, know the free-plan numbers: requests to static assets are free and unlimited, the daily limit of 100,000 requests applies to Worker script invocations (for example server-side rendering), a Worker version can hold 20,000 files, and individual files can be up to 25 MiB. A site with a very large media library can hit the file-count limit, so check yours. Cloudflare says Workers supports most Pages use cases and recommends starting new projects with Workers. If you are weighing Cloudflare's own tooling against a deploy-from-Git workflow, our comparison of DeployHQ Static Hosting and Cloudflare Pages lays out the difference.
Your own server. Static files will happily run on the VPS you already pay for. If you are replacing a VPS plus a control panel such as Plesk, you keep some cost; the saving is in maintenance and patching, not hardware. This is the right choice when you also host other things on the same box.
Step 7: Cut over one site at a time, with a way back
Do not switch everything in a weekend.
- Deploy the new site to a staging hostname and test it with the old one still live.
- Check every URL from your inventory: status codes, titles, canonicals, redirects, forms, search and analytics.
- Lower your DNS TTL a day before.
- Switch DNS for one site, then verify it live from outside your network.
- Keep the old WordPress hosting running, untouched, until the new site has held its rankings for a few weeks.
- Only then back up everything and cancel the old hosting.
The rollback is simple as long as you wait: point DNS back. That is why cancelling the old hosting is the very last step.
After the move
The ongoing work shrinks to content changes and the occasional dependency update. Put the Astro project in Git, deploy on push, and every change gets reviewed and can be rolled back. If you manage several sites, keeping the same project template across them makes this a one-line change in many places.
Frequently asked questions
Will I lose my Google rankings if I migrate from WordPress to Astro?
Not if you keep URLs identical or map every changed URL with a permanent redirect, per Google's site-move guidance. Expect it to take a few weeks for a small site's pages to settle, and monitor Search Console in the meantime.
Can I keep WordPress as my CMS and still use Astro?
Yes. Astro can fetch posts from the WordPress REST API at build time, so editors keep the dashboard while the public site is static. You still have to run and patch WordPress somewhere, so the maintenance saving is smaller.
What happens to my contact forms?
A static site cannot receive form posts by itself. Use an external form endpoint and add spam protection such as Cloudflare Turnstile.
Is Astro the only option?
No. Other static site generators work the same way. We picked Astro here because its WordPress migration paths are documented.
Should I migrate a WooCommerce store?
Generally no. Checkout, accounts and inventory need a server and database at request time. Keep stores on WordPress and deploy them carefully.
Ready to ship your first migrated site? Start with DeployHQ and deploy it from Git in minutes.
Questions about moving a WordPress site? Email support@deployhq.com or reach us on X at @deployhq.