Pourquoi Google indexe-t-il parfois vos pages AMP avant leur version HTML canonique ?

Comment Google peut-il indexer l'AMP avant la page HTML principale ?

La séquence classique voudrait que Google découvre d'abord la page HTML, identifie le lien rel=amphtml, puis crawle la version AMP. Mais ce scénario ne reflète pas toujours la réalité du web.

Si un site tiers, un flux RSS ou un lien direct pointe vers l'URL AMP elle-même (par exemple https://example.com/article.amp.html), Google peut indexer cette version en premier. La page HTML canonique n'a peut-être pas encore été crawlée — ou pire, elle est bloquée temporairement par un problème serveur, une erreur robots.txt ou un budget de crawl insuffisant.

Dans ce cas, Google indexe ce qu'il a sous la main : la page AMP. Elle apparaît dans les résultats de recherche comme URL principale, même si elle porte la balise rel=canonical vers la version HTML qu'il n'a pas encore vue.

Que se passe-t-il une fois la page HTML crawlée ?

Quand Google finit par découvrir la page HTML canonique, il analyse les balises rel=amphtml et rel=canonical entre les deux versions. Si tout est correctement balisé, il comprend que l'AMP est une variante et que la version HTML doit être privilégiée.

Le moteur bascule alors son focus : l'URL HTML devient la version indexée principale, et l'AMP passe en tant que variante alternative. Ce basculement peut prendre quelques jours, le temps que Google recrawle les deux pages et mette à jour son index.

Mueller affirme que ce processus se résout automatiquement, sans intervention manuelle. En théorie. Sur le terrain, ça dépend de la cohérence de vos balises et de votre budget de crawl.

Pourquoi cette situation pose-t-elle problème en pratique ?

Pendant cette phase de transition, l'URL AMP reste visible dans les SERPs. Les outils analytics et Search Console peuvent afficher des données fragmentées : une partie du trafic arrive sur l'AMP, une autre sur la HTML.

Si vous suivez vos rankings avec des outils tiers (SEMrush, Ahrefs, etc.), vous risquez de voir deux URLs distinctes positionnées pour la même requête, ou des fluctuations artificielles de positions. Les conversions trackées côté HTML peuvent ne pas refléter le trafic réel si une part arrive encore sur l'AMP.

Autre problème : si votre page HTML a des éléments de conversion absents de l'AMP (formulaires complexes, chat, widgets), les utilisateurs atterrissant sur l'AMP auront une expérience dégradée. Et Google ne se soucie pas de savoir si votre tunnel de conversion est cassé pendant ce délai.

• Google peut indexer l'AMP en premier si des liens externes pointent directement vers cette version
• La reconnexion avec la page HTML canonique se fait automatiquement après crawl, mais peut prendre plusieurs jours
• Durant cette transition, les données analytics et rankings peuvent être fragmentées entre les deux URLs
• Les utilisateurs atterrissant sur l'AMP peuvent avoir une expérience appauvrie si la page manque d'éléments présents sur la HTML
• La résolution automatique suppose des balises canoniques correctes — toute incohérence prolonge le problème

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

Oui, et c'est même un cas de figure fréquent sur les sites qui génèrent des URLs AMP accessibles publiquement. On observe régulièrement des pages AMP indexées en premier, surtout quand elles sont partagées sur Twitter, LinkedIn ou agrégées dans des flux RSS qui pointent directement vers l'URL .amp.html.

Le problème, c'est que Mueller présente ça comme un non-événement qui se résout tout seul. En réalité, ça dépend. Si votre site a un crawl budget faible, que la page HTML est profonde dans l'arborescence ou qu'elle renvoie des erreurs temporaires, Google peut mettre des semaines à faire le lien. J'ai vu des cas où l'AMP restait indexée pendant plus d'un mois avant que Google ne bascule. [A vérifier] si ce délai est vraiment « automatique » dans tous les contextes.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller ne dit rien sur ce qui se passe si les balises canoniques sont incohérentes. Si l'AMP pointe vers une URL HTML qui elle-même redirige, ou si la page HTML ne déclare pas correctement le lien rel=amphtml, Google peut rester coincé dans un état intermédiaire.

Autre point : il affirme que Google « se concentre sur la HTML » une fois la connexion établie. Mais ça ne veut pas dire que l'AMP disparaît de l'index. Elle reste accessible, et dans certains cas (recherches mobiles, Top Stories), c'est toujours l'AMP qui peut être servie en priorité. Le « focus » dont parle Mueller est flou : s'agit-il du ranking, de l'affichage, ou juste de la version canonique stockée ?

Enfin, il ne mentionne pas les impacts sur les Core Web Vitals. Si l'AMP est indexée en premier et que Google collecte des données CWV sur cette version, puis bascule vers la HTML qui a des perfs différentes, est-ce que les métriques se réinitialisent ? Ou est-ce que Google garde un historique mixte ? [A vérifier] comment les signaux UX sont gérés dans cette transition.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous avez désactivé AMP ou supprimé les balises rel=amphtml/canonical, cette situation ne se produit plus. Mais attention : les anciennes URLs AMP peuvent rester en cache dans l'index Google pendant des semaines. Il faut forcer un recrawl via Search Console ou attendre que Google purge naturellement.

Autre cas : si vous utilisez AMP uniquement pour les Top Stories et que les URLs AMP ne sont jamais linkées directement, le risque d'indexation AMP-first est quasi nul. C'est surtout un problème pour les sites qui exposent les URLs AMP dans leur sitemap, leurs flux RSS ou leurs partages sociaux.

Que faut-il faire concrètement pour éviter ce problème ?

D'abord, ne linkez jamais directement vos URLs AMP dans vos partages sociaux, flux RSS ou newsletters. Utilisez toujours l'URL HTML canonique. Si votre CMS génère automatiquement des liens vers l'AMP, paramétrez-le pour qu'il pointe vers la version HTML standard.

Ensuite, vérifiez que vos balises rel=canonical et rel=amphtml sont symétriques. La page AMP doit pointer vers la HTML avec rel=canonical, et la HTML doit pointer vers l'AMP avec rel=amphtml. Toute incohérence prolonge la confusion de Google.

Si vous constatez qu'une page AMP est indexée avant sa version HTML, forcez le crawl de la page HTML via l'outil Inspection d'URL dans Search Console. Ne vous contentez pas d'attendre : Google peut mettre des semaines à recrawler naturellement si votre budget de crawl est serré.

Quelles erreurs éviter dans la gestion AMP/HTML ?

Ne créez pas de chaînes de redirections entre AMP et HTML. Si l'AMP pointe vers une URL HTML qui redirige elle-même ailleurs, Google peut ignorer la directive canonique. Chaque URL doit pointer directement vers sa cible finale.

Évitez de bloquer les URLs AMP dans le robots.txt tout en les laissant accessibles. Si Google ne peut pas crawler l'AMP, il ne peut pas vérifier la cohérence des balises canoniques, et la situation reste figée.

Ne supprimez pas les pages AMP sans redirection 301 explicite. Même si la page HTML est indexée, Google peut continuer à tenter d'accéder à l'AMP pendant des mois. Une 404 sur l'AMP peut dégrader le crawl budget et ralentir la consolidation.

Comment vérifier que votre configuration est conforme ?

Utilisez le rapport AMP dans Search Console pour identifier les pages AMP indexées. Si vous voyez des URLs AMP apparaître alors que la version HTML existe, c'est un signal qu'il faut forcer le recrawl de la HTML.

Auditez vos flux RSS, sitemaps XML et partages sociaux pour vérifier qu'ils pointent vers les URLs HTML canoniques, jamais vers les .amp.html. Un simple grep sur vos templates peut révéler des liens AMP hardcodés par erreur.

Surveillez vos rankings avec des outils tiers : si vous voyez deux URLs (HTML et AMP) positionnées pour la même requête, c'est que Google n'a pas encore consolidé. Forcez le crawl de la HTML et attendez quelques jours.

• Vérifiez que les balises rel=canonical (AMP → HTML) et rel=amphtml (HTML → AMP) sont symétriques et cohérentes
• Ne linkez jamais directement les URLs AMP dans vos flux RSS, sitemaps ou partages sociaux
• Forcez le crawl de la page HTML via Search Console si l'AMP est indexée en premier
• Évitez les chaînes de redirections entre AMP et HTML — pointez toujours vers l'URL finale
• Auditez régulièrement le rapport AMP dans Search Console pour détecter les incohérences
• Si vous désactivez AMP, mettez en place des redirections 301 AMP → HTML avant de supprimer les pages