Skip to content

Product

How SlaySlop checks Cookie Inventory

SlaySlop's Cookie Inventory check is Cookie signals in the product—an inventory of public cookie and tracking signals observed during the scan, kept next to consent and policy checks for an honest Legal row.

· by Henry Smith

How SlaySlop checks Cookie Inventory

I still reach for the Application panel first when someone asks what cookies a site sets. That habit is fine for one URL. It does not scale to a crawl, and it does not leave a client-readable artifact. SlaySlop's Cookie signals check—the live name behind the Cookie Inventory glossary route—"Inventories public cookie and tracking signals observed by the scan."

That is the mechanism I care about: observation during the scan, turned into an inventory you can file against.

Outcome the check is for

You get a Legal-oriented inventory of cookie and tracking signals on public pages the scan covered. The outcome supports triage and handoff: which signals appeared, on which surface, and whether Consent controls and policy pages tell a compatible story.

I use it when a client asks for a cookie list before legal review—not as the legal review itself. If counsel needs a memo, they get the inventory as an attachment, not as a substitute for their judgment.

Boundaries

Read-only public scanning. Permission required. Not a pentest. Not legal advice. Cookie signals ≠ Consent controls. Consent controls "Reviews visible signals related to analytics and cookie consent." Privacy policy checks whether a public privacy policy can be found and reached. Terms page is another discoverability check. I keep the labels straight so tickets stay searchable.

Authenticated-only cookies behind a login the public scan did not enter will not appear. Do not invent coverage claims. SlaySlop also will not click "accept" for you in a way that invents a consent record—the inventory is about observed signals on the public scan surface.

Loading diagram.

Happy path: how the signal is observed

Practical sequence aligned with published product language:

  1. Crawl and open public pages in the scan model.
  2. Observe cookie and tracking signals that appear on that public surface.
  3. Inventory what was observed for the Legal report row.
  4. Keep Consent controls and Privacy policy nearby so contradictions are obvious.
  5. Share the report through a portal when the client should not see your entire workspace.
bash
# Local sanity on a host you may test
curl -sI "https://staging.example.com/" | rg -i 'set-cookie|^HTTP/'
text
Manual cookie pass
url:
clean_profile: yes
cookies_seen:
trackers_suspected:
banner_seen: yes|no

I still do the manual pass on the two URLs we will demo. The scan inventory catches breadth; the manual pass catches "wait, that pixel was supposed to be off."

How I explain the observer without overclaiming: the scan loads public pages and records cookie and tracking signals it can observe, then presents that as Cookie signals. It is not a full traffic MITM of every third party on earth, and it is not your CMP admin export. It is the public surface, which is what outsiders and many auditors ask about first.

Pitfalls in interpreting the result

Treating an empty Cookie signals row on a content-only blog as proof the SaaS app subdomain is clean. Verifying from a browser that already accepted consent. Expecting the inventory to list every possible marketing tool ever contracted, including ones not loaded on scanned pages. Synonym-cycling the ticket into "privacy issues" with no URL.

When CMP changes land, rescan. Local calm that never meets a second observer is how false confidence regenerates—same lesson as Consent controls. If the CMP script throws, pair with Console errors ("Captures runtime exceptions from a real browser session") before you rewrite banner copy.

Why I keep this next to uptime and SEO

Clients experience one site. They do not care that Availability status, title tags, and Cookie signals live in different catalog groups. On handoff week I put one paragraph in the portal: uptime probe healthy, SEO basics present, cookie inventory reviewed next to consent UI. Dull paragraph. Survives the call.

Soft product mention only when it helps: SlaySlop's Legal checks give me that paragraph from one report instead of three tools and a spreadsheet that drifts.

What I refuse to claim in the portal

I will not write "GDPR compliant" from a Cookie signals row. I will write "Public cookie and tracking signals inventoried on scanned pages; consent UI reviewed separately; privacy URL returns 200." That sentence survives scrutiny. The compliance adjective does not.

Cadence after launch

Weekly or post-campaign rescans catch pixels that arrive after handoff. I schedule one deliberately after the first marketing experiment rather than waiting for a complaint.

Related next step

Run the permissioned scan, read Cookie signals beside Consent controls, then fix tag load or CMP config before you argue about copy on the cookie policy page. Soft link: Cookie inventory.