google.com/goto : l'anti-scraping de Google
Ce qui se passe
Google Search réécrit les liens des résultats organiques en google.com/goto?url=... au lieu d'exposer directement l'URL de destination dans le HTML.
Quand vous cliquez sur un résultat, Google redirige vers la page réelle. Le paramètre url utilise un encodage custom, propre à Google. Ce n'est pas un simple base64 de l'URL cible. En pratique, cela ressemble à une référence opaque vers l'enregistrement de la page dans l'index Google.
Fin août 2026, ce comportement apparaît de façon cohérente sur les recherches en navigation privée ou déconnecté d'un compte Google. Cela peut encore être une expérimentation, mais ce n'est plus limité à une petite part des SERP.
Ce n'est pas la même chose que google.com/url
Google utilisait déjà des wrappers de redirection. L'ancien format est google.com/url?q=[URL encodée], où le lien cible est lisible dans la query string.
Le nouveau format goto est différent :
- Le
hrefdu résultat est/goto, pas la destination - On ne peut pas décoder le blob
url=offline - L'URL réelle est dans l'en-tête
Locationde/goto. On interroge cette URL. On ne suit pas la redirection.
Google a encore besoin de la destination pour dessiner la SERP (domaine, favicon, attribution), donc des copies de l’URL restent sur la page. C’est une autre histoire que la lecture de Location. La marche à suivre : google.com/goto : lire Location avec HEAD.
Ce changement compte pour toute personne qui construit un index de recherche à partir des données SERP à grande échelle.
Pourquoi Google fait ça
Cela s'inscrit dans la poussée plus large de Google contre la collecte automatisée de SERP, notamment les crawlers IA et les scrapers SEO qui extraient en masse les URLs de résultats pour bâtir leurs propres index.
Avec des liens en clair, un scraper pouvait parser des milliers d'URLs depuis le HTML sans repasser par Google. Avec goto, chaque résultat exige une requête de plus vers Google juste pour connaître la destination. On lit Location, on ne suit pas jusqu'à la page. C'est plus lent, plus bruyant, et Google obtient un signal clair quand le même client résout des centaines de liens d'affilée.
Combiné à des moves précédents comme la suppression de &num=100 et le durcissement de BotGuard/SearchGuard, Google augmente progressivement le coût du scraping SERP naïf.
Ce que nous avons observé chez Autom
Nous avions repéré les liens goto sur un faible pourcentage de SERP. À ce niveau, il était difficile de livrer un correctif fiable sans casser les réponses pour tout le monde.
Fin août 2026, le pattern est beaucoup plus cohérent pour les sessions déconnectées et privées. Les URLs de résultats sur Google Search sont effectivement toutes en goto dans ces conditions.
Nous suivons le déploiement et testons en continu.
Mise à jour chez Autom.dev
Nous avons mis à jour notre pipeline Google Search pour résoudre les liens google.com/goto (lire Location, sans suivre) et renvoyer l'URL de destination finale dans les réponses API, dans les mêmes champs structurés que nos clients utilisent déjà.
Si vous appelez les endpoints Google Search d'Autom, vous devriez continuer à recevoir des URLs de destination exploitables sans modifier votre intégration. Nous continuerons à surveiller le déploiement Google et à ajuster si le format de redirection change à nouveau.
Lectures associées
- google.com/goto : lire Location avec HEAD
- Google a supprimé num=100
- Google poursuit SerpAPI : ce que SearchGuard révèle
- Scraping SERP avec Google, Bing et Brave
Besoin de données SERP live pendant que Google change les règles ? Essayez 1 000 requêtes gratuites sur les tarifs Autom, ou obtenez une clé API sur app.autom.dev/register.