Canonical Tags for AMP and Mobile URLs

Both setups run on a reciprocal pair of links

AMP pages and separate mobile (m-dot) URLs only work when the annotations are paired in both directions: the main page points out to its alternate, and the alternate points its canonical back. Leave out either half and Google has no confirmed pair to act on: an AMP page with no rel="amphtml" link from its twin may never be discovered or paired, and a one-way mobile annotation leaves Google to sort the two URLs out as ordinary duplicates rather than device versions.

The two configurations share a shape. In each, the same content is published at two URLs, and one of them exists only for a particular format or device. The difference is the attribute used on the outbound leg.

AMP, formerly Accelerated Mobile Pages, is an HTML framework for fast-loading pages. "Separate URLs" is Google's name for the m-dot pattern: a desktop site at example.com, a mobile site at m.example.com, and user-agent detection with redirects between them.

Paired AMP: amphtml out, canonical back

Google's AMP documentation says Search indexes AMP pages the way it indexes any other page and holds them to the same standard. It also requires every AMP page to link to a canonical, which may be a non-AMP twin or the AMP page itself. The AMP project's discovery guide shows the pair:

<!-- on the regular page: https://www.example.com/giraffes -->
<link rel="amphtml" href="https://www.example.com/amp/giraffes">

<!-- on the AMP page: https://www.example.com/amp/giraffes -->
<link rel="canonical" href="https://www.example.com/giraffes">

A standalone AMP page, with no regular version, still carries the tag, pointed at its own URL:

<link rel="canonical" href="https://www.example.com/giraffes">

Google suggests a predictable URL scheme, either an amp. subdomain or an /amp/ directory, which makes the pairing easy to audit with a pattern match. Two parity rules sit on top of the links. Users should be able to see the same content and complete the same actions on the AMP page as on the canonical where possible, and both pages should carry the same structured data. Parity has been enforced since February 1, 2018, when Google began sending users to the non-AMP page when the two did not match, so a teaser AMP page that truncates the article defeats the purpose of having one.

Separate mobile URLs: alternate out, canonical back

On an m-dot site, the desktop page announces its mobile counterpart with rel="alternate" and a media query, and the mobile page names the desktop URL as canonical. Google's mobile-first indexing best practices, which now absorb the old separate-URLs guide, give this pattern:

<!-- desktop page: https://example.com/ -->
<link rel="canonical" href="https://example.com/">
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/">

<!-- mobile page: https://m.example.com/ -->
<link rel="canonical" href="https://example.com/">

The mapping must be page to page. Redirecting every deep desktop URL to the m-dot homepage breaks the pair for all of them, because Google expects an equivalent mobile version of each desktop page. The same one-to-one rule applies to the redirects that route users between the hosts.

Google's general guide to consolidating duplicate URLs describes the same arrangement from the canonical side: a canonical page with a mobile twin on another URL should carry an alternate link pointing to it. That places the m-dot pair inside ordinary canonicalization, not in a separate mobile system, and it is why the Page indexing report files m-dot URLs under the same statuses as any other alternate.

What mobile-first indexing did not change

Mobile-first indexing (Google indexing and ranking the version of a site crawled by Googlebot Smartphone) created a reasonable-sounding argument: if Google indexes the mobile content, the mobile URL should be canonical. Google says otherwise. For separate URLs, the desktop URL is always the canonical and the mobile URL is its alternate. Mueller addressed the question directly in July 2024: "Tl;dr: no, don't change it."

The two facts fit together once canonical and content are separated. The canonical decides which URL represents the pair; mobile-first indexing decides which version's content is read. Google also serves the mobile URL to searchers on mobile devices even though the desktop URL is canonical, so the annotation does not cost mobile users anything.

What did change is the cost of a thin mobile site. Search Engine Roundtable reported Google's June 2024 announcement that remaining sites would move to smartphone crawling after July 5, 2024, with Mueller warning that content not accessible on a mobile device would no longer be indexable. Desktop crawling continues for some features, per that report. On an m-dot site, anything missing from the mobile pages is therefore missing from the index.

One loose end concerns the Vary: user-agent response header. Google's mobile-first page describes it as part of the dynamic serving and separate-URL setups, while Mueller said in 2024 that Google does not use Vary to understand the mobile and desktop relationship. The two readings reconcile if Vary is treated as a caching instruction rather than a signal to Google; do not count on it to establish the pair.

Keeping the m-dot and desktop versions in step

Under mobile-first indexing, every difference between the two hosts is a difference in what gets indexed. Google's checklist for separate URLs amounts to making the mobile site a complete copy with its own address:

• Identical robots.txt rules and robots meta tags; a noindex that exists only on m-dot applies to the version Google indexes.
• Equivalent structured data, titles and meta descriptions.
• Matching error behavior, so a URL that returns 404 on desktop does not return 200 on mobile.
• hreflang kept within each version: mobile URLs reference mobile URLs, desktop references desktop. The hreflang page covers the syntax.
• No URL fragments standing in for mobile pages.
• Both hosts verified in Search Console, and server capacity for the extra crawling of the mobile host.

AMP in Google Search today

Much of the pressure to build AMP came from Top Stories eligibility, and that pressure is gone. Google announced in May 2020 that AMP would stop being required for Top Stories on mobile, and the change took effect with the page experience rollout that began in mid-June 2021. Google also said in April 2021 that it would stop showing the AMP badge. AMP on desktop does not get search-specific features.

AMP is not deprecated in Search either. Google's AMP documentation was still being updated in 2026 and still describes the AMP status report and how to remove AMP. It is simply one way to build a page, with no eligibility advantage.

Removing it is a small migration, and the pair has to come apart in the right order. Google's removal steps are to delete rel="amphtml" from the canonical pages, then send the AMP URLs to their canonicals with a 301 or 302 (or return 404 if the AMP URLs should vanish everywhere), and watch the indexed AMP count fall in the AMP status report. Deleting AMP pages without redirects throws away whatever traffic and links still land on them.

Failure modes and how to spot them

• AMP page self-canonical with a twin present, or no canonical at all. The AMP page then presents itself as standalone, or fails Google's requirement outright.
• Missing rel="amphtml" on the regular page. The AMP version may never be found or paired. Google's AMP troubleshooting list asks about both links for this reason.
• Teaser AMP or mismatched structured data between the two versions.
• m-dot promoted to canonical because of mobile-first indexing, contrary to Google's guidance.
• Cross-version hreflang, with mobile pages pointing at desktop alternates.
• Different robots rules on the two hosts.

URL Inspection on an AMP or m-dot URL shows the user-declared canonical beside the Google-selected one; agreement there means the pair is working. The Page indexing report will list those alternates as "Alternate page with proper canonical tag," which is the intended outcome for this setup, not an error to fix. For AMP, the Search Console AMP status report and the Rich Results Test cover validation. For m-dot, crawl both hosts with a smartphone and a desktop user agent and diff the canonicals, alternates, hreflang, robots directives and body content. A quick curl -s https://m.example.com/ | grep -i canonical confirms the mobile page's canonical in the raw HTML. Bing publishes no current guidance on either pairing, so Google's documentation is the only reference to test against.

When to leave the configuration alone

A working m-dot setup with correct desktop-canonical annotations should keep them. The durable fix for m-dot is migrating to responsive design, which Google recommends as the easiest pattern to maintain; flipping the canonical to the mobile host is a change with downside and no documented upside.

A working AMP deployment with enforced parity likewise has no Search reason to be ripped out, and a site without AMP has no Search reason to add it. The decision now rests on maintenance cost and performance, not on eligibility. If it goes, treat it as a redirect migration.

Frequently asked questions