How Do You Deploy a Static Site Behind Cloudflare? Cache, SSL and Redirect Settings

Deploying a static site behind Cloudflare comes down to four settings: set SSL to Full (strict), define separate cache rules for HTML and for hashed asset files, handle the SPA fallback on the origin server, and consolidate www and non-www with a single 301 redirect. Purging the cache after every deploy stops visitors from seeing stale pages.

By static site we mean a site built from HTML, CSS, JavaScript and image files generated at build time rather than rendered on each request. Sites written in React or Vue and prerendered to HTML during the build fall into this group too. 404 Ajans's own site is an example: it is written in React 18 with Vite, every page is prerendered to static HTML at build time, and it is served from an OpenLiteSpeed server sitting behind Cloudflare. The settings below come from real problems encountered in that kind of setup.

Which Cloudflare SSL mode should you use: Flexible or Full (strict)?

The correct Cloudflare SSL mode for a static site is Full (strict). In Full (strict) mode Cloudflare connects to the origin server over HTTPS and verifies that the origin's certificate is valid. Flexible mode, by contrast, carries traffic between Cloudflare and the origin as unencrypted HTTP and is the most common cause of redirect loops.

The loop works like this: in Flexible mode Cloudflare requests the page from the origin over HTTP. The origin usually has a rule (in .htaccess or the hosting panel) that redirects HTTP to HTTPS. The server answers 'go to HTTPS', the browser returns to Cloudflare over HTTPS, Cloudflare asks the origin over HTTP again, and the cycle repeats until the browser gives up with ERR_TOO_MANY_REDIRECTS.

• —Off: no HTTPS at all. Never use it for a new site.
• —Flexible: encrypted between the visitor and Cloudflare, unencrypted between Cloudflare and your server. A security gap and a redirect-loop risk.
• —Full: HTTPS to the origin, but the certificate is not validated, so expired or self-signed certificates are accepted.
• —Full (strict): HTTPS to the origin with a valid certificate required (from a public certificate authority or Cloudflare Origin CA). The recommended mode.

For the origin certificate you have two practical options: a Let's Encrypt certificate issued from your hosting panel (CyberPanel, cPanel and so on) or an Origin CA certificate generated in the Cloudflare dashboard. An Origin CA certificate is only trusted for traffic that comes through Cloudflare, can be issued with a long validity period, and removes most renewal headaches. Then turn on Always Use HTTPS. Enable HSTS only once you are sure every subdomain supports HTTPS, because browsers remember that decision for months.

How should you cache HTML versus hashed asset files?

Caching a static site works in two tiers: JavaScript, CSS and font files that carry a content hash in their filename are treated as immutable and cached aggressively for a year, while HTML files are cached briefly or purged on every deploy. That split lets new releases appear immediately while assets still load fast from the edge.

Build tools like Vite emit files with names such as assets/index-a1b2c3.js. When the content changes, the hash changes and so does the filename, so an old copy lingering in cache never causes a problem. The header 'Cache-Control: public, max-age=31536000, immutable' suits these files. HTML is always served under the same name (index.html), so caching it for a long time hides new content. By default Cloudflare does not cache HTML at all; it only stores static files with certain extensions. If you want HTML at the edge, you have to opt in deliberately with a Cache Rule.

• —Rule 1 — paths starting with /assets/: Eligible for cache, Edge TTL one year, Browser TTL respects the origin header.
• —Rule 2 — HTML pages: either Bypass cache, or a short Edge TTL (a few hours, for example) plus a purge on every deploy. Keep Browser TTL short.
• —Rule 3 — sitemap.xml, robots.txt, llms.txt: short TTL, so search engines and AI crawlers always see the current version.
• —Rule 4 — form submissions or API paths: always Bypass cache.

A classic mistake: HTML is cached for a long time, and the next deploy deletes the old hashed files from the server. The cached HTML then requests JavaScript files that no longer exist and the site loads as a blank white screen. The fix is to purge HTML on every deploy, or to keep the previous build's assets folder on the server for a few days.

How do you set up the SPA fallback on the origin server?

An SPA fallback is a server rule that sends every request without a matching real file or folder to the application's index.html. Cloudflare does not apply this rule for you; it has to live on the origin server, as a RewriteRule in .htaccess on Apache and OpenLiteSpeed, or as a try_files directive on Nginx.

On Apache-compatible servers the logic is three lines: if the requested path is not a real file (RewriteCond %{REQUEST_FILENAME} !-f) and not a real directory (!-d), hand the request to index.html. With prerendering, every page already has its own index.html in its own folder, so the fallback only fires for unknown URLs, which preserves both speed and the content search engines see.

Watch out for soft 404s. If the fallback returns the homepage shell with a 200 status for every nonexistent URL, Google may treat those URLs as empty or duplicate pages. A healthier approach is to serve a separate 404 shell with a noindex tag for unknown paths, or to return a real 404 status where possible. The 404 Ajans build generates a dedicated 404.html file for exactly this purpose.

How do you 301-redirect www and non-www to a single address?

If both the www and non-www versions of a site respond separately, search engines see the same content at two addresses and ranking signals get split. The fix is to pick one canonical hostname and move the other to it with a permanent 301 redirect. On Cloudflare the cleanest way is a Redirect Rule, handled at the edge before the request ever reaches the origin.

• —Make sure DNS has a proxied (orange cloud) record for www; if the record is missing or DNS-only, the rule never fires.
• —Under Rules, create a Redirect Rule that sends requests for www.yourdomain.com to https://yourdomain.com while preserving the path.
• —Choose status code 301 and enable preserving the query string.
• —Check that canonical tags, hreflang links and every URL in sitemap.xml use the hostname you picked.
• —Test all four combinations (http, https, www, non-www) with curl -I; each should reach the destination in one or at most two hops.

Avoid redirect chains. If http://www first goes to https://www and only then to the non-www host, you have two hops. That will not break the site, but it adds needless latency; ideally the rule should send every variant to the final address in a single step.

Why and how should you purge the cache after every deploy?

Purging deletes the old file copies stored on Cloudflare's edge servers so that visitors get the new release. If HTML is cached at the edge and you skip the purge after a deploy, some visitors will keep seeing old pages, old titles and old internal links until the cache TTL runs out.

• —Purge Everything: the simplest and safest option for small and medium static sites.
• —Custom Purge: clears only the URLs of changed pages plus sitemap.xml, preserving the cache hit ratio on large sites.
• —Automated purge via API: run it as the last step of your deploy script with an API token scoped only to Cache Purge.
• —Development Mode: temporarily bypasses cache (for about three hours) while you test; not a permanent solution.

Order matters: upload the files first, then purge. Do it the other way round and a request arriving mid-upload can make Cloudflare re-cache the old or half-uploaded version.

Step-by-step deployment checklist

Deploying a static site behind Cloudflare without incidents depends on doing things in the right order: the origin certificate and HTTPS first, then the SSL mode, then redirects and cache rules, and finally the file upload followed by a purge. Following that sequence minimises the risk of redirect loops, mixed-content warnings and stale pages during launch.

• —1. Move the domain's DNS to Cloudflare and set both the apex and www records to proxied.
• —2. Install a valid certificate on the origin (Let's Encrypt or Cloudflare Origin CA).
• —3. Set SSL/TLS to Full (strict), then enable Always Use HTTPS.
• —4. Add a one-way 301 Redirect Rule between www and non-www.
• —5. Configure the SPA fallback rule and the 404 shell on the origin.
• —6. Use Cache Rules to cache hashed assets long and HTML briefly or not at all.
• —7. Upload the full build (including prerendered pages) to the server.
• —8. Purge the cache and check the cf-cache-status header (HIT, MISS, DYNAMIC, BYPASS) with curl -I.
• —9. Inspect a few URLs in Google Search Console and resubmit the sitemap.

Once this is set up correctly, every future deploy is just steps 7 and 8. If you are unsure about any part of the initial setup, SSL and redirects in particular, getting expert help is far cheaper than trial and error on a live site, which can easily cost you a few hours of downtime.