Chrome won't refresh updated page without clearing cache

I mostly use Safari, but I’ve recently been viewing my website on Chrome and it seems some page updates need to have the cache cleared. This never happened in Firefox or Safari. Wondering if this is how clients see things, then how do I fix it so the updated page is forced?


Are you on Cloudflare by any chance? I ‘know’ (from reading the forums, not experience) that there is an option to disable caching while you’re working on a site to make sure that changes get pushed live.

1 Like

Chrome is actually doing it correctly. If you have ‘cache busting links’ enabled in RW7, then Chrome will respect this and will not purge its cache of CSS or JS files when it comes back to view one or more of your webpages.

That can give the impression of newly published pages sometimes looking broken - the content will be correct but other styling or functionality might misbehave. And yes, it could effect what website visitors see, when they arrive at your website.

So you could try disabling ‘cache busting links’ in your site settings. Then do a full republish of the website and see if that makes any difference.

If you are using CloudFlare, login to your CloudFlare account and clear the cache there.

If you do want to do a ‘hard refresh’ of your website cache in Chrome (without effecting other websites you browse to) open the web inspector in Chrome. Then right-click the refresh button and select Hard Reload from the menu.

The ‘problem’ (if you want to call it that) is not only isolated to RapidWeaver - I’ve seen the same thing happening in concrete5 which also uses a similar system of cache-busting links.


Ah I will check that out, thank you, @jabostick. I also seem to remember seeing a post but couldn’t remember the suggestion was related to Cloudflare.

@willwood I’m not worried about myself, but other users not seeing the changes. Will it hurt me to disable ‘cache busting links’? But then, you said that might not work… and then, instead, if I go into Cloudflare and clear the cache… that will clear for all users?

thanks, Lisa

Cache busting links and CloudFlare changes will effect all visitors to your website. The trick to hard reload the webpage will only work on your computer.

I’ve ended-up turning off cache-busting links on several of my own and client websites, because there were reports of changes not showing immediately in Chrome and IE Edge.


thanks for the clarification :slight_smile:

Will: where would we find this “cache busing links” option. I’ve never heard of it and I can’t find it after a quick search. I have no idea if I have it on or off.

general prefs >

1 Like

Is this prefs located just under the Rapidweaver 7 menu heading? I don’t see anything like you are showing. My prefs have 4 tabs (general, publishing, updates, and addons). General shows default theme and some other things.

It’s under “settings” at the bottom of your panel on the left, under resources. General > Advanced.

1 Like

Okay, now I got it. Thanks. Turning off cache busting now!


It’s only applicable if you are using RW7.

In your RW sidebar, scroll down to Settings and click General. Scroll to the bottom of the page and click Advanced.

You are then presented with a series of check boxes. Disable cache-busting links here, the 5th option down in the site options.

This will have the result of removing the ‘rwcache’ query string from your CSS and javascript links in the page:

Now instead of Chrome holding tightly onto these CSS and JS files in its cache, it will reload the CSS and JS files each time the page is refreshed.

You can read more about cache busting links here:

However I think there is a bug in how RW handles cache-busting query strings that @dan probably needs to be made aware of. I noticed that if you make changes to a page (like change some content, adjust a theme style setting or add and remove a stack) the changed flag is correctly applied to the page but the query string applied on the cache-busting links does not change on the published website. Therefore Chrome does not see the latest CSS and JS changes (it assumes the CSS and JS has not changed). I would expect the cache-busting links to receive a NEW query string, if a page gets flagged as changed.


Will: Thanks. It would certainly be good if any remaining bugs surrounding this issue got fixed in RW soon.


One other thing you can do in Chrome instead

  • in “Developer Tools>Settings” (in the “3 dots” menu near the top right of the Developer Tools)
  • click “Disable cache (while DevTools is open)”
  • and obviously, have Developer Tools open when you refresh the page
    Then when you are working on a website, any changes you make will show up properly!

Yes, but again, that doesn’t help what my users see.

1 Like

I see this exact issue with stacks borders. I have a “faux” “blog” index page which is hand made each day using a Stacks3 page. I copy the latest entry which is a Stacks3 Text stack. The Text stack has a border on the bottom acting as a divider. When I copy the top stack and change content for the new entry, then publish, the bottom border does not render. I assume it is because Chrome has the css cached.

For my own sanity I installed a Chrome extension that loads everything on each page load.

I’m not sure how this caching issue affects my visitors. I found that if I run Chrome normally and allow it to cache, then a quick reload or two pulls in the new css and the rule is then rendered.

Sanity is definitely critical. Which one?

Cache Killer unlike some where you have to click icon to clear cache this is a “turn it on” “turn it off” extension. Thus, leaving it on will slow you down when doing normal browsing. But frankly, I turn it on and leave it on as my connection is fast enough that cache loading doesn’t slow me down much. I’d rather have it on because I work on my site quite a bit and prefer cache reloads all the time.

Now if I could just ensure that my visitors are seeing the right thing… short of a manual edit of a cache-busting link on the server.???

1 Like

As info to all… just a place to start research:

This explains viewers of a previous site of mine - not seeing what I thought they were seeing.
The Chrome users were in a muddle & I never equated it to the browser choice.

fwiw, I ran into this just a few days ago by using Safari for a server log-in & Chrome as my site viewer, while trying to narrow down which color settings were controlling what in order to change one errant one. “Thang” clarified.