TL;DR: Auditing third-party cookies means inventorying every cookie and tracker your site sets that comes from a domain other than your own. Use your browser’s developer tools — Application > Cookies and the Network panel — to capture what loads, then catalog where each tracker comes from (analytics, embedded maps/video/social, chat widgets, fonts). Classify each as essential, functional, analytics, or advertising, then decide per item: remove it, replace it with a privacy-respecting alternative, or disclose and (where required) gate it behind consent. Re-run the audit after every site change, because trackers reappear with new embeds.
Most government websites accumulate third-party cookies the same way a desk accumulates clutter: one item at a time, added by different people for different reasons, with no one keeping a list. A communications staffer embeds a YouTube video. A new vendor drops in a chat widget. A theme update pulls fonts from a third-party CDN. Each change quietly invites an outside company to set cookies and potentially track your constituents — and your privacy policy says nothing about any of it.
A third-party cookie audit is how you replace guesswork with a real inventory. This is a hands-on, technical walkthrough aimed at government IT teams, webmasters, and the contractors who support them. You don’t need special software to start — the developer tools built into Chrome, Edge, and Firefox are enough to find every tracker your site loads. By the end you’ll have a classified inventory and a clear decision for each item: remove, replace, or disclose.
This audit is the practical counterpart to understanding what a cookie disclosure is and when it’s required. You can’t write an accurate disclosure until you know what your site actually sets.
Before You Start: First-Party vs. Third-Party
A quick refresher, because the whole audit hinges on it. A first-party cookie is set by the domain in the address bar — yourcity.gov. A third-party cookie is set by a different domain that your page loaded a resource from: a script, an iframe, a font, an image, a tracking pixel. When yourcity.gov embeds a YouTube player from youtube.com, any cookie youtube.com sets is third-party.
Third-party cookies are the audit’s focus because they’re the ones that can follow a constituent across the web and that trigger most disclosure and consent obligations. First-party cookies still belong in your inventory, but they’re usually operational and lower-risk.
Step 1: Set Up a Clean Test Environment
Your own browser is polluted — extensions, prior logins, and cached cookies will distort the picture. Start clean:
- Open a new incognito/private window (or a fresh browser profile). This disables most extensions and starts with no cookies.
- Decide which browser. Chrome and Edge share the same DevTools; this guide uses their labels. Firefox is equivalent with slightly different menu names.
- Have a list of representative page types ready, not just the homepage. Audit at least: the homepage, a content/news page (where embeds live), a forms/permit page, a page with a map, the search results page, and any portal or payment page. Trackers differ by page type.
Tip: clear cookies between page loads if you want to see exactly what each page sets on a fresh visit. In DevTools, Application > Storage > “Clear site data.”
Step 2: Inventory Cookies in the Application Panel
This is the core of the audit.
- Open DevTools: F12, or right-click anywhere on the page and choose Inspect.
- Go to the Application tab (in Firefox: Storage).
- In the left sidebar, expand Cookies. You’ll see one entry per domain that has set cookies on this page.
Each domain listed under Cookies is a source. Your own domain (yourcity.gov) is first-party. Every other domain is a third party. Click each one to see its cookies, and for each cookie note:
- Name (e.g.,
_ga,_fbp,VISITOR_INFO1_LIVE) - Domain that set it (this tells you the vendor)
- Expires / Max-Age — “Session” or a date. Persistent cookies that last months or years deserve scrutiny.
- SameSite and Secure flags — relevant for security as well as classification.
Record all of this in a spreadsheet. A workable schema:
| Cookie name | Set by domain | First/Third | Expiry | Suspected purpose | Vendor |
|---|
Don’t try to classify perfectly yet — just capture everything. Repeat for every page type on your list, because a video embed on one page won’t show up on another.
Don’t forget local storage and other storage
While you’re in the Application panel, also glance at Local Storage, Session Storage, and IndexedDB in the same sidebar. Modern trackers increasingly store identifiers here instead of (or alongside) cookies, precisely because it evades cookie-only audits. Note any third-party storage you find.
Step 3: Trace Trackers in the Network Panel
The Cookies view shows what got stored. The Network panel shows who asked for it — useful when a cookie’s purpose isn’t obvious from its name.
- Open the Network tab in DevTools.
- Check Preserve log so redirects don’t wipe your data.
- Reload the page (Ctrl/Cmd+R) so DevTools captures every request from the start.
- Look at the Domain column (right-click the column header to enable it if hidden). Sort or group by domain.
Now scan for any domain that isn’t yours. Each represents a third-party resource your page pulled in. Common offenders and what they usually mean:
google-analytics.com,googletagmanager.com,analytics.google.com— analyticsdoubleclick.net,googlesyndication.com,facebook.com/connect.facebook.net— advertising / social trackingyoutube.com,youtube-nocookie.com,vimeo.com— embedded videomaps.googleapis.com,mapbox.com— embedded mapsfonts.googleapis.com,fonts.gstatic.com,use.typekit.net— third-party web fontsintercom.io,zendesk.com,drift.com,tawk.to— chat / support widgetsaddthis.com,sharethis.com,platform.twitter.com— social sharing buttons
Click any request to see its Cookies sub-tab, which shows cookies sent and received for that specific request. This is how you connect a mysterious cookie back to the feature that caused it. The Initiator column tells you which script triggered the request — invaluable for finding which embed or tag is responsible.
Step 4: Find the Trackers DevTools Makes Easy to Miss
A few categories hide:
- Tag managers. If you see Google Tag Manager (
googletagmanager.com), the real trackers are configured inside it and may fire conditionally. Get access to the GTM container and review every tag — it’s the most common place undisclosed trackers live on government sites. - Cookies set after interaction. Some widgets only set cookies once the user clicks (a chat bubble, a “load video” placeholder). Re-run the audit while actually using the page.
- Cookies set on subdomains or portals. Payment processors, hosted form tools, and SSO logins often live on a different host. Audit those flows separately.
- CMS- and host-injected scripts. Granicus, CivicPlus, and similar government platforms sometimes inject their own analytics or A/B testing scripts you didn’t add. Check the Network panel for the vendor’s domains.
For a faster first pass across many pages, free tools like Cookiebot’s scanner, Blacklight (from The Markup), or browser extensions like EditThisCookie can crawl and report — but they’re a starting point, not a substitute for the manual DevTools review that lets you trace each cookie to its cause.
Step 5: Classify Every Cookie
Now turn the raw inventory into decisions by sorting each cookie into a category. The four standard buckets:
| Category | Definition | Typical examples | Disclosure / consent posture |
|---|---|---|---|
| Essential / strictly necessary | Site can’t function without it | session, CSRF token, load balancer | Disclose; usually exempt from consent |
| Functional / preferences | Improves experience but not required | language, font size, “remember me” | Disclose; consent depends on jurisdiction |
| Analytics / performance | Measures usage | _ga, _gid, DAP cookies | Disclose; consent likely required in EU and for some state laws |
| Advertising / tracking | Targets ads, builds profiles, cross-site tracking | _fbp, doubleclick cookies | Disclose and gate behind consent; highest risk |
Be honest in the gray zones. A social-sharing widget that phones home before the user clicks it is tracking, not a “preference.” Analytics configured to share data with an ad network is advertising, not “performance.”
Step 6: Decide — Remove, Replace, or Disclose
For every third-party cookie, pick one of three paths.
Remove
The single most effective remediation for a government site is to delete trackers you don’t actually need. Ask of each one: does this deliver value to constituents, or did it arrive by accident? Frequent candidates for removal:
- Social-sharing button libraries that track users (replace with simple
mailto:/share links that set no cookies) - Leftover advertising pixels from a one-time campaign
- Duplicate analytics tools running side by side
- Abandoned chat widgets no one monitors
Fewer third parties means fewer cookies, fewer disclosure obligations, faster page loads, and a smaller attack surface. It’s the rare fix that improves privacy, performance, and security at once.
Replace
Where the feature is needed but the tracker is heavy-handed, swap in a privacy-respecting alternative:
- Analytics: move to the federal Digital Analytics Program (DAP, behind analytics.usa.gov), self-hosted Matomo, Plausible, or Fathom — all configurable to set no third-party cookies.
- YouTube embeds: use the
youtube-nocookie.com(privacy-enhanced) embed domain, or a click-to-load facade that loads nothing until the user presses play. - Web fonts: self-host the font files instead of pulling them from
fonts.googleapis.com. This also speeds up rendering. - Maps: consider static map images for simple location displays instead of a full interactive embed.
Disclose (and gate, where required)
For trackers you keep and can justify, document them in your cookie disclosure: name the vendor, the category, the purpose, the duration, and how to opt out. Update the disclosure to match the inventory exactly — accuracy is the whole point. Where the law requires consent (EU residents, or advertising/sale cookies under certain state laws), the tracker must be blocked until the visitor agrees, which means a properly configured consent banner. See government website cookie banner requirements for building that correctly, and our state privacy laws guide for whether consent (vs. mere disclosure) applies to your entity.
A Note on Mixed Content and Security
While you’re auditing what loads, watch for resources loaded over http:// on your https:// site — DevTools flags these as mixed content. They’re a security and trust problem distinct from cookies; if you spot any, see our guide to mixed content issues on government websites. Reviewing third-party domains is also a natural moment to revisit your security headers, since a strong Content-Security-Policy can actually prevent unauthorized third-party scripts from loading in the first place.
Make It Repeatable
A one-time audit is a snapshot that’s wrong the moment someone publishes a new page with an embed. Turn the audit into a routine:
- Document the process so any team member can repeat it (this guide is a starting template).
- Re-audit on a schedule — quarterly at minimum, and after every CMS upgrade, theme change, or new vendor integration.
- Lock down who can add embeds and tags. Restrict GTM access and require a privacy review before any new third-party script ships.
- Use Content-Security-Policy to allowlist exactly which third-party domains may load, so an unreviewed tracker simply won’t run.
Manually re-auditing third-party cookies after every content change isn’t realistic for a busy government web team — which is exactly why undisclosed trackers pile up between audits. Govzu continuously scans your government website for the third-party cookies and trackers it actually loads, flags new ones the moment a staffer publishes an embed or a vendor injects a script, and helps keep your cookie disclosure honest. Combined with continuous compliance monitoring across accessibility, privacy, and security, your one-time audit becomes a standing guarantee instead of a snapshot that’s already out of date.