Common Cookie Inventory mistakes that still ship

I keep a short list of Cookie signals mistakes that survive code review. None of them are exotic. They come from treating the Application panel like a checklist and the consent banner like a substitute for an inventory. Lab notebooks get messy; handoff notes should not.

SlaySlop's Cookie signals check "Inventories public cookie and tracking signals observed by the scan." The observation point matters: public surface, crawl context, evidence on the affected page. The mistakes below fight that observation point.

Outcome if you catch these early

You get an inventory that matches what a first visit actually accumulates, plus tickets that name hosts and routes instead of "fix cookies somehow." Mechanisms first. Blame later. Agencies that keep this boring tend to keep clients.

Boundaries

Read-only public scan. Permission required. Not a pentest. Cookie signals sits under Legal next to Consent controls, Privacy policy, and Terms page. Closing an inventory finding does not retire a missing privacy policy or a missing consent UI.

Static HTML is a weak witness for cookies set from script after hydration. The Website scanner product states that SlaySlop crawls in a real browser and that rendered pages surface client-side behavior static requests miss. That is how the check observes signals a single curl never sees.

Mistake 1: one Application tab, one second

People open Cookies for www.example.com, see two first-party rows, and call it done. They never open the filter for third-party hosts. They never watch Network for collect, g/collect, or pixel paths that set cookies via response headers.

# After a permissioned browse, dump response Set-Cookie names from the document
# (Headers only — still not a full inventory; use the browser for document.cookie too.)
curl -sI "https://www.example.com/" | awk 'BEGIN{IGNORECASE=1} /^set-cookie:/{print}'

A document response with no Set-Cookie does not prove the page stays cookie-quiet after JavaScript runs. Cookie signals is an inventory of observed public signals, not a single header dump.

Mistake 2: staging inventory, production tags

Staging runs with analytics off "to keep noise down." Production enables the full GTM container on launch morning. Your lab notes say clean. The live Cookie signals row does not. Scan the host you are handing off. Paste a production URL, staging build, or client preview you have permission to scan—and be honest about which one you used in the portal.

Mistake 3: banner equals inventory

Consent controls "Reviews visible signals related to analytics and cookie consent." That is UI chrome. Cookie signals inventories cookies and tracking signals. Shipping a pretty banner while an undeclared marketing pixel still sets identifiers is two different failures wearing one word: cookies.

Mistake 4: ignoring post-consent differences

Some stacks set almost nothing until Accept. Others set essentials earlier and marketing later. If you only inspect the pre-consent state, you miss what the client will see after they click through. If you only inspect the post-accept state on a reused profile, you miss the first-layer story. Both states belong in notes. Write "pre" and "post" as separate lines. Future you will thank present you.

Mistake 5: treating the inventory as counsel

An observed list of public cookie and tracking signals is evidence. It is not a lawful-basis memo. Do not tell a client the Legal row is "compliant" because Cookie signals looked tidy. Say what was inventoried on which routes, then loop counsel for the regimes that actually apply.

Happy path that avoids the list

1. Fresh profile on each launch URL.
2. Note pre-interaction cookies.
3. Exercise consent paths you promised.
4. Note post-interaction cookies and third-party requests.
5. Diff against Cookie signals findings and prior handoff notes.
6. Open Consent controls and Privacy policy rows in the same triage pass.

When SlaySlop ranks findings by impact, start at the top. A surprise identifier on /pricing usually beats a noisy footer preference cookie on an unused language route.

How I annotate a Cookie signals finding

When evidence names a route, I paste three lines into the ticket: the cookie or tracker host, whether it appeared pre- or post-consent, and the GTM tag id or script URL if I have it. That annotation stops the "delete all cookies" impulse. It also makes the next scan useful, because you can see whether the same initiator returned.

If marketing insists a vendor is required, the ticket becomes a documentation ticket instead of a deletion ticket. Cookie signals still inventories the public signal. The fix is aligning the public cookie policy and the Consent controls chrome with reality, not pretending the inventory is wrong.

Related next step

When a finding names a route, reproduce on that route before arguing with the scanner. Soft read: the Cookie signals glossary entry and the checks catalog.