Bypass StackPath CDN Cache for Logged-In WordPress Users

You log into WordPress, publish a quick post fix, visit your homepage, and you’re staring at stale HTML from four hours ago without an admin bar in sight. When you run full-page caching at the edge on StackPath, the CDN doesn’t give a damn that you’re an administrator. To the edge node, every incoming GET request looks identical unless you configure it to inspect the Cookie header.

Leaving full-page edge caching running without logged-in bypasses breaks your site in two bad ways. First, editors can’t see draft updates, pending revisions, or the admin bar. Second—and much worse—if your origin ever spits out personalized session markup while the edge is listening, StackPath can cache that response and serve your admin toolbar or someone else’s WooCommerce cart to thousands of random visitors. Let’s wire this up properly using StackPath EdgeRules and origin headers.

Why WordPress Logged-In Users Break on Edge Caching

StackPath sits as a reverse proxy in front of your origin (usually Apache or Nginx). When someone hits /my-post/, StackPath hashes the URL and host header to create a cache key.

Out of the box, that cache key ignores cookies. An anonymous reader from Frankfurt and an administrator logged in from Chicago generate the exact same cache key. If the CDN already holds a fresh copy in edge memory, it answers with an HTTP 200 immediately. Your origin PHP process never even wakes up.

WordPress core tracks logged-in sessions via authentication cookies containing encrypted user hashes. If we want logged-in users to actually see their changes, we have to force StackPath to inspect those cookie headers on every incoming request. If an auth cookie shows up, the edge must stand down and pass the request untouched straight back to origin.

Identify the Exact WordPress Auth Cookies

You don’t need to match every cookie on your domain. Marketing tags, cookie consent scripts, and Google Analytics leave cookies everywhere, and none of those should bust the edge cache. We only care about the cookies WordPress uses for authentication, comment state, and sessions.

The official WordPress Cookie documentation lays out these naming conventions:

• wordpress_logged_in_*: The primary auth cookie dropped right after successful login. The trailing string is a hash unique to your installation.
• wordpress_sec_*: The session cookie used for SSL-secured sessions.
• comment_author_*: Created when a guest leaves a comment so WordPress can pre-populate their name and email on their next visit.
• woocommerce_items_in_cart & woocommerce_cart_hash: Essential for stores; these flag active shopping sessions.
• wp-postpass_*: Set when someone enters a password for a protected post.

For standard blogs and publishing sites, matching wordpress_logged_in_ handles 99% of your problems. That single prefix matches subscribers, authors, editors, and admins alike.

Configure EdgeRules in StackPath to Bypass Cache

StackPath uses EdgeRules to rewrite routing logic right on the edge nodes. You can roll this rule out across their global network in about two minutes from the portal.

1. Sign in to your StackPath console and pick your Site (CDN delivery).
2. Head to EdgeRules in the left-hand menu.
3. Click Add EdgeRule.
4. Set the rule name to: Bypass Cache for Logged-In Users.

Under the If… section, set up your condition:

• Condition: Request Cookie.
• Operator: Contains (or Matches Regex).
• Value: wordpress_logged_in_.

If you also want comment authors and password-protected posts to bypass edge caching, click the OR operator to add extra checks:

• OR Request Cookie contains comment_author_
• OR Request Cookie contains wp-postpass_
• OR Request Cookie contains woocommerce_items_in_cart

Now, define the response behavior under the Then… section:

• Action: CDN Cache Settings.
• Cache Expiration: Bypass Cache (or toggle CDN Caching to Disabled).

Hit save. EdgeRules usually propagate across StackPath PoPs in 30 to 60 seconds.

Add Fallback Cache-Control Headers in .htaccess or Nginx

I never rely solely on CDN edge rules. If an edge rule gets accidentally toggled off during an audit, your origin server needs its own defensive headers telling downstream caches to back off. We wrote a deep dive on this approach in our guide on how to configure Cache-Control headers in WordPress .htaccess for CDN caching.

WordPress natively sends Cache-Control: no-cache, must-revalidate, max-age=0 on admin screens, but custom page templates and REST calls can slip through the cracks. Setting explicit response headers at the web server layer fixes that.

For Apache or LiteSpeed (.htaccess)

Drop this near the top of your .htaccess file, right above the standard WordPress rewrite block:

 # Detect WordPress login cookie and tell CDN to pass through SetEnvIf Cookie "wordpress_logged_in_" IS_LOGGED_IN Header set Cache-Control "private, no-cache, no-store, must-revalidate" env=IS_LOGGED_IN Header set Pragma "no-cache" env=IS_LOGGED_IN Header set Expires "0" env=IS_LOGGED_IN

This snippet looks at the incoming Cookie header. If wordpress_logged_in_ shows up, Apache sets the IS_LOGGED_IN environment variable and rewrites the downstream Cache-Control header to private. StackPath adheres to MDN Cache-Control specifications, meaning it won’t store responses flagged as private or no-store.

For Nginx

If your origin runs on Nginx, drop this mapping and header logic directly into your server block:

# Define cookie bypass variable
set $skip_cache 0; if ($http_cookie ~* "wordpress_logged_in_|comment_author_|woocommerce_items_in_cart") { set $skip_cache 1;
} location ~ .php$ { # Standard fastcgi setup... fastcgi_pass unix:/run/php/php8.2-fpm.sock; # Send cache bypass header if authenticated if ($skip_cache = 1) { add_header Cache-Control "private, no-cache, no-store, must-revalidate"; }
}

Protect wp-admin and wp-login.php Paths

Never let the CDN touch /wp-admin/ or wp-login.php, even for anonymous visitors who don’t carry cookies yet. Caching the login form can serve expired security nonces to real users, locking them in an endless login loop.

Create a dedicated EdgeRule just for admin paths:

1. Click Add EdgeRule.
2. Name: Bypass Admin and Login URLs.
3. If: URL Path matches regex ^/(wp-admin|wp-login.php).
4. Then: CDN Cache Settings → Bypass Cache.

Make sure this rule sits near the top of your EdgeRules list. StackPath processes rules top to bottom. If you have a generic site-wide rule higher up enforcing a 24-hour cache on all paths, it will run before this bypass rule unless you reorder them.

If you’re worried about un-cached staff traffic bogging down your host, check our guide on how to configure Origin Shield in StackPath CDN to reduce origin server load.

Test the Bypass Rule with cURL and DevTools

Don’t test this inside your everyday desktop browser. Chrome and Firefox will cache HTML in their internal memory and disk buffers, making you think the CDN is misbehaving when it’s actually your local browser lying to you. Use curl to inspect raw edge response headers.

Start by testing an anonymous visitor request:

curl -I https://example.com/sample-post/

Look at the headers. By the second run, you should get a confirmed edge hit:

HTTP/2 200
date: Thu, 23 Oct 2024 14:10:02 GMT
content-type: text/html; charset=UTF-8
x-cache: HIT
x-hw: 1698070202.d002.am2.t,1698070202.c001.am2.H
cache-control: public, max-age=86400

Now, simulate an authenticated WordPress session by passing a mock wordpress_logged_in_ cookie:

curl -I -H "Cookie: wordpress_logged_in_abc123hash=adminuser" https://example.com/sample-post/

Here’s what a successful bypass looks like:

HTTP/2 200
date: Thu, 23 Oct 2024 14:10:15 GMT
content-type: text/html; charset=UTF-8
x-cache: BYPASS
cache-control: private, no-cache, no-store, must-revalidate

Two critical markers here: x-cache: BYPASS (or MISS depending on your StackPath setup) and the cache-control: private header coming from the origin. If you pass that cookie and still get an x-cache: HIT, double-check your EdgeRule regex spelling or verify that another rule isn’t overriding it higher in the stack.

Gotcha: Cookie Stripping and Query Strings That Break the Rule

When I first pushed this configuration on a staging environment with active editors, they called me ten minutes later complaining that post previews were broken. WordPress preview links look like https://example.com/?p=1234&preview=true.

Two common edge settings usually cause this:

1. Aggressive Query String Stripping

CDNs love stripping query strings to raise their cache hit ratio. If you configured StackPath to strip query parameters before checking rules, the edge won’t pass preview=true back to WordPress. Make sure query arguments remain intact so WordPress can load auto-drafts from the database rather than your published version.

2. Asset Optimization Plugins Stripping Cookies

Some WordPress optimization plugins attempt to strip cookie headers on static assets. If you followed our tutorial to strip Set-Cookie headers for static assets in StackPath, make sure you constrained that rule strictly to static extensions (like .js$, .css$, .webp$).

If you accidentally write a broad rule that strips incoming Cookie headers on root HTML documents (/ or /*.php), the CDN will drop your wordpress_logged_in_ cookie before the bypass rule evaluates it. StackPath will treat you like an anonymous visitor every single time.

Handling WooCommerce Cart and Checkout Exceptions

WooCommerce introduces a separate headache. A shopper adding items to their cart isn’t logged in, but you can’t show them edge-cached HTML or their mini-cart total and checkout page will stay empty.

WooCommerce drops these cookies the moment a visitor adds an item:

• woocommerce_items_in_cart: Set to ‘1’ when the cart has items.
• woocommerce_cart_hash: A unique fingerprint of the cart contents.

Here is the EdgeRule pattern you need for WooCommerce:

# StackPath EdgeRule Logic
IF: Request Cookie CONTAINS "woocommerce_items_in_cart"
OR: Request Cookie CONTAINS "woocommerce_cart_hash"
OR: URL Path MATCHES REGEX "^/(cart|checkout|my-account)"
THEN: CDN Cache Settings -> Bypass Cache

This allows casual window shoppers to browse super-fast cached product pages. The moment someone clicks “Add to Cart,” the cookie drops, StackPath bypasses cache on subsequent views, and their dynamic cart state remains intact.

Frequently Asked Questions

Does bypassing the cache for logged-in users slow down the site for regular visitors?

No. Public visitors never send WordPress auth cookies. Their requests bypass this rule completely and continue hitting StackPath’s memory cache in 20-30ms. Only authenticated users bypass cache to hit PHP.

Can I use Wildcard (*) in StackPath EdgeRule cookie checks?

Yes. If you choose Matches Regex, use wordpress_logged_in_.*. If you pick the Contains operator, just write wordpress_logged_in_ without wildcards. The “Contains” operator automatically matches any cookie that includes that substring.

Why does my WordPress toolbar still disappear after logging in?

Check your origin for a local caching plugin (WP Rocket, LiteSpeed Cache, WP Super Cache). If your origin server caches full HTML pages on disk and serves them indiscriminately, StackPath will bypass its own cache, grab that stale page from your origin disk cache, and serve it to you anyway. You need to configure your origin plugin to bypass logged-in users too.

Should I bypass the CDN cache for all cookies?

Definitely not. Google Analytics (_ga), Cloudflare identifiers, and GDPR consent plugins set cookies for every single visitor. If you tell StackPath to bypass on any cookie, your cache hit ratio will hit zero immediately, turning your CDN into an expensive pass-through proxy.

Where to Go from Here

Once your cURL tests confirm that logged-in requests bypass cache while public readers pull from edge memory, take a close look at your DNS records. If you haven’t cleanly linked your host to StackPath yet, check out our walkthrough on how to connect Namecheap DNS to StackPath CDN with Hostinger origin to keep DNS resolution just as lean as your cache layer.