How your cookie banner hurts your SEO — and what to do about it
Cookie banners cost LCP, CLS and INP, and Googlebot sees the banner too. Typical impact ranges, the fixes in order of effect, and how to drop the banner altogether.
This article was translated from Danish. Read the original.
A cookie banner hurts your technical SEO in four measurable ways. It adds render-blocking JavaScript that delays Largest Contentful Paint (LCP). It causes layout shift (CLS) when it is injected after the first paint. It adds main-thread work that worsens Interaction to Next Paint (INP). And with analytics gated behind consent, it blinds you to a large share of your own traffic data. Googlebot does not consent to anything: it crawls the page as a fresh visitor, banner and all, so whatever the banner does to your first paint, it does to what Google measures.
This is not an article about the rules. Nikan has written that one in cookie banners: the rules. This is about what the banner does to your page speed, your rankings and your data, and what you do about it. There are two paths: make the banner cheap, or remove what makes it necessary. We cover both.
How a cookie banner affects Core Web Vitals
Core Web Vitals (LCP, CLS and INP) are a confirmed, if lightweight, ranking signal and, more importantly, a proxy for the real-user experience that decides whether visitors stay. Consent tooling touches all three. The ranges below are what third-party consent scripts commonly land in across web-performance field studies; they are typical intervals, not a promise about your site.
| Metric | Typical damage from a careless consent tool | Mechanism |
|---|---|---|
| LCP (target 2.5 s or less) | +200–800 ms, worse on mobile | Render-blocking third-party script in <head>; on some sites the banner is the LCP element |
| CLS (target 0.1 or less) | 0.1–0.4 added shift | Banner injected after first paint pushes or overlays content; top-bar banners are worst |
| INP (target 200 ms or less) | +50–300 ms on early interactions | Consent JavaScript competing for the main thread exactly when the user first taps |
Your numbers depend entirely on which tool, how it is loaded and how heavy the page already is. A slim, self-hosted consent script loaded deferred can cost close to nothing. A tag-manager-injected commercial platform that loads a framework, fetches remote configuration and paints a full-screen modal can be the single most expensive third party on the page.
Two things make it worse in practice. First, the consent tool loads before everything it gates. It must, by definition, run before the trackers it controls, so it sits at the front of the critical path. Second, consent walls that block the whole page (full-screen modals with a dimmed backdrop) put the banner in front of your content on every first visit. For Googlebot, every visit is a first visit.
What Googlebot actually sees
Googlebot does not click “accept”. It renders the page as a first-time visitor who has consented to nothing, and that has three concrete consequences:
- Your field data skews toward the banner-present experience. Google’s CrUX data comes from real Chrome users, many of whom are first-time visitors seeing the banner. The page with the banner is your measured page.
- Content behind a consent wall can be invisible. If the tool blocks the page content until the user interacts, Google may index the wall instead of the content. Interstitial-style walls can also trip Google’s intrusive-interstitial signals on mobile. (They are also legally shaky, since consent has to be freely given, but that is the other article.)
- Consent-gated embeds are not indexed. If YouTube videos, maps or review widgets only load after consent, crawlers never see them. Sometimes that is fine; a map contributes nothing to ranking. Sometimes it is not: video results and review snippets disappear. The click-to-load placeholder is the correct pattern for compliance; just know the embedded content is invisible to search.
Then there is the measurement side. With analytics gated behind consent, which is required for Google Analytics and similar tools, you lose every non-consenting visitor from your data. In practice that is often somewhere between a third and two thirds of them. That is not a ranking factor, but flying half-blind makes every SEO decision worse. It is the core argument for cookieless measurement, covered in web analytics without cookies.
The fixes, in order of impact
- Load the consent script deferred, self-hosted if possible. A synchronous third-party script
in
<head>is the single worst pattern. Self-hosting removes a DNS lookup, a TLS handshake and a third-party dependency, and keeps the consent infrastructure on your own origin, in the EU. The reasoning is the same as in Danish hosting or US cloud. - Reserve the space, or overlay without pushing content. A bottom banner with
position: fixedcauses zero CLS. A top banner that pushes the page down is a guaranteed shift. If the tool injects late, pre-allocate its space with CSS. - Never block rendering of the actual content. The page paints first; the banner appears on top of it. Content should be fully server-rendered and crawlable regardless of consent state.
- Keep the banner’s JavaScript small. Consent scripts under 20 kB exist and are easy to build; 300 kB consent bundles also exist. Check yours in the coverage panel. The banner needs show/hide, two buttons, a preferences pane and a signal to your tag loader. It does not need a framework.
- Gate correctly: nothing non-essential fires before consent. This is the compliance half, and it is also performance: every blocked tracker is script weight a non-consenting visitor never pays. Verify with a clean profile and the network tab. A tag manager firing pixels before consent is both a rules violation and wasted bytes.
- Use placeholders for heavy embeds. A click-to-load YouTube placeholder is both the consent-correct and the fast pattern. An embedded player is 500 kB or more of JavaScript you skip entirely.
- Measure before and after in the field, not just in Lighthouse. Lab tests often understate consent-tool cost, because remote configuration fetches and A/B-tested banner variants behave differently in the wild. Watch CrUX or your own real-user data for two to four weeks around any change.
If you want the broader run-through of what else slows a page down, images and fonts included, it is in why your website is slow.
The stronger fix: need less consent
Every item above optimizes the banner. The higher-leverage move is shrinking what the banner has to do, because consent is only required for what is not strictly necessary:
- Replace consent-requiring analytics with a cookieless tool hosted in the EU: Umami, Plausible or a cookieless Matomo. No device storage, no personal data, no consent trigger for measurement, and you get all of your traffic data back instead of a consenting subset. The Danish DPA’s position on Google Analytics from September 2022 makes this the safer route anyway.
- Drop trackers that earn nothing. Most small-business sites carry pixels for ad campaigns that ended a year ago and heatmap tools nobody opens. Each removal is script weight and consent surface gone.
- Self-host fonts and static assets so no third-party requests need disclosure or gating at all.
A site that runs cookieless analytics and no ad pixels needs no consent banner. Zero banner bytes, zero CLS, zero consent wall in front of Googlebot, full analytics coverage. That end state is not reachable for every business; if you run paid social, you keep the pixel and the banner. But for a large share of small-business sites it is.
nbsweb.dk is the proof. We run self-hosted, cookieless Umami, we set no cookies, and there is no banner. You can check it while reading this: open the developer tools, look under Cookies, and there is nothing there. That is how we build by default.
What this costs to fix
Honest market ranges: a commercial consent platform runs DKK 0–450 a month at small-business scale, and a performance-focused consent implementation or clean-up from an agency typically lands at DKK 3,750–19,000 as a one-off, more if the tag stack is a mess. All prices ex. VAT.
Our own numbers: this is included in how we build. Our sites ship with either no banner (cookieless stack) or a slim, deferred, layout-stable consent layer, covered within the fixed prices on pricing: Start at DKK 3,995, Build from DKK 14,995, hosting and maintenance from DKK 375 a month. Performance tuning and ongoing technical SEO are part of the Growth plan at DKK 975 a month. For the wider budget picture, see what a website costs.
The takeaway: the conflict between compliance and technical SEO is real but almost entirely an implementation problem. A consent setup designed by someone who cares about both the rules and LCP costs you nearly nothing in rankings. A default snippet pasted into a tag manager costs you real Core Web Vitals headroom every day. If your PageSpeed report lists your consent tool among the top third parties, that is fixable, and it is the kind of work our SEO service exists for.
Frequently asked questions
Does Google penalize sites for having a cookie banner? No, not as such. Google measures what the banner does to the page: load time, layout shift, responsiveness. A fast, stable banner costs nothing. A slow one costs exactly what it costs.
Is a banner an “intrusive interstitial”? A small banner that overlays a corner or the bottom of the page is not. A full-screen wall that hides the content until the user acts can be, on mobile. Keep the content visible behind it.
Can I just remove the banner for speed? Only if you also remove what it covers. Drop the banner and keep the tracking, and you are worse off than before, both legally and in your data.
Will I lose data by going cookieless? The opposite. Consent-gated analytics count only the visitors who click accept. Cookieless measurement counts everyone, with less detail per person and no cross-site tracking. For most business sites, that is the better trade.
Why us
Cheaper than most, and not worse for it
We are three developers. No project managers, no salespeople, no open-plan office downtown. That overhead is what you would otherwise be paying on top of the work itself, and it is why we can keep the price down on websites, webshops, web apps and mobile apps alike. Every price is published and fixed in writing before we start — from DKK 375 a month or DKK 3,995 one-time. See prices.
Cheaper does not mean less. We build and run our own products: NBS Booking, NBS Food and the KalorieTracker app, which is live in the App Store and Google Play. So we have already paid for the mistakes we advise you about. You talk to the person writing the code, and you own the code afterwards. If you want to move on without us, you can.