Google Amp and SEO

Accelerated Mobile Pages (AMP) is an open-source HTML framework that lets you create stripped-down versions of your pages with restricted CSS, JavaScript, and HTML. It was built to make mobile pages load faster, and Google used to reward it with prominent placement in search results, including carousels and the Top Stories section. That changed in 2021 when Google removed the AMP requirement for Top Stories. Since then, AMP has become a purely technical implementation choice, not a ranking signal or a visibility requirement.

What does that mean for you? If you already have AMP pages running, you need to ensure they are correctly linked to their canonical (non-AMP) versions using rel="amphtml" on the canonical page and rel="canonical" on the AMP page. If you get that wrong, Google may index the AMP version as the primary page, which can cause [duplicate content](/duplicate-content/) issues and dilute your link equity. If you are considering starting AMP from scratch, I would only do it if you have a specific, measurable performance problem that cannot be solved with a well-optimised responsive design or a [PWA](/pwa/). AMP adds maintenance overhead: you have to keep two versions of every page in sync, and any custom JavaScript you need (like a chat widget or a third-party script) will likely break the AMP validation. For most sites, the effort is not worth it.

AMP matters most in three scenarios. First, if your site is heavily reliant on display advertising or third-party scripts that slow down the page, AMP's strict limitations can force a clean, fast experience. I have seen publishers with ad-heavy article pages reduce their Largest Contentful Paint (LCP) by over 40% after switching to AMP. But that same improvement could often be achieved by cleaning up the ad setup on the canonical page itself. Second, if you are targeting users on very slow networks or old devices, AMP's cached delivery through Google's infrastructure can make a real difference. The AMP cache preloads resources and serves them from Google's CDN, which can cut time-to-first-byte significantly. However, since Google now uses [Core Web Vitals](/core-web-vitals/) as a ranking factor, improving your canonical page's performance with server-side rendering or lazy loading might be a more sustainable approach. Third, AMP still appears in some specialised search features, like recipe carousels or job listings, where Google may prefer AMP pages. Check your current SERP appearance: if you see AMP pages showing up in a carousel format, keeping AMP might help you retain that placement. But in my experience, those cases are becoming rarer. I would only invest in AMP if you have data that proves it drives measurable traffic or conversions that you cannot replicate on your canonical pages.

I used to think AMP was a ranking signal. I implemented it on a news site in 2019 expecting a boost, and for a few months our mobile traffic from Google did increase. But that was because Google was still showing AMP pages in the Top Stories carousel, which drove more impressions. When the requirement was removed, traffic dropped back to baseline. I now understand that the benefit was from the carousel placement, not a ranking signal. I also overlooked how easily AMP can cause canonicalisation problems. On one client's site, the AMP page's rel="canonical" was pointing to itself by mistake, and Google indexed the AMP version as the canonical. That split the page's authority and caused a 30% drop in organic clicks until we fixed it. I also underestimated the maintenance burden. Every time we added a new feature to the canonical page—like a related articles slider or a video embed—we had to replicate it in AMP or exclude it, and often the AMP version would break validation. After a year, we removed AMP entirely and improved the canonical page's performance through [technical SEO](/technical-seo/) optimisations like code splitting and image optimisation. The mobile page speed improved by 35% without the dual-version headache. I now believe AMP is a tool for niche use cases, not a default tactic.