Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Compliance · Medium severity

Cookie Banner Missing: Check Whether Consent and a Usable Choice Are Needed

Review a missing cookie banner with observed tracking. Assess actual consent requirements, fresh-state behaviour, unreadable dialogs and the detection window.

Published · Updated

What the check tests

Check
comp.consent.banner-present - Consent dialog present when non-essential cookies are used
Passes when
Runs only when the snapshot already found a documented tracking identifier or endpoint. A dialog we can see is not there is a finding; a dialog we cannot see - closed shadow root, cross-origin CMP frame - returns nothing and is counted as reduced coverage.
Scope
graded on every page crawled
Severity
Medium
Fix effort
medium - a working day
Impact when fixed
medium

In one paragraph

Cookie banner missing means the rendered snapshot combined recognised tracking evidence with no consent interface the detector could identify. Determine whether the actual operations require consent and whether an effective choice mechanism is available at the right time. A site using only applicable exempt operations may not need a consent banner. Neither absence of a recognised tracker nor presence of a notice establishes complete compliance.

Why it matters

Under the ePrivacy framework, non-exempt storage or access on terminal equipment requires prior consent with appropriate information. Exemptions concern actual operations, such as qualifying strictly necessary access for a requested service, not simply category names selected in a CMP.

A banner is one implementation mechanism, not the substantive legal test. A notice with only an OK button can exist while choice or timing is defective. A custom mechanism can also be usable despite falling outside a detector's vendor list.

Geography, stored preferences, conditional rendering, and runtime failures affect what a visitor sees. A staff browser that accepted months ago does not reproduce a new user's state. A scanner's location and limited wait are observations, not evidence of every jurisdiction or device.

How WebAuditOS evaluates this finding

The supplied per-page rule observes a fresh rendered mobile snapshot without clicking and searches its known platform roots, consent-dialog semantics, and positioned-banner patterns after its documented short settle window.

Recognised tracking with no detected dialog can fail at medium severity; detected dialog or no listed evidence can pass under its rules. Unclassified third-party cookies, unreadable or potentially cross-origin overlays, and missing renders can remain ungraded. It does not validate freely given consent, effective blocking, or every unknown tracker.

How to fix it

  1. Inventory actual storage, access, and processing on representative templates. Decide the relevant exemptions and consent requirements using applicable national implementation and guidance.
  2. Test with a fresh profile before choosing anything, recording the URL, time, locale assumptions, and important technical evidence. Do not infer that every network request is an analytics cookie operation.
  3. If consent is required, provide a clear accessible mechanism before the relevant operation begins. The request for consent must be informative and the behaviour must follow the choice; adding a visual bar after collection is not a complete repair.
  4. Initialise tags and embedded providers according to the reviewed design. Test custom scripts as well as the CMP's own integration so a recognised platform does not merely coexist with uncontrolled collection.
  5. Offer a genuine understandable choice and a suitable ongoing way to change it. Assess rejection, granular settings, withdrawal, and the consequences of each rather than a single first-layer screenshot.
  6. Test unreadable frames, shadow roots, delayed overlays, and region-specific deployment deliberately. A detector limitation can require manual evidence; do not weaken necessary isolation solely to make a scan read the dialog.
  7. Review keyboard access, focus, readable controls, and error recovery if the CMP fails. A consent interface can itself create an accessibility barrier or a failed default state.
  8. Rescan banner and behaviour checks separately. Document what was actually tested, and do not advertise a green badge as a general legal approval.

What the fix can break

A banner added to a site with no relevant consent requirement can create unnecessary confusion. Use accurate information and a proportionate design rather than collecting consent without a purpose.

Failure-open tag configuration can defeat a polished interface. Test behaviour when vendors or network dependencies are unavailable.

Do not treat names such as functional or privacy in a script URL as evidence of a valid exemption or compliant mechanism.

Questions

No. Assess the actual storage/access and applicable rules rather than assuming a universal banner obligation.

No. Choice, information, timing, and actual behaviour need separate evaluation.

Why can an existing banner be missed?

The observed state, timing, languages, rendering, or accessibility boundary may fall outside the detector's coverage.

Review pre-choice cookies, analytics evidence, and the cookie consent guide.

Standards and sources

  • ePrivacy
  • § 89 odst. 3 ZEK
  • GDPR Art. 4(11)
  • GDPR Art. 7

In the report

Test this on your own site

Every scan runs comp.consent.banner-present on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.