--- title: "Fix a Site Broken in Chrome: 6 Proven Cache Steps Now" slug: "fix-site-broken-in-chrome-cache-checklist" published: "2026-07-23" updated: "2026-08-03" categories: - "Tools" tags: - "site broken in Chrome" - "Chrome cache" - "clear Chrome cache" - "cache-busting query parameter" - "service worker cache" - "CDN cache purge" - "clear DNS cache Chrome" - "Empty Cache and Hard Reload" - "troubleshoot Chrome-only issue" - "Chrome DevTools clear site data" llm-intent: "reference" audience-level: "beginner" framework-versions: - "chrome@latest-desktop (stable, 2026)" - "chromedevtools@latest" - "service-workers@1" - "cloudflare@latest" - "fastly@latest" status: "stable" llm-purpose: "Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS…" llm-prereqs: - "Access to Google Chrome" - "Access to Chrome DevTools" - "Access to Service Workers" - "Access to CDN (Cloudflare, Fastly, etc.)" - "Access to DNS resolver / DNS cache" llm-outputs: - "Completed outcome: Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS…" --- **Summary Triples** - (cache confirmation, test, append a temporary query parameter (e.g., ?test=1 or ?t=TIMESTAMP) to the URL to force a fresh request) - (Incognito mode, use, open the page in Chrome Incognito to check if an extension or profile cache is causing the issue) - (clear site data, perform, remove cookies and site data for the domain via Chrome settings or DevTools Application > Clear storage) - (Empty Cache and Hard Reload, invoke, open DevTools, right‑click refresh button, select 'Empty Cache and Hard Reload' to clear origin disk cache during the session) - (DNS and sockets, reset, clear Chrome DNS cache (chrome://net-internals/#dns) and close socket pools (chrome://net-internals/#sockets)) - (service workers, remove/unregister, unregister any service workers via DevTools Application > Service Workers or update their fetch handlers to skip the cache) - (CDN/proxy caching, verify and purge, check CDN or reverse proxy cache (edge caches, caching rules, stale TTLs) and perform a purge for the affected URL(s)) - (network isolation, test, test the page on a different network or mobile data to detect ISP or resolver caching) - (final verification, confirm, after clearing caches, reload without the query parameter and verify the issue is resolved on the original Chrome profile) ### {GOAL} Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS… ### {PREREQS} - Access to Google Chrome - Access to Chrome DevTools - Access to Service Workers - Access to CDN (Cloudflare, Fastly, etc.) - Access to DNS resolver / DNS cache ### {STEPS} 1. Confirm with cache-busting query parameter 2. Open page in Incognito mode 3. Clear site data via DevTools 4. Use Empty Cache and Hard Reload 5. Clear DNS cache and socket pools 6. Test on different network or device 7. Purge CDN or remove service worker # Fix a Site Broken in Chrome: 6 Proven Cache Steps Now > Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS… Matija Žiberna · 2026-07-23 A page that misbehaves only in Chrome, while working fine in another browser, on another device, or through an external testing tool, usually points to something Chrome is holding onto rather than a bug in the page itself: corrupted cache data, an outdated redirect, stale DNS information, a leftover service worker, or a cached response from a proxy or CDN. The fastest way to confirm this is a cache-busting query parameter on the URL, and if that fixes the page, the rest of the fix is about clearing the right cache rather than touching code. I run into this constantly across client sites with CDNs, service workers, and aggressive edge caching, and it always starts the same way: a client reports a broken page, I open it fine in Firefox or an incognito window, and Chrome alone shows the stale version. Here's the exact sequence I use to confirm it's a caching issue and clear it. ## Confirm the Cache With a Query Parameter Add a temporary query parameter to the affected URL: ```text https://example.com/problem-page/?test=1 ``` This changes the URL enough that Chrome treats it as a new request instead of serving a cached response. If the page suddenly renders correctly, stale or corrupted cache data is almost certainly the cause, and you can move straight to clearing it instead of digging through the page's code. ## Clear Chrome's Cache for the Site A handful of fixes work through most cases, roughly in order of how disruptive they are: 1. Open the page in Incognito mode. 2. Clear site data for the affected domain. 3. Use Chrome's Empty Cache and Hard Reload option. 4. Clear Chrome's DNS cache and socket pools. 5. Test on a different network or on mobile data. 6. Check whether a proxy, CDN, service worker, or redirect rule is caching a bad response. To clear data for one site specifically, open Chrome settings, search for the domain under stored site data, and remove it. Chrome DevTools offers a faster path for this during active debugging: open the Application panel, go to Storage, and select Clear site data. ## Check for Trailing-Slash and Route-Level Caching If the issue only shows up on one route, test both versions of the URL, since Chrome and some CDNs can cache them separately: ```text /example-page /example-page/ ``` A cache-busting parameter works here too: ```text /example-page/?refresh=1 ``` If that query parameter clears the problem, the next step is usually clearing the relevant browser cache or purging the cached page directly from your CDN or hosting platform, since the stale copy is often sitting at that layer rather than in Chrome alone. ## Rule Out the Browser Before Debugging the Code Before assuming the website itself is broken, compare the page across normal Chrome, Incognito mode, another browser, another device, another network, and the same URL with a cache-busting query parameter. Six quick checks like this can save hours of debugging code that was never the problem. ## FAQ ### Why does this happen in Chrome specifically and not other browsers? Each browser keeps its own cache, service worker registrations, and DNS resolver cache. Chrome tends to cache aggressively and hold onto service workers longer than some other browsers, so a stale response can persist in Chrome well after a CDN or origin server has already updated. ### Does Incognito mode guarantee a clean test? Mostly, but not completely. Incognito skips your existing cache and cookies, but it can still hit a cached response sitting at a CDN or proxy layer, so a correct result in Incognito narrows the problem to Chrome's local cache rather than ruling out caching entirely. ### What's the difference between "Empty Cache and Hard Reload" and clearing site data? A hard reload clears the cache for that page load only. Clearing site data through Chrome settings or DevTools removes cookies, local storage, service workers, and cached responses for the entire domain, which matters when a service worker is the actual culprit. ### How do I know if the problem is a CDN cache instead of a Chrome cache? If the cache-busting query parameter fixes the page in Chrome but the original URL still fails after clearing Chrome's cache and testing in Incognito, the stale response is most likely sitting at the CDN or proxy layer and needs to be purged there directly. ### Should I add cache-busting parameters permanently to avoid this? No. That defeats the purpose of caching and can hurt performance across your whole site. Use the query parameter only as a diagnostic step, then fix the actual cache configuration, service worker logic, or CDN purge behaviour causing the staleness. ## Conclusion A page that only breaks in Chrome is rarely a code problem. Confirming it with a cache-busting query parameter, then working through Chrome's site data, DNS cache, and any CDN or service worker involved, resolves most of these cases without touching a single line of application code. Let me know in the comments if you've run into a caching issue this didn't catch, and subscribe for more practical debugging guides. Thanks, Matija ## LLM Response Snippet ```json { "goal": "Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS…", "responses": [ { "question": "What does the article \"Fix a Site Broken in Chrome: 6 Proven Cache Steps Now\" cover?", "answer": "Site broken in Chrome? Diagnose and fix Chrome-only failures fast with cache-busting, clearing site data, removing service workers and purging CDN or DNS…" } ] } ```