Faut-il privilégier un sous-domaine ou un sous-répertoire pour héberger vos pages AMP ?

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

Google ne veut pas imposer de contrainte architecturale rigide pour l'implémentation AMP. Cette flexibilité vise à faciliter l'adoption de la technologie quelles que soient les contraintes techniques d'un site existant.

La déclaration de Mueller s'inscrit dans une logique de pragmatisme technique : que vous optiez pour amp.example.com, example.com/amp/ ou example.com/page?amp=1, le moteur de recherche traitera les pages de manière équivalente. Aucune structure ne bénéficie d'un avantage crawl ou indexation.

Quelles sont les différences pratiques entre ces trois structures ?

Le sous-domaine (amp.example.com) nécessite un certificat SSL distinct et une configuration DNS dédiée. Cette option peut compliquer la maintenance mais offre une séparation technique nette entre contenus standard et AMP.

Le sous-répertoire (example.com/amp/) partage le certificat SSL du domaine principal et simplifie la gestion des analytics. C'est souvent le choix privilégié pour sa simplicité d'implémentation et sa cohérence d'architecture.

Les paramètres d'URL (example.com/page?amp=1) permettent de servir les deux versions depuis la même adresse. Cette approche réduit la duplication apparente mais peut poser des problèmes de canonicalisation si mal configurée.

L'absence de préférence signifie-t-elle vraiment une totale équivalence SEO ?

Sur le papier, oui. Google traite ces trois structures sans favoritisme apparent pour l'indexation des pages AMP elles-mêmes. La neutralité affichée reflète une volonté de ne pas pénaliser les choix d'architecture.

Reste que certaines structures peuvent avoir des implications indirectes. Un sous-domaine dilue potentiellement l'autorité du domaine principal, tandis qu'un sous-répertoire concentre les signaux de ranking sur un seul domaine racine. Ces effets ne sont pas spécifiques à AMP mais inhérents à toute architecture multi-versions.

• Flexibilité totale : Google accepte sous-domaine, sous-répertoire et paramètre d'URL sans distinction
• Aucun avantage crawl : les trois structures sont traitées équitablement par Googlebot
• Choix guidé par la technique : privilégiez la structure qui simplifie votre maintenance et votre infrastructure
• Attention à la canonicalisation : quelle que soit la structure, les balises rel=canonical et rel=amphtml doivent être correctement implémentées
• Impact indirect possible : les sous-domaines diluent l'autorité de domaine, indépendamment de la technologie AMP

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

Oui, dans les grandes lignes. Les sites utilisant des structures différentes pour leurs pages AMP n'affichent pas de différences significatives de performance dans les résultats de recherche. Les tests A/B menés sur des migrations de sous-domaine vers sous-répertoire (ou l'inverse) ne révèlent pas d'impact mesurable sur les positions organiques.

Cela dit, cette neutralité ne signifie pas que toutes les structures se valent en pratique. Un sous-domaine mal configuré (certificat SSL expiré, robots.txt bloquant, DNS lent) pénalisera vos pages AMP. La déclaration de Mueller présuppose une implémentation technique irréprochable, ce qui n'est pas toujours le cas sur le terrain.

Quels sont les risques cachés de chaque structure ?

Les sous-domaines posent des problèmes de fragmentation d'autorité. Les backlinks pointant vers amp.example.com ne renforcent pas directement example.com, même si Google comprend la relation entre les deux. Pour des sites à faible autorité, cette dilution peut avoir un impact mesurable.

Les paramètres d'URL créent des complications avec les outils analytics et de tracking. De nombreux scripts considèrent ?amp=1 comme un paramètre de session et peuvent fragmenter les données de trafic. Sans configuration spécifique dans Google Analytics, vous risquez de compter double vos visites.

Les sous-répertoires présentent moins de pièges techniques mais imposent une structure d'URL plus longue. Si votre site utilise déjà des chemins profonds (/category/subcategory/article/), ajouter /amp/ peut créer des URLs dépassant les 100 caractères, ce qui dégrade l'expérience utilisateur lors du partage.

Dans quels cas cette neutralité ne s'applique-t-elle pas vraiment ?

La déclaration de Mueller concerne l'indexation pure. Elle ne tient pas compte des effets de bord architecturaux qui peuvent impacter votre SEO global. Un sous-domaine AMP non référencé dans votre sitemap principal, sans liens internes depuis le domaine racine, sera crawlé avec une fréquence réduite.

Pour les sites internationaux, la gestion des hreflang devient significativement plus complexe avec des sous-domaines AMP. Vous devez déclarer les relations linguistiques entre amp.example.fr, amp.example.de ET example.fr, example.de, ce qui multiplie les risques d'erreur de configuration. [À vérifier] : l'impact réel de ces configurations complexes sur le crawl budget n'a jamais été quantifié publiquement par Google.

Quelle structure choisir pour un nouveau déploiement AMP ?

Si vous partez de zéro, le sous-répertoire reste le choix le plus sûr. Il simplifie la gestion SSL, concentre l'autorité sur un seul domaine, et facilite le suivi analytics sans configuration exotique. Optez pour une structure /amp/ ou /accelerated/ selon vos préférences sémantiques.

Les sous-domaines ne se justifient que dans deux cas spécifiques : quand votre infrastructure impose une séparation technique stricte (serveurs dédiés, CDN différent), ou quand vous testez AMP sur une partie limitée du site sans impacter la production. Dans ces situations, le surcoût de maintenance est compensé par la flexibilité opérationnelle.

Les paramètres d'URL fonctionnent si vous servez dynamiquement AMP et HTML depuis le même code. Cette approche convient aux sites à forte logique applicative (sites de rencontre, plateformes SaaS) mais complique la mise en cache CDN et nécessite une configuration analytics avancée.

Comment migrer entre structures sans perdre de trafic ?

Une migration de structure AMP suit les mêmes règles qu'une migration classique. Implémentez des redirections 301 permanentes depuis l'ancienne structure vers la nouvelle, en conservant la correspondance page à page.

Mettez à jour simultanément toutes les balises rel=amphtml sur vos pages canoniques et les rel=canonical sur vos pages AMP. Un décalage entre redirections et balises relationnelles crée une incohérence que Google peut mettre des semaines à résoudre.

Soumettez les deux sitemaps (ancien et nouveau) via Search Console pendant au moins deux cycles de crawl complets. Surveillez le rapport de couverture d'index pour détecter les pages AMP orphelines ou les erreurs de canonicalisation.

Quelles erreurs de configuration guettent chaque structure ?

Sur sous-domaine, l'erreur classique est de ne pas déclarer la propriété du sous-domaine dans Search Console séparément du domaine principal. Google traite amp.example.com comme un site distinct : sans validation, vous ne verrez pas les erreurs AMP remontées.

Avec les sous-répertoires, le piège fréquent concerne le fichier robots.txt. Certains CMS génèrent automatiquement des règles Disallow pour les répertoires /amp/ ou /accelerated/, considérés comme du contenu dupliqué à bloquer. Vérifiez que Googlebot-AMP a bien accès complet à votre sous-répertoire.

Les paramètres d'URL posent problème avec les canonicales croisées. Si example.com/page et example.com/page?amp=1 pointent tous deux vers example.com/page comme canonical, Google peut ignorer la version AMP. La version AMP doit pointer vers la version HTML, pas vers elle-même.

• Choisissez la structure qui simplifie votre infrastructure technique existante, pas celle qui semble la plus SEO-friendly
• Vérifiez que votre certificat SSL couvre tous les sous-domaines si vous optez pour amp.example.com
• Implémentez les balises rel=amphtml et rel=canonical de manière bidirectionnelle et cohérente
• Déclarez vos pages AMP dans un sitemap dédié ou une section spécifique de votre sitemap principal
• Testez votre configuration avec l'outil de test AMP de Google avant tout déploiement massif
• Surveillez le rapport de couverture d'index Search Console pour détecter les pages AMP non indexées