O que o banner de consentimento de cookies integrado do Wix realmente faz

O Wix Cookie Consent Banner — disponível para cada site Wix em Settings, Privacy & Compliance — é uma das ferramentas de consentimento nativas mais capazes que qualquer plataforma hospedada fornece. Ele suporta opt-in por categoria nas categorias Essential, Functional, Analytics e Advertising, pode ser configurado para exigir ação afirmativa explícita, suporta conteúdo multilíngue através da camada de tradução do site e integra-se nativamente com a política de consentimento que as próprias Marketing Apps do Wix respeitam. Quando o operador configura o banner para exigir consentimento e ativa os controles por categoria, as integrações nativas do Wix — Wix Analytics, a integração do Facebook Pixel, a integração do Google Ads, a integração do Google Tag Manager, a integração do Hotjar — respeitam a escolha do usuário sem fiação adicional.

O que o banner não faz, e onde ocorre a falha de conformidade mais comum, é bloquear scripts de terceiros que o operador adicionou através da função Custom Code do Wix, código Velo ou widgets HTML incorporados. O banner registra a escolha do usuário; o trabalho do operador é ler essa escolha da política de consentimento e executar condicionalmente a lógica de terceiros que vive fora da lista de integrações gerenciadas do Wix. O padrão funciona uma vez que está em vigor, mas não é automático.

A configuração padrão não é suficiente

A configuração padrão do banner quando o operador o ativa pela primeira vez é consentimento implícito — visitar o site é tratado como consentimento até que o visitante recuse. Essa postura tem sido a fonte de descobertas regulatórias repetidas contra sites hospedados pelo Wix em todo o EEA, UK e nos regimes que se alinharam com o GDPR. O operador deve alterar a configuração para exigir consentimento afirmativo explícito antes de cookies não essenciais serem definidos, deve definir as alternâncias por categoria como off por padrão, e deve verificar que a opção de rejeitar é pelo menos tão proeminente quanto a opção de aceitar na UI do banner. Essas três configurações — consentimento explícito, padrão desativado, rejeitar proeminente — são o mínimo que um site Wix precisa para atingir o limite estabelecido pelo EDPB em suas diretrizes de banner de cookies de 2023 e reafirmado nas prioridades do grupo de trabalho de 2026.

Como o Wix lida com o consentimento sob o capô

O Wix expõe o estado de consentimento do visitante através de um objeto de política de consentimento que as integrações internas da plataforma leem e que o código do operador pode ler através da plataforma de desenvolvimento Velo. A API Velo expõe a política de consentimento sob wixWindow.consentPolicy no front-end e o módulo equivalente no back-end. A política de consentimento retorna um objeto estruturado com sinalizadores booleanos por categoria e um timestamp; o código Velo ou Custom Code do operador lê esses sinalizadores antes de inicializar qualquer lógica de terceiros não essencial.

As categorias de consentimento que o Wix expõe mapeiam para a taxonomia padrão. Essential cobre cookies de sessão, carrinho, segurança e balanceamento de carga e não requer consentimento. Functional cobre preferências, listas visualizadas recentemente e armazenamento similar não essencial, mas não rastreador. Analytics cobre Wix Analytics, Google Analytics 4, Microsoft Clarity e ferramentas de medição similares. Advertising cobre Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight e o inventário de pixels de marketing mais amplo. As Wix Marketing Apps nativas bloqueiam nessas categorias automaticamente; tudo que o operador adiciona precisa ser bloqueado manualmente.

O padrão de integração para incorporações de terceiros e Custom Code

O padrão que funciona no Wix tem quatro partes. Primeiro, configure o Cookie Consent Banner integrado para exigir consentimento explícito, defina as alternâncias por categoria como desativadas por padrão e garanta que a opção de rejeitar seja pelo menos tão proeminente quanto aceitar. Segundo, identifique cada script de terceiros que o site adiciona fora da lista de integrações nativas do Wix — tipicamente estes estão em Settings, Custom Code, em módulos de código Velo, ou em widgets HTML incorporados — e faça um inventário de qual categoria de consentimento cada um se enquadra. Terceiro, envolva cada script de terceiros em uma verificação de consentimento que lê a política de consentimento antes de executar. Quarto, garanta que o aviso de privacidade exibido pelo banner reflita os destinatários de terceiros reais, não a linguagem genérica do modelo Wix.

• Custom Code em Settings — os operadores comumente adicionam Google Tag Manager, Facebook Pixels adicionais, tags de conversão adicionais do Google Ads, snippets do Hotjar e scripts de rastreamento de chamadas via Custom Code. Cada um destes deve ser configurado com a configuração de Consent Mode apropriada na UI do Custom Code — o Wix expõe a seleção de categoria de consentimento no nível de snippet — para que o snippet só carregue quando a categoria relevante for concedida.
• Código Velo — o código Velo de back-end e front-end pode ler wixWindow.consentPolicy e fazer fan-out condicionalmente para APIs de terceiros. Qualquer módulo Velo que chame um endpoint de terceiros para registrar eventos, disparar pixels ou sincronizar dados para um CRM deve verificar a categoria relevante antes de executar.
• Widgets HTML incorporados — iframes HTML incorporados de terceiros (widgets de chat, widgets de calendário, incorporações sociais) normalmente carregam seus próprios scripts que definem seus próprios cookies. O padrão é renderizar o iframe dentro de um wrapper controlado pelo Velo que insere condicionalmente o elemento iframe apenas após a porta relevante ter sido concedida.
• Sites Wix Studio — o Wix Studio herda o mesmo mecanismo de política de consentimento, mas adiciona recursos de design responsivo e modo desenvolvedor que tornam o bloqueio de consentimento no estilo Velo mais fácil de manter. O padrão de integração é idêntico; a ergonomia de manutenção é melhor.

As armadilhas de conformidade específicas do Wix

Três padrões se repetem nas implantações Wix e são responsáveis pela maior parte dos problemas sinalizados por reguladores. O primeiro é o contêiner Google Tag Manager de terceiros gerenciado pelo operador — o operador instala o GTM via Custom Code, depois adiciona dezenas de tags através da UI do GTM sem configurar o Consent Mode v2 dentro do próprio GTM. O banner do Wix bloqueia corretamente o carregador GTM, mas depois que o GTM é carregado, as tags dentro disparam sem verificações de consentimento adicionais a menos que o GTM tenha sido configurado para respeitar o Consent Mode. A correção é ativar o Consent Mode v2 no contêiner GTM e conectar o gatilho de cada tag ao sinal de consentimento apropriado.

O segundo é o provedor de formulário incorporado — Typeform, JotForm, Calendly e similares — que carrega seus próprios cookies para fins analíticos e de pré-preenchimento. O banner do Wix não bloqueia o widget incorporado por padrão; o operador deve bloquear o próprio elemento widget via Velo ou usar o padrão de marcador de posição click-to-load que adia o carregamento do iframe até que o usuário interaja com ele.

O terceiro é a divulgação de transferência transfronteiriça. A infraestrutura de hospedagem do Wix funciona em regiões incluindo os Estados Unidos, e muitos dos destinatários de terceiros do operador operam em outros lugares; o modelo de aviso de privacidade que o Wix fornece não nomeia essas jurisdições especificamente, e o operador deve editar o aviso para nomear cada região de destinatário. As orientações do EDPB de 2023 foram explícitas de que a linguagem genérica de dados processados por prestadores de serviços não é suficiente, e o mesmo padrão se aplica a sites hospedados pelo Wix.

Validação e postura de auditoria para 2026

Uma implantação Wix defensável em 2026 deve passar em quatro verificações técnicas. Primeiro, uma sessão de navegador limpa servida a partir de um endereço IP do EEA deve produzir zero cookies não essenciais antes que o banner tenha sido ativado — não apenas zero cookies gerenciados pelo Wix, mas zero cookies de cada snippet Custom Code, módulo Velo e widget incorporado. Segundo, o caminho de rejeição deve manter esse estado. Terceiro, o caminho de aceitação deve produzir apenas as tags com as quais o usuário consentiu, e o log de consentimento do Wix junto com qualquer log do lado do operador deve conter o registro correspondente. Quarto, uma retirada deve imediatamente parar disparos de tags adicionais, expirar os cookies definidos durante a sessão consentida, e propagar o opt-out para quaisquer destinatários de terceiros downstream que mantenham seu próprio estado.

A expectativa de trilha de auditoria é onde o Wix está melhorando, mas ainda requer esforço do operador. A plataforma registra decisões de consentimento em seu próprio log acessível ao proprietário do site, o que é suficiente para muitas consultas regulatórias. Para implantações que precisam de uma trilha de auditoria mais completa — versão do banner, estado da categoria, versão do idioma e estado do destinatário downstream — o operador deve adicionar código Velo que escreve eventos de consentimento em um armazenamento externo consultável. Um site Wix que configurou corretamente o banner integrado, bloqueou cada caminho Custom Code e Velo, editou o aviso de privacidade para nomear cada destinatário transfronteiriço e adicionou o log de trilha de auditoria é um site Wix que transformou a simplicidade do criador hospedado da plataforma de um passivo de conformidade em uma parte defensável da postura de consentimento de um editor.