Debug Google AdSense in Chrome DevTools

What Google AdSense traffic looks like

AdSense starts with a loader script carrying the publisher ID; the actual ad requests go to Google's ad-serving infrastructure downstream.

Endpoint pattern

pagead2.googlesyndication.com/pagead/js/adsbygoogle.js, normally with a ?client=ca-pub-XXXXXXXXXXXXXXXX query parameter; legacy setups load show_ads.js from the same host. Downstream ad requests go to googleads.g.doubleclick.net/pagead/ads but are attributed to Google's ad-serving platforms. The AdSense detection keys on the two loader scripts

Transport

Script loads; on the page, each ad slot is an <ins class="adsbygoogle"> element pushed via (adsbygoogle = window.adsbygoogle || []).push({})

Key parameters

client: the ca-pub- publisher ID, the first thing to verify in any AdSense debugging session · per-slot parameters and the page URL travel on the downstream ad requests

Consent signals

Under GDPR the ad requests carry gdpr= and gdpr_consent= TCF parameters; non-personalized ad configurations add signals like npa=1

Debugging AdSense with Event Watcher

• Detects the adsbygoogle.js and show_ads.js loads and labels them as Google AdSense with the ad-tech category badge.
• No dedicated parser: the raw request view's parsed query parameters give you the client publisher ID directly, plus the cookies sent and the consent verdict.
• The Script Tree view shows what loaded the AdSense script: site code, GTM, or a consent platform's script blocker.
• The downstream doubleclick ad requests appear as their own events in the same stream, so you can follow loader then ad request in order.

AdSense and consent

Event Watcher checks AdSense against marketing consent.

AdSense participates in Google Consent Mode: with ad_storage denied, Google can still serve non-personalized, cookieless ads, so the loader firing before a consent choice is expected in a correctly configured Consent Mode setup.

What matters is whether the pre-consent ad requests are actually cookieless and carry denied signals. Compare them against the Consent Mode state the extension reads; the Consent Mode v2 debugging guide walks through interpreting those signals.

A hard-blocking (non-Consent-Mode) setup instead requires that the loader not fire until marketing consent is granted. Pre-consent loads there are genuine findings.

Common debugging scenarios

• Ads not serving. Confirm the adsbygoogle.js load actually happened and that its client parameter matches the AdSense account. A wrong or missing ca-pub- ID fails silently.
• Loader fires before consent. Decide first which model the site runs: Consent Mode (expected: verify denied signals on ad requests) or hard blocking (a violation: the pre-consent badge is your evidence).
• Double loader. Grouped by Endpoint reveals adsbygoogle.js loading twice, common when both a CMS plugin and a hardcoded tag exist; Script Tree names both initiators.
• AdSense vs other Google ad tags. The stream separates the AdSense loader from other Google ad-serving requests, useful when a site mixes AdSense with Ad Manager and you need to know which product requested an ad.
• Consent string sanity check. Inspect gdpr_consent= on downstream ad requests to confirm the CMP's TCF string is actually reaching Google.