Blog

Choosing a headless CMS is as much an organisational decision as a technical one. In this article we share the criteria that led us to pair WordPress with Astro: a mature editorial workflow, granular role management and a large plugin ecosystem on the content side; type-safe components, partial hydration and zero-JS-by-default on the rendering side.

• Editors keep the tools they know.
• Developers ship features faster with TypeScript and Astro components.
• Visitors get pages that stream from the server with minimal client JavaScript.

The result is a stack that scales with the team rather than against it.

A quick tour of the src/lib/wordpress.ts client that powers every content-driven page on the ITFB website. The client wraps undici.fetch with an optional DNS lookup override, which lets the Astro server reach WordPress even when the vhost name is not resolvable locally.

High-level API:

• fetchPosts(locale, limit?) — latest published posts.
• fetchPostBySlug(slug, locale) — a single article.
• fetchServices(locale) — entries of the service custom post type.

All functions fail closed: on network or HTTP errors they return empty arrays or null, so pages degrade gracefully instead of crashing.

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

ITFB successfully rolled out a new headless architecture combining WordPress as a content backend with Astro 6 SSR on the frontend. This separation lets editors keep the familiar WordPress UI while the public site gains fast server-side rendering and a modern component model.

The integration relies on the standard WP REST API (/wp-json/wp/v2) plus a small must-use plugin that injects ACF-style fields and Polylang language filtering.