Clear the right cache after a website change Print

Quick answer

A website may use browser, application, server, and CDN caches at the same time. Clear the layer holding the stale content rather than repeatedly editing the page or purging every cache without a reason.

Before you begin

Confirm the change was saved to the correct site and release. Record the affected URL or asset and compare a fresh visit with the editing or preview view.

What to do

1. Identify whether the stale item is HTML, an image, stylesheet, script, or a logged-in application response. Different resource types may follow different cache rules.
2. Check the application or hosting cache associated with the changed content. Avoid clearing private user data or unrelated settings as a troubleshooting shortcut.
3. If a CDN such as Cloudflare holds the resource, use a targeted purge where appropriate. Available purge options and limits depend on the service and plan.
4. Request the resource again and inspect the actual result. A successful purge response does not alone prove that the intended page or asset changed.
5. Repeat the relevant visitor workflow and record any cache versioning or release changes needed to prevent future stale assets.

How to check the result

Confirm the public content matches the approved release and that essential dynamic pages still behave correctly. Test another session when account-specific or consent-specific content is involved.

If you need help

If stale content persists, provide the exact URL, time, browser, and observed cache headers if available. Do not disable caching globally or weaken security protections before the layer and cause are understood.

Website changes not showing: confirm the source, then the cache

Check the exact public hostname and affected URL. Confirm that the approved file or CMS change reached its intended document root and that no newer live edit replaced it. An unchanged source file, a different domain folder and stale cached content can look alike.

1. Compare the page/asset in a fresh visitor session and a normal reload. Check whether the incorrect item is HTML, an image, CSS or JavaScript. A private window can help separate browser storage from an upstream cached response.
2. Use the application's supported control to clear its relevant generated cache. For W3 Total Cache, first identify its active methods through the configuration guide. Avoid changing cache backends during a simple content refresh.
3. If a CDN cached the exact resource, use an appropriately targeted purge through the authorized provider. Keep query strings, asset variants and the actual hostname in mind. Purging a different URL cannot update the resource visitors requested.
4. Read the response and, when available, relevant Cache-Control, Age or provider cache-status headers. Headers are evidence about a layer, not proof that the site's origin files changed.
5. Reopen the affected page and a nested page, verify the expected content/assets and check a real form or other affected function. Keep private/account pages from entering an inappropriate shared cache.

If the change still does not appear, provide the URL, time, expected visible difference, confirmed source location and redacted response evidence through support. Use the document-root checks when the upload destination is uncertain.

Related help

• Upload a reviewed file with cPanel File Manager
• Replace a WordPress image and check its display
• Investigate a legitimate request blocked by Cloudflare
• How to install and set up W3 Total Cache in WordPress
• Find the correct document root before an AI tool uploads files
• Send a website support request with useful troubleshooting details

Official references

• Cloudflare cache purging

Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.

Customer symptom and related-help review: November 1, 2026.