Open your own website in a private browser window, open the network tab, and count the third-party domains it contacts before you click anything on the cookie banner. On a typical platform-built dealer site the answer is not one or two. Every one of those requests is a vendor you've taken on, a privacy disclosure you owe, and — if it's loading before consent — a compliance question. You can find out where your own site stands in about ten minutes, and the audit below shows exactly how.
I build dealership sites, and I made a deliberate choice on my own: consent-gated analytics, self-hosted fonts, one form processor, nothing else. That makes the contrast easy to demonstrate rather than assert. I'm not a lawyer and none of this is legal advice.
Why a dealer should care about this at all
Three reasons that have nothing to do with ideology.
Every third-party script is a performance cost. Tag stacks are one of the main reasons inventory pages get slow, which connects directly to the image and page-speed side of the same problem.
Every third-party script is also a security surface. A script you load has the same access to your page as your own code does, including anything a visitor types into a form on it.
And every tracker is a disclosure obligation. If a visitor in the EU or UK asks what you collect about them, "I don't know, ask my website vendor" is not an answer that helps you.
How to audit your own site in ten minutes
No tools required beyond a browser.
Open a private or incognito window so you start with no cookies. Open developer tools, go to the Network tab, filter to All, and load your homepage. Do not touch the cookie banner. Then sort by domain and write down every domain that isn't yours.
Now check the Application tab (Chrome) or Storage tab (Firefox) and look at cookies and local storage. Again, before consenting.
Then click Accept and watch what appears that wasn't there before. The difference between those two lists is your actual consent gate. If the lists are identical, you don't have one — you have a banner.
What you're looking for is a short list where every domain is one you can name and justify, and a visible difference between the before-consent and after-consent lists. A long list that's identical before and after you click Accept means the banner is decoration. For a useful comparison, run the same audit on a competitor's site and then on a site built with a minimal stack, and put the two lists side by side.
Based on how these sites are assembled, the categories you'll find are predictable: analytics, ad platform pixels and remarketing tags, chat widgets, call-tracking scripts doing dynamic number insertion, digital retailing and finance tools, inventory or merchandising widgets, review platforms, accessibility overlays, session recording, and hosted webfonts.
The consent gate is a sequence, not a banner
Here is the part most dealers assume their vendor has handled. A cookie banner that appears while the trackers are already running is decoration.
Google's consent mode is the mechanism for doing it properly, and the documentation is specific about order: load the Google tag with a gtag('consent', 'default', ...) call that denies what should be denied, then load your consent solution, then call gtag('consent', 'update', ...) after the user indicates a choice. Google states flatly that if the consent code is called out of order, consent defaults won't work.
Two options exist beyond the basic setup that are worth knowing about, because they're the honest answer to "won't blocking cookies destroy my data?" URL passthrough can pass ad click, client ID and session information through URL parameters when storage consent is denied, and ads_data_redaction further redacts ad click identifiers when ad_storage is denied, routing requests through a domain without third-party cookies. So the choice isn't between tracking everything and measuring nothing.
One piece of nuance Google recommends and most implementations skip: scope your default consent settings to the regions where you actually show a banner. Region-specific defaults use ISO 3166-2 codes, and the most specific region wins — so a default of granted for US and denied for US-CA means a California visitor gets denied. That preserves measurement where banners aren't required while respecting the rules where they are.
Here's what mine looks like, and it's the whole thing:
gtag('consent', 'default', {
analytics_storage: 'denied',
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
wait_for_update: 500
});Everything denied by default, with a 500ms window for the banner to report the visitor's choice before tags fire. If the visitor declines, no analytics cookies are set and no usage data is sent to Google. If they accept, the update call grants it. The site works identically either way, which is what the banner says.
The fonts thing, because it's the cheapest win available
Almost every dealer site loads its typefaces from Google's font CDN. That means every visitor's browser makes a request to a third party before a single pixel of your page renders, and that request carries their IP address and browser details.
Self-hosting fixes it completely. All the fonts on my site are self-hosted alongside the website files, so no font requests go to Google or anyone else, and loading a font transmits nothing about the visitor to a third party. It also removes a render-blocking external connection, so it's a performance win at the same time. This takes about twenty minutes to implement and there is no downside.
What a minimal stack actually looks like
Mine, in full: one analytics property, consent-gated; self-hosted fonts; one form processor. That's it.
The form processor is worth describing because it's the one place real personal data moves. The demo form collects a name and email as required fields plus an optional dealership name and message. Submissions go over HTTPS to Web3Forms, get emailed to me, and sit in the Web3Forms dashboard for 30 days so I can follow up. Named vendor, named retention period, named purpose, written down in the privacy policy where anyone can read it.
The general principle scales to a dealership: for every third-party script on the site, you should be able to state what it does, who the vendor is, what data it receives, and how long they keep it. If you can't do that for a script, the honest options are to find out or remove it.
A note on one category specifically. Call tracking with dynamic number insertion swaps the phone number on your page depending on the traffic source, so you can attribute calls. Vendors in that space assert it has no impact on SEO, and a common view among local SEO practitioners is that Google understands number switching. I'd treat both as claims rather than settled fact, and if you use DNI, at minimum make sure the number in your Google Business Profile and your structured data is your real primary line.
What this means for your dealership
Run the ten-minute audit. Then take the list of third-party domains to whoever manages your site and ask three things for each one: what is this, do we still use it, and does it load before or after consent. In my experience that conversation retires two or three scripts that nobody remembers adding, which is free performance.
Then read your own privacy policy against what you found. If the policy doesn't name the tools the audit revealed, the policy is wrong — and that's the document a regulator or a customer would read first.
This is also one of the clearer differences between owning your code and renting a platform. On a platform, the tag stack is partly the vendor's product decision; scripts arrive with updates and you find out by auditing. When you own the build, nothing loads that you didn't put there. That's a real point in the custom versus platform column, though it's rarely the deciding one.
Where I'd tell you not to hire me
If you need a formal GDPR compliance review, a data protection impact assessment, or a records-of-processing document, that's a privacy professional's job. I can tell you what your website loads and I can change what it loads. I cannot tell you whether your overall data processing is lawful, and you shouldn't accept that opinion from a developer.
And if your dealership genuinely depends on a rich remarketing stack for its advertising, stripping it out to win a tag audit would be a bad trade. The goal isn't the smallest possible stack. It's a stack where every item is there on purpose.
Sources
- Google Tag Platform, Set up consent mode on websites (last updated 30 July 2026) — default/update sequence and ordering warning,
wait_for_update, Consent Mode v2 parameters, URL passthrough,ads_data_redaction, region-specific defaults and precedence. - Google Analytics Help, What the value (not set) means in your reports — consent mode implementation errors and their measurement effects.
- elottri.com privacy policy — self-hosted font subsets, Web3Forms processing and 30-day retention, consent-gated GA4, GDPR rights.
- CallSource and WhatConverts on dynamic number insertion — cited as vendor claims about DNI and SEO, not independent findings.
Want the audit run on your site? Send me the URL and I'll send back the list of what it loads before consent.