Où héberger vos pages AMP : sous-domaine, sous-répertoire ou paramètre ?

Pourquoi Google reste-t-il neutre sur la structure d'URL des pages AMP ?

La déclaration de Mueller reflète une réalité technique : Google crawle et indexe les pages AMP quelle que soit leur localisation dans l'arborescence du site. L'algorithme ne confère aucun bonus de ranking à une méthode plutôt qu'à une autre.

Cette neutralité s'inscrit dans la philosophie technique d'AMP : le format lui-même importe davantage que son emplacement. La validation HTML AMP et la conformité aux spécifications constituent les vrais critères d'éligibilité au carrousel mobile, pas l'architecture d'URL choisie.

Quelles différences techniques entre ces trois approches ?

Le sous-domaine (amp.site.com) sépare complètement l'environnement AMP. Cette isolation facilite la gestion d'infrastructures distinctes mais fragmente les signaux d'autorité : Google traite techniquement le sous-domaine comme une entité partiellement séparée.

Le sous-répertoire (/amp/article.html) centralise tout sous le domaine principal. Tous les backlinks, l'historique et l'autorité restent consolidés. C'est la structure préférée quand on veut maximiser la cohérence des signaux.

Les paramètres d'URL (?amp=1) génèrent une version alternative sans modifier le chemin. Simple techniquement, mais cette méthode complique la gestion canonique et peut créer des doublons si les paramètres ne sont pas correctement configurés dans Search Console.

Cette flexibilité cache-t-elle des implications stratégiques ?

La neutralité affichée par Google ne signifie pas que tous les choix se valent pour votre écosystème. La structure d'URL influence directement la manière dont vous gérez les redirections, les canonical, et la distribution des signaux de ranking.

Un site avec une forte autorité de domaine aura intérêt à garder ses AMP en sous-répertoire pour capitaliser sur cette autorité. À l'inverse, un projet isolé avec une équipe technique dédiée peut justifier un sous-domaine pour simplifier les déploiements.

• Aucun impact SEO direct entre sous-domaine, sous-répertoire ou paramètre selon Google
• Le choix dépend de vos contraintes techniques (infrastructure, équipes, CMS)
• Les signaux d'autorité se consolident mieux en sous-répertoire qu'en sous-domaine
• Les paramètres d'URL nécessitent une configuration rigoureuse de Search Console pour éviter les doublons
• La cohérence de la structure canonical prime sur le type d'URL choisi

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

Dans la pratique, les sites qui ont migré leurs AMP d'un sous-domaine vers un sous-répertoire rapportent souvent une amélioration de la consolidation des signaux. Google traite théoriquement les sous-domaines comme partie intégrante du domaine principal, mais la réalité montre une distribution d'autorité moins fluide.

Les sites de presse qui ont adopté le sous-répertoire constatent que leurs articles AMP héritent plus rapidement du PageRank interne. [À vérifier] Google n'a jamais publié de données comparatives sur la vitesse de propagation du PageRank entre ces structures, mais l'expérience terrain suggère une différence mesurable.

Quels risques cette déclaration minimise-t-elle ?

Mueller ne mentionne pas explicitement les pièges de configuration propres à chaque méthode. Les paramètres d'URL, par exemple, génèrent fréquemment du contenu dupliqué si vous oubliez de déclarer le paramètre dans Search Console ou si votre canonical pointe vers la mauvaise version.

Le sous-domaine crée une complexité supplémentaire pour le suivi analytique et la consolidation des données. Vous devez configurer le cross-domain tracking, ce qui ouvre la porte aux erreurs de mesure et aux pertes de sessions dans Google Analytics.

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

Si votre domaine principal souffre de pénalités manuelles ou algorithmiques, isoler vos AMP sur un sous-domaine peut théoriquement limiter la contamination. Google affirme traiter les sous-domaines comme partie du domaine, mais cette séparation technique existe bel et bien.

Pour les sites multilingues ou multi-régions, la structure d'URL des AMP doit s'aligner sur votre stratégie hreflang. Un paramètre risque de compliquer la déclaration des versions alternatives linguistiques, tandis qu'un sous-répertoire facilite la cohérence avec votre arborescence existante.

Quelle structure choisir concrètement pour votre site ?

Privilégiez le sous-répertoire (/amp/) si vous cherchez la simplicité et la consolidation maximale des signaux. C'est la configuration la plus propre pour maintenir l'autorité de domaine et simplifier la gestion des canonical. La majorité des CMS modernes supportent cette structure nativement.

Optez pour le sous-domaine (amp.site.com) uniquement si vous avez une raison technique impérieuse : infrastructure séparée, équipe dédiée, ou besoin d'isolation complète pour des tests. Acceptez le coût supplémentaire en configuration (cross-domain, analytics, Search Console).

Les paramètres d'URL (?amp=1) conviennent aux petits sites ou aux environnements où modifier l'arborescence est impossible. Mais cette solution exige une rigueur absolue dans la configuration de Search Console et la gestion des canonical pour éviter les doublons indexés.

Comment vérifier que votre configuration actuelle est optimale ?

Utilisez l'outil Inspection d'URL dans Search Console pour vérifier que Google détecte correctement la relation entre votre page canonical et sa version AMP. Le rapport doit afficher explicitement le lien entre les deux versions sans erreur.

Contrôlez votre fichier sitemap XML : si vous utilisez un sous-domaine AMP, créez un sitemap dédié sur ce sous-domaine et déclarez-le séparément dans Search Console. Pour un sous-répertoire, intégrez les URLs AMP dans votre sitemap principal avec un tag spécifique.

Analysez vos logs serveur pour détecter d'éventuelles anomalies de crawl. Si Googlebot crawle vos pages AMP et canonical avec des fréquences très déséquilibrées, votre structure génère peut-être une inefficience qu'une migration pourrait corriger.

Quelles erreurs éviter absolument dans l'implémentation ?

Ne créez jamais de chaînes de redirection entre vos versions. Si un utilisateur clique sur un résultat AMP, il doit atterrir directement sur la page AMP, pas sur une canonical qui redirige ensuite vers l'AMP. Ces redirections circulaires dégradent l'expérience et consomment du crawl budget.

Évitez de changer de structure d'URL AMP sans plan de migration rigoureux. Les URLs AMP générées précédemment restent en cache dans l'écosystème Google (carrousels, résultats sauvegardés). Une migration brutale crée des 404 qui persistent plusieurs semaines.

Si votre choix technique se révèle complexe à maintenir ou génère des inefficiences de crawl, une migration vers une architecture plus cohérente peut s'imposer. Ces arbitrages techniques nécessitent souvent une analyse approfondie de votre infrastructure et de vos signaux SEO actuels. Pour des configurations critiques ou des sites à fort trafic, l'accompagnement d'une agence SEO spécialisée dans les migrations AMP peut vous éviter des erreurs coûteuses et accélérer la stabilisation de vos performances.

• Vérifier la cohérence des balises canonical et amphtml entre toutes vos pages
• Déclarer correctement vos URLs AMP dans Search Console selon la structure choisie
• Configurer le cross-domain tracking si vous utilisez un sous-domaine AMP
• Tester la relation canonical/AMP via l'outil Inspection d'URL pour chaque template de page
• Auditer vos logs serveur pour identifier les patterns de crawl inefficaces
• Documenter votre choix technique pour éviter les changements arbitraires futurs