Moving your WordPress site to Cloudflare: what it actually involves

You have a WordPress site. You are tired of plugin update notices, the occasional hacked-site scare and hosting bills that go up every renewal. Someone told you that modern sites run on Cloudflare now and load instantly. Fair question: can you actually move, what breaks, and how long does it take?

Short answer: yes, you can move. Most of the pain sits in one step (getting your content out of WordPress and into a clean format), and the job is closer to a rebuild than a house move. Here is what it really looks like, including the parts that bite.

What “moving to Cloudflare” actually means

Cloudflare is not a WordPress host. You do not upload your PHP site there and carry on. Instead your site gets rebuilt as a modern site that Cloudflare serves from its network: the pages are prepared in advance rather than assembled by a database on every visit, images sit in Cloudflare’s file storage (R2), and any live data sits in its database service (D1). There is no server to patch, and nothing to keep running when nobody is visiting.

There are a few common destinations:

• A modern static site (usually built with Astro, sometimes Next.js or Hugo). Your pages and posts become content files. It is fast, cheap and boring in the best sense. Good for brochure sites, portfolios and blogs that do not change hourly.
• EmDash, Cloudflare’s own open-source CMS, released under an MIT licence. Cloudflare describes it as a “spiritual successor to WordPress”. It is built on Astro 6 and runs on Workers, with content in D1 and files in R2. If you want an admin panel to write in, this is the closest thing to WordPress on Cloudflare.
• A headless CMS plus a Cloudflare-hosted front end, if you already pay for something like Sanity or Contentful and want to keep it.

None of these is “the” answer. The right one depends on how often your content changes and who edits it.

The honest map of the work

Before anything else, here is where the time actually goes:

If you take one thing away: budget for the content cleanup. Everything else is smaller than it looks.

Step 1: get your content out

WordPress is generous here, which is the one real advantage of leaving it. In the admin, Tools, then Export, then All content produces a single XML file. The format is called WXR (WordPress eXtended RSS) and it holds your posts, pages, categories, tags, comments, custom fields and the list of media attachments.

Two things it does not hold:

• The image files themselves. WXR records the URLs, not the pictures. Your actual files live in wp-content/uploads on the server and have to be downloaded separately, usually over FTP or from your host’s file manager.
• Your theme and plugin settings. Menus, widget placement, theme options and plugin configuration do not travel.

There is a second route worth knowing about, because it changes the quality of what you get. WordPress also exposes your content through its REST API (the /wp-json/ address on your site), and that version of the content has already been processed by WordPress: shortcodes expanded, filters applied. If your site was built with a page builder such as Elementor, Divi or WPBakery, that processed output is a thicket of nested div elements and inline styles. Pulling the raw content straight from the database usually gives cleaner material to work from. This is exactly the kind of judgement call a developer, or we, would make on your behalf.

Step 2: clean up the content (the real work)

WordPress keeps each post as one lump of HTML with whatever markup accumulated over the years. A modern site wants structured content: a heading is a heading, an image is an image with a caption, a quote is a quote. Getting from one to the other is where the hours go.

The things that reliably cause trouble:

• Shortcodes. Square-bracket things like [gallery], [caption] or anything a plugin added. They are WordPress-only syntax and render as literal text everywhere else. Each one needs a decision: recreate it, convert it, or drop it.
• Page-builder markup. Pages built in Elementor or Divi are often not worth untangling. For a heavily designed landing page it is faster to rebuild it in the new design than to salvage the HTML.
• Inline styles. Years of pasted-in colours and font sizes. These get stripped, because in a modern site the look lives in the design, not buried inside each paragraph.
• Embeds. YouTube videos, maps, Instagram posts and form widgets each need a new home.

Nobody automates this to 100%, and anyone promising otherwise has not looked at your posts. The realistic pattern is to convert the straightforward 90% in bulk, then go through the odd ones by hand. AI agents are genuinely good at this now, which is a large part of why the job costs less than it did two years ago.

Step 3: move the media

Download your uploads folder, then upload it to Cloudflare’s R2 storage. The important detail is not the upload, it is the bookkeeping: every image URL inside your content still points at the old site, so you need a map of old address to new address and one pass to rewrite them all. Miss this and you get a site that silently loads its images from the server you are trying to shut down.

One genuine ongoing saving: R2 charges nothing for bandwidth out. On a metered WordPress host, a post that goes viral costs you money. Here it does not.

Step 4: rebuild the design

Your PHP theme does not come along. On a modern site the design is built from components, so this is a rebuild rather than a port. In practice that is usually good news: most WordPress themes carry a decade of accumulated weight, and the rebuilt version is typically several times faster. If you like your current look, it can be reproduced fairly closely.

Then the awkward inventory. Open your plugins page and write down every active plugin and what it actually does for you. Contact forms, SEO metadata, sitemaps, redirects, cookie banners, booking, membership, ecommerce. On the new site each of those becomes either a built-in feature, a small piece of code, or a third-party service. Most have a clean answer. A few, notably full ecommerce and complex membership sites, do not yet, and it is better to find that out now than halfway through.

Step 5: go live

The deployment itself is refreshingly dull, which is the point. The site gets published to Cloudflare, your domain gets pointed at it, and that is it. No server to configure, no PHP version to worry about, no security updates arriving forever. This is the part that takes an afternoon rather than a fortnight.

Do not skip: keep your URLs

This is where migrations quietly wreck search rankings. Every address that Google already knows about, and every link pointing at your site from elsewhere, should still work afterwards.

The routine is simple and non-negotiable:

1. Crawl the old site first and save a full list of every public address, before you change anything.
2. Keep the existing address structure wherever you can. On a modern site you control the routing, so there is rarely a technical reason to change /2019/07/my-post/ into something else.
3. For anything that genuinely must change, set up a 301 redirect from old address to new.
4. Resubmit your sitemap in Google Search Console after launch, and watch the coverage report for a few weeks.

Do this properly and traffic dips for a week or two, then recovers. Skip it and you start from zero.

The sharp edges, honestly

A modern Cloudflare-hosted site is faster, cheaper to run and far less fragile than WordPress. It is not free of trade-offs.

• There is no plugin marketplace. WordPress has roughly sixty thousand plugins. Anything niche you relied on may need a bespoke replacement.
• You cannot fix it by clicking around. Structural changes go through code, which means either a developer or a service that handles it.
• EmDash specifically is young. Cloudflare launched it as a developer preview in April 2026, with v1.0 arriving around its Birthday Week in late September. The plugin ecosystem is small and the docs are still being filled in. Its sandboxed plugins also need a paid Cloudflare account, from about five dollars a month.

If you want the fuller comparison, see EmDash vs WordPress, or the wider field in the best WordPress alternatives for 2026. Leaving a closed builder instead? The same logic applies with different export options in our guides to leaving Wix, leaving Squarespace and leaving Joomla.

At 2emdash we do this for people who would rather not do it themselves: we rebuild your existing site on Cloudflare and hand you a simple panel to run it from. We’re an independent service, not affiliated with Cloudflare or the EmDash project.