Gérer la redirection /goto de Google dans votre pipeline SERP

Les liens des résultats de recherche Google masquent désormais l'URL réelle derrière un jeton /goto. Détectez-le, résolvez-le en une requête et redonnez sa précision à vos données de positions — en 30 minutes.

Le résumé en 30 secondes

Le 26 août 2026, Google a confirmé que les liens des résultats de recherche passent désormais par google.com/goto?url=[jeton chiffré] avant d'atteindre leur destination. Barry Schwartz l'a rapporté dans Search Engine Roundtable et Search Engine Land, et un porte-parole de Google a confirmé que le déploiement s'inscrit dans « des mesures techniques de long terme contre des formes d'abus en évolution ».

Si votre équipe extrait des URL de destination des résultats de recherche Google (suivi de positions, scraping de SERP, collecte de données pour l'IA), un présupposé vient de se briser : l'URL réelle n'est plus visible dans le lien. Elle est chiffrée dans un jeton que le navigateur suit comme une redirection ordinaire.

Bonne nouvelle : c'est réparable, et le correctif est plus petit que ce que la plupart imaginent. Le jeton ne se déchiffre pas, mais il se résout avec une seule requête HTTP supplémentaire, et comme il est déterministe, il se met en cache. Cet article vous guide dans un correctif de 30 minutes : détecter le changement, résoudre en sécurité et vérifier que vos rapports affichent toujours les bonnes pages. Si vous ne scrapez pas le SERP et ne comparez pas les positions avec des URL extraites de ces pages, passez directement à « Ce que le changement ne touche pas ». Rien ne change sur votre site.

Ce qui a exactement changé

Pendant des années, le lien d'un résultat Google portait la destination réelle dans le lien lui-même :

html
<a href="https://yoursite.com/landing-page?utm_...">...

Ce même résultat peut maintenant porter un lien de transit :

html
<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...

En le suivant, Google renvoie une redirection HTTP vers la destination. Deux points importants sur son fonctionnement :

  • Le jeton est chiffré et indétournable. D'après une rétro-ingénierie indépendante (publiée en août 2026), il se compose d'un marqueur d'1 octet, d'un identifiant de clé de 4 octets et de données au format Tink. Modifiez un caractère et Google répond HTTP 400. Vous ne pouvez ni forger un jeton ni décoder l'URL sans les clés de Google.
  • Le jeton est déterministe. La même URL de destination produit toujours le même jeton. Cela suffit à rendre tout le correctif bon marché : résoudre une fois, puis s'appuyer sur le cache du jeton.

Derek Perkins, de Nozzle, a observé un déploiement proche de « 100 % » chez plusieurs fournisseurs d'IP résidentielles, ce qui explique pourquoi, cette fois, ce n'est pas qu'une expérimentation.

Ce qui survit au changement

Toujours lisible

A disparu

L'URL affichée sous l'extrait (en général le domaine)

L'URL exacte de destination dans le href

Le paramètre ved (position, type de clic, horodatage)

La correspondance directe d'URL au niveau du lien

Titres des résultats, extraits et positions

Tout décodage de lien côté client

Structure de la redirection /goto de Google : le lien du résultat passe par un jeton google.com/goto chiffré avant qu'une redirection 3xx atteigne la vraie page

Que le paramètre ved survive mérite d'être noté : les données de position et de type de clic que les outils de suivi lisaient dans les liens des résultats sont toujours là. Seule l'URL de destination est masquée.

Ce que le changement ne touche pas

  • Positions et trafic. Le système de classement de Google n'a aucun lien avec les liens qu'il affiche.
  • Les données de Google Search Console. Positions, impressions et clics dans GSC proviennent des données internes de Google et ne sont pas affectés.
  • Les robots qui visitent votre site. Googlebot, GPTBot et tout robot qui explore vos pages ne touche jamais à google.com/goto. Il n'apparaît que dans les liens que Google vous présente.
  • Bing et les autres moteurs. C'est un changement côté Google uniquement.

Seuls sont concernés ceux qui exploitent des pipelines lisant les liens des tables de résultats de Google. Si c'est votre cas, vous le sentirez ; sinon, pour vous, ce n'est que du bruit.

Vérifiez si vous êtes concerné

Exécutez les quatre vérifications. Les deux premières prennent cinq minutes ; les deux dernières sont une conversation avec votre fournisseur.

Vérification

Comment

Si vous voyez ceci

1. Données SERP brutes

Cherchez google.com/goto dans le HTML enregistré ou nouvellement collecté des tables de résultats

Toute occurrence = votre source est déjà tokenisée

2. Échantillon SERP en direct

Lancez une requête habituelle, faites un clic droit sur un résultat et copiez le lien

Un lien goto sur une requête normale = le test est réel

3. Colonne d'URL de votre outil

Récupérez votre dernier rapport de mots-clés : la colonne d'URL affiche-t-elle google.com/goto ou un jeton ?url= ?

L'outil stocke des liens de transit

4. Schémas de dérive des positions

Comparez les changements d'URL suivies cette semaine à vos propres modifications de site

De grands écarts après une semaine calme = un problème d'analyse, pas un changement de position

Si tout est propre, vous n'êtes pas concerné : mettez cette page en favori et avancez.

Si vous trouvez une occurrence, les quatre étapes suivantes rendent sa précision au pipeline. Chaque étape dit quoi faire, ce à quoi ressemble une bonne sortie et comment se rétablir quand ce n'est pas le cas.

Pipeline en quatre étapes pour remettre les données SERP tokenisées dans l'ordre : détecter, résoudre, mettre en cache, vérifier

Étape 1 : Détectez les jetons là où ils apparaissent

Ce qu'il faut faire. Dans votre script d'extraction SERP, collectez tous les liens de résultats et signalez tout ce qui commence par https://www.google.com/goto?url= (faites aussi matcher le /goto?url= nu qui apparaît sur certaines interfaces et le url= suivi d'une charge façon base64). Enregistrez le taux de signalement par requête — c'est votre indicateur de déploiement. Et sur la base de l'observation de Derek Perkins : le déploiement n'est pas uniforme entre plages d'IP, suivez-le donc par fournisseur, pas de façon agrégée.

Résultat attendu. Un goto_rate par requête. 0 % signifie que votre source renvoie encore des liens directs ; 100 % signifie une tokenisation complète.

Contrôle qualité. Lancez la même requête deux fois depuis deux IP différentes. Si l'une est tokenisée et pas l'autre, il y a un partage de plages d'IP, et les deux côtés doivent être traités.

Récupération. Si l'échantillon donne zéro occurrence mais que vous soupçonnez une tokenisation, vérifiez si votre extraction lit un DOM rendu par JavaScript plutôt que le HTML brut. Des jetons peuvent apparaître dans le balisage rendu même quand la réponse brute reste au format ancien.

Étape 2 : Résolvez un jeton avec une seule redirection

Ce qu'il faut faire. Quand le résultat porte un jeton, suivez le lien côté serveur en désactivant le suivi des redirections et lisez l'en-tête Location :

bash
curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i location

La réponse est un HTTP 3xx vers la destination réelle. Conservez-la. Deux règles rendent cette étape peu coûteuse et sûre :

  • Cachez par jeton, pas par URL. Comme la tokenisation est déterministe, une résolution par jeton suffit. Enregistrez token -> resolved_url et réutilisez-le indéfiniment.
  • Ne scrappez jamais `google.com/goto` comme une page. Google a ajouté Disallow: /goto? à son propre robots.txt fin juillet 2026. Cette adresse n'est explicitement pas faite pour être récupérée par des robots ; un fetcher correct suit légèrement le lien du jeton et ne lit que la chaîne de redirections ; un fetcher cassé indexe ou archive l'URL goto elle-même et salit vos données. Fin juillet, près de 3 750 URL de ce type étaient déjà indexées sur google.com lui-même.

Contrôle de coût avant le lancement : un premier balayage de SERP à plusieurs centaines de résultats, c'est des centaines de requêtes supplémentaires vers google.com, exactement le type de charge que surveille la détection de robots de Google. Le cache déterministe réduit cela à une requête par jeton unique — ne faites donc pas l'économie de l'étape.

Résultat attendu. Une table de correspondance stable entre jetons et destinations. Vérifiez dix jetons aléatoires dans un navigateur : chacun doit tomber sur une page plausible.

Contrôle qualité. Confirmez que la longueur du jeton est stable entre URL différentes et que des URL de destination identiques produisent toujours le même jeton. Si la correspondance casse, il y a eu rotation de clés (voir Étape 5).

Récupération. Un jeton qui renvoie 400 est forgé, tronqué ou vient d'une session expirée ; re-scrapez le SERP et réessayez. Deux échecs consécutifs signifient généralement un HTML d'archive obsolète, pas un jeton cassé.

Étape 3 : Stockez la destination, pas l'enveloppe

Ce qu'il faut faire. Le reste du pipeline (correspondance mot-clé/page, contrôles d'indexation, audit de schéma) doit voir l'URL de destination. Après l'Étape 2, conservez donc trois champs par résultat : resolved_url, token et accessed_at. Retirez les liens goto de la colonne d'URL de tout rapport ; une URL google.com dans un rapport de mots-clés est une erreur de qualité de données sous une douzaine de formes.

Si vous ne pouvez pas ajouter de résolveur cette semaine, l'étape intermédiaire sûre est d'omettre complètement la destination plutôt que de stocker le jeton : les données de position et de classement restent significatives, seule la colonne d'URL reste vide. Un outil qui affiche clairement « pas d'URL » est bien plus facile à interpréter qu'un outil qui rapporte une chaîne de jeton comme une vraie adresse.

Résultat attendu. Un rapport dont 100 % des lignes sont des URL http(s) de vos domaines et zéro ligne google.com.

Contrôle qualité. Comparez les données au niveau URL avec Search Console pour dix mots-clés. Les lignes doivent correspondre. Si Search Console donne une position à une URL que votre rapport déclare « introuvable », il y a un trou dans le résolveur ou dans le parseur.

Récupération. Si une petite part des URL échoue encore à la résolution, journalisez ces jetons séparément. La plupart des échecs remontent aux deux coupables de l'Étape 2 : HTML obsolète ou mur de détection de robots sur la requête suivante.

Étape 4 : Vérifiez ce que fait votre fournisseur

Ce qu'il faut faire. Si vous dépendez d'un outil de suivi de positions ou d'une SERP API (y compris celles construites sur des données Google scrapées), le déploiement dure depuis des semaines. Posez ces cinq questions et confrontez-y tout changement dans les rapports :

Question

Bonne réponse

Attention

Vous résolvez les jetons /goto côté serveur ?

Oui, avant de renvoyer les résultats

« On renvoie les URL telles quelles »

La colonne d'URL peut être google.com ?

Jamais

« Rarement » = toujours cassé

Vous mettez en cache les jetons résolus ?

Oui, car déterministes

Tout résoudre à chaque appel grille des crédits

Crédits ou prix changent du fait des redirections ?

Aucun changement prévu

Surfacturation par suivi

Vous utilisez des IP résidentielles ?

Oui

Les IP de datacenter ont été tokenisées plus tôt et peuvent être traitées autrement

Résultat attendu. Soit un correctif confirmé, soit une raison claire de partir. Sous 30 jours, vous devez pouvoir fusionner les URL de vos rapports avec l'historique de changements du site sans bruit.

Voie de repli. Pas d'amélioration fournisseur sous une semaine : remplacez ce point de données par l'API Google Search Console pour les positions, qui provient directement des données de Google et ne voit jamais de jeton. Le prix est un peu moins de détail au niveau du lien ; acceptable si vos décisions exigent de la précision plutôt que des fonctions tierces.

Étape 5 : Surveillez l'étape suivante

Le mécanisme ne reste pas en place. Surveillez trois choses chaque mois :

  1. Rotation de clés. L'échantillon de rétro-ingénierie a trouvé quatre identifiants de clé en circulation, avec un dominant (« ee47aa4d », environ 62 % des jetons). Si une cinquième clé apparaît et que la part dominante bouge, attendez-vous à une invalidation de cache : résolvez les jetons à nouveau à la rotation.
  2. Extension à d'autres surfaces. /goto a aussi été observé dans des liens sponsorisés et d'autres types de résultats. Si vos outils touchent aux annonces ou aux images, élargissez la recherche de l'Étape 1.
  3. Durcissement continu. Ceci s'inscrit dans une séquence plus longue : rendu JavaScript imposé (début 2025), lancement de SearchGuard, fermeture du &num=100 (septembre 2025) et action DMCA sous la Section 1201 contre SerpApi (décembre 2025). Chaque élément est documenté séparément ; l'article de rétro-ingénierie rassemble la plupart. Attendez-vous à ce que récupérer l'URL finale soit de plus en plus difficile, pas de moins en moins.

Vérification du résultat final

  • [ ] Le détecteur de l'Étape 1 tourne en CI ou planifié et journalise goto_rate par requête
  • [ ] Tous les jetons de l'échantillon se résolvent vers des destinations réelles, vérifiées au navigateur
  • [ ] Zéro URL google.com/goto dans vos rapports (cherchez dans le dernier export)
  • [ ] Dix mots-clés correspondent ligne à ligne avec Search Console
  • [ ] Le fournisseur a confirmé la stratégie de résolution, ou les données de positions passent par l'API GSC
  • [ ] Un contrôle dédié de rotation de clés figure dans votre rythme mensuel

Questions fréquentes

Est-ce que cela affecte mes positions ou mon trafic ? Non. Ce qui change, c'est le chemin du clic ; le système de classement, les résultats et ce que voit l'internaute ne changent pas. Vos performances organiques ne sont menacées que si un outil que vous exploitez se met à rapporter des données fausses.

Peut-on décoder un jeton goto ? Pas de l'extérieur. C'est une charge chiffrée au format Tink et changer un caractère renvoie HTTP 400, donc pas de forge possible non plus. La voie praticable est de suivre la redirection et de lire l'en-tête Location — exactement ce que fait le navigateur.

Un scraper a-t-il le droit de suivre les liens `/goto` ? En pratique, suivre un lien à jeton via la redirection est ce que fait un clic de navigateur, mais Google a interdit /goto? dans son robots.txt et ses conditions limitent l'accès automatisé aux résultats de recherche. Si vous scrapez le SERP, vous êtes déjà du mauvais côté de ces conditions ; ce déploiement ne change pas cela, il le rend plus lourd uniquement. Choisissez votre position de conformité avant de construire le résolveur.

Dois-je changer quelque chose sur mon site ? Non. Le changement est entièrement dans les liens que Google affiche. Ce qu'il faut vérifier, ce sont les outils qui lisent le SERP en votre nom — c'est l'Étape 4.

Auteure : Olivia Stone, chercheuse en intelligence SERP chez Auspia (analyse plus de 25 000 requêtes). Elle écrit sur l'analyse SERP, les schémas de classement et la façon dont les changements de résultats de recherche affectent les données de position.

Explorer ce thème

Continuez sur la même piste de croissance