Tools and methodology · Published 27 September 2026 · By John Cookie

A cookie scanner is useful when its results lead to better questions. It becomes misleading when a detected banner, missing signal or headline score is treated as a complete verdict on a website.

This guide explains how to use an initial scan, how to record its limits and when to investigate further. The example below is a mock report, not a result from a customer website.

Try the instant website checker

Enter a public domain in our free online cookie and tracking checker for a homepage source check. No installation or sign-up is required. Use the results as pointers for browser testing, as explained below.

Once you have confirmed your technology inventory, use the UK cookie policy generator to prepare a draft and declaration. Browse all free tools →

What does our WordPress scanner check?

CookieBanner Check reviews public homepage signals: consent wording and controls, policy links, common tracking technologies and possible Consent Mode indicators. It gives website owners a starting list of items to investigate.

It does not inspect private plugin or tag-manager settings, test every page or prove that all cookies and pixels are blocked before consent. Its visible-signal score is not a legal compliance certificate. See the plugin’s scope and limitations before interpreting a result.

Signal

A tool or control appears in the scan.

Question

What does it do in this visitor journey?

Evidence

A documented test supports the finding.

Five conclusions a result does not justify

1. “A banner was found, so the setup works”

The presence of wording is only the first part of the journey. The next questions are whether controls are usable, choices persist and the intended behaviour follows. Keep a screenshot of the interface and a separate record of the technical checks.

2. “No signal was found, so nothing is installed”

A tool can be absent from the scanned page but present on a landing page, embedded form or checkout. It might also load after an interaction that was outside the scan’s scope. Treat absence as “not detected in this test”, then compare the result with your own inventory.

3. “A tracking script was found, so it must be breaking the rules”

A script reference does not establish its execution, the information it accesses or when it sends data. Ask your developer to identify the purpose and inspect the relevant visitor states. Record an unresolved question when the evidence is incomplete instead of attaching an accusation to a domain name.

4. “A policy link was found, so the policy is accurate”

Open the page and compare its descriptions with the actual setup. Check the named technologies, purposes and routes for changing preferences. A working link is useful; an outdated list of tools still needs attention.

5. “The score went up, so the whole website improved”

Before comparing scores, check the tool version, page, browser conditions and scoring method. A change in wording might affect detection without changing tag behaviour. Conversely, a technical fix may matter even when a simple visibility score barely changes.

A sample report you can reproduce

Mock report · fictional example.com · no live scan performed

Public homepage review

Scope: Homepage only. Private settings, other pages and visitor-state network tests are outside this example.

  • Observed signal: A cookie-policy link is detected.
    Follow-up: Open it and compare its contents with the tool inventory.
  • Observed signal: A tag-manager reference is detected.
    Follow-up: Identify the tags and test the intended consent behaviour.
  • Unresolved: A route to reopen preferences is not clearly identified.
    Follow-up: Check the footer, keyboard navigation and mobile interface manually.
  • Not tested: Rejection, acceptance, withdrawal and checkout behaviour.
    Follow-up: Agree a separate test plan before making wider claims.

When making your own version, replace the fictional details with actual observations. Add the tested URL, date, tool version, screenshots and an evidence reference for each finding. Keep cookie values, session tokens and personal details out of material you publish or share.

Turn the scan into a manageable action list

  1. Run and record. Keep the original output and identify exactly what was covered.
  2. Check the visible journey. Open each control and policy link on desktop and mobile. Note anything a visitor cannot find or operate.
  3. Verify the behaviour. Use our Reject All testing guide to structure the browser checks. Ask for authorised configuration access where public evidence cannot answer the question.
  4. Assign and retest. Give each item an owner, a next action and a repeatable retest. Close it only when the relevant evidence supports doing so.

The ICO’s guidance covers technologies beyond cookies, including pixels, web storage and fingerprinting. This is another reason to define the scope of a “cookie check” precisely. Read the ICO’s explanation of storage and access technologies.

When is a deeper review useful?

Consider a focused review when findings conflict, a new marketing tool has been added, choices behave differently across templates, or you cannot establish who owns the configuration. Agree the pages, visitor states, evidence and access needed before commissioning work.

Use the free checklist alongside the scanner. For the current UK context, read our September 2026 cookie rules briefing. Our review services explain the different scopes available.

Make sense of your scan

Send your website URL and the finding you want to understand. We can help identify a useful next step.

Request a free initial check

About the author: John Cookie is the pen name of a digital marketer with 20 years’ experience. These articles explain practical website observations and testing methods; they are not legal advice or compliance certification. Read about John and the review approach.


Leave a Reply

Your email address will not be published. Required fields are marked *