Cloudflare Rebuilt Its Blog. Should You Rebuild Yours?

What Cloudflare's migration to EmDash tells us about the future of high-performance company blogs

Your company blog probably started as a simple decision: install a CMS and start publishing. That was probably the right call at the time.

But five, seven, or ten years later, the blog looks very different. Thousands of posts. Years of SEO value. Dozens of contributors. A media library that's grown out of control. Plugins nobody remembers installing. A database that gets slower every quarter.

Eventually the question stops being "how do we publish content?" and becomes "is our CMS still the right platform for the content business we've actually built?"

Cloudflare recently answered that question for one of the most heavily trafficked technical blogs on the internet. They migrated to EmDash, a modern CMS built around Astro and Cloudflare's own developer platform — and wrote up the whole migration in their own postmortem. The interesting part isn't that they changed CMSs. It's why, how, and what happened afterward.

We build and maintain web applications on headless CMS stacks for a living — this blog runs on Sanity — so a migration story at Cloudflare's scale is worth reading closely, even if your traffic looks nothing like theirs.

More Than a Redesign

In August 2026, Cloudflare launched a redesigned blog. At first glance it looked cosmetic — cleaner interface, dark mode, a better reading experience. Underneath was a much bigger architectural change: a full move from their previous CMS to EmDash.

Cloudflare frames this as "Customer Zero" — when the company builds a product, it runs that product on real production traffic before asking anyone else to. For the blog, that meant proving a serverless, edge-native CMS could hold up under substantial traffic, a large media library, many authors, localized content, and archives that keep growing.

Why Move at All?

The common assumption is that companies migrate because their CMS is "bad." Usually that's not it. A CMS can be perfectly fine for years — what changes is everything around it. Traffic grows. The content team grows. SEO gets more sophisticated. Engineering wants APIs, structured content, and AI integrations the old platform was never built for. The system that was right five years ago quietly turns into a constraint.

Before committing to EmDash, Cloudflare's team tested the workflows that actually matter day to day: publishing and unpublishing, scheduling, media management, search, author and byline handling, localization, Content Security Policy requirements, and plain editor usability. This wasn't "swap the CMS and hope." It was treated as its own engineering project — which is the same audit we run before recommending a rebuild in our own web application work.

The Architecture Behind It

The new Cloudflare blog runs EmDash on a Cloudflare Worker, with layered caching — Workers Cache plus an object cache built on Workers KV — and a Hyperdrive connection into PlanetScale. It's built around the edge rather than a traditional origin-server model.

The payoff shows up in the numbers: Cloudflare reports serving roughly 99.5% of static files from cache, and around 70% of all requests served from cache rather than hitting the database or application layer directly. The mental model shifts from Browser → Server → CMS → Database to Browser → Edge → Cache → Application → Database — the closer content sits to the visitor, the less work the origin has to do.

The Frontend Got Rebuilt Too

The migration doubled as a chance to modernize the reading experience, not just the backend.

Native dark mode shipped tied to system preferences, with an explicit toggle and accessibility checked across both themes.

They also fixed a small but telling usability problem: the email subscription box used to sit in the top-right corner, where readers kept mistaking it for a search bar and typing queries into it.

It moved into a dedicated call-to-action at the end of each post instead. A reminder that a CMS migration is a good forcing function for cleaning up UX debt that's been sitting there for years, not just a backend swap.

Zero-Downtime by Design

This is the part most migrations get wrong. You can't take a blog with years of accumulated SEO equity offline and hope it comes back intact — URLs break, redirects fail, images vanish, search engines choke on unexpected responses.

Cloudflare built a proxy Worker to route visitors between the legacy blog and EmDash, using a version cookie to decide which experience a given visitor saw, with a fallback path back to the old system if anything went wrong.

Rollout was gradual — 1% → 5% → 15% → … → 100%.

The question wasn't "does the new site work?" — it was "does it work under real traffic, and can we recover cleanly if it doesn't?" That's the same staged-rollout discipline we build into hosting and maintenance work, just at a very different scale.

The Results

The migration produced measurable gains.

The new setup shows a flat, consistent response profile against the old platform's periodic spikes under load, plus the ability to serve hundreds of requests per second. During Cloudflare's Agents Week, the new blog published 28 posts in nine days, pulled in close to 3 million pageviews, and peaked around 450 requests per second — while, separately, the underlying infrastructure absorbed a 28,000 requests-per-second DDoS attack without visitors noticing.

Nobody needs Cloudflare's exact stack to take the lesson: a content platform designed around performance and scale from day one beats one that gets performance fixes bolted on after it's already slow.

You Probably Don't Need Cloudflare's Architecture

Most businesses will never see hundreds of requests per second on their blog. You don't need Workers KV, PlanetScale, Hyperdrive, or a traffic-splitting proxy just to publish. But the underlying principles hold at any scale — fast, secure, search-friendly, easy for your content team to manage, easy for developers to extend, reliable under spikes, and structured well enough to feed AI search and agentic workflows rather than fight them.

EmDash Isn't the Only Option

EmDash makes the most sense for teams already inside the Astro and Cloudflare ecosystem. It's not the only direction modern publishing is heading.

Sanity, which this blog runs on, takes a structured, API-first approach instead: content and presentation live in separate layers, so the same structured content can power a website, a mobile app, documentation, internal tools, and AI-driven search from one source. For teams already building in Next.js, React, or Astro, that separation tends to pay for itself quickly — it's the model behind most of the web application work we do, and it's why "which CMS" is one of the first questions we ask on any new build, not the last.

Sometimes EmDash makes sense. Sometimes Sanity does. Sometimes your current CMS is still exactly right. The goal was never "replace it because it's old" — it's choosing the architecture that fits the business you actually have today.

The Real Blocker Is Usually the Content

For most companies, the reason they don't migrate isn't technical. It's the eight years of posts, the thousands of images, the internal links, the backlinks, the indexed URLs. That content is an asset — a migration that quietly destroys it isn't an upgrade, it's a loss.

Treating content migration and SEO preservation as first-class engineering work means planning for URL preservation, redirect mapping, metadata continuity (titles, descriptions, canonicals, Open Graph, structured data), media migration, internal link integrity, a clean sitemap, ongoing search-performance monitoring, and a real rollback path if something breaks. A CMS migration isn't a content export — it's an infrastructure migration, and we scope it that way whether it's a blog or a full commerce platform.

Is It Time to Look at Yours?

If your current blog is fast, secure, and easy to maintain, you may not need to touch it. But it's worth asking a few honest questions: Is the CMS slowing down your dev team? Does it need more plugins every year just to do the basics? Is your frontend constrained by it? Are hosting costs climbing faster than your traffic justifies? Is your content hard to reuse anywhere outside the website? Would structured content and real APIs actually help your team? Are you keeping technical debt around mainly because migrating feels risky?

A few "yes" answers there is usually a good enough reason to at least evaluate the alternatives.

Thinking About Migrating Your Blog?

At Webloom Labs, we help businesses modernize legacy websites and content platforms without throwing away the years of content and search authority they've already built. We look at content architecture, SEO preservation, URL and redirect strategy, performance and frontend work, CMS selection, media migration, AI and automation integration, and rollback planning — not just moving rows from one database to another.

Take a look at our recent work, or talk to us about what a migration would actually look like for your blog.