Frequently asked questions

For a site that publishes — a business site, a blog, a magazine — write in WordPress and serve the public site as static files from an edge network such as Cloudflare®, with WordPress kept private and forms, comments and search rebuilt as edge functions. For a shop, a members’ area or a booking site, good managed WordPress hosting with a CDN is still the better choice. The full comparison is in our guide.

Yes. For a new site there is nothing to migrate: we set up WordPress on a private subdomain, the edge in your own Cloudflare account, forms, comments and search as edge functions, and the sync between them, so the site is fast and out of attackers’ reach from its first page. Design and content stay yours, or your designer’s; we build the environment they live in. See pricing.

It is one of the least disruptive. The public site moves to modern infrastructure — static pages on a global network, functions at the edge — without rebuilding what you have, and the ageing WordPress behind it stops facing the public. If WordPress itself needs bringing up to date, the rehearsal on a copy is where we find out, and the quote says what it takes.

No. Headless WordPress replaces your theme with a new front end written in a JavaScript framework, and every template is rebuilt by developers. Here your theme stays: the pages WordPress already renders become static files, and only the dynamic parts are rebuilt.

Today, every visit asks your server to run WordPress and build the page. After the move, your pages already exist as files, copied to Cloudflare data centres around the world, and each visitor is served from the one nearest them. The parts that cannot be files — forms, comments, search — are answered by small functions running in the same places.

No. WordPress stays exactly as it is, at a subdomain, and you and your editors keep writing in it. Publishing a post updates the public site within seconds. The only thing that changes for you is the address you log in at.

Those produce the files, and stop. The files are the easy half. The work is keeping what your site does — its forms, comments, search and whatever is particular to it — working at the edge, and keeping the edge and WordPress in step in both directions, with a nightly check that reports any difference.

Because the half of your site that matters most is the half nobody can see from outside: what your forms collect, what your plugins do, what your theme assumes. Rebuilding that needs administrator access and judgement, not a settings screen — which is also why the assessment is something we run, with access you grant, rather than a tool you run alone.

Shops, members' areas, courses and booking calendars hold live state — a basket, a login, progress, availability — that a mirror cannot. Sites that draw their content with JavaScript cannot be mirrored either. The scan tells you in seconds, and the assessment confirms it, before anything is paid for. We are extending the engine to support them; if your site depends on one, add it in your account and we will work on it with you.

Usually, yes — block themes, classic themes, and builders such as Elementor or Divi — because what is captured is the page your theme renders. The exceptions are widgets that call back to WordPress while a visitor uses them; the scan and the assessment list them, and each is either rebuilt or named as staying on WordPress.

They keep working, answered at the edge, and every submission and every comment arrives in WordPress as a real submission and a real comment — where you already read and moderate them.

Addresses stay the same, and every page keeps its title, description, canonical address and structured data. Each build is checked against SEO, accessibility (WCAG 2.2 AA) and data-protection rules before it goes live. What usually happens to rankings is the effect of a site that got much faster.

The work itself is 3–5 days for a brochure site, 6–12 days for a content site, and 12–20 days for a multilingual or regulated one. The quote gives dates, and the switch itself takes seconds.

The switch is one DNS record, prepared days in advance, so undoing it is changing that record back — seconds, not hours. WordPress is untouched throughout: it has been serving the same content the whole time.

What has to be rebuilt is defined by plugins, forms and templates that no crawl can list. We also need your hosting panel or SSH to move WordPress to its subdomain, and your DNS for the switch — for the length of the project and no longer.

At the end, we list every account and key we used and you remove them. We keep no credentials. While we work, any personal data we can see is covered by a data processing agreement that comes with every quote.

In your own Cloudflare account, until it reaches your WordPress. A form submission waits at the edge only until it is delivered. We do not hold it — which is exactly why hosting in our account is not on sale yet: that would change, and it needs an agreement that does not exist today.

We run commands that read how your WordPress is built: active plugins, theme, forms and their fields, how many pages of each kind. Nothing is changed, your users, comments and submissions are not opened, and no copy of your content is kept. You create the access for us, and you remove it when we are done.

For most sites, nothing: the Cloudflare Free plan covers them. A busy site costs from US$5 a month, billed to you directly by Cloudflare. A care plan from us is optional — see pricing.

Everything runs in your own Cloudflare account, from a repository you own, beside a WordPress you never stopped having. Ending a care plan changes nothing about your site. Going back to serving from WordPress is one DNS record.

Yes — white-label, per site, and 30–40% below the listed prices for recurring volume.

Prices exclude VAT. It is added where the law requires it, and shown on the quote and the invoice.