Prove the change was published at the intended URL
Prove the edit is published at the correct URL, then identify which browser, application or delivery cache still serves the old version.
A draft or an edit to a different hostname can look like a cache problem. Record the exact public HTTPS URL, change time and a distinctive non-sensitive phrase or asset version. In the application admin, verify that the change is truly published rather than still a draft, scheduled item or editor preview. Open the canonical public URL in a fresh browser session and on another network if available. A preview URL, a www variant or a different language path may reach a different page.
Do not start by purging every cache. First establish whether the origin application contains the new version. If the application itself shows old content, the issue is publishing or deployment, not visitor caching. A new hosting default page or wrong document root belongs to the separate deployment guides.
Narrow the cache layer with safe comparisons
Compare a normal session with a private session and another device. If only one browser shows old content, its local cache or an open tab is a plausible cause; refresh or clear only that site’s stored response. If multiple browsers see old content but an authenticated application preview shows new content, the site’s own page cache may need a targeted purge. Where an actual contracted reverse proxy or CDN exists, a shared cache may be involved. MDN explains that private browser caches and shared intermediary caches can retain responses under HTTP caching rules. Browser results alone do not identify a particular vendor or prove a Novasean CDN exists.
For assets, check that the page references the new file URL and that the file itself changed. An unchanged asset URL with long-lived caching can remain stale even when HTML updates. The application owner may use its documented asset versioning or scoped purge control.
For example, if a private window shows the new text but the usual browser shows the old, inspect that browser's cache or service worker. A private window can also bypass login and personalisation, so compare the same public URL.
Clear only the confirmed owner-controlled layer
Use a normal refresh for a local browser cache. If the application offers a cache plugin or built-in purge, the application owner should follow that component’s procedure for the affected page or asset. Ask Novasean support whether the purchased service includes an intermediary cache and an account-scoped purge route before requesting one. Avoid globally disabling caching or changing cache headers without a rollback plan; that can affect site performance and does not fix a wrong origin.
Check an independent visitor view
After the targeted action, open the exact public URL in a fresh unauthenticated session and confirm the distinctive change. Check one linked page or asset and the expected canonical hostname. If the application origin is current but an intermediary still serves old content, send support the URL, observed response time and safe comparison rather than claiming the browser refresh failed. If the origin itself remains old, return the issue to the application publisher or deployment owner.
Frequently asked questions
Does private browsing always bypass a CDN cache? No. It changes local browser state, while a shared cache may still serve the same stored response.
Is this DNS propagation? A stale page at the correct live origin is usually a different question. First confirm the hostname and destination before blaming DNS or cache.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.