WordPress Changes Not Showing After Update (Cache Troubleshooting Guide)

Common examples include Elementor, Divi, Oxygen, and block-based themes using theme.json.Suggested read: Server Cache vs. Browser Cache vs. Site Cache: What’s the Difference?sudo ls -lah /path/to/cache

sudo rm -rf /var/cache/nginx-rc/runcloud-hub-fastcgi-app-auer/*

3. Reload NGINX

Many modern WordPress themes and page builders generate compiled CSS and layout files that sit outside standard page caching.Most WordPress setups rely on disjointed tools, one plugin for page cache, another for object cache, and a separate dashboard for your CDN. This makes it hard to know which layer is holding onto the old data. With RunCache, server-level NGINX configuration and full-page caching are managed from a single dashboard, which reduces overlap between cache layers.If the source code shows the new version, but the site still looks wrong, you are facing a “Hard Cache” issue on the server or CDN. The browser is requesting the new file, but an intermediate layer (such as NGINX or Cloudflare) has aggressively cached that path and is ignoring the query string. To fix this, you need to update the caching rules of your server and CDN.

How to Fix WordPress Changes That Are Not Showing 

You publish an update, refresh the page, and nothing changes for your visitors.

Step 1: Hard Refresh the Page and Verify 

Since every Content Delivery Network (CDN) operates differently, the exact steps here will vary depending on whether you use Cloudflare, BunnyCDN, or Fastly.Before you assume the server is broken, you need to determine if WordPress is actually telling the browser to fetch the new file. This diagnostic step determines whether the failure occurs within the WordPress application logic or at the server/network level.Sometimes, even after clearing every cache, the old design still appears. This usually happens not because the server is broken, but because the browser thinks it already has the correct file and refuses to ask for a new one. This is common with CSS (styles) and JS (functionality) files. 

Step 2: Purge the WordPress Cache Plugin

Only proceed to server-level cache clearing after completing this step.

Once you have the path, you can remove the cache files. Be extremely careful with the rm -rf command. A single mistake can delete critical system files.RunCloud’s NGINX templates come preconfigured with safe, industry-standard Cache-Control policies. Our stack is tuned to aggressively cache static assets for maximum speed while ensuring dynamic HTML remains fresh and revalidates frequently. This built-in logic prevents “configuration drift” and safeguards you from accidentally locking your users onto an obsolete version of your site.

Clear Theme and Page Builder Caches

If your WordPress changes are not showing after an update, then you are in the right place. In this cache troubleshooting guide, we will move past the basic advice of “have you tried turning it off and on again?” We will dive deep into why your logged-out view differs from what you see as an admin, and how to verify whether you are hitting the page cache or the Redis object cache.If you are not using RunCloud, reload PHP-FPM to force OPcache to rebuild.RunCloud allows you to control exactly how the server handles these dynamic parameters through its advanced NGINX caching rules:On most servers, OPcache persists until PHP-FPM is reloaded.This is common after:

• Elementor – Tools → Regenerate Files and Data
• Divi – Theme Options → Builder → Advanced → Clear Cache
• Oxygen – Settings → Library → Clear Cache
• Block themes – re-save global styles or theme settings

Open your browser’s developer tools and reload the page with the Network tab visible. Click the main HTML request and inspect the response headers. Look for indicators such as:Even if you disable the caching plugin on your WordPress website, your server (NGINX/FastCGI) might still be holding a cached version of your HTML to speed up load times.

Step 3: Purge Server Page Cache (FastCGI / NGINX cache)

Suggested read: How to Create Custom NGINX Configuration Easily Using RunCloudBy following the workflow we outlined, you can stop guessing and start resolving issues systematically. 

1. Locate the Cache Path

If clearing Redis does not resolve the issue, temporarily disable the object cache and reload the page to confirm whether a transient is responsible.To fix this, you need to clear the cache of your WordPress page cache plugin first. If that fails, check your functions.php file to ensure you are updating the version number on your enqueued scripts.However, the process is generally the same: log in to your CDN provider’s dashboard, navigate to the Cache or Purge section, and look for the option to clear the cache. You should always select Purge by URL (or “Custom Purge”) and enter the specific link that is stuck, rather than clearing the entire cache.If you are using a page builder or a performance-focused theme, you must clear its internal cache before touching the server.

2. Delete the Cache Files

If you are running Multisite, prefer site-specific cache purging through WordPress or RunCloud tools rather than command-line flushes.If the issue disappears, the problem is application logic, not caching.Suggested read: How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress PerformanceWhen troubleshooting a website, we should start with the easiest fix (your browser) and work our way back to the server. The most reliable mechanism to force a browser to discard stale data and retrieve a fresh asset is not by manually renaming the file on the server, but by implementing versioning query strings (such as requesting style.css?ver=2.1), which instantly tells the browser that the underlying content has been modified. By appending this unique identifier to the resource URL, you can bypass local browser caches and CDN edges.It is recommended to set a 1-year expiration for static assets (such as images and fonts) for optimal performance.

If you find yourself constantly modifying plugin settings, consider RunCache. It combines page, object, and edge caching into a single dashboard, which eliminates the need for complex plugins that don’t effectively communicate with your server.Typical actions include:If you are using a third-party caching plugin, clear its cache once before moving on. If this does not resolve the issue, do not keep purging here.

If the response is a fresh 200 but the content is still wrong, the issue lies inside WordPress logic or asset generation.

Step 4: Clear Object Cache 

Managing NGINX rules, Redis instances, and CDN purges separately is a recipe for frustration. RunCloud RunCache solves this by integrating server-side page caching, object caching, and edge caching into a single, intuitive dashboard. You get the raw speed of a custom-tuned server with the ease of use of a simple plugin.Inspect the HTTP response headers in your browser’s developer tools (Network tab) and look for headers such as X-Cache, X-RunCache, or cf-cache-status that indicate a HIT. Before clearing anything, use the quick checks below to identify which cache layer is actually blocking your update.However, if you only want to flush the cache for a particular WordPress site, navigate to your WordPress root directory and run the wp cache flush command. This will clear the object cache for that site specifically, without risking data loss for other applications sharing the same Redis instance.

In the above example, we can see there are two different folders present on the server. You can delete the folder you want to clear the cache from. For example, if you want to clear the cache for runcloud-hub-fastcgi-app-auer, run the following command:

This caching layer stores the results of database queries in memory to speed up PHP execution, but it can sometimes hold onto stale data even after the content has changed. If you only clear your page cache (HTML), these database-driven elements will persist because the server continues to retrieve the old query results from memory instead of the database.sudo rm -rf /var/run/nginx-cache/*

If you need to clear the NGINX FastCGI cache manually, delete the temporary files NGINX has created, then reload the service. Here is how to do it safely.However, the best way to handle caching is to use a platform that simplifies it.

Clear PHP OPcache After Code Changes

A cached response confirms that the issue is not WordPress itself but an upstream cache layer.How to interpret the results and fix the issue:

• Theme file edits
• Plugin updates
• Custom PHP changes

Suggested read: How to Easily Fix Leverage Browser Caching Warning in WordPressRunCache supports smart purging. It handles edge caching logic for you, ensuring that when you update content, the specific URL is automatically cleared from the CDN. This keeps your site fast and your server happy, without you ever needing to log in to a separate CDN dashboard.If your configuration separates caches by folder, then you can delete only a part of the cache without changing anything else. To do this, first run the following command to see a list of all the available folders in the Nginx cache:Always confirm whether Redis databases or FastCGI cache folders are isolated per site before manually clearing them.

Step 5: Purge CDN Cache 

This step is often skipped, which is why many cache purges appear to do nothing.sudo systemctl reload nginx
# OR
sudo service nginx reload

When parts of your site that update automatically (like a “Recent Posts” widget, shopping cart count, or user login status) remain stuck, the issue is likely within your Object Cache (typically Redis).

Run this command to find the path:

Guessing wastes time. Confirm the cache status before making any changes.

How to Confirm Which Cache Layer Is Responding

Yes, if Cache-Control headers set a long Time-To-Live (TTL) without validation, browsers will refuse to request new versions until the timer expires. RunCloud lets you standardize these rules at the NGINX layer, preventing config drift and ensuring users across all devices receive the latest updates.If the source code still shows the old version, the issue is not the server cache. The issue lies within WordPress itself. Your caching plugin might be serving a stale HTML page that contains the old link tags, or your theme might be “hardcoding” the version number instead of using the dynamic wp_enqueue_style function.

• X-Cache or X-RunCache – server page cache
• cf-cache-status – Cloudflare edge cache
• Status 304 – browser or intermediary cache revalidation

Debugging a WordPress site that refuses to update is one of the most tedious parts of development, but it doesn’t have to be a mystery. As we’ve discussed, the “invisible wall” preventing your changes from showing up is usually a result of multiple caching layers (browser, server, object, and CDN) working a little too well.If theme or plugin code changes do not appear, PHP’s opcode cache may still be serving an older compiled version.

How to Handle Real-Time Updates with Stale Cached Assets

RunCloud offers a much simpler solution that eliminates the need for SSH access or complex commands. You can manage Redis directly from the WordPress Dashboard by navigating to your RunCache settings and clicking the Clear Redis Object Cache button.

Step 1: Fix CSS/JS Cache Busting With File Versioning

Suggested read: How To Use Redis Full-Page Caching To Speed Up WordPressIf the Incognito window still shows the old version, the issue is not your browser and must be upstream.

• Include cache based on matching query string: This setting lets you specify parameters that trigger the creation of a unique cache file, ensuring that visitors viewing ?currency=USD see a different cached version than those viewing ?currency=EUR without slowing the page.
• Exclude cache based on matching query string: Conversely, this option lets you define specific query strings that will force the server to bypass the page cache entirely whenever they are present, ensuring that dynamic or sensitive URLs are always served live from the backend.

Step 2: Confirm the Browser is Requesting the New CSS/JS URL (Not a Cached URL)

Caching is the process of storing commonly accessed information on the server. To make your site load faster, browsers, plugins, servers, and CDNs show visitors a “snapshot” instead of rebuilding the page from scratch every time. This works well in most scenarios, but the problem arises when you update the site, and the cache keeps showing the old snapshot.Here is how you can do this:

• Open a Fresh Session: Open your website in an Incognito (Chrome) or Private (Firefox/Safari) window to ensure your local browser history isn’t interfering with the test.
• Access the Source Code: Right-click anywhere on the page background and select “View Page Source” (or press Ctrl + U on Windows / Cmd + Option + U on Mac). Do not use “Inspect Element” for this, as the DOM can sometimes differ from the raw source delivered by the server.
• Locate the Specific File: Press Ctrl + F (or Cmd + F) to open the search bar. Type in the name of the file you modified, such as style.css, main.js, or the specific plugin stylesheet handle.
• Analyze the Query String: Focus on the filename’s ending. You are looking for a version parameter, which typically looks like ?ver=1.2.3 or ?ver=time_stamp. Compare this number to the version you expect (e.g., if you just updated a plugin from version 2.0 to 2.1, the tag should read plugin.css?ver=2.1).

This guide explains why those failures happen and shows you how to fix them in the correct order, without guessing.

• Scenario A: The Version Number Has Not Changed

If you want consistent performance and a “Clear Cache” button that actually works,create a new test site today to experience RunCache. sudo grep -r "fastcgi_cache_path" /etc/nginx/

• Standard Install: Usually /var/cache/nginx or /var/run/nginx-cache.
• RunCloud Server: located at /var/cache/nginx-rc/ 

This occurs because WordPress typically bypasses caching for logged-in users, while logged-out visitors are served a static HTML copy stored in the server’s page cache. To resolve this, you need to purge the server-level cache (FastCGI/RunCache) via the RunCloud dashboard, which clears the stale HTML without affecting your browser settings.Option A: Clear Everything (Root/Sudo)Before changing any settings, force your browser to reload the page. On Windows, press Ctrl + F5, or Cmd + Shift + R on Mac. Alternatively, you can open the URL in an Incognito/Private window.However, applying those same rules to your dynamic HTML pages is disastrous. If you accidentally instruct browsers to cache your homepage HTML for 30 days, no amount of server-side purging will resolve the issue. The visitor’s browser will simply stop requesting the page from your server entirely, relying on its local copy until the timer expires.This step is not required for content edits but is critical for code-level changes.

Special Considerations for WordPress Multisite

WordPress Multisite environments often share Redis instances, PHP workers, and cache directories across multiple sites. Flushing object cache or Redis globally may affect other sites on the network.Run the following command to clear all the cache created by NGINX:If CSS remains stale, the asset URL likely hasn’t changed, so browsers and CDNs continue serving the file based on previous expiration headers. While you should implement versioning for your assets, you can also check your RunCloud NGINX configuration to ensure headers are set correctly and purge the specific file path from the server.

Wrapping Up

On RunCloud servers, PHP-FPM reloads are handled automatically through the dashboard and do not require manual intervention.If these files are stale, server purging will have no effect because WordPress is still outputting old asset references.Incorrectly configuring the Cache-Control headers can create persistent caching issues. This HTTP header instructs the user’s browser: “Save this file locally and do not check the server for updates for X days.”Always start by clearing the server-level cache, as this is the most common source of “stuck” content for dynamic sites. RunCloud lets you safely clear server and Redis object caches from a single dashboard, ensuring fresh content is served before you need to troubleshoot downstream layers like the CDN or the local browser cache.If your WordPress website is not showing changes after an update, caching is the most common cause.

FAQs on WordPress Changes Not Showing After Update