Introduction
Cookie banner compliance is not something you achieve once and check off a list. It is a continuous alignment between what your banner says, what your cookie policy declares, how your tags actually behave on every page load, and what regulators expect in your target jurisdictions. A cookie banner checklist bridges the gap between knowing the requirements and verifying they are met on the live site—not in a staging environment, not in a mockup, not in the CMP vendor's dashboard, but on the production URL a real visitor or regulator would load.
This checklist is designed for practical, repeatable verification. Each item includes what to check, how to check it, and what to do if it fails. The checklist is structured sequentially: pre-deployment preparation, banner design and UX, technical enforcement, policy and documentation alignment, and ongoing monitoring. Work through it in order, but treat it as a living document you return to after every GTM container publish, marketing tag addition, plugin update, or theme change.
The checklist assumes an EU-facing website using analytics, advertising, or other non-essential tracking technologies. If your site uses only strictly necessary cookies and no third-party scripts, many items still provide useful verification of that factual claim. Automated checks in this checklist reference GDPRChecker scanner capabilities, but the manual verification steps work with any browser Developer Tools.
This article provides technical operational guidance. It does not constitute legal advice. Consult qualified privacy counsel for jurisdiction-specific requirements applicable to your organization and data processing activities.
1. Pre-deployment preparation
Before you configure or deploy a cookie banner, you need a complete inventory of what runs on your site. Skip this step and your banner will describe a fictional version of your site—a mismatch that scanners and regulators detect immediately.
Inventory all tags, scripts, and third-party services that set cookies, read device storage, or make network requests to analytics, advertising, or social media domains. Include Google Analytics (GA4), Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, TikTok Pixel, Hotjar, HubSpot tracking, Intercom, chat widgets, A/B testing tools, affiliate pixels, and any custom scripts that use localStorage or IndexedDB for measurement purposes. For each item, record: the script source or provider, whether it is configurable through the site admin or hardcoded in the template, the cookies or storage keys it creates, and the purpose category (strictly necessary, analytics, marketing, functional, or unclassified).
Classify each item correctly. The bar for 'strictly necessary' is high: the cookie must be essential to deliver a service the user explicitly requested at that moment. Session authentication, shopping cart persistence, load balancing, and security tokens typically qualify. Analytics, advertising, heatmapping, session recording, A/B testing, and social media widgets do not—regardless of how useful they are to your business. Several national DPAs, including CNIL and the Dutch AP, have published guidance confirming that standard analytics implementations do not qualify for the strictly necessary exemption.
Document your legal basis for each category. Consent is the appropriate basis for analytics and marketing in most configurations. If you rely on legitimate interest for any processing, document the legitimate interest assessment (LIA) and ensure it is separately reviewable. A banner that collects consent for some purposes and cites legitimate interest for others must clearly distinguish between the two in the interface.
2. Banner design and UX
The banner must present Accept all and Reject all with equal visual weight on the first layer. Check: button size, font weight, color contrast, border treatment, and tap target area are equivalent. Reject must not be hidden behind Manage preferences, Settings, or a second screen. A Manage preferences link can sit alongside the two primary buttons for granular category control.
Banner copy must name specific purposes, not vague descriptions. Instead of 'We use cookies to improve your experience,' state 'We use analytics cookies to measure audience and marketing cookies to show relevant ads.' Link to the privacy policy and cookie policy from the banner footer. Confirm both links return HTTP 200 and resolve to pages with current content.
Category toggles in the preference center must default to off for non-essential purposes. Strictly necessary toggles may be locked on. Each category needs a short explanation—one to two sentences—describing the purpose and naming key vendors. Users must be able to toggle individual categories and save preferences without accepting all by default.
Accessibility: banner must be keyboard-navigable with visible focus indicators, all interactive elements must have accessible names, color contrast must meet WCAG 2.1 AA minimums, and the banner must not trap focus or block page content without a clear dismiss path for users who cannot interact with the overlay.
Mobile: verify Accept and Reject are both visible without scrolling on a 375px-wide viewport. Buttons must have adequate tap targets (minimum 44x44 CSS pixels). Banner must not obscure critical page content on small screens. Test on real mobile devices, not only responsive design mode in desktop browsers.
3. Technical enforcement
This is the section most teams skip because they assume the banner handles it automatically. Most CMPs do not. You must verify that blocking actually works on the live site.
Script order: the consent banner or runtime guard script must appear in the HTML head before Google Tag Manager, analytics scripts, marketing pixels, and any third-party embeds that set cookies. Open the page source (View Source, not the DOM inspector). Confirm the guard or CMP script is the first or nearly first script element in head, before any GTM or gtag reference. If GTM appears first, tag triggers are unreliable regardless of what the CMP dashboard reports.
Pre-consent blocking: open a private browser window. Open Developer Tools to the Network tab. Navigate to your site. Before clicking anything on the banner, filter network requests for google-analytics.com, googletagmanager.com, connect.facebook.net, and similar tracking domains. Zero non-essential tracking requests should appear. If requests appear before banner interaction, your blocking is failing or your script order is wrong.
Post-reject enforcement: click Reject all on the banner. Navigate to two or three internal pages. Confirm no tracking requests appear on subsequent pages. Check browser cookies/storage for any non-essential entries. Confirm Consent Mode signals are set to denied for all parameters if Google tags are present.
Post-accept enforcement: clear browser storage, reload, and click Accept all with analytics and marketing enabled. Confirm tracking requests appear correctly on subsequent pages. Confirm Consent Mode signals update to granted for the appropriate parameters. Verify that analytics events fire and appear in your analytics dashboard within the expected reporting window.
Consent persistence: after accepting or rejecting, close and reopen the browser (not just the tab). Return to the site. Confirm the banner does not reappear and the previous consent state is honored. Repeat with a new private window to confirm clean-session behavior.
Complement manual checks with a scanner
Run a GDPRChecker public scan in parallel with your manual checks. The scanner simulates a first-time EU visitor in a clean browser session and independently reports pre-consent network requests, consent UI detection, and policy link status. Use it as a second opinion after your manual verification.
4. Policy and documentation alignment
Your cookie policy must match your live site behavior, not your intentions or your staging environment. Compare the detected cookies and trackers from your inventory and scanner output against the cookie table in your published cookie policy. Flag every discrepancy: cookies on the live site that are missing from the policy, policy-listed cookies that no longer appear on the site, and category mismatches where a cookie's declared purpose does not match its actual behavior.
Both the privacy policy and cookie policy must be reachable from the cookie banner, the site footer, and any consent preference center. Each URL must return HTTP 200. Cookie policy must include: provider names for each cookie, purpose descriptions, cookie lifetimes or maximum retention, whether data is shared with third parties, and the names of significant third-party recipients. If your site serves multiple languages, provide policy translations for each supported language.
If your site uses Google Analytics, Google Ads, or other Google services that rely on Consent Mode v2, your cookie policy should mention that consent signals are communicated to Google and describe which parameters are mapped to which consent categories. If you participate in the IAB Transparency and Consent Framework (TCF), include your Global Vendor List reference and CMP ID. These details help enterprise buyers and partners complete their own vendor due diligence.
5. Ongoing monitoring and verification
Cookie compliance degrades over time if you only test once. Marketing adds pixels for campaigns. GTM containers receive weekly updates. Plugins auto-update and inject new scripts. Themes are refreshed and lose custom CMP integrations. A site that passed all checks in January may fail most of them by June if no one retested.
Schedule recurring scans: at minimum monthly for active marketing sites, weekly if your site uses multiple tag management containers or if marketing frequently adds pixels. Run scans automatically rather than relying on manual reminders. Configure alerts so the designated compliance contact is notified when a scan detects new cookies, new third-party requests, or changes in consent UI detection status.
Maintain a consent log: each consent event should record timestamp, categories accepted or rejected, policy version in effect at consent time, and a session identifier. These records are critical for GDPR Article 7(1) accountability demonstration. The log should be exportable and searchable by date range for audit purposes.
Version control your cookie policy and banner configuration. When you change purposes, add vendors, or update categories, increment a version identifier. Compare each new consent event against the current version. If a user consented under an old version and the changes are material, re-prompt for consent. Document your version change criteria and renewal process in your privacy documentation.
Automate recurring verification
GDPRChecker's scheduled scan feature runs scans automatically on your configured cadence and sends alerts when new cookies, trackers, or policy changes are detected. This converts compliance verification from a manual checklist event into a continuously monitored state.
How GDPRChecker helps with each checklist section
Pre-deployment preparation: GDPRChecker's public scanner produces a cookie and tracker inventory from a single scan, identifying scripts, network requests, and cookie metadata without requiring manual DevTools inspection. The dashboard cookie inventory lets you review, re-categorize, and approve each detected item before publishing a declaration.
Banner design: The consent banner editor covers layout, copy, category configuration, and appearance in one workflow. Accept all and Reject all are included with equal visual weight by default. Mobile preview shows how the banner renders on small screens before publish.
Technical enforcement: Runtime-guard.js loads before marketing tags and applies blocking rules tied to consent categories. Setup verification confirms the guard appears in head before GTM and heartbeat signals prove the runtime is active on production. The compliance scanner independently verifies pre-consent blocking on the live URL.
Policy alignment: Cookie inventory review workflow connects detected cookies to your published declaration. Policy consistency checks compare declared cookies against live scan results and flag discrepancies. Declaration snapshots record the state at publish time for version comparison.
Ongoing monitoring: Scheduled scans with change detection and alerts keep verification current without manual reminders. Consent logs capture timestamp, choices, and policy version per event for Article 7(1) accountability.