A Wix-managed headless project built with Wix's Astro integration loads the same site analytics, tag manager, and consent-policy runtime scripts as a standard Wix site. This article explains the default consent behavior and how to override it before analytics or advertising scripts run.
Note: This applies to headless projects built with the Astro integration. Wix injects these scripts when it builds your project, which doesn't happen for projects built with another web framework.
On a newly created Wix-managed headless site, the default consent policy grants every category, essential, functional, analytics, advertising, and dataToThirdParty, until you configure a different site-level default or a visitor makes a choice.
This is an opt-out default. Analytics and tag manager scripts can run, and set a session cookie, before a visitor interacts with any consent UI. Some regions require opt-in consent before non-essential cookies run, such as under GDPR or Germany's TDDDG. If a site serves visitors there, set a restrictive policy yourself before those scripts trigger, using the steps below.
If you already set a site-level default policy with the Update Consent Policy API, the runtime uses that configured default instead of the all-granted policy shown above.
The runtime exposes a consentPolicyManager object on window:
window.consentPolicyManager.getCurrentConsentPolicy(): returns the active policy as { defaultPolicy, policy: { essential, functional, analytics, advertising, dataToThirdParty }, createdDate }. defaultPolicy is true until a policy has been explicitly set for this visitor.window.consentPolicyManager.setConsentPolicy(policy, successCallback, errorCallback): persists a policy for the current visitor. The runtime always forces essential to true. The callback parameters are optional. Setting a category changes only that category, and omitted categories keep their current value.Note: This is the same object documented as the Consent Policy Manager API in the @wix/site package. It also exposes resetConsentPolicy() to revert to the site default and onConsentPolicyChanged() to react to later policy changes. Use window.consentPolicyManager directly only for the early inline script in the steps below, which must run before your bundle loads. Use the @wix/site import everywhere else.
Call setConsentPolicy() with the categories you want to deny:
A script that Wix injects with defer sets up consentPolicyManager, so it isn't guaranteed to exist yet when your own script runs. For example, an inline script you add to your layout's <head> might run first. Rather than polling for it, check for it once and otherwise listen for the consentPolicyManagerReady event, which the runtime dispatches on window the moment the manager becomes available:
<head>Add the helper from step 1 and the check from step 2 as an inline script in your layout, such as src/layouts/Layout.astro, so it runs before the visitor sees any content:
Note: setConsentPolicy() only changes the policy stored for the current visitor going forward. It doesn't undo cookies already set by scripts that already ran. Run it as early as possible, before any tracking script has a chance to execute. setConsentPolicy() itself persists the policy through a network request rather than setting it synchronously, so on a slow connection it's possible for the runtime's very first tracking call on that same page load to still see the prior policy. The setConsentPolicy() reference also notes that policy changes take effect only after the visitor refreshes the page. If a site needs certainty from the first pageview on, set a restrictive policy at the site level with the Update Consent Policy API instead of relying only on this early-script override.
Last updated: 12 August 2026