Choose the next check from the evidence
If Site Health cannot detect page cache because a request back to the site failed, start with the loopback request guide. An incomplete test does not establish that caching is absent.
Confirm that the new content was published
Open the page in WordPress and check that you saved or published the latest changes. Compare the editor's page address with the public address, including the domain and language version. A draft, a different template or a change made on staging will not appear on the live page after a cache purge.
Choose one visible detail to verify, such as a corrected heading, and record the page address. Check it in a private browser window before clearing anything. If the private window shows the new version while your normal window does not, start with the browser. When both show the old version, investigate the site's saved copies next.
Refresh the browser's copy first
Reload the page in the private window and compare it with another browser or device. A private window starts with separate browser storage, but it still receives content from your host and CDN. It does not bypass every cache between the website and the visitor.
If only the normal browser is stale, use that browser's clear-browsing-data settings and select cached images and files. Review the other boxes before confirming so that you do not unnecessarily erase saved passwords or cookies. Reopen the page afterwards. A browser-specific result does not require flushing the site's database cache.
Clear generated design files when styles are wrong
If an Elementor design is correct in the editor but has old colours, spacing or fonts on the public page, open Elementor > Editor > Home, select Tools, choose Clear Files & Data and Save Changes. Older interfaces place the control under Elementor > Tools. Follow Elementor's generated-file instructions, then visit the affected page so the required files can be rebuilt.
Other builders and optimisation plugins have their own generated CSS controls. CSS is the file format used to style the page. Clear those files only through the tool that created them, then continue with the page caches below. Do not delete the uploads directory or remove arbitrary CSS files in File Manager.
Purge the active WordPress page cache
Look under Plugins > Installed Plugins for your caching tool and open its settings. A page cache stores a prepared copy of a page so WordPress does not have to build it for every visitor. Use its Clear cache or Purge control, preferably for the affected page when the tool supports that. Wait for the success notice before testing.
For LiteSpeed Cache, open LiteSpeed Cache > Toolbox > Purge. Purge All - LSCache clears its page cache; generated optimisation files have separate controls. Use the LiteSpeed Toolbox reference to choose the intended action. Empty Entire Cache is broader and is not the routine first choice.
Do not install a second cache plugin just to obtain a purge button. A host-managed cache can exist without a separate plugin. If several tools appear to cache full pages, note their names and use our caching-plugin guide to establish which one should control that job.
Clear hosting and CDN copies that remain
Sign in to your hosting dashboard, select the correct website and look for its documented cache management control. Purge that site's affected page or page cache. Hosts use different labels, so ask support to identify the active layer if the control is unclear. Give them the page address and the visible detail that remains outdated.
A CDN stores copies closer to visitors. If you use Cloudflare, open the domain's Caching > Configuration page and choose Custom Purge in the purge section. Select URL and enter the complete affected address, including https, then purge. Cloudflare's single-file purge guide explains exceptions for custom cache keys. Purging the page alone does not necessarily purge a separate image or stylesheet URL.
Clear from the source outwards: generated files, WordPress or hosting page cache, then the CDN. Otherwise an outer cache can refill from an older inner copy. A full-site purge increases the work needed to rebuild pages, so choose a quieter period for a large shop and avoid repeating it without new evidence.
Leave specialist caches to the evidence
An object cache such as Redis stores results used by WordPress, while PHP's OPcache stores prepared program code. Neither is the ordinary browser copy of an edited heading. Ask the host to inspect these when database values or recently deployed code remain stale after the relevant checks. A shared Redis flush can affect other sites, so use only the site's documented control with the host's guidance.
Avoid deleting all temporary database values, clearing customer sessions or restarting PHP as a standard cache-clearing routine. Those are different operations with wider effects. If the symptom is a shopping basket that resets or shows another total, follow our cart troubleshooting guide and verify cache exclusions for personalised pages.
Verify the published page and stop repeated purges
Open the exact address as a logged-out visitor on desktop and mobile. Check the corrected detail, images and menus, then test a form or cart if the change affected it. Reload once more to confirm that the rebuilt cached version is also correct. An administrator view alone is insufficient because signed-in users can receive a different response.
If the old content returns, record which purge temporarily fixed it and ask that provider to inspect invalidation, the process that removes outdated copies. When every view still shows the same wrong content, revisit the assigned page or template and recent edits. Cache clearing cannot publish an unsaved change or repair a broken layout by itself.
Get help with the next step
If you cannot identify which layer keeps serving the old page, BugShield can help review the cache setup and check that content updates reach visitors reliably.