How to Audit Your Website's Trackers
In October 2026, a class action alleged that a single "track my package" click in Google Search fired 415 network requests to at least 28 domains — while a one-line notice told users only their tracking number would be shared. The number made headlines. But the number isn't the lesson. The audit method that surfaced it is — because you can run the same method on your own site today, for free, and find out exactly what fires before anyone consents. This guide shows you how, step by step.
To audit your website's trackers, load a page in a fresh browser with DevTools open and watch what it sends — before you touch any consent banner. The core method is four moves: open the page in incognito with the Network tab recording; list every third-party domain it contacts; note which fire before consent; and check what data rides along in those requests. That's the same method behind the "415 requests to 28 domains" headline — just pointed at your own site instead of someone else's.
A single interaction can quietly contact dozens of companies. The audit turns "I think our banner handles it" into a list you can actually see — and act on.
The click that allegedly fired 415 requests to 28 companies
On 9 October 2026, two California residents filed a proposed class action — Woodley v. Google LLC (N.D. Cal., No. 5:26-cv-11715) — over the package-tracking box that appears in Google Search results. According to the complaint, when a user searched a UPS tracking number and clicked to track the package, the interaction set off 415 network requests to at least 28 web domains. A FedEx tracking search, the complaint alleges, fired 142 requests to at least 19 domains.
The companies on the receiving end, as named in the filing, read like a roll call of the ad-tech industry: Meta, Google's own DoubleClick and Analytics, Adobe, Microsoft Bing, The Trade Desk, Tealium and Quantum Metric. The data allegedly sent along included browsing activity, location, device details and identifiers that let those firms tie the activity to existing profiles. And the disclosure the user saw? A single line: "Only your tracking number will be sent to UPS." The suit argues that statement was inaccurate, and brings claims including invasion of privacy, intrusion upon seclusion, and California wiretapping under CIPA §631.
Two things to hold steady before going further. First, these are allegations — the case is new, unproven, and the defendants dispute it; nothing here is a finding of wrongdoing. Second, and more useful to you: the eye-catching part isn't that it was Google, or that the number was 415. It's how anyone knew. Nobody needed Google's source code. They loaded the page, recorded the network traffic, and counted. That's an audit — and it's the thing you can do too.
Why the method matters more than the number
"415 requests to 28 domains" is a great headline and a terrible target. If you fixate on the number, you learn the wrong lessons: that this is a big-company problem, that your site is probably fine because it's smaller, or that some specific threshold of requests is "the bad one." None of that holds up.
The number is just the output of a measurement. Change the site and you get a different number — but the method that produced it is identical, and it's the part that transfers. A small e-commerce site with a chat widget, an analytics tag, two ad pixels and an embedded map can quietly contact a dozen companies on a single page view. You will never know which, or when they fire relative to consent, until you run the measurement. The audit is the skill; the number is just what it happens to return this time.
This reframing matters because most site owners have never actually looked. They assume the consent banner handles it, or that their platform is "compliant out of the box," or that a privacy policy listing "advertising partners" covers them. The audit replaces all of that assumption with a list you can see — and once you can see it, you can fix it. The rest of this guide is that method.
What a tracker audit actually measures
A proper tracker audit answers four questions, in order. Each one is a layer the previous assumption hides.
Notice that "do we have a banner?" is not one of the four. A banner is a control, not a measurement — and as the 2026 EU scans showed, the banner is frequently present while the trackers fire anyway. The audit measures what actually happens, which is the only thing a regulator or a plaintiff cares about.
The step-by-step audit (free, about 2 minutes)
Everything you need is already in your browser. No extension, no account, no cost. The one rule that makes or breaks the result: look before you click the banner. The whole point is to see what fires without consent, so if you accept cookies first, you've destroyed the evidence.
Step 1 — Start clean
- Open a fresh incognito / private window. This clears old cookies so you're measuring a first-time visitor, not yourself.
- Open DevTools (F12, or right-click → Inspect) and switch to the Network tab.
- Tick "Preserve log" so requests aren't wiped on navigation, and leave the recording dot red (on).
Step 2 — Load the page and freeze
- Type your URL and load it. Do not touch the cookie banner yet.
- Let the page settle for a few seconds. Everything in the Network panel now fired before any consent.
Step 3 — Count the third parties (the "28 companies" step)
- Add the Domain column: right-click the Network column header → Domain. Now sort by it.
- Scan for domains that aren't yours:
google-analytics.com,googletagmanager.com,doubleclick.net,facebook.net/connect.facebook.net,analytics.tiktok.com,px.ads.linkedin.com,demdex.net(Adobe),tealium, and anything else not on your own domain. - Each distinct third-party domain is roughly one company with a copy of this request. That count is your version of "28."
Step 4 — Inspect what's inside
- Click a tracker request and read the Headers and Payload. Look for the page URL, a user or click ID, email hashes, or form values being passed along.
- Open Application → Cookies and check whether analytics/ad cookies (
_ga,_fbp,_ttp) already exist before you clicked. They shouldn't.
Step 5 — Now test consent
- Click Reject (or "necessary only"). Watch the Network panel: ideally nothing new fires. If trackers still appear, the reject button is cosmetic.
- Reload clean, then click Accept: the tracking requests should now appear. That's correct — consent was given.
Repeat Step 2–4 on your highest-intent interactions, not just the homepage: the checkout, the "track my order" button, the contact form, the search box. As the Google/UPS case shows, the interaction a user trusts most — "just show me my package" — can be the one that fires the most.
Get the same audit, rendered and mapped, in ~10 seconds
Our free scanner runs exactly this method in a real browser — lists every tracker, flags the ones that fire before consent, and maps each domain to the company and the law (CIPA, CCPA, GDPR) — so you get the audit without the DevTools legwork. No account.
Scan your site free →How to read what you find
A raw list of domains isn't the finding — the finding is when each one fired. The same tracker is fine or a problem depending entirely on which side of the consent click it sits on. Use this to classify what the audit turned up:
| What you saw | What it means | Priority |
|---|---|---|
| Ad/analytics domain fired before any click | Tracking without consent — the core exposure, and the CIPA/ePrivacy fact pattern | High |
| Trackers fired after clicking Reject | The reject path leaks — often worse legally than no banner, since it misrepresents the choice | High |
| Analytics/ad cookies present before any click | Storage set without consent; check whether it's truly essential | High |
| A domain you don't recognise at all | A tag added by a marketer, agency, or embedded widget the CMP doesn't manage | Medium |
| Trackers appeared only after Accept | Working as intended — consent was given first | OK |
| Only your own domain + CMP + fonts before the click | Clean pre-consent state — what you're aiming for | OK |
Anything in the "High" rows is what a scanner, a regulator, or a plaintiff's expert would flag first. The "unrecognised domain" row is the sleeper: it's how sites end up with trackers nobody decided to add, and it's exactly the gap a consent tool can't close because it was never told the tag existed.
When the manual audit stops working
The DevTools method is perfect for a spot check: one page, one moment, one person looking. It falls apart the instant you need coverage instead of a snapshot. A real site has dozens or hundreds of pages; trackers change when marketing ships a campaign; a tag that was clean in October reappears in December. And a single manual pass can't prove to anyone — auditor, client, court — what the state was last quarter.
That's the boundary where a scanner earns its place: it crawls many pages, runs on a schedule, alerts you when something new starts firing, and keeps a dated record. If you're responsible for one site, the manual audit plus an occasional free scan is plenty. If you manage a portfolio — an agency running consent for many clients — the scale and liability math is different enough that it's its own topic; we cover it in tracker scanning for agencies. Either way, the free scanner is the fastest way to run this audit without the DevTools steps: see free website tracker scanners for the landscape.
What to do with the results
An audit that just produces a scary list is wasted. The point is to act. In order:
- Triage by timing. Fix the "fires before consent" and "fires after reject" items first — those are the legal exposure. A tracker that only fires after accept can wait.
- Gate, don't just document. The fix isn't adding the tracker to your privacy policy; it's holding it until consent. That's prior blocking — the consent layer loads first and releases tags only on accept.
- Hunt the unrecognised domains. Trace each one to the tag or widget that loads it. If nobody can say why it's there, that's your answer about whether to keep it.
- Re-audit after every change. A campaign launch, a new embed, a theme update — any of these can reintroduce a tracker. The audit is a habit, not a one-time event.
- Keep the record. Save the before/after of each audit. When someone asks what your site did on a given date, a dated scan is the only honest answer — the live banner can't tell you what fired months ago.
The Google/UPS complaint exists because someone ran this method and wrote down what they saw. Run it on your own site first, and you get to fix the gaps on your terms instead of discovering them in a demand letter. For the US cases that make that gap expensive, see the CIPA lawsuit tracker.
Key takeaways
- The number is the headline; the method is the lesson. "415 requests to 28 domains" (alleged, in Woodley v. Google) came from loading a page and counting — something you can do on your own site.
- An audit answers four questions: what fires, when (before or after consent), what data rides along, and who ends up with it. "Do we have a banner?" isn't one of them.
- Look before you click. The whole value is seeing what fires without consent — so audit in a fresh incognito window with DevTools Network open, before touching the banner.
- Count third-party domains in the Network tab; test Reject (nothing new should fire) and Accept (now trackers appear). Fires-after-reject is often the worst finding.
- Unrecognised domains are the sleeper risk — tags a CMP never manages because nobody told it they exist.
- Manual is for spot checks; scanners are for coverage. Use the free scanner for speed and scale, and keep dated records so you can prove what your site did.
Frequently asked questions
How do I audit the trackers on my website?
Open your site in a fresh incognito window with DevTools and the Network tab recording, and load the page without touching the cookie banner. Add the Domain column and list every third-party domain the page contacts (google-analytics.com, doubleclick.net, facebook.net, tiktok, linkedin, Adobe's demdex.net, and so on) — each distinct domain is roughly one company receiving the request. Click individual requests to see what data they carry, and check Application → Cookies for analytics or ad cookies set before any choice. Finally, test the Reject and Accept buttons to confirm trackers are actually held until consent. A free privacy scanner runs this same method automatically.
What was the "415 requests to 28 domains" lawsuit about?
It refers to Woodley v. Google LLC (N.D. Cal., No. 5:26-cv-11715), a proposed class action filed on 9 October 2026 over the package-tracking box in Google Search. The complaint alleges that clicking to track a UPS package fired 415 network requests to at least 28 domains — sending browsing, location and device data to companies including Meta, Adobe, Microsoft, The Trade Desk, Tealium and Quantum Metric — while Google's notice said only the tracking number would be sent to UPS. It brings claims including California wiretapping (CIPA §631), invasion of privacy and fraud. These are allegations that have not been proven in court, and the defendants dispute them.
Why does it matter whether a tracker fires before or after consent?
Because that timing is the line between compliant and not. Under EU and UK rules, non-essential trackers must not run until the visitor consents, so anything firing before the choice is a breach. In the US, routing a visitor's interaction to a third party without consent is pleaded as wiretapping, with statutory damages of $5,000 per violation under California Penal Code §637.2. A tracker that fires only after the user clicks accept is generally fine; the same tracker firing on page load, before any choice, is the exposure. That's why an audit records timing, not just the list of trackers.
Do I need paid tools, or can I audit trackers for free?
You can do a solid spot audit entirely free with your browser's built-in DevTools — no extension or account needed. That's enough to check one page at one moment. You'll want a scanner when you need coverage rather than a snapshot: crawling many pages, re-checking after site changes, catching new trackers automatically, and keeping dated records to prove what your site did. A free privacy scanner handles the single-page case in about 10 seconds; ongoing monitoring across a whole site or a client portfolio is where paid, scheduled scanning pays off.
What's the most common thing a tracker audit turns up?
Two things, usually. First, trackers firing before consent — analytics and ad tags that run on page load even though a banner is present, because the banner was never actually wired to block them. Second, unrecognised domains: tags nobody on the current team remembers adding, often introduced by a past campaign, a marketing contractor, or a third-party widget that loads its own scripts. The second is the sleeper risk, because a consent tool can only govern the tags it has been told about — a tracker it doesn't know exists fires outside the gate entirely.
How often should I audit my site's trackers?
Treat it as a habit tied to change, not a calendar chore. Run an audit after anything that can alter what loads: a new marketing campaign or pixel, an added embed or widget, a theme or platform update, or a change to your consent tool's configuration. Beyond that, a periodic baseline — monthly for an active site, quarterly for a stable one — catches drift. The practical version for most teams is a free scan whenever you ship a change, plus scheduled scanning if you manage multiple sites and need alerts and dated records rather than manual passes.
The bottom line
The Google/UPS case will take years to resolve, and whether the 415 number holds up is for a court to decide. But the part that's useful to you doesn't depend on the verdict. Someone found that number by doing something you can do in two minutes: loading a page, recording the network, and counting what left. The audit is not a specialist skill — it's a browser tab and the discipline to look before you click.
Run it on your own highest-trust interactions — your checkout, your "track my order," your contact form — and you'll likely find trackers you didn't know were there, firing before anyone agreed. That's not a disaster; it's the most fixable kind of problem, because now you can see it. The sites that end up in a complaint are the ones where nobody looked. Be the one who looked.
Run the audit on your own site — free, in ~10 seconds
Our free scanner runs the exact method in this guide: it loads your page in a real browser, lists every tracker, flags the ones that fire before consent, and maps each domain to the company and the law — CIPA, CCPA, GDPR. Then run ConsentPixel free for 14 days: prevention-first blocking that holds non-essential tags until genuine consent, with a dated, per-visitor record that proves it. Any platform.
Scan your site free →Related reading
- Free website tracker scanners — the tools that automate the audit in this guide
- Tracker scanning for agencies — running this audit across a portfolio of client sites
- Is a cookie banner enough to be compliant? — why a visible banner doesn't mean trackers are held back
- A consent platform isn't enough: the $1.4B lesson — why installing a CMP doesn't close the gap by itself
- CIPA lawsuit tracker — the US cases, including package-tracking and pixel suits
ConsentPixel — Privacy · Verified builds prevention-first consent tooling that blocks non-essential trackers until visitors genuinely consent, on any platform, and proves consent came first. This article is an educational how-to and general information, not legal advice; ConsentPixel is not a law firm. The litigation described is active and its figures are unproven allegations; company names are used to describe the case and the audit method, not to allege wrongdoing. Verify your own obligations with qualified counsel.