Pourquoi un double canonical AMP/desktop peut-il tuer l'affichage de vos pages ?

Qu'est-ce qu'un canonical en chaîne et pourquoi ça bloque AMP ?

La balise canonical indique à Google quelle URL considérer comme version de référence. Dans une configuration AMP classique, la page AMP pointe vers la desktop via canonical, et la desktop renvoie vers l'AMP via balise amphtml.

Le problème surgit quand la version desktop possède son propre canonical pointant ailleurs — typiquement vers une URL paramétrisée ou une autre variante. Google se retrouve face à un circuit ouvert : AMP dit « ma référence c'est A », mais A dit « ma référence c'est B ». Résultat : l'algorithme ne sait plus quelle page servir en mobile.

Quel impact concret sur l'affichage dans les SERP ?

Quand Google détecte cette incohérence, il peut simplement ignorer la version AMP. Vous perdez alors les avantages du format : vitesse de chargement, badge éclair, carrousel Top Stories dans certains verticaux.

Pire : Google peut indexer une URL que vous ne contrôlez pas vraiment. Si votre desktop canonical pointe vers une version avec paramètres de tracking, c'est cette URL polluée qui risque d'apparaître dans l'index, pas votre page propre.

Est-ce que Google suit toute la chaîne de canonical ou s'arrête-t-il ?

Müller ne donne pas de limite explicite dans cette déclaration. L'observation terrain montre que Google suit généralement 2 à 3 sauts maximum avant d'abandonner. Au-delà, il traite les pages comme des entités distinctes.

Le vrai danger n'est pas tant la longueur de la chaîne que l'ambiguïté du signal. Une configuration AMP ↔ desktop doit être bidirectionnelle et fermée. Tout tiers élément dans la boucle la casse.

• Une page AMP peut pointer vers une desktop via canonical
• Cette desktop doit renvoyer vers l'AMP via balise amphtml — et nulle part ailleurs via canonical
• Toute chaîne de canonical au-delà de ce couple provoque une perte de contrôle sur l'affichage mobile
• Google privilégie toujours la cohérence des signaux sur la longueur de la chaîne

Cette règle s'applique-t-elle encore maintenant que AMP a perdu son poids ?

AMP n'est plus un facteur de ranking officiel depuis la généralisation des Core Web Vitals. Pourtant, le format reste utilisé dans certains verticaux — actualités, e-commerce rapide, fiches produits. Si vous maintenez encore des versions AMP, cette règle s'applique intégralement.

Soyons honnêtes : beaucoup de sites ont supprimé AMP entre 2021 et 2023. Mais si vous avez conservé le format pour des raisons de performance pure ou d'intégration Google News, un canonical mal configuré vous pénalise directement en visibilité mobile.

Google détecte-t-il systématiquement ces chaînes ou faut-il attendre un recrawl ?

La déclaration de Müller ne précise pas la fréquence de détection. Terrain, on observe que Google recalcule les relations canonical à chaque crawl profond, pas nécessairement à chaque visite Googlebot. [A vérifier] : aucun chiffre officiel sur le délai moyen avant détection d'une incohérence.

C'est là que ça coince. Vous pouvez corriger un canonical et attendre 3 semaines avant que Google actualise son mapping. Pendant ce temps, votre AMP reste invisible ou dégradée dans les SERP mobiles.

Une configuration AMP → desktop sans amphtml réciproque fonctionne-t-elle quand même ?

Non. Google a toujours exigé une relation symétrique pour valider une paire AMP/desktop. Si la desktop ne renvoie pas vers l'AMP via balise amphtml, Google traite les deux pages comme des entités indépendantes.

Concrètement, vous perdez tout bénéfice : pas de badge AMP, pas de priorisation mobile, juste deux URLs concurrentes qui se cannibalisent. Certains sites pensent qu'un simple canonical suffit — c'est faux, et Müller le confirme implicitement ici.

Comment auditer vos chaînes canonical AMP/desktop ?

Premier réflexe : crawlez votre site avec Screaming Frog ou Oncrawl en mode mobile + desktop. Extrayez les balises canonical et amphtml, puis croisez les données dans un tableur. Cherchez les pages AMP dont le canonical desktop possède lui-même un canonical tiers.

Deuxième vérification : testez manuellement vos paires avec l'outil Inspection d'URL de la Search Console. Google vous indique quelle URL il considère comme canonique et si la relation AMP est reconnue. Si le statut affiche « Page alternative avec balise canonical correcte » mais sans mention AMP, votre chaîne est cassée.

Quelles corrections apporter en priorité ?

Supprimez tout canonical parasite sur la version desktop. Si votre page desktop doit absolument pointer vers une variante (ex: version HTTPS vs HTTP), faites une redirection 301 côté serveur plutôt qu'un canonical. La redirection résout le problème en amont, avant que Google ne crawle.

Ensuite, vérifiez que chaque page desktop avec une version AMP contient bien la balise <link rel="amphtml" href="...">. C'est le signal réciproque indispensable. Sans lui, Google ignore la relation même si le canonical AMP est correct.

Faut-il encore maintenir des versions AMP ou tout migrer en responsive pur ?

Ça dépend de votre vertical. Si vous êtes dans l'actualité ou le contenu éditorial rapide, AMP conserve un avantage dans les carrousels Top Stories et Google News sur mobile. Pour l'e-commerce ou les sites corporate, le jeu n'en vaut plus la chandelle.

La maintenance d'un double template AMP/desktop coûte cher en ressources. Si vos Core Web Vitals sont excellents en responsive pur, abandonnez AMP. Sinon, gardez-le propre : un canonical bidirectionnel strict, aucune chaîne tierce.

• Crawler toutes vos pages AMP et extraire leurs balises canonical
• Vérifier que chaque desktop ciblée possède une balise amphtml réciproque
• Supprimer tout canonical tiers sur les pages desktop liées à AMP
• Tester dans Search Console l'inspection d'URL pour valider la reconnaissance AMP
• Automatiser la surveillance avec un script mensuel détectant les chaînes cassées