Quand votre prospect prend enfin contact avec un commercial, l’essentiel est déjà joué. Les acheteurs B2B réalisent en moyenne près de 70 % de leur parcours d’achat avant tout échange avec un vendeur, et dans 80 % des cas, c’est l’acheteur qui déclenche ce premier contact (6sense, 2024 Buyer Experience Report). Autrement dit : le terrain où se gagne ou se perd l’affaire, c’est la recherche en ligne. Et ce terrain, votre concurrent l’occupe peut-être déjà. Le SEO B2B n’est pas une version « sérieuse » du SEO grand public. C’est une discipline à part, avec ses propres règles. Faible volume, forte intention. Cycle long. Plusieurs décideurs sur un même achat. Un mot-clé qui ne ramène que dix visites par mois peut valoir bien plus qu’un autre qui en ramène mille. La logique du volume brut, ici, vous trompe. L’enjeu n’est donc pas d’attirer du trafic. C’est de capter la bonne intention, au bon moment, et de la transformer en lead qualifié que le commercial pourra closer. Plus de datas, moins de blabla. Pourquoi le SEO B2B ne se pilote pas comme le SEO B2C En B2C, on achète une paire de chaussures en cinq minutes, seul, sur un coup de tête. En B2B, on sélectionne un logiciel à 40 000 euros par an, à plusieurs, sur trois mois, avec une procédure d’achat et un budget à justifier. Tout change : le rythme, les acteurs, la nature des requêtes, la façon de mesurer. Une stratégie de référencement naturel calquée sur les réflexes B2C produit du trafic flatteur et zéro pipeline. La différence n’est pas cosmétique. Elle impose une mécanique entièrement orientée vers la génération de leads et non vers l’audience. Cycle de vente long, comité d’achat multiple : ce qui change tout Un achat B2B n’est presque jamais une décision individuelle. Un comité d’achat compte en moyenne 6 à 11 décideurs, chacun menant sa propre recherche en parallèle (Gartner, parcours d’achat B2B). Le directeur financier cherche le ROI. L’utilisateur final cherche la facilité de prise en main. Le responsable technique cherche l’intégration et la sécurité. Le sponsor cherche un argument pour convaincre sa direction. Résultat : un même achat génère une dizaine d’intentions de recherche différentes, parfois contradictoires. Votre site doit répondre à chacune, sous peine de sortir du radar d’un des décideurs et de voir le deal capoter sur un maillon. A cela s’ajoute le temps. Le cycle de vente B2B se compte en semaines ou en mois (de l’ordre de 80 à 90 jours en médiane), pas en clics. Un prospect peut lire un de vos articles en janvier, revenir sur une page produit en mars, et ne demander un devis qu’en avril. Le SEO doit nourrir cette maturation lente, pas espérer une conversion immédiate. Faible volume, forte intention : la règle inversée du mot-clé B2B En B2C, plus un mot-clé est recherché, plus il intéresse. En B2B, la règle s’inverse souvent. Les requêtes à fort volume sont génériques, attirent des curieux, des étudiants, des concurrents. Les requêtes à faible volume mais forte intention attirent des acheteurs. Un mot-clé comme « logiciel de gestion de maintenance GMAO pour industrie agroalimentaire » ne génère peut-être que trente recherches mensuelles. Mais celui qui le tape sait exactement ce qu’il veut, dispose probablement d’un budget, et se situe en phase d’évaluation. Les benchmarks SEO B2B le confirment : ces mots-clés à faible volume mais forte intention génèrent un trafic de bien meilleure qualité, et le cycle long justifie pleinement d’investir dessus (First Page Sage et Stratabeat, 2025). Le scoring d’un mot-clé B2B ne se fait donc pas sur le volume. Il se fait sur la valeur potentielle du compte qui se cache derrière la requête. Trente visites de directeurs achats valent mieux que mille visites de stagiaires. 70 % du parcours d’achat se joue avant le premier contact commercial C’est le chiffre qui devrait réorienter tout votre budget. Les acheteurs B2B ne passent qu’environ 17 % de leur temps d’achat en contact direct avec les fournisseurs, le reste étant de la recherche autonome répartie sur plusieurs sources (Gartner, 2024). Quand on divise ce temps de contact entre les trois ou quatre fournisseurs en lice, chaque vendeur ne dispose plus que de 5 ou 6 % du processus pour convaincre. Pendant les 95 % restants, votre prospect lit, compare, évalue, en autonomie. S’il ne vous trouve pas à ce moment-là, vous n’existez pas dans la short-list finale. Et selon le rapport de Demand Gen Report relayant l’étude 6sense, c’est bien l’acheteur qui mène la danse jusqu’à ce qu’il décide de vous solliciter. Le SEO est le seul levier capable d’être présent pendant cette phase invisible mais décisive. Cartographier l’intention de recherche par étape du tunnel Couvrir le SEO B2B, c’est couvrir un tunnel entier, pas une seule page. Chaque étape correspond à un état d’esprit différent de l’acheteur, donc à un type de requête et un type de contenu. On parle classiquement de TOFU (haut de tunnel), MOFU (milieu) et BOFU (bas de tunnel). Le piège classique : produire uniquement du contenu de notoriété, faute de penser conversion. Ou l’inverse, ne miser que sur les pages produit en ignorant la phase de découverte. Les deux laissent des leads sur la table. Requêtes informationnelles (TOFU) : capter sans espérer convertir tout de suite En haut de tunnel, l’acheteur ne connaît pas encore sa solution. Il connaît son problème. Il cherche « comment réduire les arrêts machine en production », pas votre nom de marque. Et il est nombreux à faire ce premier pas : 71 % des recherches B2B démarrent par une requête générique, non liée à une marque (RevenueZen, 2025). Le contenu TOFU répond à ces questions sans forcer la vente. Guides, définitions, articles de fond, comparatifs de méthodes. L’objectif n’est pas le devis immédiat. C’est d’entrer dans le radar de l’acheteur dès le début de sa réflexion, et d’installer la crédibilité. Celui qui résout votre problème gratuitement aujourd’hui sera consulté quand viendra l’achat. Erreur à éviter : juger ces contenus à l’aune des conversions directes. Ils convertissent peu, c’est normal. Leur rôle est d’alimenter le haut du tunnel pour que le MOFU et le BOFU aient de la matière. Requêtes commerciales et transactionnelles (MOFU/BOFU) : le coeur du lead C’est ici que se fabrique le pipeline. En milieu et bas de tunnel, l’acheteur a identifié sa catégorie de solution et compare les fournisseurs. Ses requêtes deviennent explicites : « meilleur logiciel GMAO », « alternative à [concurrent] », « prix solution X », « X vs Y », « logiciel GMAO avis ». Ces requêtes ont un volume ridicule comparé au TOFU. Elles ont aussi un taux de transformation sans commune mesure. La recherche organique affiche le meilleur taux de conversion trafic-vers-lead, tous canaux confondus, à 4,1 %, devant le trafic direct (3,7 %) et le SEM/PPC (2,7 %), selon First Page Sage. Et un lead organique se transforme en client dans 14,6 % des cas, contre 1,7 % pour un lead outbound issu de salons, cold call ou emailing non sollicité (First Page Sage, 2025). Ces chiffres dictent la priorité : les pages MOFU et BOFU ne sont pas un complément éditorial, ce sont vos actifs de génération de leads les plus rentables. On les traite comme tels. Aligner chaque requête sur un décideur du comité d’achat C’est le gap que la plupart des stratégies SEO B2B ignorent. Puisqu’un achat mobilise 6 à 11 décideurs aux préoccupations distinctes, chaque requête devrait être rattachée à un membre précis du comité. Concrètement, on construit une matrice : Le décideur économique (DAF, direction) cherche le ROI, le coût total de possession, les garanties contractuelles. On lui adresse des calculateurs ROI et des cas clients chiffrés. L’utilisateur final cherche la facilité d’usage, les fonctionnalités, les tutoriels. On lui adresse des démonstrations et des comparatifs de fonctionnalités. Le responsable technique ou intégrateur cherche les spécifications, la sécurité, les API, la compatibilité. On lui adresse de la documentation et des pages techniques. Le sponsor interne cherche des arguments pour convaincre sa hiérarchie. On lui adresse des études sectorielles et des chiffres de marché. Cette cartographie requête/décideur transforme le SEO d’un exercice de visibilité en un dispositif de couverture de comité. Si une seule de ces personnes ne trouve pas la réponse à sa question chez vous, elle devient le point de friction qui fait basculer le choix vers un concurrent. Produire les contenus de conversion qui transforment le trafic en lead Le trafic ne paie pas les factures. Le lead, oui. La différence entre les deux tient à un ensemble de contenus pensés pour déclencher une action, pas pour remplir un calendrier éditorial. C’est précisément la faiblesse de la plupart des sites B2B : ils publient des articles de fond à la chaîne et oublient les pages qui convertissent. La science du clic ne vaut rien sans l’art de la conversion. Pages de comparaison, cas clients chiffrés, calculateurs ROI Trois formats portent l’essentiel de la conversion BOFU. Ils méritent un investissement disproportionné par rapport à leur nombre. La page de comparaison (« X vs Y », « alternatives à Z ») capte un acheteur en phase de choix final. Elle doit être honnête, factuelle, et assumer vos points forts sans dénigrer. C’est souvent la dernière page lue avant la demande de devis. Le cas client chiffré est l’actif le plus sous-exploité du B2B. Pas un témoignage vague, mais des résultats : « moins 32 % d’arrêts machine en huit mois », « ROI atteint en quatorze mois ». La preuve concrète neutralise le risque perçu, qui est le principal frein à l’achat B2B. Chaque donnée devient une histoire qui rassure le comité. Le calculateur ROI transforme une page passive en outil. Le visiteur saisit ses paramètres, obtient une estimation de gain, et vous laisse souvent ses coordonnées pour recevoir le détail. C’est un aimant à leads qualifiés, et un argument tout prêt pour le décideur économique. Formulaires courts, contenus premium et soft conversions Tout le monde n’est pas prêt à demander un devis. Imposer la conversion forte unique (le bouton « contactez-nous ») revient à perdre 95 % des visiteurs qui ne sont pas encore mûrs. La parade : étager les niveaux d’engagement. On parle de soft conversions. Livre blanc ou étude sectorielle en échange d’un email : engagement faible, idéal pour le MOFU. Webinaire ou démonstration : engagement moyen, signal d’intérêt réel. Devis ou audit gratuit : engagement fort, lead chaud. Règle d’or sur les formulaires : plus c’est court, mieux c’est. Chaque champ supplémentaire fait chuter le taux de complétion. En haut de tunnel, un email suffit. On enrichit la fiche au fil de la relation, pas d’un coup. Le scoring se charge ensuite de distinguer le simple curieux du compte à fort potentiel. Structurer le maillage et les balises pour guider vers la conversion Un site B2B bien structuré conduit le visiteur, étape par étape, du contenu de découverte vers la page de conversion. Le maillage interne n’est pas qu’un signal SEO, c’est un parcours. Concrètement : chaque article TOFU pointe vers le contenu MOFU correspondant, qui pointe lui-même vers la page produit et la page de devis. On évite les culs-de-sac. On évite aussi de noyer le lecteur sous quarante liens : trois ou quatre liens pertinents et orientés conversion valent mieux qu’une nuée dispersée. Côté balisage, la hiérarchie compte autant pour les moteurs que pour l’humain. Bien structurer vos balises Hn aide Google à comprendre la logique de la page et guide le lecteur vers le call-to-action. Un titre clair, des intertitres qui répondent à une intention précise, des appels à l’action visibles : la structure travaille pour la conversion, pas seulement pour le ranking. Mesurer le ROI du SEO B2B sur un cycle de vente long C’est le point où la plupart des stratégies s’effondrent. On sait produire du contenu. On ne sait pas prouver qu’il rapporte. Sur un cycle long, le lien entre un article publié en mars et un contrat signé en décembre est tenu pour invisible. Il ne l’est pas. Il faut juste le bon dispositif de mesure. Abandonner le trafic brut, suivre MQL, SQL et opportunités Le nombre de visiteurs est une métrique de vanité en B2B. Elle monte, elle rassure, elle ne dit rien du chiffre d’affaires. Les KPI qui comptent sont ceux du pipeline : MQL (Marketing Qualified Lead) : le contact a montré un intérêt suffisant (téléchargement, formulaire, plusieurs visites) pour être suivi. SQL (Sales Qualified Lead) : le commercial a validé qu’il correspond à la cible et au moment d’achat. Opportunité : un deal identifié, chiffré, en cours de négociation. Revenu : le contrat signé, attribué à sa source. Suivre cette chaîne, et non le trafic, recentre tout le SEO sur sa finalité réelle. Une page qui génère peu de visites mais beaucoup de SQL vaut dix pages à fort trafic sans pipeline. C’est la différence entre un site qui fait du bruit et un site qui fait du business. Connecter le SEO au CRM pour attribuer le revenu au canal Sans cette connexion, la mesure reste théorique. Avec elle, le SEO devient un centre de profit pilotable. Le principe : tracer le canal d’origine du lead dès la première conversion (champ source dans le formulaire, paramètres UTM, suivi multi-touch), et remonter cette information dans le CRM. Quand le deal se signe neuf mois plus tard, le revenu reste rattaché au canal organique qui l’a initié. Cela suppose une rigueur que peu d’entreprises mettent en place : un champ « source de lead » obligatoire, un modèle d’attribution défini (premier contact, dernier contact ou multi-touch), et une discipline commerciale pour ne pas écraser l’information à la requalification. C’est exigeant. C’est aussi la seule façon de répondre à la question « combien rapporte le SEO » avec un chiffre, pas une intuition. La donnée, ici, fait toute la différence entre un budget défendable et un budget coupé au premier arbitrage. Les délais réels : 3 à 6 mois pour le ranking, 9 à 12 mois pour le pipeline Soyons clairs sur le calendrier, parce que personne ne l’est. Le SEO B2B montre des gains de positionnement sous 3 à 6 mois. Mais l’attribution complète au pipeline prend généralement 9 à 12 mois, parce que le délai SEO s’ajoute au cycle de vente long (Onely et LATT SEO, 2025). La séquence réelle : trois à six mois pour ranker, puis le temps que le trafic se constitue, puis le cycle de vente de 80 à 90 jours qui s’enclenche sur chaque lead. Additionnez. Un investissement SEO démarré en janvier produit ses premiers contrats attribuables à l’automne, voire l’hiver suivant. Cette réalité doit être posée dès le départ, surtout auprès de la direction. Couper le budget au bout de quatre mois parce que « ça ne rapporte pas encore », c’est jeter l’investissement juste avant qu’il ne porte. La recherche organique génère pourtant une part majeure des leads inbound B2B, estimée autour de 53 % (RevenueZen, 2025). On ne vise pas la lune pour atterrir le mois suivant. Construire l’autorité du domaine sur un marché de niche Sur une requête B2B ultra-ciblée, vous n’affrontez pas mille sites. Vous en affrontez cinq ou six, tous spécialistes. Gagner ne se joue pas au volume de contenu, mais à la crédibilité perçue par Google et par l’acheteur. L’autorité devient l’arbitre. Netlinking sectoriel et donnée propriétaire Oubliez les annuaires généralistes et les liens achetés en masse. Sur un marché de niche, un lien depuis un média spécialisé de votre secteur, une fédération professionnelle ou un partenaire reconnu pèse plus que cent liens génériques. Le meilleur aimant à liens, en B2B, c’est la donnée propriétaire. Une étude sectorielle annuelle, un benchmark chiffré, un baromètre original : ce sont des actifs que les autres acteurs citeront naturellement, parce qu’ils n’existent nulle part ailleurs. Vous publiez la référence, les autres la relaient, vos liens et votre autorité se construisent. La donnée qui fait parler les chiffres devient votre meilleur commercial. Schema markup et E-E-A-T pour les requêtes ultra-ciblées Sur les requêtes de niche, deux leviers techniques font la différence. Le premier : les données structurées. Implémenter le schema markup, un allié pour les sites B2B, aide les moteurs à comprendre la nature de vos contenus (FAQ, produit, avis, organisation) et à vous afficher avec des résultats enrichis qui captent le clic. Le second : l’E-E-A-T (Experience, Expertise, Autorité, Fiabilité). Google value les signaux de crédibilité, particulièrement sur les sujets à enjeu. En B2B, cela passe par des auteurs identifiés et qualifiés, des pages « à propos » solides, des études de cas vérifiables, des sources citées. Un acheteur qui engage 40 000 euros ne fait pas confiance à un contenu anonyme. Google non plus. Les robots vous trouvent, les prospects vous choisissent : les deux exigent la même preuve d’expertise. Par où démarrer une stratégie SEO B2B orientée leads Pas besoin de tout faire d’un coup. La séquence qui fonctionne tient en cinq mouvements. Cartographiez votre comité d’achat. Listez les 6 à 11 décideurs types de vos deals et les questions que chacun se pose. C’est la base de toute la stratégie de contenu. Identifiez les requêtes à forte intention, pas à fort volume. Scorez-les sur la valeur du compte potentiel, BOFU et MOFU en priorité. Produisez d’abord les contenus de conversion (pages de comparaison, cas clients chiffrés, calculateur ROI), puis le TOFU qui alimente le tunnel. Connectez le SEO au CRM dès le premier jour, avec un champ source obligatoire et un modèle d’attribution. La mesure se prépare avant les premiers leads, pas après. Fixez le bon horizon : 3 à 6 mois pour le ranking, 9 à 12 mois pour le pipeline. Tenez le cap. Le SEO B2B n’est pas un sprint de trafic. C’est un investissement qui transforme chaque clic en opportunité et chaque donnée en histoire de pipeline. Racines solides, ambitions élevées : une fondation patiente qui finit par dominer sa niche pendant que les autres rachètent leurs leads au prix fort. Vous voulez bâtir une stratégie SEO B2B qui se mesure en contrats signés, pas en visites ? Parlons-en avec les équipes Brioude

L’article SEO B2B : la strategie orientee leads qui convertit est apparu en premier sur Brioude.

Le consultant SEO Daniel Roch a relayé cette mise à jour sur LinkedIn, en rappelant qu'elle vient confirmer les résultats d'un test qu'il avait mené sur le sujet, ainsi que les réserves qu'il exprimait depuis plusieurs mois sur le fichier llms.txt.

Que dit exactement la documentation de Google

Dans la section consacrée aux idées reçues sur l'optimisation pour l'IA générative, Google liste plusieurs pratiques que les éditeurs de sites peuvent ignorer sans crainte pour leur visibilité. La première concerne directement le sujet : les fichiers llms.txt et les autres formats spéciaux. Google précise qu'il n'est pas nécessaire de créer de nouveaux fichiers lisibles par machine, de fichiers texte pour IA, de balisages ou de contenu en Markdown pour apparaître dans Google Search, y compris dans ses fonctionnalités d'IA générative comme les AI Overviews ou l'AI Mode, car Google Search lui-même ne les utilise pas.

La firme de Mountain View ajoute une précision importante : le moteur peut tout à fait découvrir, explorer et indexer toutes sortes de fichiers en plus du HTML sur un site. Mais cela ne signifie pas que ces fichiers bénéficient d'un traitement particulier. Autrement dit, qu'un fichier llms.txt existe sur un site ou non ne change rien à la façon dont Google traite ce site.

Google va même plus loin en précisant que créer et maintenir ce type de fichier reste tout à fait possible, notamment pour d'autres services ou systèmes qui s'appuient sur ce format. Cela ne nuira ni n'aidera la visibilité ou le positionnement dans Google Search, puisque Google l'ignore tout simplement.

Pourquoi ce sujet fait débat depuis plusieurs mois

Le fichier llms.txt a été proposé comme une sorte d'équivalent au robots.txt, mais destiné aux modèles de langage plutôt qu'aux robots d'indexation classiques. L'idée consistait à fournir aux IA un résumé structuré du contenu d'un site, dans un format simplifié et lisible par les machines, pour faciliter la citation ou la compréhension du site par les outils d'intelligence artificielle.

Ce format a rapidement été présenté par certains acteurs du GEO comme une nouvelle brique incontournable de l'optimisation pour les IA. Mais, dans le même temps, certains experts ont appelé à la prudence sur ce point, en s'appuyant sur des constations et des tests maisons.

Les limites structurelles du format pointées par les experts

Le premier argument avancé par Daniel Roch est l'absence de standard reconnu. Le fichier llms.txt n'a jamais été officiellement adopté par les grands acteurs du marché de l'IA générative, ce qui en fait une initiative communautaire plutôt qu'une norme établie.

Le deuxième argument porte sur la structure même du fichier. Son format est très permissif, ce qui signifie que son contenu peut varier considérablement d'un site à l'autre. Cette absence de cadre strict empêche de considérer le fichier comme fiable ou exhaustif. Un fichier llms.txt peut donc très facilement se révéler incomplet, devenir obsolète au fil du temps, ou être manipulé pour orienter artificiellement la perception d'un site par une IA.

Le troisième argument concerne les capacités déjà existantes des IA pour récupérer de l'information. Les modèles disposent d'autres moyens techniques pour explorer et comprendre le contenu d'un site, ce qui rend un fichier de synthèse dédié moins indispensable qu'on ne le présente parfois.

Enfin, le quatrième argument touche à la nature même des requêtes adressées aux IA. Pour une grande partie des questions posées, l'intelligence artificielle cherche une réponse précise et localisée dans le contenu, pas une vision d'ensemble du site fournie par un fichier global. Un llms.txt, par construction, ne peut offrir qu'une vue générale, ce qui correspond rarement à ce que l'IA va réellement chercher pour répondre à une requête spécifique.

Ce que Google recommande à la place

Au-delà du cas du llms.txt, la documentation de Google liste d'autres pratiques GEO considérées comme inutiles pour son propre moteur.

• Le découpage du contenu en petits fragments, connu sous le nom de chunking, n'est pas nécessaire. Les systèmes de Google sont en effet capables de comprendre plusieurs sujets traités sur une même page et d'en extraire la partie pertinente pour chaque utilisateur.
• La longueur idéale d'une page n'existe pas dans l'absolu, et le bon réflexe reste d'écrire pour son audience plutôt que pour un système d'IA.
• Réécrire du contenu spécifiquement pour les IA n'est pas non plus utile selon Google, qui indique que ses systèmes comprennent les synonymes et le sens général d'une recherche, sans nécessiter une correspondance exacte de mots-clés.
• Les mentions artificielles d'une marque à travers le web sont également écartées, Google misant sur ses systèmes de détection de contenu de qualité et de lutte contre le spam.
• Enfin, les données structurées ne sont pas requises spécifiquement pour l'IA générative, même si leur usage reste recommandé dans une stratégie SEO globale, notamment pour l'éligibilité aux résultats enrichis.

Google recentre ainsi le débat sur les fondamentaux déjà connus du SEO : une structure technique claire, un contenu non générique apportant un point de vue ou une expertise réelle, et une expérience de page satisfaisante pour les visiteurs. Pour le moteur, optimiser pour la recherche générative reste avant tout une question de SEO, et non une discipline distincte nécessitant de nouveaux formats ou de nouvelles balises.

L’article "Google confirme qu’il ignore le fichier llms.txt et clôt le débat" a été publié sur le site Abondance.

Au programme de cette édition Réacteur de juin 2026 :

• SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search, par Lou Pichard
• Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA, par David Groult et Erwann Cardon
• Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites, par Indiana Aflalo
• Pourquoi vous continuez de produire du contenu… pour rien [partie 2], par Killian Le Moal
• Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline, par Sylvain Deauré

On remercie chaleureusement nos 6 auteurs et autrices pour leur réactivité et surtout la qualité des articles publiés : Indiana Aflalo, Lou Pichard, David Groult, Erwann Cardon, Killian Le Moal et Sylvain Deauré.

En bonus : comme à l’accoutumée, cette nouvelle édition accueille également notre veille de juin 2026 et une présentation des outils qui ont retenu notre attention ces dernières semaine !

 Accéder à l’édition complète

Et, si ce n’est pas encore le cas, abonnez-vous !

SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search

Par Lou Pichard, directeur SEO chez Eskimoz Bordeaux

À découvrir dans cet article :

• SFCC est partout (Adidas, Lacoste, Sandro, Maje...), mais reste l'un des CMS les moins documentés du marché. 2025 change la donne : refonte du centre d'aide et arrivée de l'agent IA AgentForce directement dans la doc.
• SFRA vs Composable Storefront : deux architectures, deux logiques SEO radicalement différentes. Sitemap, canoniques, SSR, Core Web Vitals... tout change selon le Core Model choisi.
• Les modules natifs les plus puissants de SFCC enfin expliqués clairement : URL Rules, Page Meta Tag Rules, et surtout les trois systèmes de redirection avec leur ordre de priorité (celui qui débloque des heures de débogage).
• Pas de .htaccess, pas de Schema.org natif : les vraies limites de la plateforme et comment les contourner avec du développement ciblé.
• Le virage Agentic Commerce arrive. Avec le partenariat Stripe-OpenAI, votre catalogue SFCC devra bientôt être lisible par les agents IA avant même de l'être par Google.

Ce qu'on a aimé :

Un vrai travail de démystification d'une plateforme réputée fermée et où la connaissance se transmet surtout en interne ou en agence. L'article de Lou Pichard rentre dans le détail opérationnel : ordre de priorité des modules de redirection, dépendance entre données catalogue et meta tags, méthodologie pour découper un cahier des charges SEO en trois briques (natif, configuration, développement custom). Exactement le genre de repères qu'on cherche en vain dans la documentation officielle de Salesforce. Pas de théorie creuse, mais des seuils précis et des outils actionnables. Un article sans concession, qui en fera réfléchir plus d’un !

SEO & Salesforce B2C Commerce : dompter la puissance de SFCC pour le search

Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA

Par David Groult, Head of SEO et Erwann Cardon, Consultant SEO Senior @NOIISE

À découvrir dans cet article :

• 8 marques, 8 secteurs, 8 logiques différentes. Autant d'exemples concrets de fiches produit qui transforment vraiment la décision d'achat.
• Le simulateur de taille ASOS analysé en détail. Comment une marque transforme l'incertitude de taille en preuve sociale personnalisée, avec un impact direct sur les retours et la marge.
• LDLC ou comment une caractéristique technique devient un levier SEO. Relier chaque spécification produit à une page de facette crée un maillage qui sert autant l'utilisateur que le crawler.
• Une grille de lecture en 5 types de gains d'information pour savoir précisément ce qui manque sur vos fiches.
• Une checklist d'audit complète pour évaluer vos fiches produit avec un regard neuf, au-delà du title et du H1.

Ce qu'on a aimé :

L'angle adopté est rare : au lieu d'une liste de bonnes pratiques génériques, l'article décortique huit cas réels et explique précisément pourquoi chaque dispositif fonctionne, sans tomber dans le name dropping superficiel. La distinction entre les différents types de gains d'information donne une grille de lecture immédiatement actionnable, et l'avertissement final sur le risque de surcharge évite l'écueil classique du « ajoutez toujours plus de contenu ».

Fiche produit e-commerce : pourquoi le gain d’information devient un vrai levier SEO, Shopping et IA

Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites

Par Indiana Aflalo, consultante SEO/GEO et fondatrice d’IndHack

À découvrir dans cet article :

• Une victoire à 139 mentions, mais portée à 80% par seulement deux IA sur cinq. L'analyse moteur par moteur révèle des comportements radicalement différents entre Claude, Mistral, ChatGPT, Perplexity et Gemini.
• Les sept piliers d'une méthode GEO complète… avec des exemples de code à l'appui.
• Le « fan-out » expliqué à travers une architecture concrète. Un hub et dix pages alignées sur les sous-intentions que les IA génèrent en arrière-plan pour construire leurs réponses.
• L'effet « winner-takes-all » sur Mistral, observé en conditions réelles. Comment un moteur peut citer jusqu'à six URLs d'un même domaine dans une seule réponse, une fois la source identifiée comme dominante.
• Les échecs documentés sans filtre. Reddit banni, Wikidata refusé, robots.txt qui bloque les bots IA pendant 24h... Et ce qu’il faut en retenir.

Ce qu'on a aimé :

Une transparence rare sur ce qui n'a pas marché autant que sur ce qui a marché. Indiana Aflalo ne se contente pas d'annoncer une victoire, elle décortique pourquoi Claude et Mistral ont réagi alors que Gemini et Perplexity sont restés hermétiques, avec des hypothèses précises pour chaque moteur. La distinction entre ce qui se transpose à un vrai site et ce qui ne se transpose pas (le contexte artificiel du concours) donne à l'article une vraie valeur méthodologique, au-delà du simple récit de performance.

Devenir une source que les IA citent : méthode, analyse moteur par moteur et limites

Pourquoi vous continuez de produire du contenu… pour rien [partie 2]

Par Killian Le Moal, Lead GEO-SEO Strategist & Innovation @ Peak Ace agency

À découvrir dans cet article :

• Un « stress test » en 3 questions à faire passer à ChatGPT sur vos 200 premiers mots.
• L'anatomie d'un chunk citable, avec un exemple avant/après bluffant. Deux versions de même longueur, un potentiel de citation radicalement différent.
• Les chiffres de fan-out par LLM qui changent tout. De 22,6 % chez ChatGPT à 98,7 % chez Gemini, avec des conséquences concrètes sur la façon de structurer vos pages.
• Trois « fausses bonnes idées » du GEO déconstruites avec des données… Ce qui marche vraiment et ce qui est une perte de temps.
• Une nouvelle grille de KPIs pour mesurer la visibilité dans les IA génératives, en complément du SEO classique.

Ce qu'on a aimé :

Le côté très opérationnel de cette deuxième partie : chaque concept s'accompagne d'un protocole, d'un exemple concret ou d'un chiffre sourcé, jusqu'à la checklist actionnable en fin d'article. La déconstruction des mythes GEO (llms.txt, Markdown, pages longues) tranche avec le discours ambiant et s'appuie sur des études récentes plutôt que sur des intuitions. C'est le genre d'article qu'on garde sous la main pour auditer ses propres pages.

Pourquoi vous continuez de produire du contenu… pour rien [partie 2]

Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline

Par Sylvain Deauré, Co-fondateur de 1492.vision

À découvrir dans cet article :

• Plus de 20 pipelines Discover aux logiques radicalement différentes, basés sur l'analyse de 42 millions de cartes. La vraie question n'est plus « suis-je dans Discover », mais « dans combien de pipelines suis-je visible ».
• L'effet multiplicateur du multi-pipeline. 58 % des URLs françaises apparaissent dans 2 pipelines ou plus, avec des outliers qui en atteignent 12 à 14 simultanément.
• Le modèle Ouest-France décrypté : comment un double ancrage local + national permet d'atteindre 25 pipelines distincts, un record pour un éditeur traditionnel.
• Ce qui plafonne structurellement le multi-pipeline : test produit pur, sport quotidien, lifestyle... avec les leviers concrets pour en sortir.
• Un signal émergent à surveiller : un pipeline d'intake social a été multiplié par 33 en trois mois, alimenté à 72 % par X.com.

Ce qu'on a aimé :

Le scorecard par profil d'éditeur (presse nationale, presse régionale, tech/review, sport, lifestyle, vidéo) qui distingue précisément les pipelines naturels et ceux à conquérir : c'est immédiatement actionnable, on peut se situer et identifier ses marges de progression. Les cas concrets (Le Monde, Ouest-France, Frandroid, L'Equipe, programme-tv.net) avec leurs empreintes pipelines détaillés offrent une grille de lecture qu'on ne trouve nulle part ailleurs.

Comment multiplier sa présence dans Google Discover : l'effet multi-pipeline

Comme tous les mois, cette nouvelle édition de Reacteur s’accompagne d’une rubrique dédiée aux derniers outils à tester et les articles qui ont retenus notre attention sur le web !

L’article "L’édition de juin 2026 de Réacteur est en ligne !" a été publié sur le site Abondance.

Article sponsorisé par Sedestral

Pourquoi la technique reste le parent pauvre des stratégies SEO

Dans la grande majorité des stratégies de référencement naturel, la répartition des efforts suit un schéma prévisible : le contenu d'abord, le netlinking ensuite, et le SEO technique quand on trouve le temps. Nulle négligence ici, mais plutôt une réalité opérationnelle. Produire des articles ou acquérir des liens génère des résultats plus visibles, plus facilement attribuables, plus faciles à valoriser en interne.

L'audit technique, lui, est perçu comme un chantier : il faut crawler le site, interpréter des rapports denses, prioriser des centaines de problèmes potentiels, puis les transmettre à des développeurs qui ont d'autres priorités.

Le résultat est souvent le même, avec des erreurs qui s'accumulent. Des pages importantes ne sont pas indexées. Des balises title sont dupliquées ou absentes. Des redirections mal configurées diluent le jus de liens. Des Core Web Vitals dégradés pénalisent le positionnement sur mobile. Aucun de ces problèmes n'est spectaculaire en soi, mais leur accumulation finit par peser lourd dans la balance des classements.

C'est précisément ce terrain que Nox, l'agent IA d'audit technique de Sedestral, a été conçu pour couvrir : transformer une tâche complexe, chronophage et souvent reportée en un processus continu et automatisé.

Ce que couvre réellement un audit SEO technique complet

Avant de comprendre ce que fait l’agent IA Nox, il est utile de rappeler l'étendue du périmètre qu'un audit technique rigoureux devrait couvrir. On parle rarement d'un seul type de vérification, mais d'une série de couches imbriquées.

• La première concerne la structure HTML et les balises. Chaque page doit disposer d'une balise title unique et optimisée, d'une méta description correctement renseignée, d'une hiérarchie de titres Hn cohérente. Des erreurs à ce niveau affectent directement la façon dont Google comprend et classe le contenu.
• La deuxième touche à l'indexation. Est-ce que le fichier robots.txt bloque involontairement des sections importantes ? Le sitemap.xml est-il à jour et correctement soumis ? Les balises canoniques sont-elles bien implémentées ? Les directives noindex sont-elles utilisées à bon escient, sans exclure des pages stratégiques ? Ces questions semblent techniques, mais leurs conséquences sont directement visibles dans les classements.
• La troisième dimension est celle de la performance et des Core Web Vitals. Google utilise ces signaux comme facteur de classement depuis 2021. Un site qui charge lentement à cause d'images non compressées, de scripts bloquants ou d'un cache mal configuré perd des positions, en particulier sur mobile.
• La quatrième englobe la sécurité et l'accessibilité : validité du certificat SSL, absence d'erreurs 4xx et 5xx, accessibilité mobile, conformité des données structurées.
• Enfin, pour les sites locaux, l'audit doit aussi vérifier la cohérence des informations NAP (nom, adresse, téléphone) et la configuration Google My Business.

Réaliser ce travail manuellement, de façon exhaustive, sur un site de plusieurs centaines de pages, représente plusieurs jours de travail. Et ce travail est à recommencer régulièrement, puisqu'un site évolue en permanence.

Agent IA vs outil d'audit classique : quelle différence concrète ?

Des outils comme Screaming Frog, Semrush ou Ahrefs permettent déjà de détecter une large part de ces problèmes. Mais leur output prend, par nature, la forme d’une liste. Parfois une très longue liste. Il revient ensuite à l'utilisateur d'interpréter chaque signal, d'évaluer sa gravité, de le mettre en contexte avec les objectifs du site et de décider quoi traiter en priorité. C'est à ce stade que la plupart des audits s’avèrent incomplets : faute de temps ou d'expertise, on traite les problèmes évidents et on ignore le reste.

Un agent IA comme Nox fonctionne différemment à deux niveaux : 

• D'abord, il ne se contente pas de signaler : il évalue l'impact SEO de chaque problème et établit une liste de correctifs classés par ordre de priorité. 
• Ensuite, pour chaque erreur identifiée, il explique clairement ce qui pose un problème et indique comment le corriger, étape par étape, dans un langage accessible. On passe d'un rapport brut à un plan d'action opérationnel.

C'est la différence structurelle entre un outil qui analyse et un agent qui raisonne. Le premier vous donne des données. Le second vous dit quoi faire avec.

Comment Nox audite concrètement votre site

Le processus de Nox s'articule autour de trois grandes phases d'analyse, menées de façon systématique sur l'ensemble des pages du site.

Analyse de la structure HTML et des balises SEO

Nox commence par inspecter le code HTML de chaque page. Il détecte les erreurs de structure, vérifie la conformité des balises title et méta descriptions (présence, unicité, longueur), contrôle la hiérarchie des titres Hn et identifie les problèmes qui impactent directement la lecture du contenu par les moteurs. Il relève aussi les erreurs de redirection (chaînes de redirections, redirections vers des pages en erreur) et vérifie la configuration du robots.txt et du sitemap.xml.

Test de performance et de sécurité

Nox teste ensuite votre site comme le ferait un véritable utilisateur, en mesurant les Core Web Vitals avec précision. Il identifie les éléments qui dégradent les performances : images non optimisées, scripts bloquant le rendu, gestion du cache insuffisante, problèmes d'affichage mobile. Il vérifie également la validité du certificat SSL et détecte les risques de sécurité associés.

Vérification de l'indexation en connexion avec Google Search Console

C'est l'une des dimensions les plus différenciantes de Nox. Au-delà de la vérification statique des balises canonical, des directives noindex et de la présence du sitemap, l'agent est capable d'appeler directement l'API Google Search Console. Cela lui permet de croiser les pages découvertes lors du crawl avec les données d'indexation réelles fournies par Google : une page est-elle effectivement connue de Google ? Est-elle indexée ?

Si ce n'est pas le cas, Nox peut la soumettre automatiquement à l'indexation, sans intervention manuelle. C'est ce qui permet de gérer l'indexation non pas comme un chantier ponctuel, mais comme un processus continu : chaque nouvelle page publiée, chaque page corrigée peut être soumise au bon moment, sans attendre le prochain crawl de Google.

Cette connexion avec la Search Console couvre également le contrôle des données structurées et de l'optimisation locale, notamment la vérification des informations NAP et de la fiche Google My Business pour les sites à dimension locale.

La priorisation : ce qui distingue un rapport utile d'une liste de problèmes à régler

Un audit complet sur un site de taille moyenne peut générer plusieurs centaines d'alertes. Sans hiérarchisation, ce volume peut être contre-productif : l'équipe ne sait pas par où commencer et finit souvent par ne rien traiter.

Nox évalue l'impact de chaque problème sur le référencement et établit une liste de correctifs classés par ordre de priorité. Ce classement n'est pas arbitraire, mais repose sur la nature de l'erreur et son poids potentiel sur le positionnement. Une balise title absente sur la page d'accueil n'a pas le même impact qu'une balise alt manquante sur une image secondaire. Une page stratégique bloquée par le robots.txt n'a pas le même impact qu'une redirection 301 sur une URL secondaire.

Pour une PME sans ressources techniques dédiées, ou pour une agence qui gère un portefeuille de sites clients, cette priorisation est décisive. Elle transforme un audit en plan d'action, avec une entrée claire. A savoir, commencer par le haut de la liste.

Ce que vous gardez sous contrôle

Comme pour les autres agents de Sedestral, Nox ne court-circuite pas la décision humaine sur les corrections à apporter. Il détecte, analyse, priorise et explique. Les modifications sur le site restent à votre main ou à celle de vos développeurs.

L'exception concerne la soumission à l'indexation via l'API Search Console, qui peut être gérée de façon automatisée par l'agent IA. C'est une action technique sans risque, qui ne modifie pas le contenu du site et qui, sans automatisation, représente une tâche répétitive chronophage.

Pour tout le reste, Nox produit un rapport détaillé et actionnable, avec les explications nécessaires pour que chaque correction puisse être appliquée sans expertise technique avancée. L'objectif est de rendre le SEO technique accessible à des équipes qui n'ont pas de consultant SEO à plein temps.

Les limites à garder en tête

Un agent IA d'audit technique ne remplace pas l'analyse contextuelle d'un consultant expérimenté face à des problématiques d'architecture complexes. Sur un site e-commerce avec des milliers de pages générées dynamiquement, des configurations de facettes ou des problèmes de contenu dupliqué à grande échelle, l'arbitrage stratégique reste avant tout humain.

De même, certains problèmes d'indexation ont des causes contextuelles que seule une lecture globale du site permet d'identifier, qu’il s’agisse d’une pénalité manuelle, une cannibalisation entre pages proches sémantiquement, ou une mauvaise gestion des paramètres d'URL sur un site international.

Ces limites ne remettent pas en question l'utilité de Nox, elles en précisent le périmètre optimal, que cela soit les PME, les e-commerçants et les agences qui gèrent plusieurs sites en parallèle. Dans ces cas, l'agent libère un temps d'expertise considérable pour les décisions stratégiques, en automatisant la détection, le tri et le guidage des corrections techniques.

L’article "SEO technique : comment un agent IA peut auditer et corriger votre site à votre place" a été publié sur le site Abondance.

Un retour aux sources vingt ans après

Sundar Pichai n'a prononcé qu'un seul autre discours de ce type auparavant, en 2020, en pleine pandémie de Covid. Il l'avait alors filmé depuis son jardin pour une cérémonie virtuelle, à une époque où les diplômés ne pouvaient pas se réunir.

Cette fois, le contexte est tout autre. Il s'adresse à la promotion 2026 dans une ambiance de célébration classique, entouré pour la première fois de ses propres parents lors d'une cérémonie de ce genre. Il en profite pour les remercier publiquement, ainsi que toute sa famille présente dans le public.

Avant d'entrer dans le vif du sujet, il évacue rapidement un sujet qui revenait dans les conseils qu'on lui donnait pour préparer son discours : éviter certains jeux de mots sur son nom de famille. Il choisit de ne pas s'y attarder, estimant que ce genre de détail n'a aucune importance face à ce qu'il veut transmettre.

Premier principe : choisir l'optimisme

Le premier principe développé par Sundar Pichai consiste à choisir une lecture optimiste des situations, même quand le contexte est difficile.

Il rappelle que chaque génération a connu ses propres difficultés, et que si l'on ne choisit pas le monde dans lequel on grandit, on choisit la façon dont on l'interprète. Il illustre cette idée avec son enfance à Chennai, en Inde, marquée par des pénuries d'eau et un accès très progressif aux technologies du quotidien comme le téléphone, la télévision ou le réfrigérateur. Malgré ces contraintes, ses parents ne l'ont jamais empêché d'imaginer un avenir différent, jusqu'à envisager une carrière dans la Silicon Valley.

Quand Stanford l'accepte, son père dépense l'équivalent d'un an de salaire pour lui payer son billet d'avion, le tout premier de sa vie. Une fois en Californie, la réalité ne correspond pas tout à fait à l'image qu'il s'en faisait. Il découvre des collines plutôt brunes que vertes, ce qui lui inspire une remarque spontanée auprès de sa famille d'accueil. Sa logeuse, Jane Earl, lui répond alors qu'on préfère dire qu'elles sont dorées plutôt que brunes. Cette reformulation toute simple devient pour lui l'illustration parfaite de ce qu'il appelle l'optimisme californien.

Il applique ce même principe à un tournant important de son parcours étudiant. Arrivé à Stanford avec l'objectif de poursuivre un doctorat et de se diriger vers le monde académique, il doit finalement quitter ce programme pour des raisons pratiques et obtenir à la place un master. Plutôt que de voir cela comme un échec, il choisit d'y voir une autre forme de réussite, fidèle à la logique des collines dorées.

Deuxième principe : se tourner vers les sujets difficiles

Le deuxième principe consiste à privilégier les projets les plus ambitieux, même quand ils paraissent presque impossibles.

Sundar Pichai raconte que son parcours après Stanford n'a rien eu d'un succès immédiat. Il lui faut près d'une décennie avant de trouver véritablement sa voie, jusqu'à son entretien final chez Google en 2004, le jour même du lancement de Gmail. À l'époque, proposer un gigaoctet de stockage gratuit à tous les utilisateurs semblait être une idée presque irréaliste.

Quelques années plus tard, il se retrouve à la tête d'un petit groupe d'une dizaine de personnes chargé de repenser entièrement le navigateur web, à un moment où le web passe de simples pages statiques à des applications beaucoup plus riches. En interne, beaucoup pensent qu'un tel projet nécessiterait des centaines d'ingénieurs.

Le lancement de Chrome a lieu en 2008. Huit millions d'utilisateurs adoptent le navigateur dès les premières vingt-quatre heures, mais la croissance stagne ensuite rapidement. Un an plus tard, Chrome ne représente encore qu'environ deux pour cent de parts de marché. Steve Ballmer, alors patron de Microsoft, ironise publiquement sur ces résultats lors d'une interview. Plutôt que de se laisser décourager, l'équipe interprète cette remarque comme la preuve qu'elle dérange, et donc qu'elle est sur la bonne voie.

L'équipe se fixe alors des objectifs volontairement très ambitieux et adopte un rythme de mise à jour bien plus rapide que la concurrence, avec une nouvelle version livrée toutes les six semaines. Cette persévérance finit par porter ses fruits. Pour Sundar Pichai, s'attaquer à des sujets difficiles attire naturellement des personnes compétentes et optimistes, et même en cas d'objectifs non atteints, le résultat final reste souvent remarquable.

Troisième principe : suivre sa passion

Le troisième principe consiste, à compétences ou conditions égales, à choisir ce qui suscite un véritable enthousiasme.

Pour Sundar Pichai, ce moteur a toujours été l'accès à la technologie. Il se souvient de son arrivée à Stanford en 1993, où il découvre pour la première fois des salles entières d'ordinateurs accessibles librement, alors qu'il n'y avait quasiment pas eu accès auparavant. Il perçoit immédiatement internet, alors en pleine construction, comme un levier de progrès humain majeur, ce qui motive directement son choix de rejoindre Google puis de travailler sur des projets comme les Chromebooks et Android.

Il évoque ensuite deux souvenirs marquants liés à l'impact concret de ces technologies :

• Des femmes en zone rurale en Inde utilisant pour la première fois un smartphone Android pour apprendre un métier et garder le contact avec leurs proches,
• Et une classe à Pittsburgh où des élèves d'origines très différentes apprennent grâce aux mêmes outils qu'il a contribué à développer.

Il conseille aux diplômés de ne pas orienter leurs choix en fonction des attentes de leurs parents, de leurs amis ou de la société en général, mais plutôt de repérer les sujets qui les font parler avec enthousiasme jusque tard dans la nuit, et de s'orienter vers ces sujets.

Pourquoi la plupart des décisions ne sont pas décisives

Pour illustrer l'idée que peu de moments sont réellement déterminants, Sundar Pichai raconte une anecdote de son année d'études à Stanford. Un camarade de classe nommé Pat lui propose un mercredi matin, sur le chemin des cours, de partir improviser un voyage à Las Vegas plutôt que d'assister au cours. Sans expérience de road trip ni habitude de sécher les cours, il accepte malgré tout.

Le trajet passe par les montagnes, où il découvre la neige pour la première fois. Une fois arrivés à Las Vegas neuf heures plus tard, Pat lui apprend à jouer au blackjack. Avec cinq dollars de mise initiale, il en gagne quinze de plus avant de s'arrêter, satisfait. Le lendemain, ils reprennent la route, et personne à l'université ne remarque leur absence.

Pour Sundar Pichai, cet épisode illustre bien la différence entre les quelques décisions qui méritent vraiment réflexion, comme le choix d'un partenaire de vie, la décision de fonder une famille ou un virage de carrière majeur, et les milliers d'autres moments du quotidien, comme un premier emploi, un déménagement ou un road trip improvisé, qui donnent du relief au parcours sans pour autant en déterminer la trajectoire.

L’article "Sundar Pichai livre un discours aux diplômés de Stanford 2026 : trois règles de vie à retenir" a été publié sur le site Abondance.

Des ajouts en masse signalés partout

Le phénomène a été repéré simultanément sur le Local Search Forum et sur X à partir de la semaine du 9 juin 2026. Le spécialiste du référencement local Len Raleigh a été l'un des premiers à tirer la sonnette d'alarme : une vague massive de numéros WhatsApp incorrects venait d'être ajoutée sur des Google Business Profiles. Rhea Velgos a pour sa part indiqué avoir reçu des notifications par e-mail de Google concernant trois fiches mises à jour avec un lien de chat WhatsApp dans le champ dédié.

Google envoie bien des e-mails d'information aux propriétaires concernés, mais tous ne les ont pas forcément vus. Il est donc conseillé de vérifier directement sa fiche Google Business Profile pour s'assurer de ne pas être affecté.

Des numéros fixes ajoutés à la place de numéros WhatsApp compatibles

Le problème ne se limite pas à un simple ajout non sollicité. Dans plusieurs cas documentés, le numéro WhatsApp affiché correspond au numéro de téléphone principal de l'établissement, qui est une ligne fixe. Or, les lignes fixes ne prennent pas en charge la messagerie texte ni WhatsApp. Le numéro ajouté est donc non seulement inutilisable pour les clients qui tenteraient de contacter l'entreprise via ce canal, mais il peut aussi induire en erreur et générer une mauvaise expérience utilisateur.

Aucune option de suppression disponible pour l'instant

Ce qui aggrave la situation, c'est l'absence totale de solution côté interface : lorsque les gestionnaires tentent de retirer le numéro WhatsApp erroné depuis leur tableau de bord Google Business Profile, l'option de suppression n'est tout simplement pas disponible. Les entreprises concernées se retrouvent donc dans l'impossibilité d'agir par elles-mêmes.

Claudia Tomina, experte produit Google reconnue sur le Local Search Forum, a confirmé officiellement qu'il s'agit bien d'un bug et que Google travaille activement à le corriger. Aucun calendrier précis n'a cependant été communiqué pour la résolution du problème. En attendant un correctif, la seule chose à faire est de surveiller sa fiche et de vérifier les e-mails envoyés par Google pour rester informé de l'évolution de la situation.

L’article "Google Business Profile : des numéros WhatsApp ajoutés automatiquement et sans possibilité de suppression" a été publié sur le site Abondance.

Une part importante de vos conversions n’arrive jamais dans vos rapports. Selon les comparatifs server-side publiés en 2026 (Addingwell, Data Detective), les sites e-commerce perdent entre 30 et 40 pourcent de leurs données de conversion à cause des adblockers et des restrictions iOS, et la fourchette monte jusqu’à 30-70 pourcent quand on additionne tous les canaux. Ce signal manquant fausse vos rapports GA4, dégrade l’optimisation de vos campagnes Google Ads et Meta, et finit par coûter du média. Le tagging server-side est la réponse technique à cette érosion. Encore faut-il comprendre ce qu’il règle vraiment, ce qu’il coûte, et quand il devient pertinent. Pourquoi la collecte client-side perd du signal en 2026 Le modèle historique repose sur du JavaScript exécuté dans le navigateur du visiteur. Chaque tag (GA4, Google Ads, Meta Pixel) charge son propre script et envoie ses propres requêtes. Ce modèle fonctionne de moins en moins bien, pour trois raisons qui se cumulent. Adblockers et restrictions navigateurs Les bloqueurs de publicité ne se contentent plus de masquer des bannières. Ils interceptent les requêtes vers les domaines de tracking connus (google-analytics.com, facebook.net, doubleclick.net). Quand un visiteur utilise uBlock Origin ou un navigateur qui filtre nativement ces domaines, le tag ne se déclenche pas et l’événement disparaît. Sur certaines audiences techniques, la part de visiteurs concernés est loin d’être marginale. Le cap cookie 7 jours de Safari ITP Safari applique l’Intelligent Tracking Prevention (ITP). Concrètement, tout cookie first-party posé en JavaScript via document.cookie est supprimé après 7 jours d’inactivité. Et si le visiteur arrive sur le site via un paramètre de lien type gclid ou fbclid, ce délai tombe à 24 heures (documentation WebKit ITP, Stape, 2025). Résultat : un client qui revient au bout de dix jours est compté comme un nouvel utilisateur, les fenêtres d’attribution s’effondrent, et le calcul du retour sur investissement devient faux. Consent Mode v2 et l’enjeu DMA Depuis le 6 mars 2024, le Consent Mode v2 est obligatoire dans l’Espace économique européen au titre du Digital Markets Act (RESONEO, Google). Il introduit quatre paramètres de consentement : ad_storage, analytics_storage, ad_user_data et ad_personalization. Depuis juillet 2025, sans une implémentation correcte de ce mécanisme, le suivi des conversions Google Ads ne fonctionne plus correctement. La collecte est donc encadrée par le consentement, et la qualité de ce qui remonte dépend autant du juridique que de la technique. Une précision importante avant d’aller plus loin : le client-side ne disparaît pas. Il reste le prérequis qui alimente le serveur. Tout part de le dataLayer côté client, qui structure les événements dans le navigateur. Le server-side ne remplace pas cette brique, il la prolonge. GTM server-side : définition et architecture Le tagging server-side déplace une partie du traitement hors du navigateur, vers une infrastructure que vous contrôlez. Le principe est documenté par Google dans sa documentation officielle Google Tag Manager server-side, qui en détaille le rôle du client, du conteneur et les bénéfices en matière de contrôle des données. Le conteneur serveur et le rôle du client Un conteneur serveur GTM s’exécute sur un serveur, pas dans le navigateur. À l’intérieur de ce conteneur, un composant nommé « client » joue le rôle d’adaptateur : il reçoit les requêtes envoyées par le navigateur, les interprète, les transforme en événements et les met à disposition des tags. Le conteneur serveur dispatche ensuite ces événements vers les destinations finales (GA4, Google Ads, Meta Conversions API). Différence concrète avec le client-side La nuance est essentielle. En client-side, le navigateur envoie une requête sortante pour chaque vendor : une vers GA4, une vers Google Ads, une vers Meta, et ainsi de suite. En server-side, le navigateur n’envoie qu’une seule requête HTTP par événement vers votre conteneur serveur. C’est ce dernier qui génère ensuite les requêtes spécifiques à chaque destination (documentation officielle Google server-side). Le navigateur ne dialogue plus directement avec les plateformes publicitaires. Le flux de données étape par étape Le parcours d’un événement se lit en trois temps : Le navigateur envoie. Le dataLayer déclenche un événement, GTM web l’envoie en une requête vers votre sous-domaine de collecte. Le conteneur serveur transforme. Le client interprète la requête, reconstruit l’événement, applique vos règles (consentement, enrichissement, minimisation). Les tags transmettent. Le conteneur envoie une requête propre à chaque destination (GA4, Google Ads, Meta CAPI). Cette indirection est ce qui rend possible tout le reste : la maîtrise des cookies, le filtrage des données et la résistance aux blocages. Cookies first-party et durée de vie : le vrai gain technique C’est ici que le server-side change réellement la donne. Le sujet n’est pas l’esthétique de l’architecture, mais la persistance de l’identifiant visiteur. Contourner le cap 7 jours de Safari Le serveur pose le cookie via l’en-tête HTTP Set-Cookie, et non via document.cookie. Or, un cookie posé en HTTP depuis un sous-domaine first-party (par exemple sgtm.votresite.fr) échappe au plafond ITP de 7 jours. Il peut persister jusqu’à 400 jours (Stape, Snowplow, 2025). Le visiteur Safari qui revient au bout de trois semaines est donc reconnu, et la fenêtre d’attribution tient. Cookie posé en HTTP vs en JavaScript La règle est simple : Safari ITP cible le JavaScript, pas le HTTP. Un cookie écrit par document.cookie (donc côté navigateur) est plafonné. Un cookie écrit par l’en-tête Set-Cookie d’une réponse serveur ne l’est pas de la même façon. Le tableau ci-dessous résume la différence. Critère Cookie JavaScript (client-side) Cookie HTTP (server-side) Méthode de pose document.cookie En-tête Set-Cookie Cap Safari ITP 7 jours (24h via gclid/fbclid) Non plafonné de la même façon Durée de vie effective Quelques jours Jusqu’à 400 jours Sensible aux adblockers Oui (domaine de tracking) Réduit (domaine first-party) Domaine personnalisé et CNAME first-party Le mécanisme repose sur un sous-domaine qui partage le domaine racine de votre site. Vous créez un enregistrement CNAME (par exemple sgtm.votresite.fr) pointant vers votre conteneur serveur. Comme ce sous-domaine appartient au même domaine racine que le site, le cookie est considéré comme strictement first-party. C’est cette configuration qui rend la collecte plus exhaustive et plus fiable : moins de pertes, des identifiants qui durent, une attribution qui colle à la réalité. Plus de datas, moins de blabla. Héberger son conteneur serveur : Cloud Run, Stape ou solution managée Une bonne part de la littérature francophone est périmée sur ce point : App Engine n’est plus le standard. En 2026, le choix se joue entre une approche serverless que vous administrez et un hébergement managé. Google Cloud Run, le standard 2026 Cloud Run est l’option serverless recommandée aujourd’hui. La facturation se fait à la requête et au temps de calcul, donc elle varie avec votre trafic. En ordre de grandeur, comptez environ 45 USD par serveur et par mois, avec un minimum de 2 instances en production, soit autour de 90 USD par mois (TRKKN, Stape, Google Cloud Run pricing, 2026). Vous gardez le contrôle total de l’infrastructure, au prix d’un peu d’administration système. Solutions managées : Stape, Addingwell Si vous ne voulez pas gérer la couche serveur, les solutions managées provisionnent et maintiennent le conteneur pour vous. Stape propose un hébergement sGTM à partir de 17 à 20 USD par mois, à prix fixe et prédictible, avec un hébergement dans l’Union européenne disponible (Stape, Capterra/GetApp, 2026). Addingwell est une alternative française managée, positionnée plus haut de gamme. Dans les deux cas, vous gagnez du temps et évitez l’admin système. Le coût réel mois par mois Solution Coût indicatif Modèle Pour qui Cloud Run ~90 USD/mois (2 instances) À la requête et au calcul Équipe technique, contrôle total Stape Dès 17-20 USD/mois Prix fixe Démarrage, prédictibilité, UE Addingwell Haut de gamme Managé Accompagnement premium FR L’arbitrage est clair : Cloud Run pour le contrôle et la maîtrise des coûts à fort trafic, le managé pour aller vite sans ressource d’infrastructure. Si vous voulez monter vos équipes en compétence avant d’internaliser, une formation Google Tag Manager permet de cadrer le setup avant d’engager du budget serveur. Mettre en place GA4 server-side Voici l’ordre d’exécution concret pour faire remonter GA4 par le serveur. Créer et provisionner le conteneur Dans GTM, créez un conteneur de type Serveur (distinct de votre conteneur Web). Le provisionnement peut être automatique via Google Cloud Platform (Cloud Run ou App Engine en assistant) ou manuel sur Cloud Run via une image Docker. Configurez ensuite votre domaine personnalisé first-party (le CNAME sgtm.votresite.fr) pour que la collecte passe par votre propre sous-domaine. Configurer le client GA4 Le client GA4 est pré-installé dans le conteneur serveur. Son rôle est de capter les requêtes GA4 entrantes envoyées par votre conteneur Web (via le champ transport_url pointant vers votre domaine de collecte) et de les transformer en événements exploitables. Vérifiez que le transport_url est bien renseigné côté web, sans quoi rien n’arrive au serveur. Baliser et valider en mode preview Routez les événements via le tag GA4 server-side, puis testez. Le mode Preview du conteneur serveur affiche en temps réel les requêtes entrantes, les événements reconstruits et les tags déclenchés. Croisez-le avec les logs Cloud Run pour confirmer que les requêtes sortent bien vers GA4. Pour une implémentation propre, comptez généralement de quelques jours à deux semaines entre la mise en place et une production stable, selon la complexité de votre tagging existant et la qualité du dataLayer en amont. Google Ads et Meta CAPI via le serveur Le server-side ne sert pas qu’à GA4. C’est sur les plateformes publicitaires que le gain de signal pèse le plus, car chaque conversion récupérée nourrit l’optimisation des campagnes. Enhanced Conversions Google Ads côté serveur Le routage server-side vers Google Ads s’appuie sur les Enhanced Conversions. Les données first-party fournies par l’utilisateur (email, téléphone) sont hachées en SHA-256 côté serveur avant d’être envoyées, ce qui permet de rapprocher la conversion d’un compte Google tout en respectant la confidentialité. Envoyées depuis le serveur, ces conversions résistent mieux aux blocages côté navigateur. Meta Conversions API et déduplication Pour Meta, le serveur alimente la Conversions API (CAPI). Le point technique à ne pas rater : la déduplication. Si vous conservez le Pixel côté client en parallèle de la CAPI côté serveur, vous devez partager un même event_id entre les deux. Meta reconnaît alors qu’il s’agit du même événement et ne le compte qu’une fois. Sans cet identifiant partagé, vous risquez le double comptage et des données gonflées. Qualité du matching et données first-party En transmettant des conversions plus complètes et des paramètres de correspondance plus riches, le serveur améliore l’Event Match Quality côté Meta et la qualité du matching côté Google. Concrètement : une mesure plus juste, donc des algorithmes mieux nourris et des campagnes mieux optimisées. La science du clic alliée à l’art de la conversion prend ici un sens très opérationnel. Consent Mode v2 et minimisation des données côté serveur Un malentendu courant : le serveur dispenserait du consentement. C’est faux. Le serveur ne contourne pas le RGPD, il aide à mieux le respecter. Transmettre le signal de consentement au serveur Le signal de consentement est capté côté client par votre CMP, via les quatre paramètres du Consent Mode v2 (ad_storage, analytics_storage, ad_user_data, ad_personalization). Ce signal est transmis au conteneur serveur avec l’événement. Le conteneur respecte alors la décision du visiteur : il envoie ou bloque les données vers chaque destination en fonction du consentement reçu. Pour le détail de l’implémentation, vous pouvez valider votre setup Consent Mode en complément de cet angle serveur. Filtrer les données personnelles avant envoi C’est l’avantage de conformité propre au server-side. Comme vous contrôlez le conteneur, vous pouvez filtrer ou minimiser les données personnelles (PII) avant de les transmettre aux partenaires : supprimer un champ, tronquer une adresse IP, ne transmettre que le strict nécessaire à chaque vendor. Cette mise en conformité par la minimisation est impossible à ce niveau de finesse en pur client-side. La mécanique technique de ces clients et tags est détaillée dans le guide server-side tagging de Simo Ahava, référence sur le sujet. Mode avancé vs mode de base Deux configurations coexistent. En mode de base, aucun signal n’est envoyé tant que le visiteur n’a pas consenti : pas de consentement, pas de tag. En mode avancé, des pings anonymes sont envoyés même sans consentement, ce qui permet à Google de modéliser les conversions manquantes. Le choix entre les deux relève d’un arbitrage entre prudence juridique et complétude de la mesure, à trancher avec votre DPO. Performance et Core Web Vitals : l’effet sur le client Déplacer le traitement vers le serveur allège le navigateur. Reste à mesurer l’effet réel, sans le surestimer. Moins de JavaScript exécuté dans le navigateur En client-side, chaque vendor charge son script et émet ses requêtes depuis le navigateur. En server-side, le navigateur n’envoie qu’une seule requête par événement vers votre serveur. Le code des différents vendors n’a plus à s’exécuter côté client, ce qui réduit le poids JavaScript de la page. Impact sur le chargement des pages Moins de scripts tiers signifie moins de travail pour le thread principal et moins de connexions sortantes. Cela peut bénéficier aux Core Web Vitals, en particulier aux métriques liées à l’interactivité et au chargement. La tendance est favorable, mais l’ampleur du gain dépend directement du nombre de tags que vous retirez effectivement du conteneur Web. Les limites à connaître (latence serveur) Soyons honnêtes : le server-side ne fait pas disparaître le travail, il le déplace. Le conteneur serveur introduit une latence réseau côté serveur, et il faut le dimensionner pour absorber les pics de trafic. Le gain front est réel quand vous déportez beaucoup de tags ; il est marginal si votre setup client-side était déjà léger. Aucun chiffre universel ici : tout dépend de votre configuration de départ. Quand le server-side se justifie (et quand non) C’est la question qui manque à la plupart des contenus sur le sujet. Le server-side n’est pas un passage obligé : c’est un investissement qui doit être rentable. Les seuils où il devient rentable Le server-side se justifie quand plusieurs de ces conditions sont réunies : Trafic significatif : le volume de données récupérées devient mesurable. Budget média conséquent : chaque point de signal récupéré améliore l’optimisation, donc le ROAS. Plus vous investissez en Google Ads et Meta, plus le gain compte. Forte part de visiteurs Safari/iOS ou d’adblockers : c’est exactement la population perdue en client-side. Exigences RGPD/PII fortes : besoin de minimiser les données avant transmission. Dépendance aux conversions Google Ads et Meta : votre acquisition repose sur la fiabilité de ces signaux. Les cas où rester client-side suffit À l’inverse, l’investissement n’est pas justifié pour un petit site, un faible budget média, une audience peu exposée à Safari, ou une équipe sans ressource technique pour maintenir le conteneur. Cas fréquent et souvent ignoré : si votre setup client-side n’est pas optimisé, corrigez-le d’abord. Un dataLayer mal structuré ou un tagging incomplet ne se règlent pas en passant au serveur. On nettoie le client avant d’investir dans le serveur. Checklist de décision Critère Server-side recommandé Client-side suffit Budget média mensuel Élevé Faible Part Safari/iOS Importante Marginale Exigences PII/RGPD Fortes Standards Ressource technique Disponible Absente Setup client-side actuel Déjà propre À corriger d’abord Mis en face du média, le coût est modeste : environ 90 USD par mois sur Cloud Run, dès 17 USD sur une solution managée. Si vous dépensez plusieurs milliers d’euros par mois en acquisition, récupérer 30 à 40 pourcent de signal perdu paie ce coût sans difficulté. Les robots vous trouvent, les prospects vous choisissent : encore faut-il les compter correctement. Conclusion Le tagging server-side n’est pas un gadget technique, c’est une réponse à une érosion mesurable du signal. Cookies first-party qui durent jusqu’à 400 jours, conversions Google Ads et Meta plus complètes via Enhanced Conversions et CAPI, minimisation des données pour une meilleure conformité, allègement du navigateur : les bénéfices sont réels quand le contexte s’y prête. Mais la décision reste data-driven. Un trafic et un budget média conséquents, une forte exposition à Safari et aux adblockers, des exigences RGPD : voilà les conditions où l’investissement se rembourse. En dessous, mieux vaut consolider le client-side d’abord. Brioude allie l’expertise data, le SEO et le SEA pour transformer chaque clic en opportunité et chaque donnée en histoire à raconter. Vous vous demandez si le server-side est rentable pour votre site, ou comment fiabiliser votre collecte avant d’investir dans un conteneur serveur ? Parlons de votre projet de tracking avec nos experts.

L’article GTM Server Side : le guide complet pour bien collecter est apparu en premier sur Brioude.

Ce qu’on vous avait déjà montré, et que Google confirme

En septembre 2025, nous avions expliqué comment suivre Abondance sur Discover via le bouton « Suivre sur Google » et la page profile.google.com. En mai 2026, nous avions publié l’analyse des 54 éditeurs américains disposant de fonctionnalités enrichies (bannière, liens configurables, publications épinglées, ordre des onglets personnalisable) sans communication officielle de Google à l’époque.

L’annonce du 4 juin valide cette lecture : il s’agissait bien d’un programme pilote, pas d’un gadget. Google parle maintenant de « Search profiles », d’un espace dédié pour mettre en avant articles, vidéos et posts sociaux, ainsi que d’un lien explicite avec le knowledge panel. Les éditeurs éligibles peuvent réclamer un profil auto-généré ou en créer un ; le suivi depuis le profil alimente Discover.

Chez 1492.vision, notre monitoring couvre près de 47 000 profils Discover dans 7 langues. La cohorte des 54 domaines US analysée en détail était avant l'annonce officielle le seul groupe avec accès persistant aux fonctions enrichies que nous avions cartographiées, mais l’infrastructure sous-jacente existe déjà pour des milliers d’éditeurs, y compris francophones, sous forme de profils auto-générés.

Les chiffres qui structurent l’accès

Éligibilité à la réclamation (au moins un compte sur une plateforme majeure) :

Autres contraintes documentées : résidence / disponibilité États-Unis uniquement pour l’instant ; âge minimum 18 ans ; un profil Search par compte Google (une autre identité = un autre compte Google).

Ce que permet un profil réclamé :

• Bannière (cover) : format carré en affichage, résolution recommandée 1080 × 1350 px minimum ;
• Jusqu’à 8 liens web (sections, live, météo, app, don…) ;
• Jusqu’à 8 publications épinglées issues des plateformes liées ;
• Handle profile.google.com/@… calqué sur le compte social le plus suivi parmi ceux connectés ;
• Insights (bêta) : clics, impressions, top contenus, pays : alimentés par une propriété Search Console générée pour le profil.

Rappel de notre analyse des 54 (détail dans l’article Abondance) : 41 bannières en ligne sur 54, 31 éditeurs avec au moins un lien configuré (65 liens au total), 13 avec un post épinglé actif, et seulement 3 liens instrumentés en UTM. Le paradoxe tient : la fonctionnalité est là, l’usage reste inégal, surtout chez les plus gros médias nationaux.

Éditable tout de suite vs validé par Google

Google distingue deux régimes :

• Immédiat : ordre des plateformes sociales, image de couverture, épinglage, liens web, retrait d’un compte erroné ;
• Soumis à validation : nom, bio, ajout d’une nouvelle plateforme non détectée automatiquement.

Conséquence pratique : si un réseau social n’apparaît pas sur votre profil auto-généré, la réclamation ouvre la possibilité de demander l’ajout d’un compte manquant. Le handle, lui, suit la logique de la plus grosse audience sociale liée, pas forcément votre préférence éditoriale.

Entités et Knowledge Graph

Sous le capot, le profil reste une surface Discover adossée au Knowledge Graph : réclamation possible depuis le knowledge panel (« View Search Profile »), enrichissement réciproque (avatar, contenus récents, lien direct). Pour Google, c’est un verrou de plus sur l’identité éditoriale (auteurs, marques, E-E-A-T) dans un écosystème où l’agrégation multi-plateformes devient critique. Le rôle des entités et du Knowledge Graph comme ossature des systèmes Google est confirmé, si besoin était.

« Pas directement » : ce que dit Google et ce qu’il faut en déduire

La FAQ officielle est explicite : « La création d’un Search profile n’affecte pas directement le classement de votre contenu sur Google Search. En revanche, si quelqu’un vous suit depuis votre profil, il peut voir davantage de votre contenu sur Discover. » 
Traduction opérationnelle : le Follow est un abonnement Discover (effet direct sur le flux pour les abonnés, comme les tests le démontraient) ; le ranking Search classique n’est pas promis, et le « pas directement » laisse la porte aux effets indirects (signaux d’engagement, fraîcheur d’audience), que ce soit sur Search ou sur Discover.
On se souvient de Navboost dans le contexte du Search, qui (indirectement) récompense les contenus les plus cliqués sur la serp. Des mécanismes similaires, quoique plus complexes et nuancés, sont à l’œuvre sur Discover.

Vers un Publisher Center 2.0 ? Intention Google, impact éditeurs

Nous l’avions évoqué dès notre première analyse Substack : cette page pourrait devenir un hub éditeur dans l’écosystème Google, non pas pour héberger du contenu (tout est tiré des plateformes liées), mais pour fédérer l’audience, redistribuer des clics et compenser une partie de la pression des résumés IA et de la personnalisation agressive sur Discover.

Rétention. Le Follow formalise une relation directe éditeur lecteur dans Google, comparable à une newsletter Discover : moins de dépendance au hasard algorithmique du flux.

Personnalisation. Plus de sources suivies = fil plus stable pour ces éditeurs ; Google consolide des signaux d’affinité explicites (opt-in) en plus des signaux implicites. Cela va d’ailleurs de pair avec les nouvelles fonctions de Discover « Tailor your feed », qui ouvrent très nettement la porte à une personnalisation explicite des flux.

Analytics. La section Insights, même en bêta et soumise aux seuils, ouvre une brèche : visibilité sur performances Search et Discover au niveau du profil, avec pont Search Console.

Presse locale. La composition du pilote (environ la moitié des 54 = TV locales + presse régionale) colle aux discours publics de Google sur le journalisme de proximité : le produit n’est pas pensé uniquement pour les mastodontes nationaux.

Publisher Center ? Pas de rebranding officiel, mais la fonction est proche : identité, liens, mise en avant, mesure, sans repasser par une interface obsolète. L’officialisation du 4 juin transforme une observation de terrain en feuille de route produit.

États-Unis seulement, mais préparez-vous dès maintenant

Search profiles réclamables : US uniquement. Aucun profil enrichi hors marché anglophone US dans notre monitoring à ce jour, conforme à l'annonce Google, mais on surveille. En revanche, votre profil auto-généré existe probablement déjà si Google vous a identifié comme entité : logo, bio (souvent Wikipedia), réseaux issus du graphe.

De nouveaux éditeurs US ont déjà pu créer leur profile, par exemple "Inspired taste":

Checklist avant l’ouverture FR :

1. Vérifier votre page profile.google.com (ou demander l’URL à @1492_vision si elle n’est pas encore visible dans Discover).
2. Auditer la cohérence des comptes sociaux déclarés.
3. Préparer une bannière carrée pro (la barre visuelle du pilote est haute).
4. Définir 3 à 5 liens prioritaires + convention UTM
5. Rédiger une bio « About » : sur les profils réclamés du pilote, 38 des 54 l’avaient réécrite : c’est votre pitch sur une page Google.

Quand l’éligibilité s’étendra, les éditeurs US auront déjà pris l’habitude ; les retardataires repartiront avec un désavantage d’usage, pas seulement d’accès.

Conclusion

Google officialise ce que nous monitorions depuis août 2025 : des profils éditeurs, un Follow Discover, et, pour une poignée d’élus US, une couche enrichie qui ressemble à un mini-site dans le flux. L’annonce du 4 juin ne change pas la donne pour les éditeurs francophones aujourd’hui, mais elle confirme la direction : entités consolidées, audience capturable, personnalisation explicite, analytics en renfort.

Nous continuons de suivre l’évolution des 47 000 profils monitorés.
L’analyse détaillée de la cohorte des 54 reste sur Abondance ; la version longue avec visuels est sur 1492.vision/research/discover-publisher-profiles-fr.

Sylvain Deauré & Damien Andell - 1492.vision

Comment s’abonner à Abondance sur Discover ?

1. Rendez-vous sur le profil Google d’Abondance.
2. Cliquez sur « + Suivre sur Google », sous le logo.
3. C’est tout : vos articles Abondance remontent plus souvent dans votre flux Discover personnel.

(Voir le guide complet.)

L’article "Vers un Publisher Center 2.0 ? Google officialise les profils étendus" a été publié sur le site Abondance.

Un nouveau coup de boutoir contre le scraping de SERP

Cet épisode s'inscrit dans la continuité directe de ce qu'on documentait en avril 2026 : Google ne se contente plus de bloquer les bots, il les nourrit de fausses données. Mais cette fois, le vecteur d'attaque est différent. Ce n'est plus la « soupe YouTube » qui est en jeu, c'est le mécanisme fondamental de géolocalisation des SERPs.

Jusqu'au 14 mai, il était possible pour n'importe quel outil SEO de récupérer la SERP française depuis une IP étrangère en ajoutant simplement le paramètre &gl=fr dans l'URL de requête sur google.com. C'est ce que faisait la quasi-totalité des outils du marché pour scraper à grande échelle, pour des raisons de coût et de disponibilité limitée des proxies français.

Google a récemment modifié la gestion du ciblage géographique de ses SERPs.

Le paramètre gl, utilisé pour cibler une région, n'est plus fiable.

Si votre IP est étrangère :
- vidéos YouTube/Facebook en page 5
- résultats instables dès la page 1

On en parle ci-dessous

— Monitorank (@monitorank) May 26, 2026

Ce qui a changé : &gl=fr ne suffit plus

Comme le communique Monitorank dès la détection du changement :

« Google a récemment modifié la gestion du ciblage géographique de ses SERPs. Le paramètre gl, utilisé pour cibler une région, n'est plus fiable. Si votre IP est étrangère : vidéos YouTube/Facebook en page 5, résultats instables dès la page 1. »

L'impact est immédiat et visible sur des mots-clés à très fort trafic. Fabien Barry l'illustre concrètement : un site présent en position 1 ou 2 sur la vraie SERP française peut ne plus apparaître du tout dans les résultats retournés par les outils non corrigés. Ce n'est donc pas uniquement un problème de pages profondes ou de résultats marginaux. Le top 1 peut être affecté.

Les mots-clés de référence pour tester

Monitorank a partagé une liste de requêtes permettant de vérifier par soi-même l'étendue du problème. Parmi les exemples documentés : « comparateur assurance auto », « iphone », « rachat de credit », « assurance habitation pas cher » ou encore « tenerife canaries ». Sur ces requêtes, certains sites présents en page 1 de la vraie SERP française n'apparaissent pas dans les résultats retournés par des outils ou API utilisant des proxies non français.

Comment vérifier par vous-même

La manipulation est simple à reproduire :

1. Connectez-vous à un VPN sur un pays non français.
2. Ouvrez une fenêtre de navigation privée (cookie Google vierge).
3. Effectuez une recherche sur google.com et ajoutez &gl=fr à l'URL.
4. Comparez avec les mêmes requêtes effectuées depuis une connexion française classique (sans VPN).

Les différences de classement observées reflètent exactement ce que vos outils de tracking voient en ce moment si leur infrastructure repose sur des proxies étrangers.

Monitorank et Ranxplorer : correctif déployé

Monitorank indique avoir identifié le problème rapidement après la mise à jour du 14-15 mai, avoir communiqué publiquement sur X, puis avoir travaillé plusieurs jours à la conception d'un correctif avant de le déployer et le valider à grande échelle. L'outil affirme avoir retrouvé sa puissance de scrape habituelle avec des résultats fiables. Ranxplorer et Goserp seraient également en mesure de fournir des données correctes selon les vérifications partagées par l'équipe.

Pour tous les autres outils, la prudence s'impose : en l'absence d'une communication explicite de l'éditeur sur ce sujet, les données de positionnement pour le marché français sont potentiellement non fiables depuis la mi-mai. Et comme lors des épisodes précédents, aucun tableau de bord n'affiche d'alerte : les données s'affichent normalement, qu'elles soient justes ou non.

L’article "Google casse la géolocalisation des SERPs : vos données de ranking sont-elles fiables ?" a été publié sur le site Abondance.