Is AMP traffic distorting your SEO statistics?

Why does AMP traffic appear as external?

The problem lies in the very architecture of AMP. When a user clicks on an AMP result in Google, they first access a version hosted on Google's cache servers (cdn.ampproject.org or google.com/amp).

From the perspective of Analytics, this AMP cache page constitutes a differentiated domain from your main site. When the user then navigates to a standard page of your site, the transition from AMP to a standard site is interpreted as a visit coming from an external domain.

What concrete impact does this have on your Analytics data?

Your reports then display cdn.ampproject.org as a traffic source, instead of google/organic. This distortion complicates the reading of acquisition channels and creates disruptions in user journeys.

Conversions attributed to AMP get diluted among external referrals. It becomes impossible to accurately measure the ROI of your AMP pages or isolate their contribution to actual organic traffic.

What technical adjustments can correct this anomaly?

First, you need to implement the AMP Analytics client ID API, which maintains session continuity between AMP and non-AMP. Adding linker parameters in amp-analytics transmits the Google Analytics session ID from one domain to another.

In Google Analytics, configure referral exclusion for cdn.ampproject.org and google.com/amp. This action forces Analytics to ignore these domains as external sources and to trace back to the true origin of traffic.

• The AMP cache creates a domain break that misleads analytics tools.
• Attribution of AMP conversions is impossible without specific tracking adjustments.
• The client ID API maintains session continuity between AMP and standard versions.
• Referral exclusions in Analytics are mandatory to clean reports.
• Without technical correction, your actual organic traffic is undervalued in your dashboards.

Does this statement truly reflect the complexity of the problem?

John Mueller remains deliberately vague about the real extent of this distortion. In reality, sites that have heavily invested in AMP without correcting their tracking have observed gaps of 15 to 40% in organic traffic attribution.

The term "necessary technical adjustments" minimizes the challenge. Properly implementing the AMP linker requires a sharp mastery of Google Tag Manager and amp-analytics. Configuration errors are common and silent: your data remains incorrect without you noticing. [To be verified] on your own setup with rigorous cross-domain tests.

What nuances should be added to this statement?

Let’s be honest: AMP has become less critical since the rollout of the Page Experience update. Google no longer favors AMP in mobile results as it used to. Many sites have abandoned AMP without a negative impact on their visibility.

The tracking issue described by Mueller therefore concerns only a decreasing fraction of sites still using AMP. If you hesitate to invest development time in this correction, first ask yourself: Does AMP still bring measurable value to your organic traffic? In most cases, the answer is no.

In what situations does this rule not apply?

If you use AMP only for stories or isolated non-transactional content, the attribution problem is negligible. Users consume AMP content without bouncing back to the main site, thus no session break to correct.

Similarly, sites that have migrated to non-AMP solutions optimized for Core Web Vitals (like well-configured modern frameworks) completely escape this problem. The real question is no longer "how to track AMP correctly" but "why continue using AMP"?

What concrete steps should be taken to correct AMP tracking?

The first step: implement amp-analytics with the linker component. In your JSON configuration, add the linker object pointing to your main domain and include the _gl parameters to transmit the client ID.

Next, in Google Analytics, navigate to Tracking Info > Referral Exclusion List. Add cdn.ampproject.org, google.com/amp, and all AMP cache variants used by Google. This action forces Analytics to ignore these domains as external sources and to trace back to the true origin of traffic.

What mistakes should be avoided during implementation?

The most common mistake: configuring the AMP linker but forgetting to accept _gl parameters on the main site. If your standard tracking is not set up to read these parameters, session continuity fails and the data remains incorrect.

Another classic trap: adding referral exclusions in Analytics without first setting up the linker. The result: AMP traffic completely disappears from your reports instead of being accurately attributed. The order of operations matters: linker first, exclusions second, validation through cross-domain tests last.

How can you verify that the configuration works correctly?

Use the debug mode of amp-analytics to trace the events transmitted. Check that the _gl parameter properly appears in the URLs transitioning from AMP to standard site. In Analytics, monitor the Real-time reports during your tests: AMP traffic should be attributed to the organic source, not cdn.ampproject.org.

Create custom segments in Analytics isolating sessions that have accessed an AMP page. Compare the attribution before and after correction: if cdn.ampproject.org disappears from sources in favor of google/organic, your configuration works. Otherwise, go back to check the JSON syntax of your linker and the cross-domain cookie propagation.

• Implement amp-analytics with the linker component and configured _gl parameters.
• Add cdn.ampproject.org and google.com/amp to the Analytics referral exclusions.
• Configure standard tracking to accept and read _gl parameters transmitted by AMP.
• Test in debug mode and check attribution in Real-time reports.
• Create segments in Analytics to isolate and measure corrected AMP traffic.
• Document the configuration for future technical site evolutions.