WordPress Changes Not Showing? Fix Every Cache Layer

Quick fix: open the page in a private window with a cache-busting query such as ?check=1. If the new version appears only while logged in, purge the WordPress/host full-page cache. If text updates but CSS does not, inspect the stylesheet URL and purge or version that asset. If nothing changes anywhere, confirm the revision was saved and that you edited the live environment.

Do not click every “Purge All” button repeatedly. Identify which layer is stale so the problem does not return after the next edit.

Confirm WordPress saved the change

Reopen the editor and verify the new content is present. Check:

• the update/publish action completed without an error;
• the correct Page, Post or template was edited;
• the status is Published, not Draft or Pending;
• a scheduled revision is not in the future;
• another editor did not overwrite it;
• the public URL belongs to that content item.

Use Revisions to compare the saved version. If the editor itself shows old content after reload, caching is not the first suspect—the save likely failed or was overwritten.

Compare logged-in, logged-out and query-string responses

Test:

https://example.com/page/
https://example.com/page/?cache-check=123

in a private window. Then compare while logged in.

Clear browser cache for the affected asset

Open developer tools → Network, enable Disable cache while tools are open, and reload. Inspect the main HTML and CSS requests.

A hard reload is useful for diagnosis but does not fix what other visitors receive. If it solves the issue, correct asset versioning or cache headers.

Purge the WordPress page cache

Caching plugins store rendered HTML so PHP and the database do not run for every visit. WordPress documents page caching as a major performance technique in its caching handbook.

Purge the specific page when possible. Then verify that publishing/updating content automatically invalidates:

• the edited URL;
• homepage or archive pages that list it;
• related-content blocks;
• feeds where applicable.

If manual purge works but every edit becomes stale again, the invalidation hook or plugin configuration is the real problem.

Purge host/server cache

Many managed hosts cache HTML outside WordPress. Their cache can remain stale even after a plugin purge.

Use the hosting panel’s cache control and inspect response headers such as Age, X-Cache, CF-Cache-Status or provider-specific headers. Header names vary; compare before and after purge.

Do not install a second cache plugin merely to clear a host-level cache.

Purge the CDN or edge cache

A CDN can cache HTML, CSS, JavaScript and images. Purge the affected URL or asset first. A global purge is disruptive on a busy site and hides which rule was wrong.

Check whether the CDN caches HTML unexpectedly, ignores WordPress cookies or applies an “everything” rule to wp-admin. Logged-in/admin pages should bypass public full-page caching.

Regenerate builder or theme CSS

Page builders and some themes generate CSS files from database settings. Saving a page may update the database without rebuilding that asset.

Use the builder/theme’s documented Regenerate CSS, Clear Files or equivalent tool, then purge page/CDN cache. Check filesystem permissions if regeneration fails.

For CSS added through WordPress itself, confirm the active theme and correct Additional CSS panel. Our Custom CSS guide shows the block-theme and classic-theme locations.

Version custom stylesheets

When developing a theme, change the stylesheet URL whenever its file changes. WordPress can use the modification timestamp as the version:

$file = get_stylesheet_directory() . '/assets/site.css';

wp_enqueue_style(
    'site',
    get_stylesheet_directory_uri() . '/assets/site.css',
    [],
    filemtime( $file )
);

Use this in development or a build/deploy process where the file exists locally. A release version or content hash is often better for immutable production assets.

Confirm you edited the correct environment

Compare the browser hostname with the WordPress Site Address, deployment target and database. Common mistakes include:

• editing staging while viewing production;
• deploying code to one server while DNS points to another;
• editing a parent theme while a child theme is active;
• changing a source CSS file without running the build;
• viewing an old container or release directory;
• editing one language/version of a page while viewing another.

Add a harmless temporary marker to the response or inspect deployment commit/version rather than guessing.

Check DNS and multiple origins

During migrations, different resolvers can reach different servers. Query DNS from more than one network and compare the origin response directly if authorized.

Ensure both IPv4 and IPv6 records point to the intended infrastructure. An outdated AAAA record can send some visitors to an old server while others see the update.

Fix the cause, then verify as a visitor

After clearing the responsible layer:

1. load the clean URL logged out;
2. test another device/network;
3. inspect the HTML/CSS response headers;
4. confirm archives and related listings updated;
5. make a second small edit and verify automatic invalidation.

The final step proves the cache configuration works. A one-time global purge only proves that caches can be emptied.