Google Ads tracking that looked fine and recorded nothing: a security header was blocking it

A website's security settings can block Google Analytics and Google Ads tags without any visible sign, and the numbers simply stop. On one client's site, ours did exactly that for about three months, from a rebuild on 2 July to a fix on 1 October. Analytics received no hits, Ads scripts were blocked, and the page looked perfect. We had audited the site eight times in that period with our own audit tool, and it never flagged the problem. The only way to know your tracking works is to test it in a browser.

What a content security policy does

A content security policy is a line sent with every page telling the browser which other addresses the page may load code from and send data to. It is a sensible protection. If a hacker injects a script, the browser will refuse to run it unless it is on the list.

The same rule blocks anything you forgot to list. Google Analytics and Google Ads use several different addresses. A policy that allows one and not the others lets the page load, shows nothing wrong to a visitor, and blocks the data on its way out.

What happened on our sites

We wrote the policy once, based on the scripts a previous version of the site used, and copied it to our other sites. Third-party additions and changes to Google's own addresses then failed quietly.

• An appliance repair site, 2 July to 1 October. The policy did not allow the address that Google Analytics uses when the property is linked to Google Ads, which posts to analytics.google.com and several others. Analytics got zero hits. A script that Google Ads loads from doubleclick.net was blocked as well. The policy also lacked the address of an online booking widget, which showed as an empty box.
• A builder's site. The same Analytics problem. The policy was corrected and deployed on 7 October, and a live mobile visit then showed no Google-address violations.
• An events site, 6 October. This one had no Ads link, and the page-view event reached Analytics normally. But scroll and engagement events go to a different Google address, and those were blocked. A four-second look at the home page showed no violations. Only a test that scrolled the pages exposed it.

We also found, on 12 October, that our own site's policy blocks Cloudflare's web analytics beacon on every page. It was left as it was for now, because the work we were doing that day was scoped to a different tool. We mention it because it is the same fault on a site we run ourselves.

On the booking widget: it turned out to have been retired and the contact form was the only live booking path, so the empty box did not cost bookings. We had first treated it as lost revenue, and that was wrong. Ask which booking path is live before you fix one.

Why the checks missed it

We run squirrelscan, the audit tool we use, and it audited that appliance repair site eight times in those three months, including a cloud audit on 21 September. It reported nothing wrong with tracking, for these reasons:

• The page it inspects is loaded and read as text. It does not listen for the browser's own security-violation messages.
• Its security check grades the policy as written on one page. A broken policy and a corrected one gave identical findings.
• Its Google tag check looks for the tag in the page's HTML, and the tag is still there when every request it makes is blocked.

The same limits apply to many other site checkers. A passing report tells you the tag exists, not that it reports.

How to test your tracking

1. Open your site in Chrome on a real computer.
2. Open the developer console, and reload.
3. Look for red messages that say a request was blocked by Content Security Policy.
4. Visit three or four different pages, scroll all the way down, and click a call or contact button. Check the console again.
5. In Google Analytics, open the real-time report while you do this, and confirm your own visit appears with the events you expect.
6. Repeat on a phone.

If you are not technical, ask whoever looks after your site to do this and show you the real-time report as proof.

For Google Ads and Analytics together, the policy needs to allow connections to several Google addresses, including those used when Analytics is linked to Ads, and the Ads scripts themselves. Your developer will know the list. It changes from time to time, which is a reason to repeat the test after any change to the tags.

What this means for Ads results

Conversion tracking that records nothing makes an account look like it is failing. It also makes it impossible to improve, because every decision about keywords and budgets depends on knowing which clicks led to enquiries. For this reason we check tracking at the browser before changing an account. See also how Ads conversions can be inflated in the other direction.

If you use our Ads management add-on at $549 a month, month to month, tracking is the first thing we test. You keep your own Google Ads account and pay Google directly for clicks. The pricing page has the rest.