GDPR Audit Example: Cookies, Trackers and Privacy Headers
This example shows the aiwebpageseo GDPR Audit for an e-commerce site. The audit found 3 critical failures — no cookie consent banner, no cookies policy page, and Google Analytics firing before user consent. Any of these could result in an ICO complaint.
| Check | Result | Detail |
|---|---|---|
| Cookie consent banner | ✗ FAIL | No consent banner detected before trackers load |
| Privacy policy page | ✓ PASS | Found at /privacy-policy |
| Cookies policy page | ✗ FAIL | No cookies policy page found |
| HTTPS / secure connection | ✓ PASS | TLS 1.3 — valid certificate |
| Analytics loaded before consent | ✗ FAIL | Google Analytics fires on page load before consent |
| Third-party trackers | ⚠ WARN | 12 trackers detected — Facebook Pixel, GA4, Hotjar |
| Security headers | ⚠ WARN | Missing Content-Security-Policy header |
| Contact information | ✓ PASS | Email address found in footer |
| Data subject rights | ✓ PASS | Right to erasure mentioned in privacy policy |
An automated privacy audit is a technical observation, not a legal opinion. It can load your page with a clean browser profile and record exactly what happened: which scripts executed, which cookies were written, whether anything was stored before a choice was offered, whether the policies it looked for exist at the URLs they usually live at. Those facts are checkable and they are what the report above contains.
What it cannot see is the part that determines whether you are actually compliant. It does not know your lawful basis for each processing purpose, whether your data-processing agreements are in place, how long you retain what you collect, whether your consent records would survive a regulator's inspection, or whether the privacy policy it found says anything true. A site can pass every check on this page and still be in breach; it can also fail a check for a reason that turns out to be defensible.
So treat the failures as facts worth acting on and the overall picture as incomplete. This is general information, not legal advice, and a site processing personal data at any scale should have someone qualified look at the whole arrangement rather than at a scan of the front end.
Of the three failures, this is the one that matters most, because it makes the other two academic. If Google Analytics fires on page load, then by the time a banner appears — if one appeared at all — the identifier has already been set and the pageview already sent. Consent requested after the fact is not consent. It is notification, and it has no legal effect.
It is rarely a decision anybody made. The usual causes are mundane: the analytics snippet is hardcoded into the template above the consent platform, or the consent script loads asynchronously while the tag does not wait for it, or a tag manager container fires everything in it on a page-load trigger regardless of the consent state. Nobody chose to do this; nobody checked either.
The fix is to gate every non-essential script on a consent signal so that nothing loads until the user has chosen — and then to verify it the only way that proves anything, which is to open the site in a clean browser profile, watch the network panel and the cookie jar, and confirm that nothing non-essential appears until you click. A consent platform that is installed but not enforcing is worse than none, because it demonstrates that you knew consent was required.
The same discipline applies to the twelve third-party trackers. Each one is a separate party you have allowed to observe your visitors, and you remain accountable for what happens on your pages.
Adding a banner is the obvious response to the first failure and it is where most sites stop. It is also where most enforcement finds them, because the standard the GDPR sets for consent is high and specific: freely given, specific, informed, unambiguous, and as easy to withdraw as it was to give.
| Pattern | Verdict |
|---|---|
| Prominent "Accept All", refusal hidden behind a settings panel | Not valid consent |
| Pre-ticked boxes for non-essential categories | Not valid consent |
| "By continuing to browse you agree…" | Not valid consent |
| Banner appears, trackers already fired | Not valid consent |
| Accept and Reject given equal prominence on the first screen | Meets the basic test |
| Withdrawal available later, in one obvious place | Required, frequently missing |
One further point that is often missed: the consent obligation for storing and reading information on a device comes from ePrivacy — PECR in the UK — and applies to non-essential cookies whether or not they process personal data. The GDPR supplies the standard that the consent must meet. Satisfying one and not the other still leaves you non-compliant, which is why "we have a banner" is not an answer to this report.
Twelve third-party trackers is a warning rather than a failure, and the honest reason it is only a warning is that the audit cannot tell whether you know what they are. Most sites do not. Trackers accumulate: a campaign adds a pixel, a plugin ships an SDK, a tag manager container grows for three years and nobody removes anything because nobody is certain what would break.
Do the inventory. For each one, write down who the vendor is, what purpose it serves, who inside the business relies on the data, and whether that reliance is real. In practice a large share of them turn out to be serving nobody — a pixel for a campaign that ended, an analytics tool nobody logs into, a heatmap trial from two years ago. Every one of those is a party observing your customers for no benefit to anyone, and deleting it is free.
There is a performance dividend too. Third-party scripts are among the most reliable causes of poor Core Web Vitals: they block rendering, they contend for the main thread, and they are served from origins you do not control. Cutting twelve trackers to four is a privacy improvement, a performance improvement and a security improvement in one afternoon, and it is the rare piece of compliance work that pays for itself.
HTTPS with a valid certificate, a privacy policy at a findable URL, a contact route in the footer, and a mention of the right to erasure. These are passes in the sense that the thing exists — the audit cannot judge whether any of them is any good.
A privacy policy that exists but describes processing you no longer do, or omits processing you have started, is worse than a missing one: it is a public, dated statement that is untrue. The same goes for data-subject rights. Mentioning the right to erasure is trivial; being able to actually locate and delete every copy of a person's data across your systems within a month of a request is the substantive obligation, and no front-end scan can verify it. If you have never tested that path end to end, test it before you rely on the sentence in the policy.
On the missing security headers: a Content-Security-Policy constrains what may execute on your pages, which is a real defence against injected third-party script — the exact risk that twelve trackers amplify. Worth adding, and worth being clear that it is a security control rather than a privacy one. It is not a ranking factor, and no assistant checks it.
| # | Action | Why here |
|---|---|---|
| 1 | Stop non-essential scripts firing before consent | Until this is true, nothing else you build has any effect. Verify with a clean profile and the network panel. |
| 2 | Ship a banner where refusing is one click from the first screen | Equal prominence, no pre-ticked boxes, withdrawal available later in an obvious place. |
| 3 | Inventory the twelve trackers and delete what nobody uses | Free, fast, and improves privacy, performance and security at once. |
| 4 | Publish a specific cookies page | Name each cookie or category, its purpose, its owner, its lifetime, and the consequence of refusing. |
| 5 | Test a real erasure request end to end | The obligation is the deletion, not the sentence in the policy claiming you would. |
| 6 | Add the missing security headers | Correctness work. Not a privacy control and not a ranking factor, but it limits what an injected script can do. |
Is a cookie banner a GDPR requirement or an ePrivacy requirement?
Both are involved, and the distinction matters because it determines what the banner has to do. The obligation to obtain consent before storing or reading information on a user's device comes from the ePrivacy Directive — implemented in the UK as PECR — and it applies to almost all non-essential cookies and similar technologies regardless of whether they process personal data. The GDPR then supplies the standard that consent must meet: freely given, specific, informed, unambiguous, and as easy to withdraw as to give. So ePrivacy says you need consent, and the GDPR says what counts as consent. A banner that satisfies the first and not the second is still non-compliant.
Why is analytics firing before consent a critical failure and not a warning?
Because by the time the user sees the banner, the thing the banner was supposed to ask permission for has already happened. Consent that is requested after the tracker has loaded is not consent; it is notification. This is the single most common finding in a cookie audit and it is usually a technical accident — the tag is hardcoded in the template, or the consent platform is loaded asynchronously and the analytics snippet does not wait for it. Fix it by gating the scripts on the consent signal so nothing non-essential executes until a choice has been made, and verify it by loading the page with a clean profile and watching the network tab.
Do I really need a separate cookies policy if I already have a privacy policy?
You need the information to be available, specific and findable; whether it lives on one page or two is a presentation decision. What regulators have consistently criticised is vagueness — a policy that says the site uses cookies to improve your experience tells the reader nothing. The information that must be there is concrete: what each cookie or category does, who sets it, whether it is first or third party, how long it persists, and what happens if the user refuses it. In practice a separate cookies page is easier to keep accurate, because it changes far more often than the privacy policy does.
Twelve third-party trackers were detected. Is that a problem in itself?
The number is not the problem; not knowing what they do is. Every third party you load can potentially read the request, set identifiers and profile the visitor, and you remain accountable for what happens on your site. Most sites with a dozen trackers cannot say what half of them are, because they arrived with a tag manager, a marketing campaign, or a plugin nobody has revisited. Inventory them, work out which ones actually earn their place, delete the rest, and make sure the remainder are gated behind consent. Removing a tracker nobody uses is the cheapest privacy improvement available and it usually makes the site faster too.
What counts as a valid consent banner?
One where refusing is as easy as accepting. Regulators across the EU and the UK have been explicit and repetitive about this: a prominent Accept All with a Reject buried behind a settings panel does not produce freely given consent, pre-ticked boxes are not consent, continued scrolling is not consent, and consent walls that make a site unusable without agreeing are heavily scrutinised. The practical test is whether a user who wants to refuse can do it in one click from the first screen. If they cannot, the banner is decorative — and worse than nothing, because it documents that you knew consent was required.
Does GDPR compliance affect SEO?
Not directly. There is no ranking factor for having a cookie banner, and Google does not check your privacy policy. Two indirect effects are worth knowing about. A poorly built consent platform can genuinely damage performance — a render-blocking banner script that delays the largest contentful paint will show up in your Core Web Vitals, and that is a real if small ranking consideration. And a banner that blocks the page content until dismissed is a poor experience for a human, whatever the ranking systems make of it. Beyond that, do this work because the law requires it, not because it moves a metric.
Does any of this apply if my company is outside the EU or UK?
Very likely, yes. The GDPR applies to organisations anywhere in the world that offer goods or services to people in the EU, or monitor their behaviour — and an e-commerce site that ships to Europe and runs analytics on European visitors is doing both. The UK GDPR works the same way for the UK. Territorial location is not the test; whose data you process is. This is general information rather than legal advice, and if you are processing significant volumes of personal data across borders it is worth having a qualified adviser look at your actual setup.
Related Demo Reports
🔒 Run a GDPR Audit on Your Site
Find cookie banner failures, tracker issues and privacy policy gaps before they become legal problems. Free to run.