We Only Use Essential Cookies — Why That Claim Is Usually Wrong

“We only use essential cookies — for the shopping basket and login sessions. We don’t do tracking.”

This is the most common misconception in UK cookie compliance. Site owners repeat this phrase confidently. But when you scan their websites, you find analytics tools, marketing trackers, embedded widgets, and third-party scripts they didn’t know about.

The gap between perception and reality is almost always 2–3x. What the owner thinks is loading is only a fraction of what’s actually there.

This matters because non-essential cookies require consent. If you have non-essential cookies and claim you only have essential ones, you’re making a false compliance claim. You’ve placed cookies without consent.

What “Essential” Actually Means

An essential cookie is one that is “strictly necessary” for a service the user has explicitly requested. The test is functional: would the service work without this cookie?

Examples of genuinely essential cookies:

• Shopping basket: An e-commerce site needs to remember items the user added. Without this cookie, the basket would empty on page reload. Essential.
• Login session: A service requires authentication. The session cookie proves the user is logged in. Without it, they’d have to re-enter credentials on every page. Essential.
• CSRF protection token: A form submission token that prevents cross-site request forgery attacks. Without it, the form could be exploited. Essential for security.
• Language preference (if required): Some content is only available in one language. A cookie that saves the user’s selected language so they don’t have to re-select on every page could be essential. But only if the user has explicitly requested that language.

Examples of cookies that are NOT essential:

• Google Analytics (_ga, _gid): These track user behavior. The service (your website) works fine without them. You use them to understand user behavior, not because users need them for functionality. Not essential.
• Facebook Pixel: Tracks users for advertising. Not essential.
• HubSpot analytics: Tracks user behavior for lead generation. Not essential.
• Hotjar: Records user sessions for behavior analysis. Not essential.
• Live chat widget: Let’s users contact support, which is useful but not strictly necessary for the core website function. Cookies set by live chat systems are not essential.
• Email capture forms: Prompts users to sign up for newsletters. Not essential.
• A/B testing tools: Record which variant the user saw so they see consistency across pages. Useful for you, not necessary for the user. Not essential.

The defining question: Is this cookie required for a service the user has explicitly requested, or is it a business convenience?

Why Site Owners Undercount Their Cookies

Most site owners genuinely believe they only use essential cookies. This isn’t dishonesty — it’s incomplete knowledge. Cookies accumulate invisibly.

Reason 1: CMS and Plugin Defaults

If you use WordPress, Shopify, WooCommerce, or similar platforms, your CMS ships with plugins and theme features that load tracking scripts. You may not have explicitly installed them. Many site owners don’t realize their chosen theme includes analytics, engagement tracking, or affiliate links.

Example: A WordPress site owner chooses a “professional business theme.” They don’t realize the theme ships with Hotjar integration for heatmaps. The site now loads Hotjar’s tracking script. The owner doesn’t know it’s there.

Reason 2: Forgotten Integrations

Years of website updates create layers. A company might integrate with HubSpot, then with Mailchimp, then with a CRM. Each integration adds scripts. If the company later switches tools, the old scripts remain. The owner forgets they’re there.

Example: A B2B company integrated with HubSpot in 2020. They switched to Pipedrive in 2023. The Pipedrive script was added; the HubSpot script was never removed. Both now run. The owner thinks they only use Pipedrive.

Reason 3: Embedded Widgets

Every embedded widget (live chat, feedback forms, video players, review widgets) loads external scripts. The site owner doesn’t think of these as “their” cookies because they didn’t create them. But PECR applies regardless of who created the script — if it’s on your site, you’re responsible.

Example: A retail site uses a Shopify app for customer reviews. The app embeds a widget that loads tracking scripts from the review provider. The site owner doesn’t consider this part of their cookie footprint because they’re using an app, not installing code themselves. But the cookies are set on their domain.

Reason 4: Social and Advertising Integration

Most sites integrate with social platforms and advertising networks (Facebook, Google Ads, LinkedIn, Instagram). These integrations load tracking pixels and cookies. Many site owners do this once and forget about it. If they’re not checking their pixel library regularly, they don’t realize what’s running.

Example: A B2B company runs Facebook ads, so they added the Facebook Pixel. Later, they also add LinkedIn conversion tracking. Then Google Ads tracking. They now have three major tracking pixels, plus analytics from their CRM, plus live chat, plus email widget. The owner still thinks “we just have analytics and maybe a pixel or two.”

Reason 5: No Audit

Most site owners have never audited their cookies. They’ve never used a scanner to see what their site actually loads. They’re guessing based on what they explicitly installed, not what’s actually running.

This is the root cause. An audit takes an hour. Most sites have never done one.

How to Find What’s Really There

Option 1: Use a scanner (£50–500, depending on depth)

• Cookiebot (cookiebot.com)
• CookieYes (cookieyes.com)
• Similar Web (similarweb.com)
• Termly (termly.io)

Upload your site URL, let it scan, download the report. Most provide detailed results including cookie names, purposes, providers, and whether they’re being blocked.

Option 2: Use browser developer tools (free)

1. Open your site
2. Open Developer Tools (F12 key)
3. Go to the “Storage” or “Application” tab (varies by browser)
4. Clear all cookies
5. Reload the page
6. Check the Cookies section — you’ll see every cookie set
7. Also check the Network tab — you’ll see every external domain contacted

Browser tools require you to interpret the results, but they’re free and comprehensive.

Option 3: Ask your developer or marketing team

If you have technical staff, ask them to audit the site. Show them this article and ask: “What cookies are actually loading?”

What Most Sites Actually Have

Based on scans of 100+ UK SME websites, the typical pattern is:

• 1–3 essential cookies (shopping basket, login session, security token)
• 3–5 analytics cookies (Google Analytics, possibly Hotjar or similar)
• 2–5 advertising cookies (Facebook Pixel, Google Ads, LinkedIn, etc.)
• 2–5 CRM or marketing cookies (HubSpot, Mailchimp, etc.)
• 2–10 widget or plugin cookies (live chat, review system, email capture, etc.)
• 2–5 third-party cookies from integrated services (Shopify apps, CMS plugins, etc.)

Total: 15–35+ cookies. Almost none of which are essential.

When asked, most site owners say “maybe 3–5.” The actual number is typically 5–10x higher.

The Compliance Implication

If you claim you only use essential cookies and have non-essential cookies loading, you’re making a false statement. This affects:

1. Your cookie policy. If you claim no tracking but you’re tracking, your policy is incorrect and potentially misleading.

2. Your consent claim. If you claim you don’t need consent for cookies (because you think they’re essential) but you’re actually tracking, you’re placing cookies without consent. That’s a PECR breach.

3. Your GDPR disclosure. Under UK GDPR, your privacy policy must disclose what data you collect and why. If you’re hiding tracking in a false “essential only” claim, you’re not being transparent.

4. Your liability. If a customer complains and the ICO investigates, discovering hidden tracking strengthens their case against you.

What to Do

1. Audit your site. Use one of the methods above. Spend an hour and know what’s actually loading.

2. Update your understanding. Don’t assume — confirm what’s really there.

3. Be honest about what you have. If you have analytics, say so. If you have advertising pixels, say so. Transparency is the safest compliance approach.

4. Implement consent if needed. If you do have non-essential cookies (which you almost certainly do), you need a functioning consent mechanism that blocks them until consent is given.

5. Update your cookie policy. List what you actually have, not what you think you have.

Most site owners find this audit surprising and humbling. But it’s the foundation of actual compliance.

The Broader Point

Cookie compliance is easy to talk about and hard to implement. Many site owners know they should have consent mechanisms but make false claims about “only using essential cookies” to avoid the work. The audit reveals the gap.

The good news: fixing this is straightforward. Install a consent management platform (CMP), block non-essential scripts until consent is given, and update your policy. This typically takes a few hours and costs £40–350/month. It’s not expensive or complicated. The friction is knowledge and inertia, not technical difficulty.

For a technical audit of your site revealing exactly what cookies load and whether you actually need consent, Bartram Web scans your site and identifies every cookie, its purpose, and whether it’s being blocked properly. To stay informed about cookie compliance requirements and other regulatory updates, subscribe to our fortnightly newsletter.

The first step is always the audit. Everything else flows from knowing what’s actually there.

Updated 2026-03-23