Should you really treat your AMP pages as primary content to ensure they are indexed?

What does "primary content" really mean in this statement?

When Müller refers to primary content, he distinguishes between two fundamentally different approaches. The first involves creating an AMP page as a mere technical adaptation of the desktop version — the same content, simply adjusted for the framework. The second approach treats AMP as an autonomous editorial entity.

Google evaluates this distinction during indexing. If your AMP is seen as a lightweight duplicate, it may be indexed but not prioritized in results. The engine seeks to identify whether this version offers distinct value or simply reformats existing content.

Why would Google make this technical distinction?

The AMP framework was designed for mobile performance, not as a content duplication system. Google wants to prevent its index from being polluted by redundant versions of the same page. If your strategy is to serve desktop in AMP form without editorial adaptation, you create a signaling issue for the algorithm.

Specifically, Google must decide: which version deserves to rank? If the AMP is just an empty shell around the desktop content, the engine will likely favor the original version. The risk then becomes diluting your ranking signals between two URLs that cannibalize each other.

How does this differ from traditional mobile version management?

With responsive or mobile-first design, you have a single URL that adapts. With AMP, you create a distinct URL — and that’s where it gets complicated. Google must understand the relationship between these URLs and decide which to index as the reference.

Müller’s statement suggests that this relationship only works well if the AMP is conceived from the outset as primary content, not a byproduct. In other words: if you start with a strategy of "first we do the desktop, then we adapt it to AMP", you miss the point. You need to think AMP-first or equivalent, not AMP-afterthought.

• AMP should not be a mere technical copy of the desktop version
• Google distinguishes between AMPs designed as standalone content and those that only serve as lightweight alternatives
• The main risk: creating URL cannibalization where no version clearly dominates
• The relationship between the desktop version and AMP needs to be considered from the editorial design stage, not added post-production
• The AMP framework was intended for performance, not to multiply indexable versions of the same content

Does this recommendation align with what we observe in the field?

Yes and no. On news sites that have massively adopted AMP, it is indeed noted that well-designed AMP pages perform better than desktop versions in mobile results. However, this performance often hinges more on loading speed than on special treatment of the content.

The problem is that Müller remains vague on the precise technical criteria that make an AMP considered as "primary content". Is it a matter of canonical? Editorial structure? User signals? [To be verified] since Google does not publicly document these thresholds.

What contradictions exist between this statement and recommended practices?

For years, Google promoted AMP as a mobile performance solution while insisting it was not a ranking factor. Now, Müller states that a poorly designed AMP may be indexed incorrectly. This is a subtle yet significant shift.

The contradiction becomes problematic when looking at the official guidelines on canonicals. Google recommends pointing the AMP canonical to the desktop version — which explicitly suggests that the desktop is the primary version. Müller now states the opposite for optimal indexing. This documentary inconsistency creates confusion among practitioners.

In what cases does this rule not really apply?

If your site uses mobile-first responsive design and you do not utilize AMP, this statement does not directly concern you. Similarly, if you use AMP solely for newsletters or embedded content, the notion of "primary content" becomes questionable.

More interesting: e-commerce sites that have tested AMP on product pages have often abandoned it, noting that the framework's limitations hindered their ability to convert effectively. In this context, treating AMP as primary content would have been counterproductive. Müller’s advice mainly applies to pure editorial content.

What should you concretely do if you are already using AMP?

Start by auditing your current AMP pages. Ask yourself: does this AMP version offer something specific or is it just a lightweight version of the desktop? If it’s the latter, you are in a scenario that Müller advises against.

Then, check your canonical tags. If all your AMPs point to the desktop as the primary version, you are explicitly signaling to Google that AMP is secondary. To align with Müller’s recommendation, you would need to reverse this logic — but be careful, this change can have massive impacts on your existing indexing.

What mistakes should you avoid in designing new AMP pages?

Never create an AMP page "just because you need one". This is the worst approach. If you launch AMP, start with a clear editorial strategy: what content, for what mobile use, with what added value compared to the desktop?

Avoid also blindly duplicating desktop content by merely removing heavy scripts. Google detects these duplications and may treat them as thin content. If the AMP does not add more than a degraded version, it’s better not to create it.

How can you check that your AMPs are indexed as primary content?

Use the Search Console to compare the performance of your AMP URLs versus desktop. If your AMPs generate significant impressions and clicks on mobile, that's a good sign. If they are indexed but invisible in analytics, you probably have a prioritization signal issue.

Also test in direct mobile search: do your AMPs appear in the Top Stories carousel or in standard organic results? The position in mobile SERPs often reveals how Google treats these pages. An AMP relegated to the bottom of results while the desktop version ranks well is a clear indicator of a problem.

• Audit all your existing AMP pages to identify if they are designed as primary content or simple alternatives
• Check the consistency of your canonical tags and measure the potential impact of reversing this logic
• Analyze Search Console data to compare AMP vs. desktop performance on mobile
• Do not launch new AMP pages without a clear editorial strategy and defined added value
• Regularly test your AMPs in mobile search to verify their real visibility in SERPs
• Document technical choices to avoid inconsistencies between editorial and technical teams