Banner sem opção de recusar: o que a auditoria LGPD acusa e como corrigir

Quando a auditoria do Sentinela chega na camada LGPD, ela faz o que um fiscal faria: entra no seu site como um visitante que acabou de chegar, sem aceitar nada, e anota o que aconteceu. Que scripts de terceiros carregaram? Que cookies foram gravados? Existe um banner? Ele deixa recusar?

O resultado sai como achados no relatório, cada um com severidade. Este texto explica os seis que tratam de consentimento, o que cada um significa e como corrigir.

Se você ainda não sabe o que um banner precisa ter, comece pelo texto anterior da série.

Como a verificação funciona

A probe LGPD pede a home do site como um visitante novo: sem cookies, sem nenhum clique. Na resposta, ela procura:

• trackers conhecidos — Google Analytics, Google Ads, Meta Pixel, TikTok, LinkedIn, Hotjar e afins — pelo script carregado e pelos cookies gravados;
• um banner de consentimento, pela assinatura das plataformas conhecidas e por marcações comuns de banner próprio;
• a opção de recusar dentro do banner.

Tudo isso é observação externa: a auditoria não entra no seu servidor nem no painel da sua ferramenta de consentimento. É exatamente por isso que ela é útil — ela vê o que o visitante vê.

Os achados, um por um

Cookies ou scripts de rastreamento sem banner

O que diz: o site gravou cookies de rastreamento, ou carregou scripts de análise e publicidade, na primeira requisição, e nenhum banner de consentimento foi encontrado.

Por que é grave: é tratamento de dado pessoal para análise ou publicidade sem consentimento algum. Não há o que discutir sobre a qualidade do banner, porque ele não existe.

Como corrigir: instalar um banner que bloqueie os scripts até o aceite. Instalar só o aviso não resolve: o achado volta como o próximo da lista.

Scripts de rastreamento detectados (com banner)

O que diz: existe banner, e existem trackers na página. Pela observação externa não dá para afirmar se eles esperam o aceite.

Como conferir: numa janela anônima, abra o DevTools na aba Network antes de qualquer clique. Se os domínios dos trackers aparecem ali, eles não esperam. Recuse, recarregue e confira de novo — eles precisam continuar fora.

Banner de consentimento não detectado

O que diz: não encontramos nenhum banner conhecido. Pode ser ausência real ou um banner próprio que não reconhecemos.

Como corrigir: se o banner existe e é feito em casa, uma classe reconhecível no container (por exemplo cookie-consent) já ajuda. Se não existe, este é o primeiro passo.

Banner sem opção visível de recusar

O que diz: encontramos o banner, mas nenhum botão ou link de "Rejeitar", "Recusar" ou equivalente. É o banner "aceite ou nada".

Por que é grave: consentimento sem alternativa não é livre (LGPD, art. 8º, §4º), e o guia de cookies da ANPD pede a recusa na primeira camada. É um achado alto, e pesa na conformidade com LGPD e GDPR no relatório.

Como corrigir: pôr "Recusar" (ou "Apenas necessários") na primeira tela do banner, com o mesmo destaque visual do "Aceitar" — mesmo preenchimento, tamanho e contraste. Um link cinza no rodapé do banner não basta.

Opção de recusa não verificável de fora

O que diz: o banner existe, mas é montado em shadow DOM — uma área da página isolada do HTML principal, que algumas plataformas usam para o estilo do site não quebrar o banner. Os botões não aparecem no HTML servido, então não dá para confirmar nem negar que a recusa exista.

Por que é só informativo: afirmar "seu banner não deixa recusar" sem ver os botões seria inventar. O achado diz o que não conseguimos ver e pede que você confira no painel da sua ferramenta. Ele não desconta nota.

Como resolver de vez: depende da plataforma. Se ela expõe a configuração do banner publicamente, a auditoria pode lê-la em vez de adivinhar — e é o que fazemos com a Cokei, como explicamos abaixo.

O caso da Cokei: recusa verificada pela configuração

A Cokei, a plataforma de consentimento da M2HP, desenha o banner em shadow DOM. Por isso, até outubro de 2026, todo site com Cokei recebia o achado "não verificável".

Hoje a auditoria reconhece o script da Cokei na página, lê a configuração pública daquele banner e confere se a recusa está ligada. São três desfechos possíveis:

• recusa ligada: nenhum achado de recusa;
• recusa desligada: o achado alto de "banner sem opção de recusar", com a configuração citada como evidência;
• não conseguimos ler a configuração: volta o achado informativo, sem chute em nenhuma direção.

Na prática, o primeiro é o único que acontece hoje: nos modos LGPD e GDPR, a Cokei força o "Recusar todos" na primeira camada, com a mesma classe visual do "Aceitar", e não oferece botão para desligá-lo. Quando essa regra entrou, os banners que estavam com a recusa desligada tiveram a versão incrementada — e os visitantes foram perguntados de novo, porque consentimento colhido sem opção de recusar não vale.

Uma coisa que a configuração não nos diz é se o botão de recusar parece tão importante quanto o de aceitar na tela do seu site. Na Cokei isso é garantido pelo próprio desenho do banner; em outra plataforma, vale conferir com os próprios olhos.

Corrigir na ordem certa

Se o seu relatório trouxe vários desses achados, a ordem que mais reduz risco por hora de trabalho é:

1. Bloquear os trackers até o aceite. É o que transforma o banner de aviso em controle.
2. Pôr a recusa na primeira camada, com o mesmo peso.
3. Dar um caminho de volta — link ou botão permanente para reabrir as preferências.
4. Registrar as escolhas com data e versão do banner.

A Cokei cobre os quatro: faz a varredura dos cookies, segura os scripts que dependem de consentimento, registra cada decisão e mantém o botão "Gerenciar cookies" no canto da página. Se a sua operação usa Google Ads ou GA4, configure também o Consent Mode v2 — é o que impede o Google de perder as conversões de quem recusou.

Depois de corrigir, rode a auditoria de novo. O achado só sai do relatório quando a correção é observada na execução seguinte; até lá ele continua ali, porque ausência de achado só vale quando foi medida.