Google vient d’ajouter un découpage que beaucoup de SEO attendaient sans trop savoir sous quelle forme il arriverait : le trafic Web issu de recherches déclenchées par une image. Dans son annonce du 24 septembre 2026, Google parle de reporting « web multimodal search » dans Search Console, avec un filtre visible comme type de recherche « Web: multimodal ».

Mon avis : c’est utile, surtout pour l’e-commerce, l’affiliation produit, les recettes, les guides d’identification, les comparatifs très visuels et certains contenus locaux. Mais il faut le prendre pour ce que c’est : un nouveau segment mesurable du Search Web, pas un rapport Lens complet, pas Google Images, et pas une boîte magique qui donne les photos ou les requêtes utilisées par les internautes.

Ce qui est confirmé officiellement

Le fait principal est simple : Google a lancé, à partir du 24 septembre 2026, un reporting Search Console dédié au trafic Web provenant de recherches multimodales. Le périmètre annoncé inclut quatre modes d’entrée : Google Lens, Circle to Search sur Android, l’upload d’image dans Google Search et le clic droit Chrome « Search this image ».

Dans le rapport Performance sur les résultats de recherche, Google indique que le filtre apparaît dans les types de recherche. La documentation Search Console distingue désormais les métriques classiques du rapport Performance — clics, impressions, CTR et position moyenne — et les types de recherche, dont Web: multimodal et Web: text-based. Ce dernier correspond aux recherches textuelles tapées dans la barre de recherche Google, d’après la documentation du rapport Performance des fonctionnalités d’IA générative.

Autre point confirmé : le reporting multimodal est aussi disponible dans le rapport de performance lié aux fonctionnalités d’IA générative, qui couvre AI Overviews et AI Mode. Je le note, mais pour la plupart des audits SEO que je ferais cette semaine, je commencerais par le rapport Performance Search classique. C’est là qu’on va chercher les URL, les pays, les appareils et les dates.

Ce que ce filtre n’est pas : Google Images, des requêtes Lens ou des photos utilisateur

Le piège, c’est de transformer ça en « enfin les données Google Lens complètes ». Non. Google donne un segment de performance pour des résultats Web déclenchés par une entrée image. Le type de recherche Image reste autre chose : du trafic depuis Google Images, comme le rappelle la documentation du rapport Performance Search.

La différence est importante. Une page produit peut apparaître dans un résultat Web après une recherche Lens sans que ce clic soit du trafic Google Images. À l’inverse, une image peut générer du trafic via l’onglet Images sans être comptée comme « Web: multimodal ». Mélanger les deux fausse vite les priorités : on ne parle pas exactement des mêmes surfaces, ni du même comportement utilisateur.

Deuxième limite, et elle est grosse : la dimension requête n’est pas disponible quand le type multimodal est sélectionné. Google l’explique dans sa documentation sur les dimensions et groupements de données du rapport Performance : ces recherches utilisent surtout des images plutôt que du texte. Donc non, vous ne verrez pas les prompts Lens, ni les formulations éventuelles ajoutées par l’utilisateur.

Troisième limite : Google ne fournit pas la photo utilisée par l’internaute. John Mueller l’a résumé publiquement sur Bluesky : on voit les pages apparues et leur fréquence, pas l’image source utilisée par la personne. Je le traite comme une déclaration publique d’un Googler, pas comme une page d’aide produit ; mais elle colle à la logique du rapport. Un autre post de John Mueller indique, après vérification, que ces données n’étaient pas précédemment incluses dans les comptes du rapport. Là aussi, intéressant, mais à ne pas citer comme documentation officielle.

Pourquoi ça mérite quand même votre attention

Si vous bossez sur des produits ou des contenus visuels, ce filtre change le diagnostic. Jusqu’ici, on pouvait optimiser les images, structurer les pages, surveiller Google Images, regarder Merchant Center, puis déduire beaucoup de choses. Maintenant, on peut isoler au moins une partie des recherches Web où l’image est le point de départ.

Le contexte business explique pourquoi Google ajoute ce découpage. En mai 2025, Debbie Weinstein indiquait que Lens dépassait 25 milliards de requêtes par mois, et qu’une requête visuelle Lens sur quatre avait une intention commerciale. Attention : ce chiffre ne vient pas de Search Console et ne dit rien de votre site. Mais il explique très bien pourquoi les marchands, comparateurs, affiliés et éditeurs visuels doivent regarder ce segment.

Mon observation : la valeur est surtout au niveau page + asset visuel. Sans requête, on ne peut pas faire le vieux réflexe « keyword → landing page → optimisation sémantique ». Il faut regarder quelles URL apparaissent, sur quels pays, quels appareils, quelles périodes, avec quel CTR et quelle position moyenne. Puis croiser ça avec le template, les images disponibles, l’état du stock, le prix, les données produit et la performance de page.

API et BigQuery : ne promettez pas encore l’automatisation

Point de prudence pour les équipes data : au 25 septembre 2026, je ne vois pas de support officiellement documenté d’une valeur multimodal dans l’API Search Analytics. La page Search Analytics API, affichée comme mise à jour le 11 août 2026, liste les valeurs discover, googleNews, news, image, video et web pour le paramètre de type, mais pas de valeur multimodale distincte.

Même prudence côté export massif. La documentation BigQuery Bulk Export de Search Console liste des valeurs web, image, video, news, discover et googleNews, mais pas multimodal. La tension documentaire est claire : l’interface et l’export manuel sont disponibles, Google recommande d’ailleurs d’exporter ces données depuis Search Console pour les analyser ailleurs, mais l’API et BigQuery ne sont pas documentés comme compatibles avec ce split au moment où j’écris.

Donc, si un outil SEO vous vend déjà une automatisation propre de « Web: multimodal » via API officielle, demandez-lui exactement quelle source il utilise. Pour démarrer, je resterais sur l’interface GSC et les exports CSV ou Sheets.

Audit rapide : comment exploiter le filtre sans surinterpréter

Voici la méthode que j’utiliserais cette semaine sur un site e-commerce ou affilié.

  1. Ouvrir Search Console, aller dans Performance, puis Résultats de recherche.
  2. Dans le type de recherche, sélectionner Web: multimodal. Google précise que les métriques apparaissent si le site reçoit ce trafic via les requêtes multimodales concernées. Ne partez donc pas du principe que tous les sites verront quelque chose immédiatement.
  3. Exporter les vues Pages, Pays, Appareils et Dates.
  4. Refaire exactement les mêmes exports sur la même période avec Web: text-based.
  5. Construire une table par URL avec impressions, clics, CTR et position moyenne pour les deux segments.

Le but n’est pas de conclure trop vite que « telle page ranke mieux sur Lens ». Le but est de repérer des écarts utiles. Par exemple : une URL avec beaucoup d’impressions multimodales et un CTR faible mérite un audit visuel et snippet. Une page qui performe en text-based mais pas en multimodal peut avoir un problème d’images, de correspondance produit ou de contexte visuel. Une page qui n’a presque pas de trafic textuel mais quelques impressions multimodales peut révéler une demande visuelle difficile à verbaliser.

Les catégories à regarder en priorité : mode, déco, mobilier, pièces détachées, outillage, plantes, beauté, recettes, objets de collection, lieux, produits vus dans une vidéo ou une capture d’écran. Ce n’est pas une liste Google officielle ; c’est mon tri opérationnel, basé sur les usages où l’image remplace naturellement le mot-clé.

Quelles optimisations tester, sans vendre de causalité magique

Google n’a pas publié, en 24 heures, un test robuste montrant que telle optimisation d’image augmente mécaniquement les impressions « Web: multimodal ». Les actions ci-dessous sont donc des hypothèses de travail, appuyées sur les bonnes pratiques existantes, pas des facteurs confirmés par cette annonce.

Côté SEO image classique, Google recommande déjà des éléments img standards, des images accessibles, des sitemaps image, des images responsive, des images nettes et de qualité, un alt text utile et des données structurées pertinentes dans ses bonnes pratiques Google Images. Pour les pages produit, Merchant Center pousse aussi des images haute résolution, un image_link obligatoire, des additional_image_link, des images lifestyle quand elles sont utiles, et des informations produit complètes via ses recommandations sur les pages produit enrichies et la spécification image_link.

Je ne dirais pas que Merchant Center améliore directement les impressions organiques « Web: multimodal ». Ce n’est pas documenté dans l’annonce. En revanche, pour un marchand, c’est logique de croiser le reporting GSC avec la qualité des images produit, les vues additionnelles, la marque, le GTIN, la couleur, la matière, le stock et le prix. Pas pour prouver un facteur, mais pour prioriser les pages où l’expérience visuelle et l’information produit sont faibles.

Mon protocole de test sur 28 à 56 jours

Je mettrais en place un test simple, imparfait mais exploitable.

  1. Sélectionner deux groupes comparables de pages : même template, même famille produit ou éditoriale, volumes proches, pas de gros changement prévu sur prix, stock ou promo.
  2. Sur le groupe test, améliorer les assets : image principale nette, haute résolution, vues additionnelles utiles, contexte d’usage si pertinent, alt text factuel, données structurées cohérentes, sitemap image, images servies dans du HTML standard.
  3. Sur les pages produit, vérifier le flux Merchant Center : image_link, images additionnelles, attributs produit structurants.
  4. Ne pas toucher au groupe contrôle pendant la période, sauf correctif obligatoire.
  5. Mesurer pendant 28 à 56 jours les impressions, clics, CTR et position moyenne en Web: multimodal, puis comparer au segment Web: text-based sur les mêmes URL.
  6. Annoter les dates dans vos dashboards, surtout parce que ce nouveau découpage arrive en même temps que d’autres variations de Search. Ne mélangez pas apparition du reporting et changement réel de ranking.

Le tableau minimum que je veux voir : URL, template, impressions multimodales, clics multimodaux, CTR multimodal, position multimodale, métriques text-based équivalentes, nombre d’images indexables, présence des images additionnelles, état du feed, stock, prix, LCP et marge ou commission. Ensuite seulement, je priorise.

Actions concrètes à lancer maintenant : vérifier si le filtre apparaît sur vos propriétés, exporter Pages/Pays/Appareils/Dates en Web: multimodal, refaire l’export en Web: text-based, isoler les URL avec impressions multimodales et CTR faible, choisir un lot test et un lot contrôle, puis annoter le 24 septembre 2026 dans vos rapports. Et si vous avez un pipeline API ou BigQuery, ne le modifiez pas à l’aveugle : surveillez d’abord la documentation officielle avant de promettre un reporting automatisé propre.