How to Check If a Website Is GDPR Compliant

Introduction

Checking whether a website is GDPR compliant is not the same as looking for a privacy policy link. A real check needs to connect what the site says, what the browser does, and what evidence the business can keep over time.

For most marketing websites, the highest-risk gap is the space between consent text and technical behavior. A banner may say analytics waits for consent, but Google Analytics, Meta Pixel, Hotjar, or a tag manager may still request data before a visitor chooses. A policy may list vendors, but the live site may have added a new script last week. A cookie table may look complete, but it may not match what the browser actually stores.

This guide gives you a practical workflow for a website GDPR compliance check. It is written from a product and operations perspective: how to inspect the page, what to test in a browser, what evidence to keep, and where an automated GDPR checker or GDPR scanner can help. It is not legal advice, but it can help you find technical issues before they become legal or customer-trust problems.

What a website GDPR check can and cannot prove

A website check can prove many technical facts. It can show whether a cookie banner appears, whether a reject option exists, whether non-essential scripts request data before consent, whether consent choices are stored, and whether a cookie inventory contains the names of detected cookies and tracker scripts.

It cannot prove every legal requirement. GDPR also includes data subject rights, processor contracts, lawful basis analysis, retention rules, security controls, breach handling, and international transfer assessments. Those need internal review, documentation, and sometimes legal input.

The useful way to think about the check is this: use technical testing to remove avoidable website failures, then use policy and process review to address the wider privacy program.

Start with public pages and policies

Begin with the pages visitors and regulators can see without logging in: the homepage, key landing pages, pricing pages, signup pages, and any high-traffic campaign pages. Confirm that the footer or equivalent navigation links to a privacy policy and, if cookies are used, a cookie policy or cookie declaration.

Do not only check that a policy exists. Read whether it explains categories of personal data, purposes, vendors or processors, contact details, rights, retention, and how users can change consent choices. For cookie-related checks, the policy should be consistent with the site: if the site uses analytics and advertising scripts, the policy should not imply that only essential cookies exist.

A common failure is policy drift. The policy was accurate when it was written, then the marketing stack changed. A new tag was added in Google Tag Manager, a heatmap product was tested, or a campaign page embedded a third-party widget. A website GDPR check should therefore compare the policy against detected scripts and cookies, not treat the policy as a standalone document.

Test the cookie banner before consent

Open a private browser window and load the page with developer tools open. Before clicking anything, filter the Network tab for common analytics and advertising endpoints. Watch for collect, gtag, gtm, doubleclick, facebook, fbevents, hotjar, clarity, segment, or other vendor requests. If these appear before the visitor accepts, you may have a pre-consent tracking issue.

Then test the banner controls. Accept all should release the relevant optional categories. Reject all should keep optional categories off and should not be harder to find than Accept. Manage preferences should let the visitor select categories such as analytics or marketing separately. If a visitor chooses analytics only, marketing pixels should remain blocked.

Finally, test withdrawal. After accepting, open the privacy settings link or floating control and change preferences back to necessary only. Optional trackers should stop loading on future navigation, and non-essential test cookies should be cleared where the runtime controls them.

1. Load the page in a private window with Network open.
2. Record whether optional trackers request data before any choice.
3. Click Reject all and refresh the page.
4. Click Manage preferences and enable only analytics.
5. Confirm analytics is allowed while marketing remains blocked.
6. Accept all, then withdraw back to necessary only.
7. Check that the stored consent state and observed cookies match the choice.

Inspect trackers, cookies, scripts, and storage signals

A website GDPR compliance check should inventory more than classic cookies. Many systems use scripts, pixels, local storage, session storage, or network calls that do not look like a simple Set-Cookie header. That is why a GDPR scanner should separate cookies from tracker scripts and pre-consent network requests.

For cookie names, focus on metadata: name, provider, category, purpose, duration, first seen, last seen, and source. Avoid storing cookie values. Values can include identifiers and should not be copied into an audit table unless there is a very specific reason and privacy review.

After the scan, review unknown items. A tag manager script may be neutral by itself, but it can load analytics or marketing vendors inside the container. Unknown does not always mean illegal, but it does mean a human should confirm the category before publishing a cookie declaration.

Collect evidence for accountability

GDPR accountability is not only about doing the right thing; it is also about being able to show what you did. For a website, useful evidence includes scan reports, consent logs, cookie inventory review notes, cookie declaration snapshots, and policy consistency checks.

Consent records should show events such as initial accept, initial reject, customized preferences, updates, and withdrawal. They should avoid raw IP addresses, raw user agents, and full URLs where not needed. A safer implementation hashes sensitive fields and stores only the page path, event type, categories, runtime version, and policy or banner version.

Evidence also needs freshness. If your site changes weekly, a scan from six months ago is weak. Scheduled scans and alerts help find new trackers, new cookies, or pre-consent requests introduced by tag updates, CMS changes, or third-party embeds.

Common pitfalls when checking GDPR compliance

• Checking only the homepage while campaign pages load separate tags.
• Treating a privacy policy link as proof that tracking is lawful.
• Publishing a cookie declaration before reviewing unknown scripts.
• Letting a tag manager load before consent defaults are set.
• Using Accept all prominently while hiding Reject or preferences.
• Forgetting to test withdrawal after a visitor has already accepted.
• Keeping consent logs but storing more personal data than necessary.

The most expensive mistakes are usually simple: a new tracker added by marketing, a banner that does not actually block anything, or a policy that no longer reflects the live site. The fix is to make the check repeatable rather than one-off.

A GDPRChecker workflow for website checks

A practical GDPRChecker workflow starts with the free public scanner, then moves into managed protection if the site owner wants enforcement and monitoring. The scanner highlights banner, policy, cookie, and tracker signals. Managed sites can add runtime blocking, consent records, cookie inventory review, cookie declaration snapshots, scheduled scan alerts, and policy consistency checks.

This does not replace legal review. It gives legal, marketing, and engineering teams a shared view of what the live website is doing. That shared view is often the missing link between policy language and production behavior.

• GDPR website scanner
• GDPR compliance checker
• GDPR cookie banner
• Cookie and tracker inventory

Short disclaimer

This guide explains technical and operational checks for website privacy readiness. It is not legal advice and does not guarantee GDPR compliance. For legal interpretation, contractual questions, data subject rights, or regulatory risk, involve qualified privacy counsel.