Consent Banners on AMP Pages: The Component, Not the Script

A consent banner on an AMP page is a different animal from the one on your main site. AMP restricts the scripts you can run, the banner has to be a component, and the consent state has to travel with the user back to the canonical page. Get any of those wrong and the consent is not valid.

AMP does not run your banner

An AMP page is a stripped-down page with a strict set of rules, and one of those rules is that custom JavaScript does not run. Your normal consent banner, which is a JavaScript widget, will not run on an AMP page at all. The banner has to be built with amp-consent, the AMP component for consent management, which renders a prompt, stores the consent state, and blocks other AMP components from running until the user has chosen.

The component works by gating. Other components, like amp-analytics, declare that they need consent, and amp-consent holds them back until the user answers. That is the right shape, and it is the shape the law requires: no tracking before consent. But it only works if every tracking component on the page declares the gate. A single analytics component that does not declare consent will run before the user chooses, and the banner will be a decoration on a page that is already non-compliant.

The Global Privacy Control post covered the same principle for the main site: the signal has to reach the scripts, not just the banner. On an AMP page, the mechanism is amp-consent, and the test is the same: check the network requests, not the banner.

Consent has to travel

An AMP page is usually a copy of a canonical page, served from a cache, and the user can move between the two. The consent state has to travel with them, or they will be asked twice, and the two answers can contradict each other. The usual mechanism is a shared cookie or a consent string that both pages read, set by the consent management platform on both the AMP and the canonical page.

The failure to watch for is a consent state that is stored in local storage on the canonical page and not on the AMP page, or the other way around. Local storage does not travel between the AMP cache and the origin, so a choice made on one page does not exist on the other. The fix is to use a cookie, which does travel, and to test the journey from the AMP page to the canonical page and back, checking that the banner does not reappear and that the choice is the same.

The consent mode modelling post showed what happens when the consent state is lost: the model fills the gap with a guess, and the guess is not consent. The AMP journey is the same failure at a different scale, and the fix is the same discipline: the state has to be stored where both pages can read it.

Test the network, not the banner

The test for an AMP consent banner is a network trace, not a screenshot. Load the AMP page with the cache cleared, and watch the network requests before you answer the prompt. If any tracking request fires, the banner has failed, whatever it looks like. Then answer the prompt, reject, and watch again. If tracking still fires, the gate is not working. Then accept, and check that the consent state is stored in a cookie that the canonical page can read.

The AMP validator will catch markup errors in the amp-consent component, but it will not catch a tracking script that runs too early. Only a network trace catches that, and it is the test that matters. A consent banner that looks right and tracks anyway is the worst kind of failure, because it is invisible to the user and visible to the regulator.

Frequently asked questions

What component shows a consent banner on an AMP page?

amp-consent, the AMP component for consent management. It renders a prompt, stores the consent state, and blocks other AMP components from running until the user has chosen. Your normal banner script will not run on an AMP page, because AMP restricts custom JavaScript, so the component is the only option.

Does consent on an AMP page carry over to the main site?

The consent state has to be shared between the AMP page and the canonical page, usually through a shared cookie or a consent string that both pages read. If the AMP page and the canonical page store consent separately, the user has to choose twice, and the second choice can contradict the first.

Can analytics run before the user answers the AMP consent prompt?

No. The banner has to appear before any tracking script runs, and the scripts have to be blocked until the user chooses. An AMP page that loads analytics before consent is collected is not compliant, whatever the banner says.

Can I style the AMP consent prompt to match my main banner?

Use the promptUI and the checkConsentHref attributes of amp-consent to show a custom prompt, with the same accept and reject options as your main banner. The prompt has to offer a genuine reject, not just an accept, and the reject has to be as easy to reach as the accept.

How do I test an AMP consent banner?

Test the AMP page in the AMP validator and in a real browser, with the cache cleared, and check that no tracking request fires before consent. The validator catches markup errors, but only a network trace catches a tracking script that runs too early.