If your click-through rate nosedived right after you dropped in a cookie consent banner, yeah — me too. I was using that default IAB TCF 2.0-consent popup from a privacy plugin, and apparently it blocked AdSense from running until the user accepted everything — including, I later learned, just loading the ad iframe at all. Like, zero requests went out. Nothing to click = CTR = toast.
Chrome dev tools showed the GPT script not being injected, and I was pulling my hair out thinking AdSense rejected my account or something. Turned out the CMP (cookie management platform) I installed wasn’t calling the right stub for ad personalization approval. It never even handed off consent to AdSense, so AdSense stayed in pre-init limbo.
The fix was half-hidden in GitHub issues (“add customEventListener for GoogleConsentCallback”) and buried in the TCF 2.0 API spec. Fun stuff. Once I patched in a conditional init for ads based on the proper string value, CTR recovered the next day — not to previous levels, but close.
Dead zones from auto ads stacking below the fold
You know when Google’s Auto Ads picks weird spots like five scrolls down, right before the comments section where no one ever goes? I discovered those dead zones account for a non-trivial portion of ad impressions that never, ever have a chance to get clicked. So your CTR metric looks worse, even though user intent didn’t change at all.
The AdSense dashboard doesn’t flag this — you’ll just see lower CTR week over week and start blaming traffic sources. I only caught it after throwing in IntersectionObserver wrappers and realizing how many placements had zero viewport entries even after 5 minutes logged-in testing.
This happens way more often on themes that aggressively lazy-load content sections (like ghost buttons that expand comments, accordion wrappers, etc.). You can tweak the Anchor Ads settings in your Auto Ads control panel, but honestly, that thing speaks in vague riddles. I had better luck disabling Auto Ads entirely for desktop and placing a few experimental display blocks manually where eyes actually land.
Responsive ad units collapse on mobile under 360px
One of the dumbest bugs I’ve fought: On super-narrow Android devices (think WebView embedded browsers inside apps), the responsive display ad code just collapses to 0px height. Not hidden, not broken, just phantom DOM shadows. And since AdSense logs don’t treat those as failed impressions, you get ghost views bloating your RPM numbers.
I traced this back to the default container styles plus the data-ad-format="auto" not resolving a width. If the viewport goes below 360px, AdSense sometimes can’t decide an ad format. That causes a height of 0 to be assigned.
What finally made it behave for me: wrapping the ad container in a div with an explicit min-width AND max-width (for fun) and giving the container a non-zero min-height. Something like this:
If you ever see mobile traffic spikes without clicks jumping as expected, check in a tiny browser window — you might be testing a blank ghost.
CTR tanking during Cloudflare optimization rollouts
Cloudflare’s Auto Minify and Rocket Loader are basically coin flips if you’re running inline AdSense snippets. In 2022, I turned on both across a multi-post Blogger setup and noticed that CTR melted overnight. Impressions stayed flat, but almost zero interaction.
Turns out Rocket Loader juggled the loading order just enough to put the ad script tag behind other less important components. Sometimes it wouldn’t fire until several seconds after user interaction — and if the user left in those first few seconds, ad load never completed at all.
After a few experiments, I started using the page rules:
Disable Rocket Loader on only /post/* URLs
Manually whitelist the GPT script using data-cfasync=false
Disable Minify for JS only (but leave CSS/HTML on)
Yes, it’s a performance trade-off, but the CTR went from subhuman back into normal range within 8 hours — I think crawling or whatever retro-indexed the changes fast.
Click-through seems to improve with nonsensical ad sizes
One of my oldest mistakes was assuming Google’s “recommended” sizes are optimal. I blindly used the 728×90 leaderboard or 300×250 MPU formats in the exact spots recommended. CTR was fine, but never popped.
Then I ran an experiment using 234×60 or random 160×600 skyscrapers on highly text-dense pages. Shockingly, those off-size ads started outperforming the recommended ones. No one talks about how ad fatigue kicks in when your layout absolutely screams, “This is the same ad you saw on ten other blogs.”
I think the surprise element messes with banner blindness. And for mobile, those ultra-narrow verticals don’t block reading flow as much — people scroll slower, maybe click more?
If you’re not A/B-ing size combinations against your real traffic segments, you’re assuming Google’s heuristic works well with your specific reader pattern… and unless you’re TechCrunch, it probably doesn’t.
Gremlins when mixing Alike Ads and Display Units
Alike Ads look cool until they start cloning themselves just beneath an existing Display Ad. I had three divs — one native-style link unit, one regular 300×250, and the newish Alike format. The page rendered fine in dev tools but on production, multiple users reported seeing the ad area repeat five times, sometimes overlapping text. CTR dropped massively that week, because users just scrolled away like it was broken spam.
The cause wasn’t documented anywhere, but I found an offhand comment in a forum suggesting that multiple formats running on the same publisher slot (especially within the same viewport zone) can conflict under auction pressure. Like if Google can’t decide who gets the space “soon enough,” it’ll flash multiple fillers before clearing them.
What tipped me off: the console sometimes logged “auction timeout fallback: native_ad_rid: undefined” — that tiny string led me down a two-day rabbit hole until I separated the layouts into different viewport-delay events and forced stagger-loaded ad init with a lazy loader script.
Not worth mixing those again unless I can wrap them properly in totally separate flexbox columns.
The AMP trap: high mobile views, terrible CTR
I used AMP on a few old article pages as a test. And yes, AMP will bump your mobile traffic. But CTR? Agonizingly low.
The issue isn’t just format. It’s timing. AMP ad units don’t always load until the content settles, and the prioritized layout shoves some ads so far down they never get interaction. More than that — the default AMP ad layout is brutally hostile to engagement. You get bizarre spacing, fixed sizes, and not a lot of UX love.
A fellow dev once sent me their AMP CTR graph and it honestly looked like a heartbeat monitor from someone passing out. We both ripped AMP out entirely the next week. Classic responsive pages outperformed even when slower.
Also: you can’t run all ad types in AMP. Native ad styles especially are limited or buggy — the CTA links won’t always fire if the iframe sandbox doesn’t resolve properly, and that’s not something you can debug unless you’re monitoring remote console logs from production devices. Which I wasn’t. Until I did… for this.
AdSense experimenting on your layout silently
Yes, they do. If you opt into “Optimize your ad layouts” under Auto Ads, Google treats your page like a sandbox. I had one post start rendering sidebar overlays — overlays I never coded — and then next day they vanished. CTR was briefly up, then cratered.
No record of it in logs, no version control diff, nothing. Turns out, the experimental layout engine just quietly flips between layout strategies without exposing what it’s testing. I only saw it because my reader emailed me a screenshot saying, “Why is half your article greyed out under this floating broom ad?”
Disabling Auto Optimization entirely made CTR more stable. If you’re not tracking conversions per format manually, it’s a crapshoot. They won’t tell you what format worked unless you manually break down ad unit groups and correlate them to UI behaviors. Which, yeah, I’m not doing for 200 posts.
