WordPress Shows Different Content Logged In vs Logged Out

You make a change to your WordPress site, reload the page while logged in, and everything looks exactly right. Then you open a private browser window or ask someone else to check, and the page looks completely different or is still showing old content. It is one of the more disorienting problems to encounter as a site owner, because everything seems fine from where you are sitting.

The cause is almost always caching, but the word caching covers a lot of ground. There may be a caching plugin active on your WordPress installation, a server-level cache running on the hosting server, a CDN like Cloudflare caching your HTML pages, or some combination of all three. Each layer operates independently and can serve different versions of your content depending on how it is configured.

This guide explains exactly why logged-in and logged-out users see different things, how to identify which caching layer is responsible, and how to fix the configuration at each level so all visitors see consistent, up-to-date content.

Quick Fix Summary

• Clear all caches including your WordPress plugin cache, server cache, and Cloudflare cache
• Test the site while logged out using a private or incognito browser window
• Temporarily deactivate your caching plugin to confirm whether caching is the cause
• Ensure dynamic pages like cart, checkout, and account are excluded from all caching layers
• Review Cloudflare's caching rules to confirm HTML pages are not being cached at the CDN level

Why Logged-In and Logged-Out Users See Different Content

WordPress generates pages dynamically, which means it builds each page by querying the database and assembling HTML on every request. This is flexible but slow at scale, so caching tools step in to store pre-built versions of pages and serve them to visitors without triggering a full page generation on every load.

The problem is that logged-in users and logged-out visitors are treated very differently by both WordPress and its caching tools. When you are logged in as an administrator or editor, WordPress sets authentication cookies in your browser. Most caching systems detect these cookies and intentionally skip the cache for you, serving the live, freshly generated version of each page. This is by design, so that you see your changes immediately without having to clear anything.

When a visitor arrives without those cookies, the caching system serves whatever version of the page is currently stored in the cache. If that cached version is old, was built with different content, or was built when a widget or menu was configured differently, the visitor sees something that does not match what you see. The gap between what you see and what they see is entirely a function of what is in the cache and when it was last built.

This is why the usual advice to simply reload the page or clear your browser cache does not solve the problem. The issue is not in your browser. It is in a cache layer that sits between your server and your visitors.

Step 1: Confirm the Problem Is Cache-Related

Before changing any settings, confirm that caching is actually the cause. Open a private or incognito browser window, which ensures you have no WordPress cookies, and navigate to the page that looks wrong. If it shows different content than what you see when logged in, caching is almost certainly responsible.

You can also inspect the HTTP response headers of the page to see which cache layer is serving it. In Chrome, open Developer Tools, go to the Network tab, reload the page, click on the main document request, and look at the response headers. Headers to look for include:

• X-Cache: HIT — indicates a cached version is being served, either at the server or CDN level
• CF-Cache-Status: HIT — confirms Cloudflare served a cached version of the page
• X-LiteSpeed-Cache: hit — indicates LiteSpeed's server cache is active
• Age: — shows how many seconds ago the cached version was built; a high value means the cache is stale

If none of these headers are present and the content is still different, the issue may be a plugin conflict rather than caching, and you can skip ahead to the plugin conflict section below.

Step 2: Clear Every Cache Layer

The fastest way to restore consistent content for all visitors is to clear every cache layer simultaneously. Clearing only one layer while others remain active will often not fix the problem.

WordPress caching plugin

If you are using WP Rocket, navigate to the WP Rocket menu in your WordPress dashboard and click Clear Cache. If you are using LiteSpeed Cache, go to LiteSpeed Cache in the menu and click Purge All. W3 Total Cache, WP Super Cache, and other plugins have similar purge options in their respective menus. Clear everything, not just the cache for a specific page.

Server-level cache

Many hosting servers run a cache layer independently of any WordPress plugin. LiteSpeed servers have their own object and page cache that operates at the server level. Nginx servers may run FastCGI cache. cPanel hosting environments sometimes have a built-in caching layer. In many cases, clearing the cache from your WordPress plugin also clears the server cache, but not always. If you have WHM or cPanel access, check for a caching configuration panel. You can also contact your hosting provider and ask them to purge the server cache for your account.

Cloudflare cache

Log into your Cloudflare dashboard, select your domain, navigate to Caching, then Configuration, and click Purge Everything. This clears Cloudflare's edge cache for all pages on your domain and forces it to fetch fresh content from your origin server on the next request. After purging, wait two to three minutes before testing, as the purge may take a moment to propagate across all of Cloudflare's edge nodes.

After clearing all three layers, test the site again in a private browser window. If the content now matches what you see while logged in, the problem was a stale cache. If the content is still different, the caching configuration needs adjustment to prevent the same issue from recurring.

Step 3: Verify Your Caching Plugin Is Excluding Dynamic Pages

Clearing the cache fixes the immediate problem but does not prevent it from happening again. For that, you need to ensure your caching plugin is configured to exclude pages that contain dynamic, user-specific content from being cached at all.

Pages that should never be cached include the shopping cart, the checkout page, the account page, the login page, and any page that shows content specific to the current visitor's session. On a standard WordPress site, these are typically at paths like /cart, /checkout, /my-account, /login, and /register. Your caching plugin should have an exclusion list in its settings where you can add these paths.

In WP Rocket, go to Settings, then Cache, and look for the Never Cache URLs section. Add each of the dynamic page paths there. WP Rocket also has a built-in WooCommerce integration that handles cart and checkout exclusions automatically when WooCommerce is active, but it is worth confirming this is enabled.

In LiteSpeed Cache, go to LiteSpeed Cache in the menu, then Cache, and look for the Excludes tab. You can add URL patterns there that will be bypassed by the cache. LiteSpeed also has a dedicated WooCommerce settings tab that configures these exclusions automatically.

Beyond specific page paths, any page that uses shortcodes or blocks to display content that changes based on who is viewing it should also be excluded. This includes membership content, conditional display plugins, and any plugin that shows different content based on user role or login status.

Step 4: Review Cloudflare's Caching Behaviour for HTML Pages

Cloudflare is designed to cache static assets like images, stylesheets, and JavaScript files. By default it does not cache HTML pages, which means your WordPress pages should be fetched fresh from your origin server on every request. However, this default can be overridden by Page Rules or Cache Rules that were set up to improve performance, and those rules can cause exactly the problem you are seeing.

Log into Cloudflare, select your domain, and navigate to Rules, then Page Rules or Cache Rules depending on which your account uses. Look for any rule that includes Cache Everything as its action. A Cache Everything rule applied to your WordPress pages will cause Cloudflare to store and serve HTML pages from its edge network, bypassing your origin entirely on subsequent requests. If visitors are receiving a cached version from Cloudflare, even clearing your WordPress and server caches will have no effect on what they see.

If you find a Cache Everything rule, you have two options. You can remove it entirely if it was set up by mistake. Or, if it was intentional for performance reasons, you can add a bypass condition that prevents Cloudflare from caching pages when a WordPress login cookie is present. This is done by adding a condition to the rule that checks for the wordpress_logged_in_ cookie and sets the cache level to Bypass when that cookie exists.

For most WordPress sites, the recommended Cloudflare cache configuration is to leave HTML pages on the default caching level, which means Cloudflare does not cache them, and to cache only static assets. This gives you the CDN benefits for images and scripts without risking stale HTML content for visitors.

Step 5: Check for Plugin Conflicts

If you have cleared all caches and verified the exclusion settings but visitors are still seeing different content, a plugin may be generating different output depending on whether someone is logged in. This is less common than a caching issue but does happen, particularly with plugins that use shortcodes or blocks to show conditional content.

To test for a plugin conflict, deactivate all plugins except WordPress itself and check the affected page while logged out. If the content now matches, reactivate plugins one at a time and check after each one until the difference reappears. The last plugin you activated before the problem returned is the source of the conflict.

Common culprits include membership and access control plugins that restrict content based on login status, personalisation plugins that display different content to different user segments, and some page builders that render shortcodes differently in the editor versus on the front end. Once you identify the responsible plugin, check its settings for options related to caching compatibility or logged-out display behaviour, or contact the plugin developer for guidance.

Multiple Caching Layers and Why They Conflict

The most complicated version of this problem occurs when multiple caching layers are active simultaneously and not configured to work together. A typical setup might include a WordPress caching plugin, a server-level LiteSpeed or Nginx cache, and Cloudflare sitting in front of everything. Each layer has its own rules about what to cache, for how long, and under what conditions to bypass the cache.

When these layers are not aligned, you can end up with scenarios where the WordPress plugin clears its own cache but the server cache still serves an old version, or where Cloudflare serves a page it cached before either of the other layers were cleared. The visitor may even receive different content on different page loads depending on which edge node or cache server their request happens to hit.

The solution is not necessarily to remove caching layers, since each one provides real performance benefits. The solution is to ensure that all layers are configured with the same set of exclusion rules, that the TTL values are reasonable and not set to extremely long durations, and that clearing the cache in one layer triggers a purge in the others where possible. Most major caching plugins have integration settings for Cloudflare that allow them to automatically trigger a Cloudflare purge whenever the WordPress cache is cleared.

In WP Rocket, go to Settings, then Add-ons, and look for the Cloudflare integration. Entering your Cloudflare API credentials there allows WP Rocket to purge the Cloudflare cache automatically whenever it clears its own cache. LiteSpeed Cache has a similar CDN integration tab. This kind of joined-up configuration eliminates most of the stale content issues that arise from running multiple caching layers.

WooCommerce-Specific Considerations

If your site runs WooCommerce, the consequences of a misconfigured cache are more serious than a cosmetic difference in how a page looks. Cart and checkout pages contain session data that is unique to each visitor. If a cached version of the cart page is served to a new visitor, they may see a cart that belongs to a previous session, complete with items they did not add. On the checkout page, a cached version could display incorrect totals, missing shipping options, or in extreme cases partial data from another user's session.

WooCommerce itself sets cookies that most caching plugins recognise as signals to bypass the cache. When a visitor adds something to their cart, WooCommerce sets the woocommerce_cart_hash and woocommerce_items_in_cart cookies. A correctly configured caching plugin will detect these cookies and stop caching pages for that visitor's session.

If your caching plugin does not have native WooCommerce support, you need to manually add all WooCommerce cookies to the cookie exclusion list in your caching plugin's settings. You also need to manually exclude the cart, checkout, and my-account pages from the page cache. Failing to do either of these opens the door to the session contamination issues described above.

When to Contact Support

If you have cleared all caches, reviewed your plugin exclusion settings, checked your Cloudflare rules, and tested for plugin conflicts, and visitors are still seeing different content, the issue may require server-level investigation. Some hosting environments have caching configured at a level that is not accessible from within WordPress or cPanel, and adjusting those settings requires direct server access.

Open a support ticket from your client area and describe what you have already tried, which pages are affected, and what the difference in content is. If you can include a screenshot of the page as seen while logged out alongside what it should look like, that speeds up the diagnosis considerably. Our team can inspect the server cache configuration, review the HTTP headers being served to visitors, and identify which layer is responsible for the inconsistency.