Consent signals on AMP pages: the stripped-down consent problem
AMP pages are the stripped-down, fast-loading versions of your articles that search engines serve to mobile visitors. They are also consent dead zones. The AMP runtime restricts JavaScript, which means your carefully built consent flow, the banner, the blocking rules, the TCF string handling, mostly does not run there. The visitor who carefully refused tracking on your main site gets the AMP version, where none of those choices apply.
This matters more than its shrinking hype suggests. AMP pages still serve meaningful mobile traffic for publishers, and they still fire ad requests. An ad stack that respects consent on the canonical page but ignores it on the AMP page has a hole shaped exactly like your mobile audience.
Why consent breaks on AMP
AMP allows only its own components and a restricted set of scripts. Your consent management platform's full JavaScript bundle is not among them. Instead, AMP provides its own consent component, amp-consent, which shows a consent prompt and stores the decision. But that decision lives in the AMP context. Getting it into your ad stack, your TCF string, and your vendor calls requires explicit wiring that most publishers never build.
The typical failure is silent divergence. The main site collects a TCF consent string and passes it to the ad stack. The AMP page shows the AMP consent prompt, stores a separate decision, and the ad tags on the AMP page fire with a default or missing consent signal. The two pages disagree about what the visitor chose, and the ad stack follows whichever signal the page provides, which on AMP is usually the permissive one.
The consent string has to travel
The fix is to make the AMP page produce the same consent artifacts as the canonical page. That means configuring amp-consent to capture the visitor's choice in the same purposes and vendor framework, generating the TCF string from that choice, and passing it to every ad call on the page: header bidding, ad server requests, and any server-side bidding that reads the string.
Most CMPs offer an AMP-specific integration for exactly this. The catch is that it is a separate integration, configured separately, and it defaults to off in many setups. Teams that integrated the CMP on their main site assume AMP is covered. It is not, until someone configures the AMP path deliberately.
Watch the purpose mapping
The subtle failure is purpose mismatch. The AMP consent prompt might offer a simple accept or reject while the main site offers granular purposes. When the AMP decision gets translated into a TCF string, the mapping has to be consistent: a reject on AMP must produce the same string as a reject-all on the canonical page. If the mapping is approximate, the ad stack receives a string that claims consent the visitor never gave, or withholds consent they did give, and both directions cost you.
Test this by comparing strings, not interfaces. Capture the TCF string the canonical page produces for a reject-all, then capture the string the AMP page produces for its reject, and diff them. The interfaces can look completely different. The strings must match.
The traffic-share trap
Teams deprioritize AMP consent work because AMP is a small share of traffic and getting smaller. That is the wrong math. The risk is not proportional to traffic share; it is proportional to the gap between your claimed consent posture and your actual one. A regulator or a vendor audit does not grade on a curve for small pages. One AMP page firing ad requests without a valid consent string is a finding, regardless of how few visitors see it.
The pragmatic answer for many publishers is to reduce the problem: fewer AMP pages, or AMP pages with a reduced ad setup that needs less consent machinery. Every AMP page you keep is a page whose consent path you must maintain. Audit whether the traffic justifies the maintenance.
The bottom line
AMP pages run a parallel consent universe with its own prompt, its own storage, and its own defaults, and your ad stack follows whichever universe the page is in. Wire the AMP consent path to produce the same TCF strings as your canonical pages, diff the strings for reject-all parity, and question whether each AMP page earns its maintenance. Consent that stops at the canonical page is consent with a mobile-sized hole in it.
Common questions
Is AMP still relevant enough to worry about?
For publishers with legacy AMP setups, yes. The traffic may be declining, but the consent obligation does not decline with it. Either maintain the consent path or retire the pages.
Can one CMP cover both canonical and AMP pages?
Usually, but through two separate integrations. The CMP's main-site JavaScript and its AMP component are different products to configure. Covering one does not cover the other.
What is the simplest compliant AMP setup?
An AMP page that shows the consent prompt before any ad call, maps the decision to a proper TCF string, and passes that string to every ad request. Or no ads on AMP at all, which removes the problem instead of solving it.