So the first thing that made me flinch was seeing a damn AdSense banner at the top of my account dashboard — something about needing to migrate my old legacy account to the new UI. Except… I did that in 2016. Or I thought I did. Turns out, if you ever created multiple property-level AdSense accounts before AdSense went fully site-centric, they didn’t all get wrapped up in that migration flow.
What tipped me off was a delightfully vague message: “Some of your sites may not be fully set up for the new AdSense experience.” No actual sites were affected, mind you. Ads were serving like nothing was wrong. But revenue reporting was patchy under certain site views, and the Experiments tab would throw a 500 if I tried to access rule-based blocking.
The platform logic flaw here? If Google detects AdSense was ever activated on multiple domains using separate logins (or granted access via business managers), they don’t combine OR flag them cleanly. You get a slow collapse of features and some truly confusing side effects. Like one of my old sites showing earnings in both old and new dashboards — with numbers that run a few cents apart.
Migrating an Old Account That Technically Doesn’t Exist
I got curious-slash-anxious and dug into the list of associated sites under my primary AdSense account. Weird part? One site that was monetized in 2013 and delisted in 2017 suddenly showed a warning: Requires manual verification.
Manual what? The domain 301s to another service now. And the old associated email address bounced. Here’s the trick I found (and it felt like borderline dark magic):
Click into Sites → Show inactive → Then hit Request Review, which pops up even if the site isn’t actually listed on your current profile.
I did this half-expecting a support ticket rejection. Instead, two days later that zombie site completely dropped from the legacy table, and the warning banner at the top… vanished. So evidently, it wants you to poke exactly the right buttons for it to do a proper cleanup, even if the site hasn’t been live in half a decade.
Combining Old Hosted Accounts With New Site-Based Ones
This one caused a hard headache when your AdSense legacy account was originally created via YouTube or Blogger. Those used to fall under “Hosted Account” restrictions. The newer site-based system manages domains and subdomains separately from hosted services, but the hierarchy never fully maps out when you migrate.
The fastest way I found to detect this mismatch was by navigating to:
https://www.google.com/adsense/new/sites
Then cross-checking that list with what’s actually set up in
https://www.google.com/adsense/host-pub-XXXXXXXX
If there’s a discrepancy, e.g., YouTube monetization is still active but doesn’t show in your new dashboard, go to your Access and Authorization tab, revoke YouTube API access briefly, and reconnect. Wildly enough, that re-syncs OAuth scopes and can trigger a permission refresh that pulls hosted data into proper display format — without relinking the property manually.
The Reporting Catch: Legacy Earnings Bleed Into Current Reports
Genuine confusion moment: I saw earnings from a domain I hadn’t touched in years show up under “Ad units” in modern AdSense reporting — even though that site was supposedly removed ages ago. Turns out, if you once served ads via a legacy tag (the flat JavaScript variant before Auto Ads), revenue can still reflect internally via the old PubID+channel pairing even if the site’s URL no longer shows up in your configurations.
And the worst part? If you try digging in by date, the legacy structural data doesn’t fully map to modern taxonomy. Things like ad placement, channel, and site don’t act like filters — they act like poorly stitched joins between separate tables. Sometimes the same impression logs twice under different names:
“example.com-TopBanner”
“TopBanner_Legacy”
Another frustrating bit: earnings from these ghost ad units sometimes fail to trigger eCPM floor optimizations, meaning you lose out on bidding logic unless you scrub the entry point manually. Best workaround I’ve found is checking the Ad units tab for anything older than 2018 and deleting them, even if they no longer visibly serve.
“Request Review” Triggers a Hidden Meta Update
This was a surprise: clicking “Request Review” on a dormant site (with no ads currently active) actually triggered a metadata refresh of account structure. Not just for the site, but for the connected domains list and network permission syncs.
I compared the account’s JSON fingerprint before and after using chrome://net-export. There were 11 modified values after the review request response timestamp.
And that helped resolve something I could never explain: why Custom channel targeting wouldn’t work on the newer property I had launched. Once the legacy meta table flipped, the targeting IDs redistributed and the associations finally rendered correctly inside Ad Manager — even though I hadn’t edited them manually.
The Unofficial Method for Unlinking a Frozen Legacy Property
You’re not supposed to be able to unlink an old PubID from AdSense once it’s suspended or frozen — usually this happens if an old hosted site was banned or flagged and the account can’t be modified through normal UI flows.
But there’s a workaround buried in the policy appeals process. Technically you’re appealing a site rejection, but you can use the form to provide metadata that includes the legacy PubID and the hostname or app ID — which forces the internal review system to treat it as an entry registration request.
Example:
Go to the Request site approval form
Enter a new domain (can be placeholder.temp.but.valid)
In the “Additional Information” box, include the old property ID and request unlink
If you’re polite and add something like: “This legacy property is inactive and no longer used. Please remove or decouple for compliance.” — I’ve seen it cleared out silently within 3 days. No confirmation email, just… gone on next dashboard refresh.
What Happens If You Never Migrate?
So this one is weirdly undocumented. You’d think Google would eventually disable all features from unmigrated legacy accounts, right? In practice, if your ad units stayed above page-level requirements and weren’t violating policies, they remain technically active — just capped.
The cap hits in a few subtle ways:
RPM values fall slowly but persistently — not due to traffic, but reduced competition in the auction
Ad blocking patterns increase — modern wrappers allow override logic that’s absent from legacy tags
Experiments and optimizations stop working — old units can’t be included in new workflows anymore
I had one educational site earning reasonable passive income from an old AdSense tag and didn’t bother migrating it until I realized Auto Ads weren’t firing anymore. Turns out the adsbygoogle.js script version it was calling had been deprecated months ago, and Chrome devtools started returning a warning:
Failed to register service: unsupported version.
The kicker: there was no visible impact until I looked at CLS stats — turns out the layout jitter was back because the placeholder sizes in the old ad slots didn’t reserve whitespace. Feels like subtle sabotage, but it’s just silent obsolescence.
Hanging Approval Requests From the Archive Era
Here’s one that drove me nuts. Some older publisher accounts still show pending approval requests for web properties that no longer exist. These don’t cause issues — until you attempt to add a new domain and get the duplicate-application error. Even if the domain is now under your Google Workspace and properly verified.
The behavior seems rooted in backend association rather than UI — G’s internal property tracker will display a ghost entry like:
To flush it, visit https://support.google.com/adsense and file a ticket under Site Verification Issue, but the key is specifying that you’re unable to remove a legacy property due to prior incomplete review. Adding the old request date (even a guess) helps.
I got one cleared retroactively from a blogger domain bought via GoDaddy that wasn’t even in DNS anymore. The support person mentioned that pre-2014 site review requests never expired in the backend unless revoked manually, and the self-service flows don’t hit that status table.
Wacky Duplicate Earnings and VAT Region Confusion
One of my oldest AdSense clients is based in Malta, and we ran into an accounting absurdity: duplicate payout amounts showing in AdSense export reports vs. payments console. It turned out to be a region-based logic bug. The client had migrated three properties, but only re-verified one under the new EU VAT compliance prompt. The others were assumed to be UK-linked by default (what? why?) and taxed differently.
This duplicated the revenue line but showed only one actual transfer. Classic footgun: different VAT logic paths based on which property gets verified first. It’s not documented, and if you try to reassign regional settings after VAT setup, the change stalls unless you flush cookies and permissions, then use incognito to repeat the profile sequence.
Dev console log showed: “user_session.has_fallback_region = true”
Fix ended up being to force logout, revisit the account in a clean browser, and manually assign payout country per property via a nested workflow under Payment Settings > Manage Settings > Payments Profile. But that only showed up once each property had earnings reported within a 30-day span. Before that, the option just didn’t exist in the menu.
