Google.com/goto : la mise à jour anti-scraping de Google rend chaque résultat plus difficile à extraire

Google a ajouté une requête supplémentaire entre les résultats de recherche et les pages de destination, créant un conflit direct avec les outils qui collectent des URL de résultats à grande échelle. Ce changement, connu sous le nom de google.com/goto : la mise à jour anti-scraping de Google, remplace de nombreux liens organiques directs par des adresses de redirection Google opaques.

Le résultat de recherche reste familier pour une personne. Son titre, le domaine affiché, le favicon et sa description restent visibles. Cependant, le lien sous-jacent peut désormais pointer vers google.com/goto?url=... plutôt que vers la page de l’éditeur.

Cette distinction compte, car la valeur encodée n’expose pas l’URL de destination complète. Un navigateur peut demander à Google de la résoudre automatiquement. Un scraper doit effectuer une requête supplémentaire, gérer la réponse et éviter de déclencher les défenses de Google.

Google présente ce déploiement comme une mesure technique contre les abus. Le changement ne bloque pas catégoriquement la collecte automatisée. Il transforme plutôt une tâche peu coûteuse d’analyse HTML en une séquence de requêtes plus bruyante que Google peut observer.

C’est le conflit central. Les utilisateurs de la recherche ont toujours besoin de liens sortants fiables, tandis que Google cherche à mieux contrôler l’accès automatisé à ses résultats. Les entreprises d’API SERP, les plateformes SEO, les chercheurs et les développeurs d’IA évoluent désormais dans cette tension.

Google.com/goto : la mise à jour anti-scraping de Google modifie la couche des liens

Google n’a pas changé ce qu’affiche un résultat organique, mais a modifié la manière dont les logiciels atteignent sa destination.

Un résultat Google traditionnel plaçait directement la page de destination dans l’attribut href de l’élément d’ancrage. Un logiciel pouvait télécharger une page de résultats, analyser son HTML et extraire plusieurs URL complètes.

La nouvelle structure insère une redirection contrôlée par Google. L’ancre du résultat peut pointer vers une adresse /goto contenant une valeur qui commence souvent par CAES. Cette valeur représente la destination sans la publier sous forme de texte lisible.

Lorsqu’une personne clique sur le résultat, le navigateur demande l’adresse /goto. Google renvoie alors une redirection HTTP qui envoie le navigateur vers la page réelle. La transition est généralement trop rapide pour être remarquée par l’utilisateur.

Google a confirmé le déploiement le 26 août 2026. Un porte-parole a déclaré que l’entreprise déploie régulièrement des mesures techniques contre l’évolution des abus afin de protéger ses services et ses utilisateurs. La confirmation a décrit cette redirection comme l’une de ces mesures.

L’entreprise n’a pas publié de spécification technique pour le jeton. Elle n’a pas non plus expliqué tous les signaux qui déterminent quels navigateurs, régions ou sessions reçoivent les liens réécrits.

Les premières observations ont précédé cette confirmation. Des spécialistes de la recherche ont signalé ce schéma en juin et juillet, alors qu’il semblait encore s’agir d’un test limité. Fin août, plusieurs fournisseurs de données observaient un déploiement bien plus large.

La confirmation du déploiement faisait état d’une couverture presque complète auprès de plusieurs fournisseurs d’IP résidentielles. Cette estimation provenait de Derek Perkins, de l’entreprise de suivi de positionnement Nozzle, et non de Google.

Autom, un fournisseur d’API de données de recherche, a rapporté une progression similaire. Son équipe a d’abord rencontré /goto sur une faible part des pages de résultats. Elle a ensuite constaté ce format de manière constante dans des sessions déconnectées et de navigation privée.

Le compte rendu technique du fournisseur indique que le paramètre opaque ne peut pas être converti en destination par un décodage local ordinaire. La destination est plutôt fournie via la réponse de redirection.

Ce format diffère de l’ancien wrapper /url de Google. Celui-ci incluait souvent une destination lisible, encodée dans l’URL, dans sa chaîne de requête. Un logiciel pouvait extraire cette valeur sans recontacter Google.

Avec /goto, le résultat de recherche visible et la destination exploitable deviennent deux éléments de données distincts. Google affiche toujours suffisamment d’informations pour qu’une personne puisse évaluer le résultat. Toutefois, le code source de la page ne garantit plus une URL sortante réutilisable.

C’est le changement significatif. Google a déplacé la résolution des destinations du HTML statique vers une interaction avec son propre serveur.

Pourquoi une redirection supplémentaire met les fournisseurs de données de recherche sous pression

La redirection crée un coût marginal pour chaque résultat résolu, et ce coût se cumule dans les systèmes de collecte à fort volume.

Un scraper élémentaire n’avait auparavant besoin que d’une requête pour recueillir plusieurs destinations organiques depuis une page de résultats. Avec le nouveau format, il peut avoir besoin de la requête initiale, plus une requête de résolution pour chaque jeton /goto unique.

Prenons un service qui surveille de nombreuses requêtes selon les emplacements, les appareils et les langues. Il peut collecter plusieurs pages pour chaque requête et répéter cette collecte tout au long de la journée. Une requête supplémentaire par résultat devient rapidement une charge d’infrastructure considérable.

Le coût ne se limite pas à la bande passante. Chaque résolution ajoute de la latence, de la gestion des connexions, une logique de nouvelle tentative et une occasion supplémentaire d’échec. Elle crée aussi un flux reconnaissable de requêtes dirigées vers le point de terminaison de redirection de Google.

Google peut observer la vitesse à laquelle un client résout les liens. Il peut comparer ces requêtes avec les cookies, les identités réseau, les caractéristiques du navigateur et l’activité de recherche antérieure. Google n’a pas révélé quels signaux il utilise ici.

La mise à jour va donc au-delà d’un nouveau format d’analyse. Elle crée un point de contrôle côté serveur entre l’obtention de la page de résultats et la connaissance de chaque destination exacte.

Le suivi traditionnel du positionnement illustre cette pression. Un outil de suivi de position doit identifier quelle page est classée pour une requête, et non simplement quel domaine apparaît. Les chemins exacts importent lorsqu’un site possède plusieurs pages en concurrence sur le même sujet.

Un outil qui stocke la redirection Google au lieu de l’URL de l’éditeur peut produire des enregistrements trompeurs. Il peut signaler des résultats manquants, fusionner des pages distinctes ou faire passer des changements de pages de destination pour des changements de classement.

Les API de recherche font face à un problème connexe. Leurs clients attendent des URL de destination propres et structurées. Ces clients ne devraient pas avoir à comprendre le wrapper de liens actuel de Google ou à réécrire leurs intégrations chaque fois que le format évolue.

Autom indique avoir modifié son pipeline pour résoudre les liens /goto tout en préservant ses champs de réponse existants. Cette approche déplace la charge de compatibilité des clients de l’API vers le fournisseur de données.

Cette correction dépend toujours de la disponibilité du service de redirection de Google pour le collecteur. Elle suppose également que le comportement actuel des réponses restera stable. Google n’a pris aucun engagement sur ces deux points.

Les produits de recherche et de recherche documentaire basés sur l’IA font face à une autre forme de pression. Certains systèmes utilisent des API de recherche commerciales, tandis que d’autres recueillent des pages de résultats via leur propre infrastructure. Ces deux approches dépendent d’un accès prévisible aux URL sources.

La redirection n’empêche pas un modèle de lire une destination une fois celle-ci fournie. Elle affecte le processus de découverte en amont qui trouve, classe et récupère les sources avant le début de l’analyse.

Les travailleurs du savoir peuvent en subir les effets indirectement. Un assistant de recherche peut manquer des sources lorsque son connecteur de recherche gère mal les URL de redirection. Il peut également stocker des wrappers Google là où les utilisateurs attendent des liens stables vers les éditeurs.

Cela rend la provenance plus difficile à inspecter. Un dossier de recherche fiable devrait conserver la page qui étaye une affirmation, et non une adresse de routage temporaire détenue par le moteur de recherche.

Les équipes qui construisent des systèmes de recherche internes devraient donc séparer l’identité de la source des métadonnées de découverte. Une base de connaissances IA interrogeable ne reste utile que lorsque ses citations renvoient à des documents durables.

La pression immédiate s’exerce sur les intermédiaires des données de recherche. Le risque en aval touche tout produit qui considère leur sortie comme une infrastructure de sources fiable.

Le véritable affrontement oppose les résultats ouverts à la résolution contrôlée

Google publie toujours une page de résultats lisible, mais contrôle de plus en plus les actions nécessaires pour transformer cette page en données réutilisables.

Il ne s’agit pas simplement de Google contre une entreprise de scraping. L’affrontement principal oppose deux modèles techniques d’accès aux résultats de recherche accessibles au public.

Le premier modèle considère une page de résultats comme un document. Un client la télécharge, lit les liens intégrés au HTML et décide de la suite. Une grande partie du Web naissant fonctionnait selon ce schéma simple.

Le second modèle considère les résultats comme un service interactif. Ce que l’utilisateur voit reste accessible, mais les valeurs importantes ne deviennent disponibles qu’au moyen de requêtes supplémentaires régies par la plateforme.

Le déploiement de /goto rapproche Google Search du second modèle. Il le fait sans supprimer les résultats organiques ni imposer un nouveau flux de travail aux utilisateurs ordinaires.

Cette nuance est importante. Qualifier cette mise à jour d’interdiction du scraping surestime son effet. Les liens restent résolubles et des tests indépendants montrent que les développeurs peuvent toujours récupérer leurs destinations.

ScrapingBee a testé /goto sur différents navigateurs, sessions automatisées et configurations réseau. Ses expériences de redirection ont montré que le jeton pouvait être décodé structurellement, mais pas converti localement en URL d’origine.

L’entreprise a rapporté qu’une requête HTTP GET avec les redirections automatiques désactivées renvoyait une réponse 302 et un en-tête Location. Cet en-tête contenait l’adresse de destination.

Ses tests ont également montré que les requêtes HEAD se comportaient différemment. Elles renvoyaient des réponses 200 sans l’en-tête de localisation nécessaire, obligeant les collecteurs à utiliser GET pour une résolution fiable.

Cette conclusion contredit la recommandation initiale d’Autom de lire l’emplacement avec HEAD. La différence peut refléter l’évolution du comportement, les conditions de test ou plusieurs variantes de déploiement.

Les développeurs ne devraient considérer aucune des deux méthodes comme un contrat permanent. Une implémentation défensive peut tester le comportement des réponses, prendre en charge plusieurs wrappers et enregistrer les échecs sans corrompre les URL stockées.

ScrapingBee a mesuré 50 résolutions avec une médiane d’environ 3,27 secondes lorsqu’elles étaient traitées séquentiellement. Cinq workers ont ramené la médiane à environ 1,23 seconde dans son environnement.

Ces chiffres proviennent des tests d’un seul fournisseur, et non d’un benchmark universel. L’emplacement réseau, la réutilisation des connexions, les réponses de Google et la limitation de débit peuvent produire des résultats différents.

L’expérience clarifie néanmoins le compromis. La mise à jour ajoute de la friction, mais une concurrence modérée peut en absorber une partie. Cette mesure est donc plus susceptible de remodeler les coûts que d’éliminer le scraping.

L’interaction avec le serveur offre aussi à Google des options que les liens statiques ne proposaient pas. L’entreprise peut ajuster les réponses, modifier les formats de jetons, appliquer des contrôles de débit ou distinguer les types de clients.

Google contrôle déjà la page de résultats de recherche elle-même. Toutefois, les URL sortantes directes limitaient l’implication de l’entreprise après qu’un client avait reçu le HTML. /goto étend cette implication à la résolution de destination.

Ce changement s’inscrit dans d’autres efforts ayant compliqué la collecte à grande échelle. Google a renforcé ses défenses contre le trafic automatisé et modifié des paramètres de pages de résultats que les collecteurs utilisaient auparavant pour obtenir des jeux de résultats plus importants.

Chaque ajustement pris isolément peut être contourné par l’ingénierie. Ensemble, ils rendent l’accès non officiel moins prévisible et augmentent la valeur d’une infrastructure de collecte maintenue.

Cette évolution révèle également une symétrie inconfortable. Google construit son index en crawlant d’autres sites web, tout en restreignant les systèmes automatisés qui collectent la présentation par Google de cet index.

Les activités ne sont pas identiques. Googlebot respecte les contrôles des éditeurs, construit un produit de recherche et fonctionne selon des systèmes d’exploration documentés. Les scrapers de SERP collectent les pages de classement générées par Google, souvent en dehors d’une relation avec une API prise en charge.

Malgré cela, éditeurs et développeurs constatent ce déséquilibre. Google attend du web ouvert qu’il reste techniquement accessible tout en rendant sa propre couche d’agrégation progressivement plus difficile à réutiliser.

Un fil de discussion communautaire très commenté a reflété ce différend. Il avait recueilli 472 points et 369 commentaires au moment de la capture fournie avec cet article.

Certains participants ont jugé cette mise à jour raisonnable pour protéger le service. D’autres l’ont décrite comme une nouvelle clôture autour d’informations issues de sites web publics. Plusieurs se sont concentrés sur le défi d’ingénierie pratique plutôt que sur le débat de principe.

L’interprétation la plus solide se situe entre ces positions. Google n’a pas fermé ses résultats de recherche, mais a rendu la réutilisation à grande échelle davantage dépendante d’interactions contrôlées par Google.

La mise à jour ajoute de la friction, sans bloquer totalement le scraping

La plus grande incertitude est de savoir si `/goto` restera un format de redirection gérable ou deviendra une couche d’un système d’application plus strict.

Le mécanisme actuel présente des limites visibles. Un scraper peut demander chaque redirection et lire sa destination. Certaines copies de l’URL sous-jacente peuvent aussi rester présentes ailleurs dans la page rendue.

Google a besoin des informations de destination pour afficher les domaines, favicons, fils d’Ariane et attributions. Selon le format du résultat, les collecteurs peuvent reconstituer une partie de l’identité sans résoudre chaque lien.

Cela ne produit pas toujours la page d’atterrissage exacte. Un domaine affiché ne permet pas de distinguer une page produit d’un article d’assistance sur le même site. Le texte du fil d’Ariane peut également omettre des paramètres ou des composants du chemin.

Le déploiement n’est pas uniforme non plus. ScrapingBee a signalé /goto dans Chrome, Edge, Playwright et son propre environnement de collecte. Brave et LibreWolf renvoyaient des liens directs durant la même série de tests.

Safari renvoyait un autre wrapper Google plutôt que le même format /goto. Changer l’emplacement du proxy ne supprimait pas systématiquement la redirection.

Ces résultats suggèrent des variations selon le client, mais ne révèlent pas les règles de sélection de Google. Le type de navigateur peut être corrélé au résultat sans en être directement la cause.

Les jetons semblaient également portables dans les tests de ScrapingBee. Des jetons collectés via une connexion pouvaient être résolus ultérieurement par un autre client, sans les cookies ou le proxy d’origine.

Ils restaient utilisables pendant plus de 24 heures dans ces expériences. Leur durée de vie maximale demeure inconnue, et Google pourrait modifier les règles de portabilité ou d’expiration sans préavis.

Cette incertitude doit orienter les décisions d’ingénierie. Un collecteur de production ne devrait pas stocker des jetons opaques comme s’il s’agissait d’identifiants permanents. Il devrait résoudre et valider les destinations au plus près du moment de la collecte.

Il devrait également conserver le wrapper d’origine à des fins de diagnostic. Conserver les deux valeurs aide les équipes à distinguer un changement de classement d’un échec du résolveur ou d’une nouvelle variante de réponse Google.

Les tentatives doivent être soigneusement limitées. Une résolution agressive peut amplifier le schéma de requêtes que cette modification semble conçue pour mettre en évidence. Des tentatives illimitées peuvent aussi accroître les coûts lors de pannes partielles.

Les systèmes de collecte devraient dédupliquer les jetons identiques avant de les résoudre. ScrapingBee a constaté des jetons répétés dans certaines pages de résultats, ce qui permet d’éviter des requêtes dupliquées inutiles.

Les fournisseurs doivent également surveiller plusieurs frontières. Ils devraient suivre la part des résultats utilisant chaque wrapper, les taux de réussite de résolution, les codes de réponse et les distributions de latence.

Une hausse soudaine des URL Google dans les données clients est un incident d’analyse, pas la preuve que les éditeurs ont disparu de la recherche. Distinguer ces situations évite de fausses alertes de classement.

Les équipes d’analytique se posent une autre question. Elles veulent savoir si la redirection modifie l’attribution des référents lorsqu’un humain arrive sur le site d’un éditeur.

Une redirection côté serveur peut toujours mener vers la destination attendue tout en préservant des signaux de référent exploitables. L’attribution réelle dépend du comportement du navigateur, des en-têtes, de la configuration analytique et de l’implémentation de Google.

Aucune base vérifiée ne permet d’affirmer que le déploiement détruit largement l’attribution organique. Les opérateurs de sites devraient examiner leurs propres requêtes d’atterrissage et classifications analytiques avant d’en tirer cette conclusion.

Les directives générales de Google sur les redirections expliquent comment son crawler interprète les types de redirection courants. Elles ne documentent pas /goto comme surface d’intégration publique pour les collecteurs tiers.

Cette différence compte. La documentation Google Search Central indique aux éditeurs comment rediriger leurs propres pages. Elle ne promet pas un comportement stable pour les wrappers de recherche sortants de Google.

Les utilisateurs font face à un compromis plus modeste, mais réel. Survoler un résultat peut révéler une adresse Google au lieu de la destination complète. Le domaine affiché fournit toujours du contexte, mais l’aperçu d’état du navigateur devient moins informatif.

Cela peut affaiblir une vérification de sécurité familière. Un utilisateur prudent peut vouloir inspecter la destination exacte avant d’ouvrir un lien, surtout lorsque plusieurs pages partagent des titres similaires.

Google peut soutenir que ses étiquettes de domaine visibles et ses protections contre les abus restent efficaces. Les critiques peuvent raisonnablement répondre qu’une étiquette contrôlée par une plateforme n’est pas équivalente à l’inspection du lien réel.

Aucune de ces préoccupations ne prouve que le déploiement nuit à la plupart des utilisateurs. Elles montrent que les mesures anti-automatisation peuvent modifier la transparence même lorsque l’expérience de clic semble inchangée.

Les éléments disponibles soutiennent actuellement une conclusion limitée. /goto augmente les coûts de collecte, casse les analyseurs simplistes et étend le contrôle de Google sur la résolution des destinations.

Ils ne soutiennent pas l’affirmation plus forte selon laquelle Google aurait rendu le scraping des recherches impossible. Des fournisseurs ont déjà démontré des chemins de résolution fonctionnels, même si ces chemins comportent de nouveaux risques opérationnels.

Ce que la mise à jour anti-scraping de Google oblige les équipes à surveiller ensuite

Trois signaux détermineront s’il s’agit d’une simple mise à jour d’analyseur ou d’un changement durable dans l’économie des données de recherche.

Le premier signal est la couverture des formats de lien. Les fournisseurs devraient mesurer la fréquence d’apparition des URL directes, des wrappers /url et des jetons /goto selon les navigateurs, régions et états de session.

Un mélange stable renforcerait l’idée que Google exécute un système de contrôle segmenté. Une évolution rapide vers des liens /goto universels renforcerait l’interprétation anti-scraping.

Un retour aux liens directs affaiblirait la conclusion plus large. Cela suggérerait que les problèmes de compatibilité, les préoccupations des utilisateurs ou les résultats expérimentaux ont prévalu sur le contrôle supplémentaire.

Le deuxième signal est le comportement du résolveur. Les équipes devraient suivre si une simple requête GET continue de renvoyer un en-tête 302 Location exploitable sans session de navigateur.

Si cette voie reste disponible, les fournisseurs expérimentés pourront considérer la mise à jour comme un coût d’infrastructure supplémentaire. Les scrapers basiques échoueront, mais les systèmes entretenus pourront continuer à fonctionner.

De nouvelles exigences d’authentification, une courte durée de vie des jetons, des limites de débit strictes ou des jetons liés au client augmenteraient sensiblement la barrière. Ils indiqueraient que Google renforce le point de contrôle plutôt que de simplement réécrire les liens.

Les changements dans le comportement de HEAD et GET méritent également de l’attention. Les premiers rapports contradictoires montrent pourquoi les fournisseurs ont besoin de tests directs au lieu de s’appuyer sur une seule recette d’implémentation.

Le troisième signal est la qualité des données dans les produits SEO et d’IA. Les clients devraient surveiller les pages d’atterrissage manquantes, les URL Google dupliquées, la volatilité inexpliquée des classements ou les citations qui s’arrêtent aux wrappers de redirection.

Ces symptômes montreraient que certains fournisseurs ne se sont pas pleinement adaptés. Des résultats stables suggéreraient que les éditeurs ont absorbé le changement sans transférer une grande partie de la charge aux clients.

Les acheteurs de données de recherche devraient poser des questions concrètes aux fournisseurs. Le service renvoie-t-il la destination finale ? Préserve-t-il les paramètres canoniques ? Comment étiquette-t-il les résultats non résolus ?

Ils devraient aussi demander si les positions rapportées ont changé à cause du format des liens. Un outil de classement doit séparer les erreurs de collecte des changements réels dans l’ordre établi par Google.

Les équipes produit d’IA ont besoin de vérifications similaires concernant les citations. Chaque affirmation récupérée devrait être reliée à l’URL finale de l’éditeur, les échecs de collecte restant visibles pour les opérateurs.

La prochaine déclaration publique de Google compte également, même si l’entreprise peut fournir peu de détails supplémentaires. Une explication officielle concernant la protection des utilisateurs ou les catégories d’abus réduirait le débat sur les intentions.

La déclaration actuelle confirme que /goto est une mesure de protection. Elle ne précise pas si les crawlers d’IA, les outils SEO, la mesure des clics ou une autre catégorie d’abus ont motivé cette conception.

Les conflits juridiques pourraient apporter davantage de contexte. Google a contesté certaines entreprises qui collectent et revendent des résultats de recherche, montrant que les contrôles techniques coexistent avec des pressions juridiques.

Cependant, /goto affecte un éventail de clients plus large que n’importe quel défendeur isolé. Des chercheurs, outils d’accessibilité, extensions de navigateur et systèmes internes de surveillance peuvent rencontrer les mêmes wrappers.

Les prochains mois révéleront si Google distingue ces usages. Des restrictions uniformes favoriseraient les fournisseurs de données centralisés capables de maintenir de vastes systèmes de résolution.

Un accès sélectif pourrait produire un marché différent. Les partenaires pris en charge et les interfaces approuvées gagneraient en importance, tandis que la collecte non officielle deviendrait moins fiable.

Pour les développeurs, la réponse immédiate est simple. Traitez les liens des résultats de recherche comme des données variables, validez les destinations, conservez le contexte de diagnostic et surveillez les échecs de résolution séparément des changements de classement.

Pour les acheteurs, la tâche est de vérifier. Demandez si votre fournisseur SEO, de surveillance ou de recherche s’est adapté avant de faire confiance à une évolution inattendue de ses rapports.

Pour les travailleurs du savoir, inspectez les citations lorsqu’un système de recherche automatisé renvoie un wrapper Google. Une réponse exploitable devrait mener à la source sous-jacente, et non s’arrêter à la couche de routage du moteur de recherche.

Google.com/goto : la mise à jour anti-scraping de Google n’est donc ni un blocage total ni une redirection cosmétique. C’est une barrière architecturale placée à un point précieux du pipeline de données de recherche.

Surveillez si ce péage reste une requête peu coûteuse. S’il s’accompagne de contrôles d’identité plus stricts, de jetons à durée de vie plus courte ou de limites plus serrées, la réparation actuelle de l’analyseur deviendra un différend plus vaste sur l’accès.