Forem: doodoolove

Why Cloudflare's Free-Plan Cache Rules Don't Cache Your HTML (And the Page Rules Fix That Does)

doodoolove — Thu, 07 May 2026 09:01:41 +0000

A 90-minute debugging session, with curl outputs.

TL;DR

We run a 6,800-page games portal behind Cloudflare on the Free plan. Last week's audit flagged that cf-cache-status was returning DYNAMIC for every HTML request, despite an origin Cache-Control: s-maxage=31536000. We spent 90 minutes building Cache Rules with every "correct" config — Eligible for cache, Edge TTL, browser TTL, expression filters covering 8 path patterns — and Cloudflare still refused to cache HTML. The fix wasn't another tweak to Cache Rules; it was switching to the older Page Rules with Cache Everything + Edge Cache TTL. Within 10 seconds of saving, our second-request TTFB dropped from 660ms to 210ms (a 68% reduction on keep-alive connections, much larger globally) and age: headers started incrementing. This post is the actual headers we saw, the configs we tried, and why the docs don't tell you this directly.

The setup

DooDoo.Love is a multilingual HTML5 games portal. ~6,800 game pages, plus categories, tags, blog, news. Origin is Vercel; Cloudflare sits in front for DNS + a few security headers + (we hoped) HTML caching. We're on the Free plan because it's enough for our traffic and we'd rather spend the $20/month elsewhere.

The full SEO audit pegged our indexing rate at 18.6% — Google had crawled and indexed only 1,250 of our 6,725 sitemap URLs. One contributing factor (among several): Googlebot was paying full origin TTFB for every page in every region. From Tokyo, that meant 1,800ms just to start receiving HTML. With a flat crawl budget, that math eats most of the budget on protocol overhead instead of actual page content.

Edge caching HTML at Cloudflare's POPs would mean Googlebot in Tokyo hits the Tokyo POP (round-trip ~30ms) instead of LAX (round-trip ~150ms). On 6,800 URLs, that's a meaningful budget unlock. So: configure CF, get cf-cache-status: HIT, ship it.

It did not go that way.

What we tried first: Cache Rules

Cloudflare's modern caching configuration UI is Cache Rules (under Caching → Cache Rules). Page Rules are the legacy interface, and the docs nudge you toward Cache Rules. So we built one:

Rule name: Cache HTML edge
Match expression:

  (http.host eq "doodoo.love" and http.request.method eq "GET" and (
    starts_with(http.request.uri.path, "/games/")
    or starts_with(http.request.uri.path, "/blog/")
    or starts_with(http.request.uri.path, "/news/")
    or starts_with(http.request.uri.path, "/categories/")
    or starts_with(http.request.uri.path, "/tags/")
    or http.request.uri.path eq "/"
    [...]
  ))

Cache eligibility: Eligible for cache
Edge TTL: Use cache-control header if present, otherwise bypass
Browser TTL: Override origin TTL → 4 hours

Saved. Deployed. State: 活动 (Active). Order: 1.

We then ran:

$ curl -sI https://doodoo.love/games/sudoku | grep -i "cf-cache-status"
cf-cache-status: DYNAMIC

Five attempts in a row, each with a 2-second sleep between. Every single one: DYNAMIC. No MISS → HIT progression. No age: header.

The origin response was healthy — cf-ray confirmed Cloudflare was on the path, x-nextjs-cache: HIT confirmed Vercel was caching its end, and cache-control: s-maxage=31536000, stale-while-revalidate was being sent. There was no Set-Cookie. No Vary: *. No Pragma: no-cache. The response was, by every spec we knew, cacheable.

Diagnostic detour: ruling out the obvious

We worked through the standard checklist:

Was the rule actually deployed (not draft)? Yes, status was 活动 (Active).
Was there a higher-priority rule overriding? No, this was the only Cache Rule.
Was the expression matching? We tested a path explicitly not in the expression (/api/test-not-in-rule) and got DYNAMIC too — but that's expected because it's not in the rule. The match question stayed inconclusive from headers alone.
Was Cloudflare seeing the request? Yes, every response had cf-ray: and server: cloudflare.
Was a static asset cacheable? curl -sI .../logo.png returned cf-cache-status: MISS (cacheable, just not yet warmed). So Cloudflare's cache pipeline was not broken globally — only HTML was failing.
Did switching Edge TTL to "Ignore cache-control header, use this TTL" fix it? No. Even forcing Cloudflare to use a manual 1-hour TTL, ignoring the origin entirely, the response stayed DYNAMIC.

That last data point was the one that broke our model. If "Ignore cache-control" + a hard TTL doesn't cache an HTML response, the rule isn't being honored at all. Something below the rule layer was vetoing the cache.

The actual answer

Cloudflare Free Plan + Cache Rules + text/html is an empirically unreliable combination. The Cache Rules feature is technically available on Free, but caching of HTML/dynamic content has documented quirks that don't apply to static assets.

We confirmed plan tier in the dashboard (top right: "Free"), and we confirmed the rule was correctly configured. Cache Rules just doesn't reliably cache text/html for Free-tier accounts in 2026, regardless of how perfectly you configure it.

The interesting thing is the docs don't say this directly. They say Cache Rules are available on Free. They don't say "but for HTML on Free, use Page Rules instead." We figured this out by switching.

The fix: Page Rules with Cache Everything

Page Rules predate Cache Rules and have a different code path inside Cloudflare. On the Free plan you get 3 rules. Here's what we set:

Rule 1: *doodoo.love/games/*
  - Cache Level: Cache Everything
  - Edge Cache TTL: 2 hours

Rule 2: *doodoo.love/categories/*
  - Cache Level: Cache Everything
  - Edge Cache TTL: 2 hours

Rule 3: *doodoo.love/tags/*
  - Cache Level: Cache Everything
  - Edge Cache TTL: 2 hours

Cache Level: Cache Everything is the magic incantation. Without it, Cloudflare's default Cache Level (Standard) is "cache only static file extensions" — which excludes HTML even though text/html is the largest miss in the URL space. Cache Rules' "Eligible for cache" eligibility flag should be the equivalent override, but on Free it isn't (or isn't fully). Page Rules' Cache Everything is.

We saved, then purged:

Caching → Configuration → Purge Cache → Purge Everything

Then verified:

$ curl -sI https://doodoo.love/games/sudoku | grep -i "cf-cache"
cf-cache-status: MISS

$ sleep 3
$ curl -sI https://doodoo.love/games/sudoku | grep -iE "cf-cache|^age"
cf-cache-status: HIT
age: 3

age: 3 — the response had been at the edge for 3 seconds. Two minutes later, age: 124. The HIT was real.

We hit /categories/puzzle and /tags/puzzle-games and saw the same MISS → HIT pattern. The three Page Rules covered our highest-traffic surface: ~6,820 game pages plus 14 category pages plus 33 tag pages = ~6,867 URLs cached at edge.

What didn't speed up: TTFB on the same connection

The first thing we noticed after the switch is that TTFB didn't change on a fresh curl. From our LA-area test machine to the Cloudflare LAX POP, TTFB stayed around 660ms whether the response was DYNAMIC or HIT. We almost reverted, thinking the Page Rule wasn't actually doing anything despite the headers.

Then we ran three requests in a single keep-alive curl session:

Req 1: TTFB 0.648s, total 0.708s   ← cold connection, full TLS handshake
Req 2: TTFB 0.210s, total 0.530s   ← reused connection, hit edge cache
Req 3: TTFB 0.211s, total 0.275s   ← same

Request 1 is dominated by the TLS handshake (~440ms in our time_appconnect). Cloudflare HIT or origin pass-through, that handshake cost is the same. Requests 2 and 3 reuse the connection and now expose the actual cache delta: 660ms → 210ms = −68%.

Most real users don't run curl cold once. They open a tab, the browser establishes a connection, and then loads the HTML + dozens of subresources over that same connection. The "cold first hit" is a small fraction of total user-perceived latency. The cache win shows up on every subsequent request.

For Googlebot and other crawlers, the win shows up differently again. From the Cloudflare Tokyo POP, our origin in LAX is ~120ms RTT away. From an Asian user/crawler, hitting the Tokyo POP is ~30ms RTT. Pre-cache: 30ms RTT (user→Tokyo) + 120ms RTT (Tokyo→LAX) + origin work + return path = ~180-220ms. Post-cache: 30ms RTT (user→Tokyo) + 5-15ms (cached HTML out) + return path = ~50-80ms. The win on a global audience is much larger than the LA-to-LA test shows.

What we'd do differently

Don't start with Cache Rules on a Free plan if your goal is HTML caching. Cache Rules are the future, the docs treat them as canonical, and on Pro+ they work perfectly for HTML. On Free in mid-2026, Page Rules with Cache Everything are still the proven path. Start there. Migrate to Cache Rules when you upgrade.

Always verify with age: not just cf-cache-status: HIT. The cf-cache-status field is generated as Cloudflare formats the response; it can theoretically be HIT while the origin was actually consulted. The age: header is harder to fake — it's the seconds since the cached response was stored. If age: increments across requests, you have real edge caching.

Test with TLS handshake folded out. Cold-curl TTFB will mislead you when the cache delta is similar in size to the TLS handshake. Use keep-alive (curl with multiple URLs in one invocation) or run from a region far from your origin to expose the real cache benefit.

Free plan trade-offs are real but not large. We get 3 Page Rules; we used them on /games/*, /categories/*, and /tags/* (the three highest-traffic surfaces). The other ~1% of pages (/blog, /news, /about, root) stay uncached. For our use case, that's fine — those routes aren't crawled or hit at the same volume. If you have 10+ high-traffic surfaces, Pro is $240/year, which most production sites can absorb.

The site this came from: DooDoo.Love, 6,800+ free HTML5 browser games.
Earlier in this debugging arc: Why We Banned 'Within the Realm of...' From Our AI Game Descriptions — the AI doorway story.

About the author: Steuber Alberto is Editor-in-Chief at DooDoo.Love. Reach me at support@doodoo.love.

Why We Banned 'Within the Realm of...' From Our AI Game Descriptions

doodoolove — Wed, 29 Apr 2026 05:00:44 +0000

A small portal's accidental brush with Google's scaled-content-abuse algorithm — and the 11-rule prompt change that fixed it.

TL;DR

We run a 6,800-game HTML5 portal where every game description is generated by GPT-4.1-mini using a prompt that tries to sound editorial. Last week we caught the prompt mid-disaster: 56% of descriptions across our entire corpus opened with the same six words ("What separates casual from committed play..."), 38% used the same skill-tier framing ("Veterans of [genre] recognize..."), and 86% violated our internal jargon budget by stuffing four or more of hitbox, frame-pacing, tick rate, RNG floor into a single page.

A wedding-dress-up game on our site discussed tick-rate. Dress-up games don't have a tick-rate. That's when we knew we'd built a textbook scaled-doorway pattern straight into the GPT prompt — exactly what Google's March 2024 spam-policy update explicitly called out:

"Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings... It does not matter if you use generative AI, manual means, or a mix to produce this scaled content."

Our indexing rate was 18.6%. The pattern was both the cause and the diagnostic.

This post is what we found, what we changed, and the verification script we now run in CI to prevent regression.

How a "neutral expert" prompt becomes a doorway pattern

The original prompt was good-faith. We wanted descriptions that read like a reviewer wrote them, not like a marketer. To anchor the model away from generic Adventure-of-a-lifetime copy, we provided positive examples of "neutral-expert voice patterns" the model could draw from. Six of them, including:

"Veterans of [X] recognize..."
"Serious players of the genre find..."
"What separates casual from committed play is..."
"A commonly overlooked mechanic..."
"The game rewards a counter-intuitive approach..."

We also asked for a tail line Expert Tip: ..., a counter-intuitive truth, and "genre jargon used unapologetically" with examples of hitbox, tick rate, frame-pacing, metagame, RNG floor.

What happened: the model picked the path of least resistance. Each of the six voice patterns is high-quality on its own. But across 6,800 generations, the model converged on a tiny subset. It's the LLM equivalent of giving a student six sample answers and being surprised they only ever quote the first three.

We discovered the problem when we wrote a homogeneity check (more on that below) and learned that 3,797 of our 6,728 entries opened with the same eleven-word sentence. We had effectively templated 56% of our content corpus.

What this looks like to Google

Google's structured-content classifier doesn't need to "understand" voice patterns — n-gram fingerprinting is enough. When 56% of pages on a domain share an opener of >40 characters, that domain pattern-matches with the documented "scaled content" spam category from the March 2024 update. The algorithmic response is documented and predictable:

Google still crawls each page (the URLs are in our sitemap).
Google evaluates the content quality signal at the domain level.
Pages that fingerprint as "templated content" land in "Crawled — currently not indexed" in Search Console.

The 16-million-page IndexCheckr study puts the cross-web indexing average at 37%. We were at 18.6%. GSQI's December 2024 spam-update case studies include a directory site with 140k programmatic URLs at 12% effective indexing rate — same shape, larger scale.

The diagnostic is unambiguous: when Crawled, not indexed dominates your index report and your domain-wide content shares a structural fingerprint, the algorithm has evaluated and rejected your content, not failed to find it.

The 11-rule v3 prompt

We rewrote the system prompt with anti-doorway constraints as first-class. Here's the structure (full prompt is in our open-source repo):

Hard constraints (kept from v2):

No first-person pronouns — write as a critic, not a player.
No em-dashes (we sanitize these but reject if they leak past).
No marketing filler ("amazing", "unbelievable adventure", "dive into", "embark on").
No AI connector words ("In summary", "Furthermore", "It is worth noting").
No invented numbers or personal events ("scored 4,500", "on level 7").
Game name appears max 3 times in 180 words.

Anti-doorway diversity (new in v3):

BANNED OPENING TEMPLATES — the description must NOT begin with: "Within the realm of...", "Within the crowded field of...", "Within the niche of...", "Across the field of...", "Among browser-based...", "In the world of...", or any near-paraphrase of "[Prep] the [realm/field/niche/world] of [genre]".
BANNED VOICE PATTERNS — do NOT use anywhere: "Veterans of [X] recognize...", "Veterans of the genre...", "Serious players of the genre find...", "What separates casual from committed play...", "Players of [X] often discover...". The same ideas may be expressed, but rephrased every time using the game's specific mechanics.
JARGON BUDGET — across the entire description, use AT MOST 2 of: hitbox, tick rate, frame-pacing, metagame, RNG floor, input lag. Default to 0–1. Pick only what is actually visible in the game.
OPENING ANCHOR — the first sentence anchors on something CONCRETE and game-specific (not generic genre framing). Pick one of six modes: (a) Concrete action/mechanic, (b) Visual/scene specifics, (c) Input/control feel, (d) Design-choice observation, (e) Physics/numerical constraint, (f) Contrast/contradiction.
NAME ANCHORING — the game name must appear in the first 80 characters.

Server-side rejection: after generation, we regex-test the output against the banned openings/voices and the jargon-count budget. Any violation is rejected and the generation retried.

What v3 actually produces

A handful of side-by-side examples (real games, real outputs):

Game: urban-echo (parkour runner)

v2: "Within the realm of stylized urban runner-platformers, this title positions itself as a deceptively straightforward exercise in rooftop momentum. Veterans of the genre recognize that what separates casual from committed play..."
v3: "Sliding under a low-hanging pipe in Urban Echo requires split-second timing that often outweighs raw speed. This browser-based parkour game challenges players to navigate a series of urban rooftops..."

Game: bazooka-survivors (bullet-hell arena)

v2: "Among browser-based bullet hell shooters, this title stands out by combining relentless enemy waves with surprisingly deliberate pacing..."
v3: "Swarms of enemies press relentlessly in Bazooka Survivors, forcing rapid decisions amid chaotic bullet patterns. This arcade shooter demands not only quick reflexes but also strategic positioning..."

Game: granny-the-game (stealth horror)

v2: "Within the claustrophobic confines of a decrepit house, players face a tense stealth challenge that hinges on sound as much as sight..."
v3: "Granny: 5-day stealth horror in a creepy house. Find the keys, avoid Granny's hearing radius, escape before sundown. Browser play, no download required."

The v3 outputs share no opening fingerprint across pages of different genres. They mention specific game mechanics (low-hanging pipe, hearing radius, 5-day timer) that the model could only emit by actually engaging with the prompt's reference to the source material.

The verification script (run this in CI)

We open-sourced the homogeneity check. It does five things:

Counts banned-opening hits across the corpus
Counts banned-voice phrase occurrences
Builds a normalized 50-character prefix per entry (strips game name + digits) and reports duplicates
Counts jargon-term overuse per entry (>2 = budget exceeded)
Optional --strict mode that exits 1 if any threshold fails — perfect for CI gates

Sample output on our v2 corpus before the fix:

[1] Banned opening frequency (target: each < 5% of corpus)
  FAIL Within the realm of: 1576 / 6728 (23.42%)
  FAIL Within the crowded field of: 428 / 6728 (6.36%)

[2] Banned voice phrase frequency (target: each < 5%)
  FAIL Veterans of [X] recognize: 2571 (38.21%)
  FAIL What separates casual from committed play: 3804 (56.54%)

[3] Top 12 normalized prefixes:
  (70x | 1.04%) "within the realm of browser puzzle games this titl"
  (56x | 0.83%) "within the realm of browser based games this title"

Same script on the v3 entries we've migrated:

--strict: PASSED

There's a subtle lesson in step 3 of that script. When we first wrote it, the prefix-uniqueness test fired a false positive on small samples — every prefix in an 11-entry test set hit 1/11 = 9.09%, which our naïve threshold flagged as failure. The fix is to require actual duplication (count >= 2) before any percentage threshold matters. Single occurrence is unique by definition. We learned this on a real CI failure that wasted ~$2 of API calls — not catastrophic, but a nice reminder that homogeneity checks need to distinguish "same prefix" from "small sample size".

What this hasn't fixed yet (honesty section)

The v3 prompt is correct. But only a small fraction of our 6,820-entry corpus has been migrated as of writing. We're running batched migration via GitHub Actions (~$0.30 per 100-slug batch). At our current cadence we'll hit 50% v3 coverage in about three weeks.

Why not all-at-once? Two reasons:

Cost: ~$30 to redo the whole corpus + es/pt/fr translations. Manageable, but not casual.
Risk: a single all-at-once rewrite means a single deploy where the entire site's content changes. If the v3 prompt has any latent issue we haven't found, it would ship to all 6,820 pages simultaneously. Batched migration gives us four daily checkpoints to verify the v3 corpus's homogeneity score before committing to the next batch.

We're also not naïvely expecting a linear recovery. Google's domain-level quality assessment is built from the pages it has crawled. To shift the assessment, we need to change enough of the corpus that the next time Google re-evaluates the domain, the n-gram fingerprint has measurably moved. The literature suggests 4–8 weeks after the corpus reaches >50% v3 before the indexing rate visibly responds.

What we'd do differently

Bake banned patterns into the prompt from day one, not as positive examples. The mistake we made was thinking "giving the model six varied voice patterns will produce variety". The model doesn't pick uniformly from six options across 6,800 generations — it picks the easiest one. The fix is to prevent high-frequency openers, not to suggest alternatives.

Treat the homogeneity check as a CI gate, not a post-hoc audit. If we'd had this in place at v2, we would have caught the 56% same-opener rate after generation #500, not after #6,728. Cheap dollars vs expensive ones.

Don't trust LLM "creativity" claims. The v2 prompt was 480 words long and produced a 56%-identical opener. The v3 prompt is 730 words long, with 11 explicit constraints. Most of those constraints are negative ("don't do X"). LLMs need negative space defined; positive examples are not enough.

If your portal or content site uses an LLM-driven descriptions pipeline, run a homogeneity check on your corpus today. Three minutes. If it passes, great. If it fails the way ours did, you have a working diagnosis before the next core update.

The site this lesson came from: DooDoo.Love — a free HTML5 browser games portal with 6,800+ titles.

About the author: Steuber Alberto is the editor at DooDoo.Love. Reach me at support@doodoo.love.

Forem: doodoolove

Why Cloudflare's Free-Plan Cache Rules Don't Cache Your HTML (And the Page Rules Fix That Does)

TL;DR

The setup

What we tried first: Cache Rules

Diagnostic detour: ruling out the obvious

The actual answer

The fix: Page Rules with Cache Everything

What didn't speed up: TTFB on the same connection

What we'd do differently

Read more

Why We Banned 'Within the Realm of...' From Our AI Game Descriptions

TL;DR

How a "neutral expert" prompt becomes a doorway pattern

What this looks like to Google

The 11-rule v3 prompt

What v3 actually produces

The verification script (run this in CI)

What this hasn't fixed yet (honesty section)

What we'd do differently

Read more