I have built on WordPress for 20 years. Long enough to watch it go from a blogging script to what runs nearly half the web, and long enough to start asking an uncomfortable question: what is WordPress actually best at now, and what is it just used for out of habit?
My answer, after a year of building differently, is that WordPress is best as an engine. It belongs in the back, doing the unglamorous work, while something modern and fast handles everything the visitor sees. I want to walk through a real example of that, a news aggregation site built with Astro on the front and WordPress behind it, because it is the cleanest illustration I know of where this is all heading.
This is a deeper, more opinionated take than the practical guide I wrote for WP Mayor. Here I want to argue the case, not just show the wiring.
The Part of WordPress That Is Worth Keeping
For most of its life, WordPress won on the front end. It was the easiest way to get a site live, the easiest way to publish, the easiest way to hand a client something they could edit. That ease was the whole pitch.
That pitch is fading, and I have made the longer case that WordPress stopped being the default elsewhere. Google sends a fraction of the organic traffic it once did to independent sites. Social platforms swallowed casual publishing. And AI builders have eaten the on-ramp: the thing WordPress was best at, getting a non-technical person from nothing to a working site, is now a conversation with a model. The easiest path no longer runs through wp-admin.
What has not faded is the back end. The data model, the editor, the user and taxonomy system, the REST API, and above all the plugin ecosystem that has spent 20 years solving boring, specific problems. That accumulated competence does not evaporate because the front end moved. It is the most valuable thing WordPress has, and it happens to be the part you can point at any frontend you like.
So the move is to stop treating WordPress as the site and start treating it as the content backend. A headless engine. You keep the editing experience and the data plumbing, and you serve the actual pages from something built for speed. For a content-heavy site, that something is Astro.
Why a News Aggregator Is the Cleanest Case
A news or feed aggregation site is the example I keep coming back to, because every property that makes headless awkward elsewhere is absent here.
The front end is read-only. Nobody logs in, comments, or submits a form on an aggregated stream, so there is no interactive layer you are forced to rebuild outside WordPress. The whole job is to fetch other people’s content, organize it, and present it fast.
The content is also high-volume and constantly changing, which punishes a traditional theme. Rendering a few hundred frequently-updating items through PHP and a stack of plugins is exactly where WordPress feels slow. Hand that rendering to static HTML and the site stops fighting itself.
And the value lives entirely in the pipeline: pulling feeds, deduplicating, mapping fields, scheduling imports, handling images. That pipeline is server-side work, and it is precisely what WordPress plus a mature plugin already does well.
The Engine: WP RSS Aggregator
On the WordPress side, the import engine is the whole point, so it is worth being specific about what it does.
WP RSS Aggregator fetches and parses RSS and Atom feeds on a schedule, deduplicates items so the same story does not land twice, and normalizes the messy reality of real-world feeds into clean records. Feeds are inconsistent. Encodings vary, date formats vary, some include full content and some only excerpts, some embed images and some link to them. Years of that plugin’s lifespan have gone into handling those edge cases so you do not have to. Rebuilding that from scratch in a custom Node scraper looks easy for the first three feeds and gets painful by the thirtieth.
The feature that makes it work headless is Feed to Post. Instead of storing imported items as lightweight internal records, Feed to Post writes each one as a real WordPress post, or any custom post type you choose, with the content, excerpt, featured image, taxonomies, and author all populated.
That detail is the hinge of the entire architecture. Real posts are exposed through the WordPress REST API and through WPGraphQL automatically, with no extra work. The moment your feeds import as posts, your aggregation layer is already a clean API that Astro can read. You did not build an API. You configured a plugin, and WordPress handed you one.
You can map feed fields onto post fields, route different feeds into different categories or post types, and set the importer to sideload remote images into your media library rather than hotlinking the source. That last setting matters more than it sounds: it means your frontend pulls images from a URL you control, which stays stable and does not lean on someone else’s server.
The display side of the plugin, the shortcodes and blocks and templates, is the part you stop using. In this architecture Astro is the display layer, so those features fall away. You are using the plugin purely as an engine, which is the theme of this whole piece.
The Body: Astro
Astro is built for content-heavy sites that are mostly static, which describes an aggregator exactly. A heavier React framework would be the wrong tool for this, as it often is for content sites.
Its defining choice is islands architecture. A page ships as static HTML with zero JavaScript by default, and you opt individual interactive components into hydration only where you need them, with a directive like client:visible or client:load. For a wall of headlines, most of the page needs no JavaScript at all, so most of the page ships none. That is the opposite of a typical WordPress theme, where the framework cost is paid on every page whether or not it is used.
Rendering mode is the next decision, and Astro 5 makes it per-route. Static is the default. You opt a single route into on-demand server rendering with one line in its frontmatter:
---
export const prerender = false
---With a server adapter installed, that route renders per request while the rest of the site stays static. So you are not choosing static or dynamic for the whole site, you are choosing it page by page.
For pulling WordPress content in at build time, Astro’s Content Layer gives you loaders. You write (or install) a loader that reads your WordPress posts and turns them into a typed content collection:
// src/content.config.ts
import { defineCollection } from "astro:content";
import { wordpressLoader } from "./loaders/wordpress";
const articles = defineCollection({
loader: wordpressLoader({ endpoint: "https://cms.example.com/wp-json/wp/v2" }),
});
export const collections = { articles };From then on your pages query articles like local content, and the WordPress origin becomes a detail they never see. This is the build-time path, and for a lot of an aggregator, build-time is the right answer.
Solving the Freshness Problem Properly
Here is where the deep version diverges from the quick guide. A static site freezes its HTML at build time, so a feed item imported a minute after your last build will not appear until something rebuilds. For a site whose entire value is being current, you need a real strategy, and Astro gives you three primitives that map onto three answers.
The first is the scheduled rebuild. Your importer runs on its cron, and after each import you trigger a rebuild, either by firing the deploy hook on a static host like Vercel or Cloudflare or on a timer. The CDN serves static HTML, and your freshness lag equals your rebuild interval. This is the right default when feeds update hourly and you want maximum speed and full indexability.
The second is the server island, and it is the most elegant answer Astro has added. You mark a single component with server:defer so it renders on the server per request and gets slotted into an otherwise static page, with fallback content shown until it arrives:
---
import LatestHeadlines from "../components/LatestHeadlines.astro";
---
<h1>Today in Tech</h1>
<LatestHeadlines server:defer>
<p slot="fallback">Loading the latest…</p>
</LatestHeadlines>The page is static and cached, but that one strip of headlines is live on every request, querying WordPress directly. You get a fast cached shell and a fresh feed in the same page, without rebuilding anything and without shipping the whole route to a server.
The third is the client island: a small component that fetches the latest items from the browser after load. The items update with no rebuild at all.
| Approach | Where it renders | Freshness | Best for |
|---|---|---|---|
| Scheduled rebuild | Build time | Your rebuild interval | The bulk of the site; pages you want fully indexed |
| Server island | Server, per request | Real-time | A live strip on an otherwise static page |
| Client island | Browser, after load | Real-time | Widgets you do not need indexed |
There is a search consideration that settles a lot of these choices. Aggregated feed items are syndicated from other sites. Having Google index them as your own pages is duplicate content, and it can drag your domain down rather than lift it. Rendering the aggregated stream client-side, where search engines do not see it in the initial HTML, keeps your own original pages clean in the index while the feed behaves as a live widget. What looks like a limitation of client rendering is often the correct SEO call for this exact content.
So the real build is a blend. Your own pages and the main archives render static and get indexed. The live strips that need to feel current become server islands. The purely syndicated streams you would rather not have indexed render client-side. Astro lets you make that choice per component, which is the flexibility the whole pattern depends on.
The Connection Layer, and Locking the Engine Down
Astro reads WordPress over HTTP, through the REST API or WPGraphQL. REST needs no extra plugin and covers most needs. WPGraphQL earns its place once you are pulling several related fields and want to avoid over-fetching across multiple REST calls.
Running WordPress as an engine also changes how you secure it. It is no longer a public website, it is an API. You can put it on a subdomain, close the public-facing theme entirely, restrict or firewall wp-admin to your own access, and cache the REST responses hard at the edge. The attack surface that comes from WordPress being a sprawling public front end shrinks when the only thing exposed is a read API feeding your build.
Two operational gotchas come with the territory, and both have bitten people I know. WordPress cron normally fires on visits to the front end, and a headless install has no front-end visitors, so scheduled imports silently stop. The fix is a real system cron hitting wp-cron.php, or wp cron event run over the CLI, with the pseudo-cron disabled. The second is images: set the importer to sideload them at import time so your frontend never depends on the source site staying up.
Where This Goes
The version of WordPress’s future that gets debated most is binary: either it keeps powering 40-something percent of the web forever, or it slowly fades as the front end moves elsewhere. The thinning crowds at WordCamp get read as proof of the second. I think both miss it.
WordPress does not need to own the front end to matter. Its data model, its editor, its taxonomy and user systems, and a plugin ecosystem that has solved thousands of specific problems are real, durable assets. The monolithic theme that renders them is the replaceable part, and replacing it is getting easier every year. A CMS that becomes the engine behind faster frameworks has found the layer it is genuinely best at, and stopped trying to be everything above it.
The news aggregator is just the clearest example because its needs line up so neatly: heavy server-side data work below, fast static rendering above. But the shape generalizes. Plenty of content sites would be better as a WordPress engine with a modern frontend bolted on, and the tooling to do it, Astro’s islands and server-rendering and content loaders on one side, mature import and editing plugins on the other, is finally good enough that you do not have to be a specialist to wire it together.
After 20 years, I find that a more interesting future for WordPress than either the triumphalism or the obituary. Its best role now is the engine behind something faster, and that is a good thing to be.
Related
Leave a Reply