Getting One AdSense Account to Rule a Zoo of Platforms
I had my AdSense account connected to a Blogger site back in the day—one of those throwaway test blogs from 2013 or whenever Google+ was still a thing. Fast forward: I install ads on a self-hosted WordPress site, a random JS-heavy SPA hosted on Netlify, and an old Django app that somehow still makes $20 a month. All trying to feed from the same AdSense account.
The thing is, AdSense sort of assumes everything is either a Google-managed product (like Blogger or YouTube), or it’s under your complete hosting control. There’s no UI flow for stitching that together. You don’t get a dropdown that says, “Link this React app under the domain parked on Vercel to the Blogger-connected profile with your legacy Hosted account ID.”
If you try integrating AdSense on a modern single-page app or a static site that loads content via XHR and doesn’t render server-side, you’ll watch your ad units collapse silently — no error, just empty divs. Meanwhile, the Blogger blog is humming ads like nothing ever changed.
One dirty fix that worked: manually set data-ad-client tags directly into HTML templates instead of relying on dynamic insertion. Seems stupidly obvious, but once you’ve debugged phantom CLS in Lighthouse reports for three hours, everything starts to feel like conspiracy theory.
Fixing the Whitelisted Sites Paradox
Let’s talk about Site Authorization. You go to AdSense settings, hit “Only show ads on sites I’ve added,” thinking you’re locking it down. But then your ads vanish… from your own domain.
The whitelist doesn’t recognize subdomain-wildcards like you expect. site.com won’t include blog.site.com, even though you’d swear there was something in the docs years ago that said otherwise. There isn’t. You have to add them separately. You also need to reverify ownership each time.
Now multiply this by five platforms: Blogger assigns a different site identity than a Netlify custom domain, even if they both point to the same DNS. The Hosted Site is still tied to the old schema (pub-123456789) that can’t always be edited. It’s AdSense’s weird dual-realm model: Hosted vs Non-Hosted. You can technically migrate, but it’s half-documented and if you screw something up, you’ll land in review limbo where no one answers for weeks.
// This got me out of trouble
// Adding individual subdomains manually
siteAuthorization: [
"example.com",
"blog.example.com",
"react.example.com",
"admin.example.com"
],
Why Auto Ads Behave Like Ferrets on Amphetamines
AdSense Auto Ads are pitched like magic. Stick one snippet in <head> and walk away. Except, if you’ve got user-generated templates, theme switching, or partial hydration like Next.js, Light DOM vs Shadow DOM suddenly gates ad rendering. Classic.
Real talk: I once activated Auto Ads on a Vue-based blog where the head content was injected post-render (I know), and AdSense happily injected five ad units inside one container, then tanked my page load by four seconds. Not even joking — one wrapper had nested iframes three levels deep because the script re-ran in each component mount cycle.
In contrast, a raw HTML blog with no build step? Auto Ads worked instantly. Which tells you exactly what Google’s detection scripts are optimized for: flat, boring websites from 2007.
I ended up using manual in-feed units on anything remotely modern, because you can wrap ads in non-breaking layout tricks like:
You retain some layout sanity that way. Auto Ads just do too much in too many unexpected DOM states.
Analytics Glue: Joining Revenue Across Platforms Without Headaches
If you’re trying to get an accurate read of what revenue came from which platform (e.g., Blogger vs Netlify vs Shopify), yeah — it’s not obvious.
Here’s the snag: AdSense reporting groups by site, but the granularity is based on how it detected the origin, which might be based on iframe location, not actual top-level domain. That’s why you’ll see duplicate entries like example.com and www.example.com, and they’ll split your totals.
You can manually clean this in the UI by navigating to the “Sites” report, smashing the “Group by domain” toggle till something sensible appears. But programmatically? You’re gonna have to hit the AdSense Management API, then coalesce based on mapped domains.
“Your earnings from www.example.com and example.com are calculated separately” — buried error from the legacy reporting view.
Normalize all domain variants when saving reports
Group revenue by tracked ad unit ID where possible, not site
Overlay Google Analytics UTM paths manually if all else fails
Log when units render or fail via custom JS — adsbygoogle.push() returns a promise
Avoid domain masking or redirects without updating the AdSense site list
It’s a swamp, but you can extract signal if you stomp hard enough.
Nothing Breaks AdSense More Reliably Than Cloudflare
This one bit me last summer: enabled Cloudflare on all my sites thinking it’d give performance wins. Didn’t think twice. A couple days later, ad revenue dropped like a rock. Auto Ads wouldn’t load, manual units wouldn’t either — just empty wrapper divs.
Turns out Cloudflare started enforcing Rocket Loader by default, which wraps scripts and defers execution. AdSense hates being deferred. And depending on browser and load order, AdSense’s DOM parsing might run before the ad containers exist. But no console errors. You’re just… left with whitespace and vibes.
Disabling Rocket Loader fixed it, but I also learned to:
Use data-cfasync="false" on the adsbygoogle.js script tag
Enable Dev Tools network logging for doubleclick.net fails — a 204 is okay, a 403 means ownership mismatch
Cache-bust JavaScript that includes units (or load inline when possible)
If your ad containers are on dynamic routes that Cloudflare tries to cache too aggressively, expect the occasional layout shift post-load. I now bypass cache on ad-bearing pages entirely. Not worth the flickering mess otherwise.
YouTube and Blogger Live in a Separate AdSense Universe
I don’t know what Google did, but YouTube and Blogger operate inside what I can only call a Medieval AdSense realm. It’s not fully integrated with the rest of your publisher account, like you’re on hosted-tenant-mode.
Revenue from videos and Blogger posts shows up, but you can’t really control targeting, ad types, or even experiment with layout like you can in the main interface. You’re at the mercy of glue logic.
I found out the hard way that removing my Blogger blog from AdSense site list nuked the ad display completely, even though the link setup was done years ago. Apparently the newer platform logic retroactively revalidates ownership for Hosted sites. There was no warning. Ads just stopped appearing one day, no violation message, nothing. It took diving into Google’s Publisher Console to even see ‘No fill’ errors on ad calls.
Don’t try to test your Blogger AdSense setup in incognito windows either. Half the ads will default to PSA (Public Service Announcements) mode if you’re not cookied correctly. Real traffic behaves differently. That was a whole afternoon gone.
Declared Ad Slots with Shadowed Script Calls
Fun bug: if you deploy manual ad units into pages with multiple app shell layers (think: embedded iframes loading their own nested scripts), AdSense’s adsbygoogle.push() sometimes fails silently because it binds onto the wrong document instance.
I crashed into this while trying to load AdSense on a separate rendered chat panel inside my main single-page app. The outer document had the AdSense JS loaded, but the subcomponents requested ads before the lib was even parsed, resulting in: adsbygoogle.push is not a function Error only appeared intermittently.
Eventually found the workaround buried in a forum thread — use setTimeout(() => adsbygoogle.push({}), 0) instead of inline adsbygoogle.push({}) after the script tag. The timeout lets the lib properly attach to window in weird z-order stacks.
Also: AdSense absolutely cannot parse unique ad units inside Shadow DOM. At all. Rip them out or move your container yield to Light DOM. Doesn’t matter what the spec says.
Lesson I Didn’t Know I Signed Up For
Back when I was juggling three partial site migrations during peak Q4 traffic, I cloned an old headless CMS instance onto a new domain and left the same ad unit IDs running. Didn’t think much of it. Within a week I got a policy email: “Ad Traffic Invalid due to duplication.” Apparently, AdSense saw identical layout + ID reuse on multiple domains and flagged it as synthetic.
There’s no documentation that screams: “Don’t reuse ad unit IDs across duplicated layout trees.” But it makes sense in hindsight. Their detection heuristics probably use some kind of DOM hash + UA profile combo. Changed up the IDs, added domain filters, penalties cleared out in two weeks. But again—zero upfront visibility.
