Google a caché les URL des résultats : redirections goto et que faire maintenant avec le parsing des SERP

```html

Le 26 août 2026, Google a officiellement confirmé : les liens dans les résultats de recherche ne mènent plus directement au site. Au lieu de l'adresse de la page en HTML, il y a un redirigeant de type google.com/goto?url=... avec un token chiffré. Le plus désagréable dans cette histoire est que les liens modifiés ne sont pas visibles par tout le monde. Une personne ordinaire dans son navigateur voit des URL directes. Elles sont cachées précisément de ceux que Google a déjà considérés comme des automatisations.

Que s'est-il passé exactement

Les premiers signaux isolés sont apparus le 23 juin 2026 — Alex Greenland y a prêté attention. Le 2 juillet, Brody Clark a massivement enregistré le phénomène. Et le 26 août, Derek Perkins, PDG de la plateforme de suivi de positions Nozzle, a rapporté un déploiement presque complet, et Google a confirmé le changement officiellement.

La formulation du représentant de l'entreprise pour Search Engine Roundtable était délibérément générale : chez Google, il y a « une longue histoire d'application de mesures techniques contre les formes évolutives d'abus », et l'entreprise « prend régulièrement des mesures pour protéger ses services et ses utilisateurs ». Qui exactement est considéré comme un abus n'a pas été précisé.

La mécanique est simple et donc douloureuse. Auparavant, dans le balisage du résultat, se trouvait l'adresse prête — le parseur la récupérait avec le titre et le snippet en une seule requête. Maintenant, il y a un lien vers un redirigeant intermédiaire de Google, et à l'intérieur — un token protobuf : une chaîne base64 avec le préfixe CAES, suivie d'une charge utile chiffrée. Il est impossible de le déchiffrer de votre côté — vous n'avez pas la clé. Le seul moyen de savoir où mène le lien est de cliquer dessus.

Trois détails qui déterminent le prix de la question

• Le token est à usage unique. Le même lien vers la même page pour la même requête reçoit un nouveau token à chaque affichage. Il ne sera pas possible de construire un annuaire « token → URL » et de le réutiliser.
• HEAD n'aide pas. La requête HEAD renvoie 200 sans l'en-tête Location — c'est-à-dire sans adresse de destination. Un GET complet est nécessaire, qui renvoie 302 avec un délai médian d'environ 59 ms.
• Ce n'est pas seulement le noyau organique qui est touché. Les adresses cachées apparaissent dans les résultats ordinaires, les vidéos, les sources AI Overviews, le bloc « Questions similaires » et dans la publicité (adresses aclk). Dans l'étude de Growtika, 493 liens ont été analysés sur huit requêtes — chaque adresse de destination était cachée.

Les calculs s'avèrent désagréables. Selon l'estimation de Perkins, pour résoudre tous les liens pour cinq pages de résultats pour une seule requête, il faut entre 500 et 1000 requêtes. Une mesure indépendante de scraping.club, après dé-duplication, donne des chiffres plus modestes de 295 à 565 — mais cela reste tout de même deux ordres de grandeur de plus qu'une seule requête, qui était auparavant suffisante.

La citation clé de Perkins décrit l'essence du changement mieux que n'importe quel chiffre : la contrainte liant devient non pas la bande passante ou le stockage, mais les limites de taux.

Pourquoi cela frappe précisément l'automatisation

C'est ici que réside le plus intéressant. Selon les observations de scraping.club, le remplacement des liens n'est pas universel : un utilisateur ordinaire — connecté ou en mode incognito — reçoit toujours des URL directes. Les redirections arrivent systématiquement aux clients automatisés : aux scripts qui lancent le navigateur avec des drapeaux comme --remote-debugging-port, et aux stacks headless avec une automatisation complète.

La conclusion pratique à comprendre avant de commencer à réécrire le parseur : l'apparition de liens goto dans votre réponse est un signal diagnostique. Cela signifie que Google a déjà classé votre client parmi les bots. Vous n'avez pas rencontré un nouveau format de résultats — vous avez vu à quoi ressemble les résultats pour ceux qui ont été détectés. Et il faut d'abord réparer non pas le parseur de liens, mais les critères qui vous distinguent d'un humain : les drapeaux de lancement, l'ordre des en-têtes, l'empreinte TLS, le comportement de la page. Nous avons examiné la méthodologie de cette auto-vérification dans un article sur comment retirer la carte de détection d'un site à partir de ses scripts.

Un détail amusant qui confirme cette version : la résolution des redirections de Google n'est presque pas protégée. Selon les mesures de scraping.club, pour accéder à un lien, il n'est nécessaire ni de proxy, ni d'en-têtes spéciaux, ni d'imitation TLS — une bibliothèque ordinaire requests fonctionne aussi bien qu'un Chrome falsifié, et à faible volume, il est possible d'atteindre plus de 110 requêtes par seconde sans limites visibles. Cela signifie que la barrière n'est ni cryptographique, ni réseau. C'est une taxe sur le volume : vous n'êtes pas bloqué, on vous facture simplement en requêtes.

Deuxième coup consécutif

Le changement ne doit pas être lu indépendamment du précédent. Du 12 au 14 septembre 2025, Google a désactivé le paramètre &num=100, qui renvoyait cent résultats sur une seule page. Après cela, pour la même profondeur de résultats, il fallait environ dix fois plus de requêtes.

Les conséquences se sont révélées visibles bien au-delà du parsing. Selon l'analyse de 319 propriétés, examinée par Search Engine Land, 87,7 % des sites ont perdu des impressions dans Search Console, et 77,6 % ont perdu une partie des requêtes uniques classées. Le trafic réel, cependant, n'a pas changé — la mesure s'est cassée : la majorité des « impressions » sur des positions éloignées étaient générées non par des humains, mais par des traceurs tirant des centaines de résultats.

En combinant les deux étapes : d'abord, les résultats ont augmenté de dix fois en nombre de requêtes, maintenant, chaque résultat a une requête séparée pour son adresse. La stratégie est claire — Google augmente méthodiquement le coût de production de ses propres résultats.

Le contexte juridique est également révélateur. Les mesures techniques ont été mises en œuvre exactement au moment où la voie judiciaire a échoué : la plainte de Google contre SerpApi pour DMCA a été rejetée — le tribunal a tracé la ligne entre la protection des œuvres et la régulation de l'accès aux faits publics, en indiquant que les faits et les URL ne sont pas des œuvres. Les détails de cette décision et ses conséquences ont été examinés dans un article séparé sur l'affaire Google contre SerpApi. Ne pas avoir pu interdire — a conduit à rendre cela coûteux.

Ce qui se casse dans les rapports en ce moment

La plateforme DemandSphere a énuméré les pannes spécifiques qui surviennent si rien n'est fait :

1. Le domaine de destination se réduit à google.com. Le parseur enregistre honnêtement ce qu'il voit dans le balisage — et tous les résultats deviennent « appartenant à Google ».
2. La correspondance des pages propres se casse. Le système cesse de reconnaître vos URL et pense que vous êtes sorti des résultats.
3. La part de voix et l'attribution des concurrents se dégradent — il n'y a plus rien à compter, tous les liens sont sur un seul domaine.
4. La série historique se brise exactement à la date de déploiement. C'est le plus sournois : le graphique montrera un effondrement qui n'a pas eu lieu dans la réalité.

La bonne nouvelle : les données purement positionnelles souffrent moins. DataForSEO a rapporté le 5 juillet 2026 que 99,99 % des résultats organiques via son API sont déjà renvoyés avec des adresses directes. Le problème se concentre dans les blocs de résultats — selon Growtika, les liens goto sont conservés dans environ la moitié des AI Overviews et dans un quart des blocs locaux. Cela signifie que ce qui est le plus important aujourd'hui est touché : les sources des réponses AI et les résultats locaux.

Comment réorganiser la collecte

La conclusion technique de tout ce qui précède est de diviser la collecte en deux couches avec un coût de requête différent.

1. Vérifiez d'abord si vous avez été détecté. Prenez la même série de résultats avec votre parseur et manuellement depuis un navigateur propre. Des liens directs dans le passage manuel et des goto dans l'automatique — c'est un verdict pour votre camouflage, et non une caractéristique de Google.
2. Séparez la collecte des résultats et la résolution des liens. La première couche est lourde : rendu, vraisemblance comportementale, IP de qualité. La seconde — un GET primitif pour 302, sans navigateur et sans imitation. Passer la résolution par la même pile coûteuse — c'est brûler le budget inutilement.
3. Comptez les limites, pas les gigaoctets. Le goulet d'étranglement s'est déplacé vers le nombre de requêtes. Planifiez votre pool d'adresses en fonction des RPS nécessaires, et non du volume de trafic.
4. Ne tentez pas de mettre en cache les tokens. Ils sont à usage unique. Il est logique de mettre en cache le résultat de la résolution — l'association « requête + position + domaine », et non le token lui-même.
5. Marquez la date de rupture dans les données historiques. Le 26 août 2026 doit être inscrit dans les rapports comme une étape claire, sinon le biais méthodologique sera interprété comme une chute de visibilité.
6. Vérifiez les blocs séparément. L'organique peut déjà être en ordre, tandis que les AI Overviews et le bloc local ne le sont pas. Testez-les comme des entités autonomes.

Quels proxies et où

La séparation en deux couches implique également une séparation de l'infrastructure — et cela coûte sensiblement moins cher que de faire passer tout par un seul pool.

La collecte des résultats elle-même est la partie la plus sensible. Il est important de ne pas se démarquer des utilisateurs ordinaires, et c'est cette couche qui détermine si vous verrez des liens directs ou des goto. Pour cela, on utilise des proxies résidentiels, et pour des tâches géo-dépendantes comme les résultats locaux — des mobiles, où l'IP semble absolument naturelle pour une région spécifique.

En revanche, la résolution des redirections, comme l'ont montré les mesures, ne présente pas d'exigences particulières : un GET ordinaire, aucune imitation, haute vitesse. C'est une tâche classique pour des proxies de centre de données — bon marché, rapide, avec de nombreux flux parallèles. La différence de coût entre les deux approches, avec 500 à 1000 requêtes supplémentaires par requête de résultats, devient un poste budgétaire décisif.

Conclusion

Google n'a pas fermé l'accès aux résultats — il l'a rendu plus coûteux et a également transformé le format de réponse en un indicateur de détection. Pour le marché, cela signifie la poursuite de la tendance commencée avec la désactivation de &num=100 : la collecte massive de données de recherche cesse d'être bon marché par défaut et devient une tâche d'ingénierie avec une économie claire.

En pratique, la conclusion se résume à deux points. Si vous voyez des liens goto — commencez par le camouflage, et non par le parseur : il se peut que ce ne soit pas ce que vous pensez qu'il faut réparer. Si le camouflage est en ordre, mais que des redirections existent toujours — séparez les couches de collecte et ne payez pas le prix premium pour des requêtes qui n'en ont pas besoin.