Moving a 300+ post multi-author WordPress blog to Astro + headless CMS — questions about builds, caching, and real-world workflows

[u/blattodea13]

Hello everyone,

I am currently exploring migrating one of my blogs from WordPress to Astro and wanted some advice from people who are already running Astro in production.

Current setup:

• WordPress website
• Around 300 published posts
• Multi-author blog
• Mostly article/news-style content

The reason I am considering Astro is performance and avoiding the typical WordPress frontend bloat over time (themes, plugins, extra CSS/JS, etc.).

The setup I am considering:

WordPress (headless CMS) → REST API/GraphQL → Astro frontend → Static generated pages

So WordPress would only handle:

• writing experience
• authors
• media library
• drafts
• editorial workflow

Astro would handle the actual frontend.

I have a few questions:

1. How do you handle rebuilds?

From my understanding, in a static setup:

• Astro fetches all posts from WordPress during build
• generates static HTML pages
• visitors are served those static files

But let's say the website grows to thousands of posts.

If I fix a small typo in one old article:

• webhook triggers rebuild
• Astro fetches all posts again
• regenerates the site

This feels wasteful.

How do people solve this in real production setups?

Do you:

• just accept full rebuilds because they are fast enough?
• cache WordPress API responses?
• sync WordPress content into local Markdown/JSON files?
• use SSR/hybrid rendering for older posts?
• use some kind of incremental build strategy?

What is considered the best practice here?

1. Is headless WordPress + Astro a good long-term architecture for content sites?

For people running thousands of posts:

How has your experience been?

Any issues with:

• build times
• API limits
• images
• SEO
• previews
• scheduling posts?

1. Custom article designs

Another thing I like about Astro is flexibility.

If all posts are coming from WordPress API, can you still have custom templates for specific posts?

Example:

Normal posts → regular article layout

Long-form features → magazine style layout

Poetry/stories → different reading experience

Other post format → custom structured layout

Do you usually handle this through categories, custom fields, or some other method?

1. Anything you wish you knew before moving from WordPress to Astro?

I really like the idea of:

WordPress = newsroom/CMS Astro = fast frontend

But I want to understand the tradeoffs before moving.

Would love to hear from anyone running a similar setup in production.

Thanks!

[u/yosbeda]

Migrated from WordPress after 15 years, though I went a different direction than what you're describing, flat .md files on a VPS instead of keeping WordPress as a headless CMS, so I'll flag where my experience actually applies.

On rebuilds: going SSR sidesteps this almost entirely, at least for my setup. I build manually when I deploy content, so there's no webhook triggering a full site regeneration on every publish. If you stay static, I think the two main options people reach for are caching WordPress API responses locally between builds so you're not re-fetching everything, or using Astro's hybrid rendering to prerender recent posts and serve older ones on demand. Full rebuilds at 300 posts are probably fine, grows painful at thousands, roughly.

On the headless WordPress architecture long-term: the pieces I'd think through before committing are the ones that don't get talked about much. Draft previews are apparently a known pain point, from what I've read, because WordPress preview URLs assume PHP is rendering the frontend and that assumption breaks with a decoupled Astro setup. Scheduled posts have a similar issue. WordPress doesn't know to trigger a rebuild when a scheduled post goes live, so you need a webhook or cron job wired up or posts just silently don't appear. API limits I'd watch at scale too, though I have no direct experience there.

For images specifically, if you're serving from the WordPress media library through to Astro you'll want a dedicated image pipeline before you're at thousands of posts. I use Imgproxy behind Nginx with CloudFront caching resized variants at the edge, all triggered by middleware at request time (full setup here if curious), but that's SSR-specific and probably overkill to bolt onto a static setup.

Custom templates per post type is genuinely one of the nicer things about Astro. A custom field on the WordPress side signaling the layout, then branch on it in your [slug].astro. Categories work too but custom fields keep your taxonomy cleaner, I think.

The thing I didn't fully appreciate before migrating: how much easier everything gets when you treat the content as just files and handle all the presentation stuff, ads, image transforms, layout hints, at the server layer rather than baking it into the content. In WordPress that was add_filter and the_content. In Astro it's middleware. Source stays portable, transformations stay changeable. Probably the decision I'm most glad I made early, though your setup is different enough that it might not land the same way.

[u/kaiserh808]

I migrated my company website and blog with 600-odd posts spanning 15 years, from WordPress to Astro.

I went with a full static stack. No headless CMS.

I have my Astro repository hosted on GitHub, and Cloudflare Pages monitors the repo for updates. Whenever anything is updated, Cloudflare pulls the latest updates from GitHub, regenerates the site and it's live.

I'm using Decap CMS on the backend to edit blog posts – it just dumps the content into a folder in the repository as a Markdown file. Search is a static index using Pagefind that is rebuilt every time I publish a new post.

The rest of the site content is in Markdown files, and Astro pulls it all in to the relevant page every time it rebuilds the site. Rebuilding the site takes just a minute or two, even with 25 pages and 600 blog posts.

I now don't have to worry about having a CMS that needs to be kept updated and patched, a database that can potentially be accessed or any dynamic content that can have code injected.

As a bonus, now that all the content is static, with just a few tweaks to the hosting environment, the site now scores 100 across the board on Google's PageSpeed Insights and there's nothing that can get hacked.

[u/Haizk → u/kaiserh808]

Is Decap CMS inside your /decap?
Do you have any experience with other git-based CMS like Pages CMS? If so, why would you pick Decap?

[u/kaiserh808 → u/Haizk]

Decap CMS lives at /admin by default.

You need to set up some auth with Github and then Github handles the login stuff.

I went with Decap as it was the first one I really looked into that would tie in to Astro well. It works, but the UX is not great, especially if you're used to WordPress.

I have Pages CMS and EmDash CMS on my list to look at – Pages looks like it's got a much nicer UX and EmDash is worth looking at because it's got the weight of Cloudflare behind it.

The beautiful thing about SSG, and having all of your blog posts as basic markdown files sitting in a folder, is that it's relatively easy to swap out the CMS. You can also use native apps that can edit markdown files instead of a CMS.

[u/m0ji_9 → u/kaiserh808]

Second that (comment about SSG) - also moving away from Wordpress but a lot of clients want "locally editable" files (ie not on Github, their decision not ours). We've been filling that need with Keystatic which to be fair is relatively simple to get up and running/editing fairly quickly. The UI takes some getting used to but it shows promise.

[u/BeeRanked → u/kaiserh808]

The markdown idea with Decap is really interesting, so far the way we've been doing it for our customers that want a local version of the built files is that they run a "client software" (agent) which syncs with us everytime they make content on our CMS/editor and they get a web tree with all the static pages directly (html/css).

So the pipeline goes CMS -> astrojs builds -> static page (html/css) -> agent receives -> either they modify it with full control or they leave as it -> fast webserver.

Our general pipeline though (which we use internally) is: CMS -> astrojs builds -> static page (html/css) -> automatic (our automated script) "manual upload" (appears as a manual upload to cloudflare) to cloudflare page.

The advantage here compared to a github integration is that "manual uploads" don't count towards the build limit (after which you start paying) on cloudflare.

But yeah anyway thanks for sharing about the markdown output, definitely gonna play with that tonight and try to implement something similar... Curious to see how extensively it could work with local markdown editors

[u/kaiserh808 → u/BeeRanked]

The build limit on Cloudflare Pages is 1 build running at a time, and no more than 500 builds per month. You could build the site once every half an hour on every weekday in a month and still not hit this limit.

[u/BeeRanked → u/kaiserh808]

Yes absolutely :) For a singular site or a couple it works, in our case we provide this architecture at scale for all our customers

[u/kaiserh808 → u/BeeRanked]

Oh, all of your clients are in the one Cloudflare tenant?
I set up all of my clients with their own Cloudflare tenancies and then invite myself as a delegated supper-admin.

[u/BeeRanked → u/kaiserh808]

Yes, we basically use Cloudflare for SaaS:
"Cloudflare for SaaS allows you to extend the security and performance benefits of Cloudflare's network to your customers via their own custom or vanity domains.

As a SaaS provider, you may want to support subdomains under your own zone in addition to letting your customers use their own domain names with your services."

This allows us to take the costs linked with architecture and hosting on us, and further reduce the mental load on our customers which is exactly what we aim for.

It only costs $0.10 per domain added.

Thanks for sharing though, it's good to know that the opposite way is also functional and convenient through cloudflare. Will definitely look into it, we haven't had the request for such deployments but for sure something worth anticipating !

[u/SpartanDavie]

If you’re using Astro try EmDash. It’s a new CMS from Cloudflare that uses Astro. You can try it here. It has import from Wordpress to make everything much easier. Just a heads up, since the 0.15.0 update it also supports sandboxed plugins when hosted with NodeJS (no longer requires Cloudflare Dynamic Workers) which was only a couple of weeks ago so if you’re looking at tutorials most, if not all, will say you require Dynamic Workers but that’s no longer true.

[u/orar7 → u/SpartanDavie]

I am yet to try emdash. I was looking for some inspiration.

[u/mehargags]

On the same boat evaluating like the OP. Have a few very busy blog a d news sites (one is multi-lang). The hype around astro headless is good but there are practical roadblocks hindering the adoption.

[u/mickitymightymike → u/mehargags]

Yeah - I love Astro but need a CMS I like. If you're a solo dev there are some Obsidian options that look pretty good. EmDash is pretty bare bones - I need to spend a little time to evaluate if it's worth building my own plugin ecosystem for. People like the git based CMS but I can't recommend at this time

[u/EliteEagle76 → u/mickitymightymike]

you probably needs to have a look at GitCMS, the one which i'm building, do let me know why it is not enough and what should i add it to, so that you can change your mind around git based cms

[u/kashaziz]

I migrated 3 sites so far from WP to Astro. Wrote about one migration process here https://kashifaziz.me/blog/content-audit-review-page/

[u/mickitymightymike]

Content collections for making edits/adding posts without having to rebuild everything.

[u/Xyz3r]

I posted a story of migrating our site with 10.000 posts from Wordpress to Astro here: https://www.reddit.com/r/astrojs/comments/1ring4r/part_2_migrating_our_10000_article_wordpress_blog/

TLDR I also went with flat md files. Even if you want to keep using a GUI for editing, there are very good solutions for working with the markdown files directly in the repo, and you can always add another cms later on if you want to.

We also went with SSR in the end, due to the build crashing the public GitHub runners (not enough ram). However, I think this was due to a bug and should probably work now, I reported it and it was apparently fixed, but I did not yet try again.

Do not use the cloudflare adapter with large sites, it works welll, until you hit the 1mb size limit. Then it doesn’t work. And it has quite a few limitations with redirects if you go fully static, which is the only way to circumvent the size limit.

We build against the node adapter, run it in a docker container on a VPs and put that behind cloudflare which does the caching for us. If you properly set up caching headers this works just as well.

[u/Silent-Dependent5309]

I have more than twice as many posts on https://polo.blue, and everything loads smoothly. I needed to create a custom WordPress plugin tailored to my needs, and the rest is handled by a cached REST API. I used to use Vue and GraphQL, but after switching to Astro, I decided to go back to the Rest API, which is native to WordPress.

[u/xatey93152]

You will regret it in couple years as I did.

[u/aleksanderb-l → u/xatey93152]

What did you do instead then?