Is AMP really a ranking factor for your SEO?

Is AMP a requirement to appear in mobile search results?

No. AMP has never been a technical requirement for mobile SEO. Contrary to what some believed during the initial rollout of the format, a non-AMP page can perfectly rank at the top on mobile.

Google has clarified this point multiple times: AMP is not a ranking signal in itself. What matters is the actual loading speed and the final user experience, regardless of the technical format used. A fast traditional HTML page will always outperform a poorly optimized AMP page.

Why does Google continue to promote AMP then?

The logic is simple: AMP imposes a strict technical framework that mechanically ensures good performance. By drastically limiting JavaScript, controlling CSS, and enforcing lazy loading of images, the format eliminates 90% of common web performance errors.

For content publishers who lack the expertise or resources to finely tune their technical stack, AMP offers a shortcut to performance. This is especially true for news sites or blogs on generic CMSs that often struggle with 2-3 seconds of unnecessary scripts.

Which regions and connections are truly affected?

The mention of "slow connections" in Google's recommendation is not incidental. On a European 4G network, the difference between a well-optimized HTML page and its AMP version is often negligible: 0.2 to 0.5 seconds.

In contrast, on a 3G network in rural areas or in certain emerging countries, the gap can reach 2 to 4 seconds. If your audience mostly uses high-speed connections, the AMP speed argument loses its strength. Analyze your Analytics data to identify the type of connections your actual users have.

• AMP is not a direct ranking factor unlike actual loading speed
• The format imposes technical constraints that mechanically ensure good performance
• The measurable impact heavily depends on the type of connections your target audience uses
• An optimized traditional HTML page can outperform an AMP page in terms of speed and experience
• Google's recommendation primarily targets sites that lack the resources to finely optimize their performance

Is this recommendation still relevant with Core Web Vitals?

This is where it gets tricky. Since the integration of Core Web Vitals as a ranking signal, the logic has changed. You no longer need a specific format to prove your performance; you just need to meet the thresholds for LCP, FID, and CLS.

In practice, a standard HTML page that meets the Core Web Vitals receives exactly the same benefits as an AMP page. Thus, the historical advantage of AMP has significantly diminished. [To be verified]: Google does not publish any data showing an average performance gap between AMP and non-AMP on comparable sites.

Do the technical constraints of AMP justify the investment?

Let's be honest: implementing AMP comes at a cost. There’s double maintenance for templates, functional limitations (forms, interactivity, advanced tracking), and dependence on Google's cache. For an e-commerce site or a web app, these limitations are often deal-breakers.

I have observed that sites abandoning AMP after optimizing their canonical version typically do not lose positions, as long as their Core Web Vitals remain in the green. The real question is: do you have the technical skills to optimize your stack without the AMP constraints?

In what cases is AMP still relevant?

Three situations still justify AMP. Firstly, high-volume news sites that still benefit from the Top Stories carousel (even though it's no longer exclusive to AMP). Secondly, sites on legacy CMSs that are impossible to optimize correctly without a complete overhaul.

Thirdly, and this is the most common case, sites primarily targeting geographical areas with limited mobile infrastructure. If 60% of your traffic comes from regions on 2G/3G, AMP remains a measurable competitive advantage. Look at your actual connection data before deciding.

Should you migrate to AMP if your site does not have it?

The short answer: No, not by default. Start by auditing your current Core Web Vitals. If your LCP is under 2.5 seconds, your FID under 100ms, and your CLS under 0.1 on mobile, you have no urgent need for AMP.

If your metrics are in the orange or red, first optimize your standard version: image compression, lazy loading, removing blocking JavaScript, performant CDN. These optimizations benefit 100% of your pages, not just a parallel version.

How to measure the real impact of AMP on your traffic?

If you decide to test AMP, set up specific monitoring in Search Console. Create a separate segment for your AMP URLs and compare impressions, clicks, and average positions with your canonical URLs over a minimum period of 3 months.

Also analyze engagement metrics: bounce rate, time on page, pages per session. AMP simplifies design, which can paradoxically reduce engagement on certain types of content. A speed gain does not always compensate for a loss of features or aesthetics.

What mistakes should you avoid when implementing AMP?

The classic mistake: implementing AMP without the correct canonical tag between the AMP version and the standard version. You risk duplicate content and cannibalizing your own pages. Always check the bidirectional amphtml/canonical relationship.

Another frequent pitfall: neglecting Analytics tracking on AMP pages. Standard JavaScript does not work; you need to use amp-analytics with specific configuration. Without proper tracking, you're operating blindly and can't measure the real ROI of your investment.

• Audit your Core Web Vitals before any AMP decision: use PageSpeed Insights and Search Console
• Analyze the geographic distribution and connection type of your actual audience via Analytics
• If you implement AMP, check the bidirectional amphtml/canonical configuration on each template
• Configure amp-analytics correctly to not lose visibility on your conversions and engagements
• Compare Search Console metrics between AMP and canonical versions over a minimum of 90 days
• Test the impact on user engagement: a speed gain does not justify a loss of conversions