WPIntell

Source evidence

Cookies added via Javascript

FAZ Cookie Manager · support · 2026-07-02T08:48:00+00:00

complaintsentiment
highseverity
0.91relevance
1replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

4 / 34 rows with source links

11.8% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

30 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
concept4uk unresolved
We use plugins like CleanTalk which adds the cookie after page load via javascript. Is the only way for us to manually add the cookies per site? The scanner doesn’t seem to find these cookies. This topic was modified 3 days, 2 hours ago by concept4uk . Hi concept4uk , you have run into a genuine limitation that affects every scanner-based cookie tool, not just this one. A scan loads your pages and reads the cookies that are present at that moment, but cookies that a script writes later – after the page has loaded, or only when a form is focused or a specific event fires, which is exactly how CleanTalk sets its anti-spam cookies – are usually not there while the scan runs, so they are not captured. There is no reliable way to force every possible runtime cookie to appear during a crawl. The good news is that you do not have to research them by hand. CleanTalk’s cookies (the apbct_* and ct_* families) are already in the plugin’s built-in cookie database, so when you add them on the Cookies page the plugin recognises the name and purpose for you. More importantly, CleanTalk is an anti-spam / security tool, so its cookies are strictly necessary – they exist to protect the site from spam and abuse. Under the GDPR and the ePrivacy rules, strictly necessary cookies are exempt from consent: you do not have to block them or place them behind the banner, you only have to declare them for transparency. So the right thing to do is to add them under the Necessary category. Because they are Necessary there is no blocking involved and no risk of breaking CleanTalk’s protection. So to answer your question directly: yes, for the handful of cookies the scanner cannot see, adding them manually is the intended approach – but it is a small, one-time task, and since they are Necessary there is no consent or blocking complexity around them. Running the scan once while logged out and briefly interacting with a page that has a comment or contact form may surface a few more, but JavaScript-injected security cookies will generally still need to be added by hand. If you tell me the exact cookie names you see in your browser for CleanTalk, I am happy to confirm the right category for each.

Comments

1 shown
fabiodalez 2026-07-02T09:22:00+00:00

Hi concept4uk , you have run into a genuine limitation that affects every scanner-based cookie tool, not just this one. A scan loads your pages and reads the cookies that are present at that moment, but cookies that a script writes later – after the page has loaded, or only when a form is focused or a specific event fires, which is exactly how CleanTalk sets its anti-spam cookies – are usually not there while the scan runs, so they are not captured. There is no reliable way to force every possible runtime cookie to appear during a crawl. The good news is that you do not have to research them by hand. CleanTalk’s cookies (the apbct_* and ct_* families) are already in the plugin’s built-in cookie database, so when you add them on the Cookies page the plugin recognises the name and purpose for you. More importantly, CleanTalk is an anti-spam / security tool, so its cookies are strictly necessary – they exist to protect the site from spam and abuse. Under the GDPR and the ePrivacy rules, strictly necessary cookies are exempt from consent: you do not have to block them or place them behind the banner, you only have to declare them for transparency. So the right thing to do is to add them under the Necessary category. Because they are Necessary there is no blocking involved and no risk of breaking CleanTalk’s protection. So to answer your question directly: yes, for the handful of cookies the scanner cannot see, adding them manually is the intended approach – but it is a small, one-time task, and since they are Necessary there is no consent or blocking complexity around them. Running the scan once while logged out and briefly interacting with a page that has a comment or contact form may surface a few more, but JavaScript-injected security cookies will generally still need to be added by hand. If you tell me the exact cookie names you see in your browser for CleanTalk, I am happy to confirm the right category for each.