WordPress change not visible: find and clear the right cache

Check that the expected change is actually public

You have corrected a WordPress page, but the site still shows the old version. Before clearing caches, check the page, its address, and the save state. A preview, draft, different language, or different template may explain the discrepancy without an old copy being involved.

In the editor, confirm that the intended update succeeded, then open the content’s exact public address. Choose a recognizable detail already present in your change, such as a corrected title. Do not add artificial text in production as a test. Keep the time and expected result in your notes.

The aim is to restore this version for visitors while keeping caching that speeds up the site. The procedure starts in the browser, then examines layers actually present at the hosting and CDN levels. If the displayed content belongs to another user or reveals private information, that is a personalization and confidentiality issue requiring its own treatment rather than a simple refresh.

Distinguish the browser, server page cache, and CDN

The browser may retain files or a response already received. A server page cache retains HTML generated by WordPress. A CDN may store another copy close to visitors. An object cache instead retains data or calculation results; clearing it is not necessarily the right action for an old HTML page.

The layers do not necessarily hold the same content or use the same retention period. A CDN serving images does not automatically retain HTML pages; Cloudflare does not cache them by default. However, a special rule or additional service can change that behavior.

Record the tools already active: a cache plugin, built-in hosting tool, CDN, and any site offline feature. Do not install a new cache to clear the existing one. Depending on the procedure, the following actions require your browser, WordPress administration, or the provider account. In multisite, always confirm the target site before a command that could affect the whole network.

Approach 1: compare without the browser’s HTTP cache

This approach applies if the old version seems limited to your browser. It requires no WordPress access. The expected result is a comparison between normal loading and a fresh network retrieval. A better version after this check points diagnosis toward the computer or its conditions without by itself proving that all remote caches are correct.

The setting described does not purge copies retained by the host or CDN. To return to normal behavior, uncheck Disable cache and close the tools. You do not need to delete passwords, history, or all cookies for this first test.

1. Open the exact public page, then press F12 and open Chrome’s Network panel.
2. Check Disable cache and reload while the tools remain open.
3. Select the relevant document or file. Check its response and any indication that it loaded from memory, disk, or a service worker.
4. Compare the expected detail, uncheck Disable cache, then repeat in ordinary browsing. If needed, with tools still open, hold the reload button or open its context menu to choose Empty cache and hard reload. This affects the local cache, not a site purge.

Check a service worker separately

A service worker is a site script that can intercept requests and provide a local copy, particularly for offline functionality. Its storage is not the same as the ordinary HTTP cache. If Network shows it participating, you can temporarily bypass it for diagnosis without deleting it.

In Chrome tools, open Application, then Service Workers. Check that the displayed service actually belongs to this site. Check Bypass for network, reload the page, and compare the version. Then uncheck this option and open normally again. The expected result is to learn whether this layer contributes to the old response.

If bypassing resolves the defect, have the update strategy of the component managing that service worker checked. Do not blindly click Unregister or delete all storage: that can alter local data and offline behavior. Browser bypassing is a diagnostic measure, not a correction to ask of every visitor. Keep the script address and observations without exporting session data.

Read headers without confusing caching with old content

In Network, select the relevant request and then Headers. Cache-Control describes retention or validation instructions. no-cache does not mean that no copy is stored: this directive requires validation before reuse. no-store requests that the relevant response not be stored; adding it does not retroactively purge every copy already distributed. Do not replace these values globally to resolve one defect.

A 304 status means that the response to a conditional request permits reuse of a copy; it does not prove that WordPress lost your update. Look at the expected content and exact resource. The document may be recent while a CSS file or image is not.

With Cloudflare, CF-Cache-Status gives a clue about that layer: HIT indicates a response found in its cache, while MISS indicates an eligible resource absent from that cache when requested. Absence of HIT does not prove absence of a hosting cache. Age must also be interpreted according to its source; its value is not the date of your last editorial change. Keep useful headers with the URL and time.

Approach 2: clear WordPress.com’s managed caches

This procedure concerns WordPress.com with hosting features accessible on a plugin-enabled site. Current documentation covers Personal, Premium, Business, and Commerce in this context. Access to the correct site’s hosting dashboard is required. On another host, use its documented tool; do not look for the same menus in self-hosted WordPress. Without these features, WordPress.com manages the site cache automatically: continue local checks and contact its support if necessary. This diagnosis requires neither a purchase nor an extra cache plugin.

For an old public page, start with the global edge cache. The object cache concerns intermediate data and should not systematically be cleared for a visual change. The menu also offers Clear all caches to invalidate both layers when justified by diagnosis. Rebuilding may slow subsequent visits; purging does not change published content.

1. Open the WordPress.com hosting dashboard and select the relevant site title.
2. In the sidebar, open Settings, then Caching in the Server section.
3. Choose to clear the global edge cache for an old public page. If both layers need invalidation, use Clear all beside Clear all caches. Wait for confirmation; the relevant buttons then remain unavailable for one minute.
4. Then open the public page in a logged-out session and verify the change. Do not repeat the purge on every reload; if the version remains old, examine the other layers and the resource actually received.

Purge the page with an existing WP Super Cache installation

This approach concerns an installation already using WP Super Cache, Automattic’s free plugin. The verified version is 3.1.5, requiring at least WordPress 6.8 and PHP 7.4, with testing declared up to WordPress 7.1.4. Recheck these details if your version differs. Do not install this plugin to control a cache supplied by another tool.

The Delete Cache button does not have the same scope everywhere you click it. On the public page, with appropriate permissions, it targets that page’s cache. From administration, it may clear site caches. The more targeted purge is therefore preferable for an isolated change.

1. While logged in with an authorized account, open the changed page’s public address, not its editing screen.
2. In the administration bar displayed on that page, use Delete Cache when present and confirm that you are on the correct content.
3. Then open the same URL in a logged-out session. Check the expected detail, then reload to check the rebuilt copy.
4. If the button is absent, do not change account permissions to make it appear. An administrator can use Settings, WP Super Cache, Easy tab, Delete Cache, knowing that this action targets the site more broadly. On a network, do not choose Delete Cache On All Blogs for a single page.

Invalidate copies in the correct order

If several layers retain the page, start with the one generating it or keeping it close to WordPress, then invalidate the CDN copy. If you clear only the CDN while the server still supplies the old response, the next visit may refill the remote cache with that same old version.

Keep a note of each action: tool, site, URL, and time. Check after the first layer before concluding that everything needs purging. For a global navigation or template change, several pages may genuinely depend on the modification; the scope will then be broader than one URL. It must remain justified by that change.

A purge does not normally alter retention rules. There is therefore no setting to restore after a simple invalidation: subsequent requests rebuild the copies. If you also changed a setting, keep its initial value and undo that change separately. Do not manually delete cache directories or empty database tables to force rebuilding.

Approach 3: purge a URL in Cloudflare

This approach targets a domain already managed by Cloudflare, with a resource actually cached at that layer. It requires authorized access to the correct domain in the dashboard. The purge does not delete the origin file or clear copies already retained in visitors’ browsers.

The expected result is a fresh retrieval of the resource from the origin, whose version must therefore already be correct. Check the complete URL: the document, its CSS file, and its image are separate resources. Do not choose a general purge instead of identifying them. If the address responds with a 301 or 302 redirect, purging it invalidates that cached redirect, not automatically the destination page. Separately identify the resource whose version is old before requesting another purge.

1. In the Cloudflare dashboard, select the relevant domain, then open Caching, Configuration.
2. Under Purge Cache, choose Custom Purge, then URL under Purge by.
3. Enter the exact address of the resource to invalidate, using the correct protocol, domain, path, and relevant parameters where applicable. The path is case-sensitive.
4. Review the list and click Purge. Then reload in a control session and check the content and its headers.
5. If the version remains old, do not repeat automatically: examine variants and cache keys. A simple purge has no content to restore; the resource remains available at the origin.

Account for cache keys and variants

One page may have several copies according to language, parameters, device, or other criteria defined by configuration. The cache key is the collection of information identifying a copy. If you measure one variant and purge another, the result can appear unchanged.

Cloudflare specifies that purging by URL in its dashboard is insufficient for certain custom keys containing headers, cookies, or other properties. Enterprise zones have special cases for device type and country in advanced options. This does not turn a simple purge into universal invalidation of every variant.

If this configuration exists, record the rule and criteria used, then have the person managing the cache use the appropriate purge method. Do not simplify the key by arbitrarily removing language or a cookie: you could mix content that must remain distinct. Adding a random URL parameter may change the cache route, but some rules ignore these parameters; it is therefore not universal proof of direct origin access.

Another point to have checked if targeted purging fails: a Cloudflare rule limited to GET requests may not match the purge request. The owner must check this condition against the rule documentation. Do not replace it with a global rule or repeatedly purge all variants to mask the discrepancy.

Distinguish recent HTML, an old file, and a generated file

If the text is correct but colors, a script, or an image remain old, examine the exact resource in Network. The HTML page may contain the correct change while requesting a file whose address has not changed. Purging only the document does not guarantee renewal of all linked files.

For a replaced image, check the variant actually chosen by the browser, not just the library original. For CSS generated by a builder or optimizer, check the produced file and the tool creating it. A purge does not necessarily rebuild an outdated generated file; use the relevant component’s documented feature if this case is confirmed.

Correct file version management helps prevent recurrence. WordPress notably allows associating a version with a stylesheet loaded using wp_enqueue_style(). This adaptation belongs in the code or tool publishing the resource; randomly changing a URL in the browser does not update every visitor. Preserve old resources still referenced during the transition and have the generation, publication, and invalidation order checked.

Avoid permanently disabling caches

A correctly configured cache reduces repeated work and brings responses closer to visitors. An old copy calls for correcting the update cycle, not necessarily permanently removing every layer. Repeated general purges can increase load and slow the first visits afterward.

Keep caches active during ordinary checks, except for a precise comparison with the initial setting preserved. Do not move the domain off the CDN or change its DNS to observe a page: you would also alter its route, protection, and sometimes availability. Existing purge menus allow a more limited action.

If you adjust a retention period, choose it according to the content type and available invalidation mechanism. An editorial page, versioned file, and personalized page have different needs. Do not copy the same Cache-Control header across the entire site to obtain immediate updating. Keep the initial value and check effects on public and private responses before any lasting change.

Check visitors and the rebuilt copy

After invalidation, open the page in a logged-out session and check the expected detail. Reload a second time to verify that the rebuilt copy remains correct. Then compare another browser or device if the defect affected several visitors. Keep the same domain, language, and relevant parameters.

In Network, distinguish the document from linked files. A correctly cached response may now contain the right version; a HIT status is therefore not a failure in itself. What matters is the received content and its consistency with the intended change.

Also check the functions affected by the change. For a page with an account, cart, or other personalized content, ensure the context remains correct using the planned test journeys. Do not trigger a real operation to verify a simple refresh. Record the purge time and result instead of continuing to clear copies once the content is validated.

If the old version returns, check the update cycle

If a purge works and then the old version reappears, examine the source filling the cache: another origin server, a generated file, synchronization, or a forgotten variant. A copy may be refreshed with content already incorrect before reaching the CDN. Keep URLs, times, responses, and the layers already invalidated.

Check that the change was made on the correct installation and that backups or deployments do not restore an old file. An old version inside the editor itself is not resolved by purging only the public cache. Also distinguish template changes from page-specific content.

Then send a precise record to the site maintainer: expected change, date, affected resource, visitor context, and the result of each procedure. Keep cache settings documented with their roles. This allows invalidation or generation to be corrected at its source without asking visitors to clear their browser after every update.

Version a custom stylesheet when loading it

This correction concerns a stylesheet belonging to your child theme, already loaded by code you control. It replaces neither an HTML purge nor rebuilding a builder’s CSS. In the existing registration code, a version based on the file’s modification time can change the requested URL after an edit. Test on a copy and keep the previous function.

Adapt the path to the existing file and integrate this principle into its current registration; do not load the same stylesheet a second time under another handle. Keep its actual dependencies if it has any. This code is not intended for WordPress core or a generated file. In an already open PHP file, do not add a second opening tag.

After changing the CSS, check in Network that its requested version changes and that the received content is correct. An old cached HTML page may still reference the old version: invalidate that page using the procedure already described. Some CDN configurations ignore parameters; check the cache key before concluding. If deployment preserves file dates, prefer a controlled release version. To undo it, restore the previous registration function and file; do not erase all theme resources.

add_action( 'wp_enqueue_scripts', function () {
    $relatif = '/assets/css/personnalisation.css';
    $fichier = get_stylesheet_directory() . $relatif;
    if ( ! is_file( $fichier ) || ! is_readable( $fichier ) ) {
        return;
    }
    $date = filemtime( $fichier );
    if ( false === $date ) {
        return;
    }
    wp_enqueue_style(
        'bpc-personnalisation',
        get_stylesheet_directory_uri() . $relatif,
        array(),
        (string) $date
    );
} );