If you’re copy-pasting ad code across multiple domains and accounts, double-check which AdSense account actually owns the ad unit. Yes, even if it worked last year.
I found out the hard way that expired domains tied to an old, barely-used publisher ID can still serve impressions in the preview tool — but try loading that ad on a real page? Nothing. Just whitespace.
Google doesn’t broadcast this: ad units from disabled, closed, or dormant accounts might behave like they are live in published HTML… but silently return zero inventory.
No warnings in the Chrome console. Nothing in the account alerts. Just zero fill and a confusing number of pageviews in Analytics with zero RPM in AdSense.
Fix: generate new ad units inside the correct live account and dump the leftovers. Don’t merge logic across accounts. Really.
Cross-check your ad client IDs (ca-pub-XXXXXXXXX). If the ad code you’re using isn’t from the primary account tied to the site’s site verification — that’s probably your problem.
The Site Isn’t Verified in That Account
Different Google products don’t share authorization states cleanly. Just because Search Console is happy doesn’t mean AdSense is.
Verifying a domain for crawling isn’t the same thing as verifying it for ad serving. Yes, it’s the same HTML file. No, the privileges are not transferable.
There’s a gray area where pages on a verified site load ads, but then those impressions go “limited” or unmonetized until site verification fully approves it. This phase can last days—or weeks. It’s not consistent, especially for newer TLDs.
If you slap AdSense on a domain before approval finalizes, the ad slots will either fail quietly or sometimes show low-end inventory as a weird consolation prize. No alerts. No email from Google. Just absence.
I once waited 10 days for a .blog domain to actually transmit monetizable impressions, even though Search Console gave it the green light in under 12 hours.
Ad Blockers or Extension Behavior is Breaking Things
Obvious? Sure. But it’s weirder than it looks. uBlock Origin sometimes doesn’t just hide ads — it mutates the DOM tree so deferred JS tags don’t fire at all. That means test pages can totally mislead you.
I once wasted an evening thinking I had misconfigured my ad slots when it was actually Firefox’s Enhanced Tracking Protection steamrolling the lazy-load observer script.
Preview mode in Chrome (Cmd+Shift+P → “Render blocking ads”) doesn’t reflect what a user with any shield plugin enabled will see. Run incognito tests. Better yet — fresh portable browser profiles.
Browser plugins like Privacy Badger or Ghostery can get smarter over time and start ghost-muting ad scripts that previously broke through. Cached rules matter more than you think.
The kicker? Sometimes extensions block ads based on your classNames, not just scripts. If you copied a div from Reddit and reused their class like _3x-0C or something, welcome to stealth blocking hell.
Auto Ads Are Set to Page-Level Below-the-Fold
If you rely on Google’s Auto ads, double-check where it thinks your placements belong. Their JavaScript will sometimes defer all ad injection to way beneath the first screen — particularly if your above-the-fold layout is too dense.
You can kinda discover this by watching network requests and scroll-triggered loads. But it’s clunky. Their “Preview” page in AdSense is more distraction than tool.
I once found a homepage where Google decided auto ads should show only three-quarters of the way down the page… under a widget nobody clicked. Real impressions, near-zero CTR.
No setting in the dashboard clearly controls this. You just toggle Auto Ads “on” and Google shrugs based on ML guesses tied to your HTML layout patterns. If the ML says your above-the-fold looks like a carousel or interactive header — good luck getting anything injected there.
Manual ad unit injection is the only way I know to avoid Auto ad surprises. And even then, don’t forget to test on phones specifically. Injection priority varies wildly between mobile and desktop.
You Hit a New Domain Limit Without Knowing It
There’s a semi-secret limit on how many new domains you can submit in a short time, especially for smaller accounts with limited history. It’s not documented. But it absolutely exists.
Once added three subdomains in the same week? Expect the latest one to get stuck in approval limbo like it fell into a bureaucratic sinkhole.
You’ll still see the “Ready” status. But behind the scenes, Google throttles review prioritization based on your account’s perceived scale and reach.
One quote from support (yes, I actually got a reply after a week):
“Review times may be impacted by account activity and cumulative requests. We appreciate your patience.”
This makes it feel like a spam trigger — too many domains too fast flags you for low-trust, even if your earnings are steady.
If you’re testing new microsites or minisites for niche traffic, stagger your AdSense submissions or expect some of them to stall silently forever.
Content Type Is Casually Censored by Category Match
Not all “allowed” content is actually monetizable. You’re allowed to publish certain stuff (like niche health info) — but AdSense can follow up by marking that URL as category-restricted or advertiser-unfriendly.
The content doesn’t trip a hard policy violation, so no obvious penalty. But you’ll get near-zero CPM inventory, and most of it will be PSA fillers or house ads.
I once published an article about non-invasive autism diagnosis tools and it tanked the RPM site-wide for 48 hours. Why? Google associated the page with sensitive health queries. No misinfo. Just wrong topic → wrong ad vertical → near-empty fill.
You can kind of catch this using “Ad review center” inside your AdSense dashboard (filter by landing page), but the insights are shallow.
The fastest way to prove it: paste that page URL into the “URL checker” inside Google Ad Manager with test mode. Bet you a coffee you get a tiny column of categories and nearly all are blocked by default.
Cloudflare Rocket Loader or Other Optimizers Are Crashing Load Order
Yes, even if they “worked fine for months.”
Cloudflare’s Rocket Loader optimizes script loading by deferring and re-ordering JS. This breaks the ad init chain for many async ad scripts — especially if you load additional logic after the default AdSense tag.
Symptoms: you’ll see the adsbygoogle.push({}) call, but it’ll throw a silent error since the object it’s trying to push into doesn’t exist yet. Classic race condition.
Weird part? Sometimes the ads load anyway in dev mode. You deploy to production… and boom, silence. It behaves like a cache issue but it’s really an execution order crash.
You’ll need to explicitly exclude Google AdSense scripts from Rocket Loader. Add a data-cfasync="false" to your ad script tag. Not optional.
Minifiers like Autoptimize or asset combiners in WP plugins also cause this intermittently. Not all JS is safely combinable, especially the inline adsbygoogle structures.
If you can’t isolate it, throw the browser into “Slow 3G” emulation and reload. It reveals load-order dependencies better than watching in normal speed.
Ads.txt Confusion or CDNs Caching an Older Version
If you’ve updated your ads.txt recently and ads still aren’t showing — yeah, it’s probably a CDN cache somewhere. Cloudflare, Netlify, or your theme’s static cache module are very good at not telling you they’re serving stale txt files.
I had a client with a headless front-end and their static hosting layer was caching ads.txt for over a week despite it being marked as no-cache. The propagation delay made it look like AdSense was broken, but it was just stale file delivery.
Use curl to grab the ads.txt file directly from edge servers. Or a tool like web-sniffer.net to bypass cache layers.
Also—don’t put redirects on ads.txt. Some devs route /ads.txt to a CMS-rendered dynamic version. Bad idea. Googlebot wants a 200 response, not a 301 chain through a route handler.
And one funtypo warning: I spent 15 minutes once trying to debug why no ads were showing and yep — the file was named ad.txt. No –s. Rage clicked the browser bar more than once that night.
