How SlaySlop checks Consent Signals

I care about the observation point. For Consent controls, SlaySlop publishes one sentence: the check "Reviews visible signals related to analytics and cookie consent." Visible is the operative word. The scanner is not claiming it reverse-engineered your CMP database. It is claiming it looked at what the rendered public page exposes about consent chrome related to analytics and cookies.

Outcome the check is for

You get a finding when the rendered page does not show usable visible cues that the site acknowledges analytics or cookie consent in the way the check looks for. The outcome is a route-linked Legal finding with evidence, not a certificate of lawful basis.

In the catalog this check lives under Legal, next to Privacy policy, Terms page, and Cookie signals (cookie inventory). Runtime UX checks such as Console errors sit elsewhere. Keep the buckets separate when you triage.

Boundaries

Read-only. Public surface. Permission required. SlaySlop does not edit code, content, settings, or data on the target. Scanning a site you do not own, manage, or have permission to test violates Acceptable Use.

The check is also not a claim about every CMP vendor, every regional template, or every Consent Mode parameter. Product language is "visible signals related to analytics and cookie consent." I treat that as UI and related on-page cues a visitor can see, observed in a real browser session—not as proof gtag('consent', 'update', …) fired with the right four v2 fields.

Static HTML is the wrong observer when the banner mounts from a tag manager. The Website scanner copy is explicit: the product crawls in a real browser; rendered pages surface client-side behavior static requests miss.

Happy path: how the signal is observed

Published scanner workflow, adapted to this check:

1. Open the public URL in a real browser crawl context.
2. Allow client-side code to run so late-mounted CMP UI can appear.
3. Review visible signals related to analytics and cookie consent on discovered pages.
4. Attach findings to routes so each issue stays linked to the page where it was observed.
5. Rank by impact so a missing consent surface on a tagged marketing page does not hide under footer typos.

Evidence per issue is part of the product framing: each finding explains the signal and the affected page. When I reproduce locally, I mirror the same idea: fresh profile, load, wait for late UI, then note what a visitor can actually see.

# Confirm the document responds before a manual consent pass
curl -sI "https://staging.example.com/pricing" | awk 'NR<=15 {print}'

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, must-revalidate

Headers only tell you the document arrived. Consent controls cares about nodes and overlays after script. In DevTools, watch the DOM for the CMP root and any "Manage cookies" control. Separately, the Cookie signals check inventories public cookie and tracking signals—useful contrast when a banner is missing but trackers are not.

A minimal "nothing visible" pattern looks like a page that loads analytics tags with no first-layer consent chrome at all:

<!-- Illustrative: tags present, no visible consent UI in the tree -->
<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>
<!-- no banner region, no cookie-settings control -->

Whether that matches your legal requirements is a counsel question. Whether the public page showed consent-related UI is the check's question.

Pitfalls in interpreting the result

"No Consent controls finding" is not the same claim as "lawful consent recorded for every purpose." Privacy policy can still be missing. Cookie inventory can still look aggressive. Console errors in the CMP script can still break the reject path while a decorative banner paints.

Coverage is easy to over-read. If the crawl did not open a deep checkout route that mounts a different CMP layout, that layout is outside the observation. Findings attach to observed pages.

Geo and A/B variants also matter. The scanner reports what it saw from its network path. Do not invent a universal "we never show banners in the EU" story from one scan row without checking your CMP targeting rules.

How I read severity in practice

A missing visible consent surface on a paid-acquisition landing page that loads ads and analytics tags usually outranks a missing surface on an obscure press clipping from 2019. SlaySlop ranks verified findings by impact in the scanner framing; lean into that instead of fixing the easiest admin screen first. Evidence on the affected page keeps the argument concrete when marketing asks why their campaign URL is blocked from launch.

Related checks and next action

If Consent controls fires on a primary landing page that also runs ads tags, fix the visible consent surface before debating microcopy. Pair with Cookie signals and Privacy policy. Then rescan the same URL; SlaySlop's fix-prompt flow includes follow-up scans to check whether an issue still appears.

Definitions live on Consent controls and the checks catalog.