← Back to the blog
AI-Native Websites

We Swapped WordPress for Cloudflare, Astro, and Claude Code. Here's Why.

9 min read · English

If none of those names mean anything to you yet, that's fine, they're just tools. This is the story of moving one real business's website, ESGready, an ESG transformation consultancy for the German Mittelstand, onto a newer stack: Astro, Cloudflare, and an AI coding tool called Claude Code. It's written for someone who isn't a developer but is curious what a move like this actually involves. (Want the full numbers and timeline? The detailed case study covers all of that; this piece is the shorter, teaching-focused version.)

1. Why now

ESGready's founder, Frank Siebke, was winning work through direct outreach and conference talks, and by August 2026 the company was also getting named in trade articles under its new positioning. The momentum was real. The website hadn't caught up to it yet, findability and load speed both had real room to grow, and a webinar was nine days out.

Frank had already sketched a redesign himself with a single AI prompt, a genuinely good starting point for direction and content. Its real limitation for getting found wasn't that it used JavaScript, Google can render JavaScript, it was that everything lived on one page rather than a set of separate, addressable pages that search engines and AI systems could each find and link to individually. Great vision, the wrong shape for discovery that works page by page.

Before: one long page holds every topic under a single address. After: more than twenty separate pages, each with its own address and a structured-data tag, so search and AI systems can find and read each one on its own.
One address for everything vs. more than twenty pages that can each be found, linked, and understood on their own.

That's the real trigger: not "WordPress is old," but "we have nine days, real momentum to back up, and a draft that needs a different shape to be found."

2. What changed, concretely

The new stack has a few pieces, and each one does a specific job:

The site went live inside the nine-day window, ahead of the webinar. (Full build timeline, screenshots, and every number: see the case study.)

3. Where the new setup is clearly better

Not "faster" or "more secure" as vague adjectives. Here's the actual mechanism behind each claim.

Before: a web server builds the page on every visit while the visitor waits. After: pages are built once, copied to data centers worldwide, and each visitor gets a finished page from one nearby. Lighthouse performance on this site: 19 to 100.
Built on every visit vs. built once and served from nearby. Lighthouse performance on this site went from 19 to 100.

Speed. ESGready's previous setup rendered each page on request. The new site's public pages are prerendered once, ahead of time, and served as finished HTML from whichever Cloudflare data center is closest to the visitor. Measured with Lighthouse: this specific site went from a performance score of 19 out of 100 to 100. That's this migration's measured result, not a guarantee that every WordPress site is slow or that every Astro site scores 100 (a well-cached WordPress setup can also be fast).

Findability. One page became more than twenty separate, addressable pages, each carrying structured data describing its content. That makes the content easier for search engines and AI systems to discover and interpret. It doesn't by itself guarantee indexing, search rankings, or being cited in an AI-generated answer.

Security. The public pages are read-only, with no database and no plugins behind them, which removes a category of attack surface common to WordPress sites. The CMS login page is still a public address anyone can find. It has no password of its own, though: it hands off to a GitHub login, so what keeps strangers from editing the site is the GitHub accounts with access to the project (with 2-factor login on, and as few people as possible), plus private deploy keys. The tradeoff is fewer public-facing things to patch, not zero security work.

Preview before publish. On this project, every change gets a real preview URL before it touches the live version, with one-click rollback available if something needs adjusting. That's how this team works, not an automatic property of every Astro or Cloudflare site, and WordPress can support a similar staging habit too, it's just not the default.

Hosting cost. At ESGready's traffic level, Cloudflare hosting costs close to nothing against the roughly 10-euro-a-month WordPress plan it replaced. That's this site's actual comparison, not a universal rule: Cloudflare bills static assets and Worker requests separately, and hosting cost is only one part of the total cost of running a site.

4. A real bump in the road, and what it taught us

Here's the part most comparison posts skip: this stack doesn't fail the way WordPress fails. It fails in its own, different ways, and finding one of them was a genuinely interesting few hours of detective work.

Shortly after the CMS went live, its login page started showing a "page not found" message in every real browser, while command-line tools checking the same address got the correct page back every time. That mismatch made it look like a caching issue at first. The real cause turned out to be a routing setting: Cloudflare's static file server was answering browser page requests directly with the not-found page, without ever handing the request to the application code that would have served the CMS correctly. Command-line tools request pages differently than browsers do, so they sailed right past the very thing that was broken.

A browser request was stopped by Cloudflare's file server and answered with a 404, while a command-line request to the same address slipped through to the app code and worked. The one-line fix sends that address to the app first.
The browser got a 404 from the file server; the command line slipped through to the app. The fix: send that address to the app first.

The fix was a one-line configuration change. Worth naming honestly: this project doesn't run an automated test suite, so catching this depended on someone noticing and looking closely, not on an automated check catching it first. That's a genuinely useful thing to know about this way of building, and it's now a documented lesson for the next project.

5. Where WordPress was genuinely easier

None of that disappears just because this migration made the site faster, less exposed on the public side, and easier to find. It's a real tradeoff, not a one-sided win, and not every WordPress site is necessarily slow, insecure, or expensive, a well-configured one can avoid several of these tradeoffs too. Likewise, Keystatic's limits described here reflect how it was configured for this project, not a hard ceiling on what an Astro-based site can support with more CMS setup.

6. The actual tradeoff, in one sentence

WordPress optimizes for "any non-technical person can change anything through a login screen," and pays for that flexibility in speed, security, and ongoing maintenance, depending on how it's set up.

This stack, as built for ESGready, optimizes for pages that are fast to serve, a smaller public-facing attack surface, low hosting cost at this traffic level, and content that's easier for search and AI systems to find and parse, and it asks for a developer or an AI coding tool in the loop for anything beyond routine content edits, with its own unfamiliar failure modes to learn along the way.

Neither of those is the "better" choice in the abstract. They're built for different priorities, and this stack wouldn't suit a business that wants full visual control over layout and new page types with zero developer involvement, which is a real thing to want.

7. How to weigh this for your own site

If this tradeoff sounds familiar, here's how to apply it instead of just nodding along.

Ask yourself what "editing the site" means to you day to day. Swapping a headline or an FAQ answer is one thing. Building a new landing page from scratch, or rearranging a whole section, is a different thing entirely. Be specific about which one you actually do.

If the answer is "I want to change anything myself, with zero help, whenever I want," that's a real preference, and WordPress (or a similar CMS with a visual editor) is built for exactly that. The tradeoff tends to be a larger attack surface to maintain and hosting bills that scale with traffic, though how much depends on how the site is set up and kept updated.

If the answer is "I mostly want the site to be fast, cheap to host, hard to break on the public side, and easy for search and AI systems to find and parse, and I'm fine looping in a developer or an AI tool for anything bigger than a text change," a stack like Astro on Cloudflare fits that better. The cost is independence, and a different set of failure modes you'll need someone technical to diagnose when they show up.

Either way, ask one more question before deciding: who is actually going to touch this site after launch, and how often? A solo owner making occasional tweaks has different needs than a five-person marketing team publishing daily. The right stack follows from that answer, not from which one sounds more impressive.

A decision flow starting from 'Who edits the site, and how often?', leading either to a visual-editor CMS like WordPress (you pay with more upkeep) or a prerendered stack like Astro on Cloudflare (you pay with needing help for bigger changes). Tip: count how often you change layout, not text.
Not sure which side you're on? Count how often you change layout, not text.

8. What was true for ESGready

For ESGready, at this moment, the tradeoff was worth making. Page speed, a smaller public-facing attack surface, content that's easier for search and AI systems to find and parse, and a lower ongoing hosting cost mattered more than full visual control over layout, and Frank knew going in that the CMS covers routine edits, not full page building.

On the speed difference, in Frank's own words: "you can never achieve that with WordPress." That's Frank's own experience and reaction, worth keeping exactly as he said it, not a technical rule to adopt as this piece's conclusion; a well-optimized WordPress site with proper caching can also be fast. What's specific and verified here is this migration's measured Lighthouse result and Frank's own words about it.

That won't be true for every business, and it doesn't need to be. The point of this piece isn't "switching stacks guarantees these results." It's "here's what this stack suited ESGready's priorities and produced, here's what we actually traded for it, and here's one honest bump along the way, so you can weigh the same trade for your own situation." (For the full story, numbers, and before/after screenshots: the case study.)


Frequently Asked Questions

Is a static site on Cloudflare cheaper than WordPress hosting?

Often, but not automatically, Cloudflare bills static assets and Worker requests separately, so the exact cost depends on the site. In this case, hosting dropped from a roughly 10-euro-a-month WordPress plan to close to nothing at ESGready's traffic level. Hosting cost is also only part of the total cost of running a site.

Can a non-developer edit an Astro site the way they'd edit WordPress?

Partly. A git-backed CMS layer (Keystatic, in this case) can let a non-developer edit predefined content, FAQ entries, testimonials, page copy, through a form-like interface, and the founder here was trained to run it himself. What it doesn't give you is WordPress's Gutenberg editor: the ability to build a brand new page or rearrange a layout freely. That part still needs a developer or an AI coding tool.

Does migrating from WordPress to Astro hurt SEO rankings?

It doesn't have to, though no migration guarantees unchanged rankings. Setting up relevant permanent redirects for every old URL helps preserve access and ranking signals, so visitors and search engines land on the new page instead of hitting a dead link. In this migration, 21 legacy URLs were redirected in a single hop.

Is Claude Code a replacement for a WordPress page builder plugin?

Functionally, it fills a similar role: it writes and edits page layouts on request. The difference is what happens behind that request. A page builder plugin changes a database row on a live site. Claude Code changes source files, which then go through a preview URL and a review step before anything goes live.

Is a static site more secure than WordPress?

The public pages typically have less to attack: they're read-only, with no database and no plugins behind them, which removes a category of attack surface common to WordPress sites. That's not the whole picture. The CMS login page is still publicly reachable; in this setup it hands off to a GitHub login, so the GitHub accounts with access to the project (2-factor on, few people) and private deploy keys are what need securing. A well-maintained WordPress site can still be reasonably secure.

Does a static site on Cloudflare ever break in production?

Yes, just in different ways than WordPress does. One migration hit a routing quirk where a server-rendered admin page returned a "not found" message to every real browser while command-line tools got the correct response. A one-line configuration fix resolved it. Worth knowing: without an automated test suite, catching that kind of thing depends on someone noticing, which is exactly what happened here.

What's the biggest downside of leaving WordPress?

Independence. On WordPress, a non-technical owner can rearrange a whole page themselves. On a stack like Astro and Cloudflare, most changes beyond routine content edits through a CMS layer need a developer or an AI coding tool in the loop.


References and further reading

Everything this article claims, you can check yourself. The first link has the full ESGready numbers; the rest are the official docs behind each technical point, and a good place to start if you want to go deeper on one topic. All links checked on 30 September 2026.

#SourceWhat you'll find thereRelevant to
1ESGready case study (Mindful AI Academy)The full project story: the nine-day timeline, Lighthouse 19 to 100, the 21 redirects, before/after screenshotsSections 1 to 3, 8
2On-demand rendering (Astro docs)Astro builds pages as static HTML ahead of time by default, and how to switch single pages to on-request renderingSections 2, 3 (Speed)
3Lighthouse performance scoring (Chrome for Developers)What the performance score measures and how it's weighted, so you know what "19 to 100" meansSection 3 (Speed)
4Cache (WordPress Advanced Administration Handbook)How caching plugins and server caches serve WordPress pages as static files, the reason a well-cached WordPress site can be fast tooSection 3 (Speed)
5Understand the JavaScript SEO basics (Google Search Central)Google does render JavaScript, and what still makes JavaScript-heavy pages harder to indexSection 1
6Introduction to structured data markup (Google Search Central)What structured data is, and why it makes pages eligible for richer results without guaranteeing themSection 3 (Findability)
7Keystatic GitHub mode (Keystatic docs)How the /keystatic login hands off to GitHub, and that only people with write access to the repository can get inSection 3 (Security), Section 5
8Configuring two-factor authentication (GitHub Docs)Step-by-step setup of 2-factor login for the GitHub accounts that guard the CMSSection 3 (Security)
9Hardening WordPress (WordPress Advanced Administration Handbook)The official checklist for keeping a WordPress site secure: updates, plugins, admin access, backupsSection 3 (Security), FAQ
10Previews (Cloudflare Workers docs)How preview URLs let you check a change in a production-like copy before it goes liveSection 3 (Preview before publish)
11Billing and limitations for static assets (Cloudflare Workers docs)Static file requests are free and unlimited; running Worker code is billed separatelySection 3 (Hosting cost), FAQ
12Worker script routing (Cloudflare Workers docs)The run_worker_first setting: the one-line fix from the bug story, and why it decides whether a request reaches your codeSection 4
13How to move a site (Google Search Central)Google's migration guide: permanent (301/308) redirects, and why rankings can fluctuate for a while after a moveFAQ (SEO rankings)
14WordPress Block Editor (WordPress.org)The Gutenberg editor that lets anyone build and rearrange pages visuallySection 5
15Claude Code overview (Claude Code docs)What Claude Code is, how it edits files and works with git, and how to get startedSection 2

Wondering whether a move like this fits your own site? Let's look at how you actually edit it, and what you'd trade.

See AI-Native Websites