If you run a small business site on WordPress and you’re wondering whether to move to Astro, this is what the move involves, what it costs, and what to check once you’ve switched.
The short version: Astro builds every page into a plain HTML file ahead of time, so there is no database to query, no plugin to update and very little JavaScript to download. Most of the work in moving isn’t the design. It’s rebuilding everything WordPress did quietly in the background: forms, old URLs, SEO settings and the media library. And Astro won’t make a site fast on its own. The scripts, fonts, embeds and images you add on top still decide the score, so each one needs checking.
- What Astro is — a JavaScript framework, not a CMS like WordPress. It turns your pages into static HTML and CSS when you publish, and ships no JavaScript unless you add some
- We moved to Astro — it took us three weeks for 12 pages and 8 posts, and we kept WordPress online for another week as a fallback
- The hidden work — a server-side script to replace the form plugin, the SEO plugin’s settings ported by hand, and redirects for every old media file and archive URL
- Speed — Astro is a fast starting point, not a guarantee. The biggest gains usually come from removing JavaScript, not adding more optimization
- What Astro doesn’t have — a built-in editor. Without a CMS connected, every change is an edit to a file and a new build
What Astro is, and why it’s fast
First, WordPress and Astro aren’t the same kind of tool. WordPress is a content management system (CMS): software that runs your website and gives you a dashboard where you log in, write pages, upload images and add features with plugins, without touching any code. Astro is a JavaScript framework: a toolkit developers use to build a website from code files. It has no dashboard of its own. Someone writes the pages as files, and Astro turns them into a finished website.
That difference also changes when each page gets built. On WordPress, a page is assembled the moment someone asks for it:
- the server runs WordPress’s PHP code
- it queries the database for the page’s content and settings
- the theme and every active plugin add their part of the page
- a caching plugin, if you have one, saves the finished page so the next visitor gets it quicker
Astro does all of that once, when you publish:
- it builds every page into a finished HTML file
- those files go up to your hosting as a plain folder
- when someone visits, the server hands over a file that already exists
That’s why it’s faster. There’s no code to run and no database to wait on, so the server can answer straight away, and every visitor gets that quick answer, not just the ones who land on a freshly cached page. A site built this way is called a static site: its pages are fixed files that only change when you publish again.
The other half is JavaScript, the code that makes parts of a page move or respond. Page builders such as Elementor and Divi have long been known for loading more code than a page needs. Elementor’s own developer documentation says that “Up to Elementor v3.1.0, all widget handlers were loaded to every page by default, regardless of whether they are actually used on the page.” Both builders have since added settings to trim this, but it shows how easily a plain text page ends up downloading code for sliders, pop-ups and animations it never shows. Astro starts from the opposite end:
By default, Astro will automatically render every UI component to just HTML & CSS, stripping out all client-side JavaScript automatically.
So a page starts with no JavaScript at all. When one part of it does need to respond to a visitor, such as a mobile menu that opens, a carousel that slides or a form that checks what you typed, you add JavaScript to that part only. The rest of the page stays plain HTML, which a browser can show almost instantly. Astro calls those interactive parts islands.
There’s a maintenance argument too. Every WordPress plugin is code running on your server, so each one has to be kept up to date, and each one is a way in if it falls behind. That’s where most WordPress security problems come from: Patchstack’s review of 2025 found that “91% of new vulnerabilities were found in plugins, and 9% were found in themes”. A static site has no plugins running on the server, so that whole list of updates and risks goes away. We cover the rest of that picture in Website Security for Small Businesses: What the Padlock Doesn’t Cover.
Our WordPress to Astro migration
Our WordPress site had 12 pages and 8 blog posts, built with:
- Elementor, the page builder, with Elementor Pro for the contact and newsletter forms
- the Astra theme
- Rank Math for SEO
- LiteSpeed Cache to save finished pages and serve them faster
The migration took about three weeks.
The design came over first, and on an Elementor site that takes longer than it looks. Elementor stores each page’s styling, such as fonts, colors and spacing, in its own data and generates its own CSS from it, which overrides whatever the theme’s settings say. So the theme can name one font while visitors see another. If you’re moving an Elementor site, copy the styling from Elementor’s generated CSS, because that is what visitors actually saw.
The blog posts came over as text files with their HTML intact. That part is quick, because nothing gets rewritten on the way.
It also means a migration copies your content exactly, mistakes included. Quotes credited to a page that doesn’t contain them, links to sources that no longer exist and statistics the original source has since changed all move across untouched. A migration is a good moment to check each post, not just move it.
What WordPress does that you don’t see
A WordPress site handles a lot behind the scenes. It sends your form submissions, manages your SEO settings, keeps old links working and publishes a page when you press a button. A static site does none of that on its own, so each one has to be rebuilt. For us, these four took most of the effort in the move.
Forms
On WordPress, a form plugin takes care of everything after a visitor presses Send. It receives the message, filters out spam and passes it on to your inbox or email list. A static site has no code running on the server behind its pages, so a form has nowhere to send its data until you add something.
The usual fix is a small script on your hosting or a third-party form service. Either way, keep any secret keys out of the page itself. Connecting a form to an email service usually needs one, and anything in a page’s code can be read by anyone who visits.
Ours is a short script on the same hosting as the site. It holds the key, checks each submission for spam and passes it on to our email service in the same format the old forms used, so the automations that run on each new sign-up kept working.
SEO settings
WordPress makes SEO easy to manage. With a plugin like Rank Math, you type each page’s title and description into a box under the editor, and the plugin adds the hidden code that describes the page to Google, called structured data. Some of Rank Math’s features need its paid plan, though most of what they add is something you can write yourself.
On Astro there’s no box to fill in. Titles, descriptions and structured data are written into the site’s files, which takes more setup but means nothing is held back for a paid tier.
We copied every title and description out of Rank Math into one file in the new site and improved them there. We also left out two pieces of structured data the plugin had added that didn’t fit the site, one of them describing a search box the site doesn’t have.
Old URLs
Every page has an address, and links from other sites, old emails and Google’s search results all point to it. If a page moves and nothing is left at its old address, those visitors land on a “page not found” error, and Google eventually drops the page. The fix is a redirect: a rule that sends anyone who asks for the old address straight to the new one. A permanent redirect, also called a 301, tells Google the move is for good, so it swaps the new address into its results.
WordPress also creates addresses of its own, such as category pages, tag pages and a news feed, so expect more of them than the pages you can see. In our move, the blog’s category pages moved under /blog/, and the tag pages and the old feed were sent to their nearest new equivalents, each with its own permanent redirect.
Images need the same care. WordPress keeps every upload in one folder and makes several resized copies of each, so a site that has run for a few years has far more image addresses than images. If you rename or reorganize them in the move, every old address needs a redirect too, because search engines and other sites may still link to them. We gave ours clearer names and folders, which meant a redirect for each old image address. Google’s guidance on site moves is to keep redirects in place for a long time:
Keep the redirects for as long as possible, generally at least 1 year.
Publishing
WordPress publishes when you press a button. A static site has to be built into files and then put on your hosting, and there are a few ways to do that:
- Upload it yourself — build the site on your computer and upload the files through your host’s file manager or FTP
- Publish automatically — keep the site’s code on GitHub and connect it to a host such as Vercel, Netlify or Cloudflare Pages, which rebuilds and publishes the site every time you save a change
- Add a CMS — connect a content management system such as Storyblok, Decap or even WordPress itself, so you can write and edit in a dashboard and the site rebuilds when you publish
We publish automatically: every change builds the site and uploads it to our hosting. The build also catches mistakes WordPress never checked for, such as a redirect pointing at a file that still exists, and stops before anything broken goes live.
Mistakes to look out for when you switch
Most launch-day problems come from the switch itself, not from Astro. These are the ones worth checking for, and each of them happened to us.
- Check that the new site is actually live. When you point your domain at new hosting, a deploy tool can report success while the files land somewhere else. Open the live address yourself after the switch, ideally in a private window so you aren’t seeing a saved copy. Ours showed the host’s placeholder page at first, even though every upload had reported success, because the upload was still set up for the old hosting.
- Hide your old site from search engines. If you keep the old WordPress site online as a fallback, Google can find it and treat it as a second copy of your site. Turn on WordPress’s “Discourage search engines from indexing this site” setting, then clear any page cache so the change actually shows. Our fallback copy was open to search engines when it first went up, and an old cached version hid the fix for a while.
- Remove the old sitemap from Google Search Console. A sitemap is the list of pages you send Google so it can find them. When you add the new one, delete the old one, or Google keeps checking a list of addresses that no longer exist. We found WordPress’s sitemap still registered weeks after the move, next to the new one and showing an error.
Finally, don’t trust a single report after a move. A month after launch, Search Console’s sitemap report told us none of our pages were indexed. Checking pages one at a time with its URL Inspection tool showed more than half of them were. If a move looks like it has wiped you out of Google, inspect individual pages before you panic. Our Search Console diagnostic walks through how.
What to measure after you move
Moving to Astro doesn’t make a site fast on its own. Speed only improves once you find what’s slowing your pages down and take it out. Test your homepage and a typical blog post with Google’s free PageSpeed Insights straight after launch, then again after each change, so you can see what each fix actually did.
Our first Astro build scored 54 out of 100 on mobile, because it still carried the animated effects the WordPress design had. This is how it changed:
| When | What changed | Speed score | Main content loads | Unresponsive time |
|---|---|---|---|---|
| Late August | First Astro build, with the animated effects carried over from WordPress | 54 | 5.0 s | 1,290 ms |
| 22 September | Heavy 3D background code replaced with a lighter version; an animation library removed | 77 | 3.0 s | 680 ms |
| 1 October | One animation now loads only when you scroll to it | 90–95 | 2.9 s | 0 ms |
| 31 October | Re-measured for this post | 91–92 | 2.9 s | 0 ms |
Our homepage on mobile, measured with Google PageSpeed Insights in 2026. Speed score is out of 100, higher is better. Main content loads is how long the biggest thing on screen takes to appear, and unresponsive time is how long the page is too busy to react to a tap; lower is better for both. A typical blog post on the site scores 98–100 on mobile, and the homepage scores 100 on desktop.
None of those gains came from Astro itself. Each one came from taking out JavaScript. Scripts have to download and run before a page can finish appearing and respond to a tap, and on a phone that takes longer. Animations and 3D effects are some of the heaviest. Ours drew a moving background and held back the main heading until it had loaded, and every one we removed or delayed made the page faster.
Astro starts you at zero JavaScript, and every script you add puts weight back. Before keeping one, ask whether what it does is worth the wait.
What Astro doesn’t have
The biggest difference is the dashboard. Because WordPress is a CMS, anyone with a login can change a page, whatever their experience, and that ease is a large part of why it’s so popular. Astro is a framework, so on its own it has no editor at all. A change means editing a file, then letting the site rebuild and upload, which takes a few minutes.
That suits us, because we build sites for a living and edit ours every day. If the owner or a marketing assistant updates your site, it’s a real cost. You can add an editor back by connecting a CMS to Astro (see the FAQ below), or stay on WordPress.
You also give up plugins. On WordPress, adding a feature is often one click. That convenience has a cost: each plugin is more code to keep updated, a possible way in for attackers, and often extra scripts that slow your pages down. On Astro, anything a plugin did, such as forms, search, comments, bookings or a shop, has to be built into the site or connected from an outside service. Our site needed only forms, so that was one job. A site with a dozen plugins doing real work has a dozen jobs.
Is Astro right for your site?
Astro fits a site whose pages are the same for every visitor and only change when you publish. That describes most small business sites: a homepage, service pages, a contact page and a blog. Consultants, agencies, accountants, law firms, clinics, restaurants, tradespeople and nonprofits usually fall into this group. It fits best when someone technical looks after the site, or when you’d rather pay for a build once than keep paying in plugin updates. If other people need to edit it, a CMS connected to Astro gives them a dashboard to do it in.
Online shops are a different case. A shop’s pages change for each visitor, with carts, accounts, stock levels and payments, so it needs something running behind the scenes. Astro can be connected to a shop platform, but that’s a bigger build, and for most small shops WordPress with WooCommerce, or a platform like Shopify, is the simpler choice.
Stay on WordPress if non-technical people edit the site often and you don’t want to add a CMS, if you rely on plugins for memberships, bookings or a shop, or if the site already works well. A slow WordPress site is often a hosting or plugin problem you can fix in place, and our Web Hosting and Website Builders: How to Get Your Site Online guide covers those choices. If you do move, plan the redirects before you plan the design, and treat the URLs as part of the build. Our post on How to Update an Old Blog Post Without Losing Its Rankings covers why an address that changes loses what it had earned.
Also Read: Domain, Email and Hosting: A 2026 Checklist for Small Businesses
Key Takeaways
- Astro builds every page into static HTML ahead of time and ships no JavaScript unless you add it, so there’s no database to wait on and no plugins to patch.
- The design is the easy part of leaving WordPress. Budget the time for forms, SEO settings, redirects and images.
- Redirect every old address, images included, and keep the redirects for at least a year, as Google advises.
- After the switch, check the live site yourself, hide the old copy from search engines, and remove the old sitemap from Search Console.
- Astro won’t make a site fast on its own. Measure after launch and remove the scripts you don’t need; that took our homepage from 54 to above 90 on mobile.
- Astro has no editor of its own. Connect a CMS if non-technical people update the site, and keep shops on a shop platform.
Frequently Asked Questions
Can you add a CMS to an Astro site?
Yes. Astro’s documentation has guides for connecting content management systems such as Storyblok, Decap CMS and WordPress itself. With WordPress as a headless CMS, you keep writing in the WordPress dashboard and Astro pulls the content in and builds the pages. You still host and update WordPress, so you keep its plugin upkeep, but visitors only ever load the static pages Astro builds. We didn’t add one: for a small site edited by people who build websites, writing in files is simpler than running two systems.
Is Astro free to use?
Astro is open source and released under the MIT License, so the framework itself costs nothing. What you pay for is hosting, your domain, any services you connect for forms or email, and the time of whoever builds and maintains the site.
Does an Astro site need special hosting?
No. A static Astro build is a folder of HTML, CSS, JavaScript and image files, which any web host can serve, and platforms such as Vercel, Netlify and Cloudflare Pages host it too. We stayed with Hostinger, the host that ran our WordPress site. The one thing a static host can’t do on its own is process a form, so ours runs a small script for that.
How long does a WordPress to Astro migration take?
Ours took about three weeks for a 12-page site with 8 blog posts, and we kept the old WordPress site online for another week as a fallback. A bigger site, a shop or custom WordPress functionality takes longer, and so does a site with many plugins to replace.
Can an Astro site have search, comments or a shop?
Yes, but none of them come built in. On WordPress each one is a plugin; on Astro each one means connecting an outside service or adding a server-side piece. Search and comments are small jobs. A full shop is a bigger build, which is why most small shops are better off on WooCommerce or Shopify. Our site has none of the three.
Final Thoughts
Before you decide, list every plugin on your WordPress site and write next to each one what would replace it. Then count the URLs that would change, images included. Then decide who will edit the site once it’s live, and whether they need a CMS. If both lists are short, the move is a few weeks of work and you end up with a site that has nothing left to patch. If either list is long, that’s the real cost of switching, and it’s worth knowing before you start.
Thinking about moving your site off WordPress?
ClubUnbrick builds fast websites for small businesses and moves existing sites without losing their search traffic.
What We Offer
- Migration planning — Every plugin, form and URL on your current site mapped to what replaces it.
- Redirect maps — Each old address, images included, pointed at its new home before launch.
- Speed work — Measured page speed, with the heavy scripts found and removed.
- Launch checks — The live site, search indexing and Search Console checked the day you switch.
We’ll tell you honestly if staying on WordPress is the better call.
