D'où proviennent les résultats d'AOL Search, effet de l'IP de sortie sur l'interface et le classement, comportement des opérateurs et mise en place d'une mesure conforme.

robots.txt, conditions d'utilisation et limites de la vérification à échelle humaine.

Pour comprendre le rapport entre AOL Search et les proxys, il faut d'abord clarifier une distinction : le domaine qui répond à la requête et l'index qui produit les liens organiques ne se situent pas au même endroit. Vous dialoguez avec l'interface AOL, tandis que la liste est alimentée par l'index web d'un partenaire. Lorsque vous changez d'IP de sortie, ces deux couches ne réagissent ni en même temps ni dans la même mesure.

C'est pourquoi la phrase « j'ai activé un proxy, les résultats ont changé » ne dit rien à elle seule. Une comparaison faite sans distinguer si ce qui a changé relève de l'interface, de l'inventaire publicitaire ou du classement organique est trompeuse.

Les sections suivantes traitent de la mise en place de cette distinction, du choix du type de sortie selon l'ampleur du travail, et de la conduite de la mesure à une cadence qui n'entre pas en conflit avec les conditions d'utilisation de la plateforme.

Que produit AOL Search lui-même, et que récupère-t-il de son partenaire ?

Sur le plan de la mesure, cela a deux conséquences. Premièrement, le classement que vous voyez sur AOL est la version du classement produit par le moteur source pour cette langue et ce pays, replacée dans la mise en page du portail. Deuxièmement, la couche portail y insère ses propres espaces publicitaires, ses raccourcis d'actualité et ses blocs promotionnels. Voir le même lien dans un ordre différent sur deux interfaces ne prouve pas que les index diffèrent ; il y a entre les deux une couche de mise en page.

N'oubliez pas que le domaine AOL possède aussi des surfaces en dehors de la recherche : le fil d'actualité, l'accès à la messagerie et les contenus du portail ne proviennent pas de l'index de recherche, mais du système de publication du site lui-même. Dans une comparaison réalisée via un proxy, le fait que ces blocs varient selon le pays ne signifie pas que les résultats de recherche ont eux aussi changé. Évaluer les deux surfaces sur une même capture d'écran est une erreur de relevé difficile à corriger par la suite.

La façon concrète de vérifier la dépendance à la source est le test apparié : exécutez la même requête depuis la même sortie à la fois sur AOL et sur le moteur auquel vous voulez le comparer, puis notez les dix premiers liens côte à côte. Si le taux de recoupement est élevé, la différence tient à la mise en page ; s'il est faible, vous regardez réellement une source différente. Établir la comparaison avec un moteur exploitant son propre couple crawler-index donne le résultat le plus instructif ; la page proxy Google explique pas à pas comment mettre en place le même dispositif de mesure sur un index indépendant. Quant au comportement des autres surfaces de portail et de moteur comme Yahoo et Bing, vous pouvez le suivre depuis la liste des guides associés en bas de page.

Où l'IP de sortie touche-t-elle la surface des résultats ?

Les interfaces de recherche estiment d'abord la région du visiteur à partir de l'adresse IP. Cette estimation détermine la langue de l'interface, les onglets régionaux, le format monétaire et l'inventaire publicitaire. Le classement organique en est également affecté pour les requêtes à dimension locale : une expression comme « suivi de colis » porte une intention différente dans chaque pays. Mais l'ampleur de cet effet varie selon les couches, et cette différence vous est utile au moment de concevoir la mesure.

L'écart entre villes d'un même pays reste faible pour la plupart des requêtes ; le changement de pays, lui, est marqué. Si vous avez besoin d'une vue au niveau de la ville, vous ne pouvez la tester qu'avec des pools permettant un ciblage par ville ; ciblage par ville et par ISP l'article explique comment le pool est restreint et dans quels cas le niveau pays ne suffit pas. Déterminez le pays de sortie en fonction des marchés couverts par votre plan de mesure : si vous vérifiez la vue américaine, une sortie aux États-Unis, et pour la vue turque, une sortie en Turquie constituent des points de départ classiques — et ne mélangez pas deux marchés dans un même tour de mesure.

Le deuxième facteur déterminant est l'endroit où le nom de domaine est résolu. Avec un proxy HTTP, le client annonce la cible sous la forme CONNECT arama.example:443 et c'est le proxy qui effectue la résolution. En SOCKS5, le comportement dépend du client : certains clients résolvent l'adresse sur leur propre réseau et ne transmettent qu'une IP au proxy. Si la résolution est faite de votre côté, un endpoint proche de vous peut être renvoyé alors que la connexion est établie depuis le pays du proxy ; il en résulte un tableau confus (où le DNS est-il résolu en SOCKS5).

Quel type de sortie suffit pour le dispositif de test ?

La page de résultats de recherche est une surface qui n'exige pas de connexion et qui porte majoritairement du texte. La décision sur le type de sortie se prend donc plus librement que pour des comptes de réseaux sociaux : ce qui compte n'est pas la session, mais la classe de réseau d'où provient la requête. Pour des vérifications à faible volume et à échelle humaine, les sorties datacenter font le plus souvent l'affaire.

À mesure que l'ampleur du travail grandit, ou si ce qui doit être vérifié est une surface régionale, la décision change. Lorsqu'une vue proche d'un profil d'abonné résidentiel est nécessaire, le proxy residential convient ; lorsqu'il faut une adresse fixe et un débit stable, c'est le proxy ISP. La vraie différence entre les deux tient à la classe de réseau dans laquelle l'adresse apparaît enregistrée. Le proxy mobile est généralement un outil trop coûteux pour mesurer l'interface de recherche desktop ; ne l'utilisez pas si vous ne testez pas spécifiquement la mise en page des résultats mobiles.

En matière de rotation, une seule règle vous simplifie la tâche : si vous faites une comparaison, l'adresse doit rester fixe. Avec une configuration qui change d'adresse à chaque requête, vous ne pouvez pas dire si l'écart entre deux mesures vient de la sortie ou de la requête. Les pools rotating sont conçus pour répartir la charge et étaler les requêtes sur une large base d'adresses, non pour une comparaison contrôlée ; l'article différence entre proxy rotating et statique compare, exemples à l'appui, quel outil convient à quel travail.

Configuration et vérification immédiatement après la configuration

Décision de protocole

Dans les tests de recherche basés sur le navigateur, le proxy HTTP comme SOCKS5 fonctionnent. Le proxy HTTP se situe à la couche applicative ; il peut voir les requêtes HTTP en clair et ouvre un tunnel pour le HTTPS. SOCKS5 se place à la couche transport et n'interprète pas le protocole qu'il transporte. La différence devient manifeste dès que vous sortez du navigateur : les outils en ligne de commande et les clients que vous écrivez vous-même ne prennent pas en charge les deux formats avec la même maturité ; prenez donc votre décision de protocole en consultant le tableau de compatibilité de votre outil. CONNECT Où la définir ?

Définissez le réglage de mesure non pas à l'échelle du système, mais sur un profil de navigateur distinct ; la justification et le détail de l'hygiène de profil se trouvent

dans la section session de la page Ask.com . Côté AOL, ce choix a une raison supplémentaire qui lui est propre : le domaine du portail héberge, au-delà de la recherche, l'accès à la messagerie et des surfaces de portail personnalisées. Si une session de portail est ouverte dans le profil que vous utilisez au quotidien, la page de recherche s'ouvre elle aussi dans le contexte de cette session, et ce que vous mesurez n'est plus la surface vue par un visiteur anonyme. Firefox conserve la définition du proxy dans ses propres paramètres de connexion, tandis que Chrome utilise celle du système d'exploitation ; côté Windows, un réglage effectué au niveau système affecte toutes les applications. Le format des informations de connexion est proxy.example.com username / 8080 / password / ; les valeurs réelles se trouvent dans votre panneau. N'utilisez le profil de test que pour la mesure, n'ouvrez aucun autre onglet.

• Lorsque vous changez de pays, changez aussi de profil ; les anciennes préférences ne doivent pas être reportées sur le nouveau tour.
• Notez l'adresse de sortie avant et après la mesure.
• Enregistrez les résultats sous forme de liste de liens, non de capture d'écran.
• Une fois la configuration terminée, vérifiez trois choses : votre adresse de sortie est-elle dans le pays attendu, la résolution de nom de domaine fuit-elle, et le navigateur révèle-t-il votre adresse réelle via WebRTC. Dans cet ordre,

les outils répondent à ces trois questions en quelques minutes. Si vous vous demandez quels en-têtes le proxy transmet à la cible, le test d'anonymat fait naturellement partie du même jeu de contrôles. mon adresse IP, Test de DNS leak et test de fuite WebRTC Une lacune de périmètre est une erreur silencieuse, mais sa cause n'est pas l'IPv6 : c'est l'endroit où le proxy a été défini. Un proxy explicitement défini dans le profil du navigateur n'est pas contourné, même si la cible possède une adresse IPv6. Ce qui est risqué, ce sont les définitions faites au niveau système ou PAC et les listes de contournement — les applications qui ignorent le proxy envoient le trafic en direct. Le vrai problème côté IPv6 est distinct : si votre client SOCKS5 résout le nom sur son propre réseau et transmet une adresse AAAA à une sortie IPv4-only, la connexion ne peut pas être établie et vous obtenez une erreur explicite, non un contournement silencieux. Dans ce cas, activez la résolution DNS distante dans le client, ou bien