Cookiebot vs. Kakapo Consent: Service or Plugin?

Cookiebot and Kakapo Consent solve the same task with two different architectures. The difference sounds technical, but it has a very practical consequence: it decides how many processors end up in your privacy policy.

The short answer

Cookiebot is a hosted service with a scanner that crawls your website from the outside, a maintained database of known cookies, and a banner delivered through the service. That's convenient and needs little maintenance.

Kakapo Consent is a plugin: the scan runs inside your own WordPress, the assignments live in your database, and the banner comes from your server. There's no intermediate step through a service.

Where the two differ

The difference that ends up in your privacy policy

A consent tool sees every visitor — after all, it has to know whether consent has already been given. If it runs as a service, that service is an additional processor: it belongs in the record of processing activities and in the privacy policy.

That's not an argument against a service — it's just one more line that has to be accurate. If you want to avoid that line, you need the architecture where nothing leaves the building.

A common mistake with both architectures: the consent tool itself gets left out of the cookie overview. It sets a cookie — that has to be listed, even if it's necessary.

The scanner: outside or inside

An external scanner opens pages the way a visitor does. That reliably finds what loads publicly — and misses anything that only appears when logged in, in the cart, or after a form is submitted.

A scanner inside WordPress knows the content, but it too can only see what appears on the pages it checks. Both architectures have the same blind spot; Kakapo Consent names it in the result message instead of suggesting completeness.

When Cookiebot is the better choice

• You don't want to deal with anything and accept an additional processor
• You look after websites outside WordPress and want one tool for all of them
• You need a maintained cookie database without doing the assignments yourself

When Kakapo Consent is the better choice

• You don't want an additional processor
• You want the consent text to describe your own website instead of a generic one
• You want to keep the proof on your side, not with a service
• You already use other Kakapo plugins

What a banner alone doesn't do

The most common misconception in this area: that installing a banner is the implementation. It isn't. What matters is whether the scripts actually stay silent before consent — and that depends on how they're embedded, not on which banner sits on top of them.

A video that a theme hard-codes into the page starts its connection before the banner has even been rendered. The same goes for a map service in a page builder module. If you don't check this, you have a banner that looks like consent and a page view that has already sent data.

1. Open the page in a fresh private window and do NOT click the banner.
2. Open the developer tools, go to the “Network” tab, and reload.
3. Filter for third-party domains: google, facebook, doubleclick, hotjar, youtube.
4. Whatever appears there before your click is exactly what the banner isn't blocking.
5. Only then is it worth debating the wording of the banner text.

Scanner or maintained list?

Cookiebot is known for its scanner: it regularly goes through your site and reports new cookies. That takes work off your hands and is why the product is widespread among large websites. The price for that is an external service that fetches your pages.

Kakapo Consent takes the other route: a list that you maintain, but without any third-party requests. That's less convenient and the worse choice for a site with fifty embedded services. For a site with five, it's the more honest one — you know what's embedded there anyway, and the list is right in ten minutes.

Frequently asked questions