Why does your scanner find cookies and trackers that I cannot myself find on my website?

The Cookiebot scanner scans for a number of different types of cookies and online trackers from the ‘classical’ http/Javascript cookies to more advanced tracking technology such as pixel tags and ultrasound beacons. This includes both first-party and third-party cookies and trackers.

See also: What kinds of cookies and tracking technologies does the Cookiebot scanner find? 

The Cookiebot scanner has been developed and refined over the past 6 years and that is why it is able to pick up on all these types of cookies and trackers.

How does the scanner find the cookies and trackers?

The Cookiebot scanner crawls your website – typically over 24 hours – to look for all the cookies and tracking technology in use. It simulates a number of regular website users visiting your website. You can think of it as a simulation of say e.g. 7-8 users simultaneously visiting the website and going through all the subpages, clicking all the links, menu points and buttons, playing embedded videos and taking all the actions possible – in other words doing everything that it is possible for a website visitor to do on the website being scanned while at the same time picking up on cookies and trackers in use. The only thing the scanner does not do is fill in forms (like actually subscribing to your newsletter) and paying for goods in a shopping cart (if you have a webshop, the scanner will put items in the shopping cart but will not actually proceed and pay for those items). The results are presented in the scan report.

If the scanner is simulating a regular website user then why can’t I see the same cookies in my browser?

The browsers of today are simply not advanced enough to see all the cookies and trackers being set.

Also, there is a difference between what cookies for example Safari and Chrome are able to see. So, if you look for cookies listed in the developer console (or similar) on your browser, chances are that you will see different results in different browsers. Also, browsers cannot register the cookies for the *entire* website but only show (some of the) cookies used on the particular page you are currently visiting. At best, if you are checking the cookies via your browser console, you are only seeing a partial picture of the cookies and trackers in use on your website.

It is also important to understand that many cookies are so-called dynamic cookies. These – unlike ‘classical’ http/Javascript cookies – are not being set when the website is loaded. They are being set during the visit depending on the user’s behavior on your website.

Firefox is sometimes able to display some of these cookies if you click around on the webpage, hit ‘refresh’ etc. However, since they are triggered based on (unknown) patterns of behavior it can be very difficult to recreate the behavior so that they are shown in the browser console.

If I want to delete or inspect some of the cookies and trackers listed in your scan report, how can I find them?

As a help for you as a website owner, we have included additional information in the scan report. For each cookie or tracker identified, you will be able to see where on your website it was first found by our scanner (First found URL), what type it is and – where applicable – in what line of the source code the script setting the cookie is located. The source is also indicated (in the example below it is coming from Google Tag Manager (GTM) because implementation has been done via GTM).

A preview of a cookie in the scan report

The scan report is being sent to you by email after each monthly scan is completed and is also available from the menu point ‘Reports’ on your Cookiebot account.

Cookies and trackers are set either a) client side or b) server side:

For client side cookies:

Cookies that are set client side are generally listed in the scan report indicating the line in the source code where it is found. You can then inspect that line of your source code and either remove or mark up the cookie script.

Cookies that are dynamic – as described above – will be identified by the Cookiebot scanner but will not be listed with a corresponding line in the source code. However, the dynamic cookies are being set by one of the other scripts setting regular/static cookies. Therefore, if you make sure to mark up those cookies that have an indication of the line in the source code, then that marking up will also automatically control the dynamic scripts that are generated based on a static cookie.

If you cannot locate a cookie based on the information in the scan report, as a last resort you can right click on your website and choose ‘inspect’ – then search for the name of the cookie or the provider to see if you can locate it. This will not work for dynamic cookies, however.

For server side cookies:

Most of the server side cookies being set are ‘strictly necessary’. In the context of Cookiebot, they can therefore be ignored and do not need to be handled further.

If you have a server side cookie which the scan report lists as ‘statistics’ ‘preferences’ or ‘marketing’, then you need to take action.

On the scan report, the cookie will likely be listed as ‘Initiator: Webserver’.

A cookie of this type cannot be marked up following the usual procedure (step 3 of our 3-step installation guide). Instead you need to check the user’s current consent state to determine if you can set the cookie or not. This must be handled as described in our developer section – see under ‘KnowledgeBase – Developer’ . Please note that there are 3 separate articles for C#, PHP and VB.

Your scanner finds cookies that are not coming from my website

Sometimes, websites redirect users to other external websites. However, if you have masked this URL so that it appears to the user that the user is still on your website, then the Cookiebot scanner will include these cookies in the scan report in order to provide transparency of the cookies and trackers in use.

An example: On your website are some icons for social media. If the user clicks one of the icons, the user will be taken to the website of the provider of that social media. However, you have masked this in a way so that your own URL is still visible to the user and so the user does not understand that he has in fact navigated to a page outside of your website. The cookies being set – in this case social media related cookies – are included in the scan report.

If you would like for these cookies to not be included in the scan report, then please unmask the URL and make it transparent to the user that the user has navigated to an external page, e.g. a social media website, that is not part of your website.