AMP and Deep Linking: Current State and Future

AMP (Accelerated Mobile Pages) changed how mobile web content was served, and those changes created specific challenges for deep linking. AMP pages are served from Google's cache at cdn.ampproject.org or via the AMP viewer in Google Search. This means the URL a user sees is not your domain, which breaks Universal Links and App Links that depend on domain verification.

This guide covers the current state of AMP and deep linking, what has changed since Google de-prioritized AMP, and how to handle AMP-to-app transitions. For broader deep linking standards, see deep linking standards in 2026. For the future of mobile deep linking, see the future of mobile deep linking.

How AMP Broke Deep Linking

The URL Problem

When Google served AMP pages, the URL in the browser was not your domain:

Your URL:    https://yoursite.com/article/summer-deals
AMP Cache:   https://cdn.ampproject.org/c/s/yoursite.com/article/summer-deals
AMP Viewer:  https://www.google.com/amp/s/yoursite.com/article/summer-deals

Universal Links and App Links verify the domain. If the user is on cdn.ampproject.org or google.com/amp/, your app's domain verification does not match, and the OS will not open your app.

The Referrer Problem

When a user tapped a link on an AMP page, the HTTP referrer was cdn.ampproject.org or google.com, not your original page. This broke:

• Attribution: Analytics could not tie the click back to your content.
• Deferred deep linking: The referrer chain was lost, making post-install routing less reliable.

The JavaScript Problem

AMP restricted JavaScript execution. Custom deep linking scripts (checking if the app is installed, attempting a custom scheme redirect) did not work in AMP pages. Only standard <a> tags with simple href attributes were allowed.

Google's AMP Pivot

Signed Exchanges

In 2021, Google introduced Signed HTTP Exchanges (SXG) as an alternative to the AMP cache. With SXG, your content is cryptographically signed and served from Google's cache, but the browser shows your original URL.

This solved the deep linking URL problem: since the browser displays your domain, Universal Links and App Links work correctly.

Core Web Vitals as the Ranking Signal

Google announced that Core Web Vitals (LCP, FID, CLS), not AMP specifically, would be the ranking signal for mobile search. This means:

• You do not need AMP to rank well in mobile search.
• Fast, well-optimized regular pages get the same treatment.
• The "AMP badge" in search results is gone.

Current AMP Status

AMP is still maintained as an open-source framework, but its role has diminished:

• Google Search: AMP is no longer required for the Top Stories carousel.
• Google News: AMP is no longer required for Google News inclusion.
• Email: AMP for Email remains active in Gmail.
• Ads: AMP for Ads (AMPHTML ads) are still used in some ad networks.

Most publishers who adopted AMP for SEO benefits are migrating away from it.

Deep Linking on AMP Pages (If You Still Use Them)

Standard Links

The simplest approach: use standard <a> tags with your domain URL.

<a href="https://yoursite.com/products/shoes">View in App</a>

When the user taps this link, the browser navigates to your domain. If your Universal Link or App Link is configured correctly, the OS intercepts the navigation and opens the app.

The limitation: this requires a full page navigation away from the AMP page.

amp-smart-links

The amp-smartlinks component was designed for affiliate link monetization, but the pattern is relevant: it rewrites links on the page to go through a redirect service.

For deep linking, a similar pattern works:

<a href="https://links.yoursite.com/products/shoes">View Product</a>

Using a dedicated link domain (like links.yoursite.com) that is configured for Universal Links / App Links ensures the link opens the app regardless of where the AMP page is served from.

App Banners on AMP Pages

Apple's native Smart App Banner works on AMP pages:

<meta name="apple-itunes-app" content="app-id=123456789, app-argument=yourapp://products/shoes">

For custom banners, AMP provides the amp-app-banner component:

<amp-app-banner layout="nodisplay" id="app-banner">
  <button on="tap:app-banner.dismiss">Close</button>
  <a href="https://play.google.com/store/apps/details?id=com.yourapp">
    Install the App
  </a>
</amp-app-banner>

This component handles platform detection and remembers dismissals.

Migrating Away from AMP

Preserving Deep Link Behavior

When migrating from AMP to standard pages:

1. Keep the same URL structure. If your AMP pages used /article/summer-deals, your standard pages should use the same path. This ensures existing deep links continue to work.

   Set up redirects from AMP URLs. If you had standalone AMP pages at /amp/article/summer-deals, redirect them:

   /amp/article/summer-deals → /article/summer-deals (301)
   

   3. Update the AMP cache. Google's AMP cache updates automatically when it re-crawls your page. You can also use the AMP Cache Update API to request immediate updates.

      Add deep linking JavaScript. Standard pages have no JavaScript restrictions. You can now add proper deep linking detection, smart banners, and deferred deep linking scripts.

      Performance After AMP

      AMP pages were fast because of strict resource constraints. When migrating, ensure your standard pages maintain performance:

      • Keep Largest Contentful Paint (LCP) under 2.5 seconds.
      • Keep Cumulative Layout Shift (CLS) under 0.1.
      • Keep Interaction to Next Paint (INP) under 200ms.

      Google's PageSpeed Insights measures these metrics. Good Core Web Vitals mean your standard pages rank just as well as AMP pages did.

      Deep Linking Alternatives to AMP

      Instant Articles and Native Content

      Facebook Instant Articles had similar deep linking challenges (content served from Facebook's domain, not yours). Meta deprecated Instant Articles in 2023.

      Apple News also serves content from Apple's domain, but supports Universal Links within article content.

      Progressive Web Apps (PWAs)

      PWAs serve content from your domain, so Universal Links and App Links work natively. If you adopted AMP for performance, PWA techniques (service workers, preloading, lazy loading) achieve similar performance without the deep linking complications.

      Server-Side Rendering

      Modern frameworks (Next.js, Nuxt, Remix) produce fast server-rendered pages from your domain. These work seamlessly with deep linking because:

      • The URL is your domain (Universal Links / App Links work).
      • Full JavaScript is available (smart banners, deferred deep linking).
      • Performance can match or exceed AMP with proper optimization.

      Handling AMP URLs in Analytics

      If you historically received traffic from AMP pages, your analytics may contain AMP-format URLs. Normalize them:

      function normalizeAmpUrl(url) {
        // Remove AMP cache prefix
        const ampCachePattern = /^https:\/\/cdn\.ampproject\.org\/c\/s\//;
        const ampViewerPattern = /^https:\/\/www\.google\.com\/amp\/s\//;
      
        let normalized = url
          .replace(ampCachePattern, 'https://')
          .replace(ampViewerPattern, 'https://');
      
        // Remove AMP suffix if present
        normalized = normalized.replace(/\/amp\/?$/, '/');
      
        return normalized;
      }
      

      This ensures your deep link attribution data is consistent across AMP and non-AMP page views.

      Tolinku and AMP

      Tolinku deep links use a dedicated link domain that works regardless of where the link is placed, including AMP pages. When a user taps a Tolinku link on an AMP page, the navigation goes to the Tolinku domain, which is configured for Universal Links and App Links. The app opens directly. For users without the app, the web fallback page loads with your configured content and store links.

      For SEO considerations when migrating from AMP, see app indexing and SEO for mobile apps.