Installation & integrations
Install Cookie once, connect Google and SiteOS services, and verify that scripts follow visitor choices.
Publish the reviewed Cookie configuration first, then copy the installation details for the selected project environment. The generated loader URL is specific to that setup. Do not reuse a production snippet in a test environment.
Install once
Choose one method: the website script for HTML/React or Next.js, the SiteOS Cookie template for Google Tag Manager, or a GTM Custom HTML tag. Avoid installing the loader both directly and through GTM. The normal external loader remains stable across configuration publications; you do not need to replace it for each banner edit.
The installation screen can provide a recovery-capable snippet for stricter loading requirements. It replaces the standard snippet; do not install both variants.
If you turn on US privacy signals (IAB GPP), the website snippet starts with a small GPP stub. Keep it before your advertising tags. With Google Tag Manager, add the stub to your page head outside the container.
For Google Tag Manager, import the SiteOS Cookie template provided by the installation flow. Configure it on Consent Initialization so denied defaults are available before the tags that depend on them. Preview the container and verify the live website after publishing the relevant changes.
Connect real services
The service catalog is an inventory and disclosure layer. Picking a preset does not install provider code. Unless you turn on automatic blocking, it does not stop scripts elsewhere on your page either.
For each optional service, identify how it loads: a website script, a framework integration or a tag-manager tag. Connect the appropriate consent control and check for duplicate installations.
For custom code, gate each service by its key from the catalog. SiteOSCookie.getServicePermission("service-key") returns the current permission, and SiteOSCookie.subscribeToServicePermission reports later changes. Unknown services, pending configuration and runtime failures never grant permission.
When a visitor withdraws consent, Cookie stops Meta Pixel, TikTok Pixel, Microsoft Clarity, Microsoft Advertising, HubSpot tracking, PostHog and Mixpanel through their own consent controls, without reloading the page, and resumes them after a new grant. It also removes their known first-party cookies, including cookies set on a parent domain. Other running scripts, such as LinkedIn Insight or Hotjar, need a controlled reload after withdrawal.
Withdrawal also deletes the first-party cookies and browser storage that rows in Cookies link to the withdrawn service, including your custom services. Link the rows, then publish again; correcting them later does not ask visitors to choose again. Third-party cookies and IndexedDB data stay, because the page cannot remove them.
Automatic blocking
With the website script, you can turn on Block known services automatically in Installation and publish. The snippet then loads the blocking loader. Place it first in <head>, before other scripts.
Scripts, iframes and pixels of the services you selected in Services then load only after the visitor allows that service. You do not need to edit their tags. Google tags are matched by measurement ID, so a Google Tag Manager container is never blocked. Advanced Consent Mode keeps Google tags loading with denied signals.
Automatic blocking covers resources from the catalogued services you selected, from vendors you confirmed in the cookie inventory, using the request domains the scan found, and from the Domains to block of your custom services. Enter cdn.example.com for one host or *.example.com for a domain and all its subdomains. Services you add from the search in Add service arrive with suggested domains to review; a domain that covers a whole company's websites, such as *.microsoft.com, is left for you to decide. After you change domains, publish again; visitors keep their choice. Inline code, requests made by scripts that are already running, server-side tags and unknown vendors are not blocked. Mark a resource with data-siteos-cookie-ignore to keep it outside automatic blocking. Turning the setting off and publishing again restores the standard loader without changing your website.
Automatic blocking is not available through Google Tag Manager, because the container loads too late to stop other scripts. For GTM installations, Installation lists a consent trigger for each selected service. Google tags in Basic Consent Mode fire on their grant event. Other tags use a Data Layer Variable for the service's permission and a Custom Event trigger on siteos_service_permissions.
Google Consent Mode
SiteOS supports Google Consent Mode v2 signals, including analytics storage, advertising storage, advertising user data and advertising personalization. The Google tags themselves still need to be installed and configured.
Choose the collection behavior deliberately. Basic mode holds relevant tags until consent; Advanced mode can allow consent-denied pings before a choice. Consent Mode does not by itself prove that every tag or script on the page is controlled, and it is separate from Google-certified CMP status.
When configuring withdrawal, include the relevant Google integration details so the supported cleanup can run. Verify both consent updates and any reload needed by your actual installation.
SiteOS Analytics and Search
To connect Analytics, both services must be enabled in the same project environment. In Cookie → Services → SiteOS Analytics, enable Control Analytics details with Cookie, review the draft and publish it. Analytics also needs its own script and collection settings.
This connection is off by default. Detailed collection follows the resolved Cookie policy; any separately enabled basic page counter has its own rules. Returning-browser recognition and People are separate permissions, not something a generic analytics choice automatically enables. See Analytics measurement and consent.
Search analytics also has separate collection settings. Select its consent-required mode when search activity should follow Cookie’s analytics choice.
Cookie declaration
A cookie declaration is a public table of the cookies and storage your website uses. Edit it in Cookies, where confirmed scan results can be added as rows. Publishing declaration changes does not ask visitors to choose again.
To show the table, add a placeholder with your public key where it should appear, such as your cookie or privacy policy page, and load the declaration script from the same origin as the loader. Privacy page table in Cookies provides the exact snippet. The table follows the page language and includes a button that reopens cookie settings.
Verify before calling setup complete
Test a fresh visit, acceptance, rejection, changing preferences and withdrawal followed by a reload. Check each configured region and any shared subdomains. Inspect requests and storage as well as the visible banner.
Installation also lists Manual checks that SiteOS cannot verify from your website, such as the GTM order in Tag Assistant, a review of Advanced consent mode and testing your custom services after refusal and withdrawal. Select Mark as checked after checking each one; changing the settings it covers asks again. Confirming is saved with the draft and is not a change to publish.
Scans and reports explain local verification, saved findings and consent evidence.