How to Set Up OneTrust Cookie Consent on Your Website

This is article 2 of the Cookie Compliance series. Article 1 covers the legal map and the stack you need. Here the goal is narrower: get OneTrust Cookie Consent live on a site without guessing which admin screen comes next.

OneTrust’s own Getting Started flow is the spine of this post: scan the website, categorise cookies, create a template, define geolocation rules, assign them to the domain, then publish and implement the scripts. The product UI labels can shift slightly by tenant version, so treat menu names as guidance and confirm against your OneTrust Knowledge Base for your release.

What you need before you start

• Access to a OneTrust Cookie Consent tenant with rights to add websites, edit templates, and publish scripts.
• A staging hostname (or a separate test domain) where you can load the testing CDN without touching production visitors.
• Permission to edit the site <head> (theme, tag manager, or CMS injector) on every page of the domain you will cover.
• A rough inventory of analytics, ads, chat, and experiment tools already in the page. OneTrust will scan, but your team still needs to recognise vendor names.
• Agreement on which regions need prior consent (typically EEA and UK), which need California sale/share opt-out handling if you sell or share, and how you will treat India traffic under DPDP notice and consent principles.

If you have not finished that regional map, pause and read the practical guide first. A CMP cannot invent a lawful model for you.

Step 1: Add the website and run a scan

From Cookie Consent, open Websites and add the domain you want to cover. Point the scanner at the production hostname you will protect, and include the paths or subdomains that actually drop tags (checkout, blog, app subdomain if they share the same consent surface).

OneTrust scanning is meant to find first- and third-party cookies, tags, trackers, pixels, beacons, forms, and storage. You can target specific pages, paths, or subdomains (include, exclude, or prioritise). Use that when a huge site wastes scan budget on unused locales, or when a marketing microsite is the only place ads fire.

After the scan finishes:

• Export or review the cookie list in the product.
• Spot unknowns early (mystery domains, abandoned pixels, duplicate analytics IDs).
• Note cookies that look essential (session, load balancer, CSRF) versus analytics and ads.

Schedule rescans after major releases. OneTrust maintenance guidance expects teams to rescan at a cadence that matches how often marketing adds tags, then compare exports so new cookies get categories and blocking methods.

Step 2: Categorise cookies

Open Categorizations (naming may vary slightly). Cookies matched to Cookiepedia often arrive with a suggested category. Review every suggestion. Wrong categories create wrong preference toggles and wrong Consent Mode mappings.

Common purpose buckets:

• Strictly Necessary: needed to deliver the service the user asked for, including the consent mechanism itself.
• Performance / Analytics: measurement that is not required to render the page.
• Functional / Preferences: remembered UI choices that are not strictly required.
• Targeting / Advertising: ads measurement, retargeting, audience building.

Assign every live cookie to a category that will appear in the Preference Center. OneTrust notes that a category appears in the Preference Center only when at least one cookie is assigned to it, and you must republish when a cookie lands in a category that domain has not used before.

Step 3: Build the banner and preference center template

On the Templates screen, create or clone a template that matches the consent frameworks you need. Pre-configured templates exist for several frameworks; customise copy, colours, and layout to your brand without breaking equal prominence for reject and accept.

For EEA and UK visitors, keep these product choices hard to get wrong:

• First layer shows Accept all, Reject non-essential (or equivalent), and a clear path into finer controls.
• No pre-ticked optional categories.
• Preference Center lists purposes in plain language and links to your privacy or cookie notice.
• A Cookie Settings control remains available after the first choice so withdrawal is as easy as the original grant.

Translate template languages you actually support. When you publish scripts, language detection can follow the browser or the HTML lang attribute; if you rely on HTML language, the template language code must match (for example de with <html lang="de">).

Step 4: Geolocation rules and domain assignment

Create a Geolocation Rules Group that uses your template. Map regions to consent models that match counsel’s instructions. Typical patterns many global sites use:

• EEA / UK: opt-in for non-essential categories; show banner before optional tags fire.
• California (if you sell or share): disclosure plus sale/share opt-out handling; do not assume an EU-style opt-in banner alone satisfies CCPA/CPRA sale/share duties.
• India: DPDP-oriented notice and affirmative consent for optional tracking where personal data is processed; align copy with your privacy notice.
• Other / global default: a conservative default that does not silently grant ads storage for visitors who should have seen a consent prompt.

Assign the geolocation rule group to the domain you scanned. Region rules are where Consent Mode defaults and category mappings often live as well (see Step 7).

Step 5: Publish test scripts and place them on staging

Open Integration > Website scripts, select the domain, and publish the test script first. OneTrust requires publishing the test script before you can publish production, and production publish is time-bounded after the test publish (within about 30 minutes in current docs).

Copy the Testing CDN. Paste it as close to the top of <head> as possible on every staging page, before other scripts that set cookies. OneTrust is explicit: the CDN must load first so the banner can communicate consent preferences downstream.

Key differences from production:

• The testing CDN is not domain-specific, so it works on staging hostnames that differ from the scanned root.
• The testing data-domain-script value is appended with -test.
• Consent cookies written with the testing CDN bind to the host you are on; preferences may not carry across pages the same way production does. Plan tests accordingly.

Also copy the Cookie Settings button snippet if you want a footer or floating control that reopens the Preference Center. The Cookie List snippet is optional for a privacy or cookie policy page.

Step 6: Enable blocking and verify behaviour on staging

By default, implementing OneTrust scripts does not block cookies when consent is missing unless Auto-Blocking is enabled at publish time, or you block tags yourself. That warning appears in OneTrust’s publishing docs for a reason.

Choose a blocking path:

1. OneTrust Auto-Blocking: enable when publishing. It can automatically block or allow cookies based on the geolocation consent model. The first time you enable it, the script tag changes; copy the new scripts onto the site. Test thoroughly on staging. Publishing with auto-blocking takes longer.
2. Tag Manager consent checks: gate GTM tags on OneTrust category groups or on Google Consent Mode states. OneTrust documents OnetrustActiveGroups, OptanonConsent, and the OneTrustGroupsUpdated dataLayer event for triggers.
3. Manual script rewrites: for tags injected outside GTM, use vendor-supported delayed load patterns or OneTrust’s client-side rewrite guidance.

Smoke-test with a clean browser profile (or a clean container):

• On first load in a consent-required region, optional ads and analytics cookies stay unset until Accept.
• Reject non-essential keeps the page usable without marketing cookies.
• Preference Center toggles update behaviour after Confirm.
• Cookie Settings reopens preferences later.
• OptanonAlertBoxClosed appears after interaction so the banner does not loop on every page (production behaviour; confirm staging expectations with the testing CDN).

Step 7: Wire Google Consent Mode v2

If you run Google Ads, GA4, or Floodlight for EEA, UK, or Switzerland traffic, treat Consent Mode v2 as part of the same project. Google’s docs require defaults before tags configure, then updates when the user chooses. v2 adds ad_user_data and ad_personalization beside ad_storage and analytics_storage.

OneTrust’s Consent Mode integration guidance (script version 202311.1.0 or newer):

• Enable Google Consent Mode on the relevant geolocation rule.
• Default mapping: Performance category to analytics_storage; Targeting category to ad_storage, ad_user_data, and ad_personalization. Change mappings if your category IDs differ.
• Preferred path in GTM: install the OneTrust CMP community template, paste the Data Domain Script ID, enable Consent Mode, map each GCM type to a OneTrust category ID, set global and region-specific defaults, and fire on Consent Initialization – All Pages.
• Alternative: set gtag('consent', 'default', ...) yourself before GTM or gtag loads, then let OneTrust update states after choice.

Google Tag Manager Help also documents a OneTrust-specific setup path that mirrors those steps. A later series article will go deeper on Consent Mode edge cases; for go-live, confirm Tag Assistant or the Consent Mode debug view shows denied defaults flipping to granted only after Accept for the mapped categories.

Step 8: Publish production and cut over

1. Publish the test script with the final configuration (including Auto-Blocking if you use it).
2. Within the allowed window, publish the production script.
3. Replace the testing CDN on production with the production CDN. Production scripts are domain-specific; they will not behave correctly on an unrelated staging host.
4. Keep the Cookie Settings control live site-wide.
5. Clear CDN and browser caches if the new banner does not appear; OneTrust notes production changes can take time to cache even when cache-busting is enabled.

After cutover, repeat the smoke tests from a VPN or geo tool that lands you in EEA, UK, California, and India (or your real traffic mix). Confirm consent logging or receipts are enabled on the geolocation rules where you need proof for audits and vendor questionnaires.

Maintenance checklist

• Rescan after marketing launches new pixels or chat tools.
• Republish when templates, geolocation rules, or newly used categories change.
• Prefer publishing on a supported (ideally latest) script version so Consent Mode and blocking fixes remain available.
• Add blocking steps to the SOP for new site content so tags never ship around the CMP.
• Re-test reject paths quarterly; banners drift when someone adds a hard-coded pixel in the theme.

Common setup failures

• CDN below other tags: ads fire before OneTrust initialises.
• Production script on the wrong host: banner loops or never stores consent correctly.
• Auto-blocking never enabled and GTM never gated: banner theater with full tracking on reject.
• Consent Mode defaults missing: Google tags assume grant until update, or fire before the CMP.
• Category mapping drift: Performance cookies labelled as Strictly Necessary so they never ask for consent.
• No reopen control: withdrawal is harder than the original Accept click.

FAQ

Do I need Auto-Blocking?

Not if every non-essential tag is gated another reliable way (GTM consent checks, server-side gating, or careful script control). You do need some blocking method. Auto-Blocking is convenient; it is not magic. Test it on staging before production.

Can I put OneTrust only through GTM?

Google’s OneTrust setup help supports loading via the CMP template on Consent Initialization. Many teams still place the CDN directly in <head> for earliest control. Follow OneTrust and Google guidance for your tagging stack, and verify order with Tag Assistant.

How does this relate to article 1?

Article 1 is the map: inventory, banner, records, blocking, Consent Mode, and multi-region duties. This article is the OneTrust install path that implements that map. GDPR owner duties are covered in article 3.

Sources and further reading

• OneTrust: Getting Started with Cookie Consent; Scanning a Website; Publishing and Implementing Cookie Consent Scripts; Maintaining Your Cookie Consent Implementation; Implementation Best Practices: Cookie Consent (MyOneTrust Knowledge Base).
• OneTrust: Cookie Consent Integration with Google Consent Mode; Cookie Consent Integration with Google Tag Manager.
• Google Tag Platform: Set up consent mode on websites.
• Google Tag Manager Help: Set up OneTrust to obtain user consent; Consent Mode setup with CMP partners.
• Series map: Cookie Compliance in 2026: A Practical Guide.

Next in this series

Up next: GDPR Cookie Consent Requirements: What Website Owners Must Know. That article focuses on ePrivacy Article 5(3), EDPB consent and cookie-banner guidance, and the owner checklist that your OneTrust geolocation rules should encode.

Disclaimer

This article was prepared by Imran using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, privacy policies, or other privacy and data-protection controls. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 3 September 2026