Why We Moved Our Website from WordPress to Astro (After 10 Years)

We make a WordPress plugin, and we just moved our own website off WordPress. I know how that sounds.

We ran our site on WordPress for over 10 years. It worked. But over time, the cracks got harder to ignore. When the WSMS rebrand came up, we decided to start fresh with Astro, and we wanted to share what that looked like for us in case it’s useful to anyone thinking about a similar move.

What wasn’t working anymore

We still think WordPress is great. Our plugin is built for it, and we’re not going anywhere on that front. But for our marketing site specifically, we kept running into the same problems:

Page loads were slow. We had caching plugins, a CDN, all the usual optimization stuff. But every request still hit a server and a database to render pages that hadn’t changed in weeks. It always felt heavier than it needed to be.

The dev workflow was rough too. Everything lived in a WordPress theme. Version control was messy, there was no component system, no type safety. Making a small change meant touching a lot of things and hoping nothing broke. After 10 years, the codebase had a lot of weight to it.

We kept working around these issues, but during the rebrand we finally asked: do we actually need WordPress for this part?

How we landed on Astro

We looked at a few options: Next.js, Hugo, Eleventy. We spent the most time evaluating Next.js, but for a content-heavy marketing site like ours, Astro was a much better fit. Faster builds, smoother developer experience, and none of the complexity that comes with a full React framework when you don’t need it. Astro felt like it was built for exactly what we needed.

A few things that mattered to us:

Pages are static by default. They get built once at deploy time and served as plain HTML from the edge. No server, no database queries at runtime. For a site that’s mostly docs, blog posts, and landing pages, this made a lot more sense.

Astro has something called Content Collections. It’s basically a way to organize all your content as Markdown/MDX files with typed schemas. We have over 2,000 content files now (blog posts, docs, gateway pages, changelogs), and they all live in the repo as files instead of database rows. It’s surprisingly nice to work with.

And when we do need interactivity (a search widget, a pricing calculator) we can drop in a React component and Astro only ships JavaScript for that piece. We’re not sending a full React app on every page load.

The developer experience is just better for us: TypeScript, Tailwind, hot reload, Storybook for testing components in isolation. It’s the workflow we wanted for years.

AI and tooling made this possible

This is the part we’re most excited to share. We used Claude for a huge chunk of this project.

Our site has over 200 React components. Building all of those by hand, with RTL support and Storybook stories for each one, would have taken forever. AI handled a lot of the repetitive work while we focused on design decisions and quality.

We also used it to migrate years of WordPress content into structured MDX files, and to translate the site into three languages (English, Farsi, Arabic). The translations needed manual tweaking for tone and accuracy, but having a solid first pass made the whole process realistic.

Another big reason we went with Astro: because content is just Markdown files in a repo, coding agents work incredibly well with it. Our team uses Claude Code and Codex daily, and they can read, edit, and create content and components without any special setup. No CMS API, no database queries. Agents just work with files, and that’s the easiest thing for them to do well.

For quality checks, we use SquirrelScan to audit pages for accessibility, SEO, performance, and other issues. It catches things we’d miss manually, and it’s become a regular part of our workflow before pushing changes live.

Honestly, without AI and these tools this project would have taken significantly longer. It changed the math on what was feasible for a small team.

We didn’t leave WordPress entirely

This is important. We split things up.

wsms.io is the Astro site. Marketing pages, blog, docs, all the public content. Fully static, deployed on Cloudflare Pages.

my.wsms.io is still WordPress with WooCommerce. User accounts, purchases, license management, checkout. WordPress handles that really well, and we didn’t see a reason to rebuild it.

This split has been clean. The marketing site doesn’t need a database. The account portal does. Each side does what it’s good at.

RTL support that actually works

This one’s personal for us. A big part of our user base reads Farsi and Arabic, and getting RTL right on WordPress was always painful. Themes would break, plugins didn’t support it well, and keeping content in sync across languages was a constant headache.

With Astro, we built RTL into the component system from day one. Every component knows about text direction and language. Icons flip automatically. Fonts load correctly per language. It’s not an afterthought. It’s part of how the site works.

The result is that our Farsi and Arabic users get a site that feels native to them, not like a mirrored English page.

What changed after the switch

We don’t have formal benchmarks, but the differences are obvious in daily use:

Pages load noticeably faster. Static HTML from Cloudflare’s edge, no server round-trips.

Working on the site is actually enjoyable now. We can spin up Storybook, build a component, see it in isolation, and push it live in minutes. The old workflow involved a lot more friction.

Deploys are simple. Push to git, the site builds and goes live globally. No database migrations, no cache clearing rituals.

Hosting costs went down too. Cloudflare Pages is free for static sites, so the marketing site costs us nothing to host. That’s a nice change from managed WordPress hosting.

We added full-text search using Pagefind, which builds its index at build time. Search across 2,000+ pages with zero runtime cost. That was a pleasant surprise.

A few things we’d tell someone considering this

Static sites can do more than you think. We were surprised how much you can build with Astro. It’s not limiting. It’s just selective about where JavaScript runs.

Files in a repo beat rows in a database for content like ours. Versioning, collaboration, backups. It all gets simpler when your content is just files.

You don’t have to migrate everything. Keeping WordPress for the parts it’s good at (e-commerce, accounts) was the right call for us. The key was figuring out which parts should be static and which shouldn’t.

AI changes what’s realistic. A project this size used to require a large team or a long timeline. That’s not necessarily the case anymore.

Wrapping up

If you’re running a content site on WordPress and you’ve been frustrated with the same things we were (slow pages, painful dev workflow, hard-to-maintain themes) it might be worth looking at Astro. It worked out really well for us.

We’re not saying WordPress is bad. We literally build software for it. But for a site like ours, Astro turned out to be the better tool.

We wanted to share this because we looked for similar stories when we were making the decision and didn’t find many from teams in our position. Hopefully this is useful to someone.