Cloudflare

Webflow handles hosting, SSL, and CDN delivery out of the box. But it does not give you direct control over DNS proxy behavior, web application firewall rules, bot management, or server-side compute at the edge. If your domain lives in Cloudflare, you need a reliable path to connect it to Webflow without breaking SSL or creating redirect loops.

Cloudflare fills that gap by managing DNS resolution, proxying traffic through its global network, and running serverless Workers that add dynamic logic to otherwise static Webflow pages. Together, the two platforms let you point a Cloudflare-managed domain to Webflow, apply WAF and caching rules at the edge, embed bot protection on forms, and build API-powered workflows between Webflow CMS events and Cloudflare services.

This integration is relevant to freelancers launching client sites on Cloudflare-managed domains, agency teams managing security and performance across multiple Webflow projects, enterprise IT managers enforcing WAF policies on marketing pages, and full-stack developers who need edge compute alongside Webflow's visual development workflow.

How to integrate Cloudflare with Webflow

What is Cloudflare? Cloudflare is a connectivity cloud platform that provides DNS, CDN, DDoS protection, web application firewall, SSL/TLS, and serverless compute services across a global network spanning 330+ cities. It operates as both a DNS provider and a reverse proxy, giving site owners control over how traffic reaches their origin servers.

Teams connect Cloudflare and Webflow when they manage domains through Cloudflare's DNS and need to point those domains at Webflow-hosted sites. The combination becomes especially useful when you need WAF rules, bot management, edge caching, or Workers-based server-side logic that Webflow's native hosting does not expose.

The Cloudflare-Webflow integration supports 5 approaches:

• DNS configuration connects your Cloudflare-managed domain to Webflow without writing code.
• Orange-to-Orange (O2O) proxy mode layers Cloudflare security and caching features on top of Webflow hosting.
• Custom code embeds add Cloudflare Turnstile and Web Analytics to your Webflow pages.
• Automation platforms connect Webflow events to Cloudflare actions.
• The Webflow and Cloudflare APIs give you full control over edge logic, cache management, and CMS sync, but require server-side development.

Most implementations start with DNS configuration and add O2O or Workers as requirements grow.

Connect your Cloudflare domain to Webflow (DNS-only)

The simplest integration path uses Cloudflare for DNS resolution while Webflow handles everything else — SSL provisioning, CDN delivery, and hosting. This is the recommended starting point for most sites, and it works on Cloudflare's Free plan. You can set this up entirely through the Cloudflare dashboard and Webflow site settings, with no code required.

Webflow also offers a Quick Connect option that auto-configures DNS at supported providers including Cloudflare. For full control, use the manual setup below.

To connect your Cloudflare domain to Webflow:

1. Add your domain to Cloudflare. Log in to the Cloudflare dashboard, select Domains > Onboard a domain, enter your apex domain, and select a plan. The Free plan is sufficient for DNS-only use.
2. Update nameservers at your domain registrar. Cloudflare assigns two nameserver addresses — copy them exactly into your registrar's nameserver settings. Propagation can take up to 48 hours.
3. Get your DNS values from Webflow. Go to Site settings > Publishing > Production in Webflow and note the required record values.
4. Add DNS records in Cloudflare. Navigate to DNS > Records > Add record in the Cloudflare dashboard and create the following records:

           Type / Name / Value / Proxy status                                                                    Type          Name          Value          Proxy status                                      A          @          198.202.211.1          DNS only (grey cloud)                          CNAME          www          cdn.webflow.com          DNS only (grey cloud)                          TXT          _webflow          Your Webflow verification code          DNS only (grey cloud)                    

5. Verify in Webflow. Return to Site settings > Publishing > Production, click Verify domain, set a default domain, and publish.

All three records must be set to DNS only (grey cloud). Enabling the Cloudflare proxy without O2O configuration causes a 525 SSL Handshake Error. Webflow handles SSL automatically through Let's Encrypt and Google Trust Services — no Cloudflare SSL configuration is needed in this path.

If your domain has CAA records, you must authorize both certificate authorities Webflow uses, or SSL provisioning will fail:

0 issue "letsencrypt.org"
0 issue "pki.goog; cansignhttpexchanges=yes"



This DNS-only path gives you Cloudflare's authoritative DNS and DDoS-protected nameservers. For WAF rules, caching control, bot management, and Workers, you need O2O proxy mode.

Enable Cloudflare Orange-to-Orange (O2O) proxy mode

O2O routes traffic through your own Cloudflare zone before it reaches Webflow's Cloudflare-powered infrastructure. This gives you access to Cloudflare Caching, Workers, and Rules — features that Webflow's native hosting does not expose. O2O is available on any Cloudflare zone plan and is officially supported by both Webflow and Cloudflare.

To enable O2O:

1. Add your domain to Cloudflare and update nameservers (same as the DNS-only steps above).
2. Create proxied DNS records in the Cloudflare dashboard:

           Type / Name / Target / Proxy status                                                                    Type          Name          Target          Proxy status                                      CNAME          www          cdn.webflow.com          Proxied (orange cloud)                          CNAME (flattened) or A          @          cdn.webflow.com or 198.202.211.1          Proxied (orange cloud)                          TXT          _webflow          Your verification code          DNS only (grey cloud)                    

3. Set the SSL/TLS encryption mode. Navigate to SSL/TLS > Overview in the Cloudflare dashboard and select Full. Do not use Flexible mode — it causes an infinite redirect loop because Webflow redirects all HTTP requests to HTTPS.
4. Verify the domain in Webflow following the same steps as the DNS-only path.
5. Disable Rocket Loader. Navigate to Cloudflare Speed settings and turn off Rocket Loader — it is incompatible with Webflow's interaction scripts and O2O traffic.

After enabling O2O, these Cloudflare features become available on your Webflow site:

• Caching with Cache Rules for edge TTL control
• Workers for server-side logic, redirects, and dynamic content
• WAF managed rules and custom rules
• Bot Management and Waiting Room
• Configuration Rules for per-request settings

These features are the main reason to move beyond a DNS-only setup.

If your Cloudflare zone has Zone Hold enabled, release it temporarily during domain verification, then re-enable it. The Webflow dashboard may show an "Update needed" status on your domain after enabling O2O — this is a cosmetic issue caused by the proxy obscuring DNS values and requires no action if your site loads correctly.

Configure edge caching for Webflow pages

Cloudflare does not cache HTML by default — only static assets like CSS, JavaScript, images, and fonts are cached. To cache Webflow HTML pages at the edge, create a Cache Rule.

To add a Cache Rule:

1. Navigate to Caching > Cache Rules in the Cloudflare dashboard.
2. Create a rule matching your domain hostname, excluding any paths you do not want cached (such as form submission endpoints).
3. Set the cache action to "Cache everything" with an appropriate edge TTL.

Because Webflow already runs its own CDN, layering Cloudflare caching creates a double-CDN scenario. Content may be stale at one layer after the other is purged. For selective caching, use Workers or Cache Rules to target specific asset types rather than enabling full proxy caching on all content.

Add Cloudflare Turnstile and Web Analytics with custom code

Cloudflare Turnstile and Web Analytics work on any website, regardless of whether it is proxied through Cloudflare. Both can be added to Webflow through custom code in head and body tags — no O2O or proxy setup is required. A free Cloudflare account is sufficient for both features.

Embed Cloudflare Turnstile on forms

Turnstile is a CAPTCHA alternative that uses browser signals to detect bots without showing visual puzzles. It supports managed, non-interactive, and invisible widget modes. Adding it to Webflow forms reduces spam submissions without degrading the user experience.

To add Turnstile to a Webflow form:

1. In the Cloudflare dashboard, navigate to Turnstile, create a new widget for your domain, and copy the sitekey.
2. In Webflow, go to Site settings > Forms and disable the built-in spam protection. Running both Webflow spam protection and Turnstile simultaneously causes conflicts.
3. In Site settings > Custom Code, add the Turnstile script before the </body> tag:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>



4. In Webflow, add an HTML Embed element inside your form, directly before the submit button:

<div class="cf-turnstile" data-sitekey="YOUR_SITEKEY_HERE" data-theme="auto"></div>



5. Publish the site and test the form.

Turnstile's client-side widget validates visitors in the browser. Full security requires server-side token validation — Webflow's native form handling does not include this step. To validate tokens server-side, route form submissions through a Cloudflare Worker or external backend endpoint.

Add Cloudflare Web Analytics

Cloudflare Web Analytics is a privacy-focused analytics tool that tracks page views, Core Web Vitals, and visitor metrics without using client-side cookies.

To add Web Analytics to a non-proxied Webflow site:

1. In the Cloudflare dashboard, navigate to Web Analytics > Add a site and enter your domain.
2. Copy the JavaScript beacon snippet.
3. In Webflow, go to Site settings > Custom Code and paste the snippet into the footer code section:

<script defer src='https://static.cloudflareinsights.com/beacon.min.js'
 data-cf-beacon='{"token": "YOUR_TOKEN_HERE"}'></script>



4. Publish the site.

If your site uses O2O proxy mode, you can skip the manual snippet. Navigate to Web Analytics in the Cloudflare dashboard, select Add a site, then choose your hostname from the drop-down and click Done — automatic injection is enabled by default.

Connect with automation platforms

No major automation platform offers a pre-built Webflow-to-Cloudflare scenario template. For most teams, custom Workers and Webflow webhooks give more control and reliability than third-party automation platforms, especially for cache invalidation workflows where timing matters.

Build with the Webflow and Cloudflare APIs

The API integration path gives you full control over edge logic, cache management, DNS automation, and CMS data sync. It requires server-side development, typically using Cloudflare Workers as the compute layer.

Three APIs are relevant to this integration:

• The Cloudflare API v4 handles DNS records, cache purging, zone management, Workers deployment, and rules configuration
• Webflow's Data API v2 handles CMS collections, items, form submissions, and site publishing
• Webflow webhooks trigger real-time events like site_publish, collection_item_published, and form_submission that Workers can receive and act on

Together, these APIs cover the core automation and edge-compute workflows in this integration.

All three use Bearer token authentication. The Cloudflare API base URL is https://api.cloudflare.com/client/v4. The Webflow API base URL is https://api.webflow.com/v2.

Purge Cloudflare cache on Webflow publish

When Webflow publishes a site, previously cached pages at Cloudflare's edge become stale. A Worker can receive the site_publish webhook and call the Cache Purge API to clear outdated content.

To set up publish-triggered cache purging:

1. Register a Webflow webhook for the site_publish event pointing to your Worker URL:

POST https://api.webflow.com/v2/sites/{site_id}/webhooks
Authorization: Bearer {WEBFLOW_API_TOKEN}
Content-Type: application/json

{
 "triggerType": "site_publish",
 "url": "https://your-worker.workers.dev/purge-cache"
}



2. Create a Cloudflare API token with Zone.Cache Purge permission.
3. Deploy a Worker that receives the webhook and calls the purge endpoint:

export default {
 async fetch(request, env) {
   if (request.method !== 'POST') return new Response('', { status: 405 });
   const body = await request.json();
   if (body.triggerType !== 'site_publish') return new Response('Ignored', { status: 200 });
   const purgeResponse = await fetch(
     `https://api.cloudflare.com/client/v4/zones/${env.CF_ZONE_ID}/purge_cache`,
     {
       method: 'POST',
       headers: {
         'Authorization': `Bearer ${env.CF_API_TOKEN}`,
         'Content-Type': 'application/json',
       },
       body: JSON.stringify({ purge_everything: true }),
     }
   );
   const result = await purgeResponse.json();
   return Response.json({ success: result.success });
 }
};



4. Store secrets and deploy: wrangler secret put CF_ZONE_ID, wrangler secret put CF_API_TOKEN, then wrangler deploy.

For targeted cache purging, use the collection_item_published webhook event and purge by URL instead of purging everything. The webhook payload includes fieldData.slug, which you can use to construct the specific URL to purge.

Route traffic with a reverse proxy Worker

O2O proxies at the DNS layer and does not support path-based routing. A Worker can route /blog/* to Webflow while sending /app/* to a different origin — all under one domain.

Webflow maintains a canonical implementation of this pattern. The Worker inspects the request path and fetches from the appropriate origin:

const WEBFLOW_ORIGIN = 'https://your-site.webflow.io';
const APP_ORIGIN = 'https://your-app.example.com';

export default {
 async fetch(request) {
   const url = new URL(request.url);
   const pathname = url.pathname;
   if (pathname.startsWith('/app/')) {
     const appUrl = APP_ORIGIN + pathname + url.search;
     return await fetch(new Request(appUrl, {
       method: request.method, headers: request.headers,
       body: request.body, redirect: 'manual',
     }));
   }
   const webflowUrl = WEBFLOW_ORIGIN + pathname + url.search;
   return await fetch(new Request(webflowUrl, {
     method: request.method, headers: request.headers,
     body: request.body, redirect: 'manual',
   }));
 }
};



Set the Webflow origin subdomain as the default domain in Webflow and pass the correct Host header to avoid infinite redirects.

Cache Webflow CMS data at the edge with Workers KV

Each Webflow Data API call adds latency and counts against request limits. A Worker with KV bindings can cache CMS collection data at the edge and serve it in sub-millisecond reads.

To implement edge-cached CMS reads:

1. Create a KV namespace and bind it in your wrangler.jsonc.
2. Deploy a Worker that checks KV first, falls back to the Webflow API on cache miss, and stores the result with a TTL:

export default {
 async fetch(request, env) {
   const url = new URL(request.url);
   const collectionId = url.searchParams.get('collection');
   const cacheKey = `cms:${collectionId}`;
   let cached = await env.CMS_CACHE.get(cacheKey, { type: 'json' });
   if (cached) {
     return Response.json(cached, { headers: { 'X-Cache': 'HIT' } });
   }
   const wfResponse = await fetch(
     `https://api.webflow.com/v2/collections/${collectionId}/items/live`,
     { headers: { 'Authorization': `Bearer ${env.WEBFLOW_API_TOKEN}` } }
   );
   const data = await wfResponse.json();
   await env.CMS_CACHE.put(cacheKey, JSON.stringify(data), { expirationTtl: 300 });
   return Response.json(data, { headers: { 'X-Cache': 'MISS' } });
 }
};



3. Register a collection_item_published webhook to invalidate the KV cache when CMS content changes.

This pattern works well for headless Webflow setups where external frontends consume CMS content. Combine it with the publish-triggered cache purge Worker to keep both KV and CDN caches in sync.

What can you build with the Cloudflare Webflow integration?

Integrating Cloudflare with Webflow lets you add security, performance, and server-side logic to Webflow-hosted sites without migrating to a traditional full-stack hosting setup.

• Enterprise-grade security on marketing sites: Apply Cloudflare WAF rules, Bot Management, and Waiting Room to your Webflow marketing pages through O2O. Healthcare staffing platform Nursa uses Cloudflare alongside Webflow as part of their enterprise website stack, meeting security requirements without leaving Webflow.
• Spam-protected lead capture forms: Replace traditional CAPTCHAs with Cloudflare Turnstile on Webflow forms. The widget runs invisibly or as a simple checkbox, blocking bot submissions while keeping conversion rates intact. Pair it with a Worker for server-side token validation.
• Multi-origin sites under one domain: Use a Cloudflare Worker as a reverse proxy to serve your Webflow marketing site at the root domain and a separate web application under /app — all on a single domain with shared SSL. Webflow provides an official example of this pattern.
• Auto-invalidating edge cache for CMS content: Build a Worker that receives Webflow site_publish and collection_item_published webhooks and calls the Cloudflare Cache Purge API. Your O2O-cached Webflow pages stay fresh without manual cache management.

If you need more control over edge compute, dynamic content injection, or multi-service orchestration, the API integration path covers those cases with full flexibility.