Webflow Migration to Cloudflare: DNS, Proxying and the Cache Settings That Break Publishes

A Webflow migration to Cloudflare has a hard date behind it. Since 13 January 2026, Webflow will not publish to a custom domain that still points at its legacy DNS records; the old site stays live, but every change is blocked until the records are updated (Webflow Help Center, updated May 2026). Sites created after 21 April 2025 are already on the new setup.

This guide covers the DNS records, the order that avoids SSL errors, and the cache settings that let a publish succeed while visitors keep seeing yesterday's page. Platform facts come from the Webflow Help Center and Cloudflare's documentation, read on 5 November 2026; the header check is our own.

What a Webflow migration to Cloudflare actually involves

Webflow moved the secure connections for its hosting to Cloudflare, citing DDoS mitigation and faster global response times. For most site owners the visible part is a DNS change. Webflow offers an automatic migration as well as a manual one, and if no Dashboard prompt appears, the correct records are in Site settings, Publishing, Production.

The second meaning is a choice, not a deadline. Many B2B teams already run their domain's DNS in Cloudflare, and some want Cloudflare's firewall, bot controls or Workers in front of the marketing site. That is now supported, but only in one configuration, and it changes who is responsible when something goes wrong. Webflow says plainly that its Support team cannot help with setting up or troubleshooting third-party proxies; it can only confirm that the Webflow origin responds correctly.

A disclosure: we build marketing sites in Webflow, so we have an interest in Webflow hosting working well.

Grey cloud, orange cloud or a full reverse proxy

There are three ways to run a Webflow site with Cloudflare involved, and the first decision is which one you are building.

For most marketing sites the grey cloud is the right answer: Webflow's own Cloudflare layer handles certificates and caching, and there is one cache to think about. Choose O2O only when you need a specific feature from your own zone and someone on your side will own it.

The third setup is for a different problem. Webflow notes that O2O "is not a full reverse proxy": it proxies at the DNS layer. Serving Webflow pages at `example.com/blog` while the rest of the domain runs elsewhere still needs a Worker or another edge function to rewrite paths. Webflow also forbids proxying the `webflow.io` staging subdomain, which it says breaches its Terms of Service.

The DNS records, step by step

Start by moving the domain's nameservers to Cloudflare if they are not there already. Webflow warns that a nameserver change can take up to 48 hours, and asks you to wait until a checker shows the new nameservers in every location before you add records.

Three details catch people. First, two A records or `proxy-ssl.webflow.com` are the legacy records and must be replaced before the proxy goes on. Second, O2O is built on CNAME records. Cloudflare's own documentation says O2O does not apply when an A record points at the provider, so the apex record changes type when you move from grey to orange. Cloudflare accepts a CNAME at the apex through CNAME flattening, which answers with the final IP address. Third, add a record for every hostname you publish.

Then, in Webflow, go to Site settings, Publishing, Production, connect the domain, verify it, set the default domain and publish. With O2O on, the domain may keep showing "Update needed". Webflow says that is expected, because the proxy hides your records from its check, and no action is needed if the site loads.

Before you change anything, lower the TTL and plan the way back. Our guide to what Webflow migration services should include covers the rollback plan, and the website migration SEO checklist covers the redirect map, which a DNS change on the same domain does not touch.

SSL: the order that avoids 525s and redirect loops

The 525. Cloudflare returns Error 525 when the SSL handshake between Cloudflare and the origin fails while the zone is in Full or Full (Strict) mode. On Webflow, both Webflow's and Cloudflare's pages point to the same cause: the proxy was switched on for standard Webflow records, or before Webflow had issued a certificate.

The order Webflow asks for. Point the records at `cdn.webflow.com`. Set them to DNS only. Wait until Webflow shows SSL as active for every domain. Only then switch the proxy back on and set the zone's encryption mode to Full (Strict). Webflow says no Enterprise plan and no custom certificate are needed for this.

Why not Flexible. Flexible mode sends requests from Cloudflare to the origin over plain HTTP. Cloudflare's troubleshooting page says this loops whenever the origin redirects HTTP to HTTPS, which is the ERR_TOO_MANY_REDIRECTS error. Full (Strict) also checks that the origin's certificate matches the hostname, which is the stronger guarantee.

CAA records. If the zone has CAA records, they must allow Let's Encrypt and Google Trust Services, the two authorities Webflow uses. Otherwise certificates fail to issue or, worse, fail to renew months later.

Zone holds. Enterprise Cloudflare zones can turn on a zone hold, which blocks Webflow from issuing certificates. Webflow warns this can stop a site going live or take a published site down during migration. Release the hold, let the certificate issue, then turn it back on. If only a subdomain is being connected, Cloudflare says only the "Also prevent Subdomains" option needs to be released.

The cache settings that break publishes

This costs the most time, because nothing looks broken: Webflow reports a successful publish, staging shows the change, and the live domain serves the old page.

The reason is that there are two caches. Webflow already runs its own Cloudflare layer and clears it when you publish. In its reverse proxy guide, Webflow describes the "double cache problem": a publish purges Webflow's Cloudflare cache but not a second cache placed in front of it, so visitors keep getting stale content. Webflow's example is CloudFront, but under O2O your own Cloudflare zone is exactly such a second layer, and Cloudflare's compatibility table says caching there is "generally discouraged (especially for HTML)" because the provider caches on its own and the two can fall out of step.

Out of the box this is not a problem. Cloudflare's default is not to cache HTML or JSON at all. The trouble starts with settings people add for speed.

We checked the response headers of five Webflow-hosted homepages and one Webflow staging subdomain on 5 November 2026. All six carried a `surrogate-control` header aimed at intermediary caches, five of them at 432,000 seconds, which is five days. Only one also sent a `cache-control` header for browsers: `max-age=86400`, one day, on the custom domain of a white-label site we work on. The same site's staging subdomain did not send it, which points to a setting on the client's own Cloudflare zone rather than Webflow. On that site we have seen a publish that was correct at the origin stay invisible on the plain URL for hours, until the client purged the cache from their Cloudflare dashboard. Nothing on the Webflow side can purge the client's zone.

The fix is a decision about ownership. If your team publishes often, do not cache HTML on your own zone. If you must, make the purge part of the publish routine, with a named person who has access to the Cloudflare account.

How to check that a publish reached visitors

Do not trust the publish button, and do not trust the purge button either. Cloudflare says a successful purge returns HTTP 200, which only means the request was received; it does not confirm that anything was evicted. The check is in the response headers.

Compare origin and edge. Request the page twice with `curl -I`: once as it is, once with a throwaway query string such as `?cb=123`, which usually misses the cache. If the cache-busted copy shows the change and the plain one does not, the publish worked and a cache is in the way.

Read `CF-Cache-Status`. `HIT` with a large `age` value means an edge copy is being served, and only a purge or the expiry will help. `MISS` or `DYNAMIC` on the cache-busted request means Cloudflare went to the origin, so stale content there points at the publish itself.

Confirm O2O is active. Cloudflare says there is no API field or zone setting that shows O2O is on. It is decided per request by your DNS. Traffic arriving at the provider's zone through O2O carries the header `cf-connecting-o2o: 1`, which a Worker can read if you need proof.

Mind the purge limits. Cloudflare rate-limits purges by plan. On the Free plan the bucket refills at five requests a minute with a capacity of 25, so a script that purges URL by URL after a large publish can stall.

Other quiet failures during the move

A previous host on Cloudflare. If the domain was last on a platform that also runs on Cloudflare, such as Shopify or WP Engine, remove it there first or Webflow may fail to verify the domain. Going the other way, remove the domain from Webflow at least five minutes before verifying it with the new provider.

Speed expectations. Putting your own zone in front of Webflow is not a speed upgrade by default; Webflow already serves through Cloudflare. If load time is the goal, our list of Webflow page speed fixes covers the changes that move Core Web Vitals.

What this means for your Webflow migration to Cloudflare

If your site still points at the legacy records, the migration is not optional: publishing is already blocked, and the fix is the two records in the first table. Keep them on the grey cloud unless you have a named reason to proxy. If you do proxy, set it up as O2O, validate SSL before the orange cloud goes on, use Full (Strict), and keep HTML out of your own zone's cache. Then agree who holds the Cloudflare login, because whoever can purge the cache decides when a publish is really live. When we take over a Webflow site, we would expect to ask for that access, or a purge contact, before the first change ships. Our marketing websites service page explains how we scope builds and migrations.