Peut-on vraiment géolocaliser la diffusion de ses pages AMP sans risquer une pénalité ?

Pourquoi Google ne supporte-t-il pas nativement la diffusion AMP par région ?

Le protocole AMP repose sur un principe d'uniformité et de cache partagé. Quand Googlebot crawle une page AMP, il s'attend à ce que la version AMP reste accessible globalement, sans variations selon l'origine géographique de la requête.

Si vous servez du contenu AMP uniquement à certains pays via des règles serveur (redirections, détection IP, headers Accept-Language), vous créez une incohérence entre la version canonical et la version AMP. Google peut indexer la balise <link rel="amphtml"> depuis un datacenter américain, mais un utilisateur français pourrait recevoir une erreur 404 ou une redirection vers la version HTML classique. Ce décalage perturbe le cache AMP et la validation des paires canonical/AMP.

Qu'est-ce que cela signifie concrètement pour l'indexation et le cache AMP ?

Le cache AMP de Google (et ceux des tiers comme Cloudflare, Bing) stocke les pages AMP de manière centralisée et géographiquement distribuée. Si votre serveur refuse de servir la page AMP selon la géolocalisation, le cache ne peut pas la récupérer correctement lors du crawl.

Résultat : vous obtenez soit une invalidation des paires canonical/AMP dans la Search Console, soit un affichage en version HTML standard dans les SERPs, perdant ainsi les avantages du badge AMP (vitesse, carousel, prérendering). Les logs serveur montrent souvent des crawls incomplets ou des erreurs 403/404 sporadiques selon le datacenter Googlebot utilisé.

Dans quels cas cette limitation devient-elle réellement problématique ?

La diffusion conditionnelle AMP par région pose surtout problème pour les sites e-commerce internationaux qui veulent géolocaliser les prix, les langues ou les catalogues produits. Si vous servez l'AMP uniquement au Royaume-Uni mais pas en France, les utilisateurs français verront la version HTML classique, créant une expérience incohérente.

Pour les médias ou blogs multilingues, l'absence de support natif impose soit d'activer AMP partout (avec hreflang bien configuré), soit de renoncer à AMP sur certaines zones. Le risque est d'avoir des URL AMP orphelines ou des contenus dupliqués si les règles de redirection ne sont pas rigoureuses.

• Uniformité du cache : Google attend que chaque URL AMP soit accessible depuis tous ses datacenters, sans dépendance géographique.
• Validation des paires : toute incohérence entre canonical et amphtml génère des erreurs dans la Search Console et empêche l'affichage AMP dans les résultats.
• Complexité technique : implémenter de la géolocalisation serveur pour AMP exige une gestion fine des headers, des codes HTTP et des règles CDN.
• Cas d'usage limités : la diffusion AMP conditionnelle n'a de sens que si les contenus varient réellement par région, pas juste pour des raisons de préférence UX.
• Hreflang et AMP : pour du contenu multilingue, il faut dupliquer les balises hreflang dans chaque version AMP et canonical, sans quoi Google peut mélanger les langues.

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui, et c'est même un des non-dits les plus frustrants d'AMP. Depuis le lancement du format, la documentation officielle reste floue sur la géolocalisation. Pourtant, sur des audits e-commerce internationaux, on voit régulièrement des sites qui tentent de conditionner AMP par pays via Cloudflare Workers ou des règles Nginx, et finissent avec des erreurs de validation massives.

Google ne bloque pas techniquement la diffusion conditionnelle, mais punit indirectement via l'invalidation des paires et la perte du badge AMP. Les logs montrent que Googlebot mobile crawle depuis des IP américaines, européennes et asiatiques de manière aléatoire. Si votre serveur refuse l'accès à certaines IP, le cache AMP ne se met jamais à jour correctement. [A vérifier] : aucune donnée publique ne chiffre précisément le taux d'échec de validation lié à la géolocalisation, mais les remontées Search Console parlent d'elles-mêmes.

Quelles nuances faut-il apporter à cette position de Google ?

La déclaration de Mueller laisse une porte entrouverte en parlant de « techniquement possible mais compliqué ». Concrètement, si vous géolocalisez AMP via des sous-domaines distincts (uk.example.com/amp, fr.example.com/amp) avec des balises canonical et amphtml propres par pays, ça peut fonctionner. Mais vous perdez l'unicité du cache et devez gérer autant de validations que de zones géographiques.

L'autre nuance : AMP n'est plus un facteur de ranking direct depuis la mise à jour Page Experience. La pression pour implémenter AMP a baissé, donc la question de la géolocalisation devient moins critique. Si votre site est déjà rapide en HTML standard (Core Web Vitals au vert), vous pouvez vous passer d'AMP régionalisé sans impact SEO majeur.

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

Si vous utilisez AMP uniquement pour les stories ou les emails (AMP4Email), la géolocalisation serveur n'est pas un problème, car ces formats ne dépendent pas du cache Google Search. Les AMP stories sont servies via le viewer de Google, qui gère lui-même la distribution géographique.

De même, si vous hébergez AMP sur un CDN avec edge computing (Cloudflare, Fastly) et que vous servez dynamiquement du contenu selon la géo sans toucher à l'URL, Google peut accepter la variation tant que la structure HTML AMP reste valide. Mais attention : toute modification du DOM via JavaScript côté client invalide le format AMP strict. [A vérifier] : les edge workers peuvent-ils modifier le HTML avant mise en cache sans casser la validation ? Les retours terrain manquent.

Que faut-il faire concrètement si on veut quand même géolocaliser AMP ?

D'abord, abandonnez l'idée de bloquer AMP par IP ou par pays côté serveur. À la place, optez pour des sous-domaines ou sous-répertoires distincts par région, chacun avec ses propres paires canonical/AMP. Par exemple : uk.example.com et fr.example.com, chacun avec /amp/ dédié. Configurez hreflang sur les versions canonical ET AMP pour éviter le duplicate content.

Ensuite, vérifiez que chaque version AMP est accessible globalement sans restriction géographique. Le cache AMP doit pouvoir crawler depuis n'importe quel datacenter Google. Si vous devez absolument bloquer certaines zones pour des raisons légales (RGPD, licences de contenu), alors renoncez à AMP pour ces régions et servez uniquement du HTML standard rapide.

Quelles erreurs éviter absolument dans ce contexte ?

Ne servez jamais une redirection 302 ou 301 conditionnelle vers la version HTML classique selon la géolocalisation. Google interprétera cela comme une incohérence entre la balise <link rel="amphtml"> déclarée et la réalité de l'URL. Résultat : erreur « URL AMP introuvable » dans la Search Console.

Évitez aussi de modifier le contenu AMP via JavaScript côté client en fonction de la géo détectée. Même si techniquement faisable avec des scripts externes, cela viole souvent les règles AMP strictes et peut invalider la validation. Préférez toujours une génération serveur statique ou un edge computing compatible AMP.

Comment vérifier que la mise en œuvre reste conforme aux attentes de Google ?

Utilisez la Search Console pour surveiller les erreurs AMP par propriété (si vous avez segmenté par sous-domaine). Vérifiez que chaque URL canonical a bien sa paire AMP validée, sans messages d'invalidation. Testez manuellement depuis des IP de différents pays via VPN pour confirmer que le cache AMP se charge correctement.

Lancez aussi un crawl Screaming Frog ou OnCrawl avec user-agent Googlebot mobile depuis plusieurs localisations géographiques (via proxies). Si vous voyez des différences d'accessibilité selon l'IP source, c'est que votre configuration géolocalisée pose problème. Corrigez avant que Google ne désindexe vos pages AMP.

• Segmenter par sous-domaine ou sous-répertoire dédié par pays, jamais par détection IP conditionnelle.
• Configurer hreflang sur canonical ET AMP pour chaque langue/région.
• Tester l'accessibilité AMP depuis plusieurs datacenters Google via proxies ou VPN.
• Surveiller les rapports Search Console AMP chaque semaine après déploiement.
• Éviter toute redirection géolocalisée sur les URL AMP déclarées dans les balises amphtml.
• Privilégier du HTML standard rapide si la géolocalisation AMP devient trop complexe à maintenir.