You are currently viewing How AMP Changes Cookie Handling

How AMP Changes Cookie Handling

How AMP Changes Cookie Handling

When you convert a standard web page to AMP (Accelerated Mobile Pages), one of the first surprises is how differently cookies behave. AMP restricts custom JavaScript, which means you cannot rely on the usual document.cookie or a third-party cookie script. Instead, AMP provides its own components — amp-analytics and amp-consent — to manage cookies in a controlled, privacy-respecting way. If you are building an AMP page that needs to store user preferences, session tokens, or tracking identifiers, you must adapt your cookies policy accordingly.

Mobile AMP page showing cookie consent dialog

Why a Dedicated Cookies Policy Matters for AMP

A cookies policy is not just a legal checkbox; it is a technical specification that tells users and regulators exactly which cookies your AMP page sets, for what purpose, and how they can control them. Under the GDPR and ePrivacy Directive, consent must be obtained before setting non-essential cookies. AMP’s amp-consent component was built to enforce this — it blocks cookie-setting components until the user explicitly agrees. If you skip implementing a proper cookies policy and consent flow, your AMP page could be non-compliant, and worse, your analytics or advertising scripts might never fire.

Key Differences: Standard Web vs. AMP Cookie Management

Aspect Standard Web Page AMP Page
JavaScript Control Full access to document.cookie No custom JS; uses AMP components
Cookie Setting Via JS or server-side Set-Cookie Via amp-analytics config or amp-consent actions
Consent Enforcement Manual implementation Built-in amp-consent blocks cookies until granted
Third-Party Cookies Possible with iframes or scripts Restricted; requires amp-iframe and careful policy
Cookie Policy Display Custom banner Use amp-consent UI or custom overlay

Implementing a Cookies Policy with AMP Components

To create a cookies policy that works on AMP, you need two things: a clear written policy page (linked from the consent banner) and the amp-consent component to manage consent logic. Here is a practical step-by-step.

Step 1: Write Your Cookies Policy

Your policy must list every cookie used on the AMP page, including those set by amp-analytics, amp-ad, or any embedded third-party service. For each cookie specify:

  • Name and domain
  • Purpose (e.g., session management, analytics, personalization)
  • Duration (session or persistent)
  • Whether it is essential or non-essential

Host this policy at a stable URL (e.g., /cookies-policy) and reference it in your consent configuration.

Step 2: Add the amp-consent Component

Include the script for amp-consent in your page :

<script async custom-element="amp-consent" src=";

Then define the consent configuration, typically as a JSON block inside an <script type="application/json"> element:

{
  "consents": {
    "my-consent": {
      "promptIfUnknownFor": "all",
      "promptUI": "myConsentUI"
    }
  },
  "postPromptUI": "post-consent-ui"
}

Code editor with AMP consent configuration

Step 3: Build the Consent UI

Create a simple banner using AMP HTML that appears when consent is needed. For example:

<amp-consent id="my-consent">
  <script type="application/json">{ ... }</script>
  <div id="myConsentUI">
    <p>We use cookies to improve your experience. Read our <a href="/cookies-policy">Cookies Policy</a>.</p>
    <button on="tap:my-consent.accept">Accept</button>
    <button on="tap:my-consent.reject">Reject</button>
  </div>
</amp-consent>

Step 4: Configure amp-analytics to Respect Consent

Link your analytics configuration to the consent by adding a data-consent-blocking attribute:

<amp-analytics type="googleanalytics" data-consent-blocking="my-consent">
  <script type="application/json">{ ... }</script>
</amp-analytics>

This ensures that analytics cookies are set only after the user accepts.

Security and Privacy Considerations

AMP’s sandboxed environment reduces the risk of cookie theft via XSS, but you still need to protect sensitive data. Never store authentication tokens in cookies that are accessible by third-party components. Use SameSite=Lax or Strict and the Secure flag. For developers dealing with ad‑related cookies, understanding Ads.txt is equally important — see our post on Why Every Developer Should Understand Ads.txt for how publishers declare authorized sellers and reduce ad fraud.

Common Pitfalls

  • Forgetting to list all cookies – AMP components like amp-user-notification may also set cookies. Audit your page with amp-cache-viewer or browser dev tools.
  • Blocking essential cookies – Do not put consent blocking on cookies required for core functionality (e.g., session tokens for login). Mark them as essential in your policy and skip the consent prompt.
  • Ignoring the AMP Cache – Google’s AMP Cache serves your page from a different domain, which can affect cookie scope. Test on both the canonical URL and the cached version.

Testing Your Cookies Policy Implementation

After deploying your AMP page, verify consent logic by testing with browser developer tools — ensure the cookie is set only after explicit user agreement. Clear site data, reload, and confirm that no analytics requests fire before consent. Use the AMP validator to check for component errors. A correctly implemented cookies policy keeps you compliant and gives users a clear choice over their data. For a real-world test, load your page from Google’s AMP Cache using the ?amp_js_v=0 parameter and check that the consent banner appears as expected on the cached version.