Kagi Proxy : préférences du compte, pays de sortie et mesure reproductible

Ce qui rend Kagi intéressant du point de vue du proxy, c'est qu'il ne s'utilise pas sans session. Le compte d'abonnement détermine à qui appartient la requête, et cette identité est indépendante de l'adresse de sortie. Lorsque vous activez un proxy, c'est le réseau d'où part la requête qui change ; l'identité de votre compte, elle, ne change pas. Sans poser cette distinction dès le départ, vous attribuerez chaque écart à la mauvaise cause.

Deuxième point : le moteur ne produit pas sa surface de résultats à partir d'une source unique. Kagi explique dans sa propre documentation qu'il combine ses index maison avec des sources de recherche externes ; s'y ajoutent les préférences de domaines de votre compte et les filtres que vous avez activés. L'adresse de sortie n'est qu'une de ces entrées.

Troisièmement, un avertissement pratique : ce qui est décrit ici sert à vérifier comment la surface de résultats publique du moteur apparaît depuis différents pays. Le respect des conditions d'abonnement et des conditions de service relève de la responsabilité de l'utilisateur.

L'identité tient au compte, la localisation au réseau

Lorsque vous envoyez une requête à Kagi, deux informations distinctes existent côté serveur. La première est votre session : le cookie ou le jeton porté par votre navigateur indique à quel abonnement appartient la requête. La seconde est l'adresse IP de sortie d'où provient la connexion. Le proxy n'agit que sur la seconde. En passant sur une sortie à Francfort, votre compte ne devient pas francfortois : c'est votre requête qui part de là.

Pour qui effectue des mesures, cette distinction est en réalité un avantage. Lorsque vous lancez la même requête depuis deux pays avec le même compte, tout ce qui dépend du compte — préférences, réglage de langue, formule — reste constant ; la seule entrée qui change est le réseau. C'est exactement ce que l'on veut pour une comparaison contrôlée. Vérifiez que votre sortie a réellement changé à l'aide de mon adresse IP ; si le pays affiché par l'outil ne correspond pas à celui sélectionné dans votre panneau, ne commencez pas la mesure.

L'inverse est vrai aussi. Si vous modifiez un réglage du compte puis changez également de sortie, vous attribuerez l'écart obtenu au réseau alors qu'il peut venir des préférences. La règle est simple : ne faites varier qu'une seule variable par exécution et laissez tout le reste en l'état.

Le système autonome auquel appartient la sortie est lui aussi une entrée. Les blocs de datacenter et les blocs d'abonnés résidentiels relèvent d'ASN différents, et cette classification peut influencer la manière dont le moteur traite la requête (ASN et réputation d'IP). Si vous souhaitez comparer le comportement d'autres moteurs de recherche, les guides des moteurs de recherche appliquent la même méthode à d'autres surfaces.

Que faut-il figer dans une série de suivi ?

Le suivi SERP n'est pas un coup d'œil ponctuel : c'est l'exécution régulière du même jeu de requêtes dans les mêmes conditions. La valeur de la série vient de sa comparabilité ; si les conditions ont bougé entre-temps, il ne vous reste qu'un mélange de deux expériences différentes. La première tâche consiste donc à écrire quelles variables seront considérées comme figées.

En pratique, une exécution se réduit en trois étapes. Une partie des requêtes prévues n'aboutit jamais, en raison d'un dépassement de délai, d'un quota atteint ou d'une connexion interrompue. Une partie de celles qui aboutissent n'entre pas dans la série parce que les conditions n'ont pas été respectées : la sortie a changé en cours de route, le réglage de langue diffère, la page ne s'est chargée qu'à moitié. Ce qui reste constitue votre mesure réelle. Ignorer ce taux d'élimination est la cause la plus fréquente des sauts inexpliqués dans une série.

Il ne suffit pas de remplir ce tableau une fois et de le mettre de côté ; joignez ces mêmes champs à la sortie de chaque exécution. Six semaines plus tard, lorsque vous verrez un saut sur un graphique, le premier endroit à consulter ne sera pas le moteur mais l'étiquette de sortie de ce jour-là. Les équipes qui ne tiennent pas de relevé en sont réduites à des conjectures.

Comment les préférences de classement du compte faussent-elles la mesure ?

L'une des caractéristiques distinctives de Kagi est de permettre à l'utilisateur d'intervenir sur les résultats : vous pouvez remonter un domaine, le rétrograder, l'épingler ou l'exclure entièrement de la liste. Avec des filtres et des lenses, vous pouvez aussi enfermer l'ensemble des résultats dans un périmètre étroit. Au quotidien, c'est une fonctionnalité puissante ; en situation de mesure, c'est une source de biais permanente.

Le problème est que ces préférences vivent dans le compte. Même si vous changez de sortie, réinitialisez le navigateur ou passez sur une autre machine, elles reviennent dès que vous vous connectez avec le même compte. Un domaine que vous aviez rétrogradé il y a six mois par agacement est toujours plus bas dans la mesure d'aujourd'hui, et vous prendrez cela pour un écart régional.

La solution consiste à maintenir un profil de mesure distinct. N'utilisez pas pour la mesure le compte dont vous vous servez au quotidien ; laissez les préférences neutres sur le compte de mesure et consignez cette décision par écrit. Si vous devez modifier une préférence, notez le changement avec sa date, car les mesures antérieures et postérieures à cette date ne comptent plus dans la même série.

Distinguer les entrées qui alimentent la surface de résultats

Penser une page de résultats comme une boîte unique fausse aussi les attentes placées dans le proxy. Côté Kagi, au moins cinq entrées agissent simultanément : l'index exploré par le moteur lui-même, les sources de recherche externes, les préférences de domaines de votre compte, la lens ou le filtre actif et le réseau depuis lequel la requête part. Le proxy ne modifie que la dernière.

Le moyen le plus rapide de le comprendre est de mener un test à variable unique. Lancez, au même moment, avec le même compte, la même requête depuis deux sorties différentes et placez les deux résultats côte à côte. La partie commune vient très probablement de l'index et des préférences ; la partie qui change est celle qui est sensible au réseau. Une fois cette distinction faite, vous saurez également quelles requêtes sont sensibles à la région.

Une partie des résultats ne change sur aucune sortie. Pour une recherche de définition technique, une documentation de bibliothèque ou un relevé historique, le poids du signal de pays est faible. Les requêtes sensibles à la région sont généralement celles qui portent sur des services locaux, l'actualité, la réglementation ou une intention commerciale. Il est plus efficace de consacrer votre budget de mesure à ce second ensemble.

Pour décider du pays d'où partira la sortie, appuyez-vous sur votre audience cible : la sortie doit se trouver là où se trouve l'utilisateur que vous voulez mesurer. Vous pouvez consulter les options la liste des localisations . Le cadre général côté visibilité dans les moteurs de recherche est, lui, rassemblé sur la page proxy pour outils SEO .