If WordPress keeps showing old text, an old image, outdated styles, or a broken layout after you save changes, start with the safest check: open the affected page in a private browser window.
If the update appears there, your browser is showing a local cached copy. If it still looks old, clear the site’s cache layers one at a time: WordPress caching plugin, hosting cache, CDN cache, then object cache if the stale part is database-driven.
Confirm the change was saved in the right place
Before clearing caches, rule out the common editing mistakes:
- Make sure the page, post, template, or product is published.
- Confirm you are viewing the same URL you edited.
- If you use a page builder, save or update the page inside the builder, not only in the WordPress editor.
- If the issue is in a header, footer, archive, or product layout, check the theme builder or template settings.
- View the page while logged out, because administrators often bypass cache.
- Add a small, distinctive test change and reload the exact affected URL.
If only mobile or only desktop is stale, the cache may store separate versions for different devices. Clear both versions if your cache plugin or host offers that option.
Rule out the browser cache
Open the affected page in a private or incognito window. You can also hard reload the page:
- Windows or Linux:
Ctrl+Shift+R - macOS:
Command+Shift+R
If the private window shows the correct page, clear cached files for that site in your browser. Avoid clearing cookies unless needed, since that can sign you out of websites.
For a more precise check, open your browser’s developer tools, go to the Network panel, enable Disable cache, and reload the page while the panel remains open. If the update appears only with browser cache disabled, the stale copy is local to your browser.
Purge your WordPress cache plugin
Most caching plugins add a clear-cache option to the WordPress admin toolbar or their settings page. Use the plugin’s full page-cache purge first.
After clearing it:
- Open the affected URL in a private window.
- Check while logged out.
- Test both desktop and mobile if the issue is layout-related.
- Reload once more to confirm the regenerated cached page is correct.
Do not uninstall a caching plugin just to clear its cache. Uninstalling can remove settings and still leave hosting or CDN caches untouched.
If the page looks correct briefly and then becomes stale again, review optimization settings such as minify, combine, defer, delay JavaScript, remove unused CSS, or critical CSS. Turn off one setting at a time, purge the cache, and retest. That gives you a clear rollback path.
Clear the hosting cache
Many managed WordPress hosts cache pages before WordPress loads. A WordPress plugin purge may not clear this layer.
Open your hosting dashboard and look for controls named Clear cache, Purge cache, Flush cache, Flush page cache, or similar. If your account contains multiple sites, clear only the affected site when possible.
Check the page in a private window afterward. If the update appears, the hosting cache was serving the stale page. Contact your host if there is no cache control, the cache keeps returning old content, or the dashboard purge does not affect the page.
For WordPress.com sites, use WordPress.com’s official site cache clearing instructions instead of adding another caching plugin.
Purge the CDN cache
A CDN can keep old copies of pages, CSS files, JavaScript files, images, and fonts even after WordPress and your host are current.
If your CDN supports targeted purging, purge the affected URL first. Use a full cache purge only when many pages or assets are stale, because it temporarily reduces caching benefits across the site.
If the text is current but the design is broken, the stale item may be a CSS or JavaScript file rather than the page itself. Open the affected page while logged out, inspect the file URL if needed, and purge that asset from the CDN.
For an image that will not update, purge the image URL from the CDN or upload the replacement with a new filename. If you replace media through SFTP or a hosting file manager, keep a current backup and preserve a copy of the original file.
Compare preview and public page
Use the WordPress editor preview as a reference point.
- If the preview is correct but the public page is stale, focus on page cache, hosting cache, or CDN cache.
- If both preview and public page are stale, the change may not have saved, or you may have edited the wrong page, product, template, or builder layout.
- If the HTML content is current but the layout is wrong, focus on cached or optimized CSS and JavaScript.
- If only dynamic values are old, such as prices, menus, widgets, counts, or account-specific data, check object caching and the plugin that creates that data.
This prevents unnecessary database edits and repeated full cache purges.
Isolate a plugin or optimization conflict
If the issue started after changing cache, performance, image, or script settings, temporarily disable the most likely setting first. If that does not help, deactivate the suspected plugin and retest.
On a live store, membership site, or busy business site, use a staging copy if available. Another safer option is the official Health Check & Troubleshooting plugin, which can disable plugins and switch themes only for your administrator session while visitors continue seeing the normal site.
Change one thing at a time:
- Disable one suspected setting or plugin.
- Purge the WordPress cache.
- Purge hosting and CDN caches if they are active.
- Test the affected URL in a private window.
- Restore the setting or plugin if nothing changes.
If disabling an optimization feature fixes the issue, leave that feature off and re-enable the rest of the cache plugin. Then restore features individually until the stale content or broken layout returns.
Treat object cache separately
Persistent object caches such as Redis or Memcached store database query results and computed values. They are not the same as a full-page cache.
Object cache is more likely involved when the page itself is fresh but database-driven information remains old. Common examples include product prices, menus, widgets, counts, options, or plugin-generated blocks.
Use the object-cache purge control provided by your host or caching plugin. Do not restart Redis, delete cache data, or run server-level flush commands on shared hosting unless your provider confirms the cache belongs only to your site.
If clearing object cache fixes the issue but it returns, update the plugin responsible for the stale value and report the problem to its vendor with the affected URL and the steps that make the stale data appear.
Check PHP opcode caching only after file changes
PHP opcode caching stores compiled PHP code, not normal page content. It can matter after a theme, plugin, or custom PHP file was changed, but it is not the usual reason an edited post or page still shows old content.
If recently changed PHP files are not taking effect, ask your host to reset the PHP opcode cache or restart the site’s PHP service. On shared hosting, avoid server-wide cache resets unless the host instructs you to do it.
A PHP service restart that fixes a code change does not mean regular WordPress content was cached there. Continue treating browser, page, hosting, CDN, and object caches as separate layers.
Recover from a cache-related layout failure
If cache optimization breaks the public layout:
- Turn off the most recently enabled optimization setting.
- Purge the WordPress cache plugin.
- Purge the hosting cache.
- Purge the affected CDN URL or the CDN cache.
- Test while logged out on desktop and mobile.
If the WordPress dashboard is inaccessible, confirm you have a current backup first. Then use your host’s file manager or SFTP to rename the suspected plugin directory temporarily. WordPress will deactivate that plugin when it cannot find the folder.
After dashboard access returns, rename the directory back to its exact original name before changing plugin settings. Do not reactivate the plugin until you have reviewed or reverted the setting that caused the failure.
Avoid manually deleting generated cache directories unless the plugin or host documents that exact procedure. Deleting the wrong files can create permission problems or remove configuration while leaving upstream caches untouched.