Canonical page, mobile site, AMP: Why does Google differentiate between these three versions?

Why does Google recognize three distinct versions of the same page?

Technically, Google treats each URL as a separate entity, even if the content is identical. The canonical page represents your reference URL, the one you want to see indexed and ranked in search results.

The mobile site is an optimized version for touch screens, often hosted on a subdomain (m.example.com) or a dedicated directory (/mobile/). AMP, on the other hand, is a specific technology developed by Google that imposes simplified HTML and strict constraints to ensure near-instant loading.

Do these three versions still coexist in today’s web ecosystem?

The ground reality is more nuanced. Since mobile-first indexing, most modern sites use a single responsive design that serves as both the canonical and mobile version. Separate mobile sites (m.example.com) have been in pronounced decline for several years.

AMP has also seen a significant decline after Google removed the lightning badge and the advantage in the Top Stories carousel. Many sites have abandoned it in favor of Core Web Vitals optimizations on their classic pages.

What signals does Google use to connect these versions?

Google relies on specific HTML tags to understand the relationship between these URLs. The canonical tag indicates which version is the main one, while alternate annotations specify the mobile or AMP variants.

Without these signals correctly configured, Google may index the wrong version, dilute your authority across multiple URLs, or completely ignore certain variants. This is a common issue on sites that have maintained a separate mobile architecture without proper maintenance.

• Canonical page: reference version, often desktop or responsive, contains the full content
• Mobile site: touch-optimized variant, may have reduced content or simplified navigation
• AMP: ultra-light version with restricted HTML, limited inline CSS, and JavaScript controlled by Google
• Cross annotations: each version must point to the others with the appropriate tags (canonical, alternate, amphtml)
• Mobile-first indexing: Google primarily indexes the mobile version, making the canonical/mobile distinction less relevant for responsive sites

Does this distinction still reflect the reality of modern web architectures?

Let’s be honest: this statement sounds like recycled dated documentation. The separation between the canonical page and mobile site is a remnant from the pre-responsive era, when sites actually maintained two distinct versions (www and m.).

Today, the overwhelming majority of professional sites use a single responsive design that serves as both canonical and mobile. This architecture naturally eliminates duplication issues and simplifies signal management for Google. Continuing to present the canonical/mobile distinction as standard is misleading.

Is AMP still worth mentioning as a viable option?

AMP lost its main competitive advantage when Google removed the lightning badge and opened the Top Stories carousel to non-AMP pages. Ground data shows a massive abandonment: major sites like The Guardian, Reddit, or Le Monde have removed their AMP versions.

Maintaining AMP represents a significant development and maintenance cost for a benefit that now sums up to a marginal loading speed gain. This gain is often nullified by functional limitations (tracking, monetization, interactivity) that frustrate publishers. [To be verified]: Google communicates little about current AMP adoption statistics.

What are the real risks of mismanaging these distinctions?

The main danger involves legacy sites that have retained a separate mobile architecture without properly implementing annotations. Google may then index m.example.com instead of www.example.com, causing confusion and dilution of authority.

With AMP, the risk is different: if the amphtml and canonical tags are not symmetrical, Google may treat the two versions as duplicate content and apply filters. Worse, it may choose to index only the AMP version, depriving your analytics of complete data and blocking certain essential third-party scripts.

What should I do if my site still uses a separate mobile subdomain?

The first question to ask yourself is: why are you keeping this outdated architecture? Migrating to a single responsive design should be your top priority. It eliminates duplication issues, simplifies your code, and aligns your site with current standards.

In the meantime, ensure that each mobile page contains <link rel="canonical" href="https://www.example.com/page"> and that each desktop page includes <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">. Test these annotations in the Google Search Console Coverage section.

How can I decide if AMP is still worth it for my site?

Analyze your Core Web Vitals on your normal pages. If you are already meeting green thresholds (LCP < 2.5s, FID < 100ms, CLS < 0.1), AMP will only provide a marginal gain. The juice is probably not worth the squeeze.

If you are a news site publishing dozens of daily articles with catastrophic CWV scores, AMP may offer a quick workaround. But consider it temporary: simultaneously invest in optimizing your classic pages to phase out AMP in the medium term.

What technical checks should be performed to avoid configuration errors?

Use Google’s Mobile Optimization Test tool to confirm that your mobile version is correctly detected. Check in Search Console that Google is indexing the version you want (look at the indexed URL in the Coverage report).

For AMP, the official validator (validator.ampproject.org) is essential. A single non-compliant HTML element is enough to invalidate the entire page. Also, check that your canonical/amphtml tags form a coherent cycle between AMP and non-AMP versions.

• Audit all pages to check the consistency of canonical and alternate tags
• Confirm in Search Console which version (desktop/mobile/AMP) Google is actually indexing
• Test the content parity between versions: the mobile/AMP version must not lack key elements present on the desktop
• Monitor Core Web Vitals reports to assess if AMP provides measurable benefits
• Plan a migration to responsive if you are still maintaining m.example.com
• Validate all AMP pages with the official validator and fix critical errors