Website caching explained: why your changes do not show up straight away

The short answer

Website caching means keeping a saved copy of a page, image or file so it can be shown again without rebuilding or downloading it. Browsers, servers and content delivery networks each keep their own copies. That makes sites faster, but it is also why an edit can seem missing until the old copy expires or is cleared.

What website caching is

Website caching is the practice of keeping a saved copy of something a site produces, such as a finished page, an image or a style sheet, so it can be shown again without producing it from scratch. Producing a page can mean running code, asking a database for content and assembling the HTML. A cached copy skips most of that work.

That is the whole trade. Caching buys speed and takes load off the server, and in return you accept that a copy can be out of date. Almost every caching problem a business owner meets is the same story: the page was changed, and a saved copy of the old version is still being served.

Caching is not one thing. A visitor's browser keeps copies, your server may keep copies, and a content delivery network (CDN) may keep copies in data centres closer to your visitors. Each copy has its own expiry rules and its own way to clear it, which is why the answer to why can I not see my edit depends on which copy you are looking at.

The layers where a page can be cached

A page on its way to a visitor can pass through several caches. The table lists the common ones, from the visitor's device back to the database.

Not every site has every layer. A small brochure site on shared hosting may have only a browser cache and a plugin page cache. A busy store may have all four. Ask your developer to list which ones are switched on for your site. The list is short and worth having in writing.

Browser cache vs server cache

The difference is who the copy belongs to. A browser cache belongs to one visitor and sits on their device. A server cache belongs to your site and is shared by everyone who visits.

Browser cache

When someone opens your site, their browser saves files such as images, scripts and style sheets. On the next visit it reuses them instead of downloading them again, which makes repeat visits quicker. You cannot reach into a visitor's device and clear it. You can only control how long your site tells browsers to keep each file.

Server cache

A server cache keeps a finished result so the server does not rebuild it for every visitor. A page cache stores whole pages of HTML. An object cache stores smaller pieces, such as the result of a database lookup. Because you or your host run it, you can clear it, and a well-set-up site clears the right parts by itself when content changes.

The two work together. A server cache makes the first response arrive sooner, and a browser cache means the browser may not need to ask at all. A fault in either one can produce a stale page, so troubleshooting means checking them one at a time.

How a browser decides whether to reuse a file

Your site tells browsers what to do through response headers, which are short instructions sent along with each file. The main one is Cache-Control. According to the MDN documentation, the max-age directive sets how many seconds a response stays fresh. Within that time the browser may reuse its copy without asking the server.

Two directives are often confused. no-cache does not mean do not cache. It means the copy may be stored but must be checked with the server before it is reused. no-store is the strict one: it tells caches not to keep a copy at all. Mixing them up is a common reason for a setting to behave differently from what was intended.

The check itself is light. The server can label a file with an ETag or a last-modified date. The browser sends that label back, and if nothing has changed the server replies 304 Not Modified with no file attached, so the browser reuses what it holds. If the file has changed, the server sends the new version.

For files that change rarely, such as images and style sheets, a long lifetime is safe when the file name changes whenever the content does. Developers call this versioning, or cache busting. The browser sees a new name, treats it as a new file and fetches it. For the HTML of a page, a short lifetime or a check on every visit is the usual choice, so edits appear promptly. The exact settings depend on the site, so ask your developer to show you what is set.

Why you do not see your changes after editing a page

Work through the layers in order, nearest to you first. Stop when the change appears, because that shows which layer was holding the old copy.

1. Confirm the edit was saved and published, not left as a draft, and that you edited the page visitors actually see.
2. Open the page in a private window, or on another device or network. If the change shows there, your own browser was holding an old copy.
3. Do a hard refresh in the original window. Browsers usually ask the server for fresh files on a hard refresh, which bypasses much of the browser cache. If that fails, clear the site's data in the browser settings.
4. Log out of the admin area and look again. Many page caches skip logged-in users, so editors can see new content that visitors cannot, or the other way round.
5. Clear the site cache from your CMS cache plugin or the hosting panel.
6. Purge the CDN, if you use one. A purge of the changed address is usually enough. Purging everything is the blunt option.
7. If a design change shows on some pages but not others, or the layout looks broken, an old style sheet is probably being served. Ask your developer whether the file names are versioned.

If none of this works, note exactly what you see, on which device, with the page address, and send it to whoever looks after the site.

Symptoms that point to a cache

Some faults look like bugs but are cache behaviour. This table matches what you see to the layer most likely involved.

What should never be cached for everyone

Anything personal or tied to one visitor's session should not come from a shared cache. That includes the basket, the checkout, account pages and any page showing a name or an order. If a shared cache stored one customer's account page and handed it to another visitor, the result is a privacy problem as well as a technical one.

A sound set-up excludes those pages by rule and uses cookies or headers to tell the cache when to step aside. Ask your developer to confirm the rules for the cart, checkout and account areas, and test them by logging in as two different customers on two devices. It also helps to know what personal data your site handles and to have it described accurately in a policy. The guide to website terms and privacy policies covers the general points. Rules differ by country and change, so ask a lawyer about your own obligations.

Caching and search engines

Google's documentation says its crawlers support heuristic HTTP caching, which in practice means the ETag and Last-Modified headers described above. When a crawler sends back the stored label and nothing has changed, the server can answer 304 and skip sending the page, which saves your server some work. Google also says its crawlers do not support other caching directives, so do not count on a page's Cache-Control settings to steer Google. Crawler behaviour is updated from time to time, so check the current documentation before relying on any detail.

The practical risk is stale content. If a cache keeps serving an old version of a page, crawlers and visitors both see the old version. After a significant content change, clear the caches and check the live page in a private window before you ask for it to be recrawled.

Caching during a redesign, a fix or a move

The first hours after a launch are when caching causes the most confusion. Visitors who used the old site may still hold its style sheets and scripts, and a CDN may still hold old pages. The result is a new page wearing old styling.

Put cache clearing on the launch checklist, in order: the server or plugin cache first, then the CDN, then a check in a private window and on a phone. The website redesign process includes a testing and launch step where this belongs, and a rebuilt site should use versioned file names so returning visitors pick up the new files automatically.

Smaller fixes need the same care. A cache plugin or CDN is software with settings that need reviewing, so it sits within routine upkeep. The guide to website maintenance vs redesign helps you judge when fixing is enough. If the site has moved to a new host, remember that the new host's cache starts empty and the previous host's settings do not carry over by themselves.

What to ask your developer or host about caching

• Which caches are switched on for the site: browser headers, page cache, object cache, CDN.
• Which pages are excluded from caching, and why.
• Whether the right caches clear automatically when you publish a page or change a product.
• How you clear each layer yourself, written as steps you can follow.
• Who looks after the caching set-up, and what happens to it if the host changes.

Put these questions into the written proposal too. When you compare website development quotes, check whether caching set-up and its upkeep are included or left to you. Host-level caching belongs to web hosting rather than to email, and the page on email hosting vs web hosting explains where that line sits. If you want a team to set up and look after caching as part of a build, the website development page from Liftup Technologies describes what a build covers.

Related guides

• How to check and improve website speed
• What Is a CDN and Does a Small Website Need One?
• Types of web hosting explained
• Website launch checklist 15 things to check before you go live

Questions and answers

What is website caching?

Website caching is saving a copy of a page, image or file so it can be reused instead of being produced or downloaded again. It makes sites faster and reduces the load on the server. The cost is that a saved copy can be out of date until it expires or is cleared.

What is the difference between browser and server caching?

Browser caching stores files on each visitor's own device, and you control it only through the headers your site sends. Server caching stores finished pages or data on your own server, is shared by all visitors and can be cleared by you or your host.

Why do I not see my changes after editing a page?

A saved copy of the old page is usually being shown by your browser, by a server or plugin cache, or by a CDN. Check in a private window first, then hard refresh, then clear the site cache and purge the CDN. Also confirm the change was published and not saved as a draft.

Do I need to clear the cache after every edit?

Often not. A well-configured site clears the affected pages when you publish. Clear caches by hand when a change fails to appear, after design or settings changes, and at launch. If you must clear them after every ordinary edit, ask your developer to fix the automatic purge.

Can caching cause problems on an online shop?

It can if baskets, checkout or account pages are cached for everyone. Those pages should be excluded from shared caches. Test with two devices logged in as different customers before launch and after any change to caching settings.

Does a CDN replace server caching?

No. A CDN is another cache that sits between the visitor and your server, usually in locations nearer to the visitor. It adds a layer. Your server may still need its own page or object cache, and each layer needs its own clearing step.