Service pillar

Astro developer

Senior B2B, EU jurisdiction, scoped per project.

Pricing is individual. I reply within one working day.

Start an engagement Long-form Astro landing →

What I ship

Astro 5+ as the front end. WordPress 6.7+ as the editorial back end, communicating over REST or GraphQL. Cloudflare Pages for static and SSR. TypeScript across the stack. Tailwind CSS for the design system. MDX for editorial flexibility where authors need it. Anthropic Claude and Model Context Protocol when AI features earn their keep.

Why Astro for headless WordPress

Astro's minimal-JavaScript model is the right baseline for content sites. Most pages on a content-led WordPress site have one or two interactive elements (a search box, a navigation menu, a contact form) and otherwise are pure HTML. Astro ships only the JavaScript those interactions need; everything else is static HTML rendered at build time or per-route SSR.

For high-traffic content sites, the cost shape matters. Static Astro pages serve from edge cache with near-zero CPU per request. The carbon and bandwidth footprint is significantly lower than equivalent Next.js SSR. For sites where interactivity is the product (dashboards, transactional commerce, real-time feeds), I recommend the Next.js pillar instead.

Who this is for

  • Publishers and content sites with editorial workflow on WordPress
  • Content-led WooCommerce catalogues where commerce is a small surface within a larger content site
  • Documentation portals and developer-facing technical sites
  • Marketing sites that need fast LCP and minimal JavaScript on mobile

Engagement model

Senior B2B contracts on EU jurisdiction. Discovery, scoping, fixed-scope or time-and-materials engagements. Pricing is individual.

Read path on the edge, write path on the origin. Cache invalidated by webhook tags. Reader / agent sends a request to Cloudflare Workers (edge). On cache hit the Edge cache (per-tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the WordPress origin and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook on publish that invalidates relevant cache tags. Reader / agent Cloudflare Workers (edge) Edge cache (per-tag) cache hit (almost no CPU) cache miss → render at edge WordPress origin Block Editor + WP Admin REST API /wp-json/ Publish / slug change / stock Read Read Webhook on publish Write
Read path on the edge, write path on the origin. Cache invalidated by webhook tags.
The default of zero JavaScript per page is not a feature; it is the architectural commitment that makes everything else cheaper.
Fred K. Schott , Astro creator , Astro Together 2025 , 2025-09-22 , source

Frequently asked questions

When does Astro win over Next.js for headless WordPress?

Content-heavy sites with predictable update cadence and minimal interactivity per page. Marketing sites, blogs, documentation portals, content-led WooCommerce catalogues. Astro ships zero JavaScript by default; interactive parts are opt-in islands. Next.js wins for personalised, session-driven, or transactional flows.

What is the islands architecture in practice?

Each interactive component is a separate island that hydrates independently, with its own JavaScript bundle. The rest of the page is static HTML. The result is faster TTI on slower networks because the browser only parses JS for the islands the user actually sees, not for the whole page.

Does Astro support React, Vue, and Svelte components in the same project?

Yes. Astro is framework-agnostic. I typically use Astro components for the HTML structure and React for any interactive islands; the choice is per-component. Mixing is supported but rarely needed in production engagements.

How does Astro perform on Cloudflare Pages?

Excellent for static and ISR-style content. Astro's pre-built HTML output serves from the edge cache at near-zero CPU. SSR routes use the Cloudflare adapter and run as Worker functions. I benchmark per engagement; static is the cheapest mode.

Can you migrate a WordPress monolith to Astro?

Yes. WordPress stays as the editorial back end, Astro becomes the front end via REST or GraphQL. Content preservation, URL mapping, hreflang, sitemaps, and structured data all carry over. Migration timeline is typically 6 to 16 weeks depending on catalogue size and integration count.

Proof through content migration

Astro is strongest when content, URL stability and publishing workflow matter more than client-side application state. The anonymised proof layer shows the migration mechanics without exposing client names.

Cluster reading

Architecture and decision

Migration and timelines

Long-form landing

Reference

Start an Astro engagement

Tell me the scope and timeline. I reply within one working day.

Contact me