Updated the website, but the browser still shows the old version?
You corrected an image or a button and it looks right on your computer. Someone else still sees the previous version. Before repeating the deployment, check which response the browser is reusing and which version of each asset the page requests.
HTML and assets have different roles
MDN's HTTP caching guide distinguishes the main document from the assets it loads. A JavaScript file or an image can have a new address whenever it changes. HTML usually keeps the same address and determines which versions should load.
A long cache lifetime applied without distinguishing content types can therefore cause problems. If the browser reuses old HTML, it may keep requesting old assets too. Checking that the server contains the new file is not enough: follow the path of a real visit.
No-cache does not mean do not store
MDN explains that Cache-Control: no-cache allows a response to be stored but requires validation before reuse. With ETag or Last-Modified, the server can return 304 if the content has not changed. No-store instead asks that the response not be stored.
These are not interchangeable ways of saying the same thing. Choose based on the content and the need for reuse. For personalized responses, review private too: a shared cache should not reuse a response intended for one user for other people.
Change the address when the asset changes
One approach MDN describes is including a version or hash in the asset filename. New HTML points to the new file, while the previous asset can remain stored without being confused with its replacement. Do not reuse an address marked immutable for content you will later replace.
After publishing, check the HTML, asset URLs and response headers. Test both a returning visit with an existing cache and a fresh visit. If a CDN or service worker is involved, review that layer too: clearing your own browser cache does not prove the rest of the delivery path is current.