I found this one by accident, in an incognito tab, looking for something else entirely.
The main nav menu on one of my own sites wasn’t showing dropdowns. Just the top-level links — Shop, About, Contact — with nothing underneath them. No error message. No broken layout. No red flag that says “something is wrong here.” Just a menu that looked slightly less finished than it should have, the kind of thing you could scroll past and not clock as a bug at all.
That’s what makes this one worth writing up. It wasn’t loud. It wasn’t a 500 error or a blank page. It was a feature quietly not working, on a site that otherwise looked completely fine — and that gap between “looks fine” and “is fine” is exactly the kind of thing that’s easy to miss on your own site, because you’re almost never looking at it the way a stranger does.
The false leads
First instinct: JS optimization settings. On a stack running LiteSpeed Cache, that’s the reflexive first suspect, and for good reason — I’d already run into one real bug there, where an exclude string meant to protect jQuery from being deferred or combined didn’t actually match the file it was supposed to protect, because of a partial-string mismatch. jquery.min.js as an exclude pattern doesn’t catch jquery-migrate.min.js — they’re different strings, and the optimizer treated them differently. That was a real, previously-solved bug on this exact stack, which is exactly why it was the first place I looked this time. Wrong lead, but not an unreasonable one.
Ruled it out. The optimization settings weren’t touching this.
Next: plugin conflicts, generally. Something stepping on something else — a common enough failure mode on a WordPress site with more than a couple of active plugins that it’s always worth a look. Deactivated things one at a time, checked the nav each time. Nothing changed. Also not it.
Two reasonable guesses, two dead ends. Worth saying plainly: neither of those checks was wasted time. They’re the correct first moves on this kind of symptom. They just weren’t the answer here.
The actual moment
What finally cracked it wasn’t a tool. It was view source — the plain, unglamorous “show me the actual HTML” option every browser has had for decades.
I was looking for one specific thing: was jQuery actually present on the page at all. Scrolled through the raw source looking for the script tag. Found it — but sitting on that script tag was an attribute referencing consent. Not a broken tag, not a missing file. A script tag that had been deliberately modified to not execute until something else happened.
It was small. Almost anticlimactic, honestly — no dramatic error, no stack trace pointing a finger. Just one attribute, sitting where it shouldn’t have been, quietly changing when a critical script was allowed to run.
The actual cause
The site runs a cookie-consent plugin, and that plugin was gating jQuery behind consent. Practically, that means the script tag for jQuery was rewritten so it wouldn’t execute until a visitor clicked “accept” on the cookie banner.
For a returning visitor with a saved “accepted” cookie already sitting in their browser, none of this is visible. jQuery loads immediately, the banner might not even show up again, and everything behaves exactly as it should — because from that browser’s point of view, consent was already given before the page ever loaded.
For anyone without that cookie — a genuinely new visitor, or anyone in an incognito window, which is functionally a new visitor every single time — the page loads in a pre-consent state. jQuery doesn’t fire. And once jQuery doesn’t fire, everything on the site depending on it silently stops working too: the nav dropdowns, and — once I went looking more broadly — the product image carousels on shop pages. No crash. No visible error. Just interactive elements that quietly do nothing, on a page that otherwise renders looking completely normal.
That’s the trap in this specific bug. It doesn’t announce itself. It degrades gracefully enough that the page still looks like a page — it just doesn’t work like one, and only for the exact category of visitor you, the site owner, almost never are: someone loading your site for the first time, with no accepted cookies, no logged-in session, no browser history that’s already told the site who they are.
The fix
Reconfigured the consent plugin so it no longer gates jQuery — jQuery now loads unconditionally, regardless of consent state, the way it would on a site with no consent management at all. Rebuilt the CSS/JS pipeline to make sure nothing cached was still serving the old gated version. Flushed every layer of cache — plugin-level, server-level — to make sure old visitors weren’t still getting the broken script tag from a cached page.
That’s it. No plugin swap, no rebuild of the consent flow, no clever workaround. Once the actual mechanism was identified, the fix was small. Finding it was the entire job.
What I know, and what I don’t
Here’s where I want to be careful, because it would be easy to round this up into a bigger story than the data actually supports right now.
What I know for certain: for at least several days, any visitor without an existing accepted-cookie session — meaning any genuinely new visitor to the site — hit a nav menu with no working dropdowns and product pages with non-functional image carousels. That’s a real, confirmed cost, and it’s bad on its own terms independent of anything to do with search.
What I don’t have yet is Search Console data confirming that Googlebot specifically crawled the site in the same broken state. Here’s the reasoning, stated as reasoning and not as a result: Googlebot doesn’t accept cookies. It crawls without a consent session, the same way a first-time incognito visitor does. So it’s reasonable to expect it encountered the same gated jQuery and the same non-functional elements a new human visitor did. But reasonable expectation isn’t confirmed data, and I don’t have the crawl-specific evidence in hand yet to say definitively that this was affecting how Google was rendering or indexing the site.
If that data shows up — a Search Console pattern that lines up with the timeline of this bug — I’ll write the follow-up with the actual numbers. Until then, this is a diagnostic-and-fix story, not a proof-of-impact story, and I’d rather tell you that directly than imply a result I can’t back up yet.
The generalizable version
The specific plugin doesn’t matter much. The pattern does: any plugin that conditionally loads a script based on something a visitor has to do first — accept a cookie, log in, complete an A/B test bucket assignment, trigger a lazy-load scroll event — can produce a site that behaves one way for you and a different way for a first-time visitor. And you are, almost by definition, the worst-positioned person to catch it, because your own browser is full of the cookies, sessions, and history that make the broken version invisible.
If you want to check your own site for this: open it in an incognito window, view source, and look for whether your core scripts — the ones your interactive elements actually depend on — are present in the HTML before you’ve clicked anything at all. If a script tag has a consent, lazy-load, or interaction-gated attribute sitting on something load-bearing, you may be shipping two different sites without knowing it — one for you, and one for everyone else.
