Scan Website for GDPR Cookies and Trackers: A Practical Guide

A website scan can show which cookies and third-party trackers a browser detects, and whether they appear before a visitor makes a consent choice. Use the results as a technical snapshot to investigate—not as proof that your site is or is not GDPR-compliant.

Key takeaways

• Scan more than the homepage: pages, embedded tools and visitor choices can change what loads.
• Check what happens before consent, after acceptance and after rejection.
• Match each detected cookie or connection to its purpose, provider and consent configuration.
• A scanner can find clues, but it cannot decide every legal question or verify every visitor experience.
• Record findings, fix the underlying setup and scan again to confirm what changed.

What a website scan can tell you about cookies and trackers

A cookie and tracker scan visits a web page in a browser-like environment and records technical activity it can observe. Depending on the tool, this may include cookies stored in the browser, requests to third-party domains, tracking technologies and how a consent banner behaves during the test.

That makes scanning useful for a first check. It can help answer practical questions: Are third-party services loading? Which pages should we investigate? Does a tracking request appear before the visitor interacts with the banner? Does the page behave differently after a choice?

A scan has limits. It usually reflects a particular set of pages, browser conditions, settings and test actions. It may miss activity that appears only after scrolling, logging in, using a form, accepting a particular option or visiting from a specific location. A list of detected cookies also does not explain their full purpose or establish the legal basis for processing.

The European Data Protection Board (EDPB) describes its website-auditing tool as an aid for organisations and auditors, not an automatic legal verdict. The same approach is sensible for any scanner: use its findings to guide investigation and remediation.

How to scan website for gdpr cookies and trackers

Start with a clean browser session and a representative page. If you use an online URL scanner, enter the public page address and read the tool’s scope before treating the output as complete. Find out whether it checks just one URL or follows links, which actions it performs, and whether it tests consent choices.

1. Choose pages that reflect real visitor journeys

Include the homepage, contact or enquiry page, service or product pages, and any page with embedded video, maps, chat, booking, analytics or advertising tools. If your site has a checkout, account area or newsletter signup, consider those separately; some may not be accessible to a public scanner.

Do not assume that one homepage result represents the whole site. Different templates may load different plugins or third-party services. A site with a small number of pages can still have varied tracking behaviour.

2. Test consent states, not just the first visit

Where the scanner allows it, compare at least these states:

Test state	What to look for
Before making a choice	Cookies and third-party requests that appear on initial load
Accept all	Which additional services load after acceptance
Reject or decline	Whether optional tracking still appears to run
Change or withdraw a choice	Whether settings can be revisited and whether behaviour changes

If the tool does not simulate these actions, perform a manual browser check as well. A banner visible on screen does not prove that every optional script waits for a choice. Research on cookie notices has identified pre-interaction tracking, choices that are not respected and hard-to-find refusal options as behaviours worth assessing. The Cookiescanner research paper also notes that automated detection of decline options can be difficult because websites are dynamic.

3. Save the evidence

Record the page, date, browser or scanner used, consent state and relevant findings. Screenshots and a list of domains can help a developer reproduce an issue. If a scan shows a result you cannot explain, repeat the test before drawing a conclusion: a service may load conditionally, or the scanner may not have interacted with the page as a person would.

For a broader starting point, KlearKomply’s free Quick Scan checks up to 10 pages. The €29 Full Readiness Scan checks up to 50 pages. Use either as an initial review of website readiness, then verify important cookie and consent behaviour directly on your site.

How to read cookies, trackers and third-party requests

A scan report may show a cookie name, domain, duration, or the page where it was observed. It may also list requests to outside services. These details are clues, not a complete explanation: names can be opaque, and a third-party request does not by itself tell you what data was sent or why.

For each finding, work through a short investigation:

1. Identify the owner. Is the domain yours, a plugin provider, an analytics service, an advertising platform or another supplier?
2. Find the component that loads it. Check your tag manager, consent platform, theme, plugins and embedded content. Ask your developer or supplier if the source is unclear.
3. Confirm the purpose. Compare the observed service with the purpose described in your consent interface and privacy information. Do not label a cookie “necessary” simply because a plugin uses it.
4. Check the relevant configuration. Confirm whether the service should run before a choice, only after a relevant choice, or not at all on that page. The correct treatment depends on the technology and its purpose.
5. Test the change. Clear the browser state, repeat the same steps and compare the results.

The EDPB explains that the GDPR may apply when cookies process personal data, while the ePrivacy Directive has specific rules about cookies. Its FAQ describes information and consent requirements for storing or accessing information on users’ devices. A technical scan cannot establish all the facts needed to apply those rules to your particular setup.

A useful handoff to a developer is specific: “On the contact page, the test recorded a request to this domain before a choice. Please identify the script responsible and confirm whether it can be held until the relevant consent.” That is more actionable than “the scan says cookies are bad.”

Does a consent banner block tracking before consent?

The practical question is not only whether a banner appears. Check whether optional services are prevented from loading until the visitor has made the relevant choice, and whether a refusal is respected. Also check what happens if someone changes their settings later.

Common patterns to investigate

• A banner appears, but a tag manager or plugin has already started an optional service.
• “Reject” is available, but the resulting browser activity looks the same as before the choice.
• The banner records a preference, while a separate embedded service still loads directly.
• A service is described under one purpose in the banner but appears to be used for another.
• A banner is configured on one page template but missing from a landing page or campaign page.

These are investigation prompts, not automatic legal conclusions. Confirm the actual setup, the visitor’s options and the purpose of each service. The presence of a consent notice alone does not establish compliance; the research cited above highlights why the behaviour behind the notice matters.

When results are inconsistent, check the consent platform’s configuration and the order in which scripts load. Then repeat the test in a clean session, using the same page and sequence of actions. Keep a note of the exact steps so that you or your developer can reproduce the result.

What to fix after a scan—and what not to assume

Prioritise findings by visitor impact and how clearly you can reproduce them. A practical order is:

1. Investigate unexpected tracking before a visitor has made a choice.
2. Check that the reject option is visible and that the site responds to it as intended.
3. Remove services you no longer use, including old tags and duplicate plugins.
4. Correct consent categories, script blocking or embedded-content settings where needed.
5. Make sure your privacy and cookie information accurately describes the services that remain.
6. Retest affected pages in each relevant consent state and keep a record of the outcome.

Avoid deleting a cookie solely because its name looks unfamiliar. First identify its source and function; removing a needed service can break site features. Equally, do not assume that a cookie is harmless just because it has a short lifetime or comes from a familiar plugin. Understand what is running and why before changing the setup.

Do not treat a scanner score as a legal certificate. Automated tools can miss dynamic behaviour, fail to recognise a consent control or report a technical detail without enough context to interpret it. The EDPB’s free, open-source auditing tool supports audit workflows such as tracker evaluation and report preparation, but its purpose is to assist analysis. For background, see the EDPB tool information. For an example of a scanner’s own limitations, TrustYourWebsite’s tool notes describe automated results as technical analysis rather than formal audit evidence or legal proof.

If your cookie review is part of a wider website project, include accessibility and other readiness checks too. KlearKomply’s guide to an EAA website accessibility scan explains how to treat automated findings as a starting point for practical follow-up.

Common mistakes when scanning a website

Scanning only the homepage. Other page templates can load additional services. Include pages that reflect how visitors actually use the site.

Checking only the cookie list. Third-party requests and what happens after a choice can be just as useful to investigate as stored cookie names.

Accepting the first result as complete. A scanner may not follow links, scroll, submit forms or simulate every consent option. Read its scope and do manual checks where needed.

Assuming a banner equals effective consent handling. Test the behaviour before and after a choice; the notice alone cannot tell you whether scripts follow the intended settings.

Treating every finding as a violation—or ignoring it as a false alarm. Verify the source, purpose and behaviour before deciding what action to take.

Fixing the symptom but not retesting. After changing a tag or banner, repeat the original test and document what changed. A fix is not confirmed until the observed behaviour matches the intended setup.

Turn scan results into a repeatable check

A useful scan is the beginning of a simple maintenance cycle: choose representative pages, test consent states, investigate findings, make targeted changes and repeat the same checks. Keep a short change log with the page, service, action and retest result. Run the process again when you add a plugin, analytics tool, advertising tag or embedded service.

If you want a quick first look, start with the KlearKomply Quick Scan. For a broader page review, the €29 Full Readiness Scan covers up to 50 pages. Neither replaces reviewing your actual consent setup or obtaining legal advice where you need it, but both can help you organise practical next steps. For questions about the service, you can also review KlearKomply’s cookie policy.

The goal is not to collect a perfect-looking score. It is to understand what your site does, make informed changes and verify that the result works for visitors in the situations you tested.