Le paramètre srsltid dans les URLs e-commerce : faut-il s'en préoccuper en SEO ?

D'où vient ce mystérieux paramètre srsltid ?

Le paramètre srsltid apparaît dans les URLs lorsque Google ajoute automatiquement des tags de suivi pour les sites e-commerce utilisant Merchant Center. C'est une forme d'auto-tagging comparable à ce que fait Google Ads avec les paramètres gclid.

Contrairement aux paramètres UTM que vous ajoutez manuellement, celui-ci est injecté côté Google, après la génération complète des SERP. L'utilisateur clique sur un résultat contenant déjà ce paramètre — votre serveur le reçoit tel quel.

Pourquoi Google fait-il ça ?

L'objectif est de fournir aux marchands des données de conversion précises dans leur compte Merchant Center. Google veut savoir quel clic organique provenant d'un produit listé dans ses services shopping a généré une vente.

Ce tracking permet d'alimenter les rapports de performance des fiches produits et d'améliorer les recommandations algorithmiques pour l'affichage des produits dans les résultats enrichis.

Ce paramètre impacte-t-il le SEO technique ?

Non. Puisqu'il est ajouté après indexation, Googlebot ne le voit jamais pendant le crawl. Vos directives de canonicalisation, votre robots.txt ou vos balises meta n'ont aucune prise dessus.

Le paramètre n'existe que dans l'URL cliquée par l'utilisateur — pas dans l'URL indexée par Google. Il n'y a donc aucun risque de contenu dupliqué lié à ce paramètre.

• Le srsltid est un paramètre de tracking post-SERP ajouté par Google lui-même
• Il ne passe jamais par le crawl ou l'indexation — donc invisible pour Googlebot
• Impossible à contrôler via canonicalisation, robots.txt ou meta robots
• Utilisé exclusivement pour mesurer les conversions e-commerce via Merchant Center
• Aucun impact sur le duplicate content ou le ranking

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, parfaitement. Les sites e-commerce reliés à Merchant Center voient effectivement apparaître ce paramètre dans leurs logs serveur et leurs outils analytics — mais jamais dans Search Console côté indexation.

C'est un comportement identique à celui du gclid pour Google Ads : ajouté dynamiquement lors du clic, invisible pour le moteur lui-même. Les équipes techniques qui paniquent en voyant ces paramètres polluer leurs URLs peuvent donc respirer.

Faut-il quand même faire quelque chose côté analytics ?

Dépend de votre configuration. Si vous utilisez Google Analytics 4, le paramètre est automatiquement reconnu et traité correctement. Si vous êtes sur une solution tierce (Matomo, Piano, etc.), vérifiez que votre configuration exclut ce paramètre de la construction des URLs uniques.

Sinon, vous risquez de fragmenter vos données de trafic avec des URLs considérées comme distinctes alors qu'elles pointent vers la même page. Ce n'est pas un problème SEO — c'est un problème de propreté analytique.

Y a-t-il des cas où ce paramètre pose problème ?

Rarement, mais ça arrive. Certains CMS mal configurés ou certains CDN peuvent interpréter ce paramètre comme une variation de contenu et générer une version cachée différente. Dans ce cas, vous servez techniquement la même page, mais avec un cache distinct.

Si votre infrastructure interprète les paramètres d'URL comme des variations de contenu à mettre en cache séparément, vous gaspillez des ressources serveur pour rien. La solution ? Configurez votre CDN pour ignorer ce paramètre lors de la génération des clés de cache.

Que faut-il vérifier concrètement sur mon site e-commerce ?

Premièrement, consultez vos logs serveur pour confirmer que ce paramètre apparaît bien uniquement dans les requêtes utilisateur, jamais dans les requêtes Googlebot. Si vous le voyez dans les user-agents de crawlers, c'est anormal.

Deuxièmement, vérifiez dans Search Console que vos URLs indexées ne contiennent pas ce paramètre. Inspectez quelques pages produits : l'URL canonique doit être propre, sans srsltid.

Dois-je modifier ma configuration technique ?

Normalement, non. Mais si vous avez une infrastructure complexe avec plusieurs couches de cache, assurez-vous que le paramètre srsltid est exclu de vos règles de cache. Sinon, vous créez inutilement des variations de cache pour la même page.

Pour les sites sur Cloudflare, Fastly ou similaires, ajoutez srsltid à la liste des query strings à ignorer dans votre configuration CDN. C'est une simple ligne de config qui peut vous faire économiser de la bande passante.

Quelles erreurs éviter absolument ?

Ne tentez pas de bloquer ce paramètre via robots.txt ou via une règle serveur qui renverrait une 404. Vous casseriez les liens cliqués par les utilisateurs — catastrophique pour le taux de rebond et les conversions.

Ne créez pas non plus de redirections 301 pour « nettoyer » ces URLs. Les utilisateurs arrivent avec ce paramètre, votre site doit l'accepter normalement et servir la page sans broncher. Le tracking Google a besoin que l'URL reste intacte.

• Vérifier dans les logs que srsltid n'apparaît que dans les requêtes utilisateur, jamais côté Googlebot
• Confirmer dans Search Console que les URLs indexées sont propres (sans srsltid)
• Configurer le CDN pour ignorer srsltid lors de la génération des clés de cache
• Exclure srsltid de la construction des URLs uniques dans votre outil analytics (si ce n'est pas GA4)
• Ne pas bloquer, rediriger ou rejeter les URLs contenant ce paramètre
• Documenter ce paramètre dans votre équipe pour éviter les fausses alertes futures