How to Check if a Website Is Cached: Browser, CDN, and Origin Testing Guide

Overview

A page can be cached in more than one place. Your browser may reuse a local response, a reverse proxy may serve a stored copy, and a CDN may deliver content from an edge location instead of contacting the origin server. These layers can produce different results, so a single speed test or one response header does not always prove where a file came from.

Use this order when testing:

1. Confirm which URL and resource you are testing.
2. Inspect the browser request and response headers.
3. Repeat the request with a clean browser session or disabled cache.
4. Use curl to compare response headers outside the browser.
5. Repeat the test from more than one network or location when edge behavior matters.
6. Compare the result with the cache rules configured at the CDN, reverse proxy, application, or origin.

Test a specific resource rather than only the homepage. Useful targets include an HTML document, a versioned CSS or JavaScript file, an image, a font, and—where appropriate—a public API response. Caching rules often differ by file type, URL path, cookie, query string, authentication state, and HTTP method.

For background on policy design, see the Cache-Control headers guide. If the test is part of a performance investigation, pair it with the guidance on improving TTFB.

Checklist by scenario

Scenario 1: Check browser caching in DevTools

1. Open the page in a Chromium-, Firefox-, or WebKit-based browser.
2. Open Developer Tools and select the Network panel.
3. Enable the option to preserve the log if navigation requests need to remain visible.
4. Reload the page and select the document or asset you want to inspect.
5. Review the Size or transfer column and the request details. A browser may label a response as coming from memory cache or disk cache, although the wording varies by browser and version.
6. Open the headers section and record Cache-Control, Expires, ETag, Last-Modified, Age, and any CDN-specific headers.

For a clean comparison, enable the browser's Disable cache option while DevTools is open, then reload. This normally affects requests made during that DevTools session; it is a diagnostic control, not proof that real visitors bypass the browser cache.

Also test a second navigation without disabling the cache. If the response is reused locally, the browser may make no network request at all. That is different from receiving a fast response from a CDN.

Scenario 2: Check a CDN or reverse proxy with curl

Run a header-only request against the exact URL:

curl -I https://www.example.com/path/file.css

For a more detailed request, use verbose output:

curl -sS -D - -o /dev/null https://www.example.com/path/file.css

Look for cache-control directives and provider or proxy indicators. To compare repeated requests, run the command more than once and record the headers each time:

for i in 1 2 3; do
  curl -sS -D - -o /dev/null https://www.example.com/path/file.css
  echo "--- request $i ---"
done

Many CDNs expose a header such as CF-Cache-Status, X-Cache, or another platform-specific status. Values such as HIT, MISS, BYPASS, or EXPIRED can be useful, but their meanings and availability depend on the provider's configuration. A missing header does not mean that caching is absent: the provider may hide diagnostic headers, or an intermediate proxy may remove them.

Use curl from a machine outside your origin environment when possible. A request made directly on the origin server may not pass through DNS routing, the CDN, or the public reverse proxy.

Scenario 3: Test cache-control behavior

Read the policy before interpreting the result:

For static assets, look for a deliberate freshness policy and stable, versioned URLs. For HTML, check whether cookies, authorization, or personalized content should prevent shared caching. For APIs, confirm that the method, authentication state, and response variation are safe for the selected policy. Never assume that a fast response is safe to cache.

Scenario 4: Check a WordPress or ecommerce page

Test an anonymous page in a private browsing window, then compare it with a logged-in request. WordPress page caching, a CDN, a hosting-layer reverse proxy, and a caching plugin may all be active at once. Product, cart, checkout, account, and other personalized routes commonly require different rules from public content, but the correct behavior depends on the site's implementation.

After publishing or changing a page, request the URL in DevTools and with curl. Verify the new content, note the cache status, and then test a related asset. If the page is stale, determine whether the required action is a plugin purge, CDN purge, reverse proxy purge, or a change to the cache key. The WordPress caching guide provides a broader framework for page, object, CDN, and WooCommerce caching.

Scenario 5: Compare edge and origin responses

First request the public hostname, which should represent the visitor path. Then, only if you have authorization and a safe test endpoint, request the origin hostname or origin address separately. Compare status codes, headers, content, and timing. Do not expose an origin address or bypass normal security controls merely to run a test.

A public response that is fast and marked as a cache hit suggests edge delivery, but it does not establish the full path. DNS, a load balancer, a hosting cache, and an application cache may all contribute. To assess the broader system, review origin logs and CDN analytics alongside the request headers. For a systematic measurement approach, see how to measure cache hit ratio and diagnose low CDN cache performance.

What to double-check

• URL variation: Query strings, trailing slashes, hostnames, protocols, and capitalization can create different cache keys.
• Cookies and authorization: A session cookie or authorization header may cause a cache bypass, vary the response, or make shared caching unsafe.
• Methods: A test with HEAD may not behave identically to a browser's GET. Compare like with like.
• Compression: Check whether the response varies by Accept-Encoding; compressed and uncompressed representations may be handled separately.
• Deployment timing: A purge may be asynchronous, and different edge locations may update at different times.
• Status codes: A cached error, redirect, or partial response can look like a successful cache test unless you verify the status and body.
• Cache key rules: Confirm which headers, cookies, query parameters, and hostnames are included or ignored.
• Freshness and revalidation: A response can be reused, revalidated, or served stale under different rules. These are not identical outcomes.

When a cache status is unclear, collect a small evidence set: the full URL, timestamp, HTTP status, relevant response headers, request headers that may affect variation, browser cache state, and the test location. This makes comparisons after a deployment or rule change much more reliable.

Common mistakes

1. Testing only one request. The first request may populate a cache, while the second reveals whether reuse is possible. Test both, but remember that a single pair is not a complete cache-hit measurement.
2. Assuming a CDN header is universal. Header names and status values are provider-specific. Check the platform documentation and your own configuration.
3. Using a cache-busting query string without understanding the rule. Adding ?test=1 may create a new cache key, bypass a rule, or be ignored. Treat it as a controlled experiment, not a normal visitor request.
4. Testing while logged in. Personalization and cookies can intentionally bypass shared caches.
5. Confusing browser cache with edge cache. A browser reuse indicator says little about what happened at the CDN.
6. Purging before recording evidence. Capture headers and content first, then purge if you have permission. Otherwise, the original behavior may be difficult to reproduce.
7. Optimizing before checking correctness. A cache hit is not beneficial if it delivers private, stale, or incorrect content.

When to revisit

Keep this checklist with your deployment and performance-testing workflow. Re-run it after changing DNS, moving hosts, adding or replacing a CDN, modifying cache-control headers, changing reverse proxy rules, installing a WordPress caching plugin, or updating a platform's page-cache integration. Repeat it after significant template, authentication, ecommerce, or API changes as well.

Before a seasonal traffic period or planned campaign, test the public HTML, key static assets, and the most important uncached or personalized routes. Record the expected cache status, purge procedure, and safe exceptions. During a post-deployment check, use this short sequence:

1. Open the target URL in a clean browser session.
2. Capture the response headers with DevTools and curl.
3. Repeat the request and compare cache indicators, content, and timing.
4. Test an authenticated or personalized path separately where relevant.
5. Check CDN and origin logs for confirmation.
6. Document any mismatch before changing rules or purging caches.

If the goal is lower latency rather than only confirming a cache hit, combine these results with a TTFB review and an examination of cache-hit ratio trends. When selecting or reassessing a provider, the CDN comparison and best CDN guide for small websites can help structure the infrastructure decision. The most useful test is one you can repeat after the next change and interpret with confidence.