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.
