AMP pour l'e-commerce : faut-il encore investir dans cette technologie ?

Pourquoi Google précise-t-il qu'AMP n'est pas un facteur de classement ?

Cette distinction marque une clarification importante dans la stratégie de Google. AMP (Accelerated Mobile Pages) a longtemps été perçu comme un avantage concurrentiel en SEO, notamment parce que les pages AMP bénéficiaient d'un carrousel dédié dans les résultats mobiles. Mais Google joue ici la carte de la transparence : ce n'est pas l'implémentation AMP en elle-même qui booste le ranking.

Ce qui compte, c'est la performance réelle de la page. Si AMP permet d'atteindre de meilleurs scores sur les Core Web Vitals (LCP, FID, CLS), alors indirectement, il contribue au référencement. Mais une page non-AMP parfaitement optimisée obtiendra exactement les mêmes bénéfices. La technologie n'est qu'un moyen, pas une fin.

Quel intérêt reste-t-il pour l'e-commerce spécifiquement ?

L'e-commerce a des contraintes particulières : fiches produits lourdes, images multiples, avis clients, scripts de tracking, boutons d'achat dynamiques. Tout ça pèse. AMP impose un cadre strict qui force l'optimisation : limitation des scripts tiers, CSS inline limité, lazy loading natif, ressources servies depuis le cache Google.

Pour un site marchand qui galère avec un CMS mal configuré ou une infrastructure peu performante, AMP peut servir de contournement technique rapide. C'est particulièrement vrai pour les retailers avec des milliers de références et peu de ressources dev. Mais attention : AMP crée aussi des contraintes fonctionnelles (formulaires limités, interactions JS restreintes) qui peuvent nuire à l'expérience d'achat.

Qu'est-ce qui a changé depuis le lancement d'AMP ?

Le contexte technique a évolué. Quand AMP est apparu, le web mobile était objectivement catastrophique côté performance. Aujourd'hui, les frameworks modernes (Next.js, Nuxt, SvelteKit) offrent des solutions de SSR et de pre-rendering qui égalent ou surpassent AMP en flexibilité. Les Core Web Vitals ont aussi déplacé le curseur : Google mesure désormais la performance réelle, pas la conformité à un standard propriétaire.

Résultat : AMP perd son caractère indispensable. Il reste pertinent dans des cas spécifiques (sites d'actualités, blogs à fort trafic mobile, fiches produits statiques), mais il n'est plus la solution universelle qu'on a pu vendre. Les retailers sophistiqués investissent plutôt dans l'optimisation de leur stack principal.

• AMP n'influence pas directement le classement, seule la performance technique compte
• Les gains potentiels se situent au niveau des Core Web Vitals et de l'expérience mobile
• L'e-commerce doit arbitrer entre simplification AMP et richesse fonctionnelle
• Les alternatives modernes (SSR, edge computing, CDN) offrent désormais des performances comparables
• La décision doit reposer sur un audit coût/bénéfice selon le contexte technique existant

Cette déclaration est-elle cohérente avec les observations terrain ?

Tout à fait. Les tests A/B menés depuis plusieurs années montrent qu'une page non-AMP bien optimisée performe aussi bien qu'une version AMP en termes de ranking. Ce qu'on observe, c'est que les sites qui ont adopté AMP ont souvent vu une amélioration des performances... simplement parce qu'ils partaient de très loin. AMP les forçait à nettoyer leur code.

Les e-commerces qui ont investi massivement dans AMP puis abandonné (Zalando, eBay dans certains marchés) n'ont pas constaté de chute de trafic. Ils ont réinvesti dans leur stack native avec de meilleurs résultats. La leçon : AMP a été un électrochoc salutaire, mais ce n'était jamais la technologie elle-même qui faisait la différence.

Quelles sont les limites non dites de cette position ?

Google reste vague sur un point : le cache AMP. Même si AMP n'est pas un facteur de ranking, les pages servies depuis le cache Google bénéficient d'une latence quasi nulle et de scores CWV mécaniquement meilleurs. C'est un avantage indirect réel que Google minimise dans cette communication.

Second point : l'écosystème publicitaire. AMP simplifie l'intégration des ads Google (AMP-ads), ce qui peut améliorer le RPM publicitaire. Pour un site e-commerce qui monétise aussi via display, cette dimension compte. Mais Google ne l'évoque pas ici car ça mélange SEO et monétisation. [À vérifier] : l'impact réel du cache AMP sur les CWV mesurés par la CrUX, données que Google ne publie pas en détail.

Dans quels cas AMP reste-t-il pertinent pour l'e-commerce ?

Trois scénarios concrets. Premier : sites legacy avec dette technique massive. Si votre Magento 1 ou PrestaShop est ingérable et que la refonte prendra 18 mois, AMP peut servir de solution transitoire pour les fiches produits principales. Deuxième : marchés mobiles ultra-dominants (Inde, Asie du Sud-Est) où la connexion est le facteur limitant, pas le code.

Troisième : pure players content-driven qui vendent via affiliation et ont besoin de vitesse maximale sans fonctionnalités e-commerce complexes (pas de panier, checkout simplifié). Dans ces cas, AMP offre encore un ROI positif. Partout ailleurs, l'investissement vaut mieux sur l'optimisation native.

Faut-il abandonner AMP si on l'a déjà implémenté ?

Pas forcément en urgence. Si votre version AMP fonctionne, génère du trafic et que vous n'avez pas de plaintes utilisateurs sur les limitations, laissez-la tourner. Le coût de maintenance est faible une fois l'implémentation stabilisée. Par contre, ne lui consacrez plus de ressources dev significatives.

Concentrez-vous plutôt sur l'optimisation de votre version standard : amélioration du LCP via un CDN performant, lazy loading des images below the fold, suppression des scripts tiers bloquants, optimisation du TTFB côté serveur. L'objectif : atteindre sur la version native les performances actuelles de la version AMP, puis déprécier progressivement cette dernière.

Comment arbitrer pour un nouveau projet e-commerce ?

Posez-vous trois questions. Un : quel est mon score CWV actuel ou projeté sur la stack envisagée ? Si vous construisez sur Shopify Plus ou BigCommerce avec un thème optimisé, vous êtes déjà dans les clous sans AMP. Deux : quelle est la complexité fonctionnelle de mes pages produits ? Configurateurs, comparateurs, avis avec media, AR... tout ça est incompatible avec AMP.

Trois : ai-je les ressources pour maintenir deux codebases ? AMP demande de dupliquer templates, tests, déploiements. Si votre équipe est limitée, mieux vaut un seul site parfaitement optimisé que deux versions médiocrement maintenues. La réponse est presque toujours : skip AMP, investis dans la performance native dès le départ.

Quelles erreurs éviter absolument ?

Ne tombez pas dans le piège du "AMP cosmétique" : implémenter AMP juste pour cocher une case, sans mesurer l'impact réel sur CWV et conversions. Ça mobilise des ressources pour un bénéfice inexistant. Autre erreur fréquente : implémenter AMP en négligeant la version standard, qui finit par pourrir et offrir une expérience dégradée.

Troisième erreur : croire qu'AMP dispense d'optimiser les images, le cache serveur ou la minification. AMP impose des contraintes, mais dans ce cadre, les optimisations classiques restent indispensables. Un AMP mal configuré (images non lazy-loadées, fonts bloquantes) peut scorer moins bien qu'une page standard bien foutue.

• Auditer les Core Web Vitals actuels (CrUX + RUM) pour identifier le delta réel qu'AMP pourrait apporter
• Évaluer le coût de développement et maintenance de deux versions (temps dev, QA, déploiement)
• Tester l'impact sur les conversions : certains parcours e-commerce souffrent des limitations AMP
• Vérifier la configuration canonical/amphtml si vous maintenez les deux versions
• Monitorer l'évolution des parts de trafic AMP vs standard pour détecter une cannibalisation
• Planifier une stratégie de sortie progressive si AMP ne démontre pas de ROI clair sous 6 mois