Website GDPR Audit Checklist

Introduction

A useful website GDPR audit is practical, repeatable, and tied to what the live site does in a browser. It should not be a static spreadsheet that someone updates once a year and then forgets. Marketing tags change, consent tools are reconfigured, and new pages go live. Your audit checklist needs to catch that drift.

This checklist focuses on the website layer: consent banners, cookie and tracker behavior, policy links, cookie declarations, consent records, and monitoring. It does not replace a full privacy program audit, but it gives teams a strong foundation for the part of GDPR and ePrivacy that visitors experience directly.

Use it before launch, after a redesign, after adding a new advertising or analytics vendor, or whenever a customer asks how you control website tracking. The strongest evidence comes from combining automated checks with manual review.

1. Define the audit scope

Start by listing the pages and systems in scope. Include your homepage, pricing page, signup flow, contact forms, blog or guide templates, campaign landing pages, embedded forms, and any subdomains that share the same marketing stack.

Also list who can change the website. In many companies, engineering owns templates, marketing owns tag manager, sales owns embedded booking tools, and customer success owns help center widgets. A website GDPR audit should understand these ownership boundaries because they explain how new trackers appear.

2. Audit the consent banner

The banner should appear before optional analytics and marketing tools run. It should give a real choice, including reject and preference controls. For GDPR and ePrivacy-oriented websites, the first visit is the most important moment to test because no prior consent exists.

Check the language and the behavior. The banner should not claim that optional cookies are off if the browser has already sent analytics requests. The reject path should not be visually hidden or require more effort than acceptance. The preferences modal should match the categories used by the runtime.

1. Open the site in a clean private window.
2. Confirm the banner appears before optional tracker requests.
3. Click Reject and refresh.
4. Confirm optional trackers remain off.
5. Open preferences and enable only analytics.
6. Confirm analytics is released and marketing remains blocked.
7. Withdraw consent and confirm optional cookies are cleared where possible.

3. Build a cookie and tracker inventory

A cookie inventory should include browser cookies, tracker scripts, pixels, and relevant storage signals. It should store metadata only: name, provider, purpose, category, duration, first seen, last seen, source, and review status. It should not store cookie values.

Separate detected items from reviewed items. A scanner may detect Google Tag Manager, Meta Pixel, Hotjar, or Google Analytics, but a human still needs to confirm whether each item belongs in analytics, marketing, preferences, or another category. Unknown items should stay in a review queue until someone decides.

Demo or test cookies should be excluded from published declarations. They can be useful for QA, but they should not appear as production tracking in a policy unless they exist on the real visitor journey.

4. Compare policy text with live behavior

Policy consistency is where many audits find drift. The cookie policy may mention Google Analytics but not Meta Pixel. The cookie declaration may include reviewed cookies but omit a new tracker script. Or the privacy policy may mention a vendor that is no longer used.

The audit should compare three sources: the inventory, the published declaration, and the policy text. Differences are not automatically violations, but they are review items. If a tracker is detected but not disclosed, the policy needs review. If the policy mentions a tracker not detected anymore, the declaration may be stale or the vendor may still run on pages you did not scan.

• Inventory item missing from declaration: review and publish a new declaration snapshot.
• Declaration item not detected: confirm whether it is still used or only appears on other pages.
• Policy mentions a vendor not detected: check other templates before removing it.
• Detected vendor missing from policy: update policy language after internal review.
• Missing withdrawal language: add clear instructions for changing preferences.

5. Review consent records and evidence

Consent records help demonstrate that visitor choices are captured. A good record does not need to identify the visitor in plain text. It should record event type, timestamp, selected categories, policy or banner version, runtime version, source page path, and hashed technical identifiers where needed.

During the audit, verify that accept, reject, customize, update, and withdraw events are recorded. Also check export behavior. CSV exports should not include raw IP addresses, raw user agents, cookie values, or secret tokens. The goal is evidence with data minimization.

6. Add post-launch monitoring

A website can pass today and drift tomorrow. Scheduled scans reduce that risk by checking for new trackers, new cookies, and pre-consent network requests after the initial audit. Alerts should go to the people who can act: privacy, marketing operations, or engineering.

Monitoring is especially important when tag manager changes do not require a code deploy. A third-party script can appear on the live site without appearing in a pull request. Weekly scans may be enough for small sites; daily scans are better for high-change marketing teams.

1. Set a baseline scan after the audit is complete.
2. Enable scheduled scans for verified sites.
3. Send alerts for new trackers, new cookies, and pre-consent requests.
4. Route findings into the cookie inventory review queue.
5. Update declaration and policy text when confirmed changes are legitimate.

How GDPRChecker supports the audit

GDPRChecker connects the audit steps into one workflow: run a website GDPR check, install runtime protection, collect consent records, review cookies and trackers, publish a declaration snapshot, monitor for new signals, and compare policy text against detected behavior.

The result is not a legal certification. It is an operational system for finding, fixing, and documenting website-level privacy issues.

• Cookie and tracker inventory
• Cookie policy generator
• How to check a website

Short disclaimer

This checklist is operational guidance for website privacy controls and technical testing. It is not legal advice and does not guarantee GDPR compliance.