I had just deployed a CSS fix for a client's custom theme, then refreshed the homepage. Clean. The layout sat where it should, the spacing was right, everything matched the mockup. I typed "fixed, it's live" in chat, closed the laptop, done. Five minutes later the reply came back: "still broken on my end." I reopened it — still fine for me. They sent a screenshot, and sure enough it was broken exactly as it had been before I touched anything. No error string, no red line in the console. Just two people looking at the same URL and seeing two different pages.
What made me stop was that there was no stack trace to chase. So I reached for the cheapest trick first — open an incognito tab, paste the exact same URL.
# My normal tab (logged into wp-admin): clean
# Incognito tab (no cookies): broken, identical to the client's screenshotThere it was. In incognito, the page was broken. I had spent an hour verifying the wrong render.
Why this happens
This site runs WP Rocket, and this is the default behavior of nearly every full-page cache plugin: they skip the page cache for logged-in users. The reasoning is sound — if you're logged in, you might be an admin or editor who needs to see draft content, fresh nonces, or the wp-admin toolbar. Serving stale, pre-baked HTML to someone like that would be the wrong call. So when I, logged in, requested the homepage, WP Rocket quietly stepped aside and WordPress rendered the page from scratch, straight from PHP, with my latest CSS.
A logged-out visitor gets a completely different path: the static, cached HTML, which still held the old CSS from before my deploy. That cache had not been busted for the public path. Two render paths, one URL.
There's another layer that widens the gap. WP Rocket has a Remove Unused CSS feature, and that is also skipped for logged-in users. So my admin view got the full stylesheet while the public got a trimmed-down version — which, if a critical rule got trimmed, can look different even when the cache is fresh. On top of that, the admin bar injects a margin-top onto <html> and sometimes other small offsets, so even the vertical positioning is never quite identical to what the public sees.
So my admin view: uncached, full CSS, admin-bar offset. The public view: cached, trimmed CSS, no offset. That is not the same page. "Works on my machine" was true — my render literally was different.
The fix
The actual fix was boring: clear the WP Rocket cache so the public path gets rebuilt with my new CSS. But the more important lesson is how you verify, because that is where I slipped.
The first and simplest rule: always verify in an incognito / no-cookie window. Not your usual tab. Not a half-hearted "let me log out" where you forget a few cookies are still stuck. A clean private window with no session.
But often I don't want to log out — I'm in the middle of something in wp-admin. So open the browser console and diff the two renders straight from the same tab:
// Public, cached render (browser still has cookies, but we drop them)
fetch(location.href, { credentials: 'omit' }).then(r => r.text()).then(t => console.log(t.length))
// Your logged-in render (cookies attached)
fetch(location.href, { credentials: 'include' }).then(r => r.text()).then(t => console.log(t.length))If those two HTML bodies differ — different length, different <style> blocks, different markup — you have just proven the cached public path diverges from your logged-in one. That's hard confirmation, not a guess.
If you're at a terminal and want it even cleaner, curl the URL with no auth cookie at all:
# Exactly what an anonymous visitor sees
curl -s https://old-site.com/ | grep -c 'class-i-just-fixed'
# WP Rocket can strip or serve differently for unknown UAs,
# so mimic Googlebot if you suspect UA-based branching
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://old-site.com/With no cookie, you hit the static HTML exactly as the public gets it. If your fix doesn't show up here, it isn't live — whatever your admin tab claims.
The takeaway
The logged-in admin render is not the public render. On any site behind a full-page cache, they are literally two different code paths: one cached and trimmed and anonymous, one fresh and full and logged-in. Verifying the logged-in one and declaring victory is like tasting the batter and calling the cake done.
My rule now is one sentence: before I say something is live, I check the cached, logged-out path — incognito, credentials: 'omit', or a cookieless curl. If it's right there, it's actually live. If it isn't, all I fixed was my own private rendering, and the visitors never got to share it.