Why AMP Pages Need a Different Approach to Cookie Consent
Accelerated Mobile Pages strip away most of what makes standard websites flexible. Custom JavaScript is banned. Third-party scripts load only through approved AMP components. This locked-down environment creates a real problem for cookie consent: the tools and scripts that power a typical cookie banner simply will not run on an AMP page.
Google introduced the <amp-consent> component specifically to fill this gap. It provides a native way to collect user consent, store that decision in the browser, and conditionally block other AMP components based on the outcome. The component shipped in 2018 ahead of the GDPR enforcement deadline and has since expanded to support the IAB Transparency and Consent Framework (TCF) v2.2.
The catch is that AMP consent works differently from a standard CMP. You cannot automatically scan and block cookies the way you would on a regular site. Every third-party component must be manually tagged with blocking attributes, and granular category-based consent (analytics vs marketing vs functional) is not natively supported outside of the TCF framework.
How the amp-consent Component Works
The <amp-consent> component is the only permitted method for managing consent on AMP pages. Only one instance is allowed per page. It uses a JSON configuration block to define consent behaviour, display a prompt UI, and communicate with a remote server endpoint if needed.
At its core, the component tracks three consent states: accepted, rejected, and unknown. When a visitor first arrives and no stored decision exists, the state is unknown. The component then displays your consent prompt. Once the visitor clicks accept or reject, that decision is cached in localStorage under the key amp-store:{domain} and reused on subsequent page loads.
Here is the basic structure:
<amp-consent id="myConsent" layout="nodisplay"> wraps a <script type="application/json"> block containing the configuration. The key properties are:
| Property | Purpose | Required |
|---|---|---|
consentInstanceId | Unique identifier for the consent instance | Yes |
consentRequired | Whether consent is needed (boolean or "remote") | Yes |
promptUI | ID of the child element containing the banner UI | Yes |
checkConsentHref | Server endpoint to check or retrieve consent state | No |
onUpdateHref | Endpoint that receives consent state changes | No |
geoOverride | Location-based configuration overrides | No |
The promptUI property points to a <div> inside the <amp-consent> element. This div contains your banner markup - headings, explanatory text, and accept/reject buttons that call on="tap:myConsent.accept" or on="tap:myConsent.reject" respectively.
Blocking Third-Party Components Until Consent
On a standard website, a CMP can intercept and block scripts before they execute. AMP does not allow this. Instead, you must add a data-block-on-consent attribute to each AMP component that should wait for consent.
For example, to block Google Analytics until consent is granted:
<amp-analytics data-block-on-consent type="gtag">
The attribute accepts several predefined values. _till_responded blocks until the visitor makes any choice (accept or reject). _till_accepted blocks until the visitor explicitly accepts. _auto_reject treats the component as rejected if no consent is given. For most analytics and marketing cookies, _till_accepted is the correct choice under GDPR consent requirements.
This manual approach is the biggest limitation of AMP consent. Every component that sets non-essential cookies or trackers needs individual attention. Miss one, and you have a compliance gap.
Components That Typically Need Blocking
The following AMP components set cookies or trigger tracking and should be blocked until consent:
<amp-analytics>- Google Analytics, Adobe Analytics, and other measurement tools<amp-ad>- display advertising from ad networks<amp-pixel>- tracking pixels including Meta Pixel and similar<amp-social-share>- social sharing buttons that may load third-party scripts<amp-youtube>- YouTube embeds that set cookies<amp-iframe>- any iframe loading external content with trackers
Components that serve a strictly functional purpose, such as <amp-form> or <amp-carousel>, generally do not need blocking.
Geo-Targeting Consent with amp-geo
Not every visitor needs a consent prompt. Under the ePrivacy Directive, consent for non-essential cookies is mandatory in the EEA. Under the CCPA, an opt-out model applies in California. Visitors from other regions may not require a prompt at all.
The <amp-geo> component detects the visitor's country and assigns them to a geo group. You then use geoOverride in the amp-consent configuration to apply different rules per group. A common setup creates three groups: EEA countries where consentRequired is true, US states where a different prompt style applies, and the rest of the world where consent may be optional.
This mirrors the geo-detection features available in full CMP solutions, though with less flexibility. You define country lists manually in the <amp-geo> JSON configuration rather than relying on automatic detection.
The Granular Consent Problem
Under GDPR Article 5(3) and the ePrivacy Directive, visitors should be able to accept or reject cookies by category - analytics, marketing, functional, and so on. Most modern CMPs offer this granular control as standard. AMP does not.
The <amp-consent> component natively supports only a binary accept/reject model. A visitor either consents to everything or rejects everything. There is no built-in mechanism for cookie categories.
Two workarounds exist. The first is to use IAB TCF purpose-based consent, where the TCF string encodes granular purpose selections and vendors parse it accordingly. The second is to use purposeConsentRequired and data-block-on-consent-purposes attributes, which let you define custom purpose names and block components per purpose. This approach is newer and requires more manual configuration.
Neither option is as straightforward as a standard CMP with automatic cookie scanning and category assignment. If your AMP pages carry significant advertising or analytics, the limitations may outweigh the performance benefits of AMP itself.
Integrating a CMP with AMP Pages
Rather than building a consent flow from scratch, you can integrate a consent management platform that supports AMP. The integration typically works by hosting an HTML file on your own domain that loads the CMP configuration, then referencing that file from the checkConsentHref property.
The flow works like this:
- The AMP page loads and the
<amp-consent>component sends a request tocheckConsentHref - Your hosted endpoint returns whether consent is required and any previously stored consent state
- If consent is needed, the prompt UI displays
- The visitor's decision is sent to
onUpdateHreffor server-side storage
This approach lets you synchronise consent across AMP and non-AMP versions of the same page. The server endpoint can read existing consent cookies and return the appropriate state, avoiding repeated prompts when visitors switch between page versions.
Practical Implementation Checklist
Getting cookie consent right on AMP pages requires careful planning. Use this checklist to cover the essentials:
| Step | Action | Notes |
|---|---|---|
| 1 | Add the amp-consent script to <head> | amp-consent-0.1.js from the AMP CDN |
| 2 | Add <amp-geo> if using geo-targeting | Define country groups for EEA, US, and rest of world |
| 3 | Create the consent JSON configuration | Set consentInstanceId, consentRequired, and promptUI |
| 4 | Design the banner UI inside the consent element | Include accept and reject buttons with equal prominence |
| 5 | Audit all AMP components on the page | Identify which ones set non-essential cookies |
| 6 | Add data-block-on-consent to each tracked component | Use _till_accepted for analytics and ads |
| 7 | Set up checkConsentHref if syncing with a CMP | Must be same-origin HTTPS endpoint |
| 8 | Test consent flow in Chrome DevTools | Verify blocked components do not load before consent |
Pay particular attention to step 6. Unlike a standard website where a CMP can automatically block scripts, AMP requires you to tag every component individually. A cookie audit of your AMP pages will reveal which components need the blocking attribute.
Common Mistakes to Avoid
Several pitfalls trip up publishers implementing consent on AMP:
Missing the reject button. AMP makes it easy to add an accept action but some publishers forget to include a reject button with equal visibility. Under GDPR and dark pattern enforcement, both options must be equally accessible. CNIL has fined organisations for making rejection harder than acceptance.
Forgetting to block amp-ad. Display advertising components set multiple third-party cookies. Leaving <amp-ad> unblocked means ad networks drop cookies before consent, violating Article 5(3) of the ePrivacy Directive.
Not testing the rejected state. After rejecting consent, verify that no analytics or advertising requests fire. Use the Network tab in DevTools to confirm that blocked components remain silent.
Ignoring non-AMP page sync. If your site serves both AMP and standard pages, consent decisions must carry across. Without a shared server-side consent store, visitors may see repeated banners, creating a frustrating experience and potential consent fatigue.
Frequently Asked Questions
Do AMP pages need cookie consent?
Yes. AMP pages are subject to the same privacy regulations as standard web pages. If your AMP page uses analytics, advertising, or any non-essential tracking, you must obtain consent under the GDPR and ePrivacy Directive before those components load.
Can I use a regular cookie banner JavaScript on AMP pages?
No. AMP prohibits custom JavaScript. You must use the <amp-consent> component, which is the only approved method for collecting consent on AMP pages. Some CMPs offer AMP-specific integrations that work through this component.
Does amp-consent support granular cookie categories?
Not natively in the traditional sense. The default model is binary accept/reject. Granular consent is possible through IAB TCF purpose strings or the newer purposeConsentRequired configuration, but both require significant manual setup compared to a standard CMP.
How do I block Google Analytics on AMP until consent is given?
Add the attribute data-block-on-consent="_till_accepted" to your <amp-analytics> element. This prevents the analytics component from loading until the visitor explicitly accepts consent.
Can I show the consent banner only to European visitors on AMP?
Yes. Use the <amp-geo> component to detect the visitor's country and assign them to a geo group. Then use geoOverride in the amp-consent configuration to set consentRequired: true only for EEA countries.
Where does AMP store consent decisions?
Consent decisions are cached in the browser's localStorage under the key amp-store:{domain}. For cross-page or cross-device persistence, you need a server-side endpoint configured through checkConsentHref.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
