Why Is My Cloudflare Cache Serving Outdated HTML Pages?

You updated your website. You hit save. You opened your site in the browser. But the old version still showed up. Sound familiar? This is one of the most common headaches for Cloudflare users.

Your changes are live on the server, yet visitors keep seeing stale content. The cause almost always traces back to caching, either on Cloudflare’s edge network or inside the visitor’s browser.

The good news is that this problem has clear, fixable causes. In this guide, you will learn why Cloudflare serves outdated HTML and how to fix it step by step.

In a Nutshell

• Cloudflare does not cache HTML by default. It only caches static files like images, CSS, and JS based on file extension. If your HTML is cached, something is forcing it, usually a “Cache Everything” rule or a plugin like APO.
• Your origin server controls cache life through headers. The Cache-Control and Expires headers tell Cloudflare and browsers how long to keep a copy. A long max-age value keeps old pages alive far longer than you expect.
• The browser cache is the hidden culprit. Many users blame Cloudflare when the stale page actually sits in their own browser. Always test in incognito mode first.
• Purging cache fixes most problems fast. You can purge a single URL or everything. Purge everything works instantly but forces a full rebuild and slows the site briefly.
• The CF-Cache-Status header tells the truth. Check it to see if a page came from cache (HIT), the origin (MISS), or was skipped entirely (DYNAMIC).
• Development Mode buys you time. It pauses edge caching for three hours so you can test changes without confusion.

What Actually Causes Cloudflare to Serve Outdated HTML

Stale HTML happens when an old copy of your page lives somewhere between your server and your visitor. Cloudflare sits in the middle as a CDN, so it can store a copy of your page on its edge servers.

When a visitor requests that page, Cloudflare may hand them the saved version instead of asking your server for a fresh one. This saves time and bandwidth. But it also means changes do not appear right away.

The other layer is the browser cache, which lives on the visitor’s device. Both layers follow rules set by cache headers. When those rules say “keep this page for a long time,” old content sticks around. Understanding which layer holds the stale page is the first real step toward fixing it.

Cloudflare Does Not Cache HTML by Default

Here is a fact that surprises many people. Cloudflare does not cache HTML pages out of the box. It caches files based on extension, not content type.

So images, stylesheets, scripts, fonts, and PDFs get cached automatically. HTML and JSON do not. This is by design, because HTML often changes and varies per user.

So if your HTML is being served stale by Cloudflare, something is overriding this default behavior. The usual suspects are a “Cache Everything” cache rule, a legacy page rule, or a WordPress plugin like Automatic Platform Optimization.

Knowing this helps you narrow the search fast. If you never set up any HTML caching, then your stale page almost certainly comes from the browser or your own server, not from Cloudflare’s edge.

Pros of the default behavior: your dynamic pages stay fresh without any setup. Cons: you miss out on the big speed boost that full page caching can give static sites.

How Cache Headers Control What Cloudflare Stores

Your origin server sends headers with every response. The two that matter most are Cache-Control and Expires. Cloudflare reads these headers and obeys them unless you override them with a rule. If Cache-Control says public, max-age=86400, that page can be cached for one full day.

Cloudflare will not cache a resource when the header says private, no-store, no-cache, or max-age=0. It also skips caching when the response sets a cookie or when the request is not a GET.

This is the most important rule set to understand. If your server sends a long max-age value, both Cloudflare and the browser will hold the old page until that time runs out, even after you update the content.

To check your headers, open your browser developer tools, load the page, and look at the response headers under the Network tab. The values you see there explain a lot of stale page behavior.

Check the CF-Cache-Status Header First

Before changing anything, find out where the stale page comes from. Cloudflare adds a header called CF-Cache-Status to every response. This header tells you the truth about caching. Open developer tools, reload the page, and read the value.

A value of HIT means the page came from Cloudflare’s cache. MISS means it came fresh from your origin and was then stored.

DYNAMIC means Cloudflare did not cache the page at all and asked your server. EXPIRED and STALE mean an old copy was served while a refresh happened. BYPASS means a header or cookie forced Cloudflare to skip the cache.

If you see DYNAMIC, your HTML is not cached by Cloudflare, so look at the browser instead. If you see HIT on a page you just changed, Cloudflare is your stale page source and you need to purge or adjust TTL. This single header saves you hours of guessing.

Step by Step: Purge Your Cloudflare Cache

The fastest fix for a single stale page is a purge. Log in to your Cloudflare dashboard. Select your domain. Open the Caching section, then click Configuration. You will see purge options.

To purge one page, choose Custom Purge, select “URL,” and paste the full address of the stale page. Click purge. Cloudflare clears that copy from every edge server within seconds. To clear your whole site, choose Purge Everything. This wipes all cached files at once.

Pros of single URL purge: it is surgical and keeps the rest of your cache warm, so the site stays fast. Cons: you must list every changed URL by hand.

Pros of Purge Everything: it guarantees a clean slate. Cons: your site rebuilds its cache from scratch, so the first visitors after the purge hit your origin and see slightly slower loads. Use single URL purges for small edits and Purge Everything after a big redesign.

Use Development Mode While You Test Changes

When you make many edits in a short time, purging after each one wastes effort. Cloudflare offers a cleaner option called Development Mode. You find it on the Overview page or under Caching settings. Turn it on with one toggle.

Development Mode pauses Cloudflare’s edge caching for three hours. During that window, every request goes straight to your origin server.

You see your real, current content with no cached copies in the way. This makes testing far easier. It also temporarily suspends features like minification and Polish.

Pros: it gives you a clean view of live changes without endless purging. Cons: your site loses its speed boost while it is active, because nothing is cached.

After three hours, Development Mode turns itself off automatically and normal caching resumes. Remember to test in incognito mode too, since Development Mode only affects Cloudflare, not your browser cache.

The Browser Cache Is Often the Real Problem

Here is a truth that trips up many site owners. You purge Cloudflare, you check everything, and the old page still appears. In many cases, the stale copy lives in your own browser, not on Cloudflare. The browser saves pages and assets to load them faster next time.

The quickest test is to open the page in an incognito or private window. A private window ignores most stored cache. If the page looks fresh there, your normal browser cache held the old version. This confirms Cloudflare was never the issue.

To clear it, do a hard refresh. Press Ctrl and F5 on Windows, or Cmd, Shift, and R on Mac. You can also clear your browser cache from settings. Always rule out the browser before you blame Cloudflare, because this single check solves a huge share of stale page reports. It costs nothing and takes seconds.

Adjust Browser Cache TTL in Cloudflare

Cloudflare lets you control how long browsers hold your files through a setting called Browser Cache TTL. You find it under Caching, then Configuration. This value sets the max-age your visitors’ browsers will respect when your origin does not send its own header.

A long Browser Cache TTL means repeat visitors keep old files for that whole period. If you set it to one month, someone who visited last week may not see your update until the month passes or they clear their cache. This is great for speed but bad during frequent updates.

Pros: longer TTL reduces repeat requests and speeds up return visits. Cons: it delays how fast updates reach loyal visitors. For sites that change often, a shorter Browser Cache TTL like a few hours strikes a better balance. Set this based on how frequently your content actually changes, not on the highest speed number alone.

Watch Out for Cache Everything Rules and Page Rules

If your HTML is being cached by Cloudflare, a rule is forcing it. The most common cause is a Cache Everything setting inside a Cache Rule or an older Page Rule. This tells Cloudflare to ignore the default behavior and store every page, including HTML.

Go to Caching, then Cache Rules, and review every active rule. Look for any rule with a cache level of “Cache Everything” or a high Edge Cache TTL. A rule that caches HTML for a month will absolutely serve stale pages. Either lower the Edge Cache TTL or add an exception for the pages that change often.

Pros of Cache Everything: it makes static sites blazing fast and cuts origin load. Cons: dynamic or frequently updated pages go stale and confuse users. You can keep Cache Everything for blog posts while adding a Bypass rule for your cart, account, or admin pages. Check old Page Rules too, since forgotten rules cause silent stale page problems for months.

Set the Right Edge Cache TTL

Edge Cache TTL controls how long Cloudflare keeps a copy on its own servers. This is separate from the browser cache. You set it inside a Cache Rule under the Edge TTL option. When your origin sends no cache header, Cloudflare uses its own defaults, such as 120 minutes for a 200 response.

If you cache HTML with a long Edge TTL, the page lives on Cloudflare’s edge for that full time. A visitor will see the same old page until the TTL expires or you purge it. So an Edge TTL of one week means a week of potential stale content.

Pros of a long Edge TTL: fewer trips to your origin and faster global delivery. Cons: updates take longer to appear unless you purge manually. For pages that change daily, a shorter Edge TTL of an hour or two works better. Match the TTL to your update schedule so freshness and speed stay in balance.

Handle Cookies and Dynamic Content Correctly

Cookies play a quiet but powerful role in caching. When your origin sends a Set-Cookie header in a response, Cloudflare normally refuses to cache that page and returns a BYPASS status. This protects user specific content like logged in dashboards. But it can break a Cache Everything setup in confusing ways.

If you cache HTML aggressively, make sure pages that need personal content, such as carts and account pages, still send cookies or carry a Bypass rule. Caching a logged in page can leak one user’s content to another, which is a serious problem. Keep dynamic pages out of the cache on purpose.

Pros of respecting cookies: user privacy stays safe and personalized pages work right. Cons: pages with cookies cannot be cached, so they load slower. The clean solution is to cache only public, shared pages and let cookie based pages stay dynamic. This keeps speed high without serving the wrong content to anyone.

Special Notes for WordPress and APO Users

WordPress sites often use Cloudflare’s Automatic Platform Optimization, known as APO. This feature caches your full HTML on Cloudflare’s edge, which is why WordPress pages can go stale even though Cloudflare normally skips HTML. APO is the override doing the work.

The good news is that APO works with the official Cloudflare plugin. When you publish or update a post, the plugin purges the cached HTML for you automatically. If your changes still do not show, the plugin may be disconnected or misconfigured. Reconnect it with your API token and confirm APO is enabled in the dashboard.

Pros of APO: it gives WordPress huge speed gains by serving full pages from the edge. Cons: if auto purge fails, you get stale pages and must purge by hand. Always test after publishing. Check that your caching plugins do not conflict, since two plugins fighting over cache control is a frequent cause of stubborn stale pages on WordPress.

A Simple Workflow to Prevent Stale Pages Forever

Now let us tie everything into a repeatable routine. First, decide which pages truly need caching and which must stay fresh. Static pages like blog posts can cache long. Dynamic pages like checkout should bypass cache completely.

Second, set sensible TTL values. Match your Edge Cache TTL and Browser Cache TTL to how often you update. Frequent updates need short values. Third, after any change, purge the specific URL rather than everything when you can. This keeps the rest of your cache warm and your site fast.

Fourth, always test in an incognito window to rule out your own browser. Fifth, check the CF-Cache-Status header to confirm the fix worked.

Following these five habits stops stale pages before they start. With this workflow, you spend less time fighting cache and more time improving your actual content, knowing your visitors always see your latest work.

Frequently Asked Questions

Why does my page still show old content after I purge Cloudflare?

The stale copy likely lives in your browser, not on Cloudflare. Test the page in an incognito window and do a hard refresh with Ctrl F5 or Cmd Shift R. If the page looks fresh in incognito, your local browser cache held the old version.

Does Cloudflare cache HTML pages automatically?

No. Cloudflare does not cache HTML by default. It only caches static files based on extension, like images and CSS. If your HTML is cached, a Cache Everything rule, a page rule, or a plugin like APO is forcing it. Review your cache rules to find the cause.

How long does a Cloudflare cache purge take to work?

A purge works almost instantly. Cloudflare clears the cached copy across its edge network within seconds. After that, the next visitor gets a fresh copy from your origin. Remember that your own browser may still hold an old version, so test in incognito mode to confirm.

What does CF-Cache-Status DYNAMIC mean?

DYNAMIC means Cloudflare did not cache the page and pulled it from your origin server. This is the normal status for HTML when no caching rule applies. If you see DYNAMIC on a stale page, the old content is coming from your browser or your origin server, not from Cloudflare.

Should I use Purge Everything or single URL purge?

Use a single URL purge for small edits, since it keeps the rest of your cache warm and your site fast. Use Purge Everything only after a big redesign or theme change. Purging everything forces a full cache rebuild, so the first visitors after the purge see slightly slower loads.

How do I stop Cloudflare from caching certain pages?

Create a Cache Rule that targets those pages and set the cache action to Bypass cache. This works well for cart, account, and admin pages. You can also make sure those pages send a no-cache or private header from your origin server, which tells Cloudflare to skip caching automatically.